Siglent SSA3000X and SSA3000X-Plus Spectrum Analyzers

[Bicurico]

Hello, sorry for late reply, I was away for the weekend.

df -k shows 100% for root: not so good!

My guess is that the "last_config.xml" file used up all the free space and now the device hangs when trying to write a new line.

You can try to make a backup of this file and then deleting it. But in order to delete it, I guess you need write permission for this partition.

You should definitely know what you are doing.

And I agree with tv84: please post this file or at least show the last entries. It might reveal if there is something wrong.

Good luck. --> great you fixed it!

[bicycleguy]

@Bicurico  It still shows 100% but seems to be working.  What does your show?

Code: [Select]

/usr/bin/siglent/usr/config # df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root                63152     63152         0 100% /
devtmpfs                 69852         0     69852   0% /dev
none                     78140         4     78136   0% /tmp
ubi1_0                   30388     20852      9536  69% /usr/bin/siglent
ubi2_0                    5848       192      5656   3% /usr/bin/siglent/firmdata0
ubi3_0                    5848        24      5824   0% /usr/bin/siglent/log
ubi0_0                   84752      7692     77060   9% /usr/bin/siglent/usr
/usr/bin/siglent/usr/config #


[Noy]

On purpose or not on purpose (bug) by Siglent..
Maybe Siglent wants to paralyze the "hacked" devices in this way.
Excessive debug logs may only be generated on "Pro" mode devices with XXXX serial numbers.

[Bad_Driver]

I had the same problem. Sometimes it took up to 10 minutes till the the system shows up, stay patient.
System reset and firmware update helped.

Have the same problem these days with my SDS2000X+.

[bicycleguy]

Continuing to run great.

The 'last_config.xml' file size has remained around 22k after approx 15 full on/off cycles.  The original issue with the calibration stuff not working correctly after shut down in VNA mode and start up in VNA mode that caused me to on/off cycle so much seems fixed.

Perhaps the xml file had become corrupted.  It appears to only be read at startup and written when shutting down.  I don't normally power on/off more than once in a day.  Startup time seemed to be increasing but I didn't write it down or realize before it was too late the startup times seemed to double every time I started up.  This started before the latest revision and was the reason I tried the latest revision.

So all this is to say I think Siglent has an unintentional bug in parsing the xml and not handling correctly when it fails.  Probably only related to config file format changes between revisions (which any programmer will tell you is a pain) or user influenced by changing SSA->VNA.

[hendorog]

Maintaining the Last config after FW upgrade has been a problem before. That file really should be blown away on FW upgrade.
 
If you think about it, it is quite hard to migrate a config file from version x to version y when version x could include many versions, including those from the future (in a downgrade situation)

Reset and Clear should work, but did anyone try changing from 'Last' or 'User' to 'Def' setting on Power On (or Preset), and then Rebooting (or Presetting) and then changing back again?
Hopefully that just deletes the file and recreates it.

[TopQuark]

I recently encountered the bug of the SA (hacked to SVA) not booting up, freezing at the Siglent logo, narrowed it down to the SA being configured to boot up with last used settings, there must have been some settings that made the SA unhappy and not boot up.

Took a lot of trails and errors (and cold sweats fearing my SA was bricked), but at the end what fixed it for me was to:
- Access the SA web server by typing the IP address of the SA into a browser (surprisingly works)
- Go to SCPI command page
- Send ":SYSTem:PRESet:TYPE?"
- If it replies with "LAST", you are probably facing the same issue I had
- Send ":SYSTem:PRESet:TYPE DFT"
- Send ":SYSTem:RESTart"
- Should boot up normally

I think this issue is a common theme among Siglent products, I once had my SDS2504X Plus not boot up due to a channel attenuation ratio set to something weird.

edit: The SA was not being upgraded when it was bricked, it just decided to not boot up one day

[RoV]

I finally decided to upgrade to 3.2.2.5.1R1 (SSA3021X+ upgraded to SVA, with correct s/n).
Everything worked perfectly. As usual, I lost the telnet connection on port 10101, but I could enter using the SCPI port (tymm's hack) and restore the line on startup_app.sh, without needing a telnet ADS file.
Disk occupation seems identical to bicycleguy, with 100% on /dev/root (but I think this is normal, it's a protected partition). File last_config.xml is 18695 bytes.

Code: [Select]

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root                63152     63152         0 100% /
devtmpfs                 69852         0     69852   0% /dev
none                     78140         4     78136   0% /tmp
ubi1_0                   30388     20860      9528  69% /usr/bin/siglent
ubi2_0                    5848       148      5700   3% /usr/bin/siglent/firmdata0
ubi3_0                    5848        24      5824   0% /usr/bin/siglent/log
ubi0_0                   84752      8460     76292  10% /usr/bin/siglent/usr


[tv84]

SSA30xxX+ Service Manuals.

[BitByBit]

We'll, I am bit more savvy on x86, but I took a swing at ARM debugging and figured out the differences needed to make the previous Python KG work with some modifications. Note that this code is only tested on an SVA1015X, and I had to use model 'SVA1000X' per what was listed in memory during key entry. All trial features are permanently unlocked and the serial # remains.

A few tips: Do not simply delete NSP_sn_bandwidth.xml ...the latest SVA firmware detects this and bad things happen. The reason nsp_data_b1 must be deleted, is that changes to NSP_sn_bandwidth.xml, by normal use, are reflected in tweaked 3DES form within nsp_data_b1.

https://pastebin.com/rhdW63Vz

[tomud]

We'll, I am bit more savvy on x86, but I took a swing at ARM debugging and figured out the differences needed to make the previous Python KG work with some modifications. Note that this code is only tested on an SVA1015X, and I had to use model 'SVA1000X' per what was listed in memory during key entry. All trial features are permanently unlocked and the serial # remains.

1. For other SVA models also leave Model = 'SVA1000X'
2. SCOPEID = Host ID from "System Info" (no console use needed)
3. "ALL" can be added to the "otheropt" array - it will generate a key for all options: otheropt = ('AMK', 'EMI', 'DMA', 'AMA', 'DTF', 'ALL')

Personally, I have not tested this code (I have already unlocked all functions in the converted SSA3021X Plus to SVA1032X for a long time - https://www.eevblog.com/forum/testgear/siglent-ssa3000x-spectrum-analyzers/msg3090863/#msg3090863). However, the code generated by this script for all options matches the code with which I unlocked my SVA1032X - so you can see that it works OK

a little changed version with the ability to run the code:
https://www.online-python.com/1SxtgdB4Op

If someone has SSA3000X Plus version (without SVA conversion), you can check if this code change works:

Model = 'SSA3000X+'

https://www.online-python.com/mihMQO2AvT

[Skashkash]

a little changed version with the ability to run the code:

If someone has SSA3000X Plus version (without SVA conversion), you can check if this code change works:

Model = 'SSA3000X+'

Just tested this with a stock SSA3021X Plus, SW: 3.2.2.4.0
 I only tried the EMI and AMK feature, but was a no go. INVALID LICENSE.   

 Let us know if you have anything else to test.

[RoV]

Thank you BitByBit and tomud!
My SSA3021X+ unit was already converted to SVA1032X thanks to an angel flying around here  , but I confirm I get the same codes now.
Remember to use the Host ID, not the Serial, and 'SVA1000X'!
Remember also to restore the Serial using SCPI before inserting options, if you are in PRO mode.
I was given two option strings to enable all features and 3.2 GHz, and they both match using opt codes '3032' and 'ALL'. I suppose that 'ALL' alone will let the instrument at 2.1 GHz.

[tomud]

@Skashkash

If you rewritten the HostID number correctly (not changing the case of the Hex notation) then there is not much I can help. I have included the script to check if the calculation method is the same for SSA and SVA (For oscilloscopes, I can see that the algorithm is the same).

Unfortunately, I don't have time to upload SSA software to my spectrum analyzer and check it more carefully. There is a chance that someone else posted an SSA memory dump (This will help you find out more).

How to take a memory dump is described in the topic about hacking SDS1104X-E https://www.eevblog.com/forum/testgear/unlocking-siglent-sds1104x-e-step-by-step/

@RoV

It's nice that you also checked and confirmed that the python script is working properly This is good news for users who have spectrum analyzers in pro mode.
It remains to wait for information from people who have restored their serial number and fully unlocked their spectrum analyzer.

As for the 3.2GHz band in my SAA3021X Plus - I had it already after changing the device type and uploading the software from SVA1032X. So it was enough to enter only the code for all options.

Later I changed the files so that the spectrum analyzer in System Info would show the name SVA1032X and added the missing VNA calibration file which tv84 shared in this thread or in the SVA1000X thread. As I remember correctly these are the files na1_p and na2_p. It is known that this is not a calibration from my spectrum analyzer and it is not perfect, but the analyzer does not throw errors in the logs anymore.

I wonder if there is any option to enter some service mode to do the correct VNA calibration (I just have the opportunity to access higher-class equipment which I could do such a calibration). I was looking at the structure of these files and they look similar to the calibration files we can save ourselves. However, without disassembling the software, it is difficult to find out what data is stored there and how it could be generated, and unfortunately I do not have time to analyze the software at the moment (maybe someday, when I find more free time, I will do disassembly and learn more about the software).

[tv84]

'SSA3000X_Plus' 

[tomud]

'SSA3000X_Plus' 

And as always, the irreplaceable TV84 comes with help  Personally, thank you very much for the contribution and help of many people in unlocking this equipment

[DL4JY]

'SSA3000X_Plus' 

With this model ID I can verify my "/_3021/" (and others)  entry in the original "SSA3021X_Plus" NSP_sn_bandwidth file.

Thanks

Juergen

[tv84]

No more time to hand in homework...

To close things off:

"SSA3000X", "SSA3000X_Plus", "SVA1000X", "SSA3000R"

[tomud]

No more time to hand in homework...

To close things off:

"SSA3000X", "SSA3000X_Plus", "SVA1000X", "SSA3000R"

Summarizing the collected information (Updated August 29, 2023)

Script to run:
http://tpcg.io/_SV2SRE

And added to the attachment (as if the links stopped working).

[John317]

I have been chasing the option codes for the SSA3000X_Plus for a while now and have had not success. I had gone as far as decompiling the software and trying to brute force the codes with varying device types and host ids applicable to my unit, but never found the right combo (wrote looping scripts to try many possibilities and a program to "type" the codes in and try them via the web interface). Even when looking in the source of Aladdin and gleaning bits and pieces about text case from the community here, I could not get the unit to accept my keys. I ended up renaming nsp_data_b1 to run in PRO mode and then sometimes switching back by recovering the file when needed. It has gotten me by, but not ideal.

With the recent posts I recovered by backup nsp_data_b1 file and rebooted. Today, I found an interesting option in my system now, VNA and listed as permanent. The option keys produced from the script above still do not work for my SSA3021X Plus, so I ran the SRLN <my serial> and let it reboot. The option page did not change for options as the VNA was still in there and the script still does not work. There might be something amiss with the unit since I have been switching between PRO and not, but still strange to see the VNA in there. Anyone else ever see this? Is there a way I can really reset it and try this script again?

[tv84]

I have been chasing the option codes for the SSA3000X_Plus

Did you crossflashed it to SVA?

[John317]

Now that I am thinking of it, I did try recently to use the ADS file upgrade with the HEX edit, but the Model number did not change and I assumed the upgrade did not go..... Maybe I am wrong and overlooked this. If that is the case, I might have made a mess.....

[John317]

Ha, I changed the model to SVA1000X in the python script and it accepted the options. I guess I have a crossflashed unit now, lol. Just the Model number is incorrect. If I remember right, I can change that in a config file. From what I read (or think I did), the model would have updated on its own.

[tomud]

Ha, I changed the model to SVA1000X in the python script and it accepted the options. I guess I have a crossflashed unit now, lol. Just the Model number is incorrect. If I remember right, I can change that in a config file. From what I read (or think I did), the model would have updated on its own.

Yes, after making the SSA->SVA crossflash, the name displayed in System Info must be changed manually in NSP_trends_config_info.xml file. The same in this file, I also changed the PID (from 0x1305 to 0x1301).

this is what my file looks like after changing:

Code: [Select]

<?xml version="1.0" encoding="UTF-8"?>
<nsp_trends_info_root>
<device>
<language>english</language>
<pid>0x1301</pid>
<vid>0xf4ec</vid>
<product_type_1>SVA1032X</product_type_1>
<manufacturer>Siglent</manufacturer>
<Support_Touch_Flag>1</Support_Touch_Flag>
<Support_VXI11_Flag>1</Support_VXI11_Flag>
<file_prefix>CP_</file_prefix>
</device>
</nsp_trends_info_root>

After changing SSA to SVA, I also uploaded the missing calibration files (na_1p and na_2p) to firmdata0/cali

These files, as I already mentioned, were provided by TV84. He also mentioned that the converted SSA-> SVA differs from the original SVA by the lack of these files.
Unfortunately, I can't find this post right now, so I am enclosing these files as an attachment.

Added after a while
Found a topic with calibration files: https://www.eevblog.com/forum/testgear/siglent-sva1015x-1-5ghz-spectrum-vector-network-analyzer-(coming)/msg3707803/#msg3707803

[John317]

Thank you tomud for this. I have updated the one file and the model now reflects it is a SVA!

Interesting enough, I already had those calibration files (na_1p and na_2p) in the directory firmdata0/cali. I wonder if when i directly cross flashed with 3.2.2.5.0 code (with the hex edit) that this version puts them in there. Maybe not, but they are definitely in there and have the same data/time as the rest in the directory. The date/time aligns with when I did the "upgrade".

Silly question, am I safe to upgrade to 3.2.2.5.1 and farther when code is released?

Thank you!