So I’ve been experimenting with a few things on the Raspberry Pi (3) hardware side of the PiAware setup and have noticed a few things that I wanted to share. It’s probably likely that my observations are either very elementary or rudimentary due to my experience with radio equipment but hopefully I’m providing good information for others like myself.
Power Supplies - For whatever reason, I assumed that a higher amperage meant more power to the radio dongle for better reception. What I found was that 2.1 amps seems to be the sweet spot for the PiAware setup. A power supply of more than 5v 2.1 amps seems to increase noise on the dongle resulting in more 1 packet aircraft or 3dbi aircraft and adds almost nothing to the overall performance. It’s well with operating range for the Raspberry Pi but doesn’t provide any extra “juice” for anything else. I experimented with 5v 2.1a, 5v 2.4a and 5v 3.0a over the course of a few days with a few devices while monitoring the rrd stats on each.
GPS - This seems to be a critical component for tracking more aircraft. The more precise it is, the better results it seems to generate ( 5%-15% depending on all the other factors ). I found my best results came from the Adafruit GPS breakout board and Raspberry PI GPS Hat. Both use the same GPS chip and it has exceptional resolution ( 2-3 meters/7-10 feet ) and both offer the ability to get GPS PPS signals for better time accuracy. You do have to disable bluetooth on the RPI3s for it to work, but a worthwhile trade off in my opinion. After that, the best and most affordable USB GPS dongle I’ve used is the Vk-162 that Stratux sells on Amazon. It has roughly the same resolution as the Adafruit devices, just doesn’t have an accessible PPS connection ( but it will show up in dmesg ).
NTP + PPS - Time accuracy seems to be as equally import as GPS accuracy ( considering both are used for MLAT calculations, seems logical ). All the devices I enabled GPS PPS on have had higher MLAT results and seems to increase the observed aircraft marginally. The GPS PPS helps keep your clock accurate down to nanosecond and picosecond levels instead of milliseconds. This helps keep the clock on par with the Atomic clocks used for time keeping in most other precision data applications.
Again, I’m sure I’m on revealing any secrets here, but just hope the things I’ve seen and learned can help others like me.
Neither NTP nor GPS are used for mlat (GPS position info is used if available, but you can just set it manually too).
You need a stable power supply, but a higher current rating doesn’t mean more power for the radio - it’s mostly an all-or-nothing thing, either the PSU can supply the required current at 5V or it can’t. A better power supply may reduce RFI.
I think you are mostly seeing either random variation or different RFI from the different setups.
I don’t mean to be difficult here, but I did take time to go educate myself further on MLAT and I keep coming across mentions of GPS PPS helping with MLAT calculations. I’ve even found threads on this forum describing just such a thing:
I understand that GPS locations can be spoofed or set manually, but it would appear that PPS can be valuable to MLAT calculations. Am I missing something here about the method employed for MLAT or something?
Other services do use ntp/pps for MLAT.
flightaware only uses it on devices, like the radarcape, that embed that timing data at the hardware level.
The jitter/latency on the USB bus is too variable to be really accurate.
FA uses timing data that is internal to the USB dongle.
It’s good to have a GPS-disciplined oscillator for frequency stability, and it is very useful to timestamp incoming samples with a GPS time. Receivers like the Radarcape do this.
Unfortunately rtlsdr dongles can’t do either of those and simply adding a GPS module to the Pi does not help you do either - you need to get that frequency stability and timestamping happening directly in the SDR. You could potentially wire in a GPSDO as a clock source for the dongle, but that wouldn’t help with the timestamping part where the real win is.
Multilateration using rtlsdr dongles uses the relative arrival time - as counted by the number of samples from the dongle - of ADS-B messages with a known transmission location versus the arrival time of messages to multilaterate, rather than an absolute timestamp (since you don’t have an absolute timestamp to work with). The system clock isn’t used at all.
(The thread you quoted is actually the one that eventually lead me to develop mlat-client / mlat-server and, later, the FA multilateration solution. This post is still a pretty accurate summary of how it works: post157238.html#p157238)
I really appreciate Flightaware that they could manage to support MLAT on RPi without GPS, with remarkable accuracy.
Quotes from discussions in another forum (Not Flightaware):
*“We have never supported MLAT on the Raspberry Pi I’m afraid. Only our Radio and Radarcape.
MLAT can be done without a GPS but we decided not to do it as it can be very inaccurate.”
“We do use MLAT ourselves but found the accuracy of non GPS systems to be really bad so we don’t use these at all. We had a working system and were not happy with the compromises that we had to make.
This is why we designed our own receiver with a <50ns accuracy (around 15 metres) and this way we get some great MLAT plots!”
“Would you use my data for MLAT calculations if I add Adafruit GPS HAT to my Pi?
No. We tried this in the early days and it was so variable that it had no benefit over the “clock” in the receivers. We timestamp within the FPGA as soon as the signal hits the front end, same place, reliably every signal.” *
