uMyo VS brainflow

You can find this math in my code here: https://github.com/ultimaterobotics/uMyo/blob/main/lsm6ds3.c lines 131-144 (it uses files quat_math.c, .h from the same folder) - there you can also find fusion with accelerometer, zero offset calibration and some other stuff (if you will actually use it - please keep in mind that function for calculation of roll, pitch, yaw angles there likely isn't working the way it should, I took it from someone else's code, didn't like the result, and never used nor debugged it - in my case angles are calculated on the receiver side from quaternion using very different math)

You can look at uMyo ( https://github.com/ultimaterobotics/uMyo ) - it's fully open source, so you can run your own production. Although its price is a bit below $40 per channel (and that is full processing unit with its own MCU and radio channel, so you only need a single receiver for all devices on the PC side), so if you need 3-4 units - then it will be cheaper to just buy them. For 10+ you may order factory production, it will be cheaper at that point (but still, if you take into account all the necessary stuff and shipment, you are looking at ~$30-35 per channel at this quantity)

For proper integration, the simplest way is to use quaternion math - at turn on set rotation quaternion to one that represents zero rotation, and then adjust it with every new data point. You can use my code from uMyo project - based on function calculate_quat() here: https://github.com/ultimaterobotics/uMyo/blob/main/lsm6ds3.c which uses quat_math and fast_math .c, .h files from the same repository. But there it's significantly more complicated than you need (performing auto-calibration and taking into account gravity for compensating vertical axis drift). In the simplest form it would be the following (assuming Qsg is our quaternion of interest, declared outside of update function and initialized as .w=1, .x=0,.y=0,.z=0):

You may want to check the library I made some time ago: https://github.com/ultimaterobotics/urf_lib (radio related stuff is in urf_radio.c, .h files)- I hadn't implemented there methods with external setting of length and packet ID (both are intended to be handled outside of the library) - but if something doesn't work as intended in your case, you can trace an example of sending from nRF52 to nRF24 here https://github.com/ultimaterobotics/uMyo_v2 , in file main.c preparation of the packet is handled with prepare_data_packet32(), which is later sent via a single call of rf_send(data_packet, data_packet[1])

We recently made an open source / hardware device using 52810. You might be interested in its PCB/schematics ( https://github.com/ultimaterobotics/uMyo_v2_pcb ) and code ( https://github.com/ultimaterobotics/uMyo_v2 ).

The home project I've been working on for 4 years (https://github.com/brainflow-dev/brainflow) has been downloaded 100k times from PyPI. It's a library to work with wearable devices, with primary focus on EEG.

About my current user base, I'd like to highlight we use SimpleBLE at my job, it has been integrated into BrainFlow, it is part of some new tools made by a large industrial automation company (whose name I cannot mention but rhymes with "Good product made by bees") and by a robot researcher in Germany.

BrainFlow provides a uniform SDK to work with biosensors with a primary focus on neurointerfaces. It provides SDK for Python, Java, C#, C++, Matlab, R, Julia and Rust. Core part of BrainFlow is written in C\C++ and all bindings call methods from dynamic library. User API is uniform for all supported devices and allows you to develop device agnostic applications.

I made a mod for Skyrim VR that brings your mental focus level (as determined by a Muse 2 meditation EEG device and the processing of https://brainflow.org) into Skyrim and scales your ingame magic power by your actual mental power. So you now actually need to learn to channel your inner strength if you want to be a successful mage! This is Real Virtual Magic!

I can get the complete EEG reading of four channels plus the gyro sensors and in the future also the heart rate. What I do with it is a different question :D I process the data myself, locally, using the brainflow.org library. So I do create a non-binary value at the moment

Sure! I use brainflow.org to collect the data from the muse and at the moment I just do a super simple spectral analysis and use the average alpha/theta ratio to determine brain power. This will definitely not stay. I am already experimenting with different ratios and I will probably implement a classifier that allows a more sophisticated classification later down the road. I will also augment it with the gyro sensor and the heart rate monitor that is integrated in the Muse. Ultimately, I will make it compatible with the OpenBCI Galea device. Join the discord to stay in touch!