Spurious EOF in TRACES CSV file


In the initialisation sequence when the unit is started:

Note that there is an EOF (0x1A) shown in the hex dump, but it does not appear in the text of the AT command string

But, in the next command string:

The EOF (0x1A) does appear in the text of the AT command string!

This is causing grief with a command-line GREP utility - because it assumes (not unreasonably) that this marks the end of the file!

And similarly for subsequent commands:

Version Info:


Sounds like there’s another need to handle “non-printable” characters in UI/logs.
It’s already integrated for CR and LF (in the next release)… We’ll probably add EOF in the processing + maybe some configuration capabilites to handle chars not managed by default.