His method gets you root access to do just about anything you want on the scope without changing from stock,
Earlier there was the memdump SCPI command that lets you dump out the memory, then its just a case of searching with a hex editor for the strings,
If someone doesn't write it up in the next day or two, I can. but the earlier memdump method is all you need to actually find the option codes.
The telnet access is more if you want to fiddle with the scope
1. I didn't need to use a special copy of bash to get a core dump, the stock bash worked exactly the same as the special one (however see 2.)
You could make it even simpler by using "SHELLCMD cat /dev/mem > /usr/bin/siglent/usr/mass_storage/U-disk0/memdump.bin" as per post 54, but then you don't really know when it's done, it seemed easier having a command line ... and it's always nice to have a look around.
QuoteYou could make it even simpler by using "SHELLCMD cat /dev/mem > /usr/bin/siglent/usr/mass_storage/U-disk0/memdump.bin" as per post 54, but then you don't really know when it's done, it seemed easier having a command line ... and it's always nice to have a look around.
These methods will continue to work until Siglent pdsh's the SCPI SHELLCMD, or disables telnet access completely by removing the telnet binary from cramfs, in an upcoming firmware revision.
Hi, does the hack actually work? I mean, has anyone verifyied wether the hacked scope actually works at 200Mhz bw or all it does is changing the system info page?
So, this means that I did not use the "keys" method to update the bandwidth. Also, the bandwidth keys in my mem dump did not show a "duplicate" key indicating that the 200M license was active, but there is a "200M" reference nearby, and the PRBD? command shows "200M".
In addition, in my mem dump, there were only four 16 char bandwidth-license strings, and not five as VT100 suggested would be there, (i.e. indicating that one of them should be duplicated to represent the license key that the scope was operating under.) (Image attached)
I'm tempted to run the MCBD <license key> key command for what appears to be the 200M key (the second one, I presume, per VT100), as a belt-and-suspenders insurance that a future update won't clobber the "bandwidth.txt -> bandwidth.bak method" of bandwidth upgrade and return my scope back to 100M.
I guess I'm asking if anyone has an understanding or feel for the difference between a 200M license key install vs simply removing/renaming the bandwidth file? If I execute MCBD on what I've labelled the "200M key", will that duplicate the key (when I dump it again?) as VT100 suggests it should be?
I'm a bit confused that neither the 100M or the 200M key is showing as a duplicate, as I would have thought that, if VT100 is correct, at least one of them would be authorizing at least one bandwidth option.
I'm a little bit confused. I thought that 200Mhz bandwidth was not an 'option' on 1104x-e. So what the 200Mhz bw key is about?
I'm a little bit confused. I thought that 200Mhz bandwidth was not an 'option' on 1104x-e. So what the 200Mhz bw key is about?
It is not an option one can purchase. The scopes use the same platform -- apparently -- and their behavior is defined by a configuration that corresponds with the model it is sold as. It is supposed to be immutable. What is not known is whether there are any inherent differences in the hardware platforms? For example, would it be unreasonable to brand a scope that does not quite meet all the requirements for a 200 MHz scope as a 100 MHz scope? I don't think so. But, if one changes the configuration, and the scope well enough works at 200 MHz, why not? Of course, I would assert that the calibration is not valid when the scope is in that mode, it may not be possible to get the scope calibrated in that mode, and (regardless) the cost of calibrating this scope (whether it is an 1104 or a 1204) is going to approximate the cost of a new scope anyway.
So basically you are confirming my fears... we can hack it to 200Mhz but we can't be sure the scope is working properly in that mode and, worst of all, calibration in the hacked scope may not be valid anymore! So what's the point in hacking this scope? Too much at risk, only to spare a couple hundred bucks.
So what's the point in hacking this scope? Too much at risk, only to spare a couple hundred bucks.