Archived - Beta test MLAT software for Raspberry Pi

[iamnothere]

Yes , DVB-T stick .

well , maybe frame rate seems lower a bit , maybe I should cleaning and maintenance the antenna , air pollution is very bad here .
Screen Shot 2015-07-19 at 11.30.23 PM.jpg

[equi]

I talked about the fr24 stats page However, really impressive!

[Guest]

Can you base your fork on the mutability repo (https://github.com/mutability/dump1090) which also has oversampling mode and a nicer gui?

Well, that's actually not decided yet. You know that different people prefer different forks. So far we would like to accumulate the statistics. But if you really want to use mutability right now, feel free to apply patches from our fork, it's still opensource.

Does this MLAT version of fr24feed expose the MLAT positions in a beast/basestation feed? so they can be plotted in VRS?

No sorry, this is not supported. The reason for that is that MLAT positions are calculated server-side, having mode-s messages from 4 receivers in the area.
To return data back to the receivers will require quite a lot of modifications and the traffic will also increase.

Can I make a suggestion that a stick is made or the initial post for this thread is edited to contain a howto for people who feed multiple sites, for instance FR and FA, describing how to setup the MLAT version of fr24feed so that both FR and FA can benefit from these advances, because I've seen a number of people not going ahead with the upgrade because it breaks feeding to other sites without clear instructions on how to do things so it works all round? I replied to the Aussie feeders thread with a quick howto because there was some complaint about all this..

Thanks, will stick a link.

i also upgraded to 1.0.14-5. all stopped working. --signup and choosing MLAT causes only to choose usb dongele as receiver
the version before gave me the option to use sbs1/3.
now it is gone. when i signup again and use MLAT no i get all hardware options back,
but when i switch on MLAT at the webinterface all is hanging up and webinterface is gone.

maybe we will get some info from the programmer, if sbs1/3 data could be used for MLAT.
why not? i'm curious about it.

This update actually blocks fr24feed to start MLAT without "dvbt" setting. The reason for that as I said, we need timestamp decoded by our dump1090 fork. Other sources of data provide timestamps in a different format or do not provide it at all.
We are definitely going to support more data sources, but for now it doesn't make any sense to start MLAT when we know in advance that the received timestamp will not be parsed correctly and hence the position will not be calculated.
The workaround you posted doesn't force MLAT calculations, it just forces additional data to be sent to the server, which is dropped there.
We would like to stabilize the MLAT implementation first, basing on DVB-T sticks and after that implement support of other data sources. I hope it makes some sense

So, going back to my NTP issue... can an option to turn off ntp sync be added? or use the localhost ntp server? I can see that fr24feed is going it alone and using pool.ntp.org but for some reason it's not using any local servers by default.. Just would think that as you are relying on ADS-B transponder timestamps for then the local timestamp could be taken from system clock.. If anything, check for presence of ntp and make sure its running..? And Raspbian installs ntp by default..

I don't know what to suggest, I cannot see why fr24feed is not getting NTP sync very often... I have been watching the ntp traffic from that machine via my border router and ALL requests are being answered. Is there a debug mode which might expose the ntp requests and the responses and why they are being disregarded? Help?

Thanks for the suggestion, we will implement usage of NTP servers configured in /etc/ntp.conf if there are some.

Any1 else noticed that the range dropped ? Before the latest release I had ~120-130nm range, but now i'm @ only ~100nm which sucks -.-

No changes were supposed to be made at this part. Hopefully nothing is broken

[equi]

No changes were supposed to be made at this part. Hopefully nothing is broken

First of all, thank you for your time to answer our postings vinnyspb . But sadly FR24's fork of Malcom Robb's fork broke my range. I don't know if you have access to our Stats pages, but if you check my Radar Page you'll notice that since 1.0.14-5 dropped for some reason. Before this release I used Malcom Robb's fork which worked fine.

[Guest]

First of all, thank you for your time to answer our postings vinnyspb . But sadly FR24's fork of Malcom Robb's fork broke my range. I don't know if you have access to our Stats pages, but if you check my Radar Page you'll notice that since 1.0.14-5 dropped for some reason. Before this release I used Malcom Robb's fork which worked fine.

Have you used some additional arguments to dump1090 before?

[equi]

Yes, the same arguments are working since one year

--net --net-http-port 8082 --aggressive --enable-agc

[Astrofreak85]

as far as I know from this and other threads "--agressive" is not recomendet as you get a lot of "false positives" since the are hex-codes that diver only by one bit

[Guest]

Yes, the same arguments are working since one year

Would be nice to compare the coverage with if you remove "--aggressive --enable-agc".

[equi]

Thanks for your tip Astro.
@vinny: I removed both entries now, but I'll wait till next service restart (i have a daily restart Job running) so we can compare today with tomorrow (tomorrow I have a bit less traffic compared to today, 5-7%).

[iamnothere]

Hi equi ,
Do you using external usb hub with extra power for the DVBT ?

[equi]

Yes, a Belkin 4 Port active Hub

[iamnothere]

Hi vinnyspb ,

I just remove the --aggressive arguments which I've been use for long time , interesting thing is I seems lose few nm but the mode-s packets rate goes up ,

mean more position report , ain't I correct ?

[papasven]

Can you base your fork on the mutability repo (https://github.com/mutability/dump1090) which also has oversampling mode and a nicer gui?

Well, that's actually not decided yet. You know that different people prefer different forks. So far we would like to accumulate the statistics. But if you really want to use mutability right now, feel free to apply patches from our fork, it's still opensource.

Hi

Easy apply patches does not work mutability repo have significant changes since nothing happens in MalcolmRobb repo i have tried.
Mutability's fork brings for me better results (more message from gnd, more messages per sec and a better range) and a important thing the CPU usage is lower, a little decision aid from me.


Regards

[bhaal]

Mutability's fork brings for me better results (more message from gnd, more messages per sec and a better range) and a important thing the CPU usage is lower, a little decision aid from me.

I've turned off my FR MLAT transmission for now while I test mutability to see if it is indeed better, and if it is, then I likely won't turn FR MLAT back on unless they convert to using an unmodified version of mutability.. cpu usage alone is significantly lower, this is a huge incentive all on it's own.. While I acknowledge that some things would need to be re-coded, it's still disappointing that we do not get back MLAT data for plotting via VRS etc, would love to see that change..

Thanks

[equi]

Yesterday's stastics without "--aggressive --enable-agc"

Aircraft seen: 1,158
Positions reported: 23,522
Maximum distance: 80nm

and this is from Monday

Aircraft seen: 1,345
Positions reported: 46,355
Maximum distance: 106nm

I will test Malcom Robb's fork tomorrow to see if its running better.