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?
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?
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.
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.
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?
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
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.
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...
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?
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