ZeppSlime banner

ZeppSlime

6 devlogs
11h 19m 50s

Turn Amazfit / ZeppOS-compatible smartwatches into SlimeVR trackers.

Maya

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!

0
Maya

this is a terrible idea, pls stop

Woo this is terrible but it is working! I’ve set up forwarding the IMU (accelerometer & gyroscope) data now and it’s pretty.. bad lol. I need to do some real-world testing (with my real watch rather than the simulator) but the requests being sent per second isn’t very good lmao.

I will definitely will implement the direct BLE connection when I get the chance. but overall I hope it will be better if i set the frequency mode of the sensors & remove the visual logging, testing on a real device.

HTTP server details

Currently, all the endpoints are GET requests with the IMU endpoint using query parameters of the raw values, which should be smaller/faster than POST requests & parsing JSON. I should move the other endpoints to query params so I could also implement support for multiple watches connected to the same server.

look at you, stealing code from your own project

Other than that, I set up some basic code for the SlimeVR Server forwarding (which I stole a bunch of the code to save time from my previous project, SlimeTora, since it’s also a TS project)

Attachment
Attachment
0
Maya

Monorepo time!

I turned the repository into a Bun monorepo consisting of the watch app and the companion server (currently a HTTP server to forward requests to SlimeVR Server).

Screw electron, embrace Tauri

The server app is a Tauri project with SvelteKit as the framework (where I’ll work on the UI later) and I went straight to implementing a basic HTTP API server with the actix_web crate.

Communication things

After creating the basic server, I installed the @zeppos/zml library to make communication easier, testing out the HTTP server through it, and it works.. after forgetting to initialize the side service in app.json again! This is one of the methods of the two I plan to implement (see the previous devlog). The user would just have to enter the PC’s IP to talk with the server for this HTTP method, but I’m making good progress :3

Attachment
Attachment
0
Maya

Accessing the data & real HW tests

I took a break for a while because I got busy on some stuff for a school event (& someone forgot she is a YSWS reviewer again lmao).

This time I tested accessing the required sensors I need (accelerometer & gyroscope) so I can interpret that for SlimeVR, displaying it on the screen for now. Also tested out the app on my actual watch for the first time, adding a visual logger package so I could see it on the watch.

Took me quite a bit longer than expected to get working (and I forgot that I needed to add the right permissions to the app.json file).

Attachment
Attachment
Attachment
0
Maya

How should we relay the data?

I was investigating how I could actually relay the data to the SlimeVR Server and came up with two solutions, both being quite scuffed.

HTTP requests

The API allows for external fetch/HTTP requests through the watch connecting to the mobile app (side service), then performing the request on the phone. However, the SlimeVR Server does UDP (or nRF dongle) to handle communication between the trackers.

The first idea was the following, but I imagine the latency would be hell:

  • Smart watch -> mobile app -> HTTP server (phone/PC) -> SlimeVR Server (HTTP -> UDP)

Bluetooth Low Energy

The watch can act as a BLE central so the second idea should be much better. Both options aren’t great solutions, but oh well it works I guess – let’s see hw it is in practice lol!

  • Smart watch as BLE central -> Phone/PC running a BLE peripheral server -> SlimeVR Server (BLE -> UDP)

Doing the UI

The rest of the time was to figure out how to actually draw onto the app, which was pretty confusing because I kept getting errors which provide basically no info (incorrect file numbers as it shows from compiled JS, and some errors that’s supposed to say what variable caused, just shows blank lmfao)

Attachment
0
Maya

ZeppSlime!

I got the Amazfit Bip 6 for Christmas because it is a very cool smartwatch for its price, with a full on developer API & app store! I had a few ideas for this so here’s the first project: turning these watches into SlimeVR trackers (similar to OwoTrack on Android).

This is my first time setting up a dev environment for it and it’s pretty cool what this company offers:

  • The apps (and watch faces) are interestingly made in JavaScript
  • The simulator to develop the apps uses QEMU

    I tried setting this up on my main NixOS machine, screwing around with the Nix flake but I didn’t get anywhere, so I decided I would just develop on my MacBook Pro instead.
Attachment
Attachment
0