No problem, was curious myself.
It seem to have cleared up, now it’s synchronized as it should be:
So 24 MHz with -p doesn’t seem to break MLAT.
edit: Logs confirm it’s working.
[2021-09-19 22:42 CEST] mlat-client(18178): Server status: synchronized with 51 nearby receivers
[2021-09-19 22:42 CEST] mlat-client(18178): Aircraft: 4 of 4 Mode S, 5 of 5 ADS-B used
[2021-09-19 22:42 CEST] mlat-client(18178): Receiver: 117.2 msg/s received 36.8 msg/s processed (31%)
So, you have the problem even without the lowercase -p
Edit: answered with bive at the same time
So, actually, at 24 MSPS the -p is switched on automatically otherwise USB 2 can’t handle the traffic
I can start with 20 and -p but after a short time MLAT kicks me off.
Airspy is in USB3 connector and there is a connected GPS receiver on USB2 port for getting more precise system time.
That’s probably the cause of the problem. I’m using external RTC-clocks on my Pi:s that require precise time if the internet connection is down. Connects via GPIO-pins.
DS3231 or similar with a button battery?
My solution does not use NTP servers at all.
GPSD and chrony work on keeping the time as exact as possible. Jitter is plus minus 0.1 usec now. Not perfect but better than on any PC with NTP servers on the net.
Exactly. Easy to configure and works well.
I have some other as well, but the DS3231 is probably the best option besides GPS.
That is of course the best option (next to having your own atomic clock on the LAN). Perhaps you can move the GPS to another Pi/computer if running 20 MHz is beneficial. Don’t know how much difference there will be for you.
Yeah, I can move the gps to another computer when must, but I would lose what I have already achieved. 
Delay and jitter of lan would make it as precise as it was originally with NTP out there.
Right now, 20 MHz sample rate is just a wish - reading the news about the good results with the actual filters.
So “only” the added benefit of having a working time system if your internet connection goes down. Seem like a damned-if-you-do, damned-if-you-don’t kind of situation for you
I’m happy if I keep all my systems within the same second. MLAT does work even when the system time is more off than that (blocked port 123 for both out- and incoming traffic by mistake, found out a week or so later when the clock on one Pi without RTC was “a bit off” 
)
LOL
I know the feeling of being busy with such a minor thing. I made the changes for MLAT purposes, you’ve hit the nail on the head.
The bad joke of the circumstances is: I might have 20 MHz sample rate without GPS and MLAT. Or, I have MLAT but staying with the good old 12 MSPS is “mandatory”.
I think, I stay with 12 for a while. I am waiting for Pi5
There is no benefit of having GPS time for MLAT … (unless it’s builtin into the receiver which requires different hardware).
I’m not sure if there is any benefit of having a GPS adjusting the system time when it comes to MLAT. See this post: MLAT and Piaware - #21 by obj
The last sentence is interesting…
But I’m no expert on this and have not read the code for how they calculate MLAT positions and how they time stamp the messages.
So am I, but who knows when that will happen…
Partially, GPS system time was an experimental project for me.
I’ve talked with a PF staff member about MLAT. They exclude all the usually accepted MLAT solutions but the special hardvers. Their own solution is within 50 nanosec. I wanted to know how close can I go with simple methods. 0.1 microsec is still not good enough…
I actually agree with them (PF) Looking at the MLAT trails on the map is enough. I wanted to contribute to improving this with my experiment, even if I find that change in the system is not measurable. Enough if I know.
As I have read obj’s post, I have to rethink these things. I’ll restore the original NTP based time settings on my pi. Perhaps I put the coordinates in manually…
Same fault again
Sep 19 20:51:10 Flightp1 airspy_adsb[22969]: No data from device for 15 seconds, attempting to restart decoder!
Sep 19 20:51:10 Flightp1 airspy_adsb[22969]: Apparently the data processing didn’t finish, report this please.
Sep 19 20:51:45 Flightp1 airspy_adsb[22969]: FATAL: watchdog timed out, aborting process!
Sep 19 20:51:45 Flightp1 systemd[1]: airspy_adsb.service: Main process exited, code=killed, status=6/ABRT
Sep 19 20:51:45 Flightp1 systemd[1]: airspy_adsb.service: Failed with result ‘signal’.
Sep 19 20:52:00 Flightp1 systemd[1]: airspy_adsb.service: Service RestartSec=15s expired, scheduling restart.
Sep 19 20:52:00 Flightp1 systemd[1]: airspy_adsb.service: Scheduled restart job, restart counter is at 2.
Sep 19 20:52:00 Flightp1 systemd[1]: Stopped Airspy ADS-B receiver.
Sep 19 20:52:00 Flightp1 systemd[1]: Started Airspy ADS-B receiver.
Sep 19 20:52:00 Flightp1 airspy_adsb[18249]: airspy_adsb v2.2-RC17
Sep 19 20:52:00 Flightp1 airspy_adsb[18249]: Listening for beast clients on port 47787
Sep 19 20:52:00 Flightp1 airspy_adsb[18249]: Acquired Airspy device with serial B58069DC393F4513
Sep 19 20:52:00 Flightp1 airspy_adsb[18249]: Decoding started at 24 MSPS (Gain: auto; CPU target: 85 %)
Sep 19 20:52:01 Flightp1 airspy_adsb[18249]: Push client connected to 127.0.0.1:30004 (beast)
You are limited by two things. Firstly, the beast format has a time resolution of 12MHz, which means even if your clock is extremely accurate, your precision is inherently limited to 83.33ns. Secondly, they are using hardware to timestamp the frames before they leave the receiver. That is not possible with rtl dongles and airspy since they transfer the digitised RF and decode in software, so there is going to be significant jitter depending on system load and USB transfer timing.
If you want that sort of precision you pretty much have to decode the frames before they travel across USB, so that means an FPGA based receiver, and then you have to use a data format that has sufficient resolution to carry the timing information.
First, I thought that I can build a system where these delays can not be eliminated but in case of a relative constans deviation, timestamping might be cheated with the tipical value of delay.
Of course, it was more and more difficult to handle the possible accumulated errors even in theories.
I stopped working on this soon.
It’s possible with the Airspy by locking the device to an external clock and using the sample timing as a time stamp. There are many direction finding applications based on this setup already. Of course, this assumes no samples are lost in the device itself.
Hmmm…
My sleepy head starts waking up. Hope for the future?
Is the same clock locking used for external frequency stabilization over the built-in stabilized local oscillator?
I used to check receiver stability by tuning to an ILS frequency, and I checked the position of signal for a longer period.
An average receiver starts drifting if you open the window of the room.
I have seen videos about stopping this small drifting by locking to an external clock. This kind of external clocks are usually not in the cheapest category.
Yeah, let’s get you a new build that shows more info for this.
Happening too often to just ignore i suppose.
2.2-RC18
- CPU target should be a bit better about not losing samples -C 90 and
greater
- Better debugging for "no data" restarts
Just update as usual, in case it happens again we’ll have something to go on.
It’s a really minor update but i wanted to keep the versioning clear.
So just skip it if you’re not keen on running the update script