Thread Network RSSI

[kalpino]

Hello,

I developed a Thread network starting off from SDK for Thread 4.1 multiprotocol example. In my application I send data over MQTT-SN with a period of 1 second (packet size is about 100 bytes).
It happens frequently that a packet requires retransmissions due to missing publication acknowledge. I think the reason is related to poor network connection.

I measured RSSI using Thread CLI (commands "scan" and "scan energy").
Here are the RSSi values considering different distances between Thread node and Border Router:

- 1cm distance: RSSI is about -30dB.
- 1m distance: RSSI is about -60dB.
- 3m distance: RSSI is about -70dB.

I wonder if these values are a bit too low to not have loss of data. I also set radio power on the node to 8dB using thread API otPlatRadioSetTransmitPower().
Is there any way to improve this behavior?

Also, is there any way I can increase radio power on the NCP connected to the Raspberry Pi (Border Router)?

Thanks!

[Edvin]

Hello,

By default I believe all the samples use 0dBm. Did you specifically change this in any of the devices? (If you are not sure, you probably didn't).

What HW are your thread nodes running on? nRF52840 DK? nRF52840 Dongle from Nordic? 3rd party modules?

Are there any non-nordic devices in your network? (besides the raspberry pi, which I assume is using an nRF52840 DK/dongle as the radio module (NCP))

Best regards,

Edvin

[kalpino]

Hello Edvin,

my workbench includes one Border Router (Rapsberry PI + nRF52840 Dongle) built with the latest Nordic image (v4.1.0-1.alpha) and one nRF52 Dongle that works as a MQTT-SN client publishing data every 1 second.

As to what concerns the radio power, I used otPlatRadioSetTransmitPower() to set radio power to 8dB at start-up. I can measure an 8dB radio power if I run otPlatRadioGetTransmitPower() at runtime.

I believe my issue is related to radio power in reception, not on transmission, on the thred node side, since I can send data but often miss the publication acknoledge sent by the Border Router.

[Edvin]

Ok, so you only have two nodes, right?

 

kalpino said:

I believe my issue is related to radio power in reception, not on transmission,

 Of course, but they are related, you know. I just wanted to check that you didn't set it lower somewhere in your FW.

Try to use nrf_802154_tx_power_set() and check whether the TX power changes when you receive it if you try to set it really low, just to check that the way that you set the TX power actually works. It is not easy to measure the difference between 0 and 8, so try to measure the difference between -40 and 8 or something, without moving the Dongles physically.

I don't think your numbers are unreasonable. I got around -30dBm with two DKs that are next to one another on my desk. A lot of the TX power is lost when the signal moves from the antenna to the air, and from air to the antenna. Also, packet loss is not only caused by TX power. It may be due to obstackles (someone walking in between, reflections, or other radio traffic sources such as WiFi. You must expect some loss from time to time. That is why we use retransmissions. 

Best regards,

Edvin

[kalpino]

I tried to use nrf_802154_tx_power_set()/get() to change radio power but I see that the change is not maintained for long, as also described here.

I am using softdevice s140 in a multiprotocol application (BLE+Thread): do I need to use a different function, such as sd_ble_gap_tx_power_set()? I am a bit confused.

Regarding your statement:

Edvin said:

I don't think your numbers are unreasonable. I got around -30dBm

I was expecting something close to 0dBm since the two nodes are one next to the other.
As a consequence I assume I cannot publish data over MQTT-SN with a short period (i.e. 1 second or lower): isn't this a bit of a limitation?

[kalpino]

UPDATE:

Using Wireshark I noticed there are multiple publish of the same message: these are not retransmissions due to the timeout (MQTTSN_DEFAULT_RETRANSMISSION_TIME_IN_MS) which is set to 5000ms.
These additional messages have the same payload and are sent with a time delta of a few milliseconds. Also, only one ACK is sent back for a set of multiple messages..

The network only have two nodes (Border Router and a Dongle that publishes messages).
Can you tell what these additional messages are?

Thanks!

[Edvin]

There are different layers of ACKing. As you can see there is a default network Ack, and a Publish Ack. The difference is that the Publish Ack is from a different layer in the stack, and I don't think it is possible to disable this. 

If you would have had 3 nodes, A, B and C. Let us say that A sends a message to C, and the routing is via B. The message requires an application Ack.

If everything works as intended, then A will send the message to B, and B will Ack it. Then B will send it to C and C will Ack it. Then C will send a Publish Ack back to A. It will start by sending this from C to B, and B will Ack that message. Then B will forward that message to A, and A would Ack it. 

If at any point a packet is dropped, it would be retransmitted, as long as it doesn't pick up the Ack. However, if the message is lost between B and C, then A would wait for 5000ms, and if it didn't receive the Publish Ack before that, it would retransmit the original message to C (via B).

Hopefully, that didn't confuse more than it explained.

Best regards,

Edvin