Wrong OGNTP packets from SoftRF RaspberryPi edition on RELAY from dump1090 #74
Comments
|
Try out adb691f Think about to enable some debug here and there, then capture an output log. Be aware that:
|
|
With the patch adb691f do not transmit anything and the debug output log as ZERO !!! SoftRF-RPi FW.REV: 1.0-rc7 DEV.ID: 7F0101 follow after a wile by 👍 I started to suspect that my dragino board is a faulty one. I ordered a new one from the Aliexpress Dragino store now: |
|
Now with the GPS lock !!! 0000000000000000000000000000000000000000 |
0000000000000000000000000000000000000000 indicates that your SoftRF is STILL transmitting empty packets. and make sure that you are submitting 100% good JSON file on 100% right port number: - that was explained in Example 6 of Raspberry Edition's wiki. |
|
BTW, for your aircraft location example above (taken from JSON) and location of ground station (taken from NMEA):
Distance between these two points is well beyond 2 * ALARM_ZONE_NONE = 20 km. |
|
Yes I updated the code with your patch and recompile the program, no output whatsoever, so I removed the patch. I reverted the patch back just for the test Btw: on my dump1090 version the aircraft in JSON format is on I will increase the ALARM zone, just for the testing. |
|
After applying the patch again and increasing the ALARM_ZONE_NONE to 180 kms, this is the output and belo you can see the JSON data as well: SoftRF-RPi FW.REV: 1.0-rc7 DEV.ID: 7F0101 |
|
It seems based on the documentation that the .json format is different and I need to install the dump1090 from the Pia ware website |
|
You are likely using very, very old dump1090. This is how json file should look like: |
|
I will install the flightaware version, it looks as you described !!! |
|
JSON input should have 'aircraft' token being defined. SoftRF's JSON parser will not do the job otherwise: |
|
My dump1090 is actually not most recent. one It was built from 'mutability' GitHub repo before they've migrated onto 'flightaware' branch: I suppose that current 'flightaware' variant should be fine for SoftRF... |
|
I will test it with the FlighAware version and report the outcome
Enviado desde mi iPhone.
AC/.
… El 4 ene 2020, a las 20:19, Linar Yusupov ***@***.***> escribió:
My dump1090 is actually not most recent. one It was built from 'mutability' GitHub repo before they've migrated onto 'flightaware' branch:
***@***.***:~ $ which dump1090
/usr/local/bin/dump1090
***@***.***:~ $ ls -l /usr/local/bin/dump1090
-rwxr-xr-x 1 root staff 319052 Dec 22 2017 /usr/local/bin/dump1090
***@***.***:~ $ dump1090 --help
-----------------------------------------------------------------------------
| dump1090 ModeS Receiver dump1090-mutability |
-----------------------------------------------------------------------------
--device-index <index> Select RTL device (default: 0)
--gain <db> Set gain (default: max gain. Use -10 for auto-gain)
--enable-agc Enable the Automatic Gain Control (default: off)
--freq <hz> Set frequency (default: 1090 Mhz)
--ifile <filename> Read data from file (use '-' for stdin)
--interactive Interactive mode refreshing data on screen
--interactive-rows <num> Max number of rows in interactive mode (default: 15)
--interactive-ttl <sec> Remove from list if idle for <sec> (default: 60)
--interactive-rtl1090 Display flight table in RTL1090 format
--raw Show only messages hex values
.....
I suppose that current 'flightaware' variant should be fine for SoftRF...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
This the aircraft.json file from the dump1090 version by FlightAware
VERSION:
| dump1090 ModeS Receiver dump1090-fa 3.8.0 |
| build options: ENABLE_RTLSDR ENABLE_BLADERF SC16Q11_TABLE_BITS=8
Output to a file:
{ "now" : 1578177576.2,
"messages" : 82564,
"aircraft" : [
{"hex":"40768d","flight":"EZY74EL ","alt_baro":35000,"alt_geom":35875,"gs":450.4,"ias":267,"tas":448,"mach":0.788,"track":184.5,"track_rate":0.00,"roll":-0.2,"mag_heading":178.8,"baro_rate":0,"geom_rate":-32,"squawk":"0530","emergency":"none","category":"A3","nav_qnh":1012.8,"nav_altitude_mcp":35008,"lat":40.474365,"lon":-4.403931,"nic":8,"rc":186,"seen_pos":0.4,"version":2,"nic_baro":1,"nac_p":9,"nac_v":1,"sil":3,"sil_type":"perhour","gva":2,"sda":3,"mlat":[],"tisb":[],"messages":2508,"seen":0.1,"rssi":-16.0},
{"hex":"4ca75e","category":"A3","version":2,"sil_type":"perhour","mlat":[],"tisb":[],"messages":3504,"seen":72.9,"rssi":-25.6},
{"hex":"0d0bba","alt_baro":18775,"alt_geom":19825,"gs":473.6,"ias":337,"tas":442,"mach":0.712,"track":253.1,"track_rate":0.03,"roll":0.4,"mag_heading":254.7,"baro_rate":1472,"geom_rate":1536,"squawk":"2645","category":"A5","lat":40.513504,"lon":-4.559265,"nic":8,"rc":186,"seen_pos":50.7,"version":2,"nic_baro":1,"nac_p":9,"nac_v":1,"sil":3,"sil_type":"perhour","gva":2,"sda":2,"mlat":[],"tisb":[],"messages":2672,"seen":30.4,"rssi":-24.6},
{"hex":"4bb152","category":"A5","version":2,"sil_type":"perhour","mlat":[],"tisb":[],"messages":3139,"seen":99.3,"rssi":-26.6},
{"hex":"3c0d09","alt_baro":38000,"alt_geom":38750,"gs":411.5,"ias":248,"tas":442,"mach":0.784,"track":40.3,"track_rate":0.00,"roll":0.2,"mag_heading":42.7,"baro_rate":0,"geom_rate":32,"squawk":"6257","category":"A3","nav_qnh":1013.6,"nav_altitude_mcp":38016,"nav_altitude_fms":38000,"nav_heading":44.3,"lat":40.588806,"lon":-2.763306,"nic":8,"rc":186,"seen_pos":28.2,"version":2,"nic_baro":1,"nac_p":9,"nac_v":1,"sil":3,"sil_type":"perhour","mlat":[],"tisb":[],"messages":3643,"seen":28.2,"rssi":-24.9},
{"hex":"3455d9","flight":"VOE2725 ","alt_baro":38000,"alt_geom":38825,"gs":409.6,"ias":243,"tas":434,"mach":0.768,"track":41.2,"track_rate":0.00,"roll":0.0,"mag_heading":45.4,"baro_rate":0,"geom_rate":0,"squawk":"6265","emergency":"none","category":"A3","nav_qnh":1012.8,"nav_altitude_mcp":38016,"lat":40.801454,"lon":-2.593273,"nic":7,"rc":371,"seen_pos":0.2,"version":2,"nic_baro":1,"nac_p":9,"nac_v":1,"sil":3,"sil_type":"perhour","gva":2,"sda":2,"mlat":[],"tisb":[],"messages":5327,"seen":0.2,"rssi":-22.4},
{"hex":"495286","category":"A0","version":0,"sil_type":"unknown","mlat":[],"tisb":[],"messages":4341,"seen":259.3,"rssi":-27.4}
]
}
pi@SoftRF:~ $
It looks OK to me !!!
Good nite.
AC/.
Sent from my iPad
… On 4 Jan 2020, at 21:11, Angel Casado ***@***.***> wrote:
I will test it with the FlighAware version and report the outcome
Enviado desde mi iPhone.
AC/.
>> El 4 ene 2020, a las 20:19, Linar Yusupov ***@***.***> escribió:
>>
>
> My dump1090 is actually not most recent. one It was built from 'mutability' GitHub repo before they've migrated onto 'flightaware' branch:
>
> ***@***.***:~ $ which dump1090
> /usr/local/bin/dump1090
> ***@***.***:~ $ ls -l /usr/local/bin/dump1090
> -rwxr-xr-x 1 root staff 319052 Dec 22 2017 /usr/local/bin/dump1090
> ***@***.***:~ $ dump1090 --help
> -----------------------------------------------------------------------------
> | dump1090 ModeS Receiver dump1090-mutability |
> -----------------------------------------------------------------------------
> --device-index <index> Select RTL device (default: 0)
> --gain <db> Set gain (default: max gain. Use -10 for auto-gain)
> --enable-agc Enable the Automatic Gain Control (default: off)
> --freq <hz> Set frequency (default: 1090 Mhz)
> --ifile <filename> Read data from file (use '-' for stdin)
> --interactive Interactive mode refreshing data on screen
> --interactive-rows <num> Max number of rows in interactive mode (default: 15)
> --interactive-ttl <sec> Remove from list if idle for <sec> (default: 60)
> --interactive-rtl1090 Display flight table in RTL1090 format
> --raw Show only messages hex values
>
> .....
>
> I suppose that current 'flightaware' variant should be fine for SoftRF...
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub, or unsubscribe.
|
I've taken more close look into each one's README-json.md and can see, that 'flightaware' is using similar but different 'dialect' of D0190 JSON rather than 'mutability' does. I've updated Example 6 with:
|
Below is a list of actions that I do and the results that I've got after these actions
and I see this output:
These lines indicate each radio transmission session for every aircraft in the traffic list:
to properly terminate 'SoftRF' UNIX process: |
|
This is ZIP of aircraft.json file that I used in the example above: Hope this helps you... |
|
Linar,
That is very helpful indeed, I will try with the FligthAware version of the dump1090 and let you know, so you can share it with some other people.
I saw that the FA version does not support by default the http to the port 8080 and relays on a file like /tmp/aircraft.json to be passed to the web servers or to SoftRF thru the “nc” command.
Thanks again for your great support.
AC/.
Sent from my iPad
… On 5 Jan 2020, at 10:52, Linar Yusupov ***@***.***> wrote:
This is ZIP of aircraft.json file that I used in the example above:
aircraft.zip
Hope this helps you...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Read that I've said above. Details: FA uses 2 altitudes (geo and pressure) and 3 speeds (tas, ias, gs). MUTABILITY uses 1 altitude and 1 speed. JSON tokens for them are different. |
|
I see thanks, I misunderstood the different dialect comment.
Thanks again.
AC/.
Sent from my iPad
… On 5 Jan 2020, at 11:12, Linar Yusupov ***@***.***> wrote:
Read that I've said above.
Details: FA uses 2 altitudes (geo and pressure) and 3 speeds (tas, ias, gs). MUTABILITY uses 1 altitude and 1 speed. JSON tokens for them are different.
FA JSON will be just ignored by SoftRF because of this condition
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Great job Linar ... your support is second to none !!!!
I will submit some enhancement to the documentation like now the stretch Raspbian distro is using automaker 1.16 and the libraries are built using automaker 1.5, so autoreconf needs to be run, essentially commenting my experiences
Again thanks so much.
AC/.
Sent from my iPad
…> On 5 Jan 2020, at 11:12, Linar Yusupov ***@***.***> wrote:
Read that I've said above.
Details: FA uses 2 altitudes (geo and pressure) and 3 speeds (tas, ias, gs). MUTABILITY uses 1 altitude and 1 speed. JSON tokens for them are different.
FA JSON will be just ignored by SoftRF because of this condition
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Great support indeed. |
lyusupov
changed the title
ATTENTION !
Recommended:
Hardware
< photo of your hardware > (required)
Same that previous issue.
Firmware version
Same than previous issue
SoftRF-RPi FW.REV: 1.0-rc7 DEV.ID: 7F0101
SX1276 RFIC is detected.
Firmware settings
{ echo "{class:SOFTRF,mode:RELAY}" ; cat /dev/ttyAMA0 ; } | sudo ./SoftRF
Describe the bug (or ask a question)
After solving some installation issues, now the dragino Hat that is properly installed, the GPS works and the dump1090 is working properly
However the RELAY packets from dump1090 in OGNTP format seems to be wrong:
This is the output of the telnet localhost 50001 of an OGN station (LEMD) nearby the RPi+dragino HAT with the SoftRF SW+dump1090
0.404sec:868.393MHz: s9:0:000000 000142: [ -65.08855,-181.61252]deg 790m +0.5m/s 162.6m/s 054.1deg +5.3deg/sec O:9/0 11x17m 01_o -6.78kHz 45.8/61.5dB/0 0e 11734.5km 224.2deg +2.3deg B0885
0.423sec:868.393MHz: s9:0:000000 000142: [ -65.08855,-181.61252]deg 790m +0.5m/s 162.6m/s 054.1deg +5.3deg/sec O:9/0 11x17m 01_o -6.79kHz 46.0/61.5dB/0 0e 11734.5km 224.2deg +2.3deg B0885
APRS <- RND000000>OGNTRK,qOR:/000142h6505.31S/18136.75W^054/316/A=002592 !W31! idA4000000 +099fpm +1.8rot FL029.04 46.0dB 0e -6.8kHz gps11x17
HTTP_Server.Exec() ... Client from 127.0.0.1:59660
HTTP_Server.Exec() ... Request for /
0.804sec:868.393MHz: s9:0:000000 000142: [ -65.08855,-181.61252]deg 790m +0.5m/s 162.6m/s 054.1deg +5.3deg/sec O:9/0 11x17m 01f_ -6.79kHz 46.2/62.0dB/0 0e 11734.5km 224.2deg +2.3deg B0885
0.505sec:868.393MHz: s9:0:000000 000142: [ -65.08855,-181.61252]deg 790m +0.5m/s 162.6m/s 054.1deg +5.3deg/sec O:9/0 11x17m 01_o -6.79kHz 46.5/62.0dB/0 0e 11734.5km 224.2deg +2.3deg B0885
APRS -> # aprsc 2.1.4-g408ed49 4 Jan 2020 00:01:59 GMT GLIDERN2 37.187.244.41:14580
APRS time - system time = +0
0.452sec:868.393MHz: s9:0:000000 000142: [ -65.08855,-181.61252]deg 790m +0.5m/s 162.6m/s 054.1deg +5.3deg/sec O:9/0 11x17m 01_o -6.80kHz 46.8/62.5dB/0 0e 11734.5km 224.2deg +2.3deg B0885
The coordinates are wrong:
-65.088 and -181.61 are totally wrong.
The traffic from dump190 over port 8080 is OK
[
{"hex":"34558e", "squawk":"3765", "flight":"AEA057 ", "lat":40.512876, "lon":-4.071496, "validposition":1, "altitude":13800, "vert_rate":1664,"track":243, "validtrack":1,"speed":386, "messages":294, "seen":286}
]
To Reproduce
Expected behavior
It looks that it could be a problem with the baud rate to the LoRa perhaps ???
The text was updated successfully, but these errors were encountered: