Skip to main content
Both telemetry streams end in the same place. Converted DAQ runs and exported charging runs are filed into an STL database in the telemetry bucket, which engineers sync down and open in SimTelLab to review battery health and kart performance while out on track.

​
The Structure

The STL database is a folder structure under the STL-database/ prefix of the telemetry bucket. The layout is not an implementation detail: SimTelLab reads it directly, so it is effectively a contract. Runs whose binary header reports hardware version 0.3 are filed under RACING_v03 rather than RACING. Each run is a pair of MATLAB files: {runName}_Tel.mat holding the channel data, and {runName}_Info.mat holding the run metadata.
For DAQ runs, the Race or Test segment comes from the isRaceDay answer that GKL API gives during conversion. If that answer is wrong, the run converts perfectly well and is then filed under the wrong event type, where nobody is looking for it. For charging runs the event type comes from the dashboard instead, and defaults to Test.

​
Getting It Onto An Engineer’s Machine

1

Sync the database down

The STL database is synced from S3 to the engineer’s own machine with aws s3 sync. A helper script in the telemetry API repository does this a year at a time, in both directions.
2

Open it in SimTelLab

SimTelLab is an externally provided Windows application. It reads the .mat files straight from the synced folder structure.
The sync script has the year hard coded, so it needs editing at the turn of a year.

​
Key Files

Last modified on September 8, 2026