Ah, yes, I do definitely tune the initial layout, and then verify across a large production pilot batch. I burn the default good value into the code, and then if the chip supports a configuration header value that sets the crystal tuning for each board, I leave it unprogrammed. The crystal startup code will check the header and use my default value if no configuration header value is present.
Then, I can implement a future cost reduction if worthwhile by only setting the header tuning value in production, without having to issue a firmware release. Or if I start seeing issues in production… the lazy engineer always plans for an easy fix to potential problems.
For verifying the crystal/layout/etc., a frequency counter works, as does a spectrum analyzer, as long as their oscillators are in spec. You can get the crystal ppm from the frequency error, e.g. for BLE a 150KHz error at 2.45GHz is 150000/2450000000 = 61ppm. There may be sources of error other than the crystal, like PLL jitter, but that is beyond my knowledge and I will defer to others more knowledgeable here in the forum.
Yes. The Datasheets recommend it. If you put it out in the sun you’ll get errors. nail polish lacquer seems to work fine though. This is mainly an issue in the photo phase, obviously
For the Lora radio and most other SRDs of the last 15 years, there’s a calibration routine in the PLL startup that trims the oscillator. Certainly post-2012 when the SPIRIT1 shipped, these routines are quite fast, or the order of 60 us or less.
The issue is that heat generated during a long, moderate power transmission (Lora IC is good for 22dBm) will heat the PCB during the transmission and cause a drift. TCXO compensates for this.
