Fixed, we’ll be live on 2.2.16 probably
1 Like
On the 2nd part the issue was that the host software changed baud rates several times in a second, or so, where it would try one baud rate see if anyone responds, if not, it would try different one… Until something responds.
With this I was having some issues where the analyzer would not pickup the data at the new baud rate, even when there were gaps between their logical packets. I will try to capture this again, but may be slightly fickle to get again.
0th issue is when you are doing terminal output with Serial, and the output stream is using \r characters to terminate lines, the terminal just keeps going back to start of row overwriting the data.
Would be good to be able to choose what your line termination is. for the terminal output
Thanks for the detailed description 
I’m not sure what the right solution for something like that is. Feels like automation scripts code be useful…
Would be good to be able to choose what your line termination is
Would you like to add that to our feature requests board? I can to do as well
Thanks @rani -
I created a new feature request.
I suggested either allow the user to choose line terminations.
and/or
allow either CR or LF to advance to next line, but only advance once if both characters are found as consecutive characters.
2 Likes
Have the problem fixed yet ? I want to parse the log but facing the same issue !
@anhnguyen2345 Are you referring to the issue with the Packet ID not incrementing properly when using our I2C analyzer? If so, we unfortunately don’t have a fix for this yet.
We recorded this issue below, along with some potential workarounds in the meantime.