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

[piopawlu]

I am not sure this has anything to do with FR24 package itself. Those files are not a part of our deb package, but reinstalling any deb from dpkg could be triggering it.

[paulvt]

I have been using FR on my Windows box but have switched to the beta on OS X. I have download the package and I am trying to setup but having a problem with receiver's COM port number/device path. How do I find this info? I have found the device is the System Profiler but no luck with getting the info input correctly. I see the bus and location ID but am stuck... can anyo

USB 3.0 Hi-Speed Bus:

Host Controller Location: Built-in USB
Host Controller Driver: AppleUSBXHCI
PCI Device ID: 0x8c31
PCI Revision ID: 0x0005
PCI Vendor ID: 0x8086
Bus Number: 0x0a
RTL2838UHIDIR:

Product ID: 0x2838
Vendor ID: 0x0bda (Realtek Semiconductor Corp.)
Version: 1.00
Serial Number: 00000001
Speed: Up to 480 Mb/sec
Manufacturer: Realtek
Location ID: 0x14600000 / 12
Current Available (mA): 500
Current Required (mA): 500

[piopawlu]

For a DVBT receiver you do not need to specify any com ports, just select receiver type DVBT and it will connect automatically.

Piotr

[yf1ar]

piopawlu said I will clean the thread and remove these posts. I am pretty sure FlightAware does not allow their equipment to be used to feed competitors' networks.

i am now feeding ADS-B flightradar24 using flightaware

this is WIII-7

[yf1ar]

i am now feeding ADS-B flightradar24 using flightaware

this is WIII-7

[Wolli]

strange display on fr24 web page

Today I notice some strange behaviour on the FR24 web page, see for example the following screenshot showing flight ACA875:
SC138.jpg
While the real position of the aircraft is - at the moment of the screenshot - already east of town "Venlo" (the track has already reached this position and my feeder does also confirm this position), the aircraft's shape is displayed still north of town "Viersen".

This is not a feeder problem, but obviously a problem of the FR24 "tracking server". Regards, -Wolli-

[Dundee]

i am now feeding ADS-B flightradar24 using flightaware

this is WIII-7

Me too. Actually Flightfeeder provide 4 ports output:
FlightAware ADS-B TSV (TCP Port 10001)
Basic AVR / RAW ADS-B (TCP port 30002)
SBS/Basestation Format (TCP port 30003)
Mode-S Beast Format (TCP port 30005)

It's confirmed that port 30003 output is not compatible with FR24 requirement. You guys may just try the other ports (10001, 30002, 30005) with corresponding to Receiver Type {ModeS Beast (TCP), SBS1/1e/3 (TCP), AVR (TCP)}. I think at least one combination is work !!!

Thanks!

[Wolli]

Today I notice some strange behaviour on the FR24 web page, see for example the following screenshot showing flight ACA875:
[...]
While the real position of the aircraft is - at the moment of the screenshot - already east of town "Venlo" (the track has already reached this position and my feeder does also confirm this position), the aircraft's shape is displayed still north of town "Viersen".

This is not a feeder problem, but obviously a problem of the FR24 "tracking server". Regards, -Wolli-

This evening I notice again this "buggy" behaviour, see screenshot:
SC-AEE4A.jpg

Regards, -Wolli-

[equi]

This happens a lot Wolli, mainly on bad Transponders or bad (FR)-Radar.

[Wolli]

This happens a lot Wolli, mainly on bad Transponders or bad (FR)-Radar.

Yep, obviously and unfortunately, dear equi. Although there are several radars online (!) in the area shown by the screenshots, the FR24 "tracking server" - for displaying the plane's shape - seems to rely frequently on a radar (probably an F-radar) that communicates incorrect positions (position with offsets. as it seems to me). However - for displaying the plane's track - the FR24 "tracking server" seems to rely on good quality data. IMHO there is some potential to slightly adjust the server software for correct display of the plane's shape position.

Note, that the plane in screenshot of posting #454 did never (!) fly on the position shown by the plane's shape. Regards, -Wolli-

[equi]

2 or 3 weeks ago there was a T-Radar between Thuringia and Hesse which broke the tracking in this region for 3 or 4 hours. No Registration, Callsign or flight track where available during that time. FR24 Server preferred this Station till it went offline (or it was disconnected from the network). However, I don't know how this Backend works - but sometimes it makes some strange things (like your Aegean Bus).

PS: Despite of that, FR24 should allow MLAT for T-Radars

[donde1]

I would like to attach an LED to the Raspberry Pi that will flash every time I get a log entry in /var/log/fr24feed.log
I know how flash to flash the LED. I was looking at the script in /etc/init.d/fr24feed for a way to insert few lines like this:
gpio -g write 4 1
sleep 0.5
gpio -g write 4 0

with a gpio -g mode 4 out at the top in the of the inialization section.
I get the LED to flash on and then in 0.5 seconds off. But it never repeats. I put the 3 lines within the start() function after the write command. I don't think I'm in the right place for this script in not in the logging loop of the aircrafts received.

[StDt]

How can I view the planes that are tracked with my raspberry pi at the moment?

With the OSX software there was an option to show the planes in range of the receiver. Is this working with the raspberry pi version too? Any hints?

[donde1]

Without a filter, you see all planes in range of all receivers. With a radar filter enabled with your radar call sign, you see planes "handed off" to your radar. These are not necessarily used to enhance the map accuracy. The FR24 computer on the network decides. The Raspberry Pi setup I have may not have the features you have, and visa versa.

[StDt]

Ok, that works with RadarView if I insert the IP address of my Raspberry Pi that is feeding FR24.

Thanks for that hint.