Two commands for enabling features #266

New Issue

MrUnknownDE · 2026-04-05T17:52:22+02:00

MrUnknownDE commented

2026-04-05 17:52:22 +02:00

Originally created by @ImUrX on 6/29/2023

First is getting tracker features, this command should provide features by following this new type:

u8[u32]

u8 specifying the length of the array and then the amount of u32s :p

The features are done via bitfields so each bit of the u32 numbers means something, for now we will be using little endian for processing the data but its gonna be shown in the actual network packet as big endian but the spec would specify what each bit is so we are gonna use indexing for defining fields:

RUNTIME_MAG_SUPPORT
MAG_ENABLED
CALIBRATION_SUPPORT
BLINK_SUPPORT

So first bit (depends of endianness) tells you if the tracker itself has support for runtime magnetometer management #230 and second bit lets you know if it's enabled or disabled.

Second command is tracker trigger, this let's you trigger commands based on the previous feature, it has two arguments which the first one is based on u16 (which is bigger than 256*32) and second one should only be a boolean for setting stuff to one or zero but we could flex this dependent to the first argument (needs to be discussed).
The first argument should refer to one of the index of tracker features (needs to be discussed) and it triggers that feature so you do TRIGGER 3 and then tracker should blink. But this doesn't mean every feature triggers stuff like TRIGGER 0 should do nothing.
TRIGGER 1 true should set MAG_ENABLED to true and vice versa.

This is a very flexible idea and shouldnt be that complicated to implement

*Originally created by @ImUrX on 6/29/2023* First is getting tracker features, this command should provide features by following this new type: ``` u8[u32] ``` u8 specifying the length of the array and then the amount of u32s :p The features are done via bitfields so each bit of the `u32` numbers means something, for now we will be using little endian for processing the data but its gonna be shown in the actual network packet as big endian but the spec would specify what each bit is so we are gonna use indexing for defining fields: 0. ``RUNTIME_MAG_SUPPORT`` 1. ``MAG_ENABLED`` 2. ``CALIBRATION_SUPPORT`` 3. ``BLINK_SUPPORT`` So first bit (depends of endianness) tells you if the tracker itself has support for runtime magnetometer management #230 and second bit lets you know if it's enabled or disabled. Second command is tracker trigger, this let's you trigger commands based on the previous feature, it has two arguments which the first one is based on `u16` (which is bigger than 256*32) and second one should only be a boolean for setting stuff to one or zero but we could flex this dependent to the first argument (**needs to be discussed**). The first argument should refer to one of the index of tracker features (**needs to be discussed**) and it triggers that feature so you do ``TRIGGER 3`` and then tracker should blink. But this doesn't mean every feature triggers stuff like ``TRIGGER 0`` should do nothing. ``TRIGGER 1 true`` should set MAG_ENABLED to true and vice versa. This is a very flexible idea and shouldnt be that complicated to implement

MrUnknownDE added the Type: Enhancement Type: Discussion Area: Hardware Protocol Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Enhancement Type: Discussion Type: Discussion Area: Hardware Protocol Area: Hardware Protocol labels 2026-04-05 17:52:24 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/SlimeVR-Tracker-ESP#266