Why Splitting Is Needed
A DAQ unit records a continuous stream of signals for a whole run. It has no idea where one lap ends and the next begins, because nothing in the kart knows when it crossed the timing line. That information exists only in the timing system. TalentID holds the timing. Lap splitting is therefore a join between two systems: telemetry supplies the signals, TalentID supplies the lap boundaries, and the converter cuts one against the other.If no timing can be matched, the run still converts. It becomes a single lap covering the entire recording, flagged as both an out lap and an in lap, and it will not appear against a competitor in the Operator Dashboard.
How A Run Is Matched To Timing
The join key is not a driver or a booking. It is the transponder, qualified by time and place:
TalentID takes those three and finds the competitor whose session overlaps that window in that region. From the competitor it can then reach the session, the event, the lap times, and the TalentID driver. That driver record carries the GKL driver ID, which is what makes the GKL calls below possible.
The Conversion Flow
1
The run reaches the converter
A run zip is uploaded to the telemetry bucket and fans out through SNS and SQS to the converter Lambda. See DAQ Upload and Conversion.
2
TalentID decides whether to convert
The converter calls TalentID for conversion status, passing the metadata and the zip checksum. TalentID answers with
shouldConvert, the matched competitor including its laps, and the session and event, or with no competitor if nothing matched.3
TalentID records the run
The converter immediately upserts the telemetry record in TalentID, whether or not it goes on to convert. This is what makes the run visible in the Operator Dashboard even when conversion is pending or has failed.
4
GKL API supplies event and driver context
The converter asks GKL API whether the run happened on a race day, which decides where the output is filed, and what the driver’s power level was at that time. See Where GKL API Fits.
5
The data is converted and split
The binary is decoded against a DBC, normalised, forward filled, then split into laps using the timing. The result is exported as STL files.
6
The result is written back
The STL files are saved to S3 and their keys are posted back to TalentID. If anything threw along the way, the run is marked as a failed conversion instead.
How The Split Is Calculated
Each timing lap gives a racing time (elapsed time from session start at the point the lap ended) and a lap time. The converter derives the boundaries from those two:[lap_start, lap_end) become that lap. Three cases are handled beyond the simple one:
- Telemetry before the first lap. Anything recorded before lap 1 starts is emitted as a separate out lap, which is typically the drive out of the pits.
- Telemetry after the last lap. Anything after the final lap ends is emitted as an in lap.
- Missing telemetry inside a lap. If a lap has no telemetry at all, a NaN filled frame is generated across the lap at the resampling interval. If telemetry is merely short at either end, the gap is padded. Both cases log a warning naming the lap, competitor and session, so a lap that looks complete in the output may have been reconstructed.
Reconversion
Timing frequently arrives after the telemetry, so conversion cannot be a one shot operation. Two checksums drive the decision to redo it:
When either differs from what TalentID has recorded, the run is converted again and the previous STL files are deleted until the new conversion completes.
Where The Timing Comes From
AlphaTiming runs on the timing laptop at each hub region. Every time results are published, typically as each session finishes, it uploads the event timing JSON to the ingestion bucket. Nobody uploads it by hand. That means timing for an event arrives in pieces across the day rather than once at the end, and each upload re-imports the event with more sessions in it than the last.What Happens On Import
TalentID imports the file and publishes an event imported notification. The reconversion checker Lambda subscribes to it, asks TalentID which zips in that event’s region and time range now have a stale competitor checksum, and republishes each one onto the same ingest topic that a fresh upload uses, marked as coming from a timing import. The converter treats it the same way, except that it never forces conversion.Because AlphaTiming publishes per session, this cycle runs repeatedly through an event day. A run uploaded before its session results were published converts with no timing, then converts again with laps a few minutes later, without anyone touching it.
Triggering A Reconversion Deliberately
There is no button for this and no manual entry point to the checker. Three routes exist:
Re-uploading is best done from the track machine, because the run number is derived from local state. See Running A Conversion Locally for converting a zip on your own machine while investigating.
Where GKL API Fits
GKL API is not involved in the timing at all. It is called twice during conversion, both times for context that only the booking platform holds:
The second call is only possible because the TalentID competitor carries the GKL driver ID. A missing driver in GKL returns a 404, which the converter treats as an empty power level rather than a failure.
The telemetry converter authenticates to GKL API with a dedicated key held in Secrets Manager, separate from the keys used by the web applications.