Routing data with a process directive times out

When I submit a  data route after connection that contains a processing step the commit times out with  the "java.util.concurrent.TimeoutException: Adding a data route timed out after 7000ms" This happens on both my RPRO and CPRO devices.

The following code times out. 
gyroCtrllr.routeData()
.fromYAxis()
.process(new Maths(Maths.Operation.ADD, 0))
.stream("pulseStream")
.commit().onComplete(new AsyncOperation.CompletionHandler<RouteManager>() {
@Override
public void success(RouteManager result) {
Log.i("PULSE","CONNECTED");
result.subscribe("pulseStream", pulseMsgHandler);
}

@Override
public void failure(Throwable error) {
Log.i("PULSE","FAILED");
Log.i("PULSE",error.toString());
super.failure(error);
}
});

Direct unprocessed routing seems to work fine. Such as the following.
accelerometerCtrllr.routeData().fromAxes()
.stream("accelStream")
.commit().onComplete(new AsyncOperation.CompletionHandler<RouteManager>() {
@Override
public void success(RouteManager result) {
result.subscribe("accelStream", accelerometerMsgHandler);
devicesInitialized += 1;
accelerometerCtrllr.enableAxisSampling();
accelerometerCtrllr.start();
}

@Override
public void failure(Throwable error) {

super.failure(error);
}
});
Any ideas on what might be happening?

Comments

  • Nothing is wrong with the code and it works fine for me.  How many processors are you using in your code?
  • I'm only using one processor. Today I've been able to get the first program to upload without timing out on some devices when I run in release (vs debug) but only some of the time. I haven't been able to find any correlation other than release vs debug.

    Is there any likely hood that this is an issue with the bluetooth stack on the android device being slower?
  • New Progress!

    It seems that the devices enter a state where uploading anything more than a simple stream route cause a timeout when my application terminates without calling disconnect. This state seems to persist until the device is power cycled (removing the battery for the CPRO) or have a soft reset issued.

    I need to ensure that I call disconnect on app close. This is somewhat of an annoyance however as my app will sometimes crash during development. 

    I'm not sure what internally is causing this but it seems like an issue that could be addressed in the firmware. Something like if you receive a connection without an intermediate disconnection run the disconnection code before accepting the new connection.
  • edited April 2016
    What firmware version are your boards using and what is the model and OS of your Android device? Also, what are the steps for reliably reproducing this state?
  • CPRO 1.2.1 RPRO 1.13 (up to date as of this writing). 
    Project Tango Tablet (just happened to be the one I had around)  OS 4.4.2

    Connect to the device and don't call MetaWearBoard.disconnect() before closing the application. Reconnect to the device and attempt to load a non trivial program.
  • I followed your steps both closing the app from the app switcher and force closing it from the settings menu, and I was able to program one of the example routes from the Android documentation with no issues.

    Terminating an app should also end the Bluetooth background service. Perhaps there is something different with the hardware or Android OS on the Tango Tablet because my Nexus 6 and 7 on 5.1.1 both work just fine with your use case.
  • I should have another tablet in the next day or two so I can test against another android device.

    I've been able to upload much more complicated routes following the procedure above.
This discussion has been closed.