-
Folks
It'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 -
It'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
It 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 a lot of trigger options for I2C so you can wait for anything from a "start" up to a particular address/data before you start recording.and then only up to a few bytes before it undersamples and fails to decode.
Not 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 ... :-)
-
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
-
Using the Rigol as you suggest is painful if you have anything more than a few dozen bytes.
Yep, I imagine so.
Entering trigger parameters via the multifunction knob is quite painful, too.
-
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.
-
Folks
It'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!)
Cheers, Howard
Maybe 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 -
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? -
Not sure about why I would buy a Saleae when I already have a Logicport? Are they better in some way?
That's true. I have not used the Logicport so I can not give you any comparisons. -
The Saleae is a toy compared to the Logicport. Just download the free Logicport Software from www.intronix.com (the demo mode will act as if the hardware would be connected) and and compare it to the Saleae stuff.Not sure about why I would buy a Saleae when I already have a Logicport? Are they better in some way?
That's true. I have not used the Logicport so I can not give you any comparisons. -
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...)
-
The Saleae is a toy compared to the Logicport. Just download the free Logicport Software from www.intronix.com (the demo mode will act as if the hardware would be connected) and and compare it to the Saleae stuff.
Am I reading it right the Logicport can only buffer 2048 samples? Is that a misprint?
-
Am I reading it right the Logicport can only buffer 2048 samples? Is that a misprint?
2048 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 as your USB processing is fast enough that you don't start dropping samples. -
I 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?Am I reading it right the Logicport can only buffer 2048 samples? Is that a misprint?
2048 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 as your USB processing is fast enough that you don't start dropping samples.
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. -
Am I reading it right the Logicport can only buffer 2048 samples? Is that a misprint?
2048 on the device, zillions on the host PC.
I don't know anything about the device but 2048 samples seems like it would make it utterly useless. -
Am I reading it right the Logicport can only buffer 2048 samples? Is that a misprint?
I don't know anything about the device but 2048 samples seems like it would make it utterly useless.
Although 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.
-
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. -
Anybody out here who has experience with sigrok?
http://sigrok.org/
They also support Rigol scopes. Is sigrok any good or just a toy? -
Anybody out here who has experience with sigrok?
What I've heard about Rigol support is that it won't do protocol decoding out of waveforms, just for models with logic analyzers.
http://sigrok.org/
They also support Rigol scopes. Is sigrok any good or just a toy?
So I never tried it. But I might be mistaken and it does work, since this was over 6 months ago. -
Am I reading it right the Logicport can only buffer 2048 samples? Is that a misprint?
I don't know anything about the device but 2048 samples seems like it would make it utterly useless.
Although 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.
I 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. -
I 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.
OK, "2048 bytes of RAM" isn't the same as "2048 samples".
(and it's a bit cheapskate on a device that expensive).it's certainly way, way better than the DS1000Z series serial decoder.
edit:
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 ...
-
You 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).Anybody out here who has experience with sigrok?
What I've heard about Rigol support is that it won't do protocol decoding out of waveforms, just for models with logic analyzers.
http://sigrok.org/
They also support Rigol scopes. Is sigrok any good or just a toy?
So I never tried it. But I might be mistaken and it does work, since this was over 6 months ago.
-
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. -
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.
Don't do that!
So, I think I'll go back to square one and write a direct conversion program from Rigol's CSV to I2C.
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 --show
ID: csv
Name: CSV
Description: Comma-separated values
Options:
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.csv
sumner: 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.sr
sumner: 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 MHz
0,0
0,1
Now 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 | xxd
0000000: 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 ...@SumitomoElec
00000a0: 7472 6963 f000 0a1d 5358 5033 3130 314c tric....SXP3101L
00000b0: 582d 4134 2020 2020 4120 6658 0fa0 468c X-A4 A fX..F.
00000c0: 7d96 0800 3833 3330 3132 4130 3033 3838 }...833012A00388
00000d0: 2020 2020 3038 3033 3231 4135 0860 708c 080321A5.`p.
00000e0: 3348 4530 3035 3634 4141 4141 3031 2020 3HE00564AAAA01
00000f0: 414c 4120 2049 5055 4941 5252 4441 4154 ALA IPUIARRDAAT
The 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 Link
Link length (SMF): 10 km
Link length (extended, 50?m MMF): (standard)
Link length (50?m MMF): (standard)
Link length (62.5?m MMF): (standard)
Link length (copper): (unknown)On a side note, is there any centralised documentation on the various settings for the sigrok decoders?
The protocol decoders are self-documenting, at least as far as options and such are concerned:
sumner: ./sigrok-cli -P i2c --show
ID: i2c
Name: I²C
Long name: Inter-Integrated Circuit
Description: 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 warnings
Annotation rows:
- bits (Bits): bit
- addr-data (Address/Data): start, repeat-start, stop, ack, nack, address-read, address-write, data-read, data-write
- warnings (Warnings): warnings
Required channels:
- scl (SCL): Serial clock line
- sda (SDA): Serial data line
Optional channels:
None.
Options:
- address_format: Displayed slave address format ('shifted', 'unshifted', default 'shifted')
Documentation:
I²C (Inter-Integrated Circuit) is a bidirectional, multi-master
bus 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:I2c
We have more protocol decoders than documentation pages though -- help is always welcome.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.
Well 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.
-
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 -
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.