Rigol MSO5074 Logic Analyzer issues

[jerryk]

If this is a character LCD with an I2C interface via a I2C GPIO IC, then you will likely find that it is only using 4-bit mode.
Typically the 8-bit GPIO provide 4 data bits and 3 control signals to the parallel bus input of the LCD.
That would explain why you cannot find the letter "P" in the data stream.

That reality became evident shortly after I was able to get the initialization sequence working.  I could see all the hex values of the init commands stream by and the LCD turned on perfectly as commanded.  The reason it worked was because I sent the data in the init sequence in 8-bit mode and all the control bits default to 0.  I then sent the character stream of my name to the LCD.  It decoded perfectly and I could read it on the event table on the scope yet just the letter "o" showed on the LCD.  Now that understand that 4-bit mode is necessary for characters and that I will never see the decoded ascii characters on any LA, going forward should be a bit easier.  I also need a clearer understanding the 8 bit I/O expanders function.

Jerry

Jerry

[tggzzz]

If this is a character LCD with an I2C interface via a I2C GPIO IC, then you will likely find that it is only using 4-bit mode.
Typically the 8-bit GPIO provide 4 data bits and 3 control signals to the parallel bus input of the LCD.
That would explain why you cannot find the letter "P" in the data stream.

That reality became evident shortly after I was able to get the initialization sequence working.  I could see all the hex values of the init commands stream by and the LCD turned on perfectly as commanded.  The reason it worked was because I sent the data in the init sequence in 8-bit mode and all the control bits default to 0.  I then sent the character stream of my name to the LCD.  It decoded perfectly and I could read it on the event table on the scope yet just the letter "o" showed on the LCD.  Now that understand that 4-bit mode is necessary for characters and that I will never see the decoded ascii characters on any LA, going forward should be a bit easier.  I also need a clearer understanding the 8 bit I/O expanders function.

Logic analysers analyse bits. If you capture a nybble, any logic analyser will represent it as a hex character.

Protocol analysers analyse messages.

Choose your tool according to what you are trying to do.

Having said that, with a little practice it is possible to read holes in 8 channel paper tape (not 5 channel!). Thus, particularly if you know what you are looking for, mentally converting pairs of hex digits into the common ASCII character becomes second nature.

[Howardlong]

Having said that, with a little practice it is possible to read holes in 8 channel paper tape (not 5 channel!). Thus, particularly if you know what you are looking for, mentally converting pairs of hex digits into the common ASCII character becomes second nature.

I dunno, I used to read 5 hole paper tape and fix minor typos with my Algol programs using a manual hand punch and some spare chad back in the 70s.

It wasn’t that long ago that reading protocols like I2C off a scope trace with pen and paper was a thing.

[tggzzz]

Having said that, with a little practice it is possible to read holes in 8 channel paper tape (not 5 channel!). Thus, particularly if you know what you are looking for, mentally converting pairs of hex digits into the common ASCII character becomes second nature.

I dunno, I used to read 5 hole paper tape and fix minor typos with my Algol programs using a manual hand punch and some spare chad back in the 70s.

It wasn’t that long ago that reading protocols like I2C off a scope trace with pen and paper was a thing.

Tony Hoare's Algol-60 compiler on an Elliott 803 perhaps? I presume you have been to TNMoC, seen one working, and discussed the schematics?

Decoding serial ASCII, e.g. a UART, is a chore.

[Howardlong]

Having said that, with a little practice it is possible to read holes in 8 channel paper tape (not 5 channel!). Thus, particularly if you know what you are looking for, mentally converting pairs of hex digits into the common ASCII character becomes second nature.

I dunno, I used to read 5 hole paper tape and fix minor typos with my Algol programs using a manual hand punch and some spare chad back in the 70s.

Tony Hoare's Algol-60 compiler on an Elliott 803 perhaps? I presume you have been to TNMoC, seen one working, and discussed the schematics?

That's the one. It was donated to the school I attended by a local engineering firm. The pupils maintained it, self-taught, with negligible teacher involvement. There were a couple of teleprinters to write the code. One of my peers was especially good at fixing the teleprinters: a good job as they often went wrong.

The curator of the 803 at TNMoC is (or was) at the same school, a year ahead of me. We still occasionally chat on Facebook.

[tggzzz]

Having said that, with a little practice it is possible to read holes in 8 channel paper tape (not 5 channel!). Thus, particularly if you know what you are looking for, mentally converting pairs of hex digits into the common ASCII character becomes second nature.

I dunno, I used to read 5 hole paper tape and fix minor typos with my Algol programs using a manual hand punch and some spare chad back in the 70s.

Tony Hoare's Algol-60 compiler on an Elliott 803 perhaps? I presume you have been to TNMoC, seen one working, and discussed the schematics?

That's the one. It was donated to the school I attended by a local engineering firm. The pupils maintained it, self-taught, with negligible teacher involvement. There were a couple of teleprinters to write the code. One of my peers was especially good at fixing the teleprinters: a good job as they often went wrong.

The curator of the 803 at TNMoC is (or was) at the same school, a year ahead of me. We still occasionally chat on Facebook.

My local tech college had a donated 803, which I used during lower 6th. It was replaced in my upper 6th by a soulless Varian 620.

[Howardlong]

Back to the task at hand, note that one of the features of the Rigol is that of Search, where you should be able to search for I2C events, like I2C start, stop, restart, addresses and/or data.

Firstly, Search doesn't even work on the LA channels, quite an omission IMO.

Secondly, Search only seems to work reliably on trivial things with I2C like Start, Stop and restart, and just semi-reliably on Address and/or Data. It seems to work best when you first capture the trace, then manipulate your search on the captured result without Zoom.

Unlike Search, all of these options do work on the trigger (except sometimes on a Data trigger, the scope crashes when trying to assign the Bit X data: at this stage I tend to have to start again with the scope setup).

Note that when triggering or searching on data, byte(s) specified in the I2C packet only relate to byte(s) immediately after the address, although you can use XX for unimportant bytes. This does not help if you're looking for a particular byte at any point in a packet, such as a string search. Rigol is not alone in this, Keysight 3000T also behaves in the same way in search (but you can do this as a trigger). On the Tek MDO3000 & MDO4000 you can both search and trigger on any data byte in the backet being a certain value.

The implementation of I2C search on the Rigol seems to be a bit of a box ticking afterthought, not just in terms of functionality, but also in terms of flakiness, so much so that as soon as you start trying to use it you realise it's of little practical use. Stick to using I2C triggers and the Record function instead!