Thanks for the update @JColvin; obviously not what we'd like to hear in so far as lack of resources behind the product but the communications is appreciated.
TBH, the dlog-utils code is... not great. The majority of the code is in type conversion and formatting (i.e. not germane to the actual processing of the data); I'm not surprised to hear it's problematic in updating it for OpenLogger as hard-coded assumptions on the data header abound (e.g. endianness; I presume the author is banking on that never changing, which may well be the case but it is in the format spec). As a reference implementation it hides the important data structure information in amongst language-specific type gymnastics. In contrast the Kaitai Struct approach removes all of that, and puts the data format front and centre, is trivially extensible (you update the struct definition and rebuild the library, done), and works "everywhere".
If it were my decision I'd dump the current dlog-utils and start again based on Kaitai Struct, the result would be:
a proper definition of the data format (rather than users having to reverse engineer the cpp code and troll the forums)
a couple of dozen of lines of code for the reference Digilent implementation
As an example, what is implemented in nearly 180 LOC dlog-utils.cpp is under a dozen lines in the dlog-utils-portable Python example (`dlog = Dlog.from_file(args.inputfile)` followed by a `write_csv`), with far greater flexibility in terms of handling future variations on data formats, and better output formatting 🙂
Given that Digilent have very limited resources for this project it's important they're used wisely, switching to Kaitai Struct is easily the best bang for buck we can ask for.
(BTW, it might sound like I'm a shill for Kaitai Struct - nope, I'm just a satisfied user and first discovered it when writing dlog-utils-portable... I once wrote code to process structured binary data in the same way as dlog-utils, but I've now seen the light 🙂