Android Question BLE2 Scan Duration, Retries, Concurrent WriteData

[rwblinn]

Working on a Test App to Control, via Bluetooth, Lego Power Functions Motors using the SBrick.

The BLE2 library v1.35 is used to connect and control the SBrick (Device).
Got a first B4A prototype up-and-running, resulting in several questions:

Question Manager Scan
After Manager.Scan(Null) is initiated whilst the Device is turned off, scan keeps on running.
Is there a way to limit the scan duration e.g. stop f.e. after 10 scanning cycles?

Question WriteData B4J IDE Logentry Retries
When sending data to the Device, the method WriteData logs the number of retries (have checked the BLE2.jar, public void WriteData, entry BA.Log("retries...").
Is it possible to remove the BA.Log entry and use a method to log the number of retries (if required)?

Question WriteData Max Retries
Is it possible to set the number of retries via Manager property instead of the hardcoded max 5 retries?

Question WriteData Max Retries Thread Sleep
Observed that when WriteData max retries (5) is reached, the Thread.sleep(150 * (5 - retries)); results in a disconnect from the device.
Is it possible to set a property to keep connected or disconnect if WriteData fails.

Question WriteData concurrent to the Device
If a motor is running, writedata is called over-and-over again (in Manager_WriteComplete) with the motor parameter (speed, direction). At the same time, seeking for a way to writedata requesting the Device Voltage & Parameter.
Should this be handled via a seperate service to avoid classing several writedata requests?
Note: Initially using resumable subs to request V&T sequentially - this is working great.

 

[Erel]

Stop scan after 10 seconds:

Manager.Scan(Null)
Sleep(10000) '10 seconds
Manager.StopScan

About the retries, you shouldn't rely on the retries mechanism. The retries mechanism is a fallback solution. You should instead try to avoid situations where multiple writings happen at the same time.
Handle the WriteComplete event and only send the next writing after it runs (note that it will not run if the characteristic is configured to not return a response). The other option is to add a short delay with Sleep between the writings.

 

[rwblinn]

Thanks for advice. Just to share progress made ...

Stop scan after 10 seconds:

Manager.Scan(Null)
Sleep(10000) '10 seconds
Manager.StopScan

Decided to use a time which stops after 10 seconds or if the right device is found in case several Bluetooth devices are found. This is working fine.

Handle the WriteComplete event and only send the next writing after it runs (note that it will not run if the characteristic is configured to not return a response). The other option is to add a short delay with Sleep between the writings.

The characteristic to drive a motor, does not return a response = do now understand why the motor stops based on "will not run if the characteristic is configured to not return a response". The motor drives for a short while, stops (indicating in the log the number of retries) and disconnects from BT.
Implemented a Workaround:
Use a flag to indicate motor is driving, which is checked in write_complete and triggers a next writedata with motor characteristics. This is working fine.
The downturn: if the motor is running, write_complete can not do anything else, like handling the return from writedata to request the motor temperature.
Did try using indicators in write_complete, but if a motor is driving and another request is made, like temperature, the motor stops driving.

Now considering to rewrite writedata and write_complete to handle non returns as the SBrick Protocol has many non-returns from commands.

Any other thoughts appreciated.

 

[Marcob]

About the retries, you shouldn't rely on the retries mechanism. The retries mechanism is a fallback solution. You should instead try to avoid situations where multiple writings happen at the same time.
Handle the WriteComplete event and only send the next writing after it runs (note that it will not run if the characteristic is configured to not return a response).

What happens when the last retry fails?
Is there some particular event that can be traced to acknowledge such WriteData failure?

 

[Erel]

It raises an exception. You can catch it with Try / Catch block.