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):
    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.

Comments

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

    Thanks

Sign In or Register to comment.