Instructions to use Thox-ai/ThoxMesh-Head-C6 with libraries, inference providers, notebooks, and local apps. Follow these links to get started.
- Libraries
- LiteRT
How to use Thox-ai/ThoxMesh-Head-C6 with LiteRT:
# No code snippets available yet for this library. # To use this model, check the repository files and the library's documentation. # Want to help? PRs adding snippets are welcome at: # https://github.com/huggingface/huggingface.js
- Notebooks
- Google Colab
- Kaggle
ThoxMesh-Head-C6
The ESP32-C6 half of ThoxAir. ThoxAir is a dual-chip device: the RV1103
runs the conversational model (Thox-ai/ThoxAir-16M-role,
llama.cpp armv7-neon), and the XIAO ESP32-C6 is the wireless coprocessor β
Wi-Fi 6, BT 5.3, Zigbee, Thread/802.15.4, Matter.
This is the triage head. The C6 sees every radio and sensor event before the RV1103 does; waking a 16M LLM for each Zigbee attribute report would be absurd, so this model classifies the event and escalates only what needs language.
| format | int8 TFLite (full quant, int8 in and out) |
| size | 9,512 bytes (budget was 256 KB β 27Γ headroom) |
| accuracy | int8 0.9647 vs float32 0.9645 |
| runtime | TFLite-Micro / LiteRT-Micro |
Quantisation cost nothing, which is worth stating because a clean float model collapsing under int8 is the classic TFLM surprise.
Classes
ignore Β· local_ack Β· wake_word Β· smarthome_command Β· sensor_alert Β·
security_event Β· network_event Β· power_event
Only wake_word, smarthome_command, sensor_alert and security_event
normally escalate to the RV1103.
Feature contract β firmware must match exactly
32 float32 features normalised to ~[0,1]. A wrong layout does not error, it returns confident nonsense, so this is the interface:
| idx | meaning |
|---|---|
| 0β5 | transport one-hot: thread, zigbee, matter, wifi, ble, none |
| 6β13 | cluster one-hot: onoff, level, occupancy, contact, temp, humidity, energy, alarm |
| 14β21 | value, delta, rssi, battery, hour, is_night, repeat_rate, link_quality |
| 22β29 | 8 log-mel band energies from the mic frontend |
| 30β31 | audio rms, zero-crossing rate |
Full names and the input quantisation scale/zero-point are in meta.json.
This model does not consume raw PCM. Bands 22β31 come from the firmware's existing mic frontend; the log-mel/MFCC frontend stays in firmware. What this head adds is fusing the audio summary with radio context.
Known limitation β synthetic data
Trained on synthetic per-class distributions. No real device captures were
available. The weights are real and the class shapes are calibrated, but it has
no real-world priors. It wants a pass over real Matter/Thread/Zigbee captures
before being trusted for anything safety-adjacent β particularly
security_event.
Ship-first: not measured on C6 silicon.
- Downloads last month
- -