I did receive a reply from one Lora module manufacturer who claims they use 10ppm xtal crystals, and they said that "They seem to work reliably down to BW=20.8". Anyone know what the specs are on the crystals that Hoperf uses?
There's some inferential evidence that the xtal in the RFM69 is 10ppm (
https://lowpowerlab.com/forum/index.php/topic,1434.msg9957.html#msg9957), so maybe HopeRF uses the same crystal in its RFM95. Admittedly, that's purely just a WAG. Wouldn't you be surprised, though, if HopeRF put a worse crystal in the LoRa than it puts into the RFM69?
Here's the rub: using the Semtech Lora calculator, it would appear that the required ppm is a function not of the spreading factor but rather of bandwidth. According to the calculator, at a bandwidth of 31.25kHz (which is what I tested with a pair of Moteino LoRa's), the max crystal offset is 8.5ppm. In comparison, at a bandwidth of 20.8kHz, the max crystal offset is 5.7ppm, and at a bandwidth of 7.1kHz the max crystal offset is 2.1ppm. So, maybe that explains why 31.25kHz is the narrowest of the RadioHead preconfigured settings.
So, assuming that's true, is there a way to compensate in software if it turns out that the HopeRF module uses 10ppm or even 20ppm crystals? Maybe. Here's an idea, and maybe you all can help me vet it. According to the datasheet, if you're running the Tx at maximum power, you're limited to a 1% duty cycle. So, suppose you run the Tx at low enough power that you can instead run it at 100% duty cycle. [What Tx power would that be? Simply anything that's not the maximum?] The idea is that the module would warm up but eventually reach a steady state where the temperature is constant (let's assume ambient temperature is constant, or else that won't be true and this gets more difficult). Likewise, run the receiver in constant Rx mode, so that it too reaches a steady state temperature (same ambient temperature assumption). Let's assume voltages are held rigidly constant, so that we can ignore that as a possible cause of variances in frequency offset. Let's assume both sender and receiver are stationary, so g-forces are not a factor. With those assumptions, is there anything else that might cause variations in the frequency offset? If not, then the crux of the idea is that the Tx module could programmatically (and purposefully) send packets at a range of frequencies above and below its set frequency with the aim that some of them will closely align with the receiver's Rx band.
If that holds water, then
1. the above method suggests redundant packet transmissions at different frequencies is a shotgun way of getting some packets through, and
2. the receiver could take note of which packets get through the best and adjust its frequency accordingly so as to better align with the Tx frequency.
Through progressive refinement from further iterations, perhaps the receiver could be well tuned to the transmitters frequency, despite using less than ideal crystals. If the above possibly/probably unrealistic assumptions of duty cycle and ambient temperature needed to support method #2 can't be met, then at least there's still the shotgun technique of method #1.
At least on its face, does that idea hold water? Or did I fail to account for something?
