EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: klaus11 on March 29, 2018, 08:11:31 am
-
it possible to do it?
-
It's pretty straightforward to hack the application modules. As for the other features, I don't know of any successful attempts.
I have a MDO4034B and when it boots up, it does say something on the syslog about a 1GHz analog board. Sure would be nice to liberate that extra 650MHz. >:D
EDIT: The info about the 1GHz analog board is not in the "console log", it's actually displayed on the scope's GUI in manufacturing mode.
-
https://0bin.net/paste/tZYZ4Fs5rjqvAoza#+yNeuILPU-nQmgFvDixaTsFyVclm2Mnh2gr2Id/aSBL
-
Super Abyrvalg!
For Upgrade bandwidth 1GHz, is it necessary to modify hardware ?, remove some capacitor or resistor ...
I have searched a service manual for some clue, but it is a useless manual
-
I've hacked a DPO4034 (non-B) to enable full bandwidth by hacking the software - bandwidth seems to be software configured, and the pre-amplifier is actually populated. However only half the number of ADCs are populated, making this hack not super useful. I need to characterize the bandwidth but last time I looked I didn't have the right tools.
Then I hacked a DPO5034 (which is - hardware wise - similar to the DPO4034B, i.e. it has a separate frontend board), see http://debugmo.de/2013/03/whats-inside-tektronix-dpo5034/ (http://debugmo.de/2013/03/whats-inside-tektronix-dpo5034/) , by removing the filter. I only did this on one channel, though. I also hacked the software for it to be detected as a 1GHz model so the UI behaves properly. (The 1GHz and 2GHz models usually have the advanced frontend board with the pre-amplifier, but the 350MHz and 500MHz models only have basic analog board). All of the DPO5xxx however have the same (full) ADC configuration, only the analog board is different.
(I'd guess the DPO4034B however would only have the half-ADC config.)
The MDO4xxx however (regardless of -, -B, -C) again have a similar design as the DPO4xxxB, full-ADC config (since they need half the ADCs for the RF part), and of course have the MDO-style analog frontend with the RF part.
What I don't know is if they have the pre-amplifier for the non-RF channels (which I think implies a SW bandwidth limit) or not (which would probably be a HW BW limit then).
Can you post the syslog, and pictures of your analog frontend?
-
Thanks, but analog frontend is very different from MDO4KC, here the filter is not so clear to see, at least for me.
-
https://0bin.net/paste/b41u5jNJcqNlURuI#fG6cEz17pYOVFTR5EX8I5XA9p8OdbkfyFLgGL0Z95O3
-
andyturk, thanks, that explains some things.
I can elaborate on chapter 9 of that text: the cfgSetUBootEnvVariable is just a name of a function in firmware, but it is not mapped to any console/GPIB cmd directly. It is called by cfgSetSerialNumber function (which is brought out to both console and GPIB explicitly) with "serial#" parameter, then by cfgSetBboSerialNumber (accessible from GPIB only) with "bboard#" and "hostname" params.
Looks like there is another "mode" enabled/disabled in a way similar to MFG mode:
:PASSW TRESPASS
:DEV:MOD 1
...
:DEV:MOD 0
Are there any new menus enabled with this?
-
oh yeah...
-
Note the sticker. :-/O
-
klaus11, for -C models the max possible bandwidth depends on actual board types installed. Try getting device log (as in andyturk's link) to see main/AFE models. There are both MB and AFE limits:
afeid bw
1, 2 200M
3 1G
4 200M
5 350M
other 200M
mbid, bw
1, 5 1G-1G
2, 6 200M-500M
7 200M-1G
-
Bravo Abyrvalg!
Bravo andyturk!
-
Bravo Abyrvalg!
Bravo andyturk!
couldn't agree more... :clap:
-
I’m sure I’ve missed it somewhere, are there some resistor IDs on the 4000B to change, and if so where are they?
-
Interesting, this thread appears to be non-existent in Google, one can but wonder why that might be.
DuckDuckGo comes up right away. Google is not your friend in this case.
-
Note the sticker. :-/O
I have a similar result on an MDO4054C that I recently purchase, except that after upgrading the bandwidth, I get a permanent "WARNiNG: This oscilloscope is not compensated." SPC also consistently fails after two minutes. If I remove the bandwidth option, reverting to 500MHz, all is fine again.
(https://www.eevblog.com/forum/testgear/someone-has-hacked-mdo4000c/?action=dlattach;attach=790284;image)
Edit: my unit has MB HW ID 7, and AFE SW ID of 2. It is an MDO4054C with SA6 factory fitted at manufacture.
For fully loaded but original bandwidth:
gen.py MDO4054C C###### 500MHz DVM DDU AFG MSO TRIG EMBD COMP ENET USB PWR AUDIO AERO AUTOMAX LMT VID SEC
For fully loaded with 1GHz bandwidth:
gen.py MDO4054C C###### 500MHz DVM DDU AFG BW5T10 MSO TRIG EMBD COMP ENET USB PWR AUDIO AERO AUTOMAX LMT VID SEC
-
https://0bin.net/paste/tZYZ4Fs5rjqvAoza#+yNeuILPU-nQmgFvDixaTsFyVclm2Mnh2gr2Id/aSBL
I think there is a little bug when using this for the MDO4000C in the way it determines the key to use: as it stands, it will always generate MDO3000 keys if you specify an MDO4000C.
I am not a Python programmer, but I hacked the code for key.py to comment out the MDO4000B for my purposes, I suspect an elif might be a better longer term option.
The problem was that although the 4000C key was correctly selected, it is immediately overwritten with the MDO3000 key.
Original key.py:
# generate an option key
def encode(model, sn, mask):
if model.startswith("MDO4") and model.endswith("C"):
k = mdo4kc_key
if model.startswith("MDO4") and model.endswith("B"):
k = mdo4kb_key
elif model.startswith("MDO"):
k = mdo3k_key
else:
k = dpo3k_key
uid = GenerateUID(model, sn)
Hacked key.py for MDO4000C and MDO3000 only:
# generate an option key
def encode(model, sn, mask):
if model.startswith("MDO4") and model.endswith("C"):
k = mdo4kc_key
print "mdo4kc_key"
# if model.startswith("MDO4") and model.endswith("B"):
# k = mdo4kb_key
# print "mdo4kc_key"
elif model.startswith("MDO"):
k = mdo3k_key
print "mdo3k_key MDO"
else:
k = dpo3k_key
print "mdo3k_key default"
uid = GenerateUID(model, sn)
# find first leading 1 bit
-
Original key.py:
# generate an option key
def encode(model, sn, mask):
if model.startswith("MDO4") and model.endswith("C"):
k = mdo4kc_key
if model.startswith("MDO4") and model.endswith("B"):
k = mdo4kb_key
elif model.startswith("MDO"):
k = mdo3k_key
else:
k = dpo3k_key
uid = GenerateUID(model, sn)
The "correct" correction should be:
# generate an option key
def encode(model, sn, mask):
if model.startswith("MDO4") and model.endswith("C"):
k = mdo4kc_key
elif model.startswith("MDO4") and model.endswith("B"):
k = mdo4kb_key
elif model.startswith("MDO"):
k = mdo3k_key
else:
k = dpo3k_key
uid = GenerateUID(model, sn)
I think this what the original programmer intended it to be.
-
Like I said I’m not a Python programmer!
-
I can get rid of the red compensation banner temporarily by enabling factory pass from the calibration memory. However after a reboot it returns.
To remove red "WARNING! This oscilloscope is not compensated." banner after each boot:
- Login with telnet, note commands are sent in the blind:
telnet <scopehostname> 4000
:PASSW TRESPASS
:DEV:MOD 1
Utility -> Calibration -> Factory Cal -> Always Pass: Yes
- Finally, optionally from telnet to remove the new menus:
:DEV:MOD 0
Tonight I managed to do a factory calibration, and immediately for the first time a successful SPC. Being my first time, the whole process took me about two hours, but I had to build a 24Vpp amplifier for my AWG which maxes out at 20Vpp.
However, after a reboot the red compensation error banner returned. I suspect I may need to lock the calibration afterwards?
Is anyone familiar with recent Tek scope calibration processes? Is there something one should do after a successful cal and SPC?
-
Note the sticker. :-/O
@andyturk I am curious about the pcb on the bottom right of the image ? is it a kind of DIY probe that use the proprietary tek connector ?
-
Note the sticker. :-/O
@andyturk I am curious about the pcb on the bottom right of the image ? is it a kind of DIY probe that use the proprietary tek connector ?
That is Leo Bodnar's pulser that he uses to get that pulse on the screen.
-
Hi All - Wow this thread was hard to find.. again.. for some reason. (perhaps a good thing)
I'm trying to better understand what is possible with the MDO4000C and this thread has good info but raises more questions that it answers..
1. It seems you can liberate modules and bandwidth via the python script.. probably only with the "Corrected" version so one would have to put the old python build environment together.. there are not great instructions on.. (I ran into lots of compatibility issues and code errors when I did this for my MDO3k - especially with the crypto library no longer supported)
2. @abyrvalg mentioned that MDO4000Cs may all differ from each other and you don't know what you have until you check the board IDs.. is this really true? Does anyone have details on this? So a 4024 can only be turned into a 4104 if you are lucky? (or not at all?). Anyone know about serial number ranges.. or have examples?
3. @andyturk when you say it is easy to do the application modules on the "C" you mean via the python script method?
4. @Howardlong any luck with that red stripe? Can you live with it if you can't get rid of it. Was this 100% via python or did you make changes to model numbers like on the B models..
Ahhh.... I really want to get a used mdo4k.. but don't feel I have confidence it will perform at the price point I can afford..
-
Hi All - Wow this thread was hard to find.. again.. for some reason. (perhaps a good thing)
I'm trying to better understand what is possible with the MDO4000C and this thread has good info but raises more questions that it answers..
...
4. @Howardlong any luck with that red stripe? Can you live with it if you can't get rid of it. Was this 100% via python or did you make changes to model numbers like on the B models..
Ahhh.... I really want to get a used mdo4k.. but don't feel I have confidence it will perform at the price point I can afford..
Below is my experience with an MDO4054C-SA6. So, it may be that other versions don’t have all the hardware bits populated, ISTR there’s a scheme that shares ADCs between the SA and scope. Certainly if I run the scope and SA simultaneously, when upgraded to 1GHz bw, the scope sample rate drops to 2.5GSa/s. The same applies in scope only mode if you enable three or more channels, but that’s documented by Tek, I assume they’re interleaving ADCs.
The red stripe appeared after I’d enabled the 1GHz bw. You can remove the red stripe by going into the dev menus and allowing it to pass tests, but you need to do it after each reboot (edit: see up thread). As far as I can tell it’s only a cosmetic annoyance, obscuring the display of the screen buffer overview. The scope seems to be reasonably accurate at 1GHz bw despite not being calibrated. When you remove the 1GHz bw option, the stripe disappears after a reboot.
I’ve been unable to successfully calibrate it at 1GHz bw. It won’t let you run an SPC without a valid cal either. Switching back to 500MHz bw, everything is fine and you can run an SPC successfully.
I can’t get one of the 70 odd cal steps to pass, and I still don't know why, but it’s near the end and can take an hour and a half to get to it. I don’t have any more information about calibration other than what’s provided onscreen (very terse) combined with some information I found about calibrating a DPO4000 that helped a little. I don’t have the Fluke calibration equipment of course, but I managed to build a few jigs and voltage amplifiers that seemed adequate for a cal.
Unless I need the extra bandwidth or a function requiring 1GHz (e.g. USB HS trigger/decode), I use the scope at its factory 500MHz.
I have a little USB thumb stick sized arduino keyboard macro generator with three buttons to select what options to set, saving me having to manually rekey. One button for default settings, one with everything enabled except 1GHz (my usual selection) and finally one with everything plus 1GHz. You need to restart the scope after each config option change.
Keep in mind that you might want to purchase the 1GHz passive probes which come up on eBay fairly frequently, but they’re not always particularly cheap. I’d already accumulated a set of four over a period of time. The 3.9pF is still a significant load at 1GHz!
What I’ve been unable to find out definitively is what is included in an upgrade from 500MHz to 1GHz, priced at about £2.3k. My reseller wanted to charge me for the upgrade, plus a new cal, plus the probes, so as that would raise the total to about 5 grand, I rejected it. I’ve read elsewhere that the probes and recal is included in the £2.3k upgrade path. If it were the latter, I’d pay for it.
Regarding the Python script, I did make a change, it’s documented somewhere on the forum, there was a problem with it choosing the right key for one of the scope series (3000, 4000B or 4000C) but I can’t remember which one. (Edit: see upthread, it affected the 4000C).
-
Thank you so much @Howardlong. That is super helpful.
So you made a small hardware device that runs your codes.. that is super cool!
Do you remember what python versions you are running to make it run? Operating system/python version/crypto version? (Edit: I see now there are links in the "link" on versions.. but probably still a good questions to ask)
So you would pay 2k to get rid of the red banner? :) (Edit: A man with similar OCD as myself??)
Many thanks and happy holidays..
-
Thank you so much @Howardlong. That is super helpful.
So you made a small hardware device that runs your codes.. that is super cool!
Do you remember what python versions you are running to make it run? Operating system/python version/crypto version? (Edit: I see now there are links in the "link" on versions.. but probably still a good questions to ask)
So you would pay 2k to get rid of the red banner? :) (Edit: A man with similar OCD as myself??)
Many thanks and happy holidays..
Python version was 2.7x but they seem to have the crypto included in some distros, certainly the one a did a few moths ago included it.
Regarding the 2k to “remove the banner”, it’s probably as much to do with resale value as it is my own OCD!
-
https://0bin.net/paste/tZYZ4Fs5rjqvAoza#+yNeuILPU-nQmgFvDixaTsFyVclm2Mnh2gr2Id/aSBL
so is it possible to enable options on DPO4000 series, too?
-
https://0bin.net/paste/tZYZ4Fs5rjqvAoza#+yNeuILPU-nQmgFvDixaTsFyVclm2Mnh2gr2Id/aSBL
can someone confirm if this works for DPO4000 series (non -B or -C), please?
-
DPO4000 uses the same AES_key as DPO3000, so you can easily change the script to accommodate for it.
BTW:
dpo4kb_key = "\x2A\x62\x31\x9B\x7F\x06\x34\x2A\x90\x1F\x07\x64\x80\x6A\xDE\xC2"
mdo4kc_key= "\xC5\x6F\x22\xB2\x5E\x70\xF1\x30\xAF\x3E\xF3\x11\x88\x11\xBF\x1B"
Edit: If the mdo4kc_key in the python script is correct, then I must have something wrong in these 2 keys.
Maybe it's like this:
dpo4kb_key = FC A9 8B 9E EF FB 95 48 B1 ED F1 3A C4 09 83 75
-
DPO4000 uses the same AES_key as DPO3000, so you can easily change the script to accommodate for it.
BTW:
dpo4kb_key = "\x2A\x62\x31\x9B\x7F\x06\x34\x2A\x90\x1F\x07\x64\x80\x6A\xDE\xC2"
mdo4kc_key= "\xC5\x6F\x22\xB2\x5E\x70\xF1\x30\xAF\x3E\xF3\x11\x88\x11\xBF\x1B"
I don't know any Python at all :-//
So is it enough just to add/change these two lines :
dpo4k_key = "\x9B\x31\x62\x2A\x2A\x34\x06\x7F\x64\x07\x1F\x90\xC2\xDE\x6A\x80" ---->>> same as DPO3000
:
:
:
keys = (("DPO4000", dpo4k_key),("MDO3000", mdo3k_key), ("DPO3000", dpo3k_key), ("MDO4000B", mdo4kb_key), ("MDO4000C", mdo4kc_key))
or other changes are also needed?
-
... or you get yourself a little option module (some cheap TDS3FFT / TRG), and reprogram it for the options you need, one by one, and transfer these to the scope (no DPO4BND for the non-B DPO4K...)
-
... or you get yourself a little option module (some cheap TDS3FFT / TRG), and reprogram it for the options you need, one by one, and transfer these to the scope (no DPO4BND for the non-B DPO4K...)
i didnt know the same modules also fit DPO4000 :-[ Do they, really?
what if I change the EEPROM in the module to something bigger like 24C16 and put several options in it at the same time?
is it possible? Based on what I had read about TDS3UAM hack for TDS3000, it was possible. I dont have any of those modules for now..
I still prefer to get the Python code running but don't know what changes other than those I mentioned in the previous post are required
-
DPO4000 uses the same AES_key as DPO3000, so you can easily change the script to accommodate for it.
BTW:
dpo4kb_key = "\x2A\x62\x31\x9B\x7F\x06\x34\x2A\x90\x1F\x07\x64\x80\x6A\xDE\xC2"
mdo4kc_key= "\xC5\x6F\x22\xB2\x5E\x70\xF1\x30\xAF\x3E\xF3\x11\x88\x11\xBF\x1B"
why the mdo4kc_key is different than what is in the script? was the script wrong?
i dont have that scope but just curious...
-
why the mdo4kc_key is different than what is in the script? was the script wrong?
I think mine is the correct (old) one. The "fake" in the code is definitely wrong.
I'm not sure that (new) key inside the python script is correct or maybe it's used in newer FWs. Only a MDO4000C owner can confirm this.
-
dpo4k_key = "\x9B\x31\x62\x2A\x2A\x34\x06\x7F\x64\x07\x1F\x90\xC2\xDE\x6A\x80" ---->>> same as DPO3000
:
:
:
keys = (("DPO4000", dpo4k_key),("MDO3000", mdo3k_key), ("DPO3000", dpo3k_key), ("MDO4000B", mdo4kb_key), ("MDO4000C", mdo4kc_key))
or other changes are also needed?
Correct. But simpler could be just rewrite this one:
keys = (("DPO4000", dpo3k_key), ("MDO3000", mdo3k_key), ("DPO3000", dpo3k_key), ("MDO4000B", mdo4kb_key), ("MDO4000C", mdo4kc_key))
-
... or you get yourself a little option module (some cheap TDS3FFT / TRG), and reprogram it for the options you need, one by one, and transfer these to the scope (no DPO4BND for the non-B DPO4K...)
i didnt know the same modules also fit DPO4000 :-[ Do they, really?
Yes, it's the same format... just that from the MDO onwards, the key was encrypted, but up to the DPO4000B, it was in clear text.
So for the DPO4000B, with DPO4BND, you're done, but for the DPO4000, you'd have to reprogram the module as many times as you want options. And no, you can't put more than one option in the module's eeprom (well, you could... but it wouldn't work, to my knowledge).
-
I finally received the DPO4104, it has self test errors (see another thread on Repair section) but the scope seems to work pretty ok. so far I have not been able to find out what problem those errors cause
However, I want to enable the options and I had read all the MDO and DPO 3000/4000B/4000C hacking threads. Now that I have got the scope
I can see none of those methods and techniques are applicable really :palm: |O
Let's say I generate the key with python script, then what? There is no place in this scope to enter any key :palm: |O
Let's say I use the module programming, then what? there is no place to "transfer" the license to the scope :palm: |O
so, unless there is a way to program a module (with a new larger EEPROM) with several options (similar to TDS3000) then I cannot see how these scopes can be hacked really.
Is there any way to do it through the SCPI commands? Telnet?
-
I finally received the DPO4104, it has self test errors (see another thread on Repair section) but the scope seems to work pretty ok. so far I have not been able to find out what problem those errors cause
However, I want to enable the options and I had read all the MDO and DPO 3000/4000B/4000C hacking threads. Now that I have got the scope
I can see none of those methods and techniques are applicable really :palm: |O
Let's say I generate the key with python script, then what? There is no place in this scope to enter any key :palm: |O
Let's say I use the module programming, then what? there is no place to "transfer" the license to the scope :palm: |O
so, unless there is a way to program a module (with a new larger EEPROM) with several options (similar to TDS3000) then I cannot see how these scopes can be hacked really.
Is there any way to do it through the SCPI commands? Telnet?
having all options enabled in the TDS3000 is not a matter of having a larger eeprom, that works with the ‘engineering option’ TDS3ENG, a bit like the official option bundle DPO4BND (unfortunately not in the pre-B models). Not having the menu to transfer a module’s license into the scope is most probably a FW version issue (got 2.68 ?).
-
Is the bandwidth on DPO4000B software upgradable? I dont mean to 1GHz but something like 350MHz to 500MHz or 100MHz to 350MHz
-
I don’t have a 4000B, but I believe so.
I have a recollection that some 4000Bs can be liberated to 1GHz if they have the right hardware.
-
I don’t have a 4000B, but I believe so.
I have a recollection that some 4000Bs can be liberated to 1GHz if they have the right hardware.
can anybody confirm? even upgrade to 500MHz is good. there is no official lupgrade option in the datasheet
but since MDOs had BW upgrade I though DPO4000B probably have it too
-
I don’t have a 4000B, but I believe so.
I have a recollection that some 4000Bs can be liberated to 1GHz if they have the right hardware.
can anybody confirm? even upgrade to 500MHz is good. there is no official lupgrade option in the datasheet
but since MDOs had BW upgrade I though DPO4000B probably have it too
Have you tried it? It’s as simple as running gen.py with the right options to create the option key.
-
I don’t have a 4000B, but I believe so.
I have a recollection that some 4000Bs can be liberated to 1GHz if they have the right hardware.
can anybody confirm? even upgrade to 500MHz is good. there is no official lupgrade option in the datasheet
but since MDOs had BW upgrade I though DPO4000B probably have it too
Have you tried it? It’s as simple as running gen.py with the right options to create the option key.
no I dont have the equipment. I have the opportunity to buy a 100MHz version for a good price
but I only want to do it if the BW upgrade is possible
-
There’s a semi cryptic note here
https://www.eevblog.com/forum/testgear/mdo3000-hacking/msg1603087/#msg1603087 (https://www.eevblog.com/forum/testgear/mdo3000-hacking/msg1603087/#msg1603087) Post 141
-
There’s a semi cryptic note here
https://www.eevblog.com/forum/testgear/mdo3000-hacking/msg1603087/#msg1603087 (https://www.eevblog.com/forum/testgear/mdo3000-hacking/msg1603087/#msg1603087) Post 141
umm...yeah. that's for MDO4000B though but I guess they are very similar to DPO4kB at least they dont have official BW upgrade option in their datasheet just like DPO4kB.
But I wonder what he meant because I cannot find that method he is talking about
-
There’s a semi cryptic note here
https://www.eevblog.com/forum/testgear/mdo3000-hacking/msg1603087/#msg1603087 (https://www.eevblog.com/forum/testgear/mdo3000-hacking/msg1603087/#msg1603087) Post 141
umm...yeah. that's for MDO4000B though but I guess they are very similar to DPO4kB at least they dont have official BW upgrade option in their datasheet just like DPO4kB.
But I wonder what he meant because I cannot find that method he is talking about
Sorry, my bad!
-
I finally received the DPO4104, it has self test errors (see another thread on Repair section) but the scope seems to work pretty ok. so far I have not been able to find out what problem those errors cause
However, I want to enable the options and I had read all the MDO and DPO 3000/4000B/4000C hacking threads. Now that I have got the scope
I can see none of those methods and techniques are applicable really :palm: |O
Let's say I generate the key with python script, then what? There is no place in this scope to enter any key :palm: |O
Let's say I use the module programming, then what? there is no place to "transfer" the license to the scope :palm: |O
so, unless there is a way to program a module (with a new larger EEPROM) with several options (similar to TDS3000) then I cannot see how these scopes can be hacked really.
Is there any way to do it through the SCPI commands? Telnet?
Wonder if you managed to enter the option code, I just scored a MDO4K and found no way to enter the option key :palm:
-
I finally received the DPO4104, it has self test errors (see another thread on Repair section) but the scope seems to work pretty ok. so far I have not been able to find out what problem those errors cause
However, I want to enable the options and I had read all the MDO and DPO 3000/4000B/4000C hacking threads. Now that I have got the scope
I can see none of those methods and techniques are applicable really :palm: |O
Let's say I generate the key with python script, then what? There is no place in this scope to enter any key :palm: |O
Let's say I use the module programming, then what? there is no place to "transfer" the license to the scope :palm: |O
so, unless there is a way to program a module (with a new larger EEPROM) with several options (similar to TDS3000) then I cannot see how these scopes can be hacked really.
Is there any way to do it through the SCPI commands? Telnet?
Wonder if you managed to enter the option code, I just scored a MDO4K and found no way to enter the option key :palm:
On my MDO4000C, it's Utility -> Utility Page: Config -> Manage Modules & Options -> Install Option.
It's a little easier to key in if you have a USB keyboard handy that you can attach.
-
On my MDO4000C, it's Utility -> Utility Page: Config -> Manage Modules & Options -> Install Option.
It's a little easier to key in if you have a USB keyboard handy that you can attach.
I am using a MDO4104-6, on the Install Option page, I can’t find any way for me to enter the key :-//
[attach=1]
[attach=2]
-
On my MDO4000C, it's Utility -> Utility Page: Config -> Manage Modules & Options -> Install Option.
It's a little easier to key in if you have a USB keyboard handy that you can attach.
I am using a MDO4104-6, on the Install Option page, I can’t find any way for me to enter the key :-//
(Attachment Link)
(Attachment Link)
Here is my MDO4000C.
I am wondering if the firmware needs updating?
-
for DPO/MSO/MDO4000 (no letter at the end) the "only" way is to program and then transfer license from an app module
It takes a while and needs many power on/offs but that's the only way :(
-
for DPO/MSO/MDO4000 (no letter at the end) the "only" way is to program and then transfer license from an app module
It takes a while and needs many power on/offs but that's the only way :(
Quck hack using a broken phone + 24c02, job done in 2 hours :-+
Thanks.
-
an MDO4024C-6 just arrived... and luckily, the week-end just starts... >:D
thus an MDO4024C with factory SA6, DPO4BND and AFG options.
but SCPI shell on port 4000 doesn't seem to work on MDO4000C :(
Anyone experienced with the 'C' models ? This one is running FW 1.10 (2018), any idea whether it's a good idea to upgrade or not ?
Strange that netcat isn't working... console log reports daemon started on port 4000...?
Anyway... web console seems to work, additional menu's are there...
here some console file: (start of...)
errSetConsoleLogState() logging to /usr/local/nv/consoleLog50.txt
cfgInit
versionBuildFWVersionString(): TimestampString: 30-Oct-15 11:43
VersionFIRMWAREVERSIONversion: v1.02
Major ver num: 1 Minor ver num: 2
sysInit
execInit
hwInit
vertReprogramFeProc(): Platform Route66c fw 1003 filefw 1003
Front Panel Firmware update not needed
Current firmware 1003 >= 1003
Main Board HW ID: 0x07
AFE Board SW ID: 0x02
cfgGetRfHwInfo(): Contents of CfgRfHwInfo:
rfHwPresent = 1; rfFrontEndType = 4; rfAfeRev = 2
rfBw = 6e+09; rfLowBandStartFreq = 9000; rfAttenResolution = 1.000000
rfAcqMemSize = 2e+09
Main Board SW ID: 0x01
HFD144[0] ID_REG = 0x00001440
HFD144[1] ID_REG = 0x00001440
HFD144[2] ID_REG = 0x00001440
HFD144[3] ID_REG = 0x00001440
fanControlInit
Init ADT7476.
mitlInit
afgInit
diagInit
diagRunEarlyPostDiags
ialInit
ialInit(): AFE id 0x2, rev 0x2, bI 8
calInit
Factory Checksum:
Demux initialization
Main Board HW Rev: 0x02
-
I think 1.10 is the latest firmware.
Check the
Utility -> I/O -> Socket Server
settings.
[attachimg=1]
[attachimg=2]
-
klaus11, for -C models the max possible bandwidth depends on actual board types installed. Try getting device log (as in andyturk's link) to see main/AFE models. There are both MB and AFE limits:
afeid bw
1, 2 200M
3 1G
4 200M
5 350M
other 200M
mbid, bw
1, 5 1G-1G
2, 6 200M-500M
7 200M-1G
AFE's always report a SW ID, whereas the main board reports a HW ID... so I'm not (yet) 100% convinced the AFE's can't be software-upgraded...
-
klaus11, for -C models the max possible bandwidth depends on actual board types installed. Try getting device log (as in andyturk's link) to see main/AFE models. There are both MB and AFE limits:
afeid bw
1, 2 200M
3 1G
4 200M
5 350M
other 200M
mbid, bw
1, 5 1G-1G
2, 6 200M-500M
7 200M-1G
AFE's always report a SW ID, whereas the main board reports a HW ID... so I'm not (yet) 100% convinced the AFE's can't be software-upgraded...
were you able to upgrade the BW to 350 or 500 or maybe 1G?
-
klaus11, for -C models the max possible bandwidth depends on actual board types installed. Try getting device log (as in andyturk's link) to see main/AFE models. There are both MB and AFE limits:
afeid bw
1, 2 200M
3 1G
4 200M
5 350M
other 200M
mbid, bw
1, 5 1G-1G
2, 6 200M-500M
7 200M-1G
AFE's always report a SW ID, whereas the main board reports a HW ID... so I'm not (yet) 100% convinced the AFE's can't be software-upgraded...
were you able to upgrade the BW to 350 or 500 or maybe 1G?
Not yet, but planned for this week, will post the result(s) in the coming days...
-
So...
apart from the python key.py glitch (which had been mentioned before by TV84 !! |O ), i.e. line 158 'if' must be replaced by 'elif', got the same results as others...
Scope is unhappy about its calibration, and SPC fails.
But 1 GHz sine wave displays fine, curiously no attenuation (500mV ampl. on the siggen)... But measurements complain with a 'low resolution' warning on the rise time and frequency measurements from time to time...
-
So...
apart from the python key.py glitch (which had been mentioned before by TV84 !! |O ), i.e. line 158 'if' must be replaced by 'elif', got the same results as others...
Scope is unhappy about its calibration, and SPC fails.
But 1 GHz sine wave displays fine, curiously no attenuation (500mV ampl. on the siggen)... But measurements complain with a 'low resolution' warning on the rise time and frequency measurements from time to time...
but at least it shows the 200MHz scope does in fact have the hardware for 1GHz BW, right?
it's probably just because of the required re- calibration that tektronix says the scope needs to be send to them for upgrade
-
but at least it shows the 200MHz scope does in fact have the hardware for 1GHz BW, right?
it's probably just because of the required re- calibration that tektronix says the scope needs to be send to them for upgrade
well... the question will be: is only Tek able to do whatever is needed, or will a 'standard' calibration by an affiliated lab be OK as well...
Sending the scope in to Tek in the current state will only lead to a factory reset (at best)... :-\
And as for the h/w, yes, it seems like it has the 1 GHz stuff, otherwise, I couldn't explain how it would be able to display that signal... although the fact that there's no attenuation (or some sort of compensation ??) is rather suspicious... (or maybe due to the lack of calibration ??? but still... more amplitude than the actual signal, i.e. 500 mV 1 GHz sine wave...?)
-
but at least it shows the 200MHz scope does in fact have the hardware for 1GHz BW, right?
it's probably just because of the required re- calibration that tektronix says the scope needs to be send to them for upgrade
well... the question will be: is only Tek able to do whatever is needed, or will a 'standard' calibration by an affiliated lab be OK as well...
Sending the scope in to Tek in the current state will only lead to a factory reset (at best)... :-\
And as for the h/w, yes, it seems like it has the 1 GHz stuff, otherwise, I couldn't explain how it would be able to display that signal... although the fact that there's no attenuation (or some sort of compensation ??) is rather suspicious... (or maybe due to the lack of calibration ??? but still... more amplitude than the actual signal, i.e. 500 mV 1 GHz sine wave...?)
yes that 500mVpp RF staying unchanged over 1GHz is strange or too good to be true. Are you sure about your SG output? Does it really stay constant from say 1MHz to 1GHz?
how about trigger stability and sensitivity? is it OK at 1GHz?
some people had reported that if the device is warmed up for long time it might pass the SPC or I remember someone even changed room and his MDO passed SPC. It was not MDO4000 I think but these are things that I remember I have seen on this forum
-
Yep... pretty sure on the signal quality and stability (got a calibrated 4GHz scope at hand), the SG is under cal as well.
Trigger stability is excellent, all channels. Sensitivity not tested yet.
From what I see, what is needed is a 'Factory adjustment'... very little hope to have this done outside Tek, I'd even bet that there's no step by step documentation of this procedure, as this is most probably done in an automated way at Tek :(
I think the only way to have the scope stop complaining (without Tek), would be to know where these adjustment values are stored (by analyzing the firmware), copy those from a working 1 GHz model, and set the required 'flags' to mark that it has been adjusted. Probability of success this way is close to (if not below) zero.
-
Yep... pretty sure on the signal quality and stability (got a calibrated 4GHz scope at hand), the SG is under cal as well.
Trigger stability is excellent, all channels. Sensitivity not tested yet.
From what I see, what is needed is a 'Factory adjustment'... very little hope to have this done outside Tek, I'd even bet that there's no step by step documentation of this procedure, as this is most probably done in an automated way at Tek :(
I think the only way to have the scope stop complaining (without Tek), would be to know where these adjustment values are stored (by analyzing the firmware), copy those from a working 1 GHz model, and set the required 'flags' to mark that it has been adjusted. Probability of success this way is close to (if not below) zero.
did you get it to work properly at 1GHz?
or did you go back to 200MHz?
-
I'm wondering if at the very least a 200MHz can be liberated to 500MHz without having a recalibration/factory adjustment. Certainly the MDO3000 could do that.
On my 4054C-SA6, I can run the SPC at 500MHz but when I liberate it to 1GHz, the channel offsets & gains set by SPC don't seem to carry across, although they're not that bad as they stand.
I did attempt a full calibration, but there's a test very near the end of the 78 or so steps that I could never get to pass, although as far as I could tell from the very terse on screen instructions, I was doing the right thing.
It would help a great deal if we could get hold of the detailed cal instructions.
-
I'm wondering if at the very least a 200MHz can be liberated to 500MHz without having a recalibration/factory adjustment. Certainly the MDO3000 could do that.
strange that you talk about it... was planning to do that this afternoon... ;-) (200->350 and 200->500)
Regarding the cal, I guess that unless you get your hands on some 'insider' info, you're unlikely to be successful.
The 'automated adjustment procedure' the scope is asking for, is the automated factory calibration, which might be slightly different.
Is there any logs where the results of the calibration are visible ??
I found functions for setting the verbosity of the Cal functions in the firmware, but no idea on how to change that 'from the outside' :-//
For one of the functions I came across, one of the error messages was "Invalid shadow registers. Talk to Peter"
So maybe you should talk to Peter... :-DD
BTW, did you try to do the cal in Mfg mode ? or in Dev mode ?
-
did you get it to work properly at 1GHz?
or did you go back to 200MHz?
Nope, experiments planned later today... hopefully getting back the cal data for 200MHz. But I'm relatively confident, the firmware shows that there are different (calibration) data sets for the different BW's (0, 1, 2, 3 indexes into some table).
So the mentioned problem is likely to happen for all non-native BW settings. Will report on that.
-
did you get it to work properly at 1GHz?
or did you go back to 200MHz?
Nope, experiments planned later today... hopefully getting back the cal data for 200MHz. But I'm relatively confident, the firmware shows that there are different (calibration) data sets for the different BW's (0, 1, 2, 3 indexes into some table).
So the mentioned problem is likely to happen for all non-native BW settings. Will report on that.
darkstar49,
did you try other BW like 500MHz for example instead of 1GHz?
look what I just found on ebay (see the pic) :o :o
it says model (from resistors) is 1 :o
so perhaps some resistor IDs must be moved around in order for the BW upgrade to work!
i dont know how that seller got this image, he must have enabled an engineering debug mode
I dont think the instrument by default would give you this information,
EDIT: changing those ID resistors (wherever they are) is probably what Tek does when you send it for BW upgrade. Plus of course calibration
I dont think they replace the board.
-
did you get it to work properly at 1GHz?
or did you go back to 200MHz?
Nope, experiments planned later today... hopefully getting back the cal data for 200MHz. But I'm relatively confident, the firmware shows that there are different (calibration) data sets for the different BW's (0, 1, 2, 3 indexes into some table).
So the mentioned problem is likely to happen for all non-native BW settings. Will report on that.
darkstar49,
did you try other BW like 500MHz for example instead of 1GHz?
look what I just found on ebay (see the pic) :o :o
it says model (from resistors) is 1 :o
so perhaps some resistor IDs must be moved around in order for the BW upgrade to work!
i dont know how that seller got this image, he must have enabled an engineering debug mode
I dont think the instrument by default would give you this information,
EDIT: changing those ID resistors (wherever they are) is probably what Tek does when you send it for BW upgrade. Plus of course calibration
I dont think they replace the board.
FWIW this is mine, a 1GHz liberated MDO4054C-SA6
You get the image in either Manufacturing Mode (:MFG:MOD 1) or Development Mode (:DEV:MOD 1). For Manufacturing mode there is a different password see post #71 https://www.eevblog.com/forum/testgear/mdo3000-hacking/msg769821/#msg769821 (https://www.eevblog.com/forum/testgear/mdo3000-hacking/msg769821/#msg769821)
FWIW, I've noticed that any residual channel offsets disappear when the channel is bandwidth limited to 250 or 20MHz.
[attachimg=1].
-
FWIW this is mine, a 1GHz liberated MDO4054C-SA6
You get the image in either Manufacturing Mode (:MFG:MOD 1) or Development Mode (:DEV:MOD 1). For Manufacturing mode there is a different password see post #71 https://www.eevblog.com/forum/testgear/mdo3000-hacking/msg769821/#msg769821 (https://www.eevblog.com/forum/testgear/mdo3000-hacking/msg769821/#msg769821)
FWIW, I've noticed that any residual channel offsets disappear when the channel is bandwidth limited to 250 or 20MHz.
(Attachment Link) .
ummm...this one also shows model number based on resistors is 1 but says 500MHz. Now I am lost...
but still it shows there have to be some ID resistors on the board to play with
I dont have a MDO4000, so are there any high res pictures of top and bottom of the main board somewhere? or can somebody provide some pictures?
-
Howardlong,
in post #9 of this thread, an MDO4034B was upgraded to 1GHz and it seems to be working fine with no warning message or DC offset
have you contacted that forum member? B versions did not even have an official BW upgrade like C versions do
-
Howardlong,
in post #9 of this thread, an MDO4034B was upgraded to 1GHz and it seems to be working fine with no warning message or DC offset
have you contacted that forum member? B versions did not even have an official BW upgrade like C versions do
Yes, I did: this appears to be a difference between B and C versions as far as we could tell.
-
FWIW this is mine, a 1GHz liberated MDO4054C-SA6
You get the image in either Manufacturing Mode (:MFG:MOD 1) or Development Mode (:DEV:MOD 1). For Manufacturing mode there is a different password see post #71 https://www.eevblog.com/forum/testgear/mdo3000-hacking/msg769821/#msg769821 (https://www.eevblog.com/forum/testgear/mdo3000-hacking/msg769821/#msg769821)
FWIW, I've noticed that any residual channel offsets disappear when the channel is bandwidth limited to 250 or 20MHz.
(Attachment Link) .
ummm...this one also shows model number based on resistors is 1 but says 500MHz. Now I am lost...
but still it shows there have to be some ID resistors on the board to play with
I dont have a MDO4000, so are there any high res pictures of top and bottom of the main board somewhere? or can somebody provide some pictures?
FWIW, the serial number of that scope is very close to mine, you'll have enough fingers for the difference.
-
You'll notice that if I switch my scope back to pre-liberation 500MHz state, the sample rate is 2.5GHz. Presumably that's because mine has a 6GHz rather than 3GHz SA?
[attachimg=1]
-
Experiments confirm what it seemed... every bandwidth has its own table and status.
I tried 2 -> 3, 2 -> 5 and 2 -> 10, same story, same messages.
Back to 200MHz, and it's happy again.
This confirms what the firmware says... 4 calibration/compensation tables. What I don't know is whether that 'factory adjustment' would leave existing tables unaffected...
It would be really interesting to have the NVRAM of an MDO4104C, the tables are definitely instrument-specific, but if one manages to find out the offsets and length of these tables (as well as a way to read & write from/to NVRAM), I'm pretty sure it could help a lot.
-
i dont have a MDO4000/B/C but just out of curiosity, what can happen if you send the scope for calibration after unlocking the BW and options? either to Tek or to another reputable cal lab? it seems everybody is only stuck at this
point step.
also what if you dont upgrade the BW and just unlock the options and send it for routine calibration? has anybody tried that?
if I understood correctly in these scopes the options are unlocked by license keys, so unlike for example keysight 3000 which requires patching the FW, what would be the problem of sending it for calibration?
-
i dont have a MDO4000/B/C but just out of curiosity, what can happen if you send the scope for calibration after unlocking the BW and options? either to Tek or to another reputable cal lab? it seems everybody is only stuck at this point step.
also what if you dont upgrade the BW and just unlock the options and send it for routine calibration? has anybody tried that?
if I understood correctly in these scopes the options are unlocked by license keys, so unlike for example keysight 3000 which requires patching the FW, what would be the problem of sending it for calibration?
The problem is this: the missing data is not linked to a calibration, but to what Tek calls an 'automated factory adjustment', which is the 'calibration' the instrument goes through once in its life, just before leaving the production lines.
This procedure is only known to Tek. LeCroy has exactly the same, named CalSoft, and no one else on Earth is able to do that 'factory adjustment'.
Those adjustment constants and curves are BW-specific, so there are 4 tables on the MDO4000C (200, 350, 500MHz, and 1GHz), but only the table for the 'original' BW is populated. Some models indeed require a h/w upgrade, but even those that don't, need the corresponding table to be filled to work properly (or at least to not display these error messages).
As for the options, while Tek may not have a view on all the options that are available as option modules, BW upgrades systematically require servicing at Tek (for the MDO4000C), so they will reset the scope to the bandwidth that is in their records, period. No doubt about this !
And it's exactly the same for BW upgrades that are 'user installable', like on the MDO3K. Those are sold per device, the key is generated on demand, so Tek knows exactly what BW has been paid for. This happens on a regular basis, and I know people who faced this, believing Tek wouldn't know... they got their '500MHz-pimped' MDO3014 back, calibrated... but at 100Mhz. :-DD
-
The problem is this: the missing data is not linked to a calibration, but to what Tek calls an 'automated factory adjustment', which is the 'calibration' the instrument goes through once in its life, just before leaving the production lines.
This procedure is only known to Tek. LeCroy has exactly the same, named CalSoft, and no one else on Earth is able to do that 'factory adjustment'.
Those adjustment constants and curves are BW-specific, so there are 4 tables on the MDO4000C (200, 350, 500MHz, and 1GHz), but only the table for the 'original' BW is populated. Some models indeed require a h/w upgrade, but even those that don't, need the corresponding table to be filled to work properly (or at least to not display these error messages).
So what is different when you just send the unit for calibration to a Cal lab, either Tek or others? I mean, let's say you send it in for traceable calibration, and it will come back calibrated, what is the difference with that 'automated factory adjustment'? as far as I know calibration of all these modern scopes is automated anyways.
As for the options, while Tek may not have a view on all the options that are available as option modules, BW upgrades systematically require servicing at Tek (for the MDO4000C), so they will reset the scope to the bandwidth that is in their records, period. No doubt about this !
Ah, ok, that makes sense. Good that at least they are not sending their lawyers instead of the scope :-DD
And it's exactly the same for BW upgrades that are 'user installable', like on the MDO3K. Those are sold per device, the key is generated on demand, so Tek knows exactly what BW has been paid for. This happens on a regular basis, and I know people who faced this, believing Tek wouldn't know... they got their '500MHz-pimped' MDO3014 back, calibrated... but at 100Mhz. :-DD
Oh, that's good to know :(
Again it's good that at least they send the scope back and not call the cops :-DD
but still I am not sure about sending the scope to other calibration labs. I think there are plenty of them that have the ability to calibrate these MDO3K or MDO4K, no?
-
but still I am not sure about sending the scope to other calibration labs. I think there are plenty of them that have the ability to calibrate these MDO3K or MDO4K, no?
I contacted two labs (i.e. not related to Tek), and both answered negatively... I'm relatively sure for Tek, but 100% sure for LeCroy, their CalSoft calibration bench (the one that generates the files in the hidden d:\calibration directory) is NOT available to external labs... I'm not sure how the procedure looks like for external labs, but it's NOT the factory calibration. And as from the (few) information I got from Tek and these 2 labs, it's exactly the same for Tek.
Now, I don't say it's impossible, maybe it's just a matter of performing a (normal) calibration with the manufacturing mode enabled (although that sounds pretty trivial). Or maybe these labs (and myself) were wrong, I don't know...
As for the lawyers/cops... don't forget (in most countries at least, no clue for the US) that it's their problem to prove that you did the cheating (i.e. that it wasn't hacked before you bought it), which is far from granted... secondly, when you buy a scope from Ebay (as an example), you're NOT in a contractual relation with Tek, etc... so while Tek is not known to have much humor when it comes to their licences, the risk is fairly low for an 'amateur' (/hobbyist) to get in trouble...
-
does it make any difference if one uses e.g. BW2T54 instead of using 500MHz for bandwidth upgrade? I mean for MDO4000C.
I dont have the scope but since the upgrade has not worked as expected, i thought maybe using the other option might work differently
in the datasheet the official upgrade option that must be ordered is MDO4BW2T54-SA but I see there is no BW2T54-SA in the option.py script
-
have anyone ever tried on the tek4 series, news about it?
-
does it make any difference if one uses e.g. BW2T54 instead of using 500MHz for bandwidth upgrade? I mean for MDO4000C.
On the MDO4054C-SA6 I have, liberating it to 1GHz BW with an option key introduces some relatively minor vertical offsets, and the red banner "WARNiNG: This oscilloscope is not compensated". Running an SPC fails. Reverting back to 500MHz, those minor offsets disappear again, as does the red banner warning.
When I add or remove options, I still use 500MHz even though it's a 500MHz factory unit. When opening up to 1GHz, I include both 500MHz and BW5T10 options.
On the other side of the coin, on the MDO3014, liberating it to 500MHz with an option key seems to be seamless.
Of course, this is purely anecdotal, although my understanding is that the MDO3000 & MDO4000C share some similarities.
-
FWIW, I discovered over the weekend that at least some bandwidth upgrades on the MDO4000C are now discontinued.
e.g., MDO4BW5T104-SA 500MHz to 1GHz w/SA.
-
Here's a .vbs I use to remove the red banner.
Set your target IP address appropriately.
Sometimes I have to run it a couple of times if the toggle settings aren't in the expected state: it does nothing more than automatically push front panel buttons and turn knobs programmatically.
set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.run("telnet.exe 192.168.50.139 4000")
WScript.Sleep 500
WshShell.SendKeys":PASSW TRESPASS"
WshShell.SendKeys("{Enter}")
WScript.Sleep 50
WshShell.SendKeys":DEV:MOD 1"
WshShell.SendKeys("{Enter}")
WScript.Sleep 50
WshShell.SendKeys"FPA:PRESS MENU0"
WshShell.SendKeys("{Enter}")
WScript.Sleep 50
WshShell.SendKeys"FPA:PRESS MENU0"
WshShell.SendKeys("{Enter}")
WScript.Sleep 50
WshShell.SendKeys"FPA:PRESS MENU0"
WshShell.SendKeys("{Enter}")
WScript.Sleep 50
WshShell.SendKeys"FPA:PRESS MENU0"
WshShell.SendKeys("{Enter}")
WScript.Sleep 50
WshShell.SendKeys"FPA:PRESS MENU0"
WshShell.SendKeys("{Enter}")
WScript.Sleep 50
WshShell.SendKeys"FPA:PRESS MENU0"
WshShell.SendKeys("{Enter}")
WScript.Sleep 250
WshShell.SendKeys"FPA:PRESS UTIL"
WshShell.SendKeys("{Enter}")
WScript.Sleep 250
WshShell.SendKeys"FPA:PRESS BMENU1"
WshShell.SendKeys("{Enter}")
WScript.Sleep 50
WshShell.SendKeys"FPA:TURN GPKNOB1,10"
WshShell.SendKeys("{Enter}")
WScript.Sleep 50
WshShell.SendKeys"FPA:TURN GPKNOB1,-5"
WshShell.SendKeys("{Enter}")
WScript.Sleep 50
WshShell.SendKeys"FPA:PRESS BMENU7"
WshShell.SendKeys("{Enter}")
WScript.Sleep 50
WshShell.SendKeys"FPA:PRESS RMENU1"
WshShell.SendKeys("{Enter}")
WScript.Sleep 250
WshShell.SendKeys":DEV:MOD 0"
WshShell.SendKeys("{Enter}")
WScript.Sleep 250
WshShell.SendKeys":PASSW INTEKRITY"
WshShell.SendKeys("{Enter}")
WScript.Sleep 50
WshShell.SendKeys":MFG:MOD 1"
WshShell.SendKeys("{Enter}")
WScript.Sleep 500
WshShell.SendKeys":MFG:MOD 0"
WshShell.SendKeys("{Enter}")
WScript.Sleep 500
WshShell.SendKeys(chr(29))
WshShell.SendKeys"qui"
WshShell.SendKeys("{Enter}")
-
FWIW, I discovered over the weekend that at least some bandwidth upgrades on the MDO4000C are now discontinued.
e.g., MDO4BW5T104-SA 500MHz to 1GHz w/SA.
What's the difference between discontinued, and selling these options at prices higher then an MDO4104C-SA6 at many brokers ? :wtf:
(might not be totally true in your case, but definitely for my MDO4024C-SA6)
-
I have a MDO4034C which I would like to upgrade to 500MHz.
But in the python scripts there is one BW3T5 option with two different masks and one is for 300MHz to 500MHz
and the other is for 350MHz to 500MHz. Obviously for MDO4000C it has to be 350MHz to 500MHz
but both of them are named BW3T5. If i generate the key and then validate it, it says 300 to 500.
So I am wondering which mask (0x40000 or 0x20000) works for 350M to 500M on MDO4000C?
my other question is that is this going to cause the same RED warning message about calibration that Hwardlong experienced with BW5T10?
-
I tried both masks and although after reboot the scope reports MDO4BW3T54 is installed but the Bandwidth still shows 350MHz and also measures about 420MHz as it was before the install :( :( :-//
this is how I did it
python gen.py MDO4034C C0xxxxxx 350MHz BW3T5 MSO AFG DVM
then in the option.py once I set the mask to 0x20000 and the next time I set it to 0x40000
I cannot upgrade to 500MHz even though the option gets installed :-//
-
I have a MDO4054C and I want to install some applications.
Can't open 0bin.net. Would anyone like to paste the full code file here?