consistance in ble data transmission

[srinivasa m]

Hello Everyone,

Is it possible to achieve BLE data transmission consistency like there are central and server? The server (nrf52832) reads the GPIO state change and sends it to the client. 

Here, I achieved the functionality of reading the gpio state change and sending it to the client once the connection is established. 

here state change from 0 to 1, sending both. if the button is pressed the server sends '0' and if the button is released server sends '1'. Here '0' transmission is important. 

here for every button press '0' transmission is important. for transmitting data(0) from server to client it is taking 47ms time. i tried for 10 times. but it taking 42ms,44ms,45ms,48ms,41ms like from 41ms to 48ms it is taking to send from server to client. 

here if the first sample takes 47ms time from server to client, is it possible to maintain the same time for the remaining 10 samples? we are sending one sample at a time. for every sample it takes different time. is it possible to maintain same time.

kindly help on this to tackle this issue.

Best regards,

Srinivasa M 

[Edvin]

Hello,

Sorry for the late reply. 

Are you using the nRF5 SDK (e.g. in Segger Embedded Studio, Keil or IAR)? Or are you using the nRF Connect SDK (NCS)?

We do have a sample called Led Button Service (LBS). The path to it depends on whether you are using NCS or the nRF5 SDK. What it does is that it transmits the button press on one device to the LED on the connected device, and vice versa. 

Regarding the timing. I suspect you are using the nRF5 SDK, which by default has a debounce on the GPIO's button handler of roughly 40ms. Then depending on your connection parameters, any queued message will be sent on the next connection event. So if your connection interval is 7.5ms (which is the minimum connection interval, according to the BLE specification), then it will take 0-7.5ms to send the message, depending on how much time is left for the next connection event, occuring on every connection interval. 

By the way that you write, asking if it is possible to have the same time for 10 samples, it sounds like you are trying to bit-bang something. Is that correct? If so, what protocol are you trying to bit-bang?

Perhaps it is better to measure the sequence that you want to send, and then send it as a byte array to the connected device instead?

Best regards,

Edvin

[srinivasa m]

Hi Edvin, 

Thanks for the response. I am using nRF SDK and Segger Embedded Studio. As per my requirement, I have to send the data instantly so that only I can run my end device. If no instant data is sending, then the end device will not work.  if the server sends 1 to the client with a time of 40ms and after 5 seconds the server sends 1 to the client with a time of 48ms.  Here we can see that there is an 8ms latency is there. 

for better understanding, I have attached the image below. kindly review and suggest the best solution to achieve the task.

I

Thanks,

Srinivasa M

[Edvin]

I see. There is a minimum connection interval of 7.5ms in Bluetooth Low Energy. So if you queue up a packet, there is no way of knowing whether it will be sent in 0.5ms, 3ms, or 7.5ms, or even a little more, if it was too close to the next connection event, and it sees it will not be able to queue it in time, it will be scheduled for the next connection event.

Some ways to work around this:

1: You can reduce the latency in the first place. Instead of using the button handler, which has a built in de-bounce, which is basically a timer that waits for a given amount of time, and checks again whether the button is still being pressed, you can use the implementation from the SDK\examples\peripheral\pin_change_int, which will give you the event "immediately".

2: You could use the radio notification feature, which you can use to set up events to trigger X time before the radio events. However, this will only work if you have one active connection, and don't do any scanning or advertising, as it will not tell you what kind of event it is. Let me know if this is interesting, and I can find the guide on how to set it up. (I was looking a bit now, but I could only find an older version, that will not work with the later nRF5 SDK versions, but I can dig more if that is interesting). 

Do however note that this can be used to e.g. send something like (it was 3ms since the pin was toggled), and then the other device could subtract that from an offset. But there is still no guarantee that the initial packet is picked up, or if it was lost due to noise. If a packet is lost, it will be re-transmitted the next connection interval, but the receiver can't tell whether this was a retransmission or not. 

So unfortunately, there is no straight forward way to do what you are trying to do. Are you measuring a pulse width? how long is it between the pulses? One option is to measure the distance between two pulses, or the amount of time it was high, and send this as serial data over BLE. Another is to not use BLE at all, but instead use ESB (Enhanced shockburst), but that is proprietary radio, and doesn't do automatic ACKing and retransmissions, like in BLE, so this is something you would have to implement if you go down that route.

Best regards,

Edvin

[srinivasa m]

My end application works only when there is a 0 to 1ms deviation. If BLE is not supported, how can I achieve this with radio notifications and ESB?

kindly suggest the best solution.

[Edvin]

I would say that it may work if you use radio notifications and BLE, but not really, because if you experience packet loss and retransmissions, then the data will be one connection interval late, and there is nothing in the application that can tell you whether it was a retransmission or not. 

Anyway, in order to set up radio notifications, you can follow this guide/blog, in case you want to look into it:

 Radio Notification 

However, if you want to look into ESB, you can check out the example in SDK\examples\proprietary_rf\esp_prx and esp_ptx. 

Note that there is no ACKing in this protocol, so if you want that, this is something you need to write yourself, if you want to make sure that packets that are not received correctly will be re-transmitted. There are many approaches here. You can echo back what you received, and have the transmitter retransmit if it doesn't hear anything in return, or you can write a CRC check.

Actually, looking into this, there seems to be some sort of acknowledgement on the low_power esb. At least the light on the transmitter doesn't change if I turn off the receiver. 

I don't know how sensitive your application is with regards to packet loss. Does it matter if you loose one packet/pulse? How about the need for two way communication? Do you transmit anything back?

Best regards,

Edvin