Android Question BLE speed

tonga

Member
Licensed User
Longtime User
Hi to all,

I'm working about Ble_example that is connected with a MCU. I see, using Logging of received data, that the data, sent in regular interval of time from MCU, are received by tablet not in regular mode but are received in bursts, sign that many of these are lost. There is a mode to speed up the reciever?

Thanks
 

SteveTerrell

Active Member
Licensed User
Longtime User
Hi to all,

I'm working about Ble_example that is connected with a MCU. I see, using Logging of received data, that the data, sent in regular interval of time from MCU, are received by tablet not in regular mode but are received in bursts, sign that many of these are lost. There is a mode to speed up the reciever?

Thanks

I have seen some quite slow data rates when there is a lot of interference in the environment. That interference can include WiFi as well as BLE.
Irregular timing could indicate that a lot of BLE re-transmissions are happening because of interference.
 
Upvote 0

tonga

Member
Licensed User
Longtime User
Hi SteveTerrell,
I think you can rule out this hypothesis because, in the same environment and with the same components, I modified an app with Android Studio and using this app the update of read values is much faster.
 
Upvote 0

SteveTerrell

Active Member
Licensed User
Longtime User
Hi SteveTerrell,
I think you can rule out this hypothesis because, in the same environment and with the same components, I modified an app with Android Studio and using this app the update of read values is much faster.

Ok, my only other thought is that if you are running with debugging the Rapid debugger is relatively slow compared with the legacy debugger in this sort of situation so be sure to test under Release.

How often is the data sent and how long is the data block? Are you detecting the block terminator yourself or using AsyncStreams?
 
Upvote 0

tonga

Member
Licensed User
Longtime User
The response speed is the same even in release mode.
To detect the received data I use the subroutine "Sub Manager_DataAvailable (ServiceID As String, Characteristics As Map)" of "Starter".
It would be useful to send data every 10-20ms
 
Upvote 0

SteveTerrell

Active Member
Licensed User
Longtime User
The response speed is the same even in release mode.
To detect the received data I use the subroutine "Sub Manager_DataAvailable (ServiceID As String, Characteristics As Map)" of "Starter".
It would be useful to send data every 10-20ms

Presumably you assemble the data block with something like this (the 6e400001 and 6e400003 is specific to my app but you probably have something similar)

B4X:
Dim receivedString As StringBuilder
    receivedString.Initialize
    If ServiceId.StartsWith("6e400001") Then
        For index = 0 To Characteristics.Size-1
            Dim cKey As String = Characteristics.GetKeyAt(index)
            If cKey.StartsWith("6e400003") Then
                Dim bytes() As Byte = Characteristics.GetValueAt(index)
                If bytes.Length > 0 Then
                    Dim s As String = BytesToString(bytes,0,bytes.Length,"UTF8")
                    receivedString.Append(s)
                End If
            End If
        Next

Then when you detect the terminator you do something with the data. Could that be taking much time?

If you are dropping characters and the data terminator is constant you could consider getting the AsyncStreams library code to rebuild the message rather than doing it with code like the above.

Sending data blocks every 10-20ms is quite fast especially if there are a number of characters in the data block and you do much processing or screen drawing with the data after it is received.
 
Upvote 0

tonga

Member
Licensed User
Longtime User
Some time ago I used prefix AsyncStream with basic bluetooth, but the speed was about the same as that of now, so I have some doubts on the success
 
Upvote 0

SteveTerrell

Active Member
Licensed User
Longtime User
Some time ago I used prefix AsyncStream with basic bluetooth, but the speed was about the same as that of now, so I have some doubts on the success

Do you use a request - reply system where the data is only sent in response to a request from the app?
 
Upvote 0

tonga

Member
Licensed User
Longtime User
After the pairing the MCU send data continuosly. I insert a seekbar that follows the position of a capsense slider. I try to use a timer to monitor the data avalaible: nothing. It seems that a good part of data passes away...
 
Upvote 0

SteveTerrell

Active Member
Licensed User
Longtime User
After the pairing the MCU send data continuosly. I insert a seekbar that follows the position of a capsense slider. I try to use a timer to monitor the data avalaible: nothing. It seems that a good part of data passes away...

Try slowing the MCU by putting bigger and bigger gaps between data blocks. If you switch to legacy debugging you can log the data as it arrives at data available.
What format is the data block? a number of bytes (characters) followed by a terminator?
 
Upvote 0

tonga

Member
Licensed User
Longtime User
Now I see another problem: if I use manager.WriteData to change the state of a led I see that I can drive that led continuosly in the MCU, but it stops the data received in Android device. In logs I see"retries" until 4 times
 
Upvote 0

Similar Threads

Top