• State Verified Answer
  • Replies 3 replies
  • Subscribers 97 subscribers
  • Views 1069 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 327053
Options

ZBOSS: wrong RSSI reported in zb_intrp_data_ind_t (integer overflow?)

Patrick Große
Summary: The callback of zb_af_interpan_set_data_indication() seems to be reporting wrong RSSI levels (looks like an overflow) after upgrading from NCS v2.4.2 to NCS v2.5.2.
Prior to the NCS upgrade, I saw RSSI values of -50 in my test setup. Afterwards I see values in the area of -120 (in close proximity) and in the area of 115 (a little bit further away). This looks like an integer overflow to me, as the datatype is int8_t. The LQI values look fine.
Since ZBOSS doesn't seem to be changed between these versions, I guessed the issue might be in hal_nordic.
I tried to pin down when exactly the problem occurred by traversing back the hal_nordic commits, but before "a1a8a83 nrfx: Update to version 3.0.0" I cannot build the firmware anymore due to heavy API changes. Up until this version, the error is present.
We are using the network co-processor design. However, the host application is not changed and the issue can be reproduced by simply exchanging the firmware on the nRF52840.
Parents
  • 0

    zboss/nwk/nwk_main.c:2166 (ZBOSS v3.11.3.0) should be the first step in the data path which deals with RSSI values. Even there, the RSSI values are odd. Until that point, the packet data seems to be taken unchanged from the lower layers.

    After some research, I found this commit in Zephyr: github.com/.../b224a099fd3d56d068f22e825a9c4cd835590878
    It changes the interpretation of the lower layer RSSI value to being in the range of -174 dBm (value 0) to 80 dBm (value 254). Reverting that commit fixes the issue.
    The RSSI/power variables are uint8_t in Zephyr but are interpreted as int8_t in ZBOSS which results in the changing sign of the value.

    I suggest adapting the ZBOSS methods to correctly converting the RSSI value before storing it in the metadata.

Reply
  • 0

    zboss/nwk/nwk_main.c:2166 (ZBOSS v3.11.3.0) should be the first step in the data path which deals with RSSI values. Even there, the RSSI values are odd. Until that point, the packet data seems to be taken unchanged from the lower layers.

    After some research, I found this commit in Zephyr: github.com/.../b224a099fd3d56d068f22e825a9c4cd835590878
    It changes the interpretation of the lower layer RSSI value to being in the range of -174 dBm (value 0) to 80 dBm (value 254). Reverting that commit fixes the issue.
    The RSSI/power variables are uint8_t in Zephyr but are interpreted as int8_t in ZBOSS which results in the changing sign of the value.

    I suggest adapting the ZBOSS methods to correctly converting the RSSI value before storing it in the metadata.

Children
Related
Terms of service