Scheduling the logging.start() method with Timer module

edited March 2018 in Android

Hi,

I'm currently working on a project involving metawear R interactivity, and I'm struggling to delay the start of the logging with the timer module. Ideally, I would like to use the Timer module to schedule the metawear so that it starts logging after a specified time.

After looking at the documentation, I've tried this :

Logging logging = device.getModule(Logging.class);
Accelerometer accelerometer = device.getModule(Accelerometer.class);
Timer timer = device.getModule(Timer.class);

int timeBeforeExecution = 5000;

//run the codeBlock every 5000 milliseconds, stop after one call, delay the first call by one (so, should be resulting in only one call, after 5000 milliseconds have passed ?)
timer.scheduleAsync(timeBeforeExecution, (short) 1, true, new CodeBlock() {
    @Override
    public void program() {
        accelerometer.stop();
        accelerometer.acceleration().stop();
        logging.stop();

        logging.start(true);
        accelerometer.acceleration().start();
        accelerometer.start();
    }
}).continueWith(new Continuation<Timer.ScheduledTask, Void>() {
    @Override
    public Void then(Task<Timer.ScheduledTask> task) throws Exception {
        if (task.isFaulted() || task.isCancelled()) {
            // scheduling failed
        } else {
            // scheduling succeeded
            task.getResult().start();
        }
        return null;
    }
});
...

My task succeeds, but when I try to download the logging, it seems Logging never started because I receive no data. Instead of using the continueWith(...) I've also tried to use lookupScheduledTask, but no success either.

Could you help me understand how to schedule my Logging to start after a defined amount of time ? Thank you !

Comments

  • Did you create a data route to direct acceleration data to the logger?

  • edited March 2018

    @Eric said:
    Did you create a data route to direct acceleration data to the logger?

    Yes I did, before obviously trying to start logging, it looks like this :

    Accelerometer accelerometer = board.getModule(Accelerometer.class);
    
    accelerometer.configure().odr(odr).range(range).commit();
    
    accelerometer.acceleration().addRouteAsync(new RouteBuilder() {
        @Override
        public void configure(RouteComponent source) {
            source.log(new com.mbientlab.metawear.Subscriber() {
                @Override
                public void apply(Data data, Object... env) {
                    // use data
                }
            });
        }
    }).continueWith(new Continuation<Route, Void>() {
        @Override
        public Void then(Task<Route> addRoute) throws Exception {
            if (addRoute.isFaulted() || addRoute.isCancelled()) {
                // route failed
            } else {
                // route succeeded
            }
            return null;
        }
    });
    

    The accelerometer configuration and the route seems to be working perfectly fine when I don't try to use the Timer module, and start logging right away

  • I haven't run into any issues with scheduling the logger to start.

    accelerometer.acceleration().addRouteAsync(source -> source.log((data, env) ->
        Log.i("MainActivity", data.toString()))
    ).onSuccessTask(ignored -> timer.scheduleAsync(5000, (short) 1,  true, () -> {
        logging.start(true);
        accelerometer.acceleration().start();
        accelerometer.start();
    })).continueWith(task -> {
        if (task.isFaulted()) {
            Log.w("MainActivity", "Task failed", task.getError());
        } else {
            Log.i("MainActivity", "Ready");
            task.getResult().start();
        }
        return null;
    });
    

    Not sure why your scheduled task is stopping then starting the sensors/logger.

  • I'll try the sample code that you provided, though it is possible to separate the accelerometer route from the timer scheduling, without encountering issues, right ? (while still making sure the route was properly added, of course)

  • It probably should be OK though doing so defeats the purpose of using asynchronous tasks and it makes error handling more complex than it needs to be.

This discussion has been closed.