Flightradar24 decoder/feeder BETA testing (Win/RPi/Linux/OSX)

[slammer99uk]

Less than 11 hours today reporting 7946 AC between 09:32 - 19:15 (now) figures obtained from BS Reporter.
My FR24feed stats are showing over 42K AC reported.

When you start the feeder off, watch for the line "syncing stream" it will occur about a minute or two after you see it feeding AC, then watch the number of AC rise and keep rising. This must have something to with the MLAT function surely?

The increase in numbers is difficult to explain. As I write this BS is tracking 133 AC where is the feeder getting the 600+ figure from? See the second snippet below.

This is what I used to see:-
2015-09-10 11:08:11 | [feed][i]sent 3 AC in 1 packet
2015-09-10 11:08:14 | [feed][i]removed 3 of 118 AC
2015-09-10 11:08:16 | [feed][i]sent 119 AC in 3 packets
2015-09-10 11:08:18 | [feed][i]removed 1 of 130 AC
2015-09-10 11:08:22 | [feed][i]sent 115 AC in 3 packets
Nice sensible numbers of AC I am actually seeing in BS

This is what I see now:-
2015-09-10 19:18:29 | [feed][i]sent 151 AC in 4 packets
2015-09-10 19:18:29 | [feed][i]removed 14 of 648 AC
2015-09-10 19:18:33 | [feed][i]removed 24 of 660 AC
2015-09-10 19:18:34 | [feed][i]sent 165 AC in 5 packets
Not so sensible numbers

Something changed, apart from the new client (now reverted to the old one) nothing has changed at my end.

Jerry

[Oblivian]

I'd say I would be seeing similar If it was, and many others. Make sure all mlat features are off in the config too. Its not supported without a stick and could be looping data on 30003

Sent from my GT-I9300 using Tapatalk

[slammer99uk]

I don't think that is going to cut it Oblivian. 11-6 .ini file has no reference to MLAT and it was disabled when running 14-9. Might be worth waiting for the crash again and check the time mine and apgphoto's in our event logs.

Currently it is chugging along nicely on 11-6.

EDIT just decided to check my event log for this event for the last 4 days that this has been happening:-
10/09 - 07:22 vers 14-9
09/09 - 07:17 vers 14-9
08/09 - 07:04 vers 14-9
07/09 - 07:17 vers 11-6
With other crashes in between, mostly from me playing around trying to fix it

Surely this is no coincidence??
Thanks for your help btw.

Jerry

[Oblivian]

Well, given it apparently was fine with the old ver, and then not. And I'm running the latest version with no issue there is only a few common denominators, which I'm trying to work out for the devs benefit.

And unfortunately with only 2 examples only perseverance and or fiddling and testing is the only way forward unless someone else speaks up.

So far, the only thing I'm seeing in common, is the SBS, and you both run windows. Of which you would hope there were a lot more examples out there. But there is a chance not many have an SBS to gain enough data to validate.
I wouldn't expect any back end changes to effect MLAT data as it has been enabled on the RPi version until now for quite some time to already handle it. So the win client is the only real thing that could have a change made to bring it up to the same point ready to be enabled with DVBs, which we can't tell who has and hasn't upgraded to. Else the RpI users would be up in arms about now if they broke with a backend change too

Too many factors involved when it comes to windows, Patch tuesdays (where they send out updates and often bung ones), NTP time sync etc etc. Without waiting for Vinny to notice and enlighten us on what side the [n] functions is occurring and what the stream sync involves we may just be stuck for the time being.

[slammer99uk]

Understood. I will continue to help with information as and when I have something I feel is worthwhile. Sorry I don't know who Vinny is, I am assuming he is something to do with the back end or a client dev.

The old version was fine until 3 days ago when it crashed (see date/times above) at which point it came to my notice that the newer version was available when checking this forum for others in the same position.

BTW I run an NTP client on my machine which updates every 10 secs, so nothing to do with out of sync time. Output for time sync in the fr24feed always shows a 0.0000 sec/min drift. Good enough for MLAT but not available to us SBS-3 users

Jerry

[Oblivian]

Understood. I will continue to help with information as and when I have something I feel is worthwhile. Sorry I don't know who Vinny is, I am assuming he is something to do with the back end or a client dev.

BTW I run an NTP client on my machine which updates every 10 secs, so nothing to do with out of sync time. Output for time sync in the fr24feed always shows a 0.0000 sec drift.

Jerry

Think hes one of the Devs. Popped up in the Rpi thread. I was running NTP service standalone, but it was conflicting with the built in one and often causing it to jump 4-7 sec at a time (got a fast clock in the laptop as it is) so got it disabled for now to see if I see the same large hops. Won't ever help me if I get the MLAT option.

Have purchased a RPi last night to have a play with that and see if its any more reliable for time and serving than the laptop now too. That way I can also run the beast (I hope) on it and still pull data over network as I do now.

[slammer99uk]

I was just writing here to say it was 07:30 here and no crash, however at 07:34, Bingo, it crashed.

Log Name: Application
Source: Application Error
Date: 11/09/2015 07:34:27
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: Lenovo
Description:
Faulting application name: fr24feed.exe, version: 1.0.11.6, time stamp: 0x54ca4ad9
Faulting module name: fr24feed.exe, version: 1.0.11.6, time stamp: 0x54ca4ad9
Exception code: 0xc0000005
Fault offset: 0x00043e8a
Faulting process ID: 0xa70
Faulting application start time: 0x01d0ebb1036e1733
Faulting application path: C:\fr24feed_win32-1.0.11-6\fr24feed.exe
Faulting module path: C:\fr24feed_win32-1.0.11-6\fr24feed.exe
Report ID: 89144e59-541e-4c18-8ed0-58526459fb0b
Faulting package full name:
Faulting package-relative application ID:
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2015-09-11T06:34:27.000000000Z" />
<EventRecordID>31541</EventRecordID>
<Channel>Application</Channel>
<Computer>Lenovo</Computer>
<Security />
</System>
<EventData>
<Data>fr24feed.exe</Data>
<Data>1.0.11.6</Data>
<Data>54ca4ad9</Data>
<Data>fr24feed.exe</Data>
<Data>1.0.11.6</Data>
<Data>54ca4ad9</Data>
<Data>c0000005</Data>
<Data>00043e8a</Data>
<Data>a70</Data>
<Data>01d0ebb1036e1733</Data>
<Data>C:\fr24feed_win32-1.0.11-6\fr24feed.exe</Data>
<Data>C:\fr24feed_win32-1.0.11-6\fr24feed.exe</Data>
<Data>89144e59-541e-4c18-8ed0-58526459fb0b</Data>

Jerry

[slammer99uk]

It is now getting to point where I may as well give up feeding FR24 The client is too unreliable, or should I say is too reliable to crash around around the same time in the morning.

Oblivian I think you need to liaise with the devs or the back end admin or at least bring it to their attention. The timing is just too coincidental to rule out a client/server fault. I appreciate that they volunteer their time and resources as do you, but if we are to carry on feeding FR24 something needs to be done to enable us to do so reliably.

Jerry

[slammer99uk]

Ok last ditch attempt. I am now running the OSX client natively on my main machine and feeding all my other feeders using its 30003 BS output over the LAN to my laptop running Windows 10. I have to say setting it up was pretty easy, just requiring the IP changing in the Hardware section in BS.

Lets see if this crashes

Jerry

[apgphoto]

Strangely enough mine also crashed this morning 0709, repeating the previous days continuous run from mid afternoon through to the morning.

No MLAT enabled details from the files:

receiver="sbs1usb"
fr24key="xxxxx"
bs="yes"
raw="yes"
baudrate="115200"
logmode="0"
windowmode="0"
mpx="yes"

ac_map_size=1600
build_arch=i386
build_flavour=generic
build_os=Windows
build_revision=284
build_timetamp=Jan 29 2015 15:59:23
build_version=1.0.11-6
cfg_baudrate=115200
cfg_bs=yes
cfg_host=
cfg_mpx=yes
cfg_path=
cfg_raw=yes
cfg_receiver=sbs1usb
cfg_windowmode=0
d11_map_size=14373
feed_alias=T-EGBJ21
feed_current_mode=UDP
feed_current_server=83.140.21.66
feed_last_ac_sent_num=159
feed_last_ac_sent_time=1441959541
feed_last_attempt_time=1441955274
feed_last_config_attempt=1441955273
feed_last_config_info=
feed_last_config_result=success
feed_last_connected_time=1441955278
feed_num_ac_tracked=732
feed_status=connected
feed_status_message=
fr24key=xxxxxxxxxxx
last_json_utc=1441959484
last_rx_connect_status=OK
last_rx_connect_time=1441955287
last_rx_connect_time_s=2015-09-11 07:08:07
msg_ring_full=0
msg_ring_length=0
num_messages=15183527
num_resyncs=0
rx_connected=1
shutdown=no
time_update_utc=1441959545
time_update_utc_s=2015-09-11 08:19:05
timing_is_valid=1
timing_last_drift=+0.0029
timing_last_offset=+0.0111
timing_last_result=success
timing_time_last_attempt=1441959095
timing_time_last_success=1441959095
timing_time_since_last_success=603

Yesterday my feed software saw 42,413 aircraft, Basestation saw 6598 aircraft.

As per Jerry the feeder is just too unreliable and the fact that FR24 "control" my output to others, Planeplotter, MilModeS etc and my own Basestation the constant crashing is at a point where I cant use it. Maybe i will just feed with my hosted unit, but that has a much lower reception area due to aerial sighting.

[apgphoto]

So I have moved house and been running the feeder with just the basic aerial from the SBS-3 on the window sill as an experiment.

If I'm very lucky I will get a max of 50 aircraft at a peak time seen by Basestation. The feeder has been running for three days solid without crashing *cheers loudly* so I presume it obviously cant cope with 150+ aircraft at anyone time.

Even with a smaller number of real aircraft the Feeder is still decoding crap from the SBS-3, below is an example of the rubbish that its seeing:

FR24 Feeder Tracked Aircraft List
Updated: 09:59:50 GMT+0100 (GMT Standard Time)

ModeS: 00000C Callsign: N/A
Lat: 0
Long: 0
Alt: 32000ft
SQW: 0000

ModeS: 000DB3 Callsign: N/A
Lat: 0
Long: 0
Alt: 0ft
SQW: 0000

ModeS: 000FDF Callsign: N/A
Lat: 0
Long: 0
Alt: 37000ft
SQW: 0000

ModeS: 002000 Callsign: N/A
Lat: 0
Long: 0
Alt: 0ft
SQW: 0000

ModeS: 00455F Callsign: N/A
Lat: 0
Long: 0
Alt: 0ft
SQW: 0000

ModeS: 005F78 Callsign: N/A
Lat: 0
Long: 0
Alt: 0ft
SQW: 0000

As a comparison my BS saw 3412 aircraft but my Feeder saw 21,508 aircraft according to the stats page, so somehow the Feeder software is just reading rubbish out of the SBS-3

As a further comparison I set up my FR24 box last night with its proper aerial mounted up on the roof...

This morning it has seen 1,141 with a range of 358nm

This morning the feeder has seen 10,891 with a range of 341nm the plotter on my SBS has actually only seen 161nm!

I'm surprised its only the two of us that have reported issues with the Feeder software and that nobody at the FR24 end has noticed how much crap data they are receiving!

Paul

[slammer99uk]

I am sorry to say I have given up on FR24feed now. I even tried the MAC OS X client and that often crashed as well. I am not bothered about the free premium account as I pay for mine anyway. So I have switched to feeding PF instead, their client is a native windows one and has been sitting in the tasktray for the last 2 weeks happily chugging away, along with feeds for VRS, ADSB-hub and MLATradar.

The other big upside is that I now have regained control of the SDR's on the SBS-3 and lost nothing by giving up FR24, but I was sorry to see it go.

Jerry

PS - I was also getting the empty messages that Paul posted he is getting. Personally I don't think this is coincidence, and probably points to incompatiblity problem with the BS format we are (were) both using to feed FR24. I believe PF calls these "positionless reports" and strips them from the displayed data, though you can still them on the personal stats page.

[apgphoto]

I have also now given up on the Feeder software its just too unstable throws out all kinds of rubbish data from my SBS-3, I wouldn't mind if all the crap data just went to FR24 but it goes to whatever is down stream of the Feeder.

Nice to see the blog post today telling everyone to switch to the current Feeder software as all other will be deactivated, would be nice if it actually worked in the first place.

[wxmeddler]

I installed the software on my windows machine yesterday after seeing the tweets and blog post. Finally got it working, had a heck of a time paring it back up with Virtual Radar Server (FR's directions in the manual are wrong). Range has decreased by at least 50km versus using RTL-1090 even with using the command line extensions such as gain and ppm. The FR24feed window I cannot minimise into the tray to get rid of the window space like the old application did. Also, the "Restart" command doesn't work because while it shuts the program down, it doesn't close the window and thus it cannot start a new one without windows throwing an exception.

Why are you pushing this as mandatory when it is obvious this system is still in Beta?

[drk]

I installed the software on my windows machine yesterday after seeing the tweets and blog post. Finally got it working, had a heck of a time paring it back up with Virtual Radar Server (FR's directions in the manual are wrong).

I guess I should have read this thread before spending hours trying to get FR24 working this week.
Yes I'm a newbie to ADS-B, however I got ADSB# and VRS running in < 5 minutes as well as rtl1090, dump1090 & mr-dump1090. D/L'ed FR24 feeder and signed-up with FR24 and have had very little success, having multiple issues and I haven't attempted to get VRS running with FR24.

I see the data fly down the screen with the 1090's but when I start FR24, I see endless pings, or a couple of sentences always ending in "connection terminated".
When I bring up FR24 live, I don't see any A/C around here, with ADSB# and VRS I was tracking 245 A/C and up to 241 miles away. so I know they're up there

At this point, I 'd appreciate some help. I've searched the web, read various comments, etc. Am I missing something?
Are the inaccuracies mentioned only related to VRS, if not, how incorrect is the manual?

And after I shutdown FR24 and restart it, I am back at the original set-up screen, does that indicate anything?

Thanks,

drk