I have a few technical questions re GPS time for a first time install. 1. From what I have read, for MLAT you need an accurate time in the microsecond range. I assume therefore that a timestamp is added to the information packet before it leaves the Pi to discount any propagation latency which would result in a server side timestamp. Is that correct? 2. I also assume that the servers correlating MLAT data have been programmed to discount any packets that a Pi might send that are off by X amount of microseconds from other packets (no foul, not harm). A case in point would be reboots, where the Pi might send packets before the time is correctly set. Is that correct? 3. I am considering connecting the Pi to the LAN via WiFi which would certainly degrade any timestamp accuracy even using chronyd on the Pi. Assuming that my first assumption is correct, a solution would be to have the ADS-B Pi also function as a time server. I currently have a GPS time server on my network with PPS accuracy based on a Pi with a Blox Neo 6M board from China that you can buy on ebay for less than US $4. A search of this forum using a variety of search terms (100s of posts or none) seems to indicate that this has not been done in the past with an ADS-B Pi. Have I not used the correct search terms, or this really a simple a case of no one trying it before? Is there any technical reason why it cannot be done that I am not aware of?
1. Fuzzy math on the server 2. Fuzzy maths to account for this. 3. Not supported out of the box and typical install for most people don't have clear view of sky for GPS. With all the spoofing going on around the world, just use network time - it's close enough for government work.
Wow. I was not expecting that response. After reading some of the posts In regards to GPS time, I live in rural area with a pretty good view of the sky and I cannot imagine anyone trying to spoof a GPS signal around here. At least my dedicated Pi time server doesn't have a problem and chronyd uses checks several time sources to before picking the best one to be sure they are in agreement. In a
My apologies for my last post. That was one I started and didn't finish because I thought better of it and did over after doing some more reading - changing the content and tone.. Unfortunately when I tried to send the redo, my unfinished first one went out instead. If I am still being moderated, please feel free to delete it and I will redo the one I intended to send that disappeared. If that is not possible, I will hang my head in shame and simply go quietly away.
No worries. I'm not easily offended! I'm usually the one offending people with direct blunt answers. Timing is important but for 99% of use cases NTP et all is perfectly fine.
The actual MLAT doensn't happen via the system time anyway, that's not accurate enough. For GPS MLAT, the GPS needs to be integrated into the 1090 MHz receiver (radarcape and similar). The MLAT on the RPi uses ADS-B aircraft to establish a synchronization between different receiver crystal frequencies. (receiver as in rtl-sdr dongle)
Here in the UK we have daylight saving where we move so that the clocks go forward in March to BST (+1 hour) and back to GMT/GMT on October 27th at 02.00 And my computer (Raspi 3b) makes the correction as well, I assume Am I right assuming that ADSB is UTC Epoch data; but what is MLAT data; I covert it to Epoch data to make it comparable with ADSB data but it looks like it's 1 hour behind (odd) until October 27th and then its in line with the ADSB data. I think my brain has shutdown..............
