I just got this scope and completed the *upgrade*. My experience was a mashup of other users, so I figured I would comment on what didn't work and what I ended up doing to achieve success.
What didn't work:I followed the core dump procedure. I did the following:
- Run the SCPI command SHELLCMD telnetd -l/bin/sh -p9999
- Connect to the scope and follow the remaining core dump procedure on post #39
There are a few typos, but I was able to execute the procedures. I ran through it several times and was never able to generate a core dump on the first try. I then tried simply restarting SDS1000b.app without rebooting the scope and killing again (not what the above procedure suggested). A few times I was able to get the core dump file to generate, but that lead to another problem. As another user stated, the scope buttons remained unusable, even after restarting the app. The only way to recover was a power cycle. This would wipe out the core file that was created. In addition to the buttons not working, the scope would not detect the USB drive anymore to copy the core dump too. The Linux OS would detect the drive, but it would not mount. I had to manually create a temp directory in /usr/bin/siglent/usr/mass-storage/ and manually mount /dev/sda1 to it to copy the core dump. I did this several times with several core dumps. I got a ~207MB file each time, but most of it was empty and searching for the string "SDS1000X-E" always yeilded "no match". So, this method did not work for me.
Perhaps someone can explain why?What did work:Using following command to get a mem dump on the USB drive worked perfectly:
post#54SHELLCMD cat /dev/mem > /usr/bin/siglent/usr/mass_storage/U-disk0/memdump.binThe flash drive I was using had an LED indicator that flashed when preforming a read/write and slowly dimmed when idle making it easy to tell when the file was done writing, which was nice. I created several mem dumps to compare. Each one was different, which was expected, but I noticed only one contained my BW keys in a contiguous block that was human readable. None of them contained the options keys in a contiguous block, thus I needed to use some tools. I ended up trying the FindKeys and Trykeys tools mentioned in
post #38. make sure you have the current version of Visual Studios (I ran VS2017 15.9) and install .NET Core 2.1 as that is what the tools run on.
Define the proper parameters in the FindKeys .json file as instructed in the repo readme and run the FindKeys tool against your mem dump file. It will generate a txt file that has all the possible combinations of possible keys through the fragmentation of the mem file.
Define the proper parameters in the TryKeys .json file as instructed in the repo readme. I noticed some things about the TryKeys program that should be addressed
before running it.
- It is setup to use authentication for the Telnet connection. This is not needed if using the below method to create an unauthenticated Telnet session. If the code is ran with the authentication step, it will hang. Simply comment out the IF statement if(!client.login() ...) to skip this.
- I noticed that the code did not handle the response of the Telnet command properly WRT the bandwidth file. When parsing out parts of the response, it didnt seem to take into account that there was more information than expected. For example, if you selected "true" in the .json file to update the bandwidth.txt file, it reads the bandwidth file to see what the current key is. The response contained the entire cat command and PWD, but the code only grabbed the first 16 characters assuming it was the currently activated key string, but it was not. I selected "false" in the .json file so that it did not try to update the bandwidth and bypassed this whole mechanism. Perhaps it should use the .Contains() method as it does elsewhere in the code? I did the BW update in a later step below.
- The telnet port is hard coded to check that 23 is used, but the .json file allows you to set a port number. This is odd as it will fail the comparison if anything other than 23 is used, so why make it a user definable option in the .json file???
I changed the code to allow any port to be used (9999 in my case). - The code will try to send each key generated from the FindKeys txt file for each option. When the scope generates the corresponding options file, the program reports success for that key and moves on to the next option. The program then reports what key worked for each option. I ran this in single step because the program closes immediately after it finishes leaving no chance to write down the information (I also did this to make sure I understood what it was doing in each step). A pause should be added at the end if not running in single step if you want to document the keys. Or, you could always cat out the license file it generates. They contain the valid keys too.
The root telnet access method is needed for the TryKeys program to run:
Run the SCPI command
SHELLCMD telnetd -l/bin/sh -p9999Then run the Trykeys based on the above config/recommendations.
If you didnt use the Trykeys to update the bandwidth (like me), run the SCPI command
MCBD (license key) where (license key) is the key for the bandwidth you want, to update it manually. Then reboot and check with the
PRBD? command to verify.
All in all, I think the method that worked for me is the simplest as it requires no software modifications (I was running 7.1.6.1.25R2 out of the box). It is also the most reliable as I was able to get the mem dump file every time I ran the command and all the files ended up producing the valid keys.
Hope my experience makes this process easier for others! I am really enjoying me new scope!
Home
Help
Search
Login
Register
