Sniffing the Rigol's internal I2C bus

[eV1Te]

Too bad the codes have not been sorted out for the MSO yet.

By the way how good is the decoding function in the MSO?
I was debugging RS232 from a GPS today on my DS1074Z-S, and the decoding function is really terrible, almost unusable.

It only decodes the waveform on the screen at the moment (not outside the screen), so if you scroll (move horizontal) past the beginning of the transmission it losses its sync and interprets the first rising edge that you can see on the screen as the start-bit which scrambles the entire message.

If you "zoom-out" then it can not decode any data at all because the it only decodes whats in the screen buffer (it does not use the large memory capability of the scope), and this data aliases very early on.

Hence it is impossible to to view more than the first ca. 15 bytes/characters of a transmission. If you are lucky and there are gaps between each byte , then you can manually can set the edge of the screen to be in one of the gaps, but if you have a continuous string of bytes then you are out of luck (unless you are lucky and happen to have the first bit just at the left part of the screen).

I  also tried using the event table or single capturing a longer sequence without any luck. Triggering of a character in the middle of the transmission doesn't work either because the decoder scrambles the message anyway (since it can not see the start of the message) even if the trigger stopped at the correct spot.

I watched this video from Rigol demonstrating the decoding function on a DS4000 scope, there they specifically say that you can zoom out and use the event table if your message is long and does not fit on the screen. Apparently the DS1000Z series of scopes has seriously downgraded decoding function and is not comparable to their more expensive scopes.

[diyaudio]

I was debugging RS232 from a GPS today on my DS1074Z-S, and the decoding function is really terrible, almost unusable.

I decoded data from a ublox GPS, the $GPRMC USART data was decoded pretty well. Sometimes you need to double check your scope setup it happended a few times where i blamed the decoders.

I own a DS2072A using the hacked firmware.

[alank2]

I think part of getting the decoders to work well is getting the trigger setup properly and also understanding that by default you aren't doing a single capture and review, but by default the scope is trying to trigger as many times as possible so it can provide a gradient display.  I think the result would be better if you (1) setup the trigger to trigger on the even you want to, (2) set the timebase so that you can capture all of the event on one screen, (3) set the trigger mode to normal not auto, and (4) once you have captured then go to stop mode so no more capturing can occur.

Whether or not the decoding stays aligned when you expand the signal and start moving through it I am not certain.  I've had it act like if part of the signal goes off the screen it lost its way and it seems like I've had it handle that properly at other times so I don't know if I was still running or stopped and reviewing the waveform.

edit : I don't see such a great value in the decoders.  I'll use them if convenient, but I much rather use a Saleae Logic or LogicPort.

[eV1Te]

I was debugging RS232 from a GPS today on my DS1074Z-S, and the decoding function is really terrible, almost unusable.

I decoded data from a ublox GPS, the $GPRMC USART data was decoded pretty well. Sometimes you need to double check your scope setup it happended a few times where i blamed the decoders.

I own a DS2072A using the hacked firmware.

I am willing to bet that the DS2000 series scopes have a much better debugger in that case. No doubt the DS1000Z only uses the screen buffer for debugging, and that's probably around 1k points or less. Doesn't the DS2000 have 2 FPGAs and the DS1000Z only 1?

The debugger works fine for short transmissions or for the beginning of a transmission, but fails completely for longer messages or when triggering in the middle of a message.

Maybe this will convince me that I "have" to buy a real logic analyzer as an early Christmas gift for my self 

[msraya]

Well, yesterday a colleague and I were debugging a FPGA design using I2C serial bus port.

I already knew that the I2C decodification does not work and indeed It was not showing anything in I2C testing close to reality.
Also, as we were doing scroll sideways in the capture zoom, the oscilloscope was completely blocked and We had to restart it.
However, the decoding of serial bus was successful (there was enough space between characters, it was not a data stream)

For the purist this is a serious error and the manufacturers have lied about decoding specifications.
However rethinking it, this equipment can not be compared with the more powerful DS2000 series since it only has a single FPGA for decoding and display.
With this in mind it is questionable the usefulness of decoding and I would not pay 188 euros for it.

In any case, the oscilloscope worked well comparable to Agilent 6000 Series we have as logic analyzer.
We do not use decoding. The scroll is somewhat slow, but it is still usable.

I can not test the SPI bus decoding, but it seems that for others users it decodes correctly.

If I had known before buy this issue, I would have perhaps opted to buy a MSO2000 series.
However for the price and the features I'm happy.
I have made also testing with the generator and FFT and it is working properly.

It's a shame that the Ultravision software made by user marmad does not support the model MSO1000Z.
I have contacted the author but I have not gotten any response yet. 

Regards
Manuel

[Howardlong]

I have the MSO1074Z-S and I agree with your comments Manuel. The I2C decoding is almost not worth having at all, and certainly as a paid for option I'd feel short-changed.

Over all, like you, I do consider it good value for money though, there's a lot of functionality in that box when you include 4 channels, the LA and the dual signal generator.

[Rigby]

Forget using a cheap scope for protocol debugging.  Get a Saleae product and live happier.  I'm not shilling for them, just a very happy customer.

[miguelvp]

I agree with Rigby, if you are measuring an already working protocol, a protocol analyzer is your thing.

If however you are prototyping a board that uses i2c, you need the scope to make sure your signals are good. The protocol analyzer will only work on clean signals.

[eV1Te]

Forget using a cheap scope for protocol debugging.  Get a Saleae product and live happier.  I'm not shilling for them, just a very happy customer.

How good is the analog mode on the Saleae analyzers, is it just a gimmic or is it eqvivalent to usb-oscilloscope with lower bandwidth?

[miguelvp]

I guess you made your point

[alank2]

Rigby - the pro models (usb3) do -10V to +10V analog.

Their logic 8 model ($199) does 0V to +5V analog.

[Rigby]

It's not too bad.  I have a Logic 16 Pro and it's a great scope when you remember the device is a logic analyzer first. 

I mean it only does 5V max and they aren't true scope probes, but if you want to see the shape of a TTL waveform, the Logic 16 Pro will get you what you need.

It is not a replacement for even a cheap eBay CRT scope, so always have a real scope on hand.

edit: sorry, phone lied to me and said it couldn't connect a few times.  it DID!  d'oh

[Rigby]

I guess you made your point

Hah!  technology failed me.  This time.

[Rigby]

Rigby - the pro models (usb3) do -10V to +10V analog.

Their logic 8 model ($199) does 0V to +5V analog.

Thank you for the correction.  I was going off memory from the settings in the software.  I recall it only going to 5V, and I guess I was wrong.

[dewey]

Quick question, please redirect me if this isn't the place for it.  This seems like the ultimate thread for such matters:

Hypothetically, how much of a chance would one be taking by trying to "mod" a DS4014 to a DS4054?  How big a possibility is there of owning a $2300 brick?  Has it happened to anyone here?

Thanks
-Dewey

[extide]

Depends on how you mod it.


So, I have a question of my own. Has anyone actually done quantitative tests on the DS4000 series regarding upgraded b/w? Has anyone looked at the mobo in a DS4014 vs a DS4024/DS4034/DS4054 to see if they are actually the same or any different? I think I saw some rise time tests on a modded DS4k, but I can;t remember, and is that really sufficient enough?

I am going to be getting a DS4014 here in the next few weeks, and will probably hack to unlock the decoding options and whatnot, but I am a bit iffy on upgrading the b/w .. Plus, 100Mhz is plenty for what I am doing at the moment anyways so I will probably leave the b/w alone.

[ted572]

Free EMI Software for the DSA815 and other Rigol Spectrum Analyzers.  And of course provides for a Linear or Log frequency display (as required for EMI reports):  https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg545685/#msg545685

[EE-digger]

Depends on how you mod it.


So, I have a question of my own. Has anyone actually done quantitative tests on the DS4000 series regarding upgraded b/w? Has anyone looked at the mobo in a DS4014 vs a DS4024/DS4034/DS4054 to see if they are actually the same or any different? I think I saw some rise time tests on a modded DS4k, but I can;t remember, and is that really sufficient enough?

I am going to be getting a DS4014 here in the next few weeks, and will probably hack to unlock the decoding options and whatnot, but I am a bit iffy on upgrading the b/w .. Plus, 100Mhz is plenty for what I am doing at the moment anyways so I will probably leave the b/w alone.

I'm interested in the answer to this also.  The minimum timebase changes across these models from 5ns to 2ns to 1ns.  Getting the 2ns or 1ns would be a definite plus (if you need it).

Den

[H.O]

Hi,
When I upgraded my unit I did some very rudimentary tests - please take it for what it is.

Using a DG4162 to generate and feed a 100MHz, 100mVp-p sinewave my Tekronix 2465B (400MHz bandwidth) measured the signal (using cursors) to 100.5mV while the DS4014 reported 85mV - which is well above the 100MHz bandwidth specification of the DS4014.

After uppgrading the DS4k measured the exact same 100MHz 100mVp-p signal as 98mV.

[Sparky]

In this post I reiterated the "License is unavailable!" message that sometimes accompanies attempts to install 300 MHz keys on Rigol DS2072A or MSO2072A models.  I have been attempting to install the 300MHz "NS8H" key on an MSO2072A without success, and called out to some folks here for info, insight and testing.  So far my tests and outcomes are:

1) Look for physical differences (e.g. "Hardware revision" resistor settings on the mainboard (DS2000_MB_V02.02)) between identical MSO2072A units (same hardware/firmware revisions from factory), of which one unit would and the other would not accept a 300 MHz key.  No differences could be found.
2) Recompile rigup 0.4 from source code (on Linux machine) to see if any keys generated were different.  Identical keys were generated.
3) Recompile rigup 0.4 with different (non-zero) "k_offset" so as to generate different valid keys.  200 MHz key can install.  300 MHz cannot install and gives the same "License is unavailable!" message.
4) Compare keys generated on my system with those generated by someone else (and for which the 300 MHz key did work) for the same memory dump.  Differences in the PCs (32-bit and 64-bit) did not yield any differences in the keys.  The above few tests effectively ruled out operator error, 32-bit/64-bit machine differences, or other similar issues.

The last outcome is that there are several license related messages stored in the firmware:

License invalid
License had installed
License has been used
License has been expried      << yes, "expried" and not "expired"
License is unavailable!
License is none!

Despite the range of messages, the only message displayed when an invalid license is entered is "License is unavailable!".  Given the range of messages available Rigol could check and distinguish between "invalid" and "unavailable" keys.  But, as the same message is always returned (for an invalid key) it is not possible be sure the reason the license was rejected.

It is possible there is a firmware level check that detects the 300 MHz key and rejects it, but if this were true the 300 MHz key would be rejected on all MSO2072A units.  Furthermore, whatever the type of check in place (firmware or hardware), it would seem Rigol could duplicate it for rejecting 200 MHz and other options, but this hasn't been done.  So, a firmware or hardware related check doesn't seem likely.

I can think of two possibilities:

1) The 300 MHz key is sometimes incorrect, and the DS/MSO detects and rejects it as such, just like any "made up" (wrong) license key.  That is, there is a "fence-post" type bug somewhere in rigup/riglol/miracl etc. or a misunderstanding with some aspect of the key generation that is occasionally exposed.

2) There is a bug in the scope firmware, causing sometimes valid 300 MHz keys to be rejected.

Anyone have further thoughts?

[EE-digger]

My thought could be out in left field but who knows ...
During production test, hardware could be "marked" as to its bandwidth and rise time capabilities.  During final production configuration, units can be configured for the highest level product they can meet, or a lower level if sales demands more lower level units.
I've never been in a production environment where the required performance was not designed in but perhaps in higher volumes, and in China, final designation occurs sort of the way pistons, pins and connecting arms were mated in the earlier days of automobile production, prior to the discovery of design for mass production.
Just my $0.02

Den

[EE-digger]

Here are some bandwidth and risetime numbers I measured on an MSO1104Z that I received two days ago.

There is a twist in bandwidth measurement that I noticed and may be of help to others.  I apologize if this exists elsewhere.

While measuring bandwidth with an Agilent source (50 ohm output) and precision in-line termination at the scope, I found bandwidth to be much higher that expected (i.e. 3dB point around 190MHz or more).  Too good to be true 

On a Tek TDS784D (1GHz) with the same external termination, I noticed that the source appears to peak as you go above 120MHz.  I knew the generator was flat (into a proper load) so repeated with the internal 50 ohm Tek setting.  This I know to have very good return loss.

The source, as I expected, was flat.  It turns out that with the 50 ohm external termination, with either the expensive Tek scope or the Rigol, you end up with peaking, probably caused by the scope input impedance (cap + inductance).

So, the numbers shown here were measured with the amplitude verified first into an internal 50 ohm scope.

Bandwidth:  (all without any aliasing effects)

-3dB :   155 MHz
-6dB :   280 MHz
-9dB :   380 Mhz

Risetime:   (measured with avalanche pulse source, 180ps rise time)

Rigol reports :   1.2ns
correcting for the avalanche pulse rise time :   1.18ns

In addition to the beautiful graphic presentation of the Rigol scopes (for any money as far as i can see, having handled recent vintage Tek, LeCroy and Agilent),  what impresses me is that the Rigols do not "fall apart" until you are up around 4X the bandwidth (from aliasing and other DSP related issues).

But now, I can't wait until mods are available for this MSO.

The I2C and SPI, while not real time, appear to work fairly well but I only have 12 hours left    On I2C at least, you can take a sweep at a long horizontal time, the stop the scope and zoom in, whereupon you will get the decoded values as soon as a packet or packets are fully on screen, as observed by others.  I2C was at 100kHz and SPI was at 500kHz.

Den

[dewey]

To upgrade a DS4014 appears to involve putting a firmware update on a USB stick, booting from it and restarting.  (instructions thread here)

I just ordered a DS4014, and would like to experiment with its bandwidth.  However, I don't want to be the proud owner of a $2300 brick.  From the above thread, it sounds as if perhaps the poster above me here is experiencing what might be a change in the DS2072A's ability to be upgraded, perhaps due to hardware level changes made by Rigol?

Does anyone know if Mr. Kreb's tool (here) will still work on a DS4014, as delivered today, November 2014?  Has the firmware changed at all since the tool was written, or will that matter?  Any reports of hardware changes made by Rigol?

I'd really appreciate anyone's input.

Thanks
-Dewey

[H.O]

There's no longer any need to apply the modified firmware since seronday found/figured out the option codes for bandwidth selection on the DS4k. See reply #3607 in this thread. It's been verified to work with the latest firmware available today (00.02.02.01.01). You can use Riglol 1.03d

[Bud]

1) The 300 MHz key is sometimes incorrect, and the DS/MSO detects and rejects it as such,

Just had a DS2072A updated to 300MHz. FW 00.03.00.SP1, HW 2.0

Used Bildschirmkopie to dump data from the scope via a SCPI command
:SYST:UTIL:READ? 15441920,13262848
then goes rigup-0.4 to generate the keys
then again Bildschirmkopie to install a key
:SYSTem:OPTion:INSTall A_KEY_WITHOUT_DASHES

Bildschirmkopie : http://peter.dreisiebner.at/rigol-bildschirmkopie-lan/download.htm
rigup-0.4:  http://gotroot.ca/rigol/

I am not sure why bother changing the scope firmware via a USB stick risking to brick the device, unless it is because of other goodies that I am not aware of. If all you want is options and bandwidth, the above procedure is non-intrusive and safe.