Noting the discussion on birdies, I think we should explore firmware work-arounds for them. I'm seeing mixed messages on whether they are generated from the uP or the si5351. I've also read elsewhere that display multiplexing is a common source of birdies, so it would be interesting to explore whether your display off mode improves things. Some thoughts:
can we put the uP into sleep mode during receive as far as possible and wake it using interrupts on any input change (button, paddle)? This may require the ms interrupt to be reduced or switched off.
if the birdies are si5351 sourced, can we try the new version of the etherkit library and see if that improves anything?
again on the si5351, can we try a different combination of PLL frequency and dividers to see if we can move the birdies. If we can, then maybe an option to swap between two different clock schemes to allow a birdie on the frequency of interest to be moved elsewhere?
Just had a bit of a play with the receive side. I'm seeing two effects:
strong birdies at a few places across the 40m band which seem to be generated from the si5351 (not affected by reset)
low level tones (just above noise) across most of the band - these seem to be uP originated as they disappear on holding the processor in reset. Would only be a problem for very weak signals I think.
The display being off does not seem to affect the noise level, but not sure if you are switching off all the external scanning of the display, so that may still be a source of noise.
Hence definitely worth exploring if we can put the processor to sleep when no interaction is occurring (or at least avoid toggling any external lines)
Noting the discussion on birdies, I think we should explore firmware work-arounds for them. I'm seeing mixed messages on whether they are generated from the uP or the si5351. I've also read elsewhere that display multiplexing is a common source of birdies, so it would be interesting to explore whether your display off mode improves things. Some thoughts: