Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...

[iDevice]

All BNCs have to be connected otherwise the calibration won't start, if I remember.
I only do it about one or twice a year when DC offsets begin to bother me, so I forgot, but I think I tested first with 3 tees and four cables and it didn't work as there was a detection of signal presence on the ext sync input.
But I'm not sure as since then I use the original test jig.
The calibration process is using the fast edge output.
The calibration fixture is nothing fancy, just a PCB with soldered chassis female BNCs, the only special care is about track length matching.
So you can achieve the same thing with four tees and adjusted 5th cable length to compensate for the branch from the 2nd output from the first tee but it's cheaper to buy the Rigol thing than trying to make it yourself anyway, so why bother...

[Gallymimus]

I'm an RF guy, and the Rigol Calibration kit board looks like it has fifty ohm microstrip.

I don't know how the cal board is used, but I assume that all channels are set to 50 ohms to use it.

However, the combined impedance will be 10 ohms (five 50 ohms in parallel: see, RF ain't all black magic!) which won't match the central feed which I assume will go off to a signal generator presumeably with a 50 ohm characteristic impedance. Whether this is a problem or not I don't know, but it seems strange to go to the effort of making 50 ohm microstrip and then mismatching the feed point so grossly. But depending on the use case, if all channels are equally badly treated perhaps it doesn't matter.

It is possible there's some impedance matching such as a wideband transformer on the board to deal with the mismatch, but I couldn't see any evidence of this. You could use a minimum loss pad to provide a broadband match too (basically a pi or T made out of resistors, they're inherently broadband, but more lossy than a transformer).

A couple of other comments. Firstly, depending on use case, it may be necessary to terminate any unused channels with fifty ohm terminators or you'll get erroneous results. Secondly, the closeness of those BNCs on your board might make for a bit of fun when trying to fit the cables, you might want to do a fit check first, I did a similar thing with SMA connectors on a board a few years ago, you don't make that mistake twice!

to give a little more background, this is for self calibration so it connects to the calibration port on the scope itself.  Also the calibration won't work if you don't have all channels hooked up.  I believe it is designed to be usable with BNC tees and a bunch of cables so somehow the impedance match is cared for or not needed.

Like I mentioned before. I suspect that this is all offset and gain calibration and likely low bandwidth.  I suppose someone could add another tee and measure what is being send out of the calibration port to confirm.

[dr.diesel]

Rigol's firmware page is now showing FW 2.02 for the 4000.

http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm

Funny that I would just happen on a newer revision, after hounding their support for bug fixes with no response.   

[Gallymimus]

BAH!

I requested the update and they send me 02.01!!!!  WTF

[salvix]

The email said 02.01, but if you look at the first few bytes of the file, you'll see it's actually 00.02.02.01.01.

00.02.02.01.01 has 9570200 bytes

00.02.01.00.03 has 9091982 bytes

sha1sum:

ab2b226cf3b5fbd42cd72054e6ba773d35973512  DS4000Update.00.02.01.00.03.GEL
5a76dc73098e1a2ddb4492d17f8a26397b09e1dd  DS4000Update.00.02.02.01.01.GEL

[electronic_eel]

Is the decoding in segmented memory bug fixed with 2.02?

Does 2.02 still accept Riglol codes or did they add a protection against that? Like the first step they did on the DSA815, the bootloader being the second.

[Gallymimus]

You'd probably have to check the change log!

Now if only we could find one of those...

Hope they fixed the hacking issue. Stealing is wrong!

[Gallymimus]

The email said 02.01, but if you look at the first few bytes of the file, you'll see it's actually 00.02.02.01.01.

00.02.02.01.01 has 9570200 bytes

00.02.01.00.03 has 9091982 bytes

sha1sum:

ab2b226cf3b5fbd42cd72054e6ba773d35973512  DS4000Update.00.02.01.00.03.GEL
5a76dc73098e1a2ddb4492d17f8a26397b09e1dd  DS4000Update.00.02.02.01.01.GEL

Well thanks for checking that. It would not have occurred to me to see if they actually sent a newer version than what they stated.

Can't wait for someone to check this against known bugs!


EDIT:
Confirmed that installed firmware is 02.02.SP1.

Also, licenses stick, 500MHz option disappears from options screen but also persisted (model still says 4054 in system info).

now we just need to figure out what might be fixed!

EDIT:

the 500MHz does in fact stay functional.

[salvix]

Interesting. Could you try downgrading to the previous firmware to see if it's still possible?

[Gallymimus]

Sure, why not, not like I have any real work to do right?



EDIT:

downgrade works fine if done from the pre-boot bootloader (turn on and mash help button).  It does not allow downgrade from within the scope firmware.

[jboard146]

Could someone post the DS4000Update.00.02.02.01.01.GEL (The supposed fixed) file to dropbox or somehting?

I'll give it a try and see if it fixes the decoding. I really want the decoding to work.

[salvix]

There you go: http://wikisend.com/download/445784/DS4000Update.00.02.02.01.01.GEL

After you download it, make sure the sha1sum is 5a76dc73098e1a2ddb4492d17f8a26397b09e1dd.

And thanks Gallymimus for checking the downgrade works! (wait, you use your scope for *work*? geez!  )

[H.O]

Hi,
I just tested the new 02.02.01.01 firmware and I'm pleased to see the main issues I've had with the protocol decoders are, as far as I can see during this fairly short test, fixed.

* If you record a bunch of frames/waveforms you can now use the decoder on the recorded frames while playing them back - at last, thank you Rigol!

* There's no distorted "preview" of the waveform when in analyze mode.

* If you enable the waveform record feature while a decoder is already turned on the scope will now hide/blank the decoded data on the screen while recording is active. This is (a lot) better than before where the decoder simply locked up displaying the last decoded. I would obviously prefer to have it show on the screen while recording as well but it's my understanding that it's compromise due to processing power. It would then be nice with an option where you could opt to have it on screen with the drawback of reduced waveform record rate. After all, there are a lot of scenarios where there's plenty of time between frames anyway. Oh well....

* Unfortunately it (the decoder) still locks up as soon as you bring out the Record mode menu on the screen. The waveform updates but the decoded data does not. Once you select an item in the menu the decoder either comes back to Life (ie you select OFF) or it hides/blanks.

* There seems to something strange going on when trying to use the Open record mode with a decoder turned on. I can't seem to make it operate properly. If I turn off the decoder then Open mode seems to work properly (and the decoder can be re-enabled again when playing back the frames/waveforms).

[dr.diesel]

Is it just me or does the multi-function knob responsiveness also seem better with 2.0.2?  I had gotten to the point that most of the time I simply used the menu button presses to scroll down, so I wasn't using the knob as much, but seems better.

[H.O]

You know, I actually kind of felt that too but then decided it was probably just wishfull thinking and imagination. Perhaps not after all....
Have you found anything else fixed or added? You didn't happen to get the release notes did you? (I didn't, just got the .gel file).

[dr.diesel]

No release notes, I was told it's still in the works, but is coming.

I've not noticed anything else fixed, but been busy with other stuff and only played a bit so far.

[alank2]

Hi,

Can someone explain to me the reason fro the vertical stringing when I view this in dots mode.  The intensity grading seems to be a part of this, obviously stopping the waveform and viewing it shows the sample dots perfect.  It also looks good running when using vectors too.

Is it noise in the triggering from the signal I'm looking at?



Thanks,

Alan

[TooOldForThis]

I can confirm your results.    I get the same artifacts at high sweep rates when in dots mode. (This is with SW rev 02.02.SP1)
I get slightly different results each time I stop the acquisition.  I find the 2nd screen shot interesting.  It appears that some percentage of the time the sample data is is displayed with a phase delay.  I don't see this effect at slower sweep rates.   Everything is fine in vector mode at any speed.

[alank2]

Does anyone notice some waviness with the VGA output on their DS4K?  At first glance you don't see it, but there is a repeating pattern in the signal that is visible if you look.  I tired a couple displays and a couple of cables and got the same thing.

[commongrounder]

alank2:
Yes, I have the same noise pattern on the VGA out of my scope as well.  I imagine there must be some crosstalk into the analog portion of the video out.  I guess they didn't have the budget to go ultra high performance on the video processing.

[alank2]

Thanks commongrounder, I just wanted to make sure it was normal.  Not a huge deal, just a little annoying.  It looks really funny to see it on a large display.

[electronic_eel]

I have 00.02.02 installed on an MSO4000 and I'm getting strange results with a measure on the math channel. The measurement is a simple power measurement multiplying voltage and amps of a 40 W bulb on an 100 R shunt. The math curve looks nice as it should be.

But I don't understand what is going on with the average measurement - it is showing a negative value.

I have also included a screenshot with all measurements on the math channel on. Although the math curve is always above the zero-mark, the measure function thinks it swings from -43 W to +31W. To me these measure results look totally bogus.

It seems like it depends on the scale of the math trace: when I use a lower load so that I can use the 500U scaling on the math trace everything is ok. Once I change the scale to 1KU the measure results go negative.

Could anybody try to reproduce this?

[electronic_eel]

I've done some more investigation:

It seems like only the measure function is affected, the regular cursors show sane values.

I have restricted the measurement area from full screen to measurement cursors and inspected parts of the math waveform. See attached screenshots. The measurement function seems to think the whole math waveform is negative.

And once I switch the math scale down to 500U everything is fine again. Maybe some kind of overflow?

If someone wonders: I turned down the voltage a bit for these measurements, my 100 Ohms shunt was getting a little warm.

[alank2]

Hi,

Well, my calibration pcb came in from itead finally.  I do know that you could kludge the cables together without it, but it made the job easier.




Before calibration:



After calibration:



I actually ran the self cal twice to see if I could get the CH1 to move up like the others, but it ended up the same both times.

If anyone wants one of these pcb's, I've got 8 extras.  I'll drop one in an envelope in the US and pay for a stamp.  You just need to buy 3 BNC cables from Jameco and you can easily build a 5-in-1 calibration fixture.

111473   CABLE ASSEMBLY,RG174/U,3 FOOT ,BNC TO BNC,50 OHM   5.49

I skipped the 33 ohm resistors the RF guys recommended because the actual Rigol fixture does not have any resistors in it...

Thanks,

Alan

[Omikron]

Hey All!

In case anyone is curious, after several weeks of calls and badgering a number of people, TEquipment has finally listed the calibration kit on their website: http://www.tequipment.net/Rigol/Calibration-Kit/General-Accessories/

Yay!