Here's a file you can use to directly downgrade to 2.02SP2 from any firmware up to, and including, 2.05SP1 (00.02.05.01.00).
I've just sent a new bug report to rigol:
I've just sent a new bug report to rigol:
I've just sent a new bug report to rigol:
good, if they release yet another new firmware to fix this, then we have three of the new headers used on the 2.05 firmware line, should allow us to see whats changing and in what places.
comparing the 2.05_sp1 and the 2.05_sp1_02 file ( fix the trigger problem ) i cant see what / how its changing. i can see some bytes common, but a third firmware might help more.
if you can post it, assuming you get a reply that is.
I've just sent a new bug report to rigol:
Can anyone confirm that pic bridge, FAT and NTFS file systems work properly in 2.04 SP1? It is sure beginning to sound like Rigol is just desperately fishing around trying to defeat the hack and not fully testing the FW "upgrades".
I've just sent a new bug report to rigol:
Can anyone confirm that pic bridge, FAT and NTFS file systems work properly in 2.04 SP1? It is sure beginning to sound like Rigol is just desperately fishing around trying to defeat the hack and not fully testing the FW "upgrades".
I've just sent a new bug report to rigol:Can anyone confirm that pic bridge, FAT and NTFS file systems work properly in 2.04 SP1? It is sure beginning to sound like Rigol is just desperately fishing around trying to defeat the hack and not fully testing the FW "upgrades".What is a little bit surprising is that the don't manage to stop the software-based hacking. They have a new hardware release (HW59, right?). What would have prevented them from going to encrypted firmware and an ID / version chip on the new hardware?
Because that would increase the costs of hardware.
A TPM or something equivalent costs a lot of money
and would not be hacker proof (look at the three major gaming consoles).
I bet the amount of money they would make with the slight increase of DS1102E sales would not cover the cost of the advanced security methods. Like I said above, if it wasn't for this they would have sold a lot less DS1052E's and that would certainly not mean a proportional increase in DS1102E sales.
I've just sent a new bug report to rigol:
Can anyone confirm that pic bridge, FAT and NTFS file systems work properly in 2.04 SP1? It is sure beginning to sound like Rigol is just desperately fishing around trying to defeat the hack and not fully testing the FW "upgrades".
I've tested a lot of flash "drives", some of them don't work, even formatted as FAT32, I could replicate the FAT and NTFS problem with a different flash and the printing problem with a different printer, but it still might be just my hardware...
cool,
can someone with a 2.05 (no SP1) system (before trying to downgrade please ) provide me with
1) a screen shot of the version info of the scope (optional, but would be nice)
2) the full version string ( you can use shafry's tool for that. should be somthing like 02.05.00.02 or so
i'll the rewrite/update the guide (need to rewrite it anyway, looks it's getting confusing)
I've tested a lot of flash "drives", some of them don't work, even formatted as FAT32, I could replicate the FAT and NTFS problem with a different flash and the printing problem with a different printer, but it still might be just my hardware...
but I bet they never sold as many low end scopes in the company's history as they're selling now with all this exposure.
That's with the 2.05 firmware your scope came with, right? I'm wondering if this is another piece of evidence that 2.04 SP1 was the last good, stable and bug-free FW release.
Maybe they know this and that's why they are just playing with FW instead of making a HW revision? Make it too much bother for a commercial user to change, but still within reach of the hobbyist?
I have RF test facilities up to 1GHz and hope to check the actual amplitude vs frequency response of the scope rather than measure rise times.
I'm planning on doing this by using the scope itself just as an indicator, with a direct coax feed and no probes, so that the measured results rely only the calibration of the signal generator.
With a background in "conventional" analogue and digital design I'd be the first to admit that my understanding of the digital processing that goes on in something like the DS1052E is strictly limited, but there does seem to be something going on under the bonnet of the 1052 that, to me at least, is quite a lot more complicated than I first expected!
Given that my main measurement interest is in analogue RF I set out a few days ago to confirm the bandwidth of my 1052E with 1102E conversion using analogue measurement techniques rather than pulse driven rise time measurements.
Following my initial tests I quickly realised that indicated amplitude, of a periodic waveform at least, both on the scope display and as measured by the scope, varies with both vertical and horizontal settings. Changing the vertical range can indicate a different amplitude for the same signal and having too many cycles per division horizontally adds distortion and also affects amplitude measurements.
Oh well, so far at least I'm learning some limitations as I go along!
Vertical range variation was, hopefully anyway, eliminated by keeping the scope on the same setting and just adjusting the level at the signal generator.
The horizontal setting was a bit more awkward, you can't swing an input frequency over a 150MHz range without adjusting the timebase, but trial and error indicated that adjusting it such that one cycle of the waveform occupied between 1 and 3 divisions gave a reasonably stable result.
Using an attenuator pad on the output of the generator and a transformer based splitter to supply both channels via 50ohm feed through terminations, I was able to remove any scope probes from the measurement chain, so far so good, and at least establish that both scope channels are very closely matched.
What I measured though didn't seem to be very consistent or to make much sense, sometimes I could measure a -3dB point around 110MHz but at others the response seemed to be almost flat up to around 140MHz and then tailing off quite noticeably at 150MHz.
Today, using either one channel or both, I could not persuade it to change from being almost flat to 140MHz.
That lack of consistency certainly concerns me but, for today anyway, it was consistent enough so I just assumed this might be an artefact of using a modern DSO on a repetitive waveform and that the processing was biasing the result.
All very nice but perhaps a bit too good to be true.
Sooooooooo....., and this is where I really starts to lose the plot, I decided that perhaps I should try a rise time measurement after all.
Feeding the scope from a fast rise time impulse generator, originally intended for the calibration of surveillance receivers at frequencies up to 1GHz, has resulted in a very clean displayed pulse with reported rise times of around 2.5ns.
Jitter seems to be swinging this between approx 2.2 and 2.6ns but it still seems to be indicating a bandwidth of around 150MHz!
So what am I supposed to conclude from all this?
I was happy to accept that my analogue bandwidth measurements could be wrong but now my risetime measurements seem to confirm them after all.
Can my 1102E conversion really have 150MHz bandwidth?
Is this suggestion totally unrealistic?
Can anyone explain exactly what's going on here?
Answers on a postcard please..........:-)
I just recieved my DS1052E today from DealExtreme. It is working fine and looks good.
It came with 00.02.05 SP1, and I haven't tried hacking it yet. But I have still managed to fuck it up, so everytime I turn it on, it shows the splash screen, and afterwards it crashes.
The problem started when I switched the Trigger Slope to the arrows going both ways (both high-to-low and low-to-high triggering) - it crashed just when I had selected that.
Though I've managed to fix the scope again, by disconnecting the source I was measuring on, turn the scope off and on again, and press the Run/Stop button right after the Splash screen disappeared. Then afterwards going into the Trigger menu and changed the Slope back!
Are there anybody in here who would try to do the same thing, and see if the same problem occours? As I said, you can "fix" it, if it happends!
Is it really a bug in 00.02.05?
Best Regards
Thomas Jespersen
This is a "known" issue with 2.05 and seems to have been resolved by a 2.05 sp2 firmware that I believe was posted here a few days ago after a rigol tech emailed it to a member.I just recieved my DS1052E today from DealExtreme. It is working fine and looks good.
It came with 00.02.05 SP1, and I haven't tried hacking it yet. But I have still managed to fuck it up, so everytime I turn it on, it shows the splash screen, and afterwards it crashes.
The problem started when I switched the Trigger Slope to the arrows going both ways (both high-to-low and low-to-high triggering) - it crashed just when I had selected that.
Though I've managed to fix the scope again, by disconnecting the source I was measuring on, turn the scope off and on again, and press the Run/Stop button right after the Splash screen disappeared. Then afterwards going into the Trigger menu and changed the Slope back!
Are there anybody in here who would try to do the same thing, and see if the same problem occours? As I said, you can "fix" it, if it happends!
Is it really a bug in 00.02.05?
Best Regards
Thomas Jespersen