Open sniporbob opened 3 years ago
Buelligan1203
commented
1 year ago Has this been addressed at all? I also have an issue with the output to takserver updating very slowly. There are often new aircraft that are not uploaded to tak, and old aircraft that have not cycled off of tak.
ritouille
commented
7 months ago Hi everyone, Seems i have the same issue on my side. I use a RaspPi with ADSBxchange installed on it. I have interfaced my Pi with my ATAK Server by reading the aircraft.json file : FEED_URL = file:///run/readsb/aircraft.json TCP+RAW and other methods are not working on my side.
The problem is after 2-3 minutes, I notice some delays between the aircraft seen on the dump1090 webpage and the aircrafts on ATAK. After a while, there is approx 45min to 1 hour delay between the two systems. With other words, on dump1090 i can see the real-time traffic but on ATAK i can see the traffic that past 1 hour before. For example, if I disconnect the antenna from the SDR dongle, I continue to see aircraft poping on ATAK during 1 hour.
Do you have an idea what is happening?
Thank for your help :)
The speed at which ADSB data is sent to FTS is slow. Running dump1090-fa and looking at the local web interface, it shows that multiple updates are received each second for every visible aircraft. Despite having sub 1 second position updates for all aircraft, aircraft position information is uploaded/updated on the server at a rate of one aircraft every 2-5 seconds using the http json method. Using tcp+beast results in an upload/update rate of one aircraft every 5-15 seconds and typically the application hangs after 4-6 aircraft are uploaded. Using tcp+raw results in a hang after the first aircraft is uploaded. The script doesn't generate any errors when it hangs.
The slow update speed does not appear to be a server resource limitation. While I have been testing on a Pi4, this same issue is (was?) occurring on the public server which I believe is more powerful than a Pi. In further support of this, it is possible to simultaneously run adsbcot and aprscot on the same pi without any negative impact on the rate of position updates, despite the server being subjected to twice the load. Conversely, stopping aprscot will not improve the refresh rate of adsbcot. Sending multiple cots and map objects using an EUD will also not have any negative impact on the rate of updates coming from adsbcot.
A significant problem will arise from this slow update rate in the form of a queue developing. It would seem that when a poll is performed, a snapshot in time is taken of all currently received aircraft. This list of aircraft is then sent slowly, one by one, to the server at a rate of one aircraft every 2-5 seconds. If another poll is performed before this list is finished being sent, the new snapshot is simply added to the end of the current list. As time goes on the list grows, and the positions of the aircraft begin to lag behind their real world locations. The result is the appearance of aircraft traveling in slow motion. Attempting to reduce the polling interval in order to update the aircraft positions more frequently will worsen the issue as it adds more snapshots to the queue. The workaround for this is to estimate the largest number of aircraft that might be simultaneously received, and plan for a large enough polling interval that the full queue will be cleared before the next poll. In high traffic areas this will necessitate very slow updates, and at times when the skies are relatively clear there will be large needless delays in position updates.