We’re using a FlightAware ProStick with a Raspberry Pi 4 to track gliders at our club. It’s running software provided by OGN (Open GliderNetwork).
After being powered on, the system works and glider data is sent to OGN for 30-60 mins. I’ve been tracking it and the OGN receiver software is helpfully reporting some kind of “frequency offset” in the signals. That “frequency offset” is steadily increasing, and when that offset exceeds 20 kHz we stop getting glider data.
Interestingly, the “frequency offset” jumps at specific times. It’s not gradual. Today we ran a test and:
From 12:36pm, it was around -11 to -9 kHz.
From 12:48pm, it was around 0 to 2 kHz.
From 12:50pm, it was around 8 to 11 kHz.
By 1:07pm, it was just a little less than 20kHz.
From 1:07 until 1:24pm there was no data so we rebooted it.
From 1:24pm, we got data again and it was -11 kHz again.
From 1:29pm, it was back around 0 kHz.
From 1:35pm, it was around 8 to 11 kHz.
By 1:57pm, it was just a little less than 20kHz.From 1:57pm until 2:36pm there was no data.
etc.
Is this indicative of a fault in the FlightAware ProStick? Should we just be buying a new one? Is it something to do with the lack of TCXO?
The prosticks do have a TCXO, and a 20kHz drift on a presumably ~800MHz signal is around 25ppm which is a lot more than the TCXO should see (for that matter, it’s more change than I’d expect from an uncompensated crystal, unless you’ve seeing large temperature changes). It’s suspicious that it immediately fixes itself if you reboot - if it’s temperature-related, I would not expect the crystal to cool down so fast that it reverses half an hour of heating.
I would suggest measuring drift via some other mechanism (e.g. maybe use kalibrate, or tune your spectrum-analyzer-of-choice to a narrowband signal and see if the signal’s frequency drifts over time) to see whether it’s really a hardware problem, or a software problem.
(note that dropped USB data can look something like a frequency shift, so it could possibly be that)
For what it’s worth, this ProStick has spent at least one winter outside in Alberta, so it has been subjected to -40c. The weather nowadays is mild, but maybe it’s internally damaged. If so, that’s obviously on us. I’m hoping this is just user/config error though.
Your mention of ppm made me look at my OGN logs again, and I see some RF diagnostic reports that mention ppm every 5 minutes. This data may be easier to look at because it’s not dependent on having aircraft in the air.
Each report is a line like RF:-2+0.0ppm/+18.7dB. The -2 is a correction value which we calculated using a tool called gsm_scan. The ppm is what I’m focusing on because it increases up to around 48.3ppm if we leave the system running for hours. The point in the logs where the ppm exceeds roughly 35 seems to correlate with when we lose our glider signals.
Below is a log of those ppm values, with timestamps in local timezone, on a ~20c day. Each time it resets to 0 is because someone power-cycled the system.
Would this maybe be indicative of a hardware fault in the ProStick, or USB packet loss as you mentioned? Or should I maybe just re-configure the system by putting a correction of “-48” instead of “-2”?
-2 ppm is more like what I’d expect from the TCXO (they’re factory-calibrated to close to 0).
The OGN code is a bit opaque, but it appears to be periodically monitoring for GSM as a frequency reference (much as gsm_scan presumably does) and adjusting the PPM correction based on that. I’d guess that something is going wrong with this process and it’s getting pulled off-frequency by something that’s not actually GSM, until eventually it’s so far off frequency that it can no longer hear the actual signal you want to hear.
Maybe there is some way to disable the live GSM-scanning behaviour? (I didn’t spend enough time in the code to track down if there was a config option for that)
I’m hoping this is just user/config error though.