Yet another Tx power question

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

The default Tx power is set to 0 dBm in the BLE component

   

Are there known calibrated RSSI valules @ 1 meter ( or 0 meters) for each dBm step?

   

Or do  they need to be calculated dynamically by the client application?

   

If so, are there any pointers to samples/documentation?

   

Thank you 

   

Andy

0 Likes
11 Replies
Anonymous
Not applicable

According to wiki: https://en.wikipedia.org/wiki/DBm

   

RSSI values are mainly a relative strength value from what I've seen. The dBm steps will be a proportional increase in power, which should theoretically be a proportional increase in signal strength for RSSI at specified distances. Keep in mind that, since signal strength decays by 1/R^3 depending on interference, increasing the signal strength by 3 dBm (double) will not affect the strength much at larger distances.

0 Likes
Anonymous
Not applicable

The reason for the question is that the RSSI reported by  CYBLE-022001-00  that I'm using , is lower than I expected

   

At a distance of  less than a meter from the device, the CySmart Android app reports RSSI between -65  and -75 

   

I was expecting it to be in the -40 range. When I increased the power to 3 dBm it got a bit better (mid -50s was the strongest) but never in the 40s

   

Are my expectations unrealistic?

   

Thank you

   

Andy

0 Likes
Anonymous
Not applicable

I wouldn't say expecting specific values at specific distances is unrealistic, but I would say expecting the scale to be set to some standard is probably unrealistic. As the RSSI is really more for determining the differences in signal strength between multiple devices, or detecting an increase/decrease, not expecting a specfic range/value as much.

   

Keep in mind that each step in the RSSI is not linear (iirc), and thus an increase to -50 from -65 is a much better signal than it seems. I have no idea what to expect for RSSI values. Really, I would just use it as a sliding scale rather than fixed values.

   

I would say your expectations aren't unrealistic, but I'm not sure why you would expect -40's as opposed to just lower values.

0 Likes
Anonymous
Not applicable

Thank you for feedback, much appreciated

0 Likes
Anonymous
Not applicable

You're welcome; Sorry I'm not able to give a better answer 🙂 I suppose if I had time to play with the PSoC 4 modules and see their RSSI values with distance I could give better information, but based on the definition of RSSI it didn't seem like it would yield better information with testing. With cellular devices I would run into RSSI values up to -100, but since the RSSI index is unique to each hardware manufacturer's own customized values for the RSSI, it doesn't correlate well enough to use for comparison.

0 Likes
Anonymous
Not applicable

Another question: It is my understanding that RSSI is part of the advertising packet (last byte of it)

   

Who puts it there? what logic is used ?

   

Thanks

   

Andy

0 Likes
Anonymous
Not applicable

That doesn't ring any bells; I don't think the RSSI is automatically appended to the packet from the sending side. It could be attached at the receiving side to help you understand the order of distance/signal strength between packets?

   

There is a TX Power Level setting you can transmit with the advertisement packet under the BLE component configuration->GAP Settings

   

Afaik, the RSSI is a receiver value, not something that is transmitted with wireless packets.

0 Likes
Anonymous
Not applicable

BLE_StackGap.h  declares a struct  CYBLE_GAPC_DIRECT_ADV_REPORT_T where the last value is rssi with a comment 

   

/** Rssi of the responding device.
     * Range: -127 <= N <= +20
     * Units: dBm 
     * N = 127 -> RSSI not available
     */

   

This implies that the rssi is placed in the advertising packet by the device that sends it. Although in my case the BLE is set up for undirected advertising so maybe this does not apply

   

I looked at   source code of some Linux tools that use bluez BLE library - they also treat the last byte in the advertising packet as the rssi value

0 Likes
Anonymous
Not applicable

Here is the full section of relevant code/comments: 

   

/** Direct Advertising Report received by GAP Central */
typedef struct
{
    /** Buffer containing Random Device Address of Scanner (local device)
     * This is the address the directed advertisements are
     * being directed to.
     */
    uint8                       * localBdAddr;

   

    /** Buffer containing Device Address of advertiser sending the directed advertisement */
    uint8                       * peerBdAddr;

   

    /** Device Address type of advertiser sending the directed advertisement */
    CYBLE_GAP_ADV_ADDR_TYPE_T   peerBdAddrType;

   


    /** Rssi of the responding device.
     * Range: -127 <= N <= +20
     * Units: dBm 
     * N = 127 -> RSSI not available
     */
    int8                        rssi;

   

} CYBLE_GAPC_DIRECT_ADV_REPORT_T;

   

At the very top comment it says: "...received by Central", I would take this to imply/mean that the structure declared here is used for a Central device to receive a Directed Advertising Report from another device (thus, it is in a receiving mode). This is the structure type passed to the BLESS event callback handler that you register upon starting the BLESS with CyBle_Start(Callback);

   

So, I don't think they are actually sending the RSSI in the advertisement packets, I think they are attaching the RSSI value to the end of packets they receive while scanning in Central-BLE mode. This specific struct is labeled as Direct Advertising Report, so my guess would be it is only applicable either when the device is doing directed scanning, or when a Peripheral device sends a Directed Advertisement to Central device (which it then calculates and appends the RSSI value for).

0 Likes
Anonymous
Not applicable

There is also CYBLE_GAPC_ADV_REPORT_T structure which  has the rssi field .

   

It is used  in the Observer sample ( day 10 )  where it prints out the packet contents ( including rssi ) without checking if this was a directed vs undirected advertising packet. So my guess is that rssi  is always added by the low level code

   

The question remains:

   

How is it  calculated?

   

Thank you for your feedback!

   

Andy

0 Likes
Anonymous
Not applicable

This page should help: http://www.cypress.com/knowledge-base-article/rssi-estimate-distance

   

And you're welcome! Always glad to help people out 🙂

0 Likes