On the earlier Firmware? The snippet of data above shows a new frame from Node 10 at just over 10s. This does fit in with my experiences of old.
As Brian says the “discarded” packets in this log are just noise. In this 40s clip there are 3 good emonTx packets spaced around 10.8s apart, there are no missing packets to solve.
Alternatively search for “NEW FRAME : OK 10” and the count should equal the duration of the log/search in seconds divided by 10.8 or thereabouts (providing emonhub and the emontx were running throughout that period ie no restarts etc).
You are unlikely to eradicate all noise, that’s why the “quiet” mode is there, so we need to find the locations where “missing” data should be and see if there is a “discarded” packet around that time that maybe that missing packet but in some way deformed or incomplete to determine what has occurred to lose that good packet. It may even take several examples to spot a lass obvious issue.
You need to go back a few years to come to the time when it was nominally the same. It was probably in the emonTx V2 era. As far as I can recall, it’s never been deliberately longer. It’s all in the forum - somewhere.
I’ve found V2 sketches from 2015 and 2017 that have a 5 s delay, i.e. the reporting interval will be up to about 5.8 s, depending on the number of c.t’s in use, and a continuous sampling one from 2014 that has an exactly 10 s reporting interval.
I feel the 2017 sketch was probably one of the last.
Not sure how original…
The kit is pretty early, not only is the rfm2pi baud 9600, it is an rfm12b as there is no rssi. The payload is also very minimal which was indeed from the tx v2 era, but I do not think this is a v2 since there are 4 powers (CT’s), possibly an early v3.2 or a shield. The payloads only started getting bigger during the v3.2 -3.4 era, the shield is still minimal.
The earlier FW all had longer than intended intervals because there was a sleep equal to the interval so the loop time was effectively added to the set interval. It was a significant time after the introducrion of phpfina that the intervals were adjusted to favour a interval slightly under the set interval as it was decided it was better to actually discard good but “surplass” data than “appear” to have missed data due to a (for example) 11s update completely stepping over one 10s phpfina time slot to land the next but one, creating a gap. This latter approach is still used today, (except for the CM I believe).
Edit - Oct 2015 the policy changed from oversized to undersized intervals
On the Git version, the actual period (timed off the emonTx processor clock) is 9.96 s. I’ve been running all my tests on a reporting period of 9.85 s.
So for the record it is now working and I’m even clever enough to use the backup function so that I don’t get lost again.
I guess I took it for granted that it “just worked” for so long, with only the odd hiccup here and there. Life has moved on in many ways as had my knowledge of the moving parts.
As this is such an excellent and sustained open-source effort I am happy to help in any way if you would like further information to tweak/adjust/etc the platform as needed.