As per a document I'm assuming Fred already sent you (If he did not, ask and I'll see if I can find it again)
Yes, this is the first thing I did, and asked him not to share on the forum as they're out of date and should not become a defacto standard. This is one of the things he meant by secrecy above.
Now that you have the packet read, you should de-escape the bytes. Once again that is documented in the protocol document which bytes mean what. Once all that wonderful magic is finished, you now have a complete datalog packet.
I sincerely hope that you do NOT do it like this!!!! Reading guts out of the packet before
deescaping and checksumming is completely
flawed! The packet must
be received, deescaped, and checksummed IN THAT ORDER
then can the header be read and the contents interpreted appropriately.
The datalog packet format <SNIP> but be advised, this is subject to change as the datalog format
will in the future be configurable.
The datalog packet format <SNIP> but be advised, this is subject to change as the datalog format has been configurable for more than two years.
Fixed! I've used it several times over that period when I've needed specific data at a higher frequency. You just have to change your external tooling to suit. Laborious, but only a little.
- where Open Source means Open Source, and Free means FreedomFreeEMS.org
- the open source engine management systemFreeEMS dev diary
and its comments thread
and my turbo truck!n00bs
, do NOT
PM or email tech questions! Use the forum!The ever growing list of FreeEMS success stories!