What type of Pi are you running and does it have anything else running on it?
Raspberry Pi 3b+ this is the only thing running
1 Like
Plenty of horse power there - thatâs not it.
Iâd try changing out the power supply.
I have looked at that as well, right now the system is not reporting any power related issues.
Suspect youâd pick up one or two!
@abcd567 I donât want to hijack a flight tracking forum (yeah, bad pun) with stuff about vessels, so Iâll make a few comments and forever hold my peace on the subject.
Youâll want to play around with all the available options in AIS-catcher relevant to your device to determine your best setup. Using the maximum supported sample rate which does not cause the dongle to drop samples is best (2304K in my case).
Nothing new here, but using a basic antenna indoors opens one up to noise from various sources. Operating my laptop near-ish the antenna impacted collection greatly, for example.
Other interference. I can have a number of abrupt and drastic swings in vessels tracked during the day. I traced that to a land mobile radio system which blasts away occasionally at 161.44 MHz. Not much my simple setup can do to cope with that though I am trying different gain settings along with narrowing the tuner bandwidth to see if that lessens the drops.
Best of luck in your efforts!
You are right.
To keep this thread on-topic, I have deleted my AIS posts from here, and re-posted in following existing AIS thread:
Does anyone monitor AIS (Ship and Vessel Tracking?)
Hi everyone,
Quick update. I did get my Flightaware Pro Stick Plus and 1090 MHz antenna. Got it all set up and I have the same exact issue; bad_sync_timeout: 851
Again, there is no power supply issue and I get the same results running the software on bare metal.
Any other ideas or suggestions?
Are you sure you have the GPS coordinates right?
(In particular, confusing degrees-minutes-seconds with decimal degrees will produce a location thatâs âwrong enoughâ to cause sync problems)
- I am running Raspbian OS Bullseye.
- GPS coordinates are formatted as
32.XXXXXXX,-89.XXXXXXX - There is only 1 USB device plugged in, that being the Flightaware SDR.
When you say it is stepping, what exactly do you mean? Hardware issue with the internal Pi USB Hub?
So if the step duration is the same for multiple peers it means that you lost samples from the SDR either at the SDR or somewhere on USB going to the decoder.
If the coords were wrong or something like that, the stepping pattern would be different.
Just chuck in an sd-card image, either piaware or adsbexchange.
Not super likely that itâs the issue but itâs not impossible either.
2 Likes
So, I have the piaware image running on a spare SD card and MLAT is in sync and working as expected. All the parameters are the same. I could understand docker being the issue but what I donât understand is why this wouldnât work when readsb was installed bare metal?
Additional thoughts? This is the first time I have EVER had MLAT data reportingâŚ
Different kernel version? The pi kernels have had a multitude of USB issues over time (at least one version we had to outright blacklist in the sdcard image)
With 10 ADS-B stations already around in our house,
Now that is interesting, are these configured differently for experimental purposes or different hardware?
I had two on one occasion but at different locations.
Geoff
They have different hardware setups in order to compare performance.
I have to work with the limitations that the building where I live in throws at me in order to get a 360 degrees view 
Happy to report that I have figured out my MLAT issue. I am in sync with 78 receivers for Flightaware and 10 receivers for ADSBExchange. I had 10 containers running in Docker on the Pi which could have been my problem, even though the top command was only showing 20% CPU usage and low RAM usage.
Once I saw that the Flightaware image worked without issue I started up readsb, piaware, and adsbx without any other containers running. Initially, the timeout started to spike but would eventally settle down. Each container I added slowly bumped up the timeout value. I would top out around 78. Then I added the autoheal container and it completely killed it, my timeout on the ADSBX UI was 900 and in the logs, I was over 1000 for the timeout value.
So, what I have done is on the Pi I only have readsb running and I am taking the data from that container and processing/feeding it to all the other containers on my Ubuntu Server that has access to an i7 and 16 GB of RAM. Even with that, when I run docker compose up -d and start everything at once I have MLAT issues for a short time until everything is done starting up.
Hopefully this will help someone in the future 
Now to get this setup on the roofâŚ
1 Like
I wouldnât exclude the possibility of a broken sd-card.
Or it might just be the internal power delivery of the pi has some sort of issue.
As in broken on the board level.
Some of the containers write to disk and if there is issues with that ⌠could be a problem.
You can run graphs1090 to monitor the pi long term:
https://github.com/wiedehopf/graphs1090#graphs1090
I have to work with the limitations that the building where I live in throws at me in order to get a 360 degrees view
Assume then that all antennas (or is it antennae?) are indoor devices.
Geoff
2 are outdoor ( on the 3rd floor of a 9 story building) and the other are indoor indeed.