Creation of some data processors times out

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):
    self.processor = pointer
    self.context = context
fn_wrapper = cbindings.FnVoid_VoidP_VoidP(processor_created)

libmetawear.mbl_mw_dataprocessor_counter_create(acc_signal, None, fn_wrapper)
# 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)



  • 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.

  • 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.

  • @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?

  • @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 $MAC_ADDRESS reset
    $ python $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):
                                                                  7.5, 7.5, 0, 6000)
            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_acc_set_odr(self.device.board, 10)
            libmetawear.mbl_mw_acc_set_range(self.device.board, 16.0)
            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
            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))
            # never reached
                                                    self.context, self.packed_callback)
        def start(self):
    address = sys.argv[1]
    device = MetaWear(address)
    if len(sys.argv) == 3 and sys.argv[2] == "reset":
    s = Sensor(device)
    print("setup finished")
    while not input():
  • libmetawear.mbl_mw_acc_get_packed_acceleration_data_signal works though.

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

  • 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?


Sign In or Register to comment.