DS1000Z series serial decode - Page 1
Forum section: electronics / testgear

author: Howardlong
author_rank: Super Contributor
timestamp: October 22, 2014, 07:39:23 am
content: FolksIt's already documented on here that the serial decode for the DS1000Z series scopes only deocdes what's shown on the screen, even with the event table list, rather than what's in memory, and then only up to a few bytes before it undersamples and fails to decode. (If I'm missing something, please let me know!)Has anyone a simple process that will take the CSV memory waveform and generate a fully decoded list? I looked at sigrok and although it looks like it might do it, I was spending too much time understanding how to use it, in fact more than writing my own code to do an I2C decode. It looked like I was going to have to write a translation filter at least. Perhaps there's somehing I'm missing here too.I already spent a couple of hours hacking my own I2C decoder, hard coded to Ch1 and Ch2 for SDA and SCK, and if no other othions are available I'll finish that off, but I fear it'll end up being a much bigger project by the time I finish, as I'll want to add LA channels, SPI, RS232 etc.Cheers, Howard

author: Fungus
author_rank: Super Contributor
timestamp: October 22, 2014, 10:03:48 am
content: Quote from: Howardlong on October 22, 2014, 07:39:23 amIt decodes whatever's shown on screen. You can record for several seconds then use the zoom/scroll features to look at the recorded data. The recording time depends on the sample rate you choose.It also has alotof trigger options for I2C so you can wait for anything from a "start" up to a particular address/data before you start recording.Quote from: Howardlong on October 22, 2014, 07:39:23 amNot sure what that means but obviously a specialized device would be better if your main interest is I2C sniffing.Maybe an Arduino with a nice PC software interface ... :-)

author: Howardlong
author_rank: Super Contributor
timestamp: October 22, 2014, 06:22:49 pm
content: I already have both a Logicport and an Agilent 54831D MSO that do this, but I was looking for something that would work with the Rigol if possible.The Logicport is great, but runs out of memory quickly on long serial decodes.The Agilent works too but you have to work with it to get the answer you want.Using the Rigol as you suggest is painful if you have anything more than a few dozen bytes. While I understand that it can be fairly CPU intensive doing the decode, I'd have hoped it might've done a more comprehensive job, especially if you ask it to save the result as a CSV.Having the serial decode available as a listing is frequently my preferred option when it's of significant length.Cheers, Howard

author: Fungus
author_rank: Super Contributor
timestamp: October 22, 2014, 07:51:36 pm
content: Quote from: Howardlong on October 22, 2014, 06:22:49 pmYep, I imagine so.Entering trigger parameters via the multifunction knob is quite painful, too.

author: Kohanbash
author_rank: Regular Contributor
timestamp: October 22, 2014, 10:53:16 pm
content: Have you looked at the Salae Logic devices.https://www.saleae.com/I have borrowed one many of times, and it has been a great help for debugging.

author: Electro Fan
author_rank: Super Contributor
timestamp: October 22, 2014, 11:10:35 pm
content: Quote from: Howardlong on October 22, 2014, 07:39:23 amMaybe this has already been addressed (sorry if it has) but how much different/better is the DS or MSO2072A than the DS1000Z in this respect? Or does the 2000 series have the same limitation? (My experience with the DS2072 has been that it decodes more than what is shown on the screen but maybe I'm misunderstanding something.) Thx

author: Howardlong
author_rank: Super Contributor
timestamp: October 22, 2014, 11:39:07 pm
content: Actually it's the MSO1084Z-S that I have. On both analog and LA channels, the decode is only what's on the screen, not what's in memory. I wrote a filter translator to convert the memory CSV generated by the Rigol into binary for sigrok earlier today, now I am just battling with sigrok.Not sure about why I would buy a Saleae when I already have a Logicport? Are they better in some way?

author: Kohanbash
author_rank: Regular Contributor
timestamp: October 23, 2014, 02:09:24 am
content: Quote from: Howardlong on October 22, 2014, 11:39:07 pmThat's true. I have not used the Logicport so I can not give you any comparisons.

author: Pinkus
author_rank: Frequent Contributor
timestamp: October 23, 2014, 07:44:11 am
content: Quote from: Kohanbash on October 23, 2014, 02:09:24 amThe Saleae is a toy compared to the Logicport. Just download the free Logicport Software fromwww.intronix.com(the demo mode will act as if the hardware would be connected) and and compare it to the Saleae stuff.

author: Fungus
author_rank: Super Contributor
timestamp: October 23, 2014, 09:37:09 am
content: If your main interest is "sniffing I2C with csv output" then I still think it would hard to beat an Arduino dumping all I2C traffic to the serial port. You can capture the output with any terminal program, eg. putty.All you need is a suitable sketch to handle the Arduino's I2C module (which is a nice little state machine - very easy to program directly, see the Mega328 datasheet).I'd be very surprised if that sketch doesn't already exist.Bingo! Two seconds with google turned up this:http://hackaday.com/2011/05/21/arduino-i2c-sniffer/(and plenty more...)

author: MarkL
author_rank: Unknown
timestamp: October 23, 2014, 04:35:44 pm
content: Quote from: Pinkus on October 23, 2014, 07:44:11 amAm I reading it right the Logicport can only buffer 2048 samples? Is that a misprint?

author: hobbified
author_rank: Newbie
timestamp: October 23, 2014, 04:51:40 pm
content: Quote from: MarkL on October 23, 2014, 04:35:44 pm2048 on the device, zillions on the host PC. The Saleae is the same way. Your buffer depth is only limited by the RAM on the host PC,as long asyour USB processing is fast enough that you don't start dropping samples.

author: MarkL
author_rank: Unknown
timestamp: October 23, 2014, 10:03:13 pm
content: Quote from: hobbified on October 23, 2014, 04:51:40 pmI realize we're a little off-topic in this thread, but are you sure about that? The 2048 sample buffer is a FIFO for the USB stream of samples to the PC?A little bit of searching digs up a bunch of owner complaints about the small memory size, and the Intronix manual refers to its "Fast acquisition rate" of 4 acquisitions per second, implying it's doing acquire then transfer. Plus the software in demo mode never has more than 2048 samples, and maintains a separate count for the acquisitions.Forgive me if you have one of these and it works as you say. I'm only going by what I read and I haven't seen anything about it streaming the data.The Saleae does stream the data, as you say.

author: Fungus
author_rank: Super Contributor
timestamp: October 23, 2014, 10:15:15 pm
content: Quote from: MarkL on October 23, 2014, 10:03:13 pm

author: rolycat
author_rank: Super Contributor
timestamp: October 23, 2014, 11:15:05 pm
content: Quote from: Fungus on October 23, 2014, 10:15:15 pmAlthough the buffer has only 2048 entries per channel, it stores transitions, not continuous samples like the Saleae. In addition, it has extensive triggering options including a holdoff which can count trigger events.It's definitely not useless.

author: Maxlor
author_rank: Frequent Contributor
timestamp: October 23, 2014, 11:27:50 pm
content: It's indeed 2048 samples per channel for the logicport, but they only need to record state changes. Should be enough for 100 or so I2C bytes. It's pretty limited, but I wouldn't go as far as calling it useless.I'd probably just use a Saleae too. Their software is a bit limited, but you can export the recording as CSV and run more analysis on that if necessary.

author: pascal_sweden
author_rank: Super Contributor
timestamp: October 23, 2014, 11:37:01 pm
content: Anybody out here who has experience with sigrok?http://sigrok.org/They also support Rigol scopes. Is sigrok any good or just a toy?

author: miguelvp
author_rank: Super Contributor
timestamp: October 24, 2014, 09:27:24 am
content: Quote from: pascal_sweden on October 23, 2014, 11:37:01 pmWhat I've heard about Rigol support is that it won't do protocol decoding out of waveforms, just for models with logic analyzers.So I never tried it. But I might be mistaken and it does work, since this was over 6 months ago.

author: Howardlong
author_rank: Super Contributor
timestamp: October 24, 2014, 10:41:16 am
content: Quote from: rolycat on October 23, 2014, 11:15:05 pmI agree, one should not underestimate the value of run length encoding, but 2k/ch is still a bit limiting, I'm frequently frustrated by it. And it's certainly way, way better than the DS1000Z series serial decoder.

author: Fungus
author_rank: Super Contributor
timestamp: October 24, 2014, 11:09:02 am
content: Quote from: Howardlong on October 24, 2014, 10:41:16 amOK, "2048 bytes of RAM" isn't the same as "2048 samples".(and it's a bit cheapskate on a device that expensive).Quote from: Howardlong on October 24, 2014, 10:41:16 amedit:Speaking of Saleae devices: There was a thread the other day on the Arduino forums where a guy was using one and seeing a short extra pulse after the start bit on RS232 communication. I guessed it was the Saleae device seeing ringing on the line as an extra pulse. Placing the probe directly on the Mega328's TX pin instead of on his breadboard made the pulse vanish, so that's probably what it was.He'd have been able to see that on a Rigol DS1000Z ...

author: biot
author_rank: Regular Contributor
timestamp: October 24, 2014, 02:45:31 pm
content: Quote from: miguelvp on October 24, 2014, 09:27:24 amYou heard right: we don't have the analog->logic conversion yet that would be needed to feed data into libsigrokdecode (which does have I2C, UART etc decoders).

author: Howardlong
author_rank: Super Contributor
timestamp: October 24, 2014, 09:21:28 pm
content: I now have a bit of code hacked to take a CSV generated by the Rigol into the binary format required by sigrok. After a bit of frustration, I finally got sigrok to read the file and generate an I2C decode. However the result isn't very useable as is. If I convert the binary format to sigrok's format using sigrok-cli and open it in sigrok's PulseView app, then it's decoded well, but it only appears to be available visually, not in a table format.So, I think I'll go back to square one and write a direct conversion program from Rigol's CSV to I2C.On a side note, is there any centralised documentation on the various settings for the sigrok decoders? In my brief experience of sigrok, the documentation I've seen seems to be mostly written for programmers interested in modifying and developing sigrok rather than for end users.

author: biot
author_rank: Regular Contributor
timestamp: October 25, 2014, 10:41:02 am
content: Quote from: Howardlong on October 24, 2014, 09:21:28 pmDon't do that!True, Pulseview can't handle all the protocol decoder functionality yet, but let's take a look with sigrok-cli. There's an input module for CSV:sumner:./sigrok-cli -I csv --showID: csvName: CSVDescription: Comma-separated valuesOptions:single-column: Enable/specify single column (default 0)numchannels: Number of channels (default 0)delimiter: Column delimiter (default ',')format: Numeric format (default 'bin')comment: Comment prefix character (default ';')samplerate: Samplerate used during capture (default 0)first-channel: Column number of first channel (default 0)header: Treat first line as header with channel names (default false)startline: Line number at which to start processing samples (default 1)Let's convert an existing sigrok save file to CSV, for demonstration purposes (there is also an output module for CSV):sumner:./sigrok-cli -i xfp.sr -O csv -o xfp.csvsumner:ls -l xfp*-rw-rw-r-- 1 bert bert 3976675 Oct 25 00:18 xfp.csv-rw-rw-r-- 1 bert bert 5718 Oct 25 00:18 xfp.srsumner:head -5 xfp.csv; CSV, generated by libsigrok 0.3.0 on Sat Oct 25 00:18:28 2014; Channels (2/8): SCL, SDA; Samplerate: 1 MHz0,00,1Now let's read that into sigrok-cli, decode as I2C, and pipe that into xxd to get a hexdump of the raw I2C payload:sumner:./sigrok-cli -I csv:samplerate=1000000 -i xfp.csv -P i2c -B i2c=data-read | xxd0000000: 0600 5000 f100 4b00 f600 0000 0000 0000 ..P...K.........0000010: 0000 c350 0000 9c40 0000 3de8 04ea 2710 ...P...@..=...'.0000020: 07cb 4576 0000 372d 0119 0000 0000 0000 ..Ev..7-........0000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................0000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................0000050: 0080 0080 a200 0000 0000 0000 0000 0000 ................0000060: 23cb 0000 0000 0000 55dc 8151 0000 b0a0 #.......U..Q....0000070: 0000 0000 0000 0000 0000 0000 0000 0001 ................0000080: 0658 0744 0000 0000 0000 0090 646c 0a00 .X.D........dl..0000090: 0000 0040 5375 6d69 746f 6d6f 456c 6563 ...@SumitomoElec00000a0: 7472 6963 f000 0a1d 5358 5033 3130 314c tric....SXP3101L00000b0: 582d 4134 2020 2020 4120 6658 0fa0 468c X-A4 A fX..F.00000c0: 7d96 0800 3833 3330 3132 4130 3033 3838 }...833012A0038800000d0: 2020 2020 3038 3033 3231 4135 0860 708c 080321A5.`p.00000e0: 3348 4530 3035 3634 4141 4141 3031 2020 3HE00564AAAA0100000f0: 414c 4120 2049 5055 4941 5252 4441 4154 ALA IPUIARRDAATThe I2C protocol decoder needs the samplerate to work, but the CSV input module doesn't parse comments, so we pass it in as an option to the input module. The -B option specifies binary ("raw") output, "data-read" is the annotation we want to see (the I2C payload being read in the session being decoded).The above is an EEPROM dump of a real XFP module by the way, The sigrok XFP protocol decoder stacks on top of this:sumner:./sigrok-cli -I csv:samplerate=1000000 -i xfp.csv -P i2c,xfp -A xfp=fieldnames-and-values | grep LinkLink length (SMF): 10 kmLink length (extended, 50?m MMF): (standard)Link length (50?m MMF): (standard)Link length (62.5?m MMF): (standard)Link length (copper): (unknown)Quote from: Howardlong on October 24, 2014, 09:21:28 pmThe protocol decoders are self-documenting, at least as far as options and such are concerned:sumner:./sigrok-cli -P i2c --showID: i2cName: I²CLong name: Inter-Integrated CircuitDescription: Two-wire, multi-master, serial bus.License: gplv2+Annotation classes:- start: Start condition- repeat-start: Repeat start condition- stop: Stop condition- ack: ACK- nack: NACK- bit: Data/address bit- address-read: Address read- address-write: Address write- data-read: Data read- data-write: Data write- warnings: Human-readable warningsAnnotation rows:- bits (Bits): bit- addr-data (Address/Data): start, repeat-start, stop, ack, nack, address-read, address-write, data-read, data-write- warnings (Warnings): warningsRequired channels:- scl (SCL): Serial clock line- sda (SDA): Serial data lineOptional channels:None.Options:- address_format: Displayed slave address format ('shifted', 'unshifted', default 'shifted')Documentation:I²C (Inter-Integrated Circuit) is a bidirectional, multi-masterbus using two signals (SCL = serial clock line, SDA = serial data line).That is of course a little cryptic if you're not used to it, so we're trying to make pages on the wiki for all of these:http://sigrok.org/wiki/Protocol_decoder:I2cWe have more protocol decoders than documentation pages though -- help is always welcome.Quote from: Howardlong on October 24, 2014, 09:21:28 pmWell you're right there -- we're a lot better at writing code than we are at documenting it, and writing super-easy clients etc. But at least the functionality is all there, as the above shows. As always help is welcome.

author: Howardlong
author_rank: Super Contributor
timestamp: October 25, 2014, 02:55:56 pm
content: Aha!Thank you, that will take a bit of digesting, and I'm in the middle of something else right now, but in the meantime thank you for your help, that is appreciated.Cheers, Howard

author: pascal_sweden
author_rank: Super Contributor
timestamp: October 25, 2014, 04:44:13 pm
content: Does the serial decode also support 9-bit data protocols? (e.g. Multi-Drop Bus protocol used in vending machines).In the MDB protocol, there is 1 master on the MDB bus, and several slaves. When the master sends data to the slaves, it starts sending an address byte, followed by data bytes. It uses 9-bit data communication, where 8 bits are reserved for data and the 9th bit is used to indicate if the byte is an address byte or a data byte. When the slaves receive an address byte corresponding to another address, they stop listening for data bytes and ignore the data on the MDB bus (as its intended for another slave on the MDB bus).The timing constraints in the MDB protocol are critical. When the master POLLs a specific slave on the MDB bus, the slave has to ACKnowledge the request within a certain time interval. If it does not respond in time, the master believes that the slave is either not there on the bus or is malfunctioning, and will disable it (the slave is no longer POLLed in the main software loop). With the scope it would be easy to verify if the timing constraints are met, and if the implementation of the MDB protocol corresponds to the official MDB specifications from NAMA.

author: biot
author_rank: Regular Contributor
timestamp: October 25, 2014, 06:25:41 pm
content: Quote from: pascal_sweden on October 25, 2014, 04:44:13 pmThere isn't a single "serial decode", covering all variants of such a broad term.Captured logic data gets fed into a python script of your choosing, which then decodes it and outputs annotations and/or binary output of the payload and/or python objects to pass on to decoders that can further decode this payload (as in the I2C/XFP example).The number of bits in the protocol has nothing to do with it.Take a look atthe sourceof the I2C protocol decoder. It handlesonlyI2C: takes two logic signals (SCL and SDA) as input, and outputs 11 types of annotations, 4 types or binary payload, and Python objects for other decoders up the stack.

author: pascal_sweden
author_rank: Super Contributor
timestamp: October 25, 2014, 09:59:17 pm
content: I was refering to the "serial decode" option on the Rigol DS1000/2000A series.

author: ThomasDK
author_rank: Regular Contributor
timestamp: April 04, 2015, 05:09:15 pm
content: Digging up an old thread, but just did an I2C decode from a Rigol DS1102E with sigrok, and thought I would add a little guideAs sigrok doesn't understand the Rigol csv format, I translated it with Matlab.Step by step:1. Save csv from scope2. Import column 2 and 3 in Matlab.These are the actual data, the first column just contains timestamps.The data is voltage readings and sigrok expects 1's and 0's. Let's fix that:Code:CH1(CH1<1)=0CH1(CH1>0.99)=1CH2(CH2<1)=0CH2(CH2>0.99)=1This will translate all readings under 1V to a '0', and all other to a '1'.3. Create a matrix with the two columns.In this step it is important to put them in the right order. You want the Clock as the first column, and Data in the second.Code:data = [CH1, CH2]Switch CH1 and CH2 as appropriate, I had the clock on CH1.4. Save the matrix as a new csv fileCode:csvwrite('i2cdata.csv',data)Now we have a file, that sigrok will read5. Apply magic. (sigrok)Copy the generated csv file to your sigrok-cli folder.Next, open "sigrok command-line tool", and type the following:Code:sigrok-cli.exe -I csv:samplerate=1000000 -i i2cdata.csv -P i2c > i2cdata.txtThat's it! i2cdata.txt now contains the decoded data./Thomas