If anyone wants to compare their results with mine, but doesn't want to make changes to source and compile, I'm attaching a binary. This differs in one way from the results that I posted in previous 2 posts. This binary will not increment the frequency by 1 Hz if the wait_for_lock function fails to lock. If there is no lock, it will just print the frequency that did not lock in the USB serial console and continue to retry. Note that you would need to handle this in your external software application if there is actually some lock errors during the sweep. This firmware image has the retry=99 in the wait_for_lock function. I can also post an image for retry=6 (or whatever) if anyone wants to compare results for that. Aside from the changes I posted above, this firmware image is based on the latest source from here:
https://github.com/ttrftech/NanoVNA , from edy555 commit 30d33571fa3929ff697bf410d3b7f25145cc6e45
[edit]
If you do try this out, it would probably be a good idea to do a re-cal just in case this might improve calibration coefficients for a few frequencies that were off from the previous cal due to unlock.
[edit]
I tested after putting it in the freezer for 10 minutes and the oven, low temp, for 10 minutes (measured 105F when I pulled it out). No pll lock errors reported with retry=99 in lock function for either temperature extreme. I did see 3-4 glitches in the display for the first 30 seconds or so after the cold temperatures. Not sure what that would be.
I would say this is something that probably should be added to the code base. Based on experience with frequency synthesizers, I have found that you *must* check for lock and have some sort of retry mechanism. It might only affect one unit out of a batch. It might only happen in temperatures extremes, but sooner or later you will find unlock happening in certain circumstances. It needs to be handled by checking lock status, retries, etc.