When I use dump1090 to receive ADS-B signal, we find it has about 60 ms delay when read signal, even we modify the code to one thread(read_sync), It still has this delay, whether there are anyone meet the same problem or how to fix it to make it has more read frequent reduce this delay?
You won’t get real time, there needs to be some processing and also USB transfer.
All of this includes buffers.
If you really get into the source you might be able to make the buffers smaller though.
(You can’t control buffers within the rtl-sdr compatible receiver though)
Also there is a network buffer you should make sure isn’t set in the configuration:
--net-ro-size <size> TCP output minimum size (default: 0)
--net-ro-interval <rate> TCP output memory flush rate in seconds (default: 0)
May i suggest a Radarcape or similar receiver which can embed GPS timestamps in the messages?
If you really want real time then the timestamps need to be embedded with the ADC and you only get that with a hardware solution.
In case you are trying to do MLAT without absolute clocks, take a look at this code: GitHub - mutability/mlat-client: Mode S multilateration client
2 Likes
It’s very helpful, thx.
~60ms sounds like it might be a 256kB buffer @ 2.4Msps (around 54.6ms). librtlsdr (and, under the covers, libusb / the kernel’s USB routines) collects a full buffer of samples before returning them. The underlying USB transactions on the USB bus itself are pretty small (128 bytes?) but it is a bulk endpoint, not one of the other types that provide bounded latency.
What are you trying to do that requires such low latencies, though?
1 Like