Is it possible to add a GPS receiver to the system?

Hi,

I have a bluetooth GPS receiver (GlobalSat 821C) in my desktop drawer unused.
In addition to its battery, it can also be powered via USB and its datastream can be connected via Bluetooth.

Is there a way to connect it to my PI 4 B + RSP1A station in order for the station to be MLAT compatible?

Regards,
Janos
 
Last edited:
Hi Janos,

No, this will not make it MLAT compatible with Plane Finder.
Hi,

Thanks for the answer.
Is there a public description of technical requirements for being compatible?
I mean, the already accepted and used equipment has (maybe special) parameters and settings. If you tell me the secret, ...do you have to kill me? :)
 
Hello Janos,

No sorry there is no public requirements. At the moment we support Plane Finder Radar and Radarcape receivers in our MLAT environment.
 
Sorry that I can't say more. We did spend a lot of time trying to get MLAT with "unknown" third party systems working.

Whilst it was working, the level of errors we could see was not acceptable to us so we drew a hard line in the sand on the requirements. You can actually see some of these errors on networks that only use NTP and RTLs.

Third party receivers (like the Radarcape) do get accepted but go through a ton of benchmarking and calibration as they no doubt work slightly differently to our own receivers and so require code tweaks in our client. With the Radarcape there was enough out there to make it worth the time investment.
 
Sorry that I can't say more. We did spend a lot of time trying to get MLAT with "unknown" third party systems working.

Whilst it was working, the level of errors we could see was not acceptable to us so we drew a hard line in the sand on the requirements. You can actually see some of these errors on networks that only use NTP and RTLs.

Third party receivers (like the Radarcape) do get accepted but go through a ton of benchmarking and calibration as they no doubt work slightly differently to our own receivers and so require code tweaks in our client. With the Radarcape there was enough out there to make it worth the time investment.
I know you have a lot of working hours designing the system, so I didn’t want to just guess.
- I thought that if I supplemented my pi4 + RSP1A + (real) cavity filter station with a GPS, and I have some interoperability with the NTPD and GPSD daemons, the solution may not be too far away...

Anyway, thanks for your work :)
 
Last edited:
Yes, we thought it wouldn't be far away when we tried it too! We work to around a 50 nanosecond tolerance and GPSD/NTPD cannot get anywhere near close to that!
 
Now, I have a 0.1 microsec sync error...

Maybe, we do not have to use laboratory class devices but it is enough to know the sync errors for all the cooperating stations to calculate the real position.
Like in "exchange"
1623677691767.png


This is a compromise, not perfect but (I think) a clever solution for having cheaper set of device. ( Not for military use LOL )
 
Last edited:
To finish my line of thoughts:
- Syncing to stratum 2 and 3 servers over Internet is surely not the solution. Even wired network to stratum 2 or 3 can have 1 microsec sync error, depending on the protocol and the load. High and/or variable jitter value is not not ideal. There are timestamps, ok. but there is no garantie for having a periodic error. Instead, sometimes it can be erratic. We can not forget that our computers are not for a single purpose, so its load will be vary. (they are not NTP computers exclusively)
- On the cheaper side, the accuracy of GPS time signals is ±10 nanoseconds so all the other unwanted delays (offset) are locally added.

As long as the typical processing time of the hardware is known and the processor is not loaded close to 100 percent, the accuracy can be maintained quite well. If necessary, you can even run sync with elevated priority, also handling the known mismatch of local clock-frequency.

- Just a line in chrony.conf: "refclock SHM 0 offset -0.00004 delay 0.0 refid NMEA"
(If local clock is fast or slow, we can run "makestep" more often, and shift the already reduced mismatch to be closer to zero in average.)


Compared to the uncertainties of Internet communication where a timestamp cannot fully solve the problem either, a local solution may also be more acceptable. The rest is just a matter of standardization.
- There are also ways to avoid the collapse of time-sensitive applications. A kind of slow sync - without bigger jumps.
- Dependancies of critical processes shall be kept on a virtual drive, in memory - for reducing the latencies.
- Of course, adding also a high precision RTC (realtime clock) to Pi device won't harm either. PTP capable GPS would help a lot.

As for me, combining a good RTC with slow sync is not impossible.

This cheap Pi-compatible 56 channel USB GPS receiver has a 30 ns timing accuracy:
UBX-G7020-KT
 
Last edited:
is there any benefit to having a gps fitted?
From an ADS-B decoding view of point, there in not any. Clock dependencies are handled by the client. For MLAT, a hardware-timestamp would help some before the decoding process. Let's say - when a signal preamble "touches the gate" at USB. Or something similar...
Moreover, using any USB device other than the receiver may cause problems.

e.g. with a high performance airspy receiver and decoder, where USB bandwidth is a key - using another device meanwhile the same controller chip works for all devices - is not too wise.
 
Last edited:
is there any benefit to having a gps fitted?
From an ADS-B decoding view of point, there in not any. Clock dependencies are handled by the client. For MLAT, a hardware-timestamp would help some before the decoding process. Let's say - when a signal preamble "touches the gate" at USB. Or something similar...
Moreover, using any USB device other than the receiver may cause problems.

e.g. with a high performance airspy receiver and decoder, where USB bandwidth is a key - using another device meanwhile the same controller chip works for all devices - is not too wise.
A combined antenna with built-in gps and a specially prepared receiver might have some benefit - but the problem is system-wide. Amateurs use what they can grab. From cheap garbage upto almost pro stations or experimental solutions can be find (well mixed). I understand that at service-level, there must be a standard solution. We can not participate in a workflow - not even with a pro station - since the hardware is not surely a standard one for the data-processor system.
 
Back
Top