@peter - The graphs in emoncms can be misleading as results will always look much worse when using a fixed interval feed to record non-fixed interval data,
Depending on the sketch used the send interval may not match the fixed “save” interval, even if set to a fixed period in the sketch, the use of sleepy_lose_some_time could have a huge impact on the accuracy of that.
Then there is the “wait til it’s clear to send” function of the rfm devices and also the time taken to arrive at emonhub where it gets a timestamp.
See RF69 reliability, timing, temp sensors, mqtt & lowpowerlabs for a discussion on this. I have installations where I have recorded delays of up to 6 secs in transmission times due to rf clashing, that 6s delay can result in one empty “fixed-interval” datapoint, and then get overwritten by the next transmission if it on time and before the next “fixed-interval” save time.
That thread lists 3 reasons a packet could fail to be received
- corrupted packets when the rfm is being woken from a deep sleep too close to sending data.
- “bitslip” from long runs of zero’s
- sketch send intervals being too long to match a fixed interval
3 is primarily about setting a 10s sleep so the interval becomes 10s plus loop run time and shortening the sleep can work but allowance for timekeeping discrepancies need to be made which result in packets being discarded (overwritten) by emoncms PHPfina, eg 9s to be safe will be updated twice and saved once within a 10s interval 10% of the time. There are the other timing issues too
- packets that are delayed momentarily due to a noisy network
- lose_some_time extending the send interval beyond the fixed interval if interrupts are used (pulse counting)
The bottom line is you cannot use fixed interval feeds to assess packet reliability, you need to use a phptimeseries to confirm what packets you receive when.
item 1) was identified and has been fixed in the emonTH sketches by adding a small delay, it hasn’t been reported in other firmware but it is possible it could crop up else where.
Item 2) has been tackled in OEM sketches by using a non-zero out of range value for unused temp sensors.
item 3) has been improved by reducing the sleep times to allow for looptime in the later sketches but older devices may still be using the older firmware intervals
item 4) maybe improved by using later rfm2pi (recompiled with later JeeLib) firmware as the rssi threshold is higher
item 5) should only be an issue if pulse counting, the only sure fire way around this is to not reset millis() in the sleep routine I guess
Overall there is an ongoing incompatibility between fixed interval feeds and non-fixed interval send intervals, it has been improved but it cannot be eradicated unless some sort of polling or a way of identifying and correcting a late packet is implemented.
@Vster - the test firmware has had the help text restrained to a “h” command to make the logs easier on the eye and reduce any chance of rogue commands being accidentally issued during the needless printing and exchange of serial prints.
You can confirm the firmware has uploaded using a “v” in a serial console, checking the emonhub.log for the startup period or by reseting the rfm2pi, the led will flash rapidly 5 times for easy identification. aside from that the sketch is pretty much unchanged, just recompiled with the latest Libs.
and presumably messing up the totals too. My DIY box only missed them very infrequently, it could go days without missing a single packet from the EmonTX. Both the DIY box and the Pi are in a cupboard about 4 feet and internal walls from EmonTX.
