OGN-R Upgrade for for PilotAware Mode-S/3D

[Kevin W]

Hi

It took me a while to get around to it, and I had some problems, but EGBKE is now running v20190429.  New Pi (3B) and existing 2 x Flight Aware Pro Plus dongles, 1 connected by an active USB extension.

I started with a fresh image and booted up, ran the config script and had quite a bit of an issue with the Eprom serial numbers part.  After multiple runs of the script and multiple reboots I ended up with 1 dongle that rtl_eeprom would not recognise, because it ended up with a Vendor Id of 0ba0 rather than 0bda!  I am not sure how, rtl_eeprom doesn't even let you set the vendor id other than by a total eeprom upload.  Anyway, a hack of rtl_eeprom to recognise 0ba0 as a valid rtl, read the eeprom of the working dongle, write it to the non working dongle, manually set the serial numbers - and the script then flew through.

FR24 package installed using the 360Radar dump1090 already running and then looks to work well. fr24feed.ini if it is of help to others:

Code: [Select]

receiver="avr-tcp"
fr24key="xxx"
bs="no"
raw="no"
logmode="1"
mlat="yes"
mlat-without-gps="yes"
And finally, an motd updated for the new box to remind me where everything is:

Code: [Select]

service rtlsdr-ogn status
    Daemon - /etc/init.d/rtlsdr-ogn
    Config - /etc_org/rtlsdr-ogn.conf
    Cron - /home/pi/rtlsdr-ogn/PilotAware-OGN.update.sh to /tmp/PilotAware-OGN.crontab.log

    OGN RF - /home/pi/rtlsdr-ogn/ogn-rf
        Config - /home/pi/rtlsdr-ogn/rtlsdr-ogn-paw.conf
        Web - http://ognpaw:8080/
        Out - netcat localhost 50000

    OGN Decode - /home/pi/rtlsdr-ogn/ogn-decode
        Config - /home/pi/rtlsdr-ogn/rtlsdr-ogn-paw.conf
        Web - http://ognpaw:8081/
        Out - netcat localhost 50001

    PilotAware - /home/pi/rtlsdr-ogn/PilotAware-OGN.exe
        Config - /home/pi/rtlsdr-ogn/PilotAware-OGN.config.dat
        Web - http://ognpaw/
        Out - netcat localhost 50002
        Log - /tmp/conn360.txt

    360 Radar Dump1090 - /home/pi/360Radar/start1090
        Config - /etc_org/default/360r-mlat-test-svr2
        Config - /home/pi/360Radar/360r-mlat-test-svr2
        Out - netcat localhost 50003
        Changes - added --stats-every 5 to /home/pi/360Radar/start1090

    Virtual Radar - /home/pi/vrs/startvrs
        Config - /home/pi/.local/share/VirtualRadar.org/Configuration.xml
        Web - http://ognpaw:9000/VirtualRadar/desktop.html

service 360r-mlat-test-svr2 status

    360 Radar Mlat
        Daemon - /etc/init.d/360r-mlat-test-svr2
        Config - /etc_org/default/360r-mlat-test-svr2
        Log - /var/log/360r-mlat-test-svr2.log

service fr24feed

    Flight Radar 24 Feed
        Daemon - /etc/systemd/system/fr24feed.service
        Config - /etc_org/fr24feed.ini
        Log - /var/log/fr24feed/fr24feed.log
        Cron - /etc_org/cron.d/fr24feed_updater to /var/log/fr24feed_update.log
        Status - /usr/bin/fr24feed-status
        Web - http://ognpaw:8754/

Cheers
Kev

[Moffrestorer]

Hi Vic,

I had the same problem with the eprom serial number part of the config, one of the SDR dongles reporting as 0ba0. I haven’t been able to resolve it. Are you able to provide a detailed description of how you implemented your hack that I might be able to follow? (see my posting OGN-R with VRS, not displaying ADS-B targets).

Thx,

Chris

[exfirepro]

[Clipped]
Hi

It took me a while to get around to it, and I had some problems, but EGBKE is now running v20190429.  New Pi (3B) and existing 2 x Flight Aware Pro Plus dongles, 1 connected by an active USB extension.

Cheers
Kev

Hi Kev,

Not sure how you will get on with these dongles. As well as a built-in pre-amp, the FlightAware Pro Plus has a built-in 1090MHz filter which will surely filter out the 868MHz FLARM signals that we need.

When I tried one of these recently on the 1090 side in PWEFortun (with a NooElec NESDRSmart on the 868), the station exhibited extremely poor performance - we (Lee and I) think due to throttling of the RPi, as the spec for the FlightAware Pro Plus indicates that it can draw up to 300mA, which is expecting a lot from the RPi when it is also running another dongle plus the Bridge. After exchanging the FlightAware Pro Plus to a standard PilotAware Low Power SDR, the performance increase is like night and day!

I’ll watch with interested to see how you get on.

Regards

Peter

[Kevin W]

Hi Kev,

Not sure how you will get on with these dongles. As well as a built-in pre-amp, the FlightAware Pro Plus has a built-in 1090MHz filter which will surely filter out the 868MHz FLARM signals that we need.

Morning Peter, I was waiting for someone to spot the 1090 filter issue - a microscope and a AFS869S3-T sorted that.  I have been running those two dongles for a good while now on the old Pi 2b, since maybe Aug 18.  I certainly saw improvements in range when I first used them, might be worth doing some tests again now.

Power supply wise it seems ok, no throttling seen on the pi, although it did crash on me once yesterday afternoon, so something to keep an eye on.

Code: [Select]

pi@ognpaw:~ $ vcgencmd get_throttled
throttled=0x0
pi@ognpaw:~ $ uptime
 06:58:17 up 17:32,  2 users,  load average: 3.10, 2.60, 2.44

Cheers
Kev

[Kevin W]

Hi Vic,

I had the same problem with the eeprom serial number part of the config, one of the SDR dongles reporting as 0ba0. I haven’t been able to resolve it. Are you able to provide a detailed description of how you implemented your hack that I might be able to follow? (see my posting OGN-R with VRS, not displaying ADS-B targets).

Thx,
Chris

Hi Chris

Not sure who Vic is 

So the way I did it - Took the working dongle in the ognpaw and ran rtl_eeprom -r filename to dump the working config.  Then took a fresh pi, installed the rtl_sdr source, edited the source to replace 0ba0 with 0bda, built rtl_eeprom,  plugged in the non working dongle, and ran rtl_eeprom to write the eeprom from the working dongle to the non working dongle (-w filename). 

I could have edited the source to add the second identifier as well as the first - but was easier to just replace the existing one and then throw that rtl_eeprom away when done.

If that doesn't work for you, you could also try playing with the "-g <conf> generate default config and write to device]" setting to generate a default config and write it?

Good luck!

Cheers
Kev