Sniffing the Rigol's internal I2C bus

[NikWing]

I fail to update the f*cking glibc from 2.13 to something newer (2.18 is current version) -_-
it's not in the repositories ...

wasting hours with linux and stuff gah.

[battlefield]

I actually connected pin 1 from the JTAG header with the 3.3V pin from the 4 pin header on the other side of the board and also to my JTAG adapter and it worked perfectly fine and so does the scope (especially now when I have everything unlocked )

[granz]

Yes, it probably will work.  I'm just saying it's a BAD IDEA.  Just because it happens to work doesn't mean it is correct.  You shouldn't be connecting two separate regulated outputs together.  There is probably just a fairly high value resistor in series with the 3.3V pin on the JTAG header.

See this:

http://electronics.stackexchange.com/questions/55270/is-it-ok-to-connect-the-output-of-buck-regulator-in-parallel

[NikWing]

ok, please help D:
I'm currently trying to find out if the avr jtagice mk2 can actually be used with blackfin ...
is jtag interface = jtag interface?
or are there special jtag interfaces?
I don't know yet how to connect with the gdbproxy, I read somewhere that WIGGLER is compatible with the avr jtagice mk2, but I don't see anything about how to use it -_-

[pascal_sweden]

I have received feedback from the Swedish distributor that the DS2072 which is on sales (special offer as DS2072A replaces the old model) is in fact HW version 2.

Is it worth to buy the HW version 2? Or is the A version even better?
What is missing in the old HW version 2?

I understand that HW version 2 is easy to hack in current FW version, but does only go up to 200MHz.
And in future FW versions it could be as difficult as on the A version, which might go up to 300MHz?

[Posterisan]

I installed Ubuntu 32-Bit and the blackfin toolchain, still no jtag connection with my segger j-link.

Linux output:

Code: [Select]

debug:     bfin: bfin_open ()
Found USB cable: jlink
J-Link initial read failed, don't worry (result=0)
Vref = 3.371 TCK=0 TDI=0 TDO=1 TMS=0 TRES=1 TRST=0
J-Link JTAG Interface ready
warning: TDO seems to be stuck at 1
error:     bfin: detecting parts failed
debug:     bfin: bfin_open ()
Found USB cable: jlink
error:     bfin: cable initialization failed

double checked all cable connections.  i have no idea whats wrong.

[cybernet]

Rigol can't afford to ignore the hacks, but they would be wise to view them as an opportunity rather than an attack.

It would be very wise for us if we did not bite the hand that feeds us by making the hacks too easy to use.  There needs to be a minimum amount of skill required to accomplish the hacks.  I don't know what this skill level should be, but making web apps capable of providing valid keys by providing a serial number and a four character option code is definitely something that I would consider "biting the hand that feeds us."

Exactly what happened, the skill level required is to dump the memory via JTAG

except if there would magically appear a tool to dump stuff without need for jtag ... *cough*

[Pehtoori]

I fail to update the f*cking glibc from 2.13 to something newer (2.18 is current version) -_-
it's not in the repositories ...

wasting hours with linux and stuff gah.

Might not be good idea to try upgrade glibc. Kind of fundamental foundation of the system. And you have to maintain binary compatibility.

So use newer live CD and spare your self from trouble.

[NikWing]

Pehtoori: too late XD
but I guess the JTAGICE mk2 is not supported -_-
damn, wasted time :/

cybernet: yeah, send it already ;P
*cough* ^^

I don't find any supported interface in germany
the next I see is the olimex from the UK via ebay ...
or shops want 25+ EUR extra ...
I'll never need a jtag again in the future D:

[Pehtoori]

Exactly what happened, the skill level required is to dump the memory via JTAG

except if there would magically appear a tool to dump stuff without need for jtag ... *cough*

There is no magic involved, but hard work of respectable guru

[granz]

I don't find any supported interface in germany
the next I see is the olimex from the UK via ebay ...
or shops want 25+ EUR extra ...
I'll never need a jtag again in the future D:

6,99 euro:

http://www.ebay.de/itm/USB-Blaster-Programmer-W-Cable-for-ALTERA-FPGA-CPLD-JTAG-Development-Board-AS-PS-/251282935520?pt=Wissenschaftliche_Ger%C3%A4te&hash=item3a81a14ee0

Added benefit of allowing you to get started with Altera FPGAs.

[Rigby]

except if there would magically appear a tool to dump stuff without need for jtag ... *cough*

Excellent.   

[NikWing]

yeah, seen the chinese thing XD look at shipping date
oh well, let's wait some more ...

[granz]

On top of this, I've overlaid the results (the yellow line) that someone posted here for the response curve of a 300MHZ "enabled" DS2000 HW v.2.  If these results are correct, the area of filter leakage (the orange diagonal lines) increases to a point above -6dB when using two channels.

I would suggest, for anyone enabling 300MHz on ANY DS2000 - that wants to be certain of signal fidelity (unless/until we see further tests), to use it only with 1 channel @ 2GSa/s (otherwise use the channel BW filter).

Marmad, thanks for posting this.  This is what I was concerned about with all the unlocking going on, but I never saw the source of the yellow trace.  Once I find (or borrow) a higher frequency signal generator I'll try to collect some more data from my (now unlocked) DS2072A and post.

[marmad]

Marmad, thanks for posting this.  This is what I was concerned about with all the unlocking going on, but I never saw the source of the yellow trace.  Once I find (or borrow) a higher frequency signal generator I'll try to collect some more data from my (now unlocked) DS2072A and post.

No problem. I think it's important to find out how low >= 500MHz signals are when the 300MHz option is enabled. Rigol doesn't have the greatest skills at designing filters - and I have to think market pressures (GW-Instek and Siglent releasing 300MHz low-cost DPO models) and the desire to have "new" features for the A-model were the driving reasons behind the new BW - rather than their touted "New input stage"

[poida_pie]

Marmad, I asked before but maybe you overlooked it, but can you tell me where you got the data for the yellow trace?

[neslekkim]

Exactly what happened, the skill level required is to dump the memory via JTAG

except if there would magically appear a tool to dump stuff without need for jtag ... *cough*

That would be great!

[zombie28]

except if there would magically appear a tool to dump stuff without need for jtag ... *cough*

or a firmware that forces A model to use non-A license decoder... *cough cough*

[marmad]

Marmad, I asked before but maybe you overlooked it, but can you tell me where you got the data for the yellow trace?

Sorry - I did miss your previous post - this thread moves so fast sometimes it's hard to keep up   And yes, the info was posted by PA0PBZ over in the DS2000 review thread - but I questioned whether it was accurate or not at the time.

His test(s) indicate a -3dB BW of ~390MHz, but in order to avoid possible interpolation errors, I would hope that Rigol actually tried to get the -3dB BW as close to 300MHz as possible. Of course, he only tested until around ~500MHz - my chart just extrapolates a further Gaussian response based on his numbers - but we certainly need more tests by more people to get a better handle on the situation. More BW above the Nyquist frequency is not a good thing - it's a bad thing.

Here is his chart:

[AndersAnd]

except if there would magically appear a tool to dump stuff without need for jtag ... *cough*

or a firmware that forces A model to use non-A license decoder... *cough cough*

Will the 50 ohm input option still work then as it's only on the A models originally?

[zombie28]

Will the 50 ohm input option still work then as it's only on the A models originally?

I think so, because it doesn't change model type, just license decoding method. However, I haven't tested it yet, because I'm still waiting for "A" scope availability in my area.

[poida_pie]

"More BW above the Nyquist frequency is not a good thing - it's a bad thing."

Totally agree. We need someone to take a DS2000, modded to 300 MHz and check response to 1 GHz (2 channels).
Any signal over Nyquist freq. limits will reappear as an alias. For peace of mind I would also like the test to be done on a 200 Mhz modded unit. We need to see just how steep the dropoff of the LMH6518 is at 500Mhz and above.

[marmad]

For peace of mind I would also like the test to be done on a 200 Mhz modded unit. We need to see just how steep the dropoff of the LMH6518 is at 500Mhz and above.

Well, there have been a couple of tests done by people with 200Mhz on v.1 HW that indicate that the -3dB point is ~240MHz, with 500MHz about ~15dB down. Even at 300MHz the rolloff looks pretty good (although the v.1 HW might not quite reach 300MHz by -3dB), so I still have doubts as to whether the data I used in my chart is accurate.

[Mark_O]

We need to see just how steep the dropoff of the LMH6518 is at 500Mhz and above.

The specs for the LH6518 indicate in 350 MHz mode it is down only 10 dB at 960 MHz, -7.5 dB ~750 MHz, -5 dB ~550 MHz, and -3 dB ~380 MHz.  Of course, other components affect the aggregate bandwidth.

For comparison, in 200 MHz mode, it's spec indicates -10 dB ~750 MHz, -5 dB ~300 MHz, and -3 dB ~200 MHz.

[Marc M.]

Good news Everyone!  Attached to this post is a utility to repair corrupted S/N's on DS2000 series scopes!  Someone I know took up the challenge to write a utility to repair corrupted serial numbers as their contribution to all the great work done so far.  It's a simple but very clever Windows .exe file that will ask your model/serial # and modify a .gel file located in the same directory as the executable file.  Note: This utility only works with firmware version 00.01.01.00.02.  If you need a copy of this firmware version, see Marmad's post (Reply #2) in this thread: https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/  The locations of the model & S/N change between firmware versions so it will corrupt any other version of firmware so verify that you have firmware version 00.01.01.00.02.  It also requires the ability to send SCPI commands to the scope.

Instructions for Use:
SNMODFIX

Use at your own risk - not sure if safe with A models with unknown model values
It is only advised to use this on scopes with a mangled 14 digit DS2A0000000001
to fix what the scope messed up, your model type might be unknown or wrong and
could be overwritten with the wrong value by doing this.

1.  Requires 00.01.01.00.02 firmware (7777543 bytes, 0xa167ef30 crc32) named
       DS2000Update.gel in same directory as executable
2.  Execute snmodfix and specify serial and model to patch firmware
3.  Flash patched ds2000update.gel using power on help button method
4.  Restart scope
5.  Enable advanced system information menu (press Trigger Menu, Menu 7,
       Menu 6, Menu 7, Utility very quickly) to enable it
6.  Show system information - serial should be fixed but NOT saved to flash
      yet - some text labels will be missing
7.  Connect using scpi and issue :SYSTem:OPTion:UNINSTall command which will
      uninstall all keys and save to flash
8.  Once settled restart scope
9.  Show system information (not advanced) should now show the correct serial
      and model
10. Update to latest stock unpatched firmware version
11. Storage -> Default
12. Reinstall any key(s)

Tested on several DS2072's w/ original hardware and it works perfectly.  Again, this has not been tested on any hardware versions other than 1.0.  Please don't ask about a Linux version as neither of us are Linux users.  Also, I don't have the source code as the author didn't offer it.  I'm very grateful for his work and won't pester him for the source code.  If you have any issues/suggestions/comments please feel free to contact me.
Edit: Corrected firmware link