This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52832 notify every 20ms at 50 meters

Hi,

My setup :

  • nRF52832
  • Soft Device S132 v5
  • SDK14.2

My use case involve me to send data to to a central device at 50 meters. I need to send only a small data : one int16_t. I have a timer set up to do a SAADC conversion then send data (sd_ble_gatts_hvx) every 20ms.

It's working great on close range. But as soon as I am further than 5 meters I got a NRF_ERROR_RESOURCES.

Since it's not really a problem if I miss few data, my first try was to ignore it :

/* It's not a problem if we loose few data */
if(retval == NRF_ERROR_RESOURCES){
  retval = NRF_SUCCESS;
}

return retval;

It work great meaning that it does crash the board now and it keep sending data but at a very low speed and multiple packet at a time it looks like on the nRF Connect app log.

So I know that this error means that the queue is full. But why is it related to the distance from the central since it's a notification so we do not expect an acknowledgment or anything!?

Also when I go to ~25 meters (outside) not only I have very slow notification update on my central, but I got disconnect (Timeout).

What are the optimizations I can do to increase my range and keep my transmission speed constant?

Thanks

Parents
  • So I know that this error means that the queue is full. But why is it related to the distance from the central since it's a notification so we do not expect an acknowledgment or anything!?
    As points out you probably have a HW problem. Notification packets don't require acknowledgments from the application layer, but all BLE packets are actually acknowledged on the Link Layer. If your notification packet doesn't successfully reach the peer, it is retransmitted over and over again until the packet is either received successfully or until the supervision timeout times out and your device disconnects. This is probably why your queue fills up and why your link eventually breaks when you move out of range. 

Reply
  • So I know that this error means that the queue is full. But why is it related to the distance from the central since it's a notification so we do not expect an acknowledgment or anything!?
    As points out you probably have a HW problem. Notification packets don't require acknowledgments from the application layer, but all BLE packets are actually acknowledged on the Link Layer. If your notification packet doesn't successfully reach the peer, it is retransmitted over and over again until the packet is either received successfully or until the supervision timeout times out and your device disconnects. This is probably why your queue fills up and why your link eventually breaks when you move out of range. 

Children
  • The designer of the board tells me that there is no HW problem, he is used to work with nRF52 and he advised me to do an antenna tuning to take into account the materials and package surrounding my custom board. How am I suppose to do that?

    Also, he tells me that we can optimize the software to the detriment of the battery autonomy to increase the range. Do you know what is he referring to ?

    Thanks for your help

  • Just to summarize everything:

    1. Both Martin and I agree that you are facing a hardware problem.

    2. 50 meters (outdoors) is really the limit for 4dBm BLE. Your assertion that you can do 100+ meters is drawn from devzone comments that refer to two devices "seeing" each other and maybe maintaining a link with very low data rate. Also BLE performance will degrade if there is a lot of local wifi or other 2.4GHz traffic. 100+ meters can only be had with perfect conditions.  No other RF traffic, no trees, bushes, nothing in between, well designed hardware placed high off the ground. 

    3. If you really need 100+meters you will either have to use a high power ble device (ie, 52832 with power amp) or use the 52840 with has 8dBm output and coded phy (BLE long range). Using coded phy and 8dBm you will easily get 100-200 meters outside.

    4. Your RSSI numbers are consistent with a normal design. Again, the pattern will not be isotropic so you will need to figure out the optimal positioning of your devices.

    5. Just because the RSSI is good does not mean the modulation is good nor that the receiver is good. If you have schematics and layout info for your custom board, we can review to look for errors.

    6. Tuning the antenna as your designer suggested, takes an RF engineer and a vector network analyzer.  It is not done without the right tools and training.  Sorry.

    Depending on the requirements of your data integrity, I would suggest you switch to a UDP style of data transmission. ( ie, you send out packets and maybe they make it and maybe they don't.)  This way you won't bog down the phy with retransmissions.  This is outside of my sphere of expertise.  Perhaps Martin can guide you.

    If need verified transmission of data, then you should switch to the 52840 and do BLE long range at 8dBm.  This will simplify your work as you will easily get 100+ meter performance.

  • Hi Richard,

    First of all, thanks for your detailed answer, I appreciate you take the time to explain it to me.

    Just to clarify, I "just" need up to 50 meters. But I become less and less optimistic about it and according to what you say, I would be happy for 30 meters ! Just the time for me to find a better solution.

    I can share with you or both of you my hardware design but it would need to be private for obvious confidential reason. I don't know how we can do it.

    I could definitely try UDP style transmission if  can guide me, as a first try.

    If this still fail, another solution for me would be to stop the real time "analysis" and store data internally, hoping that I have enough memory because this was not necessarely designed for this use case.

  • You can send me a PM with board info for review.

    Also, Nordic have a similar system set up.  Just search in the devzone for info on how to do this privately.  I think the process changed with the new website.

    Sorry I can't help you on sending packets without acknowledgment/retransmission.  The software layers really isn't my thing. 

    Since you just need to send 16 bits, you could easily use the beacon app to send the data.  There is plenty of room if you use major/minor (total 32 bits). Beacons by definition don't have an ack since it is non-connectable.  This could be a easy way to solve your issue. At 100 meters, I think you would get through about 20% of your beacons and close to 100% at 50 meters. Not sure how you would handle encryption if you are worried about someone seeing the data or spoofing your setup.

  • If you have changed or added packaging the designer is absolutely right. A device should always be tuned after it is placed in its intended enclosure. Nordic offers free tuning and if you want I can give you an address you can ship it to and we will do the tuning in our lab. 

    He could be referring to the TX power. The default TX power (at least in our examples) is 0 dBm and you can try to increase this to 4 dBm. That should increase your range, but the radio will also consume ~40% more power: Radio current consumption (Transmitter)

Related