> ## Documentation Index > Fetch the complete documentation index at: https://playbook.smedleygroup.com/llms.txt > Use this file to discover all available pages before exploring further. # Telemetry > Locally hosted services collecting kart fleet charging and DAQ run data, and the pipeline that converts it for analysis. Live ## Overview The Telemetry system exists to collect and enable analysis of kart fleet telemetry data. It gives SG the ability to monitor fleet battery health in real time and to ingest and analyse live run data (DAQ) from the karts during sessions. Combined with timing data from TalentID:Coaching, this provides a more complete picture of driver and kart performance. ## How It Works Telemetry is a set of locally hosted services that communicate directly with the kart fleet over TCP to collect CAN charging data and DAQ (run) data. They run as a single Docker Compose stack on the machine at the track. Logically there are three parts: * **Charging Data Receiver.** Collects CAN charging data from the fleet over TCP and moves it through the pipeline into InfluxDB. * **Telemetry Dashboard.** A web application to monitor fleet battery health in real time and export charging data runs to S3. * **Exporter API.** Queries InfluxDB for charging data monitored in the Telemetry Dashboard, and receives DAQ run uploads from the karts and puts them in S3. Those parts are delivered by eleven containers in total, including a three node NATS cluster carrying messages between the services and InfluxDB as the charging data store. See [Track Operations](/software/developer/estate/systems/telemetry/track-operations) for the full list. Telemetry reads timing data from TalentID:Coaching to correlate telemetry readings with lap timing, and reads booking event data from GKL API to understand which events are races and which are tests. Collected telemetry data is written back into TalentID:Coaching via its API, where it is stored alongside timing data with a reference to its respective MATLAB data in S3. > [!NOTE] > > Telemetry is locally hosted, not cloud-hosted. This is an important operational distinction, because it requires physical presence on the network where the karts are. > [!WARNING] > > **Aentron karts are not officially supported in production.** The infrastructure is all there, the `aentron` battery spec is implemented end to end and the karts do stream, but the full factory test that would sign it off was never scheduled. It has been outstanding since September 2025. Treat anything on the `aentron` spec as unverified in production until that test is done, and do not rely on its charging data for fleet decisions. `mep` karts are unaffected. ## The End To End Journey Telemetry spans a machine at every track and a conversion pipeline in AWS. There are two data streams, collected the same way and converted very differently, which meet again in the STL database. For all of it on one diagram, see [Architecture](/software/developer/estate/systems/telemetry/architecture). **A DAQ run:** | Stage | Where | | - | - | | A run is recorded by the DAQ unit and posted to the local API | The track machine | | It is zipped with its logging table and metadata, given a run number, and uploaded | The track machine | | The upload triggers conversion: resample and decode, normalise, forward fill, split, export to STL | AWS | | Timing from AlphaTiming is imported, which can trigger a reconversion | AWS | | Converted runs appear against competitors on the DAQ page | Operator Dashboard | **A charging run:** | Stage | Where | | - | - | | Charging data streams in from the karts continuously and is stored in InfluxDB | The track machine | | An engineer exports it to STL from the dashboard and syncs it to S3, by hand | The track machine | **Both:** | Stage | Where | | - | - | | Engineers sync the STL database down and review battery health and kart performance | SimTelLab, on an engineer's machine | There is one track machine per hub region. It is started and stopped every day of an event, and once per event a setup script is run to pull the latest scripts and images. ## Detailed Documentation > **[Architecture](/software/developer/estate/systems/telemetry/architecture)** > > The whole system on one diagram: the track machine, the AWS pipeline, and the two data streams. > **[Track Operations](/software/developer/estate/systems/telemetry/track-operations)** > > The machine at the track: setting one up, the event cycle, what runs on it, and the backups. > **[The Charging Data Receiver](/software/developer/estate/systems/telemetry/receiver)** > > How the receiver polls the karts, how frames are decoded and written, and the internal signals. > **[DAQ Upload and Conversion](/software/developer/estate/systems/telemetry/daq-pipeline)** > > How a run gets from the kart to STL, what the zip contains, and what the converter does. > **[Timing and Lap Splitting](/software/developer/estate/systems/telemetry/timing-and-lap-splitting)** > > How TalentID timing turns a recording into laps, and how reconversion is triggered. > **[Charging Export](/software/developer/estate/systems/telemetry/charging-export)** > > How an engineer exports charging data to STL from the track dashboard, and what the export does to it. > **[Internal Signals](/software/developer/estate/systems/telemetry/internal-signals)** > > The `x` prefixed signals the pipeline emits about itself, and what a healthy kart looks like. > **[Telemetry Dashboard](/software/developer/estate/systems/telemetry/dashboard)** > > The three screens on the track machine, and how they reach the API. > **[Exporter API](/software/developer/estate/systems/telemetry/exporter-api)** > > Every endpoint the dashboard calls, plus the DAQ upload endpoint. > **[Local Development](/software/developer/estate/systems/telemetry/local-development)** > > Standing in for the kart fleet with the simulator, and converting a run on your own machine. > **[STL Database and SimTelLab](/software/developer/estate/systems/telemetry/stl-database)** > > Where every converted run is filed, and how engineers get it onto their own machine. > **[Deployment And The Pipeline](/software/developer/estate/systems/telemetry/deployment)** > > How a merge becomes a running change: the CDK pipeline, the images, and the AWS resources it creates. > **[Troubleshooting](/software/developer/estate/systems/telemetry/troubleshooting)** > > Runs that did not arrive, did not convert, or do not show on the dashboard. Plus known issues. ## Repositories | Repository | Description | | - | - | | [can-wifi](https://github.com/Smedley-Group-Advanced-Technology/can-wifi) | Telemetry services and infrastructure code | ## Dependencies ### Internal * **TalentID: Coaching.** Telemetry reads timing data from TalentID:Coaching to correlate with telemetry readings. It also writes collected telemetry data back into TalentID:Coaching via the API, where it is stored and served alongside timing KPIs. * **GKL API.** Telemetry reads booking event data from GKL API to understand active events. Read-only. ### Infrastructure * **TalentIdPipeline-Infra-CDK.** Provides the VPC and shared MongoDB EC2 instance. * **Local network.** Telemetry services are locally hosted and communicate with the kart fleet over TCP on the local network. ## Notes * Both data streams are in production. Charging data is exported by hand from the track dashboard; DAQ runs convert automatically in AWS. * Aentron karts are not officially supported in production, pending a full factory test that has been outstanding since September 2025. The `aentron` battery spec is fully implemented, so the support gap is verification, not capability. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.