Anomaly report for PiAware feeder with a MAC address of b8:27:eb:xx:xx:xx:
This feeder is not being used for multilateration because its timing information appears to be unreliable. This can be caused by the site location being incorrect, or because your Pi is running out of free CPU.
Today I have the “Anomalies” header on the statistics page for both of my PiAware receivers. One of the RaspPi Piawares is less than a day old.
I have no idea why this has happened and yet I can see that the MLAT reports show that the two systems are not being used.
If you have free CPU and the location is correct, then no, there’s no fix for this; it is a hardware limitation.
FA will use your data when it looks OK, and discard it when it looks unreliable.
piaware monitors the CPU use itself, if you’re not seeing high-CPU warnings too it is fine.
The hardware limitation is just that, a hardware limitation. The DVB-T dongles are cheap and not all that great and sometimes they drop samples which causes problems with mlat timing. It is unpredictable when this happens - it seems to be related to the individual dongle you have, the ambient temperature, the individual Pi it is connected to, how long a USB cable you have, phase of the moon, etc. Changing any of those variables might help (or might not)
I am just curious as to why this has happened. The #1 system has been operating without this anomaly and then when I add #2, they both start have the same anomaly warning.
As #1 has been working as it the current configuration, I am just trying to understand why it has come about so that I can have an excuse to learn more and tinker more.
Surely it wouldn’t be because FlightAware has two systems colocated. There are others with multiple systems and I assume they are located near each other.
While fiddling with settings today I changed the error correction, PPM, in dump1090-mutability from 63 to 0. After a restart I received the same anomaly message as you. This happens occasionally after a restart but clears up in a few minutes. Not so this time. The anomaly persisted until I changed back to my original PPM value thirty minutes later.
It has been stated that the PPM value does not have much meaning at 1090 mHz but it his case it seems to have. Now this may be a red herring. Regardless you may have a marginally working radio, possibly power related, possibly heat related, etc.
If it were me, the radio would be the first thing swapped out in pursuit of a solution.
My current hypothesis is that the problem lies in the timing used for USB signalling when the dongle talks to the host. If it is near the edge of the USB specs under ideal conditions, then if you happen to have a crystal that’s quite far off spec or a noisy USB connection or a Pi that happens to be less tolerant of USB timing problems, then that might be enough that you start occasionally dropping data. Hard to be sure without throwing a logic analyzer at the USB bus, though.
The dongles use the same crystal oscillator to do both the RF stage tuning/sampling and the USB signalling, and IIRC adjusting the PPM offset actually tweaks the oscillator directly (you can wedge the dongle’s USB interface entirely until a power cycle by moving the PPM adjustment too far), so it’s quite possible that changing the PPM offset is enough to break or unbreak the mlat timing problem too.
Most dongles have an uncompensated crystal so they will naturally change frequency as ambient temperature changes, too, and that might also be enough.
I would be interested to know if anyone with a dongle that has a TCXO still sees the problem.
I have “stock” PiAware setups. I ordered the pieces per the FightAware site. I am also running the stock software. I wish I could run the other versions, what with all of the interesting displays I see posted, but at this point in time it is beyond my abilities. I am open to trying out other hardware, but assumed that the relatively easy install of a stock configuration was about all I could do. In fact I wasn’t aware of all of the possibilities until after starting up my system and then discovering this forum, which is extremely helpful and a terrific resource.
The build that I just assembled and started up last evening has the small Nooelec dongle: NooElec NESDR Nano 2+ Tiny RTL-SDR USB Set w/ 0.5PPM TCXO, R820T2 Tuner, Antenna and Remote Control It has had the MLAT anomaly warning since startup.
I also meant to mention that my RasbPi is located next to antenna with only the pigtail from the antenna to the RasbPi.
I picked up one of the Nooelec 2+ TCXO dongles a few weeks ago on a whim just to see how it performed. My original Nooelec 2 did exhibit the MLAT anomaly infrequently at random intervals. Since installing the TCXO stick, I haven’t seen the anomaly at all. The new dongle has been in service for a couple of weeks now. As obj pointed out, there are countless variables that may cause the problem, and shotgunning the entire dongle isn’t exactly a laboratory grade test. I probably just got lucky with the new stick.
My original intention with the TCXO dongle was to see if it improved performance in my setup during temperature extremes. I have the entire setup housed in an IP66 box up on the roof. Here in Nebraska this time of year, I have seen the temp in the box drop as low as +5 F (I have a temp probe in there). After a couple of weeks of observation…I have seen almost no difference in performance between the two dongles, other than the MLAT anomaly described above. Interestingly, my max range is very slightly decreased with the TCXO dongle. Probably not an unusual occurrence in these cheap radios. A microscopic manufacturing difference in the RF front end could make all the difference from dongle to dongle.
I only ever see that message now when trying to use a USB cable, when the dongle is plugged directly into the pi there are no problems.
But maybe its just my rubbish cables
I agree, they do seem random. I was concerned that one setup was brand new and it had the warning and then I noticed my other one had same warning. I am starting to think they are co-located so they are affected in the same manner by the FA system.
