Weak BLE connection causing dropped ADC reads.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
chsi_1572801
Level 3
Level 3
First like received

Hello

   

I am working with the CYBL11573-56 and have come across an issue that I would like to get some feed back on. My system is using 4 of the ADC channels to read accelerometer X, Y, Z axis and battery level info. The system reads and transmits the XYZ data over the BLE every 20 ms through a notify characteristic. When the BLE signal gets weak (Below -75dB RSSI)  I start seeing missed ADC reads and it looks like the BLE stack is blocking the ADC callback. Has anyone run into anything like this?  

   

Thanks,

   

-Chris  

0 Likes
1 Solution
chsi_1572801
Level 3
Level 3
First like received

Hello

   

I just wanted to write a closing post to this thread. I was able to solve this problem by moving my ADC reads from the original polled system to a interrupt based system and use a thread safe single provider single consumer queuing (FIFO) mechanism to manage moving data from the ADC background thread to the main thread. This way if the CyBle_ProcessEvents() function ever blocks for longer that my ADC read period the data is just queued up in the FIFO buffer.

   

-Chris 

View solution in original post

0 Likes
12 Replies
Anonymous
Not applicable

Hi, 

   

Are your ADC reads triggered by an interrupt? If they are, have you tried making that interrupt a higher priority than the BLE_bless interrupt? It should be noted that interrupting the BLE stack can lead to race conditions and other issues, but this might be a decent starting point towards resolving your issue. 

0 Likes

Yes one of the first things I tried was putting my ADC interrupt at the highest priority I have I2S second and BLE is lowest.   

0 Likes
Anonymous
Not applicable

Ok, another thing you can try is increasing your connection interval. The GAP Central has to periodically synchronize with the GAP Peripheral and I suspect that this synchronization is taking a while due to the low signal strength that you described. By increasing your connection interval, you're making this synchronization happen less often, which should reduce the number of ADC readings you miss, but not totally eliminate them. Keep in mind that it is the GAP Central that sets the connection interval, however the Peripheral's maximum connection interval setting also needs to be set high enough to accommodate the connection interval. 

   

Another thing to keep in mind is that -75dbm is a very weak signal, so in addition to your timing issues, its not unreasonable to think that you might run into issues with dropped packets as well. 

0 Likes

Hi Matthew

   

My system writes the ADC samples to a external flash memory as well as sending over the BLE realtime. The design was done that way so that if the connection is lost during the capture phase the data can be resent after the the connection is reestablished. What i didn't count on was BLE taking up all CPU cycles when the connection gets weak. I actually miss stated something because my system actually is polling the adc based on a timer event. The software is written so that I have a 20 ms system heart beat that reads the ADC, processes audio and writes the data to flash. Originally I was only sending the data over BLE after the capture phase was done which worked fine.  It is only now that I am trying to send BLE data as captured that I ran into this issue.

   

-Chris  

0 Likes
chsi_1572801
Level 3
Level 3
First like received

I currently have my GAP peripheral set at connection interval of 10 ms min 10 ms max and slave latency of 100. Are you saying  setting my min and max higher might help?

0 Likes
Anonymous
Not applicable

Hi Chris, 

   

It should help, but it won't eliminate your issue entirely. Just for testing purposes, try setting the min and max connection intervals to their maximum value (4 seconds if I remember correctly).  This way, your capture phase is only interrupted every 200 cycles instead of twice per cycle as you have it now. 

   

Basically, at these low signal levels, data gets lost during the synchronization process. Due to this data loss, the central and peripheral have to send data multiple times to confirm the connection. These multiple attempts take up clock cycles which screws up the rest of your application....well I think that's what's happening anyway...there could be other things in your code causing the issue. If your code isn't proprietary, you might want to upload a zip file of your code so that other users here can take a look at it. 

0 Likes
chsi_1572801
Level 3
Level 3
First like received

Yea our code is proprietary. I can send out sections of it but that's all. It started as the cypress remote control app because of the I2S sound and I2C accel systems but has changed into something very different  over the last year of development. I will try changing my the GAP settings and see what happens. The approach that I am working on now is to have the client just tell the node to stop sending during the capture phase if the signal goes below like -60dB  . If that doesn't work I may have to try  changing to a interrupt /dma driven system. If that doesn't work maybe a simple task scheduler may be in order. Last will be changing to a dedicated hardware solution.  

0 Likes
Anonymous
Not applicable

Hi,

   

Do you have low power modes implemented in code? If so, are you able to see any change if you disable the low power mode?

   

Regards,

   

-Madhu Sudhan

0 Likes
chsi_1572801
Level 3
Level 3
First like received

Hello Madhu

   

I am not using any low power stuff with my application. I have it all disabled. In this design power consumption is not a issue. 

   

Thanks

   

-Chris

0 Likes
Anonymous
Not applicable

Hi Chris,

   

We did not notice this issue when we tested this on our side. Are you using your own board? If so, do you face this issue when you are using our Module eval boards. If you have any of our module eval boards, can you please test using them. I just wanted to make sure this is not a hardware issue.

   

Regards,

   

- Madhu Sudhan

0 Likes
chsi_1572801
Level 3
Level 3
First like received

Hi,

   

We are using the CYBLE-202007-01 module.  This only happens when there is an abrupt change in signal strength but the connection is not lost.  In our application the node  rides in an elevator to measure/capture acceleration and calculate velocity. When connection is lost due to range changes caused by the elevator moving away from the mobile device we just resend the data after  the connection is reestablished and this is working well. Its only when the signal goes from fairly strong to weak quickly that  the BLE blocks longer than the 20 ms sample window and we drop capture data. I am in the process of changing the system from a polled ADC read and flash write system to using interrupts to read ADC data (and possible DMA) and push in on a FIFO. Then if the BLE ever blocks we stop sending over BLE and insure that the FIFO is always written to flash. I am hoping this will prevent any missed ADC reads.  Do you have any thoughts on this approach? 

   

-Chris   

0 Likes
chsi_1572801
Level 3
Level 3
First like received

Hello

   

I just wanted to write a closing post to this thread. I was able to solve this problem by moving my ADC reads from the original polled system to a interrupt based system and use a thread safe single provider single consumer queuing (FIFO) mechanism to manage moving data from the ADC background thread to the main thread. This way if the CyBle_ProcessEvents() function ever blocks for longer that my ADC read period the data is just queued up in the FIFO buffer.

   

-Chris 

0 Likes