uMyo VS urf_lib

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

Of significant stuff I wrote an nRF52 "core" (not Arduino core, it's for using with arm-gcc and makefiles) with necessary functions to feel comfortable there: https://github.com/ultimaterobotics/urf_lib - apart from simpler stuff like timers, uart, radio handlers and star protocol, I also made a custom implementation of BLE peripheral device (4.2-ish, hadn't implemented everything from 4.2, only parts I needed - that indeed was terribly complicated, if Nordic had their softdevice open sourced, I wouldn't do that). Since then I've added there fast ADC, PWM, SPI with DMA, persistent storage parts but those are not yet published.

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])

I in fact wrote a library for nrf52 family that, among other things, handles my own RF protocol (https://github.com/ultimaterobotics/urf_lib although no documentation yet) - I'm using star architecture, one central node talking to multiple peripherals at close to realtime schedule - communication cycle time is <2 ms per connected device, variable payload up to 250 useful bytes, no in-built acks or retransmits. That's because I had the need for such pattern in multiple projects I worked on.