Siglent SSA3000X and SSA3000X-Plus Spectrum Analyzers

[Elasia]

When you become familiar with SVA's UI you might find the setting to reset to the factory cal so to check any discrepancies between another Cal kit. 

Start exploring into 0.01dB/div and you'll find differences alright. 

Sounds good - once I get my 'SSA' SVA up and running - looking forward in exploring the UI 

@ 0.01db/div - just touching the connectors will definitely generate differences 

I guess getting some connector torque wrenches will come in handy - if you are really serious about calibration.

Tau is thinking in terms of it being a SVA in the first place.. SSAs dont have the factory cal files on them... it throws the warnings to console.. thats how i know its not loaded in the first place and needs default data saved

[Elasia]

How to crossflash a SSA3000X Plus into a SVA1032X:

1. Telnet into the equipment
2. rename
   /usr/bin/siglent/ecomb_p
   to
   /usr/bin/siglent/ecomb
3. in file /usr/bin/siglent/startup_app.sh change the line
   /usr/bin/siglent/ecomb_p &
   to
   /usr/bin/siglent/ecomb &
4. in file /usr/bin/siglent/config/NSP_config_upgrade_info.xml change the line
   <upgrade_static_id>11405</upgrade_static_id>
   to
   <upgrade_static_id>11403</upgrade_static_id>
5. Reboot
6. Now you can update your SSA with the Siglent's SVA stock FW.
   (should work with SVA1032X_2.2.1.2.5 or SVA1032X_2.2.1.2.7, at least)
7. After having flashed your first SVA stock FW, the SSA has become a "true" SVA.

To lower the risk you can do an additional step which is to activate the telned daemon before the line reference in step 3.
(for example, place there: /sbin/telnetd -l /bin/sh -p 10101  &     )

As always: do it at your own risk.

tv84 - thanks for your great mentoring and guidence for newbees like me on this subject


I could not resist in 'closing the loop' with your crossflashing proof of concept - to reverse the process 



How to crossflash a SVA1032X into a SSA3000X Plus:

1. Telnet into the equipment
2. Rename

    /usr/bin/siglent/ecomb
   to
   /usr/bin/siglent/ecomb_p

3. in file /usr/bin/siglent/startup_app.sh change the line
 
   /usr/bin/siglent/ecomb &
   to
   /usr/bin/siglent/ecomb_p & 
   
4. in file /usr/bin/siglent/config/NSP_config_upgrade_info.xml change the line

   <upgrade_static_id>11403</upgrade_static_id>
   to
   <upgrade_static_id>11405</upgrade_static_id>
   
5. Reboot
6. Now you can update your SVA with the Siglent's SSA stock FW.
   (should work with SSA3021/3032X Plus_V2.2.1.2.5 or SSA3021/3032X Plus_V2.2.1.2.7, at least)
7. After having flashed your first SSA stock FW, the SVA has become a "true" SSA.
8. If you already ‘own’ a SVA1032X – there may not be a good reason for crossflashing the FW for this device to turn into a SSA3021/3032X Plus.
    It’s just proof of concept as proposed by tv84

To lower the risk you can do an additional step which is to activate the telned daemon before the line reference in step 3.
(for example, place there: /sbin/telnetd -l /bin/sh -p 10101  &     )

As always: do it at your own risk.

btw... dont do this anyone.. it wont work sorry mate

[Elasia]

I found this chinese N type VNA calibration set for... 21 bucks, i'll have it in about a week.. go go prime

https://www.amazon.com/gp/product/B081J14316/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

[tv84]

tv84 - thanks for your great mentoring and guidence for newbees like me on this subject

I could not resist in 'closing the loop' with your crossflashing proof of concept - to reverse the process 


How to crossflash a SVA1032X into a SSA3000X Plus:

1. Telnet into the equipment
2. Rename

    /usr/bin/siglent/ecomb
   to
   /usr/bin/siglent/ecomb_p

3. in file /usr/bin/siglent/startup_app.sh change the line
 
   /usr/bin/siglent/ecomb &
   to
   /usr/bin/siglent/ecomb_p & 
   
4. in file /usr/bin/siglent/config/NSP_config_upgrade_info.xml change the line

   <upgrade_static_id>11403</upgrade_static_id>
   to
   <upgrade_static_id>11405</upgrade_static_id>
   
5. Reboot
6. Now you can update your SVA with the Siglent's SSA stock FW.
   (should work with SSA3021/3032X Plus_V2.2.1.2.5 or SSA3021/3032X Plus_V2.2.1.2.7, at least)
7. After having flashed your first SSA stock FW, the SVA has become a "true" SSA.
8. If you already ‘own’ a SVA1032X – there may not be a good reason for crossflashing the FW for this device to turn into a SSA3021/3032X Plus.
    It’s just proof of concept as proposed by tv84

To lower the risk you can do an additional step which is to activate the telned daemon before the line reference in step 3.
(for example, place there: /sbin/telnetd -l /bin/sh -p 10101  &     )

As always: do it at your own risk.

WARNING! THIS WILL NOT WORK!   (If you do it, it will require bootloader access.)

To do what you have described, you MUST NOT execute your Steps 2 and 3. All the rest is OK.

So, in the extreme, a simple re-setting of the Product_ID in the NSP_config_upgrade_info.xml file allows for the reverse crossflashing.

[tautech]

I found this chinese N type VNA calibration set for... 21 bucks, i'll have it in about a week.. go go prime

https://www.amazon.com/gp/product/B081J14316/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

Hmmm, if you haven't got a factory cal like a legit SVA you might be better served with a SMA cal kit and N-SMA adaptors as mostly you use SMA cables anyways.
That way, Cal can be performed near the port or close to the DUT at the end of cabling.

These might seem suitable:
https://www.amazon.com/Calibration-Dedicated-Include-Short-DC-3Ghz/dp/B07DGSF59F/ref=sr_1_9?dchild=1&keywords=SMA+calibration+kit&qid=1590914147&sr=8-9

But there are some cheaper ones here:
https://www.amazon.com/s?k=SMA+calibration+kit&ref=nb_sb_noss_2

[techneut]

And to show a hybrid SVA:

[noreply]

tv84 - thanks for your great mentoring and guidence for newbees like me on this subject

I could not resist in 'closing the loop' with your crossflashing proof of concept - to reverse the process 


How to crossflash a SVA1032X into a SSA3000X Plus:

1. Telnet into the equipment
2. Rename

    /usr/bin/siglent/ecomb
   to
   /usr/bin/siglent/ecomb_p

3. in file /usr/bin/siglent/startup_app.sh change the line
 
   /usr/bin/siglent/ecomb &
   to
   /usr/bin/siglent/ecomb_p & 
   
4. in file /usr/bin/siglent/config/NSP_config_upgrade_info.xml change the line

   <upgrade_static_id>11403</upgrade_static_id>
   to
   <upgrade_static_id>11405</upgrade_static_id>
   
5. Reboot
6. Now you can update your SVA with the Siglent's SSA stock FW.
   (should work with SSA3021/3032X Plus_V2.2.1.2.5 or SSA3021/3032X Plus_V2.2.1.2.7, at least)
7. After having flashed your first SSA stock FW, the SVA has become a "true" SSA.
8. If you already ‘own’ a SVA1032X – there may not be a good reason for crossflashing the FW for this device to turn into a SSA3021/3032X Plus.
    It’s just proof of concept as proposed by tv84

To lower the risk you can do an additional step which is to activate the telned daemon before the line reference in step 3.
(for example, place there: /sbin/telnetd -l /bin/sh -p 10101  &     )

As always: do it at your own risk.

WARNING! THIS WILL NOT WORK!   (If you do it, it will require bootloader access.)

To do what you have described, you MUST NOT execute your Steps 2 and 3. All the rest is OK.

So, in the extreme, a simple re-setting of the Product_ID in the NSP_config_upgrade_info.xml file allows for the reverse crossflashing.

OOPS!!!

Apologies to all following the crossflashing proof of concept in this thread.

tv84 noted such a concise step-by-step process after the successful and brave effort of Elasia and Techneut to do the crossflash from SSA to become a SVA, that I could not resist in simply reversing his process and posting as a tong-in-cheek.

Unfortunately, when you think about it (I clearly did not) it’s not a directly ‘flip-flop’ process!!!

The startup_app.sh for the SVA is different to the startup_app.sh for the SSA rendering the 'reversing' instructions DESTRUCTIVE if you do what was suggested by MY tong-in-cheek post

Despite the fact that you need to examine your thinking, if you ever decide to crossflash from an original SVA to become a SSA

PLEASE TAKE NOTE and DO NOT perform the ‘reverse’ procedure that I posted as a tong-in-cheek.

[noreply]

And to show a hybrid SVA:

 

[techneut]

tv84 - thanks for your great mentoring and guidence for newbees like me on this subject

I could not resist in 'closing the loop' with your crossflashing proof of concept - to reverse the process 


How to crossflash a SVA1032X into a SSA3000X Plus:

1. Telnet into the equipment
2. Rename

    /usr/bin/siglent/ecomb
   to
   /usr/bin/siglent/ecomb_p

3. in file /usr/bin/siglent/startup_app.sh change the line
 
   /usr/bin/siglent/ecomb &
   to
   /usr/bin/siglent/ecomb_p & 
   
4. in file /usr/bin/siglent/config/NSP_config_upgrade_info.xml change the line

   <upgrade_static_id>11403</upgrade_static_id>
   to
   <upgrade_static_id>11405</upgrade_static_id>
   
5. Reboot
6. Now you can update your SVA with the Siglent's SSA stock FW.
   (should work with SSA3021/3032X Plus_V2.2.1.2.5 or SSA3021/3032X Plus_V2.2.1.2.7, at least)
7. After having flashed your first SSA stock FW, the SVA has become a "true" SSA.
8. If you already ‘own’ a SVA1032X – there may not be a good reason for crossflashing the FW for this device to turn into a SSA3021/3032X Plus.
    It’s just proof of concept as proposed by tv84

To lower the risk you can do an additional step which is to activate the telned daemon before the line reference in step 3.
(for example, place there: /sbin/telnetd -l /bin/sh -p 10101  &     )

As always: do it at your own risk.

WARNING! THIS WILL NOT WORK!   (If you do it, it will require bootloader access.)

To do what you have described, you MUST NOT execute your Steps 2 and 3. All the rest is OK.

So, in the extreme, a simple re-setting of the Product_ID in the NSP_config_upgrade_info.xml file allows for the reverse crossflashing.

OOPS!!!

Apologies to all following the crossflashing proof of concept in this thread.

tv84 noted such a concise step-by-step process after the successful and brave effort of Elasia and Techneut to do the crossflash from SSA to become a SVA, that I could not resist in simply reversing his process and posting as a tong-in-cheek.

Unfortunately, when you think about it (I clearly did not) it’s not a directly ‘flip-flop’ process!!!

The startup_app.sh for the SVA is different to the startup_app.sh for the SSA rendering the 'reversing' instructions DESTRUCTIVE if you do what was suggested by MY tong-in-cheek post

Despite the fact that you need to examine your thinking, if you ever decide to crossflash from an original SVA to become a SSA

PLEASE TAKE NOTE and DO NOT perform the ‘reverse’ procedure that I posted as a tong-in-cheek.

Don't feel too bad, your instructions would just confuse someone. Here is the startup_app.sh
startup_app.sh.txt

[Elasia]

I found this chinese N type VNA calibration set for... 21 bucks, i'll have it in about a week.. go go prime

https://www.amazon.com/gp/product/B081J14316/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

Hmmm, if you haven't got a factory cal like a legit SVA you might be better served with a SMA cal kit and N-SMA adaptors as mostly you use SMA cables anyways.
That way, Cal can be performed near the port or close to the DUT at the end of cabling.

These might seem suitable:
https://www.amazon.com/Calibration-Dedicated-Include-Short-DC-3Ghz/dp/B07DGSF59F/ref=sr_1_9?dchild=1&keywords=SMA+calibration+kit&qid=1590914147&sr=8-9

But there are some cheaper ones here:
https://www.amazon.com/s?k=SMA+calibration+kit&ref=nb_sb_noss_2

Yeah I was wondering about a sma set too, i got real work i could use those for so really want to see what comes out of your adventure with hendorog coming up

These will hold me over in the mean time... cheap chinese is cheap chinese... dont think it matters a whole lot since it wont be a spec alignment like you were saying before.. worst case is i could put a converter on them so not really worried about it

[noreply]

Don't feel too bad, your instructions would just confuse someone. Here is the startup_app.sh
startup_app.sh.txt

Yeah, but there is no excuse - you can't make stupid comments - even tong-in-cheek - because you are 100% correct about possible confusion!

I was so euphoric about the success you guys demonstrated - that basic instincts did not kick-in, like making sure the start-up files were identical - which they clearly are not - thereby cannot have symmetrical reverse process.

Just to top-off my carelessness - I just performed a crossflash on my SSA with SVA1032X_2.2.1.2.7.ADS - the process went fine, but still reporting in system info a SSA3032x PLUS device with original options (I never enabled hack in my original SSA).

The real salt-in-the-wound is that I should have realized that by changing the ID - my SSA telnet is no longer useful 
I did take tv84 suggestion for the ‘safety’ /sbin/telnetd -ll /bin/sh -p 10101  & , but this only worked (could go straight into telnet after crossflash) on the initial boot after the FW update.

Unfortunately (carelessness again) I did not perform the mopping up housekeeping whilst having an open telnet session and decided to reboot - just to see if it comes back up without any problems.

It did, but I guess the original start-up we modified with the telnet start demon line is now gone, and since the ID is now set for the SVA my telnet_10101.ADS is not responding 

Not a bad start to the day I guess

[Elasia]

Don't feel too bad, your instructions would just confuse someone. Here is the startup_app.sh
startup_app.sh.txt

Yeah, but there is no excuse - you can't make stupid comments - even tong-in-cheek - because you are 100% correct about possible confusion!

I was so euphoric about the success you guys demonstrated - that basic instincts did not kick-in, like making sure the start-up files were identical - which they clearly are not - thereby cannot have symmetrical reverse process.

Just to top-off my carelessness - I just performed a crossflash on my SSA with SVA1032X_2.2.1.2.7.ADS - the process went fine, but still reporting in system info a SSA3032x PLUS device with original options (I never enabled hack in my original SSA).

The real salt-in-the-wound is that I should have realized that by changing the ID - my SSA telnet is no longer useful 
I did take tv84 suggestion for the ‘safety’ /sbin/telnetd -ll /bin/sh -p 10101  & , but this only worked (could go straight into telnet after crossflash) on the initial boot after the FW update.

Unfortunately (carelessness again) I did not perform the mopping up housekeeping whilst having an open telnet session and decided to reboot - just to see if it comes back up without any problems.

It did, but I guess the original start-up we modified with the telnet start demon line is now gone, and since the ID is now set for the SVA my telnet_10101.ADS is not responding 

Not a bad start to the day I guess

tv im sure will fix you up.. or if he really wanted to he could put out a special one that permanently turns it back on after a firmware update by adding the line to the startup scripts.. or adds it to the crossflasher

[noreply]

Don't feel too bad, your instructions would just confuse someone. Here is the startup_app.sh
startup_app.sh.txt

Yeah, but there is no excuse - you can't make stupid comments - even tong-in-cheek - because you are 100% correct about possible confusion!

I was so euphoric about the success you guys demonstrated - that basic instincts did not kick-in, like making sure the start-up files were identical - which they clearly are not - thereby cannot have symmetrical reverse process.

Just to top-off my carelessness - I just performed a crossflash on my SSA with SVA1032X_2.2.1.2.7.ADS - the process went fine, but still reporting in system info a SSA3032x PLUS device with original options (I never enabled hack in my original SSA).

The real salt-in-the-wound is that I should have realized that by changing the ID - my SSA telnet is no longer useful 
I did take tv84 suggestion for the ‘safety’ /sbin/telnetd -ll /bin/sh -p 10101  & , but this only worked (could go straight into telnet after crossflash) on the initial boot after the FW update.

Unfortunately (carelessness again) I did not perform the mopping up housekeeping whilst having an open telnet session and decided to reboot - just to see if it comes back up without any problems.

It did, but I guess the original start-up we modified with the telnet start demon line is now gone, and since the ID is now set for the SVA my telnet_10101.ADS is not responding 

Not a bad start to the day I guess

tv im sure will fix you up.. or if he really wanted to he could put out a special one that permanently turns it back on after a firmware update by adding the line to the startup scripts.. or adds it to the crossflasher

I think I need to take a break and get some fresh air - perhaps this will make me think before leap 

I took some screnshots, the systems info just after the crossflash of the SVA firmware - remember I had a 'stock' SSA3021x Plus - untouched!

Then I had a look at the mode screen - can see the SVA stuff grayed out - BUT silly me did not note if this is already present (also grayed out) in the stock SSA?? I think not - but cannot be sure 

[Elasia]

I think I need to take a break and get some fresh air - perhaps this will make me think before leap 

I took some screnshots, the systems info just after the crossflash of the SVA firmware - remember I had a 'stock' SSA3021x Plus - untouched!

Then I had a look at the mode screen - can see the SVA stuff grayed out - BUT silly me did not note if this is already present (also grayed out) in the stock SSA?? I think not - but cannot be sure 

They dont show up at all unless you are running the SVA program, they are hard disabled in the SSA program

[noreply]

I think I need to take a break and get some fresh air - perhaps this will make me think before leap 

I took some screnshots, the systems info just after the crossflash of the SVA firmware - remember I had a 'stock' SSA3021x Plus - untouched!

Then I had a look at the mode screen - can see the SVA stuff grayed out - BUT silly me did not note if this is already present (also grayed out) in the stock SSA?? I think not - but cannot be sure 

They dont show up at all unless you are running the SVA program, they are hard disabled in the SSA program

Thanks for the Feedback Elasia

Well that's great news 

- another confirmation that the SVA FW crossflash does indeed work on a new 'untouched' SSA3021x Plus   

Now need to get to the business end of things in getting all of the options enabled - hope I can figure this out without any serious  - more importantly - NO MORE careless mistakes 

[techneut]

The real salt-in-the-wound is that I should have realized that by changing the ID - my SSA telnet is no longer useful 
I did take tv84 suggestion for the ‘safety’ /sbin/telnetd -ll /bin/sh -p 10101  & , but this only worked (could go straight into telnet after crossflash) on the initial boot after the FW update.

Unfortunately (carelessness again) I did not perform the mopping up housekeeping whilst having an open telnet session and decided to reboot - just to see if it comes back up without any problems.

It did, but I guess the original start-up we modified with the telnet start demon line is now gone, and since the ID is now set for the SVA my telnet_10101.ADS is not responding 

Not a bad start to the day I guess

I can confirm that. The last thing I did was changing the ID and after that the SSA telnet.ads didn't work anymore and the SVA telnet.ads also not. I changed the ID back and hope that er are some very smart people with a fix before the next firmware update. And there is always the UART.

[Sighound36]

I would suggest either a couple of parameters need to be in alignment possibly hardware and software or there is a different section to thenmain boards no one has spotted?

[tv84]

 

Gentlemen, test please.

[noreply]

Gentlemen, test please.

Perfect - works like a charm 

Thank YOU so much

- now I need to get / create a flowchart / checklist, to make the various SVA functions come to life.

I can't afford to make any more careless mistakes 

[noreply]

Just documenting ... 

[techneut]

And thanks to tv84 no longer a unidentified (flying) object

[noreply]

The 'untouched' /usr/bin/siglent/startup_app.sh after the SVA firmware crossflash

- with added line (in RED) to start telnet demon (thanks to tv84)
- now after boot of the SVA you will be able to access telnet at your defined SVA lan ip on port 10101

I checked the added line for starting telnet demon after rebooting system

- all seems to boot OK
- telnet starts OK
- remember when editing startup_app.sh (or any files) you need to make files system rw



***BEGIN CODE***
#/bin/sh

export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:$PATH
export LD_LIBRARY_PATH=/lib:/usr/lib:$LD_LIBRARY_PATH
#echo "qt path config"
export QT_PATH_ROOT=/opt/qt
export LD_LIBRARY_PATH=$QT_PATH_ROOT/lib:$QT_PATH_ROOT/lib/ts:$LD_LIBRARY_PATH
export QT_PLUGIN_PATH=$QT_PATH_ROOT/plugins
export FONTCONFIG_PATH=$QT_PATH_ROOT/share
export QT_QPA_PLATFORM=linuxfb:fb=/dev/fb0:size=1024x600:mmsize=223x125:rotation=0
export QT_QPA_GENERIC_PLUGINS=evdevtouch:/dev/input/event0
export QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS=/dev/input/event0

export LD_LIBRARY_PATH=/usr/bin/siglent:$LD_LIBRARY_PATH
export LANG=en_US.utf8


mount -o remount,rw /usr/bin/siglent
if [ -d /usr/bin/siglent/usr/backup/app ]; then
        cp -rpf /usr/bin/siglent/usr/backup/app/* /usr/bin/siglent/
        echo "cp -pf /usr/bin/siglent/usr/backup/app/* /usr/bin/siglent/"
        sync
        rm /usr/bin/siglent/usr/backup/app -r
        sync
fi

/usr/bin/siglent/config_eth0.sh
/sbin/telnetd -l /bin/sh -p 10101  &
/usr/bin/siglent/Aladdin &

mount -o remount,ro /usr/bin/siglent
***END CODE***

[noreply]

And thanks to tv84 no longer a unidentified (flying) object

 

with a bit of envy 

I've still got to navigate with care before I get there 

[tautech]

And to show a hybrid SVA:

So what does the Mode list now look like ?

[noreply]

Before doing something silly ..

I noted that in the SVA there are TWO firmdata files

firmdata0

and

firmdata1

What is the expected structure in the SVA ?? - I recall the SSA had only one firmdata file - firmdata0

Second observation is that the firmdata0 and firmdata1 content seems to be identical ??


AND

The SVA firmdata0 NSP_sn_bandwidth.xml content is IDENTICAL to the same file in the SSA firmdata ??

Is the firmdata in the SVA the 'leftover' from the SSA??

It seems to be that the stock SVA firmware does not have license file info - presumably this is loaded onto the device at a later (post firmware) stage??

If so, this would make sense as it appears the SVA NSP_sn_bandwidth.xml file contains the SSA license data only.

In my case because it was an untouched SSA3021x Plus - there are no SVA options visible in the file 

Question is ...

What are the SVA various options legit 'license tags' that can be added into the current NSP_sn_bandwidth.xml file??

Am I on the right track here or simply 

Would be nice to understand this before going further 


EDIT: When you take you time and try to understand what's sitting in front of your eyes - eventually everything falls into place - all good - another successful SVA crossflash with all options enabled about to happen