Have ordered a RPi2 to join the party and do some other tasks, you guys mostly running Raspbian or is there a slimmer/faster alternative I should look at. Not too afraid of a lack of gui if it comes to it.
Announcement
Collapse
No announcement yet.
Archived - Beta test MLAT software for Raspberry Pi
Collapse
This topic is closed.
X
X
-
-
Originally posted by Oblivian View PostHave ordered a RPi2 to join the party and do some other tasks, you guys mostly running Raspbian or is there a slimmer/faster alternative I should look at. Not too afraid of a lack of gui if it comes to it.T-YSBK22
Comment
-
Originally posted by rodeo View PostYup, just running Raspbian .... its all pretty easy if you're not afraid to get down and dirty at the command line :-) just be aware of the little quirks of running both both FR and FA on the one RPi (mainly to do with MLAT feedback from FA)Posts not to be taken as official support representation - Just a helpful uploader who tinkers
Comment
-
I don't know why but I have the problem, that the DVB-T stick disconects again...since some days (maybe last 9th or 10th september...)
dmesg looks like this, again:
[ 418.294221] usb 1-1.5.4: new high-speed USB device number 7 using dwc_otg
[ 418.406266] usb 1-1.5.4: New USB device found, idVendor=0bda, idProduct=2838
[ 418.406291] usb 1-1.5.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 418.406309] usb 1-1.5.4: Product: RTL2838UHIDIR
[ 418.406325] usb 1-1.5.4: Manufacturer: Realtek
[ 418.406341] usb 1-1.5.4: SerialNumber: 00000001
[ 418.440797] usb 1-1.5.4: dvb_usb_v2: found a 'Realtek RTL2832U reference design' in warm state
[ 418.496092] usb 1-1.5.4: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
[ 418.496176] DVB: registering new adapter (Realtek RTL2832U reference design)
[ 418.512063] i2c i2c-3: Added multiplexed i2c bus 4
[ 418.512110] rtl2832 3-0010: Realtek RTL2832 successfully attached
[ 418.512191] usb 1-1.5.4: DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))...
[ 418.512618] r820t 4-001a: creating new instance
[ 418.524860] r820t 4-001a: Rafael Micro r820t successfully identified
[ 418.546290] Registered IR keymap rc-empty
[ 418.546863] input: Realtek RTL2832U reference design as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5.4/rc/rc0/input2
[ 418.547189] rc0: Realtek RTL2832U reference design as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5.4/rc/rc0
[ 418.548079] input: MCE IR Keyboard/Mouse (dvb_usb_rtl28xxu) as /devices/virtual/input/input3
[ 418.548904] rc rc0: lirc_dev: driver ir-lirc-codec (dvb_usb_rtl28xxu) registered at minor = 0
[ 418.548935] usb 1-1.5.4: dvb_usb_v2: schedule remote query interval to 200 msecs
[ 418.557523] usb 1-1.5.4: dvb_usb_v2: 'Realtek RTL2832U reference design' successfully initialized and connected
[ 418.557881] usbcore: registered new interface driver dvb_usb_rtl28xxu
[ 500.992929] usbcore: deregistering interface driver dvb_usb_rtl28xxu
[ 501.195585] r820t 4-001a: destroying instance
[ 501.195962] usb 1-1.5.4: dvb_usb_v2: 'Realtek RTL2832U reference design' successfully deinitialized and disconnected
I only did a "fr24feed restart" between the conect and the automatic disconect of the stickT-EDDC46
Comment
-
Originally posted by Kpin View PostI have been following one aircraft I know not to be ADS-B equipped flying along the north coast of The Nederlands, and clearly some of the Raspberry Pi feeders are feeding Flight Aware calculated positions back into FR24.
So fare I have seen T-EHAM63 and T-EHSB7 shown as the radar for this aircraft (OY-EUR). Something should be done to weed these position reports out.
However, I have just seen it supposedly tracked down the UK by no less than 6 T-xxxx feeders which are clearly pumping backfed MLAT data (presumably from FlightAware) into FR24:
T-EGCC96
T-EGGP49
T-EGLK18
T-EGSS27 (a feeder near Stansted favoured when the aircraft is almost over Southampton at FL150? Very dodgy!)
T-EGHI61
T-EGLK18 (again)
T-EGHI62
Tracking only changed to MLAT when it was mid-channel and presumably out of range of that last EGHI (Southampton) feeder contributing to the 3rd party MLAT feed.
FR24, surely it is easy to detect this server side when you are getting ADS-B data for a particular aircraft from only a couple of feeders and the majority are picking up non-ADS data and either contact those concerned or disregard their feed data?
Perhaps we should start a name and shame thread?
atr no mlat6.pngLast edited by cbgsy; 2015-09-15, 19:30.
Comment
-
Originally posted by cbgsy View PostI've just seen another example of this with flight GR679 from Manchester to Guernsey which is operated by G-VZON, an ATR-72 - definitely MLAT only.
However, I have just seen it supposedly tracked down the UK by no less than 6 T-xxxx feeders which are clearly pumping backfed MLAT data (presumably from FlightAware) into FR24:
T-EGCC96
T-EGGP49
T-EGLK18
T-EGSS27 (a feeder near Stansted favoured when the aircraft is almost over Southampton at FL150? Very dodgy!)
T-EGHI61
T-EGLK18 (again)
T-EGHI62
Tracking only changed to MLAT when it was mid-channel and presumably out of range of that last EGHI (Southampton) feeder contributing to the 3rd party MLAT feed.
FR24, surely it is easy to detect this server side when you are getting ADS-B data for a particular aircraft from only a couple of feeders and the majority are picking up non-ADS data and either contact those concerned or disregard their feed data?
Perhaps we should start a name and shame thread?
[ATTACH=CONFIG]6438[/ATTACH]
I reported the problem to support and they are aware of this but apparently unable to fix it at the moment:
"Yes, that is happening at the moment. Our developers are looking into it.
At the moment the option is to completely block those feeds but they are not feeding bad data continuously. Well, our developers are looking into it and hopefully they will come up with a solution soon."
Comment
-
Easy quick solution is what bhaal suggested in this post: http://forum.flightradar24.com/threa...ll=1#post68679
which is, to quote:
sudo piaware-config -mlatResultsFormat "basestation,listen,31003"
this will stop the FA mlat client sending mlat positions back to dump1090 (and therefore stop it screwing everything up for fr24feed) and also allow you to add the feed mlat position feed to VRS on port 31003.
This is what I have done and I believe it to be working, as a good stop-gap measure.
There is a few feeders here in Sydney suffering the same issue (hopefully I'm not one of them !!)T-YSBK22
Comment
-
Originally posted by rodeo View PostEasy quick solution is what bhaal suggested in this post: http://forum.flightradar24.com/threa...ll=1#post68679
which is, to quote:
sudo piaware-config -mlatResultsFormat "basestation,listen,31003"
this will stop the FA mlat client sending mlat positions back to dump1090 (and therefore stop it screwing everything up for fr24feed) and also allow you to add the feed mlat position feed to VRS on port 31003.
This is what I have done and I believe it to be working, as a good stop-gap measure.
There is a few feeders here in Sydney suffering the same issue (hopefully I'm not one of them !!)
Comment
-
Originally posted by cbgsy View PostFR24, surely it is easy to detect this server side when you are getting ADS-B data for a particular aircraft from only a couple of feeders and the majority are picking up non-ADS data and either contact those concerned or disregard their feed data?
Note that the standard FlightAware/piaware sdcard images, which is the large majority of installs, do not forward mlat outside their own systems unless explictly told to. mlat-client sends synthetic position messages to dump1090, but dump1090 is configured not to forward those messages further (e.g. it will not send them back out on port 30005). They can only escape if the user explicitly asks to forward them, or if piaware is installed on top of an existing system that forwards them.
I contacted FR24 / Planefinder / VRS at the time I developed this to let them know they may start seeing these messages, with details on how to recognize and discard them as needed.
Planefinder had it supported in a matter of hours.
VRS added support for marking mlat messages as such, and has gone through a whole release cycle with that support now.
I have had no response from FR24 at all, so I suppose it's not really important to them. If it is important to them.. perhaps they can reply to my email.Last edited by obj; 2015-09-16, 14:02.
Comment
-
Originally posted by obj View PostI contacted FR24 / Planefinder / VRS at the time I developed this to let them know they may start seeing these messages, with details on how to recognize and discard them as needed.
Comment
-
Originally posted by Kpin View PostJust so I understand: You are the developer behind dump1090, and those feeder hosts cross feeding from FA to FR24 must be doing this deliberately, because dump1090 would not normally do this?
The cross-feeds may be accidental, but a vanilla Flightaware sdcard image will not do this by default - it requires reconfiguration before it will forward mlat data. This filtering happens within the version of dump1090 provided on the image. Current development versions of dump1090-mutability behave in the same way, you must explicitly pass --forward-mlat before they will forward it. Other dump1090 versions may forward mlat data regardless - if you install the piaware feeder manually into an existing system, this could happen if the user doesn't take care.
It's also possible that the cross-feeds are actually nothing to do with Flightaware, and they're coming from another multilateration source such as mlat-radar.net (which also uses mlat-server / mlat-client) which has fairly complete UK coverage.
Part of the problem is that there is a huge variety of different bits of software involved, and it's not at all practical to require that only particular software is used. That's why the approach is to make the positions easily identifiable so when they do, inevitably, leak out, you can detect that and ignore them. The lack of an ADS-B data exchange protocol that can also carry metadata doesn't help here.
It would be great to have a better, more robust way of doing this. But it requires coordination between all the bits of software involved, and despite my efforts that has not happened.
Comment
-
Originally posted by obj View PostOther dump1090 versions may forward mlat data regardless - if you install the piaware feeder manually into an existing system, this could happen if the user doesn't take care.
Obviously, someone who is not prone to tinkering like me will leave things as installed and thats where the problems are starting. There's a couple of feeders here in Sydney that obviously have stock installs.
Cheers.T-YSBK22
Comment
-
The simplicity of the how-to may also hamper that.
Most people are happy to share data here and there to multi sites to increase the coverage of not 1 in particular. And at the same time may only visit support/forums when they have to if it just 'works' by following a guide.
Of course many of these users will have done the setup and not updated versions since, nor have the one capable of self-updating (or may not even know the commandline to pull from the repository as a couple of low-posters have asked for assistance for here)
Catch22 really. Add features to make stuff better, hampered by first editions. Like we are seeing with web development now. Older platforms requiring early IE versions, now don't support the new browsers. Update browser, find it doesn't work with older web server code they have not updated elsewhere to support Web3->HTML5 ARGHPosts not to be taken as official support representation - Just a helpful uploader who tinkers
Comment
-
I like to setup different Raspberry pi's in this region to see all the General Aviation flying around here using the mlat capabilities of FR24, also at low altitude's.
On the forum I read a lot about this topic and so far I understood a non ADS-B plane should be seen by minimal one FR24 (F) feeder and three Raspberry pies. They all should see an ADS-B plane as reference.
In this region I see local mlat planes above 3000ft. At lower altitudes they disappear. During the same flight of those local planes, I see the radar changing from mlat into T-feeders. The T-feeders are all the time of the same four feeders. If the radar is changing from mlat to a T-feeder the plane is jumping to another position (1-2 km) So it's not very accurate.
Last week I set up my first pi and it's running well.
My question is: Will a Radarcape receiver be seen as a F-feeder from FR24? So if I use that feeder together with some Rasberry Pi's in the region will I see alle the planes at low altitude?Last edited by Cooler; 2015-09-19, 20:50.
Comment
Comment