All the data comes from the modem.
My software then calculates the differences each minute.
e.g:-
sample 1 - RSCorr = 100
sample 2 - RSCorr = 150
Difference = 50
The graph reports 50 for that minute.
sample 3 - RSCorr = 175
Difference = (175 - 150) = 25
The graph reports 25 for that minute.
The connection then resyncs, so RSCorr = 0
sample 4 - RSCorr = 40
Difference = (40 - 0) = 40
The graph reports 40 for that minute.
& so on & so on.............................
Even if the modem's data isn't reset at a resync, the difference between the samples is calculated & reported in the graphs.
So, let's say RSCorr wasn't reset to zero, sample 4 would have been 215.
Difference = (215 - 175) = 40
The graph would still report 40 for that minute.
A special case is when the maximum value the modem can store is reached.
The value is then reset to zero.
Whatever data is stored by the next minute's sample is recorded & if there is only 1 minute difference between samples, whatever is recorded is reported in the graph.
However, if the data hadn't been harvested for a while, the first new sample could be a huge value & a great big spike incorrectly reported in the graph.
So, whenever there are 2 minutes or more between samples (e.g. the software/PC has been switched off), the data at the next sample is ignored to avoid the misleading spike, although the data is still recorded in modem_stats.log, ready to calculate the difference when the next minute's sample data is obtained.
So, between samples when the software isn't running, the difference could be say 100,000,000.
Reporting that as a minute by minute difference would be clearly wrong, so the very first sample after re-starting the software is ignored.
But the next sample is say 100,000,040
The one minute difference would then be only 40, which would be correct so it is reported in the graph.
The only graphs that don't work like that are DS & US OHF.
They aren't actually error counts as such, so whenever a few samples are missed, for whatever reason, the graphs intentionally report a spike, which acts as a visual 'flag' to indicate that there had been a pause or delay in sampling.
I have attached an example of the DS OHF graph from when my virus scanner slowed the PC down at 04:00 that much that a sample or two were missed or were delayed.
Thus spikes are seen
I have also attached the DS CRC graph from the same period. Spikes are not seen at 04:00.
The spikes that are shown in the DS CRC graph from earlier on are actually genuine CRC error spikes.