How to set Packet Send Time < 3 sec?

[jnh]

Could someone please post the special terminal command required to set a packet-send interval of less than 3 seconds?

I'm upgrading from an ECM-1240, and have found its second-by-second realtime reporting quite useful when testing equipment, tracking the cycling behavior of appliances, etc. So, I was disappointed to see that the GEM seems to enforce a 3-second minimum:

^^^SYSIVL001 -> IVL (acknowledged)
^^^RQSITV -> 03 (same for IVL002 or IVL000)

A search turned up this old post by Teken mentioning an early software change:

https://www.brultech.com/community/view ... imum#p4648

"Some of the release notes for the COM 2.37 ...
- Packet send interval minimum value set to 3 seconds. There was an issue where some customers would set this value too low and the GEM could not process the packets fast enough. This caused the GEM not to respond to commands or to the Setup Page. If a l If a lower packet send interval is required, this may be obtained by using a special command via terminal."

I can see how faster updates might be a problem with the more verbose ASCII-based formats (HTTP GET, etc.) and/or when communicating through a radio module or Dashbox, but I'll be using plain hardwired serial, and the more compact BIN32-NET (8) format, which at 429 bytes per packet, and 1 packet/sec should occupy less than 25% of even a 19200 bps line's capacity.

I won't be using the built-in web page interface, and will hardly ever send any commands to the GEM once it's placed in service. So, it would be no problem it takes a few tries at 1 pkt/sec for ^^^SYSOFF to be recognized. Also, none of the 1-wire sensors or pulse counters will be active, in case that helps with CPU loading.

^^^RQSTST -> 00000000
^^^RQSPST -> 0000

Running Com firmware 4.36, ENG firmware 1.49, which appear to be the latest.

[ben]

I just uploaded 5.13 COM to https://www.brultech.com/software. It should allow you to do 1 second with the Bin32 formats.

[jnh]

Thanks, Ben. I've updated my COM firmware to this 5.13 release. Attempting to set ^^^SYSIVL001 or ^^^SYSIVL002 (with packet type = 08) still gives a reporting interval of 3 seconds, though - ^^RQSITV returns 03, and updates come every 3 sec after a ^^^SYS_ON. Is another step necessary?

Since posting about this yesterday, I've modified my logging daemon to disable automatic realtime updates and instead poll the GEM every second with ^^^APISPT, which has been working reliably once I got the timing right. This solution might be preferable anyway, but it'd be good to have the option to either "push" or "pull"...

[ben]

Thanks, Ben. I've updated my COM firmware to this 5.13 release. Attempting to set ^^^SYSIVL001 or ^^^SYSIVL002 (with packet type = 08) still gives a reporting interval of 3 seconds, though - ^^RQSITV returns 03, and updates come every 3 sec after a ^^^SYS_ON. Is another step necessary?

Since posting about this yesterday, I've modified my logging daemon to disable automatic realtime updates and instead poll the GEM every second with ^^^APISPT, which has been working reliably once I got the timing right. This solution might be preferable anyway, but it'd be good to have the option to either "push" or "pull"...

Hmmm, might be an issue with the command. Are you able to try setting it thru the GEM Setup Webpage?

[jnh]

ok, setting a 1-second reporting time from the web GUI does work, as reflected in RQSALL after. I had to wait until I could reach the cabling to temporarily connect a different computer capable of accessing that interface (are the "serial bridge" and "TCP server" protocols, for passing web GUI traffic over RS-232 documented anywhere? I'd like to have a go at writing a Linux equivalent to this part of the GEM Network Utility, which does run under Wine on x86, but not from the little i.MX6 ARM mini-server that all my home automation stuff is normally attached to).

But, after setting this, for some reason I couldn't get the GEM to reliably generate real-time packets following ^^SYS_ON. Toggling several times between ^^^SYSOFF and ^^^SYS_ON would eventually get it transmitting at 1/sec for a while, but I wasn't confident this would continue working. In case it matters, I'm connected to the GEM's Com2 at 19200 bps (expecting my ~60' / 20m cable through the attic's probably too long for 115200), and the Com2 Packet Type == 00, which should duplicate what's being sent to Com1 (type 08). Next time I have the GEM's cover off I'll conect a short DE-9 pigtail so a laptop can be more easily brought out to it directly, and maybe move the permanent cable to its Com1.

For what it's worth, the polling method using ^^^APISPT, via Com2 at 19200 has been rock solid, at 3600 packets/hour since I installed the GEM - the ECM-1240 woud miss one every 58-59 minutes. I was hoping enabling realtime-mode might reduce the latency of updates slightly, if new measurements were to be sent as soon as they were available, but with further timing tweaks (sending another ^^^APISPT immediately after processing each packet) I have it about as responsive as the ECM-1240, with a little more than 1 seconds' delay from a load toggling on or off and this showing up in a packet. So, maybe there's no benefit to using realtime mode. I do like knowing that a flickering LED on the GEM means data is actually being read, rather than being fired off into the ether with perhaps nothing listening at the other end.

By the way, does the packet-send interval have any effect at all on accurate measurement of very small loads? Do fractional watt-seconds get truncated each time a packet is generated, such that, say a 1/2 watt load might show up as a one W-s every 2 seconds, but not if reported every second?

[ben]

ok, setting a 1-second reporting time from the web GUI does work, as reflected in RQSALL after. I had to wait until I could reach the cabling to temporarily connect a different computer capable of accessing that interface (are the "serial bridge" and "TCP server" protocols, for passing web GUI traffic over RS-232 documented anywhere? I'd like to have a go at writing a Linux equivalent to this part of the GEM Network Utility, which does run under Wine on x86, but not from the little i.MX6 ARM mini-server that all my home automation stuff is normally attached to).

But, after setting this, for some reason I couldn't get the GEM to reliably generate real-time packets following ^^SYS_ON. Toggling several times between ^^^SYSOFF and ^^^SYS_ON would eventually get it transmitting at 1/sec for a while, but I wasn't confident this would continue working. In case it matters, I'm connected to the GEM's Com2 at 19200 bps (expecting my ~60' / 20m cable through the attic's probably too long for 115200), and the Com2 Packet Type == 00, which should duplicate what's being sent to Com1 (type 08). Next time I have the GEM's cover off I'll conect a short DE-9 pigtail so a laptop can be more easily brought out to it directly, and maybe move the permanent cable to its Com1.

btcfg.py by mwall is pretty similar: http://lancet.mit.edu/mwall/projects/we ... n/btcfg.py in terms of pre-built tools (it just uses commands also).

The GEM Setup Webpage in some cases writes memory locations directly instead of using commands. I'll have Paul look at the 1-sec interval stuff.

For what it's worth, the polling method using ^^^APISPT, via Com2 at 19200 has been rock solid, at 3600 packets/hour since I installed the GEM - the ECM-1240 woud miss one every 58-59 minutes. I was hoping enabling realtime-mode might reduce the latency of updates slightly, if new measurements were to be sent as soon as they were available, but with further timing tweaks (sending another ^^^APISPT immediately after processing each packet) I have it about as responsive as the ECM-1240, with a little more than 1 seconds' delay from a load toggling on or off and this showing up in a packet. So, maybe there's no benefit to using realtime mode. I do like knowing that a flickering LED on the GEM means data is actually being read, rather than being fired off into the ether with perhaps nothing listening at the other end.

By the way, does the packet-send interval have any effect at all on accurate measurement of very small loads? Do fractional watt-seconds get truncated each time a packet is generated, such that, say a 1/2 watt load might show up as a one W-s every 2 seconds, but not if reported every second?

The GEM counts at a minimum 1 watt-second at a time (1-watt minimum). It'll likely show a blip every few seconds.