I’ve been “studying” the data from the Flight Feeder and talking to the Planeplotter’s staff about this subject. They said that the data provided from Flight Feeders are rounded to the nearest milisecond. One milisecond on speed of light is equal to 300km - not enough to get precise MLAT fixes.
Then, the timestamps from the FF has to be much more precise to work on Planeplotter MLATting. Planeplotter needs timestamps from 50 to 500 nanoseconds.
The question is: Is that possible to get more precise timestamps from FlightFeeder to use its data for MLATs?
It’s about the precision of timestamps sent by the Flight Feeder. All messagens are rounded to the nearest milisecond (0,001 second), but for MLAT fixes, the time spacing between messages should be between 50 and 500 NANOseconds (0,000000050 to 0,000000500 seconds, if I counted the zeroes correctly lol).
Precision and accuracy are two different things. Seems to me like both are issues that need to be resolved. If my Pi was off by a millisecond, it would really screw up the location. But first we need the accuracy to measure more than that.
I really did mean precision, not accuracy. MLAT works based on the difference in arrival times at different receivers. You don’t need a globally synchronised clock, just one that is at a known frequency (+ a reference message to provide a temporary baseline). And it’s usually the sample clock that is used for that, not the system clock anyway.
To go back to the OP, what you want is Beast format output which includes a 12MHz sample clock, or the equivalent one of the AVR formats. I don’t know enough about the Flghtfeeder hardware to tell you how to get that though.
To go back to the OP, what you want is Beast format output which includes a 12MHz sample clock, or the equivalent one of the AVR formats. I don’t know enough about the Flghtfeeder hardware to tell you how to get that though.
As far as I know, it’s possible to get the beast data format through dump1090. Why is not possible to get this data on the FlightFeeder?
Is there some technical reason? Or (I try not to believe on this) is there an another obscure reason not sending this worthy data to Planeplotter Network?
That’s the question! Sorry for asking this, but I think that it should be clarified.
Hi. We’re not trying to obscure anything. There are two generations of FlightFeeders. Older ones based on the Beast have a high precision counter and newer non-Beast ones have a less analog radio board and they have the capability, but we haven’t yet made use of it.
I don’t remember the exact issue with getting the high precision timer into the messages. As I recall we are running the Beast in the recommended configuration with the timer included, binary data, full 3 Mbit/sec bandwidth, etc. Although dump1090 has support for Beast format, there was some problem with propagating the counter, and I think our reader program is discarding it.
We think ADS-B data over time will become a commodity and if you accept that then it’s easy to draw negative inferences for the long term value and profitability of the networks. Consequently we endeavor to play fair and be good citizens and be open and compatible, treat people who choose to participate as partners and, particularly with piaware, play well with whatever else you’re running on the board and not get in the way of your experiments and whatnot.
Don’t get me wrong though in singling out piaware, we will continue to track dump1090 improvements in addition to making our own (and open sourcing them) and we will investigate getting the high-precision counter emitting through the dump1090 beast output port and if it’s not super difficult go ahead and add that and push the software out to the flightfeeder network.
We really are about communicating and sharing information and making it easier, first and foremost, so where it looks like we might have done something bad or sneaky, truly it is far more likely to be due to a screwup, a mistake, lack of understanding, a lack of resources, or just a technical decision that you might disagree with or in hindsight might not have turned out to be the best.
MLAT is something that we are behind on and we are working toward. Even with the elaborate things the network time protocol daemon does to set your system’s time accurately, it’s not very accurate when you start trying to use it to measure those time intervals with the precision needed, and jitter in the processor’s interrupt handling and whatnot, adds to the inaccuracy. Also the location of the site needs to be known as accurately as possible and you need to have a lot of overlapping stations with good relative geometry to the aircraft and and and and and. Lot’s to do… -karl
Very nice. All clear. I’ve made a question about a thing discussed between some colleagues who also have the Flight Feeder and you have answered it on a very good way.
Language is a problem, I’m not a English native speaker (sorry for that), then sometimes it can cause some little misunderstandings.
I’m not disagreeing with your decisions, I’m just trying to understand why it’s not possible to get raw data for Planeplotter MLATting. Before your answer, I felt that there was some “obscure” things behind this issue, but now it’s all clear. Really.
