BLE stops sending values when input data moving too fast

Bugs and Other Issues
, , ,
1

Hi !

I am currently trying to develop an app that should act as a GamePad controller sending data (such as Joysticks and toggle switches) through BLE to an Arduino Uno r4 WiFi.

The app is working pretty good except regarding one point : when I start moving one Joystick in a circular motion without any "stops", the received data on the Serial Plotter are blocked to the last sent values until I stop rotating it.

Here is what I tried to troubleshoot the problem :

  • At first, I printed the values of the joysticks on the screen every 100ms to see if these values where blocked until I stop rotating, which is not the case : the values were correctly updated almost instantly.

  • Then, I tried to send fixed ramp values to see if the BLE module was "blocked" during the fast rotation of the joysticks, which was not the case : when moving the joysticks fast, it took a bit more time to receive the whole ramp, but it was still working.

  • After this, I told myself that maybe the "BLE.WriteBytes" function wants input data that are "stable" and so wait for the data to stabilise before sending it. To test this assumption, I created buffer variables that, every 100ms, take the values of the actual values. Even with this strategy, the problem kept persisting.

  • Finally, I tried to add a 100ms delay between the "BytesWritten" event and the "WriteBytes", such that the whole system has a bit more time to breathe and is not constantly sending data through BLE. Once again, it didn't fix the problem.

Here is a screenshot of my BLE callback :

Capture d'écran 2025-01-19 162613
Capture d'écran 2025-01-19 162613483×722 95.4 KB

I join aswell the whole aia file.

Arduino_GAMEPAD_v2 (1).aia (339.0 KB)

Thanks a lot for anyone taking time to read this post !

2

The problem is at the last branch of this event:

blocks
blocks1958×2788 717 KB

Of the 4 elseif branches, the first 3 have associated flags to shut off the flow of Bytes Written.

The 4th doesn't, so it always sends, and always gets a response triggering another send.

3

This behaviour was actually intended :
The flags and potentiometers are supposed to have a higher priority and if none of them has been updated then the joystick message is sent by default. This allows to have a continuous stream of data (which is maybe not the best idea?)
I don't really see the link betwen the absence of flag and this problem of joystick moving too fast, and especially how to solve it.

Thank you very much for the answer !

4

Could someone explain me how to solve the problem?

5

ANother mitigation tactic for mismatched transmission and reception rates is to use lists as queues.

Each queue would be composed of newly added data waiting to be transmitted, with the oldest at slot 1 where it would be removed after receiving acknowledgement of transmission.

You could add one or more Labels showing the length of each queue, as an indication of how long a delay you have reached, like the amusement park signs warning park goers of their expected wait times on line around the popular roller coaster.