Tachoparser decodes tachograph data into two top-level Go structs:Documentation Index
Fetch the complete documentation index at: https://mintlify.com/traconiq/tachoparser/llms.txt
Use this file to discover all available pages before exploring further.
Card for driver card files and Vu for vehicle unit files. Both are serialised to JSON by the dddparser tool. This page documents the major fields exposed in that JSON output, grouped by section. Each data block also carries a verified boolean that reflects whether its cryptographic signature passed validation.
The verified field
Every data block that carries a signature — overview blocks, activity arrays, events, faults, technical data — has a verified field in the JSON output. It is set to true only when all of the following conditions are met:
- The relevant public keys were loaded at startup (via
internal/pkg/certificates). - The certificate chain embedded in the file (ERCA root → member state → VU/card) decoded successfully.
- The block’s signature verified against its certificate and the block’s raw bytes.
verified remains false. Parsing itself still succeeds — only the verified field is affected.
Card data (-card)
Driver card files use TLV encoding. The Card struct holds every TLV-encoded section. Fields for the same logical section come in pairs: a _1 variant for 1st-generation data and a _2 variant for 2nd-generation data. Both variants may be present in the same file.
card_icc_identification — ICC chip identification
card_icc_identification — ICC chip identification
card_icc_identification_1 (TLV tag 0x000200) for 1st-generation data and card_icc_identification_2 (tag 0x000202) for 2nd-generation data.card_chip_identification — chip serial number
card_chip_identification — chip serial number
card_chip_identification_1 (tag 0x000500) and card_chip_identification_2 (tag 0x000502).driver_card_application_identification — application metadata
driver_card_application_identification — application metadata
driver_card_application_identification_1 (tag 0x050100) and driver_card_application_identification_2 (tag 0x050102). A v2-specific variant is also present as driver_card_application_identification_v2 (tag 0x052502).card_event_data — recorded events
card_event_data — recorded events
card_event_data_1 (tag 0x050200) and card_event_data_2 (tag 0x050202).card_fault_data — fault records
card_fault_data — fault records
card_fault_data_1 (tag 0x050300) and card_fault_data_2 (tag 0x050302).card_driver_activity — daily activity data
card_driver_activity — daily activity data
card_driver_activity_1 (tag 0x050400) and card_driver_activity_2 (tag 0x050402).card_vehicles_used — vehicles used records
card_vehicles_used — vehicles used records
card_vehicles_used_1 (tag 0x050500) and card_vehicles_used_2 (tag 0x050502).card_place_daily_work_period — place records
card_place_daily_work_period — place records
card_place_daily_work_period_1 (tag 0x050600) and card_place_daily_work_period_2 (tag 0x050602).card_identification_and_driver_card_holder_identification — driver identity
card_identification_and_driver_card_holder_identification — driver identity
card_identification_and_driver_card_holder_identification_1 (tag 0x052000) and card_identification_and_driver_card_holder_identification_2 (tag 0x052002).VU data (-vu)
Vehicle unit files use TV encoding. The Vu struct holds one overview block per generation (at most) and multiple activity, events, faults, detailed speed, and technical data blocks. Multiple blocks of the same type are common in real data.
vu_overview_1 — 1st gen overview
vu_overview_1 — 1st gen overview
0x7601) is the anchor for all 1st-gen signature verification. It embeds the MemberStateCertificate and VuCertificate at fixed offsets at the start of the block, followed by vehicle identification, downloadable period, card slot status, download activity data, company locks, and control activity data.vu_overview_2 / vu_overview_2_v2 — 2nd gen overviews
vu_overview_2 / vu_overview_2_v2 — 2nd gen overviews
0x7621) and its v2 variant (TV tag 0x7631) serve the same anchoring role for 2nd-gen signature verification. Certificates are stored in record arrays (MemberStateCertificateRecordArray, VuCertificateRecordArray) rather than at fixed offsets.vu_activities_1 — 1st gen activity blocks
vu_activities_1 — 1st gen activity blocks
0x7602). Each element covers one calendar day and contains the driver slot, co-driver slot, and the raw activity change byte stream.vu_activities_2 — 2nd gen activity blocks
vu_activities_2 — 2nd gen activity blocks
0x7622). The structure uses record arrays for driver, co-driver, and vehicle periods rather than the fixed-layout approach of the 1st generation.vu_activities_2_v2 — 2nd gen v2 activity blocks
vu_activities_2_v2 — 2nd gen v2 activity blocks
0x7632). Extends the 2nd-gen structure with GPS-authenticated accumulated driving records, border crossing records, and load/unload records.