Hacking the frequency response to 200Mhz (which changes the model number to SDS1204X-E in the system screen) is completely separate from enabling the AWG/MSO/WiFi functions.
What guide are you following ? There are actually multiple ways of attacking this problem. Here is one such guide:
Hacking The Siglent 1104X-E Oscilloscope – Maker Matrix
I used a different approach described in this thread on eevblog, although it turns out the python script method is easier than what I did:
Siglent SDS1104X-E Hack to 200Mhz， and full options ? - Page 10
Quick cal is nothing to do with doing a full calibration. Have a look in the manual.
It's a feature where for the first 15 minutes or so of on-time the scope will do a periodic "quick calibration" where every couple of minutes it will stop sampling for a fraction of a second and adjust the DC zero calibration then resume sampling. This results in a barely noticeable blink. Once fully warmed up it stops doing this.
The advantage of having quick cal enabled is DC offset at high gain settings will be more accurate when the scope is cold as it will try to compensate for the warm up drift.
The disadvantage is that it momentarily interrupts sampling of your signal when this happens so if you are doing data logging or other type of capture work it can interfere. In that case disable quick cal. If you do a lot of capturing and/or don't care about slight DC offsets at high gains when the scope is cold just turn off quick cal.
And yes the quick cal button always says "on" when you do a full calibration and then reverts to the previous setting. I think this is just a user interface quirk.
Looks to me like you have the gain set way too high while doing the probe compensation, looking for the tiniest bit of curvature on edge of the square wave.
You might actually be causing clipping in the input stages or ADC doing that. (And because it's already a square wave this might not be obvious) You really should have the calibrate signal fully displayed on the screen and not extending above or below it.
One thing to learn about DSO's and 8 bit ones in particular is that there is not much headroom above full screen in the input stages. If the signal is expanded off the top and bottom of the screen chances are the input stage is clipping, so never do that.
With 8 bits there are 256 discrete levels - with a signal that is displayed full screen approximately 200 levels are visible, so you can only "overscan" a full screen signal by about 25% without risking clipping. To demonstrate this put something like a sinewave in, turn up the gain until its at about 2x full screen amplitude, press the run/stop button to stop capture then turn the gain down until it fits on screen again and you'll find it's clipped.
(When you turn the gain down in stop mode it can only scale down the data it has already sampled, rather than actually reducing the input stage gain which is what it would do in run mode)
I didn't have to touch my probe calibration after unlocking 200Mhz.
Yes I was going to comment on the noise, although that's partly because you have the gain too high. Mine sits on a shelf above my desktop PC most of the time and it picks up noise from the PC's LCD screen if the leads are near the screen - enabling the 20Mhz bandwidth limit when you don't need high bandwidth helps a lot here.
Yeah it is pretty noisy, although to be fair its not the only test equipment to have a noisy fan. I only switch it on when I want to use it so it doesn't bother me especially when it's near a noisy PC but I can see why someone working all day in a quiet lab would find it annoying.
Last edited:
Sorry but the notion that the probes need to be upgraded when unlocking 200Mhz mode has been well tested and debunked.The supplied probes are PP510 100MHz , so to make use of the 200MHz hack you've just done you need a christmas present of some 200MHz (min) probes
The PP510 probes while "rated" to 100Mhz work absolutely fine to 200Mhz.
Please have a look at the following post, which demonstrates there is very very little difference between the "100Mhz" PP510 probes and the "200Mhz" PP215 which is provided with the SDS1204X-E:
Siglent SDS1104X-E In-Depth Review - Page 3
It's important to remember 10:1 scope probes work together with the input characteristics (impedance, capacitance etc) of the scope and it's the final bandwidth of the probe and scope combination that matters. Both PP510 and PP215 give a response in 10:1 mode that is -3dB at about 228Mhz, so well in excess of 200Mhz.
In short, for anyone unlocking an SDS1104X-E to 200Mhz - the supplied PP510 probes are absolutely fine to use. Buying an SDS1104X-E and unlocking 200Mhz really is a bargain and there isn't really any downside to it.
Last edited:
Here's what one guy who's explaining the hack says:
By making this tutorial, I am in no way recommending you do any of what follows. This is intended to be for educational purposes only. You could brick your machine. You could void your warranty. You could mess up the scope’s calibration. The included probes may or may not be accurate at frequencies appreciably higher than 100Mhz. Some of this is probably unethical since Siglent sells some of the unlock keys for some of the features we will be exploring below.
So you should be thoughtful before jumping in. Your scope, your risk; it's always easy and no risk for those who don't have to do it to their scope.
Jan
There is only one minor different IIRC - the 100MHz probes are 300V in 10X whereas the 200MHz probes are meant to be 600V. Given the two probes have a open band for the ground clip to connect I'd probably err on the side of caution with the 600V side of things!
The Mrs did say she doesn't understand why I need it.. not yet.. but soon.. also code for "you're spending too much time in the man cave.".
The python script method is actually very safe. No "hacking" is required at all. It's basically just a keygen as someone worked out the algorithm which generates the keys based on the SCOPEID and serial number of the scope.
SCOPEID and serial number can both be retrieved via the built in SCPI interface, (in fact serial number is also available on the screen in the utility menu) those are then fed into the python script which spits out all the keys to activate various features.
These are then activated by sending the keys with the right command via SCPI again. For the AWG/WiFi/MSO codes the method of entering the code is exactly the same as if you had bought those features - they are activated with SCPI commands. The only "hack" is acquiring the code without buying it but the activation process is the same. If you enter an invalid key it just ignores it.
This python script is way easier than the method I used which was to do a memory dump of the device and search through the memory dump with a hex editor looking for certain strings.
(which means being able to execute code on the device)Although I didn't use the python script to unlock mine as I had already done it the hard way before I found the script - I've just run it now and confirmed it generates the exact same feature unlock keys that I found the more difficult way, so it definitely does work.
Last edited:
Ok, I wasn't aware of the difference in voltage rating, but like you, I would still not trust them over 300v anyway!
The main point is the frequency response of the two probes is almost identical though, within normal batch tolerances according to the measurements I linked.
It's rare that I would need to measure something over 100Mhz, but it's nice to know it can "just in case"...
Actually just reading that article again and he says to enter the AWG/WiFi/MSO codes using the on screen user interface - which would be very tedious and error prone! Much easier to do it via SCPI. Here is an example of the SCPI commands, keys would have to be changed to match the individual device of course:
LCISL AWG,W543W3ISPY9VBUVM
LCISL WIFI,23INF6KJFIKWMTNZ
LCISL MSO,AS425ISDE39RDHM3
Having done my fair share of coding, embedded, including cracking and other such activities in the past, it's important to highlight that this is not "hacking" in the bad computer user but utilising tools to unlock features that are charged for.
In theory siglent could sue you for loss of earnings but, it's likely to cost them more todo that than the cost of the licences.
They would simply refuse and warrantee repair work should the scope have software that wasn't theirs running but unless they track every user and the options bought for their scopes (unlikely due to cost) they are likely not to bother worrying about it. Companies won't do it because of risk, hence the number of instances would be low. The DIY market isn't worth causing a problem.
However.. should siglent use cryptographic guarded area in the ARM or Intel CPUs to manage security, then it will be extremely difficult for software engineers to reverse engineer and provide a tool to provide unlock codes.
In this scenario, the certificates are used and installed in the secure key management, so only unlock codes that are signed by siglent's private key would work.
However they're unlikely todo that unless someone produces a toolkit that costs less than the amount they're losing. Intel have made new cryptographic CPU instructions to make full memory encryption a possibility. However for an oscilloscope using full memory encryption there would be a definite performance impact.
I won't be long for the non-RSA style encrpyption to appear - NIST are currently in the last period of their security programme to find a replacement that is quantum safe but in the end nobody is going to force an update of a oscilloscope..
So that leaves firmware/software update going wrong - this is really a siglent issue as they own the update mechanism. Only bad programming ends up failures unless the underlying hardware has a fault - which goes back to finger pointing at siglent.
Most systems will have a rollback or roll forward with a new firmware version in the case of a corrupt install. Otherwise siglent will have additional costs unbricking products and never getting repeat sales again.
I hate python. It reminds me of Cobol for hipsters.
I have spent years looking and poking hex dumps, with 65C02 and ARM2 through ARM 710 assembler.
In theory siglent could sue you for loss of earnings but, it's likely to cost them more todo that than the cost of the licences.
They would simply refuse and warrantee repair work should the scope have software that wasn't theirs running but unless they track every user and the options bought for their scopes (unlikely due to cost) they are likely not to bother worrying about it. Companies won't do it because of risk, hence the number of instances would be low. The DIY market isn't worth causing a problem.
However.. should siglent use cryptographic guarded area in the ARM or Intel CPUs to manage security, then it will be extremely difficult for software engineers to reverse engineer and provide a tool to provide unlock codes.
In this scenario, the certificates are used and installed in the secure key management, so only unlock codes that are signed by siglent's private key would work.
However they're unlikely todo that unless someone produces a toolkit that costs less than the amount they're losing. Intel have made new cryptographic CPU instructions to make full memory encryption a possibility. However for an oscilloscope using full memory encryption there would be a definite performance impact.
I won't be long for the non-RSA style encrpyption to appear - NIST are currently in the last period of their security programme to find a replacement that is quantum safe
but in the end nobody is going to force an update of a oscilloscope..So that leaves firmware/software update going wrong - this is really a siglent issue as they own the update mechanism. Only bad programming ends up failures unless the underlying hardware has a fault - which goes back to finger pointing at siglent.
Most systems will have a rollback or roll forward with a new firmware version in the case of a corrupt install. Otherwise siglent will have additional costs unbricking products and never getting repeat sales again.
I hate python. It reminds me of Cobol for hipsters.
I have spent years looking and poking hex dumps, with 65C02 and ARM2 through ARM 710 assembler.
Last edited:
Ahh I was attempting to use MDCB (IIRC).. will have to try that but for now it's back in it's box until the coast is clear
(err the man cave is tidy).To be honest that's the reason I got a bit concerned after reading this a few days ago.
The thing is that (as I previously said) I only care about analogue audio and I'm gonna pair the scope with a siglent AWG anyway (most likely the SDG1032X). 100MHz would be more than enough I guess.
Also for now I don't really care about the wi-fi as I'm gonna connect it to my PC through LAN.
So to sum up, I just don't know whether I should bother...
ROFL. At this risk of this turning into a Python beatdown, I hate it too. For not having braces and relying on indentation. Less of an issue now that there are editors that'll make the code flow obvious. But it really put me off when I first tried to use it and all there was were basically plain old text editors.
I went back to it recently to try out Arduino programming, but, really, I still hated it. Was glad to use C++ instead (there being no embedded JVM). There's even an STL implementation available.
Ahh I was attempting to use MDCB (IIRC).. will have to try that but for now it's back in it's box until the coast is clear
MCBD is only for applying the frequency response limit code to unlock 200Mhz.
It's LCISL for unlocking the three feature codes, with the correct feature prefix and a comma before the code as in my example.
BTW you can apply the 100Mhz MCBD code if you ever want to revert it back to original spec for example if you were worried about sending it back for a warranty repair as there were never official 200Mhz unlocks available for purchase.
The three feature codes can't be removed using LCISL from what I remember, once you've enabled them they will remain enabled. There is a way to disable them again but I think it needs telnet access to modify a file directly. I didn't look into it much as why would I want to disable them again ?
If you do have telnet access to the filesystem it's pretty easy to find where these persistent things like keys are stored because 95% of the filesystem is a read only cramfs filesystem, and the preferences/keys etc are all stored in plain text or text based xml in the few read/write mount points...
Getting root telnet access to these scopes is pretty trivial but does require local (USB) access.
Last edited:
As far as I can see there's nothing like TPM or secure key management in these scopes, the feature activation keys are stored in plain text in the file system and then examined by the main scope executable (all the features in the scope except the web interface and screen mirroring are handled by one big executable) which calculates the key based on the Scope ID and serial number using a simple algorithm and if the keys in those plain text files match the feature is allowed. (And in the case of the frequency response, the appropriate digital filter is activated and the model number set - 100Mhz mode simply changes the coefficients of the low pass digital filter, it doesn't change any analogue circuitry)
All the SCPI commands are really doing is writing these key values to these plain text config files - you could do the same thing via telnet if you really wanted...
The algorithm must be pretty obvious because it has already been reverse engineered by the person who wrote the python script.
There also doesn't seem to be any private key signing for firmware updates - the ADS file format which is used for firmware updates has already been reverse engineered and there are tools out there to create custom ADS "update" packages.
For example someone has written a telnet server package as an ADS update file - so to install telnet its simply a matter of installing this "update" as if it were an update, and all it does is adds one line of php to the webserver to start a telnet server if you go to a magic URL...
Even better, this seems to persist across all the firmware updates/downgrades I've done, although I know how to manually remove it.
Great scope it is, secure embedded device it is not. In 10 minutes of poking around it in telnet I discovered how to circumvent the access password that you can set on the web interface for remote control.
It seems to be possible to freely upgrade AND downgrade firmware versions on these - I've done so a few times now. However if the system failed to boot I'm not sure how you would bootstrap it as the ADS packages are read by going into the utility menu...
The separate "OS update" uses uboot and a kernel/filesystem on a USB device to boot from USB but whether this could restore a fully messed up non-booting system I don't know and I don't care to find out!
Ok I'm afraid we can't talk anymore.
Then you'll be amused to find that the unlock codes were originally found by doing a memory dump of the running system to a file on external USB and then looking for certain strings with a hex editor - that's how I unlocked mine before I became aware of the python key generator which is a much easier, safer way which doesn't require any hacking...
If you're going to use a Siglent SDG1032X with it from what I've read you can use the bode plot function without the AWG license key.To be honest that's the reason I got a bit concerned after reading this a few days ago.
The thing is that (as I previously said) I only care about analogue audio and I'm gonna pair the scope with a siglent AWG anyway (most likely the SDG1032X). 100MHz would be more than enough I guess.
Also for now I don't really care about the wi-fi as I'm gonna connect it to my PC through LAN.
So to sum up, I just don't know whether I should bother...
You only need the AWG license key if you want to use it with the headless SAG1021I - that then lets you control the AWG for non-bode plot use via the scope's own UI. (Since the SAG1021I doesn't have a UI of its own) But even the SAG1021I doesn't need the license if you're only bode plotting.
That's also my understanding so I don't really see the reason to do the hack.
I might try though just for fun...
On a similar note, I was reading about the owon scopes being 14bit. Are they true 14bit and if so, are they any better than the siglent?
I think you should read some of the reviews - evblog Dave didn’t like it.
Hi,
have a look at what price level 12Bit scopes start from A-Brands like TeledyneLeCroy and such. Then ask Yourself if a lowlevel cheapy could possibly be 14Bit and deliver something we could refer to as 'quality' in the slightiest sense.
Also have a look at their website and see if You can find firmware updates and at what rate they update.
Keep in mind that the useability of a modern scope depends on the quality of its firmware and the design of the GUI far more than on its hardware.
And they all appear buggy on the market.
Now, how long are You willing to accept serious bugs? We got a Hantek 2102B signal generator at my company.
While beeing quite interesting/ok hardwarewise its firmware (no updates available over the devices lifespan) cripples the device so that You can't rely on what appears at its outputs.
In short ... the firmware renders the thing a piece of crap and its just collecting dust on a shelf.
I decided to go with Siglent because they seem to 'listen' to the community.
So far they haven't disappointed.
They not only update their firmware correcting for bugs, but also add more functionality to the devices.
The latest updates appeared this week and related to the SDS1000X-E and the SDS200X+ series. Go figure
jauu
Calvin
have a look at what price level 12Bit scopes start from A-Brands like TeledyneLeCroy and such. Then ask Yourself if a lowlevel cheapy could possibly be 14Bit and deliver something we could refer to as 'quality' in the slightiest sense.
Also have a look at their website and see if You can find firmware updates and at what rate they update.
Keep in mind that the useability of a modern scope depends on the quality of its firmware and the design of the GUI far more than on its hardware.
And they all appear buggy on the market.
Now, how long are You willing to accept serious bugs? We got a Hantek 2102B signal generator at my company.
While beeing quite interesting/ok hardwarewise its firmware (no updates available over the devices lifespan) cripples the device so that You can't rely on what appears at its outputs.
In short ... the firmware renders the thing a piece of crap and its just collecting dust on a shelf.
I decided to go with Siglent because they seem to 'listen' to the community.
So far they haven't disappointed.
They not only update their firmware correcting for bugs, but also add more functionality to the devices.
The latest updates appeared this week and related to the SDS1000X-E and the SDS200X+ series. Go figure
jauu
Calvin
There is a second release of R37 too that "fixes the wifi bug". If you go R37 firmware you'll need V2 operating system - I'm waiting to see if someone with the 200MHz has already done that update. I don't have time to mess with the scope - oddly I have some household electronics that have died thanks to some power outage intermittent starts so it's going to get put to some good use before it gets used on the tube amp..
@Calvin - Agreed for me, coming from a software product/services background, the firmware release schedule shows a support infrastructure and investment in the product/customer relationship. Releasing a product and not releasing regular firmware updates for bugs is the modern form of simply is taking your money and running. It is a key metric on the purchase decision. Hence steering away from the 1202X-E given it's firmware has been left to rot (I assume they've merged the 1202 and 1x04 operating system if they want a cost effective product range!).
@Calvin - Agreed for me, coming from a software product/services background, the firmware release schedule shows a support infrastructure and investment in the product/customer relationship. Releasing a product and not releasing regular firmware updates for bugs is the modern form of simply is taking your money and running. It is a key metric on the purchase decision. Hence steering away from the 1202X-E given it's firmware has been left to rot (I assume they've merged the 1202 and 1x04 operating system if they want a cost effective product range!).
My 1104X-E which is unlocked to 200Mhz is running the latest 37R6 release that includes the WiFi fix - no problems here.
The only change I’ve noticed is the fix to WiFi.