Page 22 of 91 FirstFirst ... 1220212223243272 ... LastLast
Results 211 to 220 of 901

Thread: Archived - Beta test MLAT software for Raspberry Pi

  1. #211
    Purser
    Join Date
    Jan 2015
    Location
    Kallangur, Brisbane
    Posts
    168
    vinnyspb: Why does FR24's feeding software require a special proprietary version of dump1090? Why can't you use the Mode-S data that comes out of mutability etc? Surely if you need modified timestamps you could do this translation at the server end? I do understand that back at the beginning of the year you launched a complete suite of fr24feed + proprietary dump1090 in order to try and iron out inconsistent data, but I would have thought that data inconsistency could be eliminated by correlation between a number of feeders seeing the same data.

    I feel like you have limited your feeder pool by being so restrictive. I see this especially with the RTLSDR MLAT data.. What I see on the FR24 website seems to be wildly inaccurate and very limited at the best of times. This is as opposed to the MLAT data I am seeing on my local VRS which gets feedback from FA's MLAT client, the data is consistent with planes which fly directly over my house, and in some directions I am seeing MLAT positions down to as low as 500ft..

    Can some consideration please be put in to using Mode-S data from standard versions of dump1090 for MLAT data, with timestamp modification being done either in the fr24feed client or at the server end. That makes a whole lot more sense to me..
    T-YBBN50 - Kallangur, QLD, Australia

  2. #212
    Super Moderator
    Join Date
    May 2011
    Location
    T-NZCH1, PP:PH New Zealand
    Posts
    5,002
    Don't believe its proprietary - seems to be the -MR Malcolm Robb updated Dump1090 (last original 1090 update was ages ago) with better reception and processing rate (along with some HTTP server data etc) and I think youll find Piaware uses a fork of that too going by some docs out there.

    https://github.com/sjthespian/dump10...ster/README.md

    The joys of open source. They all have advantages and disadvantages

  3. #213
    Flight attendant
    Join Date
    Jan 2013
    Location
    T-LSZD25
    Posts
    53
    Quote Originally Posted by bhaal View Post
    Surely if you need modified timestamps you could do this translation at the server end?
    Timestamps need to be done on the client. The networking path would cause too much jitter (1ms=300km)

  4. #214
    Purser
    Join Date
    Jan 2015
    Location
    Kallangur, Brisbane
    Posts
    168
    Quote Originally Posted by Oblivian View Post
    Don't believe its proprietary - seems to be the -MR Malcolm Robb updated Dump1090 (last original 1090 update was ages ago) with better reception and processing rate (along with some HTTP server data etc) and I think youll find Piaware uses a fork of that too going by some docs out there.

    https://github.com/sjthespian/dump10...ster/README.md

    The joys of open source. They all have advantages and disadvantages
    Can you please link me to the source for FR24's fork of MR's fork of the original dump1090 please? As for Piaware, it's not restricted to the MR version of dump1090 for MLAT data, I think the latest .deb for dump1090 produced for PiAware might even be the Mutability fork of dump1090..

    Quote Originally Posted by helios View Post
    Timestamps need to be done on the client. The networking path would cause too much jitter (1ms=300km)

    Ok, firstly let me say, prior to my previous post I had not investigated fully how the FR version of Pi MLAT worked. I still haven't, but I think I have a good idea now...

    "Take Mode-S only packet attach wildly inaccurate timestamp based on NTP which at best can only be considered accurate to the second, send modified packet to MLAT server, and cross fingers..."

    Is that it? Is that how FR are doing this? If so, how many feeders does it take to get a position which could be considered even vaguely correct?

    vinnyspb, I am trying to give constructive criticism, while asking these questions so please do not take personal offence :/

    Ok... So, NTP lets start there... My nearest stratum 1 NTP server (which can only be used by request [I have not requested it]) is on average 1.847ms (and 7 hops) away from the Linux desktop I type this forum post from (I have "fibre to the premises" internet). It is 2.735ms away from the Pi B+ that runs dump1090, so already right there is a HUGE amount of jitter, around 1ms of which caused by the lag inside the Pi itself... everything runs over that 1 USB host, all the SDR packets as well as the network traffic, then we have the CPU load causing extra grief as well (cpu load which is not helped by the cycle hungry FR24 version of dump1090)..

    So, setting an accurate time is going to be extremely difficult.. You might suggest setting up a stratum 1 NTP server ON the Pi itself using a GPS transponder... Wrong, fr24feed uses exotic intercontinental NTP servers...

    The main reason why MLAT positioning was originally tossed overboard with regards to RTL-SDR receivers is because of the USB bus lag... THAT still exists regardless of how accurate a clock source is that exists. I can only see 1 way around that... 2 dongles using the same clock crystal, and have dump1090 read data from both dongles, and any identical Mode-S packets it doesn't receive at the same time from both dongles: Toss them overboard.. Any that it does, timestamp them with the onboard GPS clock and send to the MLAT server... Wait... Did I just come up with a cheap alternative to a Mode-S Beast??? I am not proficient in C, so trying to code a soft-Beast is out of my depth, but it's food for thought..

    So, working towards what I understand fr24feed to be doing: Tack an inaccurate timestamp to a Mode-S packet which has a huge amount of lag generated by the USB bus and send it to MLAT servers, and hope like crazy that it works out... At this point I stop wondering why the Dash-8 I saw this afternoon on my VRS with FlightAware MLAT positions fed in, as well as seeing the plane with my own eyes, fly directly overhead, appear on the FR24 website about 20km east of my position.

    Advantages to doing RTL-SDR MLAT positioning this way: no reliance on any thing else... Can't think of any other advantages?

    Disadvantages, wildly inaccurate positions.. Large number of feeders required to make the data more accurate before it's displayed ONLY on the FR24 website, not feedback data for the feeders so they can use that data on their own display system... Also, adding all these timestamps chews a hefty amount of CPU cycles..

    Moving forward, the Mutability way of doing things (Which is what FA is using):

    dump1090 receives Mode-S packets and ADS-B packets at the same time, for packets which arrive at exactly the same time, send them to the MLAT server. There is no need to add exotic timestamps etc, just send the raw information.

    Advantages: Considerably accurate MLAT positions, positions are also calculated quickly, from the normal bare minimum 3 feeder locations to generate an MLAT position, (however the more the merrier in case of poorly configured geographic co-ordinates of feeders).. Less cpu required as data is not being transposed onto existing packets, the packets are just being forwarded..

    Disadvantages: MLAT positions cannot be generated for a Mode-S only aircraft if there is no ADS-B enabled aircraft visible to at least 3 feeders at the same time, they also have to receive the same ADS-B and Mode-S packets in the same order as each other, otherwise the data is discarded. (this is occuring right now, a Mode-S only capable rescue helicopter is about to fly near by, I can only tell this by signal strength as there are no ADS-B enabled aircraft within range of my receiver right now)

    I may have some or all of this wrong.. Please enlighten me if I have as this is what I am trying to do, understand... I am not posting all this to try and upset people etc.. I am trying to educate myself by generating a bit more discussion, and also hopefully help get better data for FR24!
    T-YBBN50 - Kallangur, QLD, Australia

  5. #215
    Flight attendant
    Join Date
    Jun 2015
    Posts
    62
    Hi bhaal,

    Thanks for the constructive criticism, but you described exactly the algorithm we've implemented here. There is no rely on NTP-only timestamps. We sync those timestamps across ADS-B traffic server-side, simultaneously visible between 3 Raspberry Pi receivers and 1 FR24 receiver that has exact precise GPS time aligned with Mode-S signal. Positions uncertainty is of course a problem, and we will definitely work on improving the quality. I understand your frustration about vendor-lock for dump1090 - that might be improved in future.
    You asked for a link to sources: https://github.com/flightradar24/dump1090
    Last edited by vinnyspb; 2015-08-03 at 06:42.

  6. #216
    Passenger
    Join Date
    Aug 2015
    Location
    Guernsey (T-EGJB6)
    Posts
    11

    Cool

    Hi everyone,

    T-EGJB6 now back online with MLAT here in St Peter Port, Guernsey using an RPi 2 with a PPS-coupled GPS receiver feeding NTP, so should be nice and stable.
    Hoping to improve coverage for the Trislanders and inter-island flights which are typically below 2000ft as well as the Dash-8 and ATR aircraft which provide most of our local flights and require MLAT.

    Flightradar24 Feeder/Decoder
    Linux/generic/armv7l/1.0.14-7
    Updated: 17:25:59 GMT+0100 (BST)


    FR24 Link: Connected via UDP
    FR24 Radar Code: T-EGJB6
    Aircraft Tracked (ModeS & ADS-B): 135
    Aircraft Uploaded: 102
    Receiver: dvbt, Connected
    MLAT running: YES

    Code:
    pi@raspberrypi ~ $ ntpq -crv -pn
    associd=0 status=011d leap_none, sync_pps, 1 event, kern,
    version="ntpd 4.2.6p5@1.2349-o Mon Jul 27 15:39:38 UTC 2015 (1)",
    processor="armv7l", system="Linux/3.18.11-v7+", leap=00, stratum=1,
    precision=-20, rootdelay=0.000, rootdisp=0.419, refid=PPS,
    reftime=d96a1556.10db60db  Mon, Aug  3 2015 17:29:10.065,
    clock=d96a1562.690440e5  Mon, Aug  3 2015 17:29:22.410, peer=19256, tc=4,
    mintc=3, offset=-0.005, frequency=-1.441, sys_jitter=0.001,
    clk_jitter=0.000, clk_wander=0.001
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    o127.127.22.0    .PPS.            0 l   12   16  377    0.000   -0.005   0.001
    *127.127.28.0    .GPS.            0 l   11   16  377    0.000    1.801   1.119
    -217.114.59.66   157.44.176.4     2 u  155 1024  377   57.604    7.965   1.916
    -217.114.59.3    158.43.192.66    2 u  330 1024  377   57.414    8.811   2.478
    +162.13.167.224  161.62.36.7      2 u  266 1024  377   28.485   -3.185   2.732
    +185.53.93.157   195.66.241.10    2 u  396 1024  377   27.643   -2.823  69.697

  7. #217
    First officer
    Join Date
    Mar 2013
    Location
    Arhus (T-EKAH3), Denmark
    Posts
    345
    So vinnyspb, is the following true for this to work?:

    1) Minimum 1 FR24 receiver and 3 RPi receivers must see the S-mode aircraft in question.
    2) All 4 receivers must at the same time also see an ADS-B aircraft for time reference.

  8. #218
    Passenger
    Join Date
    May 2013
    Posts
    27
    Not sure if this is the right thread.. and hope I haven't missed a conversation about this already, but after updating everything to latest stable (via apt-get), two problems:

    1) I am somehow missing MR dump1090... the service is trying to start it from /usr/lib/fr24 but the only thing there is dump1090 (mr-dump1090 nowhere to be found).. is the path to executable configurable somewhere?

    2) My feed got renamed... and I don't like the new name. I ran the --signup but provided existing sharing key... (which is still in the .ini file) but got a new name.. why? how do I go back to the old one

  9. #219
    Flight attendant
    Join Date
    Jun 2015
    Posts
    62
    Quote Originally Posted by Kpin View Post
    So vinnyspb, is the following true for this to work?:

    1) Minimum 1 FR24 receiver and 3 RPi receivers must see the S-mode aircraft in question.
    2) All 4 receivers must at the same time also see an ADS-B aircraft for time reference.
    Exactly.

    Quote Originally Posted by t-kclt2 View Post
    Not sure if this is the right thread.. and hope I haven't missed a conversation about this already, but after updating everything to latest stable (via apt-get), two problems:

    1) I am somehow missing MR dump1090... the service is trying to start it from /usr/lib/fr24 but the only thing there is dump1090 (mr-dump1090 nowhere to be found).. is the path to executable configurable somewhere?

    2) My feed got renamed... and I don't like the new name. I ran the --signup but provided existing sharing key... (which is still in the .ini file) but got a new name.. why? how do I go back to the old one
    /usr/lib/fr24/dump1090 is a fork off mr-dump1090, you can use all it's features. No need to reconfigure the path.
    Feed rename happened most likely due to the different coordinates selected during previous registration.
    Please contact FR24 support to change radar id back.

  10. #220
    Passenger
    Join Date
    Sep 2013
    Location
    near EDDH
    Posts
    17
    New Version with MLAT works fine for me

    [ ok ] FR24 Feeder/Decoder Process: running.
    [ ok ] FR24 Stats Timestamp: 2015-08-05 08:24:53.
    [ ok ] FR24 Link: connected [UDP].
    [ ok ] FR24 Radar: T-EDDH14.
    [ ok ] FR24 Tracked AC: 50.
    [ ok ] Receiver: connected (12532 MSGS/0 SYNC).
    [ ok ] FR24 MLAT: ok [UDP].
    [ ok ] FR24 MLAT AC seen: 51.


    Thanks a lot, great work!
    near HAM // F-EDDH1 FR24 Box // T-EDDH14 Raspberry Pi - DVB-T Dongle

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •