changing the rigol DS1052E to DS1102E using USB , the dummy guide

[Gizmo]

From what I've read the general consensus seems to be not to self calibrate now, I believe.

I personally didn't after creating the firmware mod.

Any thoughts on this from others who know more would be welcomed though!

[radiogeek97]

gizmo
    thanks  i trust your opinion, heck I trusted your mod with the scope    i will hold off for now untill i know enough to evaluate my needs.

thanks again the upgrade was smooth

take care
john

[Gizmo]

Glad it's all working out well for people! 

I should get around to adding a DS1152E upgrade firmware as well,  just as an option for people. This would upgrade to the 150Mhz model.

Due to the fact the ADC chips are actually rated at 40Mhz (in all units), I'm not sure what issues you will get by overclocking them to such frequencies. As with all chip manufacture, they will be binned based on QC, but I don't know what the QC tests are for the ADC's at given frequencies.

Makes me wonder how Rigol's QC varies from the ADC chip manufacturer...

[pico]

Any thoughts on this from others who know more would be welcomed though!

Some thoughts from someone who actually knows less than you: 

I read the user manual about self-calibration, and it seemed a pretty safe thing to do, given that they were recommending a recalibration if the ambient temps had changed more than 5*C, for example.

They did say to let the unit run for 30mins before the calibration step to get to full stable operating temperature.

I got the impression from reading earlier posts in this thread and others that calibration problems after upgrading/downgrading the fw were most likely due to the differences in where the calibration data was stored between fw versions.

But given I was "sidegrading" from factory 4.0.0.1 to the single-byte patched 4.0.0.1, I felt it was much less likely to run into problems regarding calibration. So I went ahead and did a self-calibration after the "sidegrade" to see if it would affect where I was seeing the trigger level on the screen compared to where the actual trigger point on the wave form was indicating. I saw no difference at all after the self-calibration.

I'm still not sure if what I am seeing is actually a problem, or is normal. It's like there is a 150nS lag between where the trigger level is shown to intersect the wave form and where the the "T" trigger mark is indicating on the x-axis.

I'll take a pic and upload, so people can comment. 

Edit:

Here's is a screen capture, using the 1052e square wave gen on the front panel as the input, trigger voltage set to 0.00uV.

As you can see, the signal crosses 0V 150nS before the "T" indicator at the top of the screen is showing.
 
Or am I misunderstanding something basic here?

[drieg]

Here's is a screen capture, using the 1052e square wave gen on the front panel as the input, trigger voltage set to 0.00uV.

As you can see, the signal crosses 0V 150nS before the "T" indicator at the top of the screen is showing.
 
Or am I misunderstanding something basic here?

You need a signal with faster edges to see wheather you have an issue with delayed trigger. Check also the situation at falling edge trigger. Both trigger delays should be approx the same. Also check in both sampling modes (equ- and real-time).

I should get around to adding a DS1152E upgrade firmware as well,  just as an option for people. This would upgrade to the 150Mhz model.

Due to the fact the ADC chips are actually rated at 40Mhz (in all units), I'm not sure what issues you will get by overclocking them to such frequencies. As with all chip manufacture, they will be binned based on QC, but I don't know what the QC tests are for the ADC's at given frequencies.

"Upgrading" to higher BW has nothing to do with the sample rate (ADC clock frequency). Lot's of people wrongly thinks it is some kind of "overclocking". No, it isn't, ADC clock frequency remains the same, you only change front-end analog bandwidth.

[pico]

You need a signal with faster edges to see wheather you have an issue with delayed trigger. Check also the situation at falling edge trigger. Both trigger delays should be approx the same. Also check in both sampling modes (equ- and real-time).

I've checked with the falling edge of the same signal, and also in equ- and real-time sampling modes.

In all cases the 150nS "trigger lag" (if that's what I'm seeing) is unchanged.

Is this all to be expected as normal observation?

I will rig up an external oscillator source to test further (although I must admit I don't understand why the trigger source on the front panel square wave generator is too slow to test trigger calibration -- I'm an o'scope newby!)

16MHz xtal source be suitable?

Edit:

Measuring a 16MHz xtal output running on an Arduino clone shows the "trigger lag" now reduced to somewhere between 2nS and 4nS (I can't read it more precisely than that from the display grid). That value does not change for rising and falling edges, or equ- vs realtime sampling.

The 16MHz clock signal looks pretty much like a sine wave though -- not very square at all! 

[pomonabill221]

For all those downgrading, model changing and upgrading twice, you can just use the above custom firmware and do it in the one flash. Much less chance of bricking.

I developed the hack specifically because I don't like the idea of all the possible things which could cock up with the existing process (like losing hardware version as above).

Up to you though! 

Incidentally the hardware version can be set using the :INFO:HARDVERSION command.

How do you use :info:hardversion with USB?  Hyperterminal? Realterm?

[kirkum]

Got my scope and updated the firmware today using Gizmo's.  Huge thanks!  BTW, you can run an md5 check using the md5sum command in linux (i.e. md5sum DS1000EUpdate.RGL)

[Gizmo]

"Upgrading" to higher BW has nothing to do with the sample rate (ADC clock frequency). Lot's of people wrongly thinks it is some kind of "overclocking". No, it isn't, ADC clock frequency remains the same, you only change front-end analog bandwidth.
[/quote]

Ah, my mistake. I thought the ADC's were switched between different frequencies with the different operating modes as well. I know the ADC's are overclocked, as pointed out by Dave's "pants down" blog, but thought this frequency varied.

[RFT-Guy]

The Trigger Delay Calibration Value is off at V3.01 and 4.01:
I tried to set the proper realtrigdelay, but it does not save, I can verify my settings with

:INFO:REALTRIGDELAY?
1.40e-09
:INFO:REALTRIGDELAY 0.0000000034
:INFO:REALTRIGDELAY?
3.40e-09


Power off and on again and - trigdelay back to 1.4 nS!!

:INFO:REALTRIGDELAY?
1.40e-09

I tried this with V2.5.2, 2.2 3.01 and 4.01!
No success, trigger delay still 1.4 ns off - which is roughly the  realtrigdelay already set!


How can I make this change permanent?

[RFT-Guy]

>>The auto calibrate must save all the calibration variables including the trigger delay that is giving you trouble

I am at V 2.06 now, and just discovered,  equtrigdelay is updated permantly to a new value... but not realtrigdelay. I thought maybe the realtrigdelay value is not written into nvram bacause the sampling mode is real, so I switched to equ. still no joy. how can I terminate the "rmt"-Session over the serial line? I cannot operate the Scope after I connected over the RS232, scope shows "rmt" and ignores any key presses. So to calibrate after updating realtrigdelay I need to take it "off line" or run the calibrate command through the terminal session. Syntax?

I think, I stay at 2.06 for now...

rgds
Michael

[RFrisbee]

Hi,

I've used Gizmo's hacked v4 firmware to increase the bandwidth of a DS1052E. All appears okay except for the displayed signal being delayed 3.4ns after the trigger point (or probably more correctly, the trigger point being displayed 3.4ns too early). On my scope the trigger offset is the same in Real Time and Equivalent Time sampling modes.

After installing NI's VISA stuff and Ultrascope software, I've tried using the :INFO:REALTRIGDELAY? query and :INFO:REALTRIGDELAY 0.0000000034 command. The returned value for the query is 0.00e+00. After sending the :INFO:REALTRIGDELAY 0.0000000034, the returned value from a query is 3.40e-09. Nothing changes on the scope at this point.

After terminating the remote session, performing a self-calibration and cycling the power the offset is still present and the query returns 0.00e+00, indicating the setting was not saved.

It's not a killer problem, but it would be nice to to be able to remove the offset. Perhaps a hack of v2.04 firmware, which appears to have fewer issues according to the posts I've read so far, would allow the trigger offset problem to be resolved? Having said that, would downgrading from Gizmo's v4 firmware to (hacked or otherwise) v2.04 firmware cause any issues <looking at drieg>?

Regards,

Robert

[tylerl]

Hi,
I've used Gizmo's hacked v4 firmware to increase the bandwidth of a DS1052E. All appears okay except for the displayed signal being delayed 3.4ns after the trigger point (or probably more correctly, the trigger point being displayed 3.4ns too early). On my scope the trigger offset is the same in Real Time and Equivalent Time sampling modes.

If you wish to fix it, there is a SCPI command, but it's not working in latest version unfortunately (another bug).

I would guess you found the bug in v4 that drieg was talking about--the value you set won't save. That's my guess, at least. If so, then presuambly a downgrade would help, but I'm certainly not the one to ask.

[jmcl]

Another "upgrade" done.
Here's the before and the after (x is used to protect the serial number):

Model: DS1052E
Serial Number: DS1EDxxxxxxxxxx
Software Version: 00.02.06.00.01
                  DSP: 00.00
                  FPGA: 02.00
                  HardVersion: 58

Model: DS1052E
Serial Number: DS1EDxxxxxxxxxx
Software Version: 00.04.00.00.01
                  DSP: 00.01
                  FPGA: 03.07
                  HardVersion: 58

No problems noted. No screen flickering whatsoever. Did not recalibrate. Did not try (yet) the trigger issue as described by other users.
Would like to get my hands on the original 00.02.06.00.01 firmware if I ever need to revert it.
Does anyone know where I can find (download) version 00.02.06.00.01?
BTW, txs Gizmo for the "custom" firmware.

[tree]

After much hacking, here's a custom firmware which sets the DS1052E to be a DS1102E. You wont notice any difference in serial or model number, but you now have the functionality of the DS1102E scope (2ns minimum time scale / 100Mhz). I've tested it and my 32Mhz clock I was looking at definitely has more resolution, so it is working.

CRC32: E62BB61B
MD5: 01d2d46d6c565c492b6f49725404f18b

http://synfin.net/public/DS1000EUpdate.rar

For anyone who is sceptical, do a file compare between the official 00.04.00.00.01 firmware and this one, and you'll see only one byte has changed.

As ever use at your own risk, blah blah. Works for my hardware 58 version DS1052E scope.


Edit:
May as well add some instructions. Copy the DS1000EUpdate.RGL file from the rar onto a memory stick, put it in the scope, and select OK when it asks if you want to update. It's that simple.

For your peace of mind, check the file's MD5 against the above number when it's on your memory stick to ensure it's correct before flashing. The scope doesn't bother with any data integrity checking, which is a bit of a shame, so if the file is corrupted at all, you will most likely brick the scope.

I have just succeeded in updating my scope's firmware using your hacked version. I previously had 2.06 with hardware version 58. I can confirm that I have access to the 2ns/div scale.

Thank you.

[tree]

I also can confirm the 1.4ns trigger delay time after using a 60MHz crystal oscillator. See picture.

[Rising Edge]

Hi, one little remark, regarding the Trigger delay issue:
I own the original 2.06 HW58 on the DS1052E and I noticed on some low rising edges also that the Signal was triggered before it reaches the given Trigger-voltage in the center of the Screen.

I could reduce the delay, by lowering the value, found unter (TRIGGER)-MENU > SET UP >SENSITIVITY.
It goes from 1 DIV to 0.1 DIV. The lower the value, the lower the delay.

Does it reduce the delays on the hacked devices too?

I hope so - Need the "Upgrade", too. 

[tylerl]

Hi, one little remark, regarding the Trigger delay issue:
I own the original 2.06 HW58 on the DS1052E and I noticed on some low rising edges also that the Signal was triggered before it reaches the given Trigger-voltage in the center of the Screen.

I could reduce the delay, by lowering the value, found unter (TRIGGER)-MENU > SET UP >SENSITIVITY.
It goes from 1 DIV to 0.1 DIV. The lower the value, the lower the delay.

Does it reduce the delays on the hacked devices too?

I hope so - Need the "Upgrade", too. 

Yes, on my hacked 3.00 -> 4.00 device, I too noticed that the trigger delay was proportional to the trigger sensitivity. But since I didn't know to check this before I went through the modification process, I didn't know whether or not this was "normal". It seems reasonable enough, though. Decreasing the sensitivity threshold decreases the delay, but the scope becomes marginally unusable at that point because of false trigger artifacts.

Also, the trigger offset is dependent on the visible scale; change the scale and your delay changes too -- which makes me think that this trigger sensitivity is closely related to the delay offset. I'm not sure how the configurable trigger delay compensation value fits into this mess, though. I was hoping someone with more knowledge of this device could elucidate.

[Rising Edge]

>>The auto calibrate must save all the calibration variables including the trigger delay that is giving you trouble

I am at V 2.06 now, and just discovered,  equtrigdelay is updated permantly to a new value... but not realtrigdelay. I thought maybe the realtrigdelay value is not written into nvram bacause the sampling mode is real, so I switched to equ. still no joy. how can I terminate the "rmt"-Session over the serial line? I cannot operate the Scope after I connected over the RS232, scope shows "rmt" and ignores any key presses. So to calibrate after updating realtrigdelay I need to take it "off line" or run the calibrate command through the terminal session. Syntax?

I think, I stay at 2.06 for now...

rgds
Michael

Hi, try using to press the FORCE button in the TRIGGER-area. It's also marked with "LOCAL"
Maybe it will work - I never made use of the RS232-connection.

[lasvegas]

I was curious if anyone knows what the 'hardwareVersion' actually is on the second info screen. It looks like people have 57,58,59; however, I have 07.

07 Sounds pretty low... wondering if anyone else had this version, and if anyone knows what the hw versions are.

(It has 02.02 sp2 SW version).

[dohzer]

Clearly I should have read some of the other posts in this thread before calibrating.
I've upgraded my originally "SW: 00.02.04 SP1/00.02.04.01.02 HW: 58" scope to 100MHz and back to 00.02.04.01.02, but after the first calibration it had a ~1ns trigger delay.
After the second self-calibration, it's down to around a 0.2ns delay, but I'm really skeptical about how it may change in the futre. 

[autip]

Hi everyone,

I have a DS1022CD FW:03.07.01.00.02 and tried to apply the hack, but it did not detect the firmware update file.
After some reading on
http://codenaschen.de/tichyblog/index.php?action=blog&entry=8_Three+Rigol+DS1052E+DS1102E+Firmware+Secrets+

I tried the Key combination at the Utility->System Information:
TRIGGER MENU,ACQUIRE,ACQUIRE,UTILITY,MEASURE,STORAGE,CURSOR,CH1,CH1,REF,TRIGGER MENU

After this, there was a new option called Service, where I was able to select the Model (and also change the Serial ID).
After choosing DS1102CD I am now able to Scale down to 2ns (before, it was limited to 20ns)

Is that equivalent to Hack the FW?

[darrylp]

just been catching up on this thread,  and noticed this talk of the trigger delay issue.

anyway, my old 58 HW version from 2.05 got hacked many moons ago,  and  I see this trigger issue.


so basically I have from running :INFO:REALTRIGDELAY? a reply of 1.3e-09  and the line crossed to the left of the trigger mark on the screen by about 1.4ns.  so if  I correct this to say -1.3e-09 the point ( crossing trigger point ) should move to the right correct ?


the EQU time was -5e-09 and seems about right prehaps it needs to be -5.5e-09 but want to make sure what way I am entering positive and negative numbers to correct this ( i'm on 2.4.01 firmware ) so as I understand it, running a calibration, and power cycle will save my values if I use the commands to set them right.

thanks

Darryl

[RFrisbee]

Update:

As I couldn't find a way to save the delay compensation settings with Gizmo's hacked v4 firmware, I downgraded to the hacked v2.02sp2 firmware (from Mikrocontroller.net forum, IIRC), used the VB program from the OP to change the model info to DS1102E and then with the aid of a fast rise time pulse generator found better settings for REALTRIGDELAY and EQUTRIGDELAY. Note that I found that these settings only take effect after an auto calibration cycle. With the older firmware the settings remained after cycling the power.

I performed a quick and dirty check of the bandwidth of the scope using a Tektronix 100MHz DDS signal generator, RG58 coax and a 500MHz 50ohm through terminator connected to the scope input. The scope does indeed have a bandwidth in excess of 100MHz and appears reasonably flat up to 100MHz. I also found that (as has been demonstrated by others) activating features that force the sample rate lower than 1GS/s resulted in the accuracy for signals above 50MHz suffering.

[omegat]

Hi,
as this is my first post - hello everybody.

I recently got my 1052 from ebay (it was a little cheaper and as I wanted to hack it anyways..) it was HW 58 with 00.02.06.00.01 installed (purchased 02-nov-2012). -> See attached images b4.jpg and after.jpg

I used Gizmo's firmware (as it was apparently less permanent and less prone to fail).
It worked like a charm and I now have a 100MHz scope!  
It also doesn't seem to have the display flicker problem reported by others.
-but-
- I can confirm that the scope won't autoscale into 2ns/div, even with a 435.1MHz signal (which I don't care about because I don't use this button anyway ... ).
- I have made some images from the trigger delay problem, once from a 144.050 MHz signal 'loosely fed' into CH1 in EQU and REAL mode; with trigger sensitivity set to .1 div. As well as from a 435.100 MHz signal coupled the same way (... ...) also REAL and EQU. (I had no other way of generating frequencies that high except from my ham radio.)
Intrestingly the 435.1 MHz signal is spot on in equ mode (but not in real), whereas the 144MHz are all over the place (regardless of the mode).
Might actually correspond to the fact that i fed in repetitive signals and no bursts.

Well, that's that. I am actually not that worried about the trig delay, because i also own a UNI-T 100MHz scope, and whith that one I'm glad when it triggers at all...

Keep up the great work and thanks Gizmo for the great hack and making my life easier!

omegat