That’s the only reason I keep feeding them.
1 Like
The only thing that looks “fine” is the “MLAT running: YES” It doesn’t mean that is actually working fine on their end.
I have the feeling that some of their devs left and now they have nobody that can really work on their software. This is because they was no development on the beta UAT feeder that I am testing for them, for a long while now. Also I don’t know of any updates on their FR24FEED either.
And that’s a red flag to me.
2 Likes
Fast becoming my line of thinking. You can see by my links how active they were previously. One acct is deleted and you only see the hired people say ‘email us’ or not actually reading whats wrong and returning boilerplate script or links to close it and move on now.
Not at all surprised if it goes ‘Ok’ for anything responding on the port/device it’s told to look for…even if its not in binary tagged format it’s expecting
Though there was a time everyone was reconfiguring after a Version release as the avr/30002 suddenly carked it (I believe)
1 Like
And that’s the kicker
If it’s an app design - you change it
If it’s user configuration design you tell them or automate it
If it’s version indifference and they don’t have the auto upgrade version or disabled it - you plead with them to upgrade - just like plane Potter does
There is a complete multitude of extra information that could have been sent out rather than a jackhammer email. And it wouldn’t have had to sound scary for anyone that doesn’t quite know how to do it - they could ask for the same support contact like they did
Except your audience would be much smaller then the reach it had
Nevermind the ones who haven’t updated their email in 6 years
What i am asking myself after i saw the twitter statement saying “We just wanted to clarify that feeders should not shaare MLAT data from other networks”
How did that happen, how did they identify now after so many years and what trouble is it causing on FR24?
Many of us are sharing data since then on different networks and it obviously never caused any issue as far as i know.
1 Like
Are you sharing MLAT? Because you shouldn’t.
I took that statement as: getting the MLAT provided from FA (example) and sending it back to FR24 to boost your stats.
1 Like
Honestly i have no idea. I am using what the majority does. Simply sharing what the network provides.
If your piaware settings are default i.e. following:
--results beast,connect,localhost:30104
then dump1990-fa is capable to keep feed back at port 30104 isolated from port 30005, and only uses it to (1) display it on skyaware map & (2) output it on ports 30105 & 30106.
As other services use oitput from port 30005 of dump1090-fa, mlat feedback of FA is automatically isolated.
That is my expectaction on this topic.
That’s not how it works.
MLAT results have a certain timestamp. MLAT results are not forwarded on 30005 unless --forward-mlat is set. They are never forwarded on 30002.
That is NOT default setting of piaware.
What I said was that if default settings of piaware are used, the mlat feedback does not get mixed up with port 30005 output which is mainly used for feeding other sites.
I missed mentioning about port 30002, thanks for mentioning it, as FR24 may use either 30005 or 30002 output.
You said something about port 30104 which is unrelated.
I was talking about piaware’s default setting, wich includes mlat-results to port 30104. If piaware’s default settings are used, proper setting of forward-mlat is also covered.
1 Like
Focusing on ports and forwarding, or including dump1090 in the equation is beginning to look a moot point.
If I can feed it ‘stuff’ without dump1090 even being the source (direct usb modes beast) and have it ‘OK’ mlat state with it. There’s clearly some processing in the actual app going on.
Same if you set it to ‘dvbt’ with a stick. And have no --net or anything else triggered during start - it does not appear to actually open any udp/tcp ports? (Someone can also test and confirm)
It reports ‘OK’ - again somehow done internally or just a false pretense like we’ve requested a wording change for for so long.
However the moment you specify another source. It clearly can’t handle what its fed (unless very specific).
And this appears to be their solution rather than fix it. Or expose the flaw/ what competitor or setup is likely to blame.
Using beast splitter with my beast, you can also send pre processed/tagged/raw and make your source that. Again , ‘OK’.
1 Like
Something else just spring to mind
Remember this from February. It was due to data manipulation and injection not being able to be detected
I don’t recall a new client version deploy with any sort of fix, so presume it was server-side
Almost a little too coincidental
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.