Great news. Congrats!!!
As I've told SMB784, I advise all to:
1st option - Instead of the official OS install, install janekivi full OS file. It's exactly the same thing with the pwds already changed.
2nd option - After installing the official OS, when you install janekivi patch, do it only with the rootfs file (and the script .txt, of course).
Less operations, less risk!
Regarding the advice of CustomEngineerer about the login problem: thinking of it, it was totally right and not an insult, it could have been a problem with the client SMB784 was using to connect to the scope. Although SMB784 was able to see the correct prompt, there was no assurance that what he writes in the console was correctly/transparently being sent to the scope.
A solution could have been to change the client (I usually use Putty) or investigate what was introducing garbage in the connection.
Or, in the extreme, use (in his case) the RPi as a gateway to telnet to the scope...
Glad it is solved! Now, time for upgrade.
As it turned out in my case, the problem wasn't the telnet, rather it was the act of copying the files from the computer to the flash drive.
I tried telnetting into the scope from the RPI with the software installed from files copied over using my desktop and couldn't log into the scope. But as soon as I copied the files over to the USB using the RPI, the scope recognized them and correctly installed the custom software, and at that point I could log in via telnet from either the RPI or the desktop.
So something was going wrong in the process of making the USB with the custom software on it when using the desktop. I have no earthly idea what could have been going on though.
In my case, using RF-loop's instructions worked perfectly once I performed them using the RPI to make the USB instead of the desktop.
As it turned out in my case, the problem wasn't the telnet, rather it was the act of copying the files from the computer to the flash drive.
Anyway, what is odd, is that you were able to correctly generate the factory OS update USB configuration. Was that the same process that didn't work for your attempt with the modified OS update?
Let's take a look in SDG1000-V100R001B01D01P31.ADS for example
This may be common knowledge, but I was about to try fixing the root password for my SDS1102X running SDS1000X_V100R001B01D02P1510.ADS, and discovered that there is no telnet service running. Only Ports 111 and 9009.
So much for my idea of trying to upgrade the bandwidth - at least until there is enough progress here to decode and re-assemble the entire thing.
https://www.siglentamerica.com/service-and-support/firmware-software/dc-power-supplies/#spd1000x-series
This was long time ago, but not in the table yet
File Header Size: 00000070
00000000 - File Checksum: FE691817 [00000004-0002FB6F] (with only the File Header decrypted) CKSM OK
00000004 - File Size: 0002FB00 (without 0x70 bytes of the File Header)
0000000C - Product_ID: 600
00000026 - Vendor/Brand: SIGLENT
0000003A - USB Host Controller: ISP1763
****************************************************
Decrypting the 0x2800 and 0x1400 blocks...
Reversing file...
XORing with 0xFF (incrementing pattern)...
XORing with 0xFF from 0x00017D80 until 0x0002FAFF
****************************************************
00000000 --- Section Checksum: FEE2D1B1
00000004 --- Section Size: 0002FACC [00000034-0002FAFF] CKSM OK
00000008 --- Section # 00000007
00000034 --- 0002FAFF ***** STM32 32-bit ARM Cortex file *****
00000034 - Vector Table: (Little Endian - Flash(ROM): 0x08000000 - SRAM: 0x20000000)
00000034 --- Initial SP value: 200193F0
00000038 --- Reset: 0802039D (Thumb 16/32 bits)
0000003C --- NMI: 080203C1 (Thumb 16/32 bits)
00000040 --- Hard fault: 080203C3 (Thumb 16/32 bits)
00000044 --- Memory management fault: 080203C5 (Thumb 16/32 bits)
00000048 --- Bus fault: 080203C7 (Thumb 16/32 bits)
0000004C --- Usage fault: 080203C9 (Thumb 16/32 bits)
00000050 --- Rsvd1: 00000000
00000054 --- Rsvd2: 00000000
00000058 --- Rsvd3: 00000000
0000005C --- Rsvd4: 00000000
00000060 --- SVCall: 080201B9 (Thumb 16/32 bits)
00000064 --- Rsvd for Debug: 080203CD (Thumb 16/32 bits)
00000068 --- Rsvd5: 00000000
0000006C --- PendSV: 080201E9 (Thumb 16/32 bits)
00000070 --- Systick: 080203D1 (Thumb 16/32 bits)
00000074 --- IRQ0 to IRQ80 [00000074-000001B7]
****************************************************
File Processed OK
If I remember correctly, the OS update was previously listed on the download page as:
SDS1004X-E Operating System -V1 (Only For 4-Channel ) (Release Date 05.22.18)
but is currently listed as:
SDS1004X-E Operating System -V1 (Only For 4-Channel ) (Release Date 06.26.18)
New firmware for SVA1015X
V2.1.1.1.12a
https://www.siglentamerica.com/download/6912/
38.8 MB
Changelog
2018/8/8
1. Spectrum Analysis modeļ¼Improved the stability of sweep and interface.
2. VNA mode: fasten the VNA sweep speed; expand the minimum span from 10M to 10 kHz.
3. Modulation Analysis mode: add trigger, optimize the modulation analysis algorithm.
4. Add user port number selection for web server.
This may be common knowledge, but I was about to try fixing the root password for my SDS1102X running SDS1000X_V100R001B01D02P1510.ADS, and discovered that there is no telnet service running. Only Ports 111 and 9009.
So much for my idea of trying to upgrade the bandwidth - at least until there is enough progress here to decode and re-assemble the entire thing.