Your own protocol, decoded — without writing a parser.
Most devices speak a protocol no tool knows. In Trace you describe it in TrIML, a short XML definition: start byte, fields, length, checksum. From then on every telegram on the line appears decoded — live, searchable and with checksum errors marked.
No mail app set up? Write directly to support@trace-analyzer.net.
Access is currently free and granted on request.
- ✓ Definition instead of code
- ✓ Checksums: XOR, sum, LRC, CRC
- ✓ Named values and enums
- ✓ Dry run on sample bytes
From the wire to the telegram.
MiniBus, a typical made-up plant telegram: start byte, type, 16-bit address, length, payload, XOR checksum, end byte. Two good telegrams and one with a corrupted checksum.
This is the output of the definition next door, shown abridged (without STX, Length and ETX) — you can download it and load it into Trace. The third telegram carries 19 instead of 18 as checksum and is marked as FrameError.
From a protocol sheet to a live view.
Describe, don’t program
Constants, bytes, words, arrays with a length field, branches by type, repetitions, bitfields: the building blocks of a serial telegram are XML elements.
Every checksum checked
XOR, byte sum, LRC and a configurable CRC (width, polynomial, initial value, reflection) are built in. A wrong telegram is marked, not dropped.
Try it before you capture
In the hub you upload or edit the definition, paste sample bytes and see the decoded output right away. Every change is a new version with rollback; the next session decodes with it.
- SearchFull-text search across all telegrams, even in the live stream.
- RecordingRaw bytes and the finished interpretation in one .msf file.
- Multiple portsSeveral interfaces in one session, on a shared timeline.
- RemoteProbe at the machine, analysis in the browser — no inbound port.
What is still missing.
So you don't have to find the limits by trying:
- Byte streams only. TrIML describes serial byte streams (RS232, RS485, USB serial, CAN via the capture plugin). Bit-level buses such as SPI clock signals need capture hardware that delivers bytes.
- No scripting inside the definition. What cannot be expressed with the built-in elements — unusual checksums, stateful protocols — needs an extension of the engine.
- Timing-based framing is coarse on USB. Protocols that separate telegrams only by pauses work reliably up to about 19200 baud with ordinary USB adapters.
- You write the first definition. We help with it: send us a protocol sheet or a capture and we will sketch the definition with you.
The whole telegram in eleven lines.
This is the core of the MiniBus definition. The step-by-step tutorial in the TrIML reference builds it from scratch.
<const type="byte" value="0x02" name="STX" /> <byte name="Type" valuedescriptor="type-descriptor" /> <word name="Address" bigendian="yes" format="0x{0:X4}" /> <byte name="Length" /> <array sizeRef="Length" name="Payload" format="{0:X2}" /> <calc name="ExpectedChecksum" type="ByteXor" from="1" to="-1" resultType="byte" /> <const ref="ExpectedChecksum" validate="true" name="Checksum" format="0x{0:X2}" /> <const type="byte" value="0x03" name="ETX" />
Frequently asked questions
Do I have to learn a programming language?
No. TrIML is XML with a small set of elements, documented with a tutorial and a complete reference. If you can read a protocol table, you can write the definition.
What if my checksum is not XOR or CRC?
Built in are XOR, byte sum, word sum, LRC and a CRC with free parameters, which covers most protocols. Anything else, tell us — new checksum types are added to the engine, not to your definition.
Who can see my definition?
Only you, until you share it with your team. A definition you upload in the hub is private by default and appears in your own sessions.
Tell us about your protocol.
Tell us briefly what you are measuring. We will enable your access — and whatever you find missing goes straight into development.
No mail app set up? Write directly to support@trace-analyzer.net.