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.

[srinivasa m]

Hi Edvin,

Thanks for the suggestion. I have used ESB and radio transmission. With ESB, I achieved 3ms, and with radio transmission and reception, I achieved 400us. 

Is it possible to achieve less than 15us? that will give more accurate results.

I observed that there is inconsistency in data transmission and reception. If 10 samples are there, every sample will be made at different times, like 246us, 330us,270us, and 400us. Is it possible to maintain a constant time of 400us for all samples?

[Edvin]

That is a tough ask. It depends on what the chip is doing when the interrupt occurs. We don't have anything that supports this directly, so if you are not able to acheive it using using the raw radio, then it is difficult. If your application is doing anything else, you can try to disable that, but I don't think there is a chance that you can get it consistently within 15us. 

What exactly are you trying to transmit? Are you bit-banging some protocol? 

BR,

Edvin

[srinivasa m]

My task is to control the LED at the receiver by pressing a button on the transmitter. When I press the button, the transmitter sends 0x05 data to the receiver, and when I release the button, the transmitter sends 0x04 data to the receiver. if 0x05 is received at the receiver end the LED turns ON and if 0x04 is received at the receiver end LED turns OFF. Here the LED turn-on time is important. when I press the button the data 0x05 is transmitted and received at the receiver time is important. The total time this process is taking is 400us. some times it is taking 230us, 330us, 320us, 380us within 400us. why this time is changing every instant of the button press? 

is it possible to make it consistent like maintaining the same time at all the instants?

If I achieve this consistency I can use this concept in my end application. In the end application instead of LED and Button some switching modules can use. 

At both ends nRF52832 is used.

[Edvin]

I am not sure. If you upload your application, I can have a look. What you can try is to replace the bsp with what you find in the examples\peripheral\radio and instead of this, use the direct gpio interrupt that you find in examples\peripheral\pin_change_int example. This will bypass the whole button handler module, and use the pin interrupts directly. Then create the payload for your packet in the interrupt handler. Note that this doesn't have a debounce, so it may be that you see several interrupts when pressing the button on the DK, but if your intention is to not use a button interfaced by a human, but to send some signal, then you would want something like this, without a debounce.

BR,

Edvin

[srinivasa m]

can we have private conversation