stop, this is terrible
I finally did real-world testing of my HTTP implementation and it was.. worse than I expected in most of the cases (see first video). This was after I refactored quite a bit of the code and trying my best to optimize it; tested out queues, rate limits (<50hz), and other stuff, but nothing seemingly helped it.
finally, a less bad implementation (BLE)
Oh well, after this I started working on the BLE implementation instead - the watch would be the BLE central/master which scans and connects to the BLE peripheral/slave, a device running the “ZeppSlime Server” (idk what to call it yet) which advertises a service with all the characteristics to write to (imu, button, wheel for now).
The watch would then simply write the data to the specific characteristic (IMU/button/wheel), and as I expected this worked WAYYY better than before, who could’ve guessed (see second video); it’s actually submitting data at a constant, not slow rate.
..but it’s still scuffed
The roles are actually reversed in my implementation, as typically the watch would be the peripheral (what devices connect to) and the PC would be the central (the device connecting to others), then the PC would subscribe to notifications on the watch; ZeppOS’ API does not expose the watch as a BLE peripheral yet, just a central.
Now all that’s needed is to interpret the sensor (gyroscope, angular velocity in deg/s, and accelerometer, in cm/s^2) data on the “ZeppSlime Server” and send it over to the SlimeVR Server via UDP!
Log in to leave a comment