Tnx AndrewBNC
Hi Renate,
pleased to meet you.
The purpose of my current use is to understand how the code works by simply going to sample PIN PA15,
I don't care about "precision".
At PIN PA15 not having an oscillator available I used the SI5351 module that once calibrated,
set and lit from a few days, remains quite stable in frequency and remains "near" to 10MHz.
that's all.
My doubts derive from the fact that sometimes both on serial and on I2C LCD
I noticed too wrong values in the middle of 10s 100s 1000s.
This fact is true because as the current frequency is:
calcfreq64 = fcount64 - prepfcount64; // The Difference is Exactly The OCXO in Hz
It always proves "precise" in relation to previous readings, nothing "jump".
It must be there, somewhere in the mathematical account of the averages, a bug.
From here my intent to understand if there is some busted value that enters the circular buffer,
or a not appropriate truncation exists somewhere in the code.
Following another occurrence that was shortly after starting:
measurements using 64-bit counter:
64-bit Counter: 442704762
Frequency: 10000004 Hz
10s Avg: 10000004.3 Hz <= CORRECT FREQUENCY
100s Avg: 0.00 Hz
1,000s Avg: 0.000 Hz
10,000s Avg: 0.0000 Hz
avgupsec: 45
1 item circbuf_ten64: 11
0 circbuf_ten64
: 362704727
1 circbuf_ten64: 372704732
2 circbuf_ten64: 382704736
3 circbuf_ten64: 392704740
4 circbuf_ten64: 402704745
5 circbuf_ten64: 412704749
6 circbuf_ten64: 422704753
7 circbuf_ten64: 432704757
8 circbuf_ten64: 452704766
9 circbuf_ten64: 342704719
10 circbuf_ten64: 352704723
11 circbuf_ten64: 22704580
# one second later
measurements using 64-bit counter:
64-bit Counter: 452704766
Frequency: 10000004 Hz
10s Avg: 11000004.7 Hz <= JUMP TO 11000004.7 Hz, add 100khz more or less
100s Avg: 0.00 Hz
1,000s Avg: 0.000 Hz
10,000s Avg: 0.0000 Hz
avgupsec: 46 <= here on 46sec, before it was a 99/100sec, seems it's not related to time
1 item circbuf_ten64: 11
0 circbuf_ten64: 362704727
1 circbuf_ten64: 372704732
2 circbuf_ten64: 382704736
3 circbuf_ten64: 392704740
4 circbuf_ten64: 402704745
5 circbuf_ten64: 412704749
6 circbuf_ten64: 422704753
7 circbuf_ten64: 432704757
8 circbuf_ten64: 452704766
9 circbuf_ten64: 462704770
10 circbuf_ten64: 352704723
11 circbuf_ten64: 22704580
The time has changed in which anomaly has appeared.
probably the problem is in the value : 11 circbuf_ten64: 22704580 ??
perhaps the value had to be more similar to a 342704725 ?
to follow under debug with some other active entry:
# another example with more debug with run time of 10266sec
measurements using 64-bit counter:
64-bit Counter: 102632754455
Frequency: 10000006 Hz
10s Avg: 10000006.1 Hz
100s Avg: 10200006.30 Hz
1,000s Avg: 10180006.442 Hz
10,000s Avg: 10189004.9564 Hz
avgupsec: 10266
lsfcount: 3858506654
previousfcount: 3848506647
fcount64: 102642754462
prevfcount64: 102632754455
1 item circbuf_ten64: 11
0 circbuf_ten64: 102582754424
1 circbuf_ten64: 102592754431
2 circbuf_ten64: 102602754437
3 circbuf_ten64: 102612754443
4 circbuf_ten64: 102622754449
5 circbuf_ten64: 102632754455
6 circbuf_ten64: 102642754462
7 circbuf_ten64: 102542754400
8 circbuf_ten64: 102552754406
9 circbuf_ten64: 102562754412
10 circbuf_ten64: 102572754418
11 circbuf_ten64: 102012754073
In this case the counters exceed 10 billion for which I believe that it is correctly printing the software.
If you don't think it is incorrect, how do you advise me to print for a more comprehensive proof?
what about " Your Own Hex Routine" ?
tnx A.