• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 51 subscribers
  • Views 2313 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Meaning of RSSI in Advertising Messages

Jeremy Jass
Prodigy 125 points
Other Parts Discussed in Thread: CC2541

Working with a CC2541 on a project that started as the SimpleBLECentral example project.  In the simpleBLECentralEventCB callback, whenever a new tag is detected the GAP_DEVICE_INFO_EVENT event is fired.  Although not used by the simpleBLEAddDeviceInfo function, and not stored in the gapDevRec_t structure that normally stores the list of discovered tags, within 'pEvent->deviceInfo.rssi' there is still a value on each GAP_DEVICE_INFO_EVENT event.  I modified simpleBLEAddDeviceInfo and the gapDevRec_t structure so now both address and rssi information is stored for all tags found during discovery.

This I got from reading other similar posts, but this is also where I'm now stuck.  The rssi readings seem to be at best wrong, and at worst a random number generator.  I'm getting numbers between 0xF5 (-126) all the way up to 0x26 (36) from the same advertiser to the same CC2541 without either of them moving at all.  Additionally, the numbers don't fall in any intelligent distribution between those extremes except they do tend to clump up on a dozen or so values that keep coming up.

How does the CC2541 actually calculate the rssi value, and what is the physical significance of the rssi from an advertising message found in the gapDeviceInfoEvent_t structure?  Is there a better way to get rssi or am I perhaps doing something wrong?  We have been hoping that by examining rssi readings we could exclude advertisers beyond a certain range or not in the room, but so far it's proving difficult.

Thanks

  • 0
    Guru 22270 points

    Hello Jeremy,

    The RSSI should provide you with a reasonable accurate value.  If you look at the Keyfob example, or even with the Sensortage, you can see consistent RSSI values as you move the device away from either the iOS device or the Dongle.

    Look at how the RSSI is being initialized and read by the KeyFob and SensorTag source code.  Follow that example to get the proper way to calculate the signal value.

    Thanks,

  • 0 in reply to Greenja
    Prodigy 125 points

    I believe the KeyFob and SensorTag projects are both peripheral device projects where I'm trying to set up the CC2541 as a central device.  Additionally, I believe most if not all of the TI example code that touches RSSI does so from the environment of an established connection.  In our application, the advertising devices just advertise (beacon) and never establish a connection with the TI chip.  The TI API does include an RSSI value in the gapDeviceInfoEvent_t structure that is returned whenever a new advertiser is discovered, I just don't know if I'm misusing that variable or the accuracy of that RSSI reading is just really low.

    Thanks

  • 0 in reply to Jeremy Jass
    Guru 22270 points

    There are some post on setting up a beacon and reading iBeacon values in the forum.  Here is one example that may be helpful to you.

    http://e2e.ti.com/support/low_power_rf/f/538/p/293551/1047923.aspx#1047923

    Thanks,

  • 0 in reply to Greenja
    Prodigy 125 points

    Right idea, just roles reversed.  We're using another BTLE chip as the beacon (Nordic nRF8002) and the TI CC2541 is trying to be the "app" in the iBeacon discussion you linked where it listens for beacons and as part of that listening assesses range from RSSI.

    I did download the beacon project and load the hex file onto a CC2541EM board.  When I edited the code on our CC2541 that is listening for advertising messages so that it didn't filter the results at all it was able to see the CC2541EM running the beacon code, but similar to when looking for our own beacon tags the measured RSSI value was very inconsistent.

    Thanks

  • 0 in reply to Jeremy Jass
    Prodigy 125 points

    Found our old CC2541-Dongle and running the packet sniffer utility I'm able to see all the advertising messages coming from our tag, and encouragingly the sniffer reports a quasi-stable RSSI value that changes with the distance between the tag and the dongle.

    So tags, beacon mode, and advertising is all working fine, it's just on the CC2541 when I try to retrieve the RSSI value from each received advertising message.  Whenever a new tag is found, "GAP_DEVICE_INFO_EVENT" is fired which has a reference to a "gapDeviceInfoEvent_t" structure which contains an int8 field called "rssi".  The value in this field swings wildly and has no apparent correlation to the rssi value reported by the packet sniffer.  Am I looking at the wrong field, looking at the field wrong, or maybe just not getting the field value reported back to the server correctly?

  • 0 in reply to Jeremy Jass
    Prodigy 125 points

    To conclude this thread .. I'm an idiot.  gapDeviceInfoEvent_t.rssi that is returned with each new discovered advertiser does contain the correct rssi value and it is reasonably accurate.  The error in my code was a pointer/referencing issue that was responsible for my entire problem.  Corrected and everything is working OK now.