Just got a new DS2072A. I converted to DS2202A with all options (via old FW and old private key).
Will the scope function correctly with the old firmware? Has anyone noted any problems?
Also, I 'lost' the serial number in the process, and the scope is now using default value. On the DG4000 via cengen (see elsewhere on this forum) you can generate a license.GEL file through which one can also apparently mod the serial number. Is such a thing possible for the DS2000? Is there anyway to restore the serial number ? Is there any real harm in having the default?
The scope doesn't ever try call Rigol if ethernet connected right?
Thanks
Steven
BUG in latest f/w, 02.01
Delayed sweep malfunctions.
To reproduce:
Ch2 must be enabled, Ch1 optional
acquire: 7M samples, normal
trigger: ch1 or not important, Auto or Normal seems to have no effect
main timebase 500us/div, delayed t.b. 100 us/div or something
Then when you move the delayed t.b. towards 1 ns/div all seems well until you select 1 ns/div..
It locks up for about 10 seconds, no waveform update, no response to keys.
Then it comes good and lets you go back to 2ns/div
I see what you're talking about, but as mentioned earlier in the thread in regards to problems with the 1ns time base:
It's another error (and there's a few of them) in an, as yet, officially unimplemented - and perhaps unfinished? - portion of firmware. As far as I know, Rigol has not started selling BW updates - but if/when someone on the forum has a DS2302A (or DS2302A-S), we can find out if the error(s) exist in the 'official' working version - and if so, report it to Rigol.
I suggest disabling 300MHz on non-A HW v.1 models. Not only is it buggy (I've had a couple of crashes from it), but it's not really perfectly implemented in the input stage.
How is it possible to uninstall only BW option?
Do ":SYSTem:OPTion:UNINSTall" and then generate new keys without 300 MHz option (with 200 MHz for example) and install them.
It can be two keys: DSAZ (200 MHz, MEM, DC, AT) then DSEA (CAN).
Or simply use DS
EZ instead as the only key, to combine CAN with all the options included in DSAZ (200 Mhz, Mem, Dec and Trig) into a single key.
Combining the two tables below
DSEZ should install CAN, 200 Mhz, Mem, Dec and Trig.
So
DSEZ should be the one key solution to use for non A DS2000 with HW 1 and the latest FW if you want 200 MHz with all available options including CAN but without 50 ohm which is not implemented on HW 1 anyway.
EZ derived from the two tables for y (3rd letter) and x (4th letter) below (DSyx):
y CAN, 300, 50ohm | x 200, 100, Mem, Dec, Trig
E on == == | Z on == on on on <- All 2202
Table for 3rd letter (y):Is this correct?
IMHO would be interesting know the entire table, and thus activate the desired options with a single key.
Code table: Use DSYX for a official key, and use VSYX for a trial key.
Y CAN, 300, 50ohm
A none
B == == on
C == on ==
D ?? ?? ??
E on == ==
F ?? ?? ??
G ?? ?? ??
H on on on
J ?? ?? ??
K ?? ?? ??
L ?? ?? ??
M ?? ?? ??
N ?? ?? ??
P ?? ?? ??
Q ?? ?? ??
R ?? ?? ??
S ?? ?? ??
T ?? ?? ??
U ?? ?? ??
V ?? ?? ??
W ?? ?? ??
X ?? ?? ??
Y ?? ?? ??
Z ?? ?? ??
E instead of
A as 3rd letter enables CAN but still leaves out the 300 MHz BW and 50 ohm which is not implemented on HW 1 anyway.
Table for 4th letter (x): Cybernet has done it, again! *ole*
Now I'm very busy and I can't test anything (check the BW for example).
Anyway. How is the new table?
Code table: Use DSAx for a official key, and use VSAx for a trial key.
x 200, 100, Mem, Dec, Trig
A none
B == == == == on
C == == == on ==
D == == == on on
E == == on == ==
F == == on == on
G == == on on ==
H == == on on on
Note: keys A..H wont change the model, only ADD an option.
2102:
J == on == == ==
K == on == == on
L == on == on ==
M == on == on on
N == on on == ==
P == on on == on
Q == on on on ==
R == on on on on <- All 2102
2202:
S on == == == ==
T on == == == on
U on == == on ==
V on == == on on
W on == on == ==
X on == on == on
Y on == on on ==
Z on == on on on <- All 2202
DONT USE BELOW Not recommended, as activates 2102 and also 2202:
2 on on == == ==
3 on on == == on
4 on on == on ==
5 on on == on on
6 on on on == ==
7 on on on == on
8 on on on on ==
9 on on on on on
Z as 4th letter for 200 Mhz, Mem, Dec and Trig.
And here's the table to convert between binary values and letters:
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg322495/?topicseen#msg322495
ok, I found out about the 0x before I read your reply lol
it says licence is unavailable
It appears that Rigol changed not only ECC keys, but also license code format.
I tried option DSBA on my non-A model with the latest firmware, it said "option installed" but I can't find any changes, certainly not the 50 Ohm option. Would there be a key for that since it is build into all A models as a standard?
I tried option DSBA on my non-A model with the laters firmware, it said "option installed" but I can't find any changes, certainly not the 50 Ohm option. Would there be a key for that since it is build into all A models as a standard?
I think it's unlikely. It's a standard feature on new A-models (and so one of their new selling points vs. non-A models), so it I doubt it would ever be sold as an 'option' specifically for HW v.2 non-A owners - thus no key. But perhaps the FW can be patched to enable it.
I tried option DSBA on my non-A model with the laters firmware, it said "option installed" but I can't find any changes, certainly not the 50 Ohm option. Would there be a key for that since it is build into all A models as a standard?
I think it's unlikely. It's a standard feature on new A-models (and so one of their new selling points vs. non-A models), so it I doubt it would ever be sold as an 'option' specifically for HW v.2 non-A owners - thus no key. But perhaps the FW can be patched to enable it.
I agree, but also wonder what the difference is between the A and non-A models so that the 50 Ohm works on the A but not on the non-A 2.0 hardware. Maybe it is as simple as the model number?
I agree, but also wonder what the difference is between the A and non-A models so that the 50 Ohm works on the A but not on the non-A 2.0 hardware. Maybe it is as simple as the model number?
It could be... changing the model number of the DSOs was all was that required to enable the different BW settings on non-A models. OTOH, as zombie28 pointed out, Rigol has changed a few things to 'enhance' security on the A-models - although that might be irrelevant in this case.
@zombie28: so what to do ... wait for cybernet to find something? ^^
OTOH, as zombie28 pointed out, Rigol has changed a few things to 'enhance' security on the A-models - although that might be irrelevant in this case.
It would be interesting to see what they did to enhance the security, because both A and non-A run on the same firmware, and my non-A still responds to the 'old' keys. Maybe the 2 things are related and it is based on the model number.
@zombie28: so what to do ... wait for cybernet to find something? ^^
yeah, for cybernet or for anyone who will analyze the new firmware and write a keygen
OTOH, as zombie28 pointed out, Rigol has changed a few things to 'enhance' security on the A-models - although that might be irrelevant in this case.
It would be interesting to see what they did to enhance the security, because both A and non-A run on the same firmware, and my non-A still responds to the 'old' keys. Maybe the 2 things are related and it is based on the model number.
I found function that tells licensing engine which version of keys and decoding subroutines to use. This function checks the 4th character of the serial number (i.e. the character after 'DS2') and when it finds anything except 'A' and 'C', then the new version of decoder will be used. For 'A' and 'C' there are some additional checks, but for now I don't know what they mean.
my serial starts with D (after DS2)
I found function that tells licensing engine which version of keys and decoding subroutines to use. This function checks the 4th character of the serial number (i.e. the character after 'DS2') and when it finds anything except 'A' and 'C', then the new version of decoder will be used. For 'A' and 'C' there are some additional checks, but for now I don't know what they mean.
Good news. So, it was one of options - to detect A-version by serial #.
Non-A versions of DS2xxx have 'A' letter in serial # and A-versions have 'D' letter.
I think that 50 ohm "option" is enabled the same way. Regardless of HW version (is there resistor or not).
I see two ways: either somebody can hack the updated algorithm or somehow patch the FW to supress this check.
currently on another track that will hopefully make stuff easier in the future - esp no need for JTAG anymore ;-)
bfin> bdinfo
U-Boot = U-Boot 2013.10 (Dec 30 2013 - 18:01:24)
CPU = bf526-0.0
Board = bf526-ezbrd
VCO = 400 MHz
CCLK = 400 MHz
SCLK = 100 MHz
boot_params = 0x00000000
memstart = 0x00000000
memsize = 0x02000000
flashstart = 0x20000000
flashsize = 0x01000000
flashoffset = 0x00000000
ethaddr = 02:80:ad:20:31:e8
ip_addr = 192.168.0.15
baudrate = 57600 bps
bfin> flinfo
Bank # 1: CFI conformant flash (16 x 16) Size: 16 MB in 71 Sectors
AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E2101
Advanced Sector Protection (PPB) enabled
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 3 ms, buffer size: 64 bytes
Sector Start Addresses:
20000000 RO 20020000 RO 20040000 RO 20060000 RO 20080000 RO
200A0000 RO 200C0000 200E0000 20100000 20120000
20140000 20160000 20180000 201A0000 201C0000
201E0000 20200000 20220000 20240000 20260000
20280000 202A0000 202C0000 202E0000 20300000
20320000 20340000 20360000 20380000 203A0000
203C0000 203E0000 RO 20400000 RO 20420000 RO 20440000 RO
20460000 RO 20480000 RO 204A0000 204C0000 204E0000
20500000 20520000 20540000 20560000 20580000
205A0000 205C0000 205E0000 20600000 20620000
20640000 20660000 20680000 206A0000 206C0000
206E0000 20700000 20720000 20740000 20760000
20780000 207A0000 207C0000 207E0000 20800000
20820000 RO 20840000 RO 20860000 RO 20880000 RO 208A0000 RO
208C0000 RO
bfin> reginfo
System Configuration registers
PLL Registers
PLL_DIV: 0x0004 PLL_CTL: 0x2000
PLL_STAT: 0x00a2 PLL_LOCKCNT: 0xffff
VR_CTL: 0x70f0
EBIU AMC Registers
EBIU_AMGCTL: 0x00f9
EBIU_AMBCTL0: 0xbbc3bbc3 EBIU_AMBCTL1: 0xb6ab77c3
EBIU SDC Registers
EBIU_SDRRC: 0x0fff EBIU_SDBCTL: 0x0013
EBIU_SDSTAT: 0x0000 EBIU_SDGCTL: 0x8011998d
Just to keep owners that aren't reading the DS2000 review thread informed:
More bugs keep getting discovered when running the 300MHz option on HW v.1 DS2000 models (
I just posted another here).
Whether those bugs exist for HW v.2 or A-model owners, I couldn't say - but considering that we've found a few of them - and that on HW v.1 models the BW only seems to increase by ~60MHz (to somewhere between ~280 - 300MHz), you might want to consider if the advantages outweigh the disadvantages before installing the option (on HW v.1)
But 200MHz works fine?
Sure - every version of the DS2000 hardware has been designed to work to 200MHz-2ns/div.
Hello,
Just to make sure: Is the JTAG-port on DS2202A at 3.3 Volt?
Yes, I think.
It shouldn't matter anyway, your JTAG box should power its output stage from the target machines supply. Some, if not most, are happy from 1.8V to 5V.
Git
currently on another track that will hopefully make stuff easier in the future - esp no need for JTAG anymore ;-)
I'm eagerly awaiting what this track will result in!!!
Just got a new DS2072A. I converted to DS2202A with all options (via old FW and old private key).
Will the scope function correctly with the old firmware? Has anyone noted any problems?
Also, I 'lost' the serial number in the process, and the scope is now using default value. On the DG4000 via cengen (see elsewhere on this forum) you can generate a license.GEL file through which one can also apparently mod the serial number. Is such a thing possible for the DS2000? Is there anyway to restore the serial number ? Is there any real harm in having the default?
The scope doesn't ever try call Rigol if ethernet connected right?
Thanks
Steven
What if you upgrade the FW back to the newer A version? Will the options stay?
Are you up to 200MHz? Or did you even manage to get upto 300MHz?
I am interested in DS2072A but want to wait until the hack is confirmed with new FW and all options enabled, including 300MHz and CAN decoding.
Can still get old DS2072 here in Sweden, maybe that is better? But that one does not get up to 300MHz, so maybe better to wait? Do you really need 50 ohm impedance? That you can fix externally with BNC adapter not?
If you just read some pages of this thread at least, it seems that it's very close to fixing it for the A series
At least I ordered the A series in anticipation of the keygen
What if you upgrade the FW back to the newer A version? Will the options stay?
A is model type - v.2 is the newer FW. But upgrading to v.2 FW with options enabled on A models does not retain the options; there is a different version of the key and decoding for them in v.2 FW.
BTW, I've heard Rigol is working on new security measures for all the devices which have been hacked - so if anyone has been on the fence about purchasing one of them (and you want to be certain you can run the current versions of keygens), it might be best to act soon.
Is somebody actively working on this hack for the DS2072A?
Has it been confirmed already that the HW design is identical between DS2072A and DS2302A?
I know that it has been confirmed between DS2072 and DS2202, but not for the A series AFAIK, and especially not for the new 300 MHz variant.