-
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...
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.
-
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:
Code: [Select]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:
Code: [Select]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:
Code: [Select]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 !!
), 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 !! ), 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...
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)
it says model (from resistors) is 1
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)
it says model (from resistors) is 1
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
FWIW, I've noticed that any residual channel offsets disappear when the channel is bandwidth limited to 250 or 20MHz..
-
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
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
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?
-
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
pointstep.
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?