10 Replies Latest reply on Jun 16, 2017 9:57 AM by epr_1639216

    Yet another Tx power question

      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 



        • 1. Re: Yet another Tx power question

          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.

          • 2. Re: Yet another Tx power question

            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



            • 3. Re: Yet another Tx power question

              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.

              • 4. Re: Yet another Tx power question

                Thank you for feedback, much appreciated

                • 5. Re: Yet another Tx power question

                  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.

                  • 6. Re: Yet another Tx power question

                    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 ?





                    • 7. Re: Yet another Tx power question

                      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.

                      • 8. Re: Yet another Tx power question

                        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

                        • 9. Re: Yet another Tx power question

                          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).

                          • 10. Re: Yet another Tx power question

                            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!



                            • 11. Re: Yet another Tx power question

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


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