Skip to content

Choosing a Satellite

A satellite is whatever you talk to — but not every satellite carries the same load. At one end sits a terminal where you type and the server does absolutely everything. At the other sits a Raspberry Pi that hears the wake word, transcribes your speech, and speaks the reply all on its own, handing the server nothing but finished text. Every device in between is a question of one thing: how much of the listening happens on the device, and how much on the server. The thinner the satellite, the cheaper the hardware and the more it leans on the network. The thicker it is, the more it keeps to itself — even the audio stays home. This page helps you find your spot on that line.

In a nutshell

  • Satellites differ by which stages run on the device (mic, VAD, wakeword, STT, TTS) and what actually crosses the wire (typed text, raw audio, or audio only after the wake word fires).
  • Anything that ships audio needs a server ready to catch it: raw-audio and base64-audio clients require hivemind-audio-binary-protocol on hivemind-core; text-only satellites work with any server.
  • The voice satellite keeps all speech on the device and sends only text; the mic satellite is the cheapest device to build but hands STT/TTS to the server.
  • Not sure? The decision guide maps a device to its satellite in a few questions.

Comparison

Most people start with the voice satellite (everything runs locally, works with any hivemind-core instance) or the mic satellite (cheapest device, but hivemind-core must do STT/TTS). Pick from the table below, or read the decision guide.

Satellite Mic VAD Wakeword STT TTS What crosses the wire
HiveMind-cli — — — — — Text in / text out
Microcontrollers (ESP32) local local1 local1 server server Raw audio stream
hivemind-mic-satellite local local server server server Raw audio stream
HiveMind-voice-relay local local local server server Audio after wakeword
HiveMind-voice-sat local local local local local Text utterances only
WebSpeech Browser browser browser — server server Audio from browser

The microcontroller clients (ESP32 in C, or MicroPython) are the thinnest hardware tier — below the mic satellite. They turn a tiny chip into a satellite without running OVOS or Python-on-a-PC on the device. See Microcontrollers (ESP32).

Server requirements by satellite

Satellite hivemind-core must provide
HiveMind-cli Any hivemind-core instance (OVOS skills or Persona)
Microcontrollers (ESP32) hivemind-audio-binary-protocol for the binary/base64 audio modes
hivemind-mic-satellite hivemind-audio-binary-protocol for STT/TTS/wakeword
HiveMind-voice-relay hivemind-audio-binary-protocol for STT/TTS
HiveMind-voice-sat Any hivemind-core instance (sends text utterances)
WebSpeech Browser base64 mode (default): ovos-dinkum-listener >= 0.0.3a19 + hivemind-core allow-msg "recognizer_loop:b64_audio". binary mode: hivemind-audio-binary-protocol

See Audio Binary Protocol for server-side setup.

Advanced: how the audio actually travels

The audio satellites do not all use the same transport, which is why their server requirements differ:

  • mic-satellite and the ESP32 binary mode send binary RAW_AUDIO frames — handled by hivemind-audio-binary-protocol on hivemind-core.
  • voice-relay sends base64 audio over the bus (recognizer_loop:b64_transcribe; TTS comes back as speak:b64_audio) — also provided by hivemind-audio-binary-protocol.
  • WebSpeech has two audio-transport settings. Its default, base64, sends base64 audio over the bus as recognizer_loop:b64_audio, decoded directly by ovos-dinkum-listener >= 0.0.3a19 once hivemind-core allows that message — this mode never touches the binary protocol. Its optional binary mode instead uses hivemind-audio-binary-protocol's STT_AUDIO_HANDLE frame type — not the same frame type as mic-satellite's RAW_AUDIO, but the same plugin.

Decision guide

Answer a handful of questions about your device and this points you at the right satellite. Follow the arrows:

flowchart TD
    A([What are you<br/>putting it on?]) --> B{A web browser<br/>or web app?}
    B -->|Yes| WS[WebSpeech Browser]
    B -->|No| C{Do you need<br/>voice input?}
    C -->|No, text only| CLI[HiveMind-cli]
    C -->|Yes| D{A bare microcontroller?<br/>ESP32 · Pico W}
    D -->|Yes| MC[Microcontrollers<br/>ESP32 / MicroPython]
    D -->|No| E{Can it run local<br/>STT + TTS models?}
    E -->|"Yes, capable CPU/GPU"| VS[HiveMind-voice-sat<br/>most private · works offline]
    E -->|No| F{Wakeword on<br/>the device?}
    F -->|"Yes, saves bandwidth"| VR[HiveMind-voice-relay]
    F -->|No| MS[hivemind-mic-satellite<br/>cheapest hardware]

    classDef pick fill:#e3f2fd,stroke:#1976d2,color:#0d47a1;
    class WS,CLI,MC,VS,VR,MS pick;

Each blue box links to its full setup page in the comparison table above: WebSpeech · CLI · Microcontrollers · voice-sat · voice-relay · mic-satellite.

About server-owned STT/TTS

When a satellite uses server-side audio processing (mic-satellite or voice-relay), the hivemind-core operator decides the STT engine, TTS engine, and voice — the satellite cannot override them. This is the "HiveMind as a service" model: speech services are authenticated and centrally governed, like any other message on the protocol.

A voice-sat by contrast runs its own STT and TTS plugins and sends only the transcribed text to hivemind-core. It has full control over its local audio stack.

See also

  • Multi-user text chatroom — hivemind-flask-chatroom is a text-only Flask web app (default port 8985, no audio) where one server-side credential is fanned out to many browser visitors. Handy for a shared text terminal to a hivemind-core instance; it is not a per-device satellite.

Next

Head to the satellite that fits your device: Microcontrollers (ESP32), HiveMind-voice-sat, hivemind-mic-satellite, HiveMind-voice-relay, HiveMind-cli, or WebSpeech Browser.

Source

Validated against the HiveMind source:

  1. On-device VAD and wakeword apply to the ESP32-S3 Voice PE build (ESP-SR WakeNet9); the plain ESP32 and the MicroPython client capture the mic and let hivemind-core do the rest. See Microcontrollers. ↩↩