Rigol 1054Z I2C capture - advice for better equipment - Page 1
Forum section: electronics / testgear

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 01, 2021, 01:59:44 pm
content: I am currently using a Rigol 1054Z oscilloscope to capture and decode I2C traffic between an Arduino project and an MCP23017 chip. I have also used the 23S17 SPI version and this works fine but am having problems with the I2C version of the chip.I can capture a burst of traffic on the scope but am having difficulty collecting the data. If I expand the trace, it will show the decoded bytes on the screen but this is only a tiny fraction of the burst. The Event table will display the data in a list format, but only the fraction currently on the display. I can scroll through and view all of the decoded data, but for several 10s or even 100s of bytes that is a very tedious process indeed. If I compress the display to show the complete burst, the Event Table then shows gibberish so exporting to CSV is nugatory. The upshot is that I can't easily get at the complete data.I came across the thread here:https://www.eevblog.com/forum/testgear/rigol-scopes-serial-decoding/It discusses this issue on Rigol scopes although the author claims that he can display the complete dataset provided that it exists within the capture window and he shows examples. He is using a DS4000. Further information in the thread suggests that this is not an issue on the DS2000 either.I do have a cheap 'Logic 16' analyser which I tend to use with Sigrok but it seems to crash quite regularly. I tried it with the Salaea software but this mixes up the channels making it unusable only with extreme difficulty and there are questions over the legality of doing so.I would therefore like to find another solution. I looked at Saleae, but with the 16 way analyser costs a riddiculous £875GBP. For that price I might as well look at something like the Rigol MSO5000. Adding the probe does push the price up to around 1,300GBP by the time VAT is added, but at least I am getting a complete scope. I can't really afford the Keysights or Teks and am really finding it hard to justify even the cost of the MSO5000 for casual hobby use. The question is, whether the capture problem is fixed on that model and whether it will decode all the data within the capture window and correctly display it in the event table and let me save it to USB?Also, is there another option for an LA that will cost much less than the Saleae? Ideally I am looking something reliable that will cost no more than the £200 mark (ok, perhaps £250 at a real push)? There must be something in-between that is not as expensive as the Salaea, but far more reliable than the cheap <50GBP stuff?

author: Venturi962
author_rank: Regular Contributor
timestamp: June 01, 2021, 02:10:30 pm
content: Perhaps something like DSLogic Plus?https://www.dreamsourcelab.com/shop/logic-analyzer/dslogic-plus/Discussion:

author: rstofer
author_rank: Super Contributor
timestamp: June 01, 2021, 04:19:26 pm
content: The Digilent Analog Discovery 2 or Digital Discovery will do an excellent job with I2C. Besides the obvious trace display, there is a table of decoded bytes.https://store.digilentinc.com/digital-discovery-portable-usb-logic-analyzer-and-digital-pattern-generator/https://store.digilentinc.com/analog-discovery-2-100msps-usb-oscilloscope-logic-analyzer-and-variable-power-supply/

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 01, 2021, 04:40:25 pm
content: Not seen the DsLogic Plus before. There seems to be some controversy with Sigrok, but that aside it is interesting and if it works well then might be worth a punt. I will have to hope that it plays nicely with my existing Sigrok installation although it ought to be possible to integrate the driver into the exiting libsigrok sources.Also just seen this thread:https://www.eevblog.com/forum/testgear/usb-logic-analyzer-recommendation/25/Someone mentioned using a BusPirate which I just happen to have but it didn't occur to me to use. It has an I2C sniffer built in which outputs the raw data. For example:Code:[0x42+0x0A+0x08+][0x42+0x08+0x00+][0x42+0x04+0xD0+][0x42+0x00+][0x43+0xFF-][0x42+0x00+0xFF+][0x42+0x12+][0x43+0xFF-][0x42+0x12+0xFF+][0x42+0x13+][0x43+0xFF-]Its a bit crude, but does give me the data for a complete event all in one burst rather than having to scroll through snippet by snippet at a snails pace. Each packet of data enclosed in brackets gives me the bytes being written/read, although I am not sure how the leading 0x42 and 0x43 relates to read and write for HW address of 0x21?Code:Searching I2C address space. Found devices at:0x42(0x21 W) 0x43(0x21 R) 0xFE(0x7F W) 0xFF(0x7F R)In any case, I could probably write a Python script to process the information into something more presentable, but for now, it does provide a solution so long as the bus speed does not exceed 100kHz.Long term, I think I would still like to get a decent LA or MSO type scope though.I had forgotten about the Analog Discovery. Missed out on one on eBay a while back, but the price got too close to the brand new cost. Don't know much about Digilent, but the product does seem to be a bit of a jack of all trades - oscilloscope, LA and more.

author: Nominal Animal
author_rank: Super Contributor
timestamp: June 01, 2021, 05:04:52 pm
content: Quote from: WaveyDipole on June 01, 2021, 04:40:25 pmFor 7-bit addressing, the I2C HW address is 7 bits, and is followed by the read/write bit.So, for HW addressA, the leading value will be 2A+1 for a read operation, and 2Afor a write operation.Thus, 0x42 is a write operation on HW address 0x21, and 0x43 is a read operation on HW address 0x21.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 01, 2021, 05:19:27 pm
content: Quote from: Nominal Animal on June 01, 2021, 05:04:52 pmAh! That now makes sense. Thank you.

author: mawyatt
author_rank: Super Contributor
timestamp: June 01, 2021, 07:01:38 pm
content: I've never used a Logic Analyzer before, analog type and been out of the lab since the 90s doing advanced IC design. Retired a few years ago and now have my own lab and knew it needed the LA capability. The Siglent SDS2102X+ we have uses a somewhat expensive LA so got involved with a DIY LA here:https://www.eevblog.com/forum/testgear/diy-logic-analyzer-probe-and-pods-for-siglent-scopes/My first use ever was trying to get a Analog Devices Multi-Channel DAC Eval PCB up and running, this proved successful and you can follow the threads on this above.The nice feature of this Siglent DSO type is that all the active electronics are built-in, so the LA feature becomes a passive design which was accomplished with a couple external PCBs and 3D printed cases as shown.Now we need to get more analog traces along with the digital, so a 4 channel is being consideredAnyway, since I've had no experience with a LA and able to get a DIY LA up and working with some useful work right from the start, I'm sure more knowledgable folks here could easily do this and have a really good scope and LA together.Anyway, just a thought.Best,

author: nctnico
author_rank: Super Contributor
timestamp: June 01, 2021, 07:10:35 pm
content: Quote from: WaveyDipole on June 01, 2021, 01:59:44 pmThe biggest question is: is your problem in the analog or digital domain? Have you tried to lower the speed of the I2C bus and see if the problem goes away? Are the logic levels OK (both chips powered from the same voltage) ?Throwing a logic analyser at the problem could help but if the problem is in the analog domain you can only see something goes wrong but not what is going wrong. Something like the DSlogic could be a cheap option but maybe it is time to upgrade your oscilloscope.

author: Adrian_Arg.
author_rank: Frequent Contributor
timestamp: June 01, 2021, 08:12:54 pm
content: I am a hobbyist, I also own a Rigol ds1054z (Released), but I chose to buy an 8-channel 24Mhz logic analyzer, since it seems to me that it is more practical than the oscilloscope and I can use both tools at the same time, I2C and SPI do not I have had no problem with the clone saleae

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 01, 2021, 08:36:52 pm
content: Quote from: mawyatt on June 01, 2021, 07:01:38 pmThanks. I will have a read. There's a similar thread discussing a DIY approach to the Rigol PLA2216 probe.Quote from: nctnico on June 01, 2021, 07:10:35 pmThat is a good question and partly why the DS1054Z was deployed as opposed to the cheap LA. The LA can see logic levels, but the scope can also see the traces on an analog level and would allow me to see whether noise or crossover effects were a factor. They are not. Also, unlike my LA, it doesn't crash every couple of minutes! The Arduino and the MCP23017 chip are both powered from the same supply and I have confirmed the voltage at the VDD pin on the chip with reference to the common ground. The DS1054Z also correctly shows the peaks on the I2C traces at the expected 5v level. I haven't yet tried to lower the speed of the bus. My intent was to verify that what was being written/read over I2C is actually consistent with what is being sent and received. To that end a quick bit of Python has made the output from the BusPirate a bit more readable:Code:Processing test2.dat...> r 0x21 0x0A 0x08> r 0x21 0x08 0x00> r 0x21 0x04 0xD0> r 0x21 0x00> w 0x21 0xFF> r 0x21 0x00 0xFF> r 0x21 0x12> w 0x21 0xFF> r 0x21 0x12 0xFF> r 0x21 0x13> w 0x21 0xFFEnd.Ok, it won't mean anything to anyone, but AFAIKT on comparing the output to the expected result, it looks 100% correct each time the process it is run, so it may be that the I2C comms are not the issue here. Certainly, lowering the bus speed might be worth a try. It could also be that my approach to coding the I2C comms is not correct in some respect but on the other hand the SPI version, which uses the same code except for the communication protocol, works just fine, yet SPI runs much faster. The only difference between the MCP23017 and MCP23S17 chips is the comms protocol. My basic tests which involved just turning LEDs on and off worked perfectly fine with both chips and pin states changed on demand as expected. I have some more headscratching to do for sure.Quote from: nctnico on June 01, 2021, 07:10:35 pmThat's the decision I am currently contemplating, i.e. whether to bite the bullet on a new mixed signal oscilloscope and kill two birds in one stone so to speak. The DS1054Z is strictly a DSO rather than an MSO and as I have discovered, is not the most useful instrument for decoding serial buses, which is why an LA also has a useful place. I only wish mine didn't keep crashing during signal capture. I also have a couple of old analog scopes knocking around which get used primarily for vintage tech. If I purchase an MSO5074, then one or more of the other scopes may have to go. I haven't decided yet and for a while have been thinking that replacing the LA would be cheaper. I do need 16 channels so the cheaper 8 channel versions are out. However, it will depend on what options are out there. Much will also depend on how easy it is to get the captured data out of an MSO5074 onto the PC when needed. If anyone has experience of that, a comment would be appreciated. Here is where LA's have an advantage as the capture is already done on the PC. I therefore appreciate the mentions of the DsLogic Plus and the Analog Discovery, but are there any others worth considering?

author: nctnico
author_rank: Super Contributor
timestamp: June 01, 2021, 09:00:09 pm
content: Quote from: WaveyDipole on June 01, 2021, 08:36:52 pmLooking at your screenshots more closely I have to say the levels on the SCL line look too low. I think that things will start to work better with stronger pull-ups or lower speed. One of the downsides of I2C is that the high and low levels are very close to the supply lines. Great for noise immunity but not so great for dealing with lower logic levels. IIRC the I2C specs say that the levels must be below 0.3 * Vcc for a low and over 0.7 * Vcc for a high. To have some margin I usually design for 0.15 * Vcc for a low and over 0.85 * Vcc for a high and have (ball-park) 75% of the top of the pulse width flat.

author: Fungus
author_rank: Super Contributor
timestamp: June 02, 2021, 09:35:09 am
content: Quote from: nctnico on June 01, 2021, 09:00:09 pmYep. Judging by those screenshots OP definitely needs stronger pullups.Lower the resistance of the pullup resistors until those clock pulses look square at the top.(or add more pullups along the bus - same thing)

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 02, 2021, 07:16:37 pm
content: I think I have figured out what the problem was. It was related to the MCP IntA interrupt which was not being triggered due to an incorrect assumption on my part.Regarding the pull-ups, I agree that the tops of the waveform do look a bit ragged. This is probably because I don't have any pull-up resistors on the CLK or SDA line at present. From the comments it sounds like I ought to add some, but what value would I use? Typically, one might use 10kΩ or 4.7kΩ on GPIO pins. Would that be an appropriate starting point for the I2C pins as well? I will hopefully have a bit of time to experiment tomorrrow and can try a range of values. nctnico, thank you for the detailed information and both you and Fungus for the suggestion.

author: nctnico
author_rank: Super Contributor
timestamp: June 02, 2021, 07:21:22 pm
content: 10k Ohm is a good starting point for pull-ups for a 5V supply. For 3.3V and lower I usually use 4.7k Ohm.

author: tooki
author_rank: Super Contributor
timestamp: June 02, 2021, 07:43:47 pm
content: Quote from: WaveyDipole on June 02, 2021, 07:16:37 pmI2C is an open-drain bus, so pull-ups are mandatory. I concur with starting with 10K.

author: Fungus
author_rank: Super Contributor
timestamp: June 02, 2021, 09:40:54 pm
content: Quote from: WaveyDipole on June 02, 2021, 07:16:37 pm4.7k is the "standard" value (used in the i2C spec) but I've used valuesmuchlower than that, eg. 470 Ohms.Quote from: WaveyDipole on June 02, 2021, 07:16:37 pmThen it shouldn't be working at all!(There must besomethingin the system with pullups...or your chips are actively driving the line high)

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 04, 2021, 08:18:47 am
content: Then I guess I am fortunate it was working at all. I had a trawl through the Mega 2560 datasheet and found that it does state that pull-ups are required, although it does also mention that there are internal pull-ups. I did wonder whether the Wire.h library enabled them and found a discussion on the subject here:https://forum.arduino.cc/t/i2c-with-internal-pullups/355691/5It seems that Wire.begin() does indeed enable the internal pull-ups, but apparently they are rated at a much higher value than I2C specifies. That might explain why it worked, but why the waveform was so distorted at the top. I initially tried external 10kΩ resistors but that made no real difference. Another attempt using 4.7kΩ fared a little better and the top of the wave was beginning to square, but the result was still very rounded. In the linked thread there is a recommendation to use 2.2kΩ resistors, but since I didn't have that value to hand, for the third attempt I used 1kΩ resistors and finally the result is a waveform that looks much better with the tops nice and square.Thank you for bringing the matter to my attention. I will include the pull-ups in the final design.UPDATE: just had the thought of putting two 1kΩ resistors in series. The screenshot (second photo) with 2kΩ pull-ups shows that this does work but the result is not nearly quite as clean. I am going to stick with 1kΩ I think.

author: nctnico
author_rank: Super Contributor
timestamp: June 04, 2021, 05:52:08 pm
content: 1k Ohm pull-ups are too low. Stick with 4.7k Ohm at the lowest.

author: rstofer
author_rank: Super Contributor
timestamp: June 04, 2021, 06:14:11 pm
content: I usually use something around 2.2kSection 7.1 of this document (I2C Standard) covers the calculationhttps://www.nxp.com/docs/en/user-guide/UM10204.pdfIn the end, resistor sizing depends on bus capacitance (which is probably a wild guess) and data rate.

author: Venturi962
author_rank: Regular Contributor
timestamp: June 04, 2021, 06:19:29 pm
content: One more piece of information, the Mega 2560 has Internal Pullups of 20K to 50K on I/O Pins, from the datasheet (Page 355)." alt="" class="bbc_img" />

author: BobRyan
author_rank: Contributor
timestamp: June 04, 2021, 10:30:33 pm
content: Another option is exporting the raw data from the scope and converting it for use in software like sigrok.I hacked togetherhttps://github.com/BobRyan530/sigctlto do this on a siglent-manufactured scope a couple years ago.

author: Fungus
author_rank: Super Contributor
timestamp: June 05, 2021, 04:53:41 am
content: Quote from: BobRyan on June 04, 2021, 10:30:33 pmYes, but that's slow and horrible.Me? I'd use the scope to make sure the bus is OK (good pullups) then use an I2C bus sniffer to capture the data to look at on on my PC. You can get them for Arduinos, etc.

author: HarryDoPECC
author_rank: Regular Contributor
timestamp: June 05, 2021, 07:06:17 am
content: 1) Check electrical implementation with scope2) Check data implementation with Bus Pirate.https://core-electronics.com.au/bus-pirate-v3-6a.htmlBus Pirate is your friend!

author: Karel
author_rank: Super Contributor
timestamp: June 05, 2021, 07:28:00 am
content: Quote from: nctnico on June 04, 2021, 05:52:08 pmMaybe if you want to conserve power. Otherwise 2K2 is fine (assuming Vdd is 3.3V).

author: nctnico
author_rank: Super Contributor
timestamp: June 05, 2021, 11:01:02 am
content: Quote from: Karel on June 05, 2021, 07:28:00 amThe OP uses a 5V system. You also need to be aware that large currents have to flow through the die of the chip and there often is a limit to the total current. A few LEDs and low-value pull-ups can eat into the budget quickly.

author: Fungus
author_rank: Super Contributor
timestamp: June 05, 2021, 11:13:50 am
content: Quote from: nctnico on June 05, 2021, 11:01:02 amIt's relative though. Pullups only use power when there's traffic on the bus. If there's not much traffic then not much power...

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 06, 2021, 09:41:32 am
content: Quote from: nctnico on June 04, 2021, 05:52:08 pmNoted.Quote from: rstofer on June 04, 2021, 06:14:11 pmThe 20cm length of the connecting Dupont wires would undoubtedly add to the capacitance, especially as the pair is still stuck together, which would not have helped. PCB tracks would be much shorter.It seems then, that the final consensus is either 4.7kΩ or 2.2kΩ. It doesn't sound like its going to be that critical, but I will avoid going as low as 1kΩ. Just to confirm, the Arduino in use is a 5V system so I am leaning towards 4.7kΩ.Quote from: BobRyan on June 04, 2021, 10:30:33 pmBob, it seems you have put in a lot of work to make that possible on the Siglent. Maybe it could be adapted for the Rigol. Does this capture a triggered burst of data or does it have to be a running stream? I would be looking to download and process the 'frozen' memory content present after a single triggered event.Quote from: Fungus on June 05, 2021, 04:53:41 amI had occurred to me that the scope might not be the best way to go for LA capabilities. Even the MSO5000 appears to be limited to just 4 protocols in its firmware. Granted they are the most common ones, but it does not support one of the protocols I am working with. Sigrok currently supports at least 16 protocols and more can be added. As pointed out, the scope is the tool to show the signal on an analog level. Granted an MSO can also show signals on a logical level, but there seem to be limitations in terms of the number of supported protocols and the ability to export the data. While being able to view data in real-time on the oscilloscope screen can be useful, being able to easily export it for reference and for working with offline is essential. It seems to me that a standalone LA is likely to be more flexible in this regard. Data is already right there on the PC, and a full range of protocols is supported. In the end, I guess it comes down to using the right tool for the right job.The DsLogic seems to be the way to go although it also occurred to me that at a push I could also use a spare Cypress FX2 development board I have with Sigrok.

author: RoGeorge
author_rank: Super Contributor
timestamp: June 06, 2021, 10:11:42 am
content: Quote from: WaveyDipole on June 01, 2021, 01:59:44 pmRigol DS1054Z is in the supported hardwarelist by sigrok.Have you tried DS1054Z + sigrok for decoding I2C on the PC?

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 06, 2021, 02:36:36 pm
content: Quote from: RoGeorge on June 06, 2021, 10:11:42 amNo, up until now I had not tried this, but having just experimented for the best part of an hour it was not very successful. PulseView supports the Rigol-DS driver and can detect the scope but could not capture anything. It also crashes quite frequently and is no longer supported. SmuView does not connect to the Rigol-DS driver when specified on the command line although it does list it in its Connect to Device dialog. However, selecting the driver, providing the IP address and then clicking the scan button does not find the 1054Z, so I couldn't do anything further with it.I also downloaded and compiled a program called DsRemote. This does connect to the scope but is slow and painful to use. It has the tendency to get rather out of sync with the scope display and I could not get the decoder to work - although it did display it briefly without any decoded data, once. The program might be useful for remote control of the scope but not much more than that.It ought to be possible to capture the raw frame data using the CLI but it would then require processing using something like a conversion and adaptation of Bob's script to decode it. Seems like a lot of messing about. At least BusPirate shows the actual bytes being transmitted and it was relatively simple to put together a small script to make the presentation of the output clearer.I am definitely considering the purchase of a DsLogic LA as it seems the better solution and is significantly cheaper than the Saleae. Unfortunatly it can't be purchased in the UK, so there will probably be import costs which is holding me back at present. Has anyone tried the DsLogic U3 Pro? Is there much advantage other than USB3.x speed vs USB2.x? The price difference is quite considerable.

author: RoGeorge
author_rank: Super Contributor
timestamp: June 06, 2021, 03:18:43 pm
content: I have a DSlogic and never needed it. So far DS1054z decoding was enough for me.AFAIK DSlogic is using sigrok, too, so if sigrok is crashing on your PC, most probably DSlogic's sigrok will also crash. I think DSlogic's sigrok is called DSview, a slightly customized and renamed PulseView. Didn't worked very well on Linux last time I tried it.DSlogic is nice for being able to set the voltage level of its digital I/O, but other than that it didn't impress me. Also, on the very high sample rate there are reflections on the wires, so it'll be a lot of fake digital wiggling around the signal's edges.Found it cumbersome to use, hard to trigger, and the live mode was not as live as an oscilloscope. Also it's USB is not galvanically isolated from the PC. IMO all logic analyzers are a distraction to use in practice, good only for didactic purposes, but nothing more.

author: Karel
author_rank: Super Contributor
timestamp: June 06, 2021, 05:51:58 pm
content: Quote from: WaveyDipole on June 06, 2021, 02:36:36 pmUnfortunately, I2C hasn't been implemented yet (RS232 and SPI decoding works fine, much better than on the scope itself because DSRemote can decode everything that's in memory, not just what is visualized on the display.).Some people make the mistake to change setings on the scope itself instead of using DSRemote.In that case they get out of sync, that's not the fault of DSRemote however. There's no way for DSRemote to be awareof any change of settings done directly on the scope.Regarding the speed, this is due to the super slow firmware of the scope. After sending a command to the scope, it takes a long time for the scope to respond.There's nothing that can be done about that (except maybe Rigol).p.s.: What you see in the attached screenshot is a long string decoded using DSRemote & Wave inspector.With the Wave inspector you can download the whole 24Mpts and scroll through the waveform and see the decodedRS232 characters without getting the decoded data garbled.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 06, 2021, 09:24:37 pm
content: Quote from: RoGeorge on June 06, 2021, 03:18:43 pmYes, it uses their custom version of libsigrok and libsigrokdecode and you are correct: DsView is their custom version of PulseView so you make a fair point.Quote from: Karel on June 06, 2021, 05:51:58 pmAh, that would explain it! I guess the available option on the decoder menu is a placeholder for now then?Quote from: Karel on June 06, 2021, 05:51:58 pmI must admit that when I made a change in the program and the scope did not respond then I did make adjustments on the scope. That might explain what happened then and I take your point.Quote from: Karel on June 06, 2021, 05:51:58 pmAgain, point well taken. I was connected over Ethernet, but even that is not going to compensate for slow firmware. Sometimes the scope can be frustratingly slow doing simple things like adjusting the Y position on a channel so this is not entirely surprising.Quote from: Karel on June 06, 2021, 05:51:58 pmUnfortunately what I need at present is I2C decoding. If Wave Inspector will download the whole 24Mpts for I2C decoding in the future then DsRemote will be worth revisiting. In the meantime I will keep it as a remote control and screen display tool in addition to lxi-tools (lxi-gui is very handy to capture screenshots from the DS1054Z on Linux). Any idea whether and when the I2C decoder will be ready? In the meantime, I appreciate it all takes time and am grateful to the author for making the project available.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 08, 2021, 01:10:34 pm
content: Does anyone know whether the Hantek 4032 plays nicely with Sigrok? From what I can gather, Hantek's software can be a bit flaky but the hardware is supposed to be decent.

author: tggzzz
author_rank: Super Contributor
timestamp: June 08, 2021, 01:19:51 pm
content: General principle:use a scope to ensure the signal integrity of theanaloguewaveforms. Once you are certain the analogue waveforms will be correctly interpreted by the receiver, flip to debugging digital signalsto debug digital signals, use a digital tester. That could be a conventional logic analyser (some are extremely cheap), or something in the "bus pirate" category of protocol decoders, or printf statements

author: Electro Fan
author_rank: Super Contributor
timestamp: June 08, 2021, 02:32:07 pm
content: Quote from: WaveyDipole on June 06, 2021, 02:36:36 pmAnyone have any experience or thoughts on the usefulness of the USB 3 version vs the USB 2 version? Thx