Altitude is reported incorrectly via FANET protocol

[lenalebt]

First: I have seen #45 and that it was closed (inalid template usage), but I think they are related.

Hardware

• Prime Mark II
• Standalone
• UAV
• UAT module
• SkyView
• Flight Recorder

Firmware version

1.0-rc6 ESP32

Firmware settings

Describe the bug (or ask a question): BUG REPORT

GPS height reported by the device seems right, but height reported via FANET protocol seems to be wrong (off by about 780m). I used 2 devices (both Prime Mark 2, from different resellers), directly besides each other (see picture above). XCSoar shows the height correctly (using GPS from SoftRF, disabling internal GPS) as 811m (see screenshot:)

In FLARM radar however, the height of the other device is shown incorrectly (as -777m relative):

This view shows absolute heights:

I also had a colleague with a Skytraxx 3.0 check my reported heights, and they are reported as the same (around 15-40m) for him, from both devices. I can see his height correctly in XCSoar via SoftRF. (no photos here, if you need them I can take them later). I tried exchanging the devices (connecting to the other Prime Mark II), which did not change the situation.

See this NMEA log (captured via serial port from the computer):
capture.txt

You can see that the reported heights are indeed relative negative around 780m as in this line:
$PFLAA,0,-1,-5,-780,3,07A370!FAN_07A370,330,,0,0.0,7*4D

I am unsure how to capture GDL90, but if you need it I can provide that as well.

Since the heights are also reported incorrectly on a device that is not running SoftRF firmware, I think it must be somewhere on the sending side, not the receiving side, but this is a pure guess.

To Reproduce

Set up two devices besides each other, observe reported heights with FANET protocol via NMEA. The heights are reported incorrectly.

Expected behavior

The heights are reported correctly (up to GPS accuracy +-10-20m).

[lyusupov]

Please, provide status screenshots and serial output capture from both SoftRF units (close to each other, good satellites reception and at the same altitude).

[lenalebt]

Okay, there you go:

device 1:
capture-25A370.txt

device 2:
capture-C56E20.txt

8 satellites reception, <1m near each other.

Here a picture of the skytraxx device seeing the 56e20 device, as well as it showing it's own altitude:

[lyusupov]

Thanks!

I am currently in travel and will not be able to validate your report on the hardware I have
until at least end of this week (or begin of next week) .
If you have enough skills to build the firmware from source code and flash the binary into your unit -
I would suggest you to alter line 322 in Protocol_FANET.cpp from:

pkt->altitude_msb   = (altitude & 0x700) >> 16;

onto

pkt->altitude_msb   = (altitude & 0x700) >> 8;

[lenalebt]

I also am on holidays, with limited internet access (bandwidth), but will try to do so! Besides that, thanks for the nice software :). Am 2. September 2019 12:55:24 MESZ schrieb Linar Yusupov <notifications@github.com>:

…

Thanks! I am currently in travel and will not be able to validate your report on the hardware I have until at least end of this week (or begin of next week) . If you have enough skills to build the firmware from source code and flash the binary into your unit - I would suggest you to alter line 322 in [Protocol_FANET.cpp](https://github.com/lyusupov/SoftRF/blob/master/software/firmware/source/SoftRF/Protocol_FANET.cpp) from: ``` pkt->altitude_msb = (altitude & 0x700) >> 16; ``` onto ``` pkt->altitude_msb = (altitude & 0x700) >> 8; ``` -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #64 (comment)

-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

[lenalebt]

Tried it, but cannot get it to link properly. This is the error message I get:

/home/lena/.arduino15/packages/esp32/hardware/esp32/1.0.1/tools/sdk/lib/libbt.a(bt.o):(.literal.esp_bt_controller_enable+0xc): undefined reference to `btdm_rf_bb_init'
/home/lena/.arduino15/packages/esp32/hardware/esp32/1.0.1/tools/sdk/lib/libbt.a(bt.o): In function `esp_bt_controller_enable':
/local_disk/lyusupov/tmp/esp-idf/components/bt/bt.c:940: undefined reference to `btdm_rf_bb_init'
/home/lena/.arduino15/packages/esp32/hardware/esp32/1.0.1/tools/sdk/lib/libbt.a(bta_jv_act.o):(.literal.bta_jv_start_discovery_cback+0x8): undefined reference to `lwip_ntohs'
/home/lena/.arduino15/packages/esp32/hardware/esp32/1.0.1/tools/sdk/lib/libbt.a(bta_jv_act.o):(.literal.bta_jv_start_discovery_cback+0xc): undefined reference to `lwip_ntohl'
/home/lena/.arduino15/packages/esp32/hardware/esp32/1.0.1/tools/sdk/lib/libbt.a(bta_jv_act.o): In function `shorten_sdp_uuid':
/local_disk/lyusupov/tmp/esp-idf/components/bt/bluedroid/bta/jv/bta_jv_act.c:811: undefined reference to `lwip_ntohs'
/local_disk/lyusupov/tmp/esp-idf/components/bt/bluedroid/bta/jv/bta_jv_act.c:817: undefined reference to `lwip_ntohl'
libraries/BTClassicSPP/BTSPP.cpp.o:(.literal._ZL13esp_bt_gap_cb21esp_bt_gap_cb_event_tP21esp_bt_gap_cb_param_t+0x10): undefined reference to `esp_bt_gap_pin_reply'
libraries/BTClassicSPP/BTSPP.cpp.o: In function `esp_bt_gap_cb(esp_bt_gap_cb_event_t, esp_bt_gap_cb_param_t*)':
/home/lena/Arduino/libraries/BTClassicSPP/BTSPP.cpp:688: undefined reference to `esp_bt_gap_pin_reply'
collect2: error: ld returned 1 exit status

I used the libbt.a from the repo, as described in the README. I tried both versions 1.0.1 and 1.0.2 of the ESP32 SDK.

[lyusupov]

INSTRUCTIONS

• 1.0.2 is NOT recommended

/local_disk/lyusupov/tmp/esp-idf/components/bt/bt.c:940: undefined reference to..

• libbt.a from this location is NOT applicable for 1.0.1 Use the binary that comes with 1.0.1

[lenalebt]

Okay, that fixed it. Thank you :)! I just uploaded the suggested change to one of the devices, and it worked. I will create a PR for the change and attach it here.

[lyusupov]

If this was sufficient - there is no need for a PR.

Be aware that your C56E20 unit is having non-genuine NEO GPS module been soldered on the board.
It is not a critical issue. Think about to uncomment line 219 in your copy of Platform_ESP32.h:

//#define USE_AT6558_SETUP

[lenalebt]

It was sufficient - PR was already there. You can merge it or decline, both fine for me as long as the fix goes into the product :).

Thanks for the hint - I already was curious why the output was different for both devices. Fun fact: The device I ordered directly from china is the one with the genuine chip, the other one (bought on the airwhere homepage) had the non-genuine GPS chip. With USE_AT6558_SETUP, output of both devices via serial looks the same.

[lyusupov]

1. "height" (in the issue's subject ) is not an aviation term. This word is in use as one of an object's dimension characteristics , like L x W x H of an aircraft.
   Aviation terms are "altitude" and "elevation".

2. my patch does not qualify yet as a fix for incorrect altitude reporting. Not every case has been tested yet. I am going to process it when I will return from my tour.
   your commit does not qualify as a contribution because there were no any of your own R&D behind that. I approve a PR when a contributor has done full R&D by him- or her- self entirely, without my intervention. Hence, when he/she saved my own time. For example of a good, approved PR, see this one

3. LilyGO company had issues in Fall of 2018 when they did inappropriate sourcing of GPS modules for every of T-Beam production batches.
   Later on, LilyGO representative told me that they had solved this issue:

We have not used the previous module since we last talked about this problem.
Now we are getting the goods directly with the original UBLOX agent.

     I saw no reports on 'fake NEO' issue with T-Beams since then.
     I suppose that your 'fake NEO' T-Beam belongs to one of that old batches.

[lenalebt]

Your project - your rules ;).

I also changed altitude calulation above 2047m (confirmed wrong yesterday). I'd add unit tests (e.g. property-based tests to verify that fanet_decode(fanet_encode(x)) == x (circa) for all sensible x), but could not find a spot to add some.

Same here - you may use it, or discard it. In the end I'm not interested in the "fame", I just want it fixed :).

[lyusupov]

The issue has been reproduced.

Resolution: confirmed

[lyusupov]

Fix has been issued in this commit.

[lenalebt]

Confirm that the commit fixes the issue, both for altitudes <2047m and >=2047m.

[lyusupov]

Thank you for the confirmation!

If the issue is no longer pertinent for you - please, close it.