-
Yes, Richard, the HW58 devices can safely run any firmware revision from v2.04 SP1 (2.04.01.02) up to v2.06 (2.06.00.01), which currently is the latest official one.
I am not sure though if the so-called HW59 really exists...
-George -
Just upgraded my scope to 2.06, big mistake! Now got a ton of noise even when the probe is grounded. Reverted to 2.05 SP2, noise still there. LCD flickers gone but I'd rather have a flickering LCD than a noisy scope. Self cal did nothing.
Seems to have the same noise as described in the other thread:
https://www.eevblog.com/forum/index.php?topic=3738.0
-
I am very sorry to read that, vtl.
Your link points to the noise problem my device has. The difference with my oscilloscope is that it was shipped with that noise levels. It did have that noise as a DS1052E model since it was unpacked, even before its firmware was updated... Updating the firmware did not fix the noise problem nor made it worse because in my case the excessive noise problem seems to be hardware related.
You can contact Drieg and describe your problem in detail to him before doing anything else that might make things worse.
-George -
Just upgraded my scope to 2.06, big mistake! Now got a ton of noise even when the probe is grounded. Reverted to 2.05 SP2, noise still there. LCD flickers gone but I'd rather have a flickering LCD than a noisy scope. Self cal did nothing.
I would be very suspicious of a component failure coincidental to the FW upgrade, since the downgrade failed to reverse it. Pending better advice, I'd consider restoring all settings & F/W to original and returning it under warranty. -
I am assuming you did a self cal at 2.06 and again with 2.05 Sp2.
I was thinking of upgrading myself, but now, I might just wait a bit.
Yup - I am a coward.
Can I ask some questions?
Did the self cal with 2.06 change anything at all?
Is the noise only at low voltage input, or is it on high voltage ranges as well?
Does the noise look different with both channels on?
If you force the scope to sample at a lower speed by, say, changing to 10mS per div with extended memory off , is the noise the same but at a lower frequency?
One of the things I am wondering is if the A/D calibration offsets for the A/D's wanders away from zero to the point where it is no longer possible to correct, or even worse, roll over changing the sign of the correction. This could happen if they use a very crude algorithm in the A/D offset autocal routine and it gets easily confused. If it was something like this, then somehow resetting the A/D offset cal nos and then doing a new auto cal could solve the problem.
Richard
Here is what I am wondering.
One of the main tasks of the self cal is to balance the readings of the 8 A/D's -
Self cal'ed at every point and made no difference.
I've attached some waveforms. The most significant thing is when the probe is grounded I get a lot of high frequency noise. Same thing on channel 2, doesn't make a difference between 1x and 10x of course.
Hopefully a fix for this, the scope is of course still usable but it seems I have just managed to make it worse than it was to begin with
-
I have a question for those who have "upgraded" to 2.06: Why?
2.04SP1 has been the weapon of choice for some time now due to bugs in 2.05. The one single advantage of 2.05 that I am aware of is that one person reported it would read a USB memory stick that 2.04 would not recognize (all earlier FW seemed to have problems with certain memory sticks, but not others).
It appears that upgrading to 2.06 fixes the 2.05 screen flicker issue, just as downgrading to 2.04SP1 does. Are there any known advantages of 2.06 over 2.04SP1? -
I think A Hellene is right in his earlier post. It is probably best to contact Drieg. He has some magical mystical way to return oscilloscope back to a state that allows the calibration to fully work.
I suppose in the Storage menu, you could try the "Factory" option and then recalibrate. but it is a long shot.
Since it is only at low signal levels, it does not look like it is anything to do with the DAC Calibrate.
It is probably worth putting the scope in equivalent sampling mode, and a fast timebase so you can have a good look at the actual noise waveform. Is it noise, or is it a consistent waveform at a 100MHz+ frequency?
Richard. -
Ah, this is a very nice finding! Thank you, Richard.
I do not know what the main plug-in is able to do. There are listed a few bugs at the included README file, though.
Having spent some time on the BlackFin documentation, this is what I've quickly found in the rigol_ldr.h:Code: [Select]struct rgl_hdr {
uchar name[10];
uchar version[4];
uchar dummy1[2];
uint32 crc32;
uchar dummy2;
};
struct ldr_hdr {
uint32 addr;
uint32 size;
uint16 flags;
};
Well, according to the BlackFin "Loader and Utilities Manual" rev. 2.2, page 3-5:
"The boot ROM evaluates the first byte of the boot stream at address 0x2000 0000.
If it is 0x40, eight-bit boot is performed.
A 0x60 byte assumes a 16-bit memory device and performs eight-bit DMA.
A 0x20 byte also assumes 16-bit memory but performs 16-bit DMA.".
Since there is such an entry (with a value equal to 0x60) at all the .RGL firmware upgrade files (right after the 21-byte revision header and before the 10-byte bootloader header) I think that the source file above should rather read something in the lines of:Code: [Select]struct rgl_hdr {
uchar name[10];
uchar version[4];
uchar dummy1[2];
uint32 crc32;
uchar dummy2;
};
struct ldr_hdr {
uint16 bmode;
uint32 addr;
uint32 size;
uint16 flags;
};
I am also not sure how dummy the dummyX entries are...
Yet, I welcome and applaud any such efforts!
-George
hi,
i'm working on a programming toolchain to write and execute own code on the rigol scope. I'm the autor of the ida plugin too.
At the moment i can say that everytime you start the scope, at least a big part of the firmware is written to ram and executed from there. So maybee the firmware-image in rom is like you upload it to the scope but the executed firmware-image looks like that what comes out of the plugin-loader. I don't know if the header-formats comes from blackfin or rigol, but i think it's from rigol.
Maybee you want to see some of my efforts...
]Very first Rigol DS1052E Homebrew
cheers,
krater
update:
here my blog entry to the video
http://codenaschen.de/tichyblog/index.php?action=blog&entry=7_Very+First+Rigol+DS1052+Oscilloscope+Homebrew -
"Hello World"
CLASSIC!
It will be fun to follow your progress on this. I wonder if you will be able to teach it some new tricks. -
I have a question for those who have "upgraded" to 2.06: Why?
First, thanks to everyone who has helped a poor stranger with 2.06 to upgrade to 100MHz. All your efforts are much appreciated.
The answer to Torch's question for me anyway is simply that the scope was delivered with 2.06 so it makes sense (to me) to go back to it, before messing with calibrations etc. Maybe I'm wrong, but it's nice not to have any flicker and latest firmware with latest hardware ought to be the right thing to do...
Anyway - thanks to all, particularly George -
Nice work, Krater! Impressive! Thank you for sharing it, also!
Now, regarding the Blackfin, I may be wrong in my observations above because I am very new to this processor family. Since I had never have to work with it before, all I have is only a few hours on the documentation, in my limited spare time...
I also like the idea of the IDA plug-in; it might come in handy! Thanks, again!
-George -
Nice work, Krater! Impressive! Thank you for sharing it, also!
Now, regarding the Blackfin, I may be wrong in my observations above because I am very new to this processor family. Since I had never have to work with it before, all I have is only a few hours on the documentation, in my limited spare time...
I also like the idea of the IDA plug-in; it might come in handy! Thanks, again!
-George
Thanks for the good feedback
It's also my first work with a blackfin processor, but i found some code that could extract the RGL files like the RGL-Loader it does. I'm not really sure and there are other more interesting pieces of code to reverse engineer
@vtl:
I have similaer noise when i ground my probes....but only when i use my scope near to my laptop/monitor. Thats maybee a normal behavior because the grounded probe is a coil that receives radio noise.
Try to switch off all electronic devices, try to use a short cable to ground the port. Do you notice a change in the noise level ?
-
Thanks Hellene!
Thank you very much for hacked v2.06
Update and callibration done... works like a charm. No problems so far. And NO screen flickering
Greets from Germany -
Hello,
I upgraded to v2.06, do the calibration, all seems work OK. Noticed that upper volts/div limit in v2.06 version is 100V as I remember in v2.05 version it was only 20V. Or am I wrong?
By the way, printing option with v2.06 works well with my USB storage disk, and haven't noticed any screen flickering. -
The max. input voltage is the voltage guaranteed not to kill the scope, not necessarily the voltage that it can display. Maybe big t changed the probe settings from 1x to 10x on the scope, although then it should be a factor of 10 difference, not 5.
-
Sorry i deleted my post. I looked at the wrong spec.
I read input voltage... i think i need my eyes get checked. 
-
So please check volts/div max voltages who have scope with 2.04 or 2.05 versions.
-
So please check volts/div max voltages who have scope with 2.04 or 2.05 versions.
I've got rev 2.04 and with probe set to 1X , the vert can be set from 2mV to 10V and set to X10 vert is 20mV to 100V....etc -
OK, It's my misunderstanding.
-
So please check volts/div max voltages who have scope with 2.04 or 2.05 versions.
I went to check and found the same results as Flavour Flave: 2.04 SP1 on 1x: max 10v/div. -
[...]
Having spent some time on the BlackFin documentation, this is what I've quickly found in the rigol_ldr.h:
[...]
Well, according to the BlackFin "Loader and Utilities Manual" rev. 2.2, page 3-5:
"The boot ROM evaluates the first byte of the boot stream at address 0x2000 0000.
If it is 0x40, eight-bit boot is performed.
A 0x60 byte assumes a 16-bit memory device and performs eight-bit DMA.
A 0x20 byte also assumes 16-bit memory but performs 16-bit DMA.".
Since there is such an entry (with a value equal to 0x60) at all the .RGL firmware upgrade files (right after the 21-byte revision header and before the 10-byte bootloader header) I think that the source file above should rather read something in the lines of:Code: [Select]struct rgl_hdr {
uchar name[10];
uchar version[4];
uchar dummy1[2];
uint32 crc32;
uchar dummy2;
};
struct ldr_hdr {
uint16 bmode;
uint32 addr;
uint32 size;
uint16 flags;
};
WRONG!
I was wrong. Actually, the first boot Byte in the ldr_hdr (the 0x60 one in the DS1000 firmware upgrade files case) is the LSB of the first firmware file dword after the 21 bytes version header.
I am sorry for the false alarm, Krater...
I promise I will stop trying to read the BlackFin documentation with a cloudy head again!
I think I have just found a new way to kill my (limited) spare time: Re-writing the whole IDA project from scratch, adding support for the internal Boot-ROM (residing at the memory space address 0xEF00.0000) and the DMA transfer engine (that the Boot-ROM uses to boot the FLASH contents into the SDRAM) of the BlackFin processor. Then I will see how to deal with the firmware portions that include scary strings like AUTO_KEY_Lock&Unlock.RGL... Then, I guess that a custom JTAG dongle based on a microcontroller or, even better, the blazing fast FT2232H will be in order, followed by a simple application to access the Spansion FLASH memory.
Wouldn't it be nice adding, say, serial commands to the firmware in order to be dumping and updating the Spansion memory contents? Or, forcing this nice piece of hardware open source?
-George -
Hellene,
Just upgraded my Rigol DS1052E to DS1152E with 00.02.04 SP1. No increase in noise from reference measurements.
All I can say is thanks!
(Props also go out to Polossatik, Drieg and the countless others who made this hack possible!)
Fish. -
I am glad you made it, Fish!
Now, the fact that the noise did not increase after the model upgrade (since the higher frequencies are not filtered anymore) indicates that the hardware of your device must be flawless and it works as designed.
-George -
Wouldn't it be nice adding, say, serial commands to the firmware in order to be dumping and updating the Spansion memory contents? Or, forcing this nice piece of hardware open source?
-George
Tooooo late
I've build i firmware like this, if you want it, send me a private message.
As i said, i working on a toolchain, and actually i can upload and start code on the scope automatic. All shall be open source, but at the moment i think its not done enough to release a first version.
cheers,
krater