Timeout



  • I'm noticing that many of the Ble commands in transactions are going much longer than the timeouts dictated in DefaultTaskTimeoutRequestFilter. How is this class used? Should I be programming my own timeouts for these Ble commands? Thanks for your help!



  • This is on a Pixel with Android Pie. I'm having a lot of trouble with this phone and Bluetooth in general.



  • It shouldn't matter that you're running in a transaction. All BLE operations are put into a task queue. The read/write/etc operations you would do in a transaction result in the exact same tasks that would be created outside of the transaction. What Ble commands are not timing out properly? How far away from the device is the phone when this is happening?

    Also, what kind of transaction are you using, and how are you running the transaction?



  • I've noticed the timeout issue in both read and write operations. I'm running this transaction right after getting a BleDeviceState.CONNECTED state event. My sensor is immediately next to the phone. Here's an example of a transaction that occasionally times out. Note: This is only write we have that uses the delayed setData() callback.

    public class SyncTimeTransaction extends BleTransaction {
        private BleDefinitions mDefinitions;
    
        public SyncTimeTransaction(@NonNull BleDefinitions definitions) {
            mDefinitions = definitions;
        }
    
        public interface BleDefinitions {
            @NonNull
            UUID getTimeSyncService();
    
            @NonNull
            UUID getTimeSyncCharacteristic();
        }
    
        @Override
        protected void start() {
            BleWrite command = new BleWrite(mDefinitions.getTimeSyncService(), mDefinitions.getTimeSyncCharacteristic());
    
            Log.i(getDevice().getName_override() + " Writing sensor time");
    
            command.setData(() -> {
                DateMapper mapper = new DateMapper();
                try {
                    return mapper.toBytes(new Date());
                } catch (MapperException e) {
                    // Returning an empty array will throw a failed event in the ReadWriteListener.
                    // Returning null will cause SweetBlue to crash
                    Log.e(getDevice().getName_override() + " Couldn't map date object to sync time!");
                    return new byte[0];
                }
            });
    
            command.setWriteType(ReadWriteListener.Type.WRITE);
            command.setReadWriteListener(readWriteEvent -> {
                if (readWriteEvent.wasSuccess()) {
                    Log.i(getDevice().getName_override() + " Wrote sensor time");
                    succeed();
                }
                else {
                    Log.e(getDevice().getName_override() + " Failed to write sensor time");
                    fail();
                }
            });
    
            write(command);
        }
    
        @Override
        protected void update(double v) {
            super.update(v);
            if (getTime() > 100) {
                Log.e(getDevice().getName_override() + " Timeout!");
                fail();
            }
        }
    }
    

    Here's how I call that transaction:

    mSensor.getBleDevice().performTransaction(new SyncTimeTransaction(mDefinitions) {
                @Override
                protected void onEnd(EndReason endReason) {
                    super.onEnd(endReason);
    
                    if (endReason == EndReason.SUCCEEDED) {
                        continueOtherBleOperations();
                    }
                    else {
                        Log.e(mSensor.getSerialNumber() + " Critical! Failed to sync time!");
                    }
                }
            }
    

    I did notice that I had the UhOh listener trigger recommending me to restart the phone at the end of the night. Possibly a state mismatch warning? Could that affect the timeouts?

    Thanks so much for your help!



  • On a possibly unrelated note, we installed the toolbox app and tried connecting to three devices at once. In both the v2 and v3 versions of the app, the first connect always worked. After toggling BLE a few times, we started to see strange behaviors.

    On two Pixels (android 9), an s7 (8.0), and an s7 edge (7.0) with the v3 app, the sensors would not always reconnect and were slow when they did. With the v2 app, sensors were quick to reconnect and slowed minimally over time. On very rare occasions, a sensor on the v2 app didn't reconnect, but we could manually initiate the connection again.

    I'm not 100% sure how to interpret these results. Is there a way we can implement the standard v2 reconnect logic in v3? Thanks again for your help.



  • Hey @ryanbis!

    Is there more info I can provide on the timeout issue? Thanks for your help!



  • Looks like you have your own timeout implemented in the transaction. Is that what is getting triggered?



  • Yes, those trigger. We added those when we noticed that the times we set in taskTimeoutRequestFilter or DefaultTaskTimeoutRequestFilter weren't triggering.