›

Creation of some data processors times out

farnasirimfarnasirim
in Requests & Bug Reports

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

  • EricEric

    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.

  • farnasirimfarnasirim

    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.

  • EricEric

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

  • farnasirimfarnasirim

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

    libmetawear.mbl_mw_acc_get_packed_acceleration_data_signal works though.

  • EricEric

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

  • farnasirimfarnasirim

    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.