Creation of some data processors times out

farnasirim

Hi there,
I'm currently trying to somehow squeeze out a no_motion signal using the currently available c++ api (as it's not available) through the python bindings, but I have noticed that some data processors work fine (e.g. highpass) whereas some of them time out upon creation and the callback is never called (e.g. counter). I assume each data processor supports certain types of MblMwDataSignals on the chip? If so could you please point me somewhere to read about those? I couldn't find anything about them in the docs.

Example case of a callback that is never called:

def processor_created(context, pointer):
    print("created")
    self.processor = pointer
    self.context = context
    e.set()
fn_wrapper = cbindings.FnVoid_VoidP_VoidP(processor_created)

libmetawear.mbl_mw_dataprocessor_counter_create(acc_signal, None, fn_wrapper)
e.wait()
# This is never reached
libmetawear.mbl_mw_datasignal_subscribe(self.processor, self.context, self.callback)

Changing the counter to a highpass will make things work as expected:

libmetawear.mbl_mw_dataprocessor_highpass_create(acc_signal, 16, None, fn_wrapper)

Thanks.

Eric

This is a bug with the counter processor.

Also, the method returns a non-zero status so you can use that to escape the indefinite wait.

farnasirim

Hi Eric,
Thanks, I have observed this in a number (majority?) of processors. packer for example.
For anyone else who might be interested, I ended up calculating "any motion" from the acc signals on my own side, and would then alternate between (acc on, motion off) and (acc off, motion on) to preserve battery.

Eric

@farnasirim said:
Hi Eric,
Thanks, I have observed this in a number (majority?) of processors. packer for example.

Provide code that demonstrates theses issues.

Are you cleaning up board resources every time you run your script?

farnasirim

@Eric Thanks, here's the code. Also what is considered a correct way of wiping the configuration on the device upon startup in a scenario where we connect to/disconnect from the device a lot? Is calling teardown enough? Is a sleep period recommended after calling it?

$ python script.py $MAC_ADDRESS reset
$ python script.py $MAC_ADDRESS

#!/usr/bin/env python

import time
from threading import Event
import os
import sys

from mbientlab.metawear.cbindings import *
from mbientlab.metawear import MetaWear, libmetawear, parse_value, cbindings


def show(data):
    return "{0:.4f} {1} {2}".format(time.time(), data.contents, parse_value(data))


class Sensor:
    def __init__(self, device):
        self.device = device
        self.packed_callback = cbindings.FnVoid_VoidP_DataP(self.packed_handler)

    def packed_handler(self, ctx, data):
        print("packed_handler:", show(data))

    def setup(self):
        libmetawear.mbl_mw_settings_set_connection_parameters(self.device.board,
                                                              7.5, 7.5, 0, 6000)
        time.sleep(1)

        pattern = LedPattern(repeat_count= Const.LED_REPEAT_INDEFINITELY)
        libmetawear.mbl_mw_led_load_preset_pattern(byref(pattern), LedPreset.SOLID)
        libmetawear.mbl_mw_led_write_pattern(device.board, byref(pattern), LedColor.GREEN)
        libmetawear.mbl_mw_led_play(device.board)

        libmetawear.mbl_mw_acc_enable_acceleration_sampling(self.device.board)

        libmetawear.mbl_mw_acc_set_odr(self.device.board, 10)
        libmetawear.mbl_mw_acc_set_range(self.device.board, 16.0)
        libmetawear.mbl_mw_acc_write_acceleration_config(self.device.board)

        acc = libmetawear.mbl_mw_acc_get_acceleration_data_signal(self.device.board)

        e = Event()

        def packer_created(context, pointer):
            self.context = context
            self.packer_processor = pointer
            e.set()
        fn_wrapper = cbindings.FnVoid_VoidP_VoidP(packer_created)

        x = libmetawear.mbl_mw_dataprocessor_packer_create(acc, 4, None, fn_wrapper)
        # return value:
        # Processor not supported for the data signal */
        # const int32_t MBL_MW_STATUS_ERROR_UNSUPPORTED_PROCESSOR = 4;

        print("Waiting for packer: {}".format(x))
        e.wait()

        # never reached
        libmetawear.mbl_mw_datasignal_subscribe(self.packer_processor,
                                                self.context, self.packed_callback)

    def start(self):
        libmetawear.mbl_mw_acc_enable_acceleration_sampling(self.device.board)
        libmetawear.mbl_mw_acc_start(self.device.board)


address = sys.argv[1]
device = MetaWear(address)
device.connect()
print("Connected")

if len(sys.argv) == 3 and sys.argv[2] == "reset":
    print("Resetting")
    libmetawear.mbl_mw_metawearboard_tear_down(device.board)
    time.sleep(1)
    libmetawear.mbl_mw_debug_reset(device.board)
    os._exit(0);

s = Sensor(device)
s.setup()
print("setup finished")
s.start()

while not input():
    pass

farnasirim

libmetawear.mbl_mw_acc_get_packed_acceleration_data_signal works though.

Eric

You can't pack that much acceleration
data in one packet.

farnasirim

Is there any particular reason why I might use mbl_mw_dataprocessor_packer_create (which can pack 2 values) over mbl_mw_acc_get_packed_acceleration_data_signal which can do 3?
Also I expected the arrival time of every 2-batch of data be equal in the former, similar to how it is in the latter, as I assume the data points are arriving at the client as a single pack and therefore at the same time? (similar to the case in the latter). Am I missing something?
Could you please comment on the clean-up question too?

Thanks