Reporting the RSSI from my REED

[Michael Simpson]

I want to be able to report the RSSI from my REED

I have tried using otPlatRadioGetRssi to return "most recent RSSI measurement".

I am testing with only my OTBR RCP and one REED.

otPlatRadioGetRssi is returning values around between -81 - 85 which I think is too low considering the distance of approx 20 meters and 17dBm transmit level.

int8_t rssi;

rssi = otPlatRadioGetRssi(otrGetInstance());

otCliOutputFormat("RSSI: %d\r\n", rssi);

If I run "neighbor table" from ot-ctl, it reports a much more believable figure of -62

| Role | RLOC16 | Age | Avg RSSI | Last RSSI |R|D|N| Extended MAC     |

+------+--------+-----+----------+-----------+-+-+-+------------------+

|   R  | 0xe000 |  10 |      -62 |       -63 |1|1|1| a26bb2c2f6248961 |

When I move the REED right next to to the RCP, "neighbor table" reports -26

| Role | RLOC16 | Age | Avg RSSI | Last RSSI |R|D|N| Extended MAC     |

+------+--------+-----+----------+-----------+-+-+-+------------------+

|   R  | 0xe000 |  15 |      -39 |       -26 |1|1|1| a26bb2c2f6248961 |

but otPlatRadioGetRssi continues to report between -81 - 85

Can someone please advise what I might be doing wrong?

 

[Sébastien Parent-Charette]

Hi Michael,

If I remember correctly you were using some EFR32 platforms previously. Are you still using a EFR32 MG12 P432 F1024 GL125 for this project or it with a different part/board? If different, please let me know which one.

As for the value reported by otPlatRadioGetRssi, it seems like you are indeed getting values that don't match the other data available in your network. I am investigating this and will get back to you with more information soon. Do you have other information related to your setup that may be relevant?

Sincerely,

[Michael Simpson]

Hi  Sebastien

I have Silab dev board BRD4001A using EFR32MG12P432F1024GL125, but have developed custom hardware for my RCP and REEDs using a Silab MGM12P32F1024GA module.

Using Simplicty Studios 5 with SDK: Name: Gecko SDK Suite: Bluetooth 3.1.2, Bluetooth Mesh 2.0.2, MCU 6.0.2.0, Micrium OS Kernel, OpenThread 1.1.2.0 (GitHub-5c2ad91cf), Platform

Version: 3.1.2

I am still using Thread 1.1

Important to note that ot-ctl "neighbor list" RSSI figures are more believable and change with distance between RCP and REED, whereas otPlatRadioGetRssi is returning values around between -81 - 85, regardless of distance between RCP and REED.

I'm not sure what else I can tell you relevant to this problem, but if you need anything more, please ask.

Regards

Michael

[Jonathan Hui]

otPlatRadioGetRssi() is intended to return the most recent RSSI reading, not the most recent RSSI for a received packet. This makes otPlatRadioGetRssi() useful for monitoring channel activity. OpenThread's channel monitor feature makes use of this capability.

You can find the EFR32 implementation of otPlatRadioGetRssi() in the openthread/ot-efr32 repo in src/src/radio.c.

If you want to obtain the RSSI for received packets from a given neighbor, the child/router/neighbor tables are where you want to retrieve that information.

--

Jonathan Hui

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/848bdfeb-77db-4650-87da-bfcd7f7b1b32n%40googlegroups.com.

[Michael Simpson]

Hi Jonathan

I am not sure what you mean by "the most recent RSSI reading, not the most recent RSSI for a received packet", I only have one RCP and one REED so I thought they would be the same.

Can you please elaborate? Are you saying the latest RSSI could be the signal when nothing is transmitting which is why it is so low? What would be the purpose of this?

Is there an API function to pro-grammatically read the RSSI for a received packet eg from the neighbor table. If this is complex, can you point me to some sample code which shows this in use. 

Thanks

Michael

[Jonathan Hui]

On Mon, May 31, 2021 at 10:13 PM Michael Simpson <michae...@gmail.com> wrote:

I am not sure what you mean by "the most recent RSSI reading, not the most recent RSSI for a received packet", I only have one RCP and one REED so I thought they would be the same.

Can you please elaborate? Are you saying the latest RSSI could be the signal when nothing is transmitting which is why it is so low? What would be the purpose of this?

Yes, the radio can measure RSSI when it is not actively receiving a packet. The radio typically uses this function to perform Clear Channel Assessment (CCA) before transmitting a packet. The radio also uses this feature to support Energy Scan, which is useful to determine other (potentially non-802.15.4) RF activity on the channel and estimate the noise floor.

 

Is there an API function to pro-grammatically read the RSSI for a received packet eg from the neighbor table. If this is complex, can you point me to some sample code which shows this in use. 

You can retrieve the RSSI for a given received message using otMessageGetRss().

--

Jonathan Hui

[Abtin Keshavarzian]

`otPlatRadioGetRssi()` asks the radio to take a RSSI sample immediately and report it (repot what it sees over the air). It is useful for tracking the noise/interference on the channel (e.g., as Jonathan mentioned used by "channel monitor" feature). 

When a frame is received, the RSSI for the received frame is also tracked.

Note that a longer message (IPv6 message) may be broken up into multiple fragment frames that are sent over the air. The value from `otMessageGetRss()` represents the *average* RSS of all received frames that are assembled together to form the (longer) received message.

Per neighbor, the average RSSI of the received frames is also tracked (along with the RSSI of the last received frame). These can be retrieved from child or neighbor tables.

Hope this helps,

Abtin.

[Michael Simpson]

Hi Jonathan and Abtin

Thank your for this information, just what I needed.

If I could make a constructive criticism, the documentation on the API is very thin listing the parameter names and type with very little by way of description. For new Thread developers, it can be difficult to find what you are looking for and understand the functionality of the parameters.

Regards

Michael