Actually, reading values from an A/D over the I2C bus will take more time
than just reading from the Nano's embedded ADC.? Not a win.
I think we can get by with just a couple ADC reads, use that to compute the SWR.
If too much jitter, just follow Arv's suggestion and make the caps bigger.
If that doesn't work, then average it out over several samples.
Or just show what you got and let the operator do the averaging.
But I think the large cap is all we need here, especially if we have 20us sample times.
And a couple 20us sample times is a drop in the bucket compared to time spent updating the si5351.
And if we are worried about spending too much time on housekeeping, then an i2c display
is not a good idea unless we set up queues and shovel data out to it with an interrupt routine.
That i2c display with blocking IO is orders of magnitude worse than a couple 20us ADC reads.
Jerry, KE7ER
toggle quoted message
Show quoted text
On Sun, May 6, 2018 at 08:30 am, K9HZ wrote:
Slowing down processing by additional code. Yes I'm extremely aware of this problem hence the my posts on timing. An outboard I2C A/D removes a lot of this load because 1) we are already using the I2C library for other functions in the radio, and 2) the update frequency requirements once off the original Arduino are much lower.
