Frequently Asked Questions
Last updated
Last updated
The data is sampled by default every 250ms (450Hz) and sends a single UDP packet of less than 512 bytes, as a result the network traffic is minimal. The frequency can be adjusted through the loop_delay parameter, but the device maximum frequency is every 10ms (100Hz) and while possible, it is hard to configure the sensor to achieve this throughput.
The sensor integrated in MUGIC® is a Bosch BNO055, one of the best fused IMU on the market. For technical documentation incl. range and accuracy, please see their documentation (https://cdn-shop.adafruit.com/datasheets/BST_BNO055_DS000_12.pdf)
This is a hard problem with any IMU sensor, since they only provide orientation and acceleration, not speed or position. For instance, it is physically impossible to distinguish a device traveling at constant speed from an immobile device since in both cases acceleration is zero. Using additional constraints (such as when the device is mounted on a doorframe or other physically -constrained element, or if the device undergoes a cyclical motion such as a rotation about a fixed axis) it is possible to achieve excellent positioning. For a free-form sensor like MUGIC® , it remains an active research project to estimate accurate speed and position, although in theory using physical constraints from an instrument such as a violin (if mounted on the box hand) should help.
(https://cdn-shop.adafruit.com/datasheets/BST_BNO055_DS000_12.pdf)
Developer note:
Without going too deep into the technical details, the Real-Time Operating System (RTOS) in MUGIC V2 allows the different functions of the device to work together in a timely fashion. For example, in the MUGIC V1, when getting a Web request, we would have to process it, return it, and then resume sending off the datagrams. The datagram is supposed to come every 20 ms, but there would be some jitter because of all these other functions. Hopefully, there is much less jitter in the RTOS in the datagram, even though we are also performing the web and BLE functions simultaneously. We will not miss a web request for reliability because the device is otherwise busy doing other tasks. In V1, it was sometimes hit or miss and some requests could go unanswered, resulting in additional bugs.
