I've moved my reply here in order to not disturb that other thread. Here are the postings I'm referring to:
https://www.eevblog.com/forum/testgear/using-a-ucurrent-with-siglent-sds1204x-e-or-sds1000x-e-series-(feature-request)/msg1474694/#msg1474694https://www.eevblog.com/forum/testgear/using-a-ucurrent-with-siglent-sds1204x-e-or-sds1000x-e-series-(feature-request)/msg1475772/#msg1475772I hope Siglent will not just truncate the displayed data (that would be the simplest, 1 second fix to display only one line text ) but instead they will choose to properly display relatively long decoded packets.
The solution for this is not as straight forward as it might appear. All other decoders display just one data word per line in the list view, hence the message length is only limited by the maximum number of list entries specific for each decoder. The list scroll mechanism is based on the message rather than line number and there is a fixed one by one relationship between message and line. The list window can be configured to have 1-7 lines and chances are that a long multiline message does not fit the displayed list area. Of course all this could be solved, but would require some substantial redesign – just for IIC, as no other current decoder requires that.
The statements above are my personal speculation, but I think I cannot be far off. This is also backed by the fact that Siglent takes a slightly different route:
It has been confirmed that we’ll get a proper solution providing a separate text box (for the currently selected message in the list view I assume). This box will indeed be multi-line and show the complete message.
As a side note : it would be really cool if they could fix the horizontal scrolling of the decoded data as well (sorry if I am asking too much for a 1000 Canadian dollars oscilloscope).
Rest assured that the price shall not be an excuse for any serious flaws.
I take it you're referring to the decoding line at the bottom of the trace view.
As a basis for the discussion, just let’s recall the working principle, even when it’s obvious: since this scope always displays the complete record with all its sample data, you choose the actual record length by selecting an appropriate timebase. In your example you have set 5ms/div, which means a record length of 5ms x 14 = 70ms total (using 1.4Mpts @ 20MSa/s).
Normally, the decoding line would appear compressed and not readable with these settings. In your case, it is perfectly readable and shows the first message truncated by the start of the 2nd one, which in turn contains nonsense. I have never seen a behavior like this before (with short messages) so it certainly has to do with some data buffer overflow and management data being overwritten because of the current bug.
I happen to have a screenshot with the same timebase, but only short messages:

SDS1104X-E_Serial_I2C_Setup
Bottom line decoding is compressed and not readable.
Normally, you’d zoom in until the decoding line becomes readable – either by using the Zoom function during Run or setting a faster timebase in Stop mode after the acquisition is completed. Then you should be able to scroll horizontally by changing the X-position, thus shifting the zoom window and being able to view all parts of the entire message. Here’s an example, showing the last two messages of a long capture with a total of 652 packets:

SDS1104X-E_Serial_I2C_Stop100us_last
So it works as expected with short messages (up to 17 data bytes).
For long messages, the initial decoding line looks weird already and the procedure described above certainly won’t work right now because of the bug that essentially destroys the decoding. So this should certainly be fixed with the coming release as well.
Just let’s wait and see. If something still isn’t fixed or the fix is not satisfactory, we can always discuss it here in the forum as the basis for a solution in a future update.
BTW, the reason why you see an extra 80h byte without acknowledgement at the end of all my messages is because the current IIC decoder expects a high idle level on the SCL line. Even though this is a valid assumption for a properly designed IIC bus system, the decoder should still be robust enough to handle the slightly different situation in my test scenario and this is just another example for an improvement that we’re most likely going to see in the coming firmware release.
In fact I have asked for a status regarding the serial decoders in general and it has been confirmed that the majority of my change requests has been finished by now and will make it into the coming release as well.