malcom2073 wrote: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.
ONLY 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.