A high performance, flexible (but simple) CRC protected communication protocol for serial lines (like FBUS, RS232, RS485, etc...). Can also be stored in files or SDcard blocks

For the curious (developer of dataloggers, university projects, etc...)

Advantages over megatune protocol

Advantage over the AIM protocol

Advantage over SerialComm/SIPR (SIPR is a nice design, SIPR also bears the same advantages listed above)

More information is helpful especially during first startup

For example:

Now other events like commanded spark can be sent (and is actually sent since 1.1.90) in the triggerlog. Optionally ECU runtime data also. More and more information helps the installer when struggling through the first startup and verification of the setup => can save days (or weeks).


The generic format is:

HDLCbytestuffed( N*primtrig, datablock, type, CRC), 7e

0x7e is the frame marker. Anything in between the 7e markers is the HDLC bytestuffed packet.

HDLC bytestuffing is the industry standard:

Decoding is trivial (the inverse operation).


The realtime data is requested by READ_REALTIME_STUFFED_TYPE_COMMAND (32+128=160) that is a0, and modbus CRC is 38bf (but in little endian): a0 bf 38

to get the long response (>60 bytes).

v3 response is sent by the MTsendRTvar?_triggerlog() function (see comm.c in the firmware zip). So payload comes from MTsendRTvar?() function:

HDLC_bytestuffed_escaped_and_framed( <payload, 32>, 2byteLittleEndianModbusCRC( <payload, 32> ) )

where 32 is the RT_STUFFED_TYPE (yes, the type is always at the end of the packet, right before the CRC: there is very good reason for this, notably when the primary, secondary and other trigger events are logged and type is NOT known in advance).

See also


So for now one can use the old crappy megatune command ("A" => 56 bytes unframed, or "D" that is more than 56 bytes now) or one can use the new more robust commands.

We usually try to keep old compatibility commands until the new is reasonable, stable and works. Roadmap:

Note that (since 1.1.89) the triggerframe format can also be chosen for the SD-card inodes ("files"). This allows logging very special and rare events on the SD-card (like more details about occasional intermittent trigger-problem that happens 1-2 times a day) - very useful when analyzing engine operation (without this, the installer is almost completely in the dark, the traditional error code flags provide too little info).