Author Topic: MDO3000 hacking  (Read 107522 times)

0 Members and 4 Guests are viewing this topic.

Offline G33KatWork

  • Contributor
  • Posts: 16
Re: MDO3000 hacking
« Reply #75 on: October 15, 2015, 07:39:21 pm »
The application modules are modules to be inserted into the scope. As long as it is present, the feature of the module is activated. You can remove the module and use it in another scope. You can also copy the license to a scope and later back to a module.
The options are bound to *one specific* scope. As soon as you activated it, you can't transfer it to another scope.

The keygen just activates everything (except the 1GHz Bandwidth-Option - you need another frontend for that). You don't need to care.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5313
  • Country: gb
Re: MDO3000 hacking
« Reply #76 on: October 15, 2015, 09:40:16 pm »
To add to what has already been stated, if you choose to use the script

Code: [Select]
python gen.py MDO3014 C123456 500MHz AERO AFG AUDIO AUTOMAX COMP DVM EMBD ENET FLEX LMT MSO PWR SA TRIG USB VID AUTO SEC

replacing C123456 with your serial number, that is all you need. Note that some of these options like ENET don't add anything of value.

It's a bit confusing, but there is no need for any physical modules, Tek have two concurrent licensing models, one with the physical modules (that can be moved between scopes) and one without. The script above requires no physical modules.

The probes are still limited to 250MHz, but they are pretty good probes, only 3.9pF loading. There is some information on these probes here https://www.eevblog.com/forum/testgear/tektronix-probes-tpp0250-and-tpp0500b-whats-the-difference-teardown-time

Information on the LA probe for MSO use is here https://www.eevblog.com/forum/testgear/mdo3000-hacking/msg765377/#msg765377.

Under Windows, use the 2.7 Python as the latest 3.x fell over with the script. In addition there is a pycrypto toolkit required.
« Last Edit: October 15, 2015, 09:43:15 pm by Howardlong »
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5313
  • Country: gb
Re: MDO3000 hacking (How to crash your scope)
« Reply #77 on: October 19, 2015, 11:30:24 pm »
I was getting a tad frustrated today when I had the scope crash on me a couple of times, at the same place. I've narrowed it down to the following steps, and they're completely repeatable.

o Boot up
o Default Setup
o Trigger Menu
o Select trigger Source D0 digital channel for trigger (digital channels do not need to be showing)
o Select trigger Type
o Turn Multipurpose A counter clockwise down the list

Crashed. Sometimes mine crashes at Pulse Width, sometimes at Timeout trigger type. Needs a cold boot.

Firmware is v1.20, dated 13 May 2015, I believe this is the latest firmware.

Anyone else care to confirm whether or not they're seeing this feature?

Edit: there are entries in the Error Log (Utility, Self Test, Error Log) for each of these occasions.
« Last Edit: October 19, 2015, 11:33:01 pm by Howardlong »
 

Offline TopLoser

  • Supporter
  • ****
  • Posts: 1922
  • Country: fr
Re: MDO3000 hacking
« Reply #78 on: October 20, 2015, 12:57:54 pm »
I have an MDO3000 series scope that crashes if I repeat those steps, same firmware 1.20
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5313
  • Country: gb
Re: MDO3000 hacking
« Reply #79 on: October 21, 2015, 07:27:30 am »
The only way around this I could find is to temporarily set the source to an analogue channel first before selecting the appropriate trigger type.

Typically, the use case for me has been SPI, using the /CS falling edge on a digital channel as a trigger first then using a bus trigger to select specific SPI frames: hardly an uncommon scenario.

I guess I'll just have to remember to switch the trigger source for now, it's mighty irritating though when the scope just hangs in the middle of things and you have to spend five minutes rebooting it, and setting it up all over again: not good for your workflow. A bit surprised to see this in a Tek scope to be honest, maybe that Danaher Business System is a bit to much about processing inefficiencies out and lean operating, but not enough about common sense and taking care. But to be fair, these days understanding and maintaining intangibles like reputation that won't fit on a spreadsheet is a difficult concept to your average MBA.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5313
  • Country: gb
Re: MDO3000 hacking
« Reply #80 on: October 31, 2015, 11:09:44 am »
Here's a vid showing the MDO3000 crash/hang I found in Firmware 1.20.

 

Offline startronic

  • Contributor
  • Posts: 16
  • Country: br
Re: MDO3000 hacking
« Reply #81 on: February 23, 2016, 01:57:24 am »
So... if one buys the TEKTRONIX  MDO3014  OSCILLOSCOPE, 4CH, 100MHZ, SPEC ANALYSER and uses the keys than he/she as a full option scope with the 3Ghz spectrum analyzer and all digital protocol analyzers including 300/400/500Mhz bandwidth ?

I repeat: yes.

Read the MDO3000-related threads here on eevblog. Take care for the attachments in these threads

Hello friend you could help me with my MDO3014, do not know how to use the python script,
 

Offline startronic

  • Contributor
  • Posts: 16
  • Country: br
Re: MDO3000 hacking
« Reply #82 on: February 23, 2016, 02:29:09 am »
You need to have Python installed on your PC.

Skip the validate.py step, it's unnecessary.

On your PC, use gen.py with, as arguments, your scope model and serial number along with the wanted bandwidth and options.

python gen.py <model> <serial> <bandwidth> <options>
Hello friend you could help me with my MDO3014, do not know how to use the python script,
 

Offline luisprata

  • Regular Contributor
  • *
  • Posts: 58
  • Country: br
Re: MDO3000 hacking
« Reply #83 on: February 27, 2016, 09:50:28 am »
startronic,

I'll help you. I`ve bought a MDO3014 and it didn't arrived yet. But I think I could help you. I`ll send you a pvt msg.

PS: I`m brazilian too. Valeu.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5313
  • Country: gb
Re: MDO3000 hacking
« Reply #84 on: February 27, 2016, 11:32:02 am »
You need Python 2.7 installed and the python.exe in your path. (Unless you explicitly state where it is on the command line)
 

Offline startronic

  • Contributor
  • Posts: 16
  • Country: br
Re: MDO3000 hacking
« Reply #85 on: February 27, 2016, 11:51:49 am »
startronic,

I'll help you. I`ve bought a MDO3014 and it didn't arrived yet. But I think I could help you. I`ll send you a pvt msg.

PS: I`m brazilian too. Valeu.



Thank you, my already arrived is a beautiful machine, I have a MSOX3024T, more like a lot of the TEKETRONIX machines, have not compared the two most superficially and are equivalent.
The script could already solve, and have a good friend here in Brazil Forum.
Hugs, thank you
Muito
 

Offline startronic

  • Contributor
  • Posts: 16
  • Country: br
Re: MDO3000 hacking
« Reply #86 on: February 27, 2016, 11:55:22 am »
You need Python 2.7 installed and the python.exe in your path. (Unless you explicitly state where it is on the command line)

Thank you friend, for the tip, already managed to work, my mdo is already full, thanks
 

Offline kappa_am

  • Newbie
  • Posts: 1
  • Country: ca
Re: MDO3000 hacking
« Reply #87 on: April 23, 2016, 12:33:53 pm »
Hi all,
I have bought an MDO 3014 with P6316 probe. These cost me a fortune still all needed functions are not available. Not only I am out of money, also, I feel assaulted. I need MSO feature. could you please help me to unlock this function.

Your help is appreciated.
« Last Edit: April 23, 2016, 12:35:29 pm by kappa_am »
A good world needs knowledge, kindness and courage.
 

Offline natman69

  • Regular Contributor
  • *
  • Posts: 61
  • Country: it
Re: MDO3000 hacking
« Reply #88 on: May 11, 2016, 07:51:30 pm »
An used MDO3012 is on my way…  :popcorn:
I've read the messages of Howardlong regarding the crash/hang of his scope.
A new firmware (1.22) was recently published by Tektronix and maybe it fixes this problem even if it's not explictly listed in the fixed bug list.

I'll receive the MDO next week and I'll test the new firmware asap…  :)

http://www.tek.com/oscilloscope/mdo3012-software-4

v1.22 3/30/2016
Enhancement:
- Added control for readout transparency

Defects Fixed:
- Fixed an issue with CAN bus and zoom with large numbers of packets
resulting in slow performance for pan across record
- Fix an issue where DVM DC Autorange would not settle properly
- Fixed "flicker" between RF manual and peak markers when they
overlap
- Fixed an issue with manual markers not displaying in the correct
location on Frequeny Domain Reference waveforms
- Fixed an issue with Peak markers not working if Stop Frequency was
greater than maximum frequency range
- Fixed an issue with recalling Frequeny Domain Reference waveforms
not drawing in the correct position
- Fixed an issue with channel 4 waveforms saving to Reference when
saving after a single sequence acquisition
- Fixed issue with frequency domain math waveforms being improperly
converted to dBm during save to .csv files
- Fixed issue with Save All with multiple frequency domain traces
causing overwritten data values
- Improved save operation where frequency domain waveforms are
previewed
- Fixed a case where frequency domain units did not match the saved
data by forcing all RF trace data to be saved as dBm
- Fixed an issue where RF saved setups would not properly recall
vertical units
- Fixed an issue with saved References not allowing very small
vertical scales
- Fixed a case where completing an acquisition with Roll Mode on
Long Records could result in the first portion of the waveform
being overwritten
- Fixed an issue with RMS measurement with vertical position moved
away from center screen
- Fixed an issue where measurements would not complete after undoing
an autoset
- Fixed an issue with NPULSECOUNT measurement type not counting
correctly
- Fixed an issue with immediate measurement on math when stopped
- Fixed a case where math units for absolute value were being cleared
- Fixed an issue with attachments for ePrint
- Fixed an issue with AC Coupled Trigger losing trigger with
vertical position changes
- Fixed an issue with a legacy command 'HARDCOPY STARt'
- Fixed an issue with where pan range was locked in zoom mode
- Fixed an issue where an Application Error could appear with Roll
Mode, 5M records, and HiRes acquisition modes. Under these
conditions, acquisition trigger mode is forced to Normal
- Fixed an issue with RF Pre-Amp always downloading cal constants
on attach
- Fixed an issue where RF Pre-Amp is in the wrong state on re-attach
- Fixed incorrect value displayed for digital sample rate
- Fixed an issue where Signal Path Compensation could fail if
run after Diagnostics. An instrument reboot is recommended after
running Diagnostics
- Improved edge trigger alignment for MagniVu on digital channels

Known Issues:
- Previewed spectrum data may save previewed header values instead of
acquired data. This can result in incorrect save file data.
To workaround: save frequency domain waveforms prior to
making changes to horizontal or vertical parameters
 
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5313
  • Country: gb
Re: MDO3000 hacking
« Reply #89 on: May 11, 2016, 09:00:22 pm »
I just did the firmware update, the crash still occurs. Firmware options are persisted.
 

Offline natman69

  • Regular Contributor
  • *
  • Posts: 61
  • Country: it
Re: MDO3000 hacking
« Reply #90 on: May 14, 2016, 03:31:44 pm »
My used MDO3012 has arrived :-+

It was loaded with 1.10 firmware. I tested it to see if the bug was present also in this early firmware version and it freezed... |O
So this bug was present from the beginning and it wasn't never fixed by Tektronix (maybe it was never submitted to the support desk?)
 

Offline G33KatWork

  • Contributor
  • Posts: 16
Re: MDO3000 hacking
« Reply #91 on: May 15, 2016, 04:37:10 am »
I can't reproduce the bug at all.

I did it exactly like in the video and it just doesn't crash. Also variants with different channels or bus decoders enabled or disabled didn't trigger a lockup.
Same on Version 1.22 and 1.20.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5313
  • Country: gb
Re: MDO3000 hacking
« Reply #92 on: May 15, 2016, 05:14:38 am »
I can't reproduce the bug at all.

I did it exactly like in the video and it just doesn't crash. Also variants with different channels or bus decoders enabled or disabled didn't trigger a lockup.
Same on Version 1.22 and 1.20.

It is only when changing the trigger on a digital channel, can you confirm it was a digital channel you were changing the trigger on?
 

Offline G33KatWork

  • Contributor
  • Posts: 16
Re: MDO3000 hacking
« Reply #93 on: May 15, 2016, 05:19:15 am »
It is only when changing the trigger on a digital channel, can you confirm it was a digital channel you were changing the trigger on?

Yes. D0.
I just tried a few other digital channels as trigger sources. Same thing. It does not lock up.

  • Default Setup
  • Trigger Menu
  • Set Source to D0
  • Select type and scroll through the list
  • Scope doesn't crash
  • ???
  • Profit
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5313
  • Country: gb
Re: MDO3000 hacking
« Reply #94 on: May 15, 2016, 09:51:10 am »
Interesting! You've got a special one! You're the first I've heard whose scope isn't afflicted.

Do you know about how old it is? I am wondering if there's been a board change of some sort down the line.
 

Offline G33KatWork

  • Contributor
  • Posts: 16
Re: MDO3000 hacking
« Reply #95 on: May 15, 2016, 09:57:28 am »
It is exactly one year old now.
There is no manufacturing date on the back unfortunately.

It's an MDO3014 with a bandwidth "upgrade" to 500MHz and all the other stuff. It's not much different from other scopes I guess.

I really wanted to get a coredump or some debug messages out of the scope when it crashes and have a look. And now the thing doesn't crash. I'm a bit sad ;)
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5313
  • Country: gb
Re: MDO3000 hacking
« Reply #96 on: May 15, 2016, 11:11:05 am »
Perhaps my work patten is unique, but the sequence seems a reasonable thing to do.

I'm sitting there one day debugging an SPI or I2C bus using the digital channels, I'd only just received the scope a day or two earlier. I use the digital channels, and because I don't fully know what I'm looking for yet I use an edge trigger rather than a bus trigger to get started.

Once I delve a little deeper, I realise I need a more selective trigger, and that's when I found the feature. At the time I didn't realise what the sequence of events were, but once it'd crashed half a dozen times over a few days I realised there was a pattern.

Anyway, I don't consider it an edge case, it's a reasonably common scenario as far as I'm concerned.

But it's strange that it now appears to be inconsistent between examples of the same model.

Mine's about six monts old, but like you I don't know what the manufacturing date is or the hardware level.

The entire UI crashes: the waveform stops and I can no longer access the screen via a browser, although the scope's browser homepage still responds. I can reproduce the fault through the browser interface, but if use the "medium" skip arrow when selecting the trigger type, it doesn't crash. It sems that it's the Runt selection that's doing it (whihc makes no sense for a digital channel anyway).
 

Offline es

  • Contributor
  • Posts: 27
  • Country: ca
Re: MDO3000 hacking
« Reply #97 on: May 15, 2016, 02:23:18 pm »
I can reproduce the crash on mine. MDO3014 unlocked with firmware v1.22. It does it even if I stop the scope before changing the trigger Type.

There is an error logged in Utility/Self Test/Error Log:

41: 20 0 320 User Interface ... plus date and time
« Last Edit: May 15, 2016, 02:35:49 pm by es »
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5313
  • Country: gb
Re: MDO3000 hacking
« Reply #98 on: May 24, 2016, 06:12:23 pm »
Some news:

I believe that this crash is caused by the TRIG option...... let's put it this way, I no longer get the crash if I remove the TRIG option.


 

Offline es

  • Contributor
  • Posts: 27
  • Country: ca
Re: MDO3000 hacking
« Reply #99 on: May 24, 2016, 07:28:18 pm »
I believe that this crash is caused by the TRIG option...... let's put it this way, I no longer get the crash if I remove the TRIG option.

Make sense, AUTOMAX, ENET, VID and TRIG are not valid options and should probably be omitted.

Check this: https://forum.tek.com/viewtopic.php?t=138432
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf