nRF52832 notify every 20ms at 50 meters

[StephaneJ]

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

[MartinBL]

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

[StephaneJ]

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

[StephaneJ]

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

[AmbystomaLabs]

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.

[MartinBL]

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

[StephaneJ]

Ok, should I use the sd_ble_gap_tx_power_set like in the ble_app_proximity example ? I will give it a try

[MartinBL]

Yes, that is correct. Just remember to use it after you have initialized the Softdevice. Otherwise your setting will be overwritten and set back to 0 dBm. 

[StephaneJ]

Still got  <error> app: ERROR 19 [Unknown error code] for sd_ble_gatts_hvx function as soon as I am > 5 meters.

sd_ble_gap_tx_power_set doesn't change my results.

Tw power -> RSSI :

• -40 : -90dBm
• -20 : -80dBm
• -16 : -75dBm
• -12 : -67dBm
• -8 : -64dBm
• -4 : -60dBm
• 0 : -55dBm
• 3 : -55dBm
• 4 : -51dBm

[StephaneJ]

I was able to reach little less then 20 meters just by changing the connection interval max from none to 20ms so I guess this is more important than I thought.

I have a question about it. I use a timer, every 20ms it send data with a call to sd_ble_gatts_hvx.

How should the connection interval configured for that ? Does the connection interval (time between when it accepts connection?) needs to be synchronized with the timer to avoid trying to send when the connection interval is not "ready".

For now I have min and max connection interval set to 20ms (no for fewer since I want to send 1 data every 20ms right ?).

Thanks for the clarification

[MartinBL]

sd_ble_gap_tx_power_set doesn't change my results.
Unless you do your measurements in an RF test chamber, then measurements like these aren't going to be very accurate. But in your list one can obviously see that the RSSI changes when you change the TX power, so at least you know that you are setting the TX power in the correct way. 

The connection interval defines how often the peripheral and central turn on their radio to talk to each other. So in your case, every 20 ms there is what we call a connection event. This event is by default 2.5 ms long (but this can be increased). This 2.5 ms period is called the connection event length, and the two devices can exchange as many packets as they want within this period. Hence, you can potentially send many short notifications (or one long one) in each connection event. So in other words, you don't need to synchronize your timer and the connection interval. The Softdevice will handle buffering of your notifications.