Siglent SSA3000X and SSA3000X-Plus Spectrum Analyzers

[durec]

durec, empty your inbox!

Yes, done. I didn't  know is full..  :-)

[noreply]

I just received a GPSDO frequency source (shipped from China - just over 2 week - nice!)

Will do dedicated review on this later, but for now have some useful information regarding the accuracy on the internal oscillator in the SSA3021X Plus.

When I hooked up up the GPSDO - it got a 'GSP lock' within 60 seconds - great!

In theory I was now getting an atomic stability on my 10MHz reference signal from the GPSDO output.

Quick check on the MSO - revealed 10MHz precisely.

But what is precisely - the MSO only has 0.0000 capability - pointless for a frequency reference accurate tp 10^-11, but how can you check that it is indeed accurate to 10^-11??

Well I certainly cannot do this with my equipment.

So, I guess the next best thing was to hook it up to the SVA and check the spectral quality of the GPSDO 10MHz frequency source.

Assuming that the GPSDO does indeed maintain accuracy - when 'GPS lock' is in effect - to 10^-11 then the SVA internal frequency is pretty good.

My measured value was 10.000003MHz - reverenced to the much more precise 10MHz from the GPSDO - accurate to 0.00000000000 digits at least

That's 3Hz above the 10MHz signal

Perhaps someone could check the published specifications for the accuracy of the internal oscillator?

I don't have this handy at the moment.

The SVA was 'powered-on' (warm-up) for at least 60 min


Please see the screen shots below;-

Since the frequency span was so narrow
- I pushed the RBW down to 100Hz and VBW to 1Hz

I did some harmonic test
- the GPSDO fundamental frequency is well above the 1st and 2nd harmonics

Interesting observation was that the 2nd harmonic was lower than the 3rd (feel free to chime-in with explanation)

Hope you find this information useful.

Those of you able to do a precise frequency source accuracy check on your SVA - please post your results.

Thanks

[Emo]

Another short report of a cross flash


Starting with 2.2.1.2.3r1 I first performed a nand dump(mtd0 - mtd11) and made myself acquainted with the file system(s). At this moment telnet access with the default password was available.

/usr/bin/siglent # df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                61.7M     61.7M         0 100% /
devtmpfs                 68.2M         0     68.2M   0% /dev
none                     76.3M      4.0K     76.3M   0% /tmp
ubi1_0                   29.7M     18.8M     10.9M  63% /usr/bin/siglent
ubi2_0                    5.7M    364.0K      5.4M   6% /usr/bin/siglent/firmdata0
ubi3_0                    5.7M     24.0K      5.7M   0% /usr/bin/siglent/log
ubi0_0                   82.8M    300.0K     82.5M   0% /usr/bin/siglent/usr
/dev/sda1                 7.5G    171.2M      7.3G   2% /usr/bin/siglent/usr/mass_storage/U-disk0

One of the remarkable findings was that there was no ecomb file and an empty firmdata1 directory

/usr/bin/siglent # ls
Aladdin         firmdata0       log             startup_vnc.sh  vnc_test
config          firmdata1       startup_app.sh  usr             vncserver
drivers         lib             startup_ftp.sh  vdma_vnc.sh     vsftpd

 I updated to 2.2.1.2.5 and using the telnet.ads I gained accesss again. Again performed then and dump.
The filesystem changed somewhat
/ # df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                61.7M     61.7M         0 100% /
devtmpfs                 68.2M         0     68.2M   0% /dev
none                     76.3M      4.0K     76.3M   0% /tmp
ubi1_0                   29.7M     22.7M      7.0M  76% /usr/bin/siglent
ubi2_0                    5.7M    600.0K      5.1M  10% /usr/bin/siglent/firmdata0
ubi3_0                    5.7M     24.0K      5.7M   0% /usr/bin/siglent/log
ubi0_0                   82.8M    756.0K     82.0M   1% /usr/bin/siglent/usr
/dev/sda1                 7.5G    712.5M      6.8G   9% /usr/bin/siglent/usr/mass_storage/U-disk0

And the ecomb_p file showed-up
/usr/bin/siglent # ls
config          ecomb_p         lib             php.ini         startup_vnc.sh  vnc_test
config_eth0.sh  firmdata0       lighttpd.conf   startup_app.sh  usr             vncserver
drivers         firmdata1       log             startup_ftp.sh  vdma_vnc.sh     vsftpd
 from this situation I followed the #963 post, renamed ecomb edited NSP_config_upgrade_info.xml and rebooted followed by upgrade with SVA1032X_2.2.1.2.7.ADS

The result was a SVA with 2.1 G bandwidth and grayed out VNA keys and 5 permanent licences including serial. Only after changing
<nsp_trends_info_root>
        <device>
                <language>english</language>
                <pid>0x1305</pid>
                <vid>0xf4ec</vid>
                <product_type_1>SSA3032X Plus</product_type_1>
                <product_type_2>SSA3021X Plus</product_type_2>
                <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>

And
/ # mv /usr/bin/siglent/firmdata0/NSP_sn_bandwidth.xml /usr/bin/siglent/firmdata0/NSP_sn_bandwidthx.xml
/usr/bin/siglent/firmdata0 # mv nsp_data_b1 nsp_data_b1x

The system was fully enabled after a reboot(however in pro-mode)

Next step is the factory calibration of the VNA part
It appeared to me that a “cali” directory is placed under firmdata0 and it seems to represent correction data for several parts of the instrument. There is also a configuration directory, however this seems to contain mathematical lookup tables etc.
In the cali directory it looks like attenuator corrections, IF stats, TG output power, RF attenuation etc

Question; could someone with a genuine SVA check if more files are included in this section please.
If so a wrong file might be better than no file or even we might have a possibility to calibrate the instrument ourselves.(I know, wishful thinking)


All in all it was a useful exercise.

[tomud]

When I hooked up up the GPSDO - it got a 'GSP lock' within 60 seconds - great!

I don't know what version of GPSDO you bought

But "catching a gps fix" doesn't mean having a stable frequency. In such systems, GPS stabilizes the work of OCXO, while OCXO requires a longer warm-up for stable operation. 60 seconds is definitely not enough and the system has not stabilized for sure.

In such systems, phase noise at the output also plays an important role - but as I said, the quality of such a system depends on the design.

The best systems are based on Trimble Thunderbolt and Chinese ham BG7TLB. Both are sufficient for amateurs.

Personally, with the Trimble Thunderbolt + rubidium generator (also bought used in China) I have all the equipment synchronized (frequency meter, oscilloscope, SSA etc.)

[noreply]

I don't know what version of GPSDO you bought

But "catching a gps fix" doesn't mean having a stable frequency. In such systems, GPS stabilizes the work of OCXO, while OCXO requires a longer warm-up for stable operation. 60 seconds is definitely not enough and the system has not stabilized for sure.

In such systems, phase noise at the output also plays an important role - but as I said, the quality of such a system depends on the design.

The best systems are based on Trimble Thunderbolt and Chinese ham BG7TLB. Both are sufficient for amateurs.

Personally, with the Trimble Thunderbolt + rubidium generator (also bought used in China) I have all the equipment synchronized (frequency meter, oscilloscope, SSA etc.)

Thanks for your feedback tomud - much appreciated.

Sorry, I did not give much information about my new GPSDO device - I was 'too excited' to check its signal - rather than talk about the device itself.

I did buy a BG7TLB - like you said this is one of the most popular (reasonably priced) units available.

My version was  2020-03-02, although the internal PCB had a more recent date 2020-04-06

I did not realize that there is already a thread on the BG7TLB GPSDO - so what I did is posted the details of my setup with photos on that thread - not to duplicate here.

The link to the thread is here ...
https://www.eevblog.com/forum/testgear/bg7tbl-gpsdo-master-reference/msg3143006/#msg3143006

You will be able to see close-up photos and the PCB top / bottom view.

My device had a CTX 970-2178-46 10.000MHZ OCXO

You are correct - the GPS locked very quickly (I must have good sky coverage in London) with supplied antenna - even through glass on window ledge.

The red led - ALM - I think this signifies that the OCXO has reached stable temperature and oscillator had been 'disciplined'? - takes less than 10 minutes to 'go off'.

I did however have the GPSDO 'on' for over 8 hours before turning off.

Correct me if wrong, but I think that during this time - the oscillator was disciplined (i did not note how long it took for the ALM led to go off when I FIRST powered-up the device) so when I powered - up just now - it took less than 10 min for the ALM to go 'off' - indicating that it should have good frequency stability.

I really don't know what revisions / changes in FW BG7TLB has made in the most recent version, but as an outside observation it seems to be working well and had relatively quick 'settle-down' period.

The real question is how good is the OCXO in the device - and how stable is it?

I guess the only way to find out is to have another frequency source - more accurate and calibrated - to reference this one to?

This is where we start going down the 'atomic clock' rabbit hole

In the past I could get a strong WWV 10MHz reference on my radio.

Assuming I can still receive this time standard transmission (not from Europe as far as I know) - it would be interesting to see if this radio signal could be used as an accurate reference?

I think that WWV uses a cesium clock - but the real question is if the signal / frequency stability that we 'see' after it goes through the demodulation within our radio receiver - is indeed accurate enough to to original cesium source?

Like I said - its all very interesting - and definitely 'rabbit hole' material 

Another - side project for me - to put on the list.

Hope the above testing / findings are useful to others who are thinking or have already purchased a GPSDO device.

[Emo]

Follow up on cross flash

There is no such thing as coincidence.
So there has been a change in hardware/assembly

[Elasia]

Follow up on cross flash

There is no such thing as coincidence.
So there has been a change in hardware/assembly

I suspected as much

I'd suggest either Superbat https://www.rfsupplier.com/ or http://renhotec.com/ to make a custom length one

https://www.rfsupplier.com/male-to-male-right-angle-sma-custom-rf-cable-assembly-for-rg316-cable_p6049.html

Or make your own using quality parts.. this is the one place you do want a good interconnect, also you should get a torque spanner

[tomud]

Follow up on cross flash

There is no such thing as coincidence.
So there has been a change in hardware/assembly

Where did you buy your spectrum analyzer?

I bought in May in Batronix, I do not know the production date, but I have a calibration date Feb-18-2020 and all the cables were installed...

So, theoretically spectrum analyzers from February and earlier do not have this problem...

Another theory is...  techneut who also had a problem with the lack of a cable is also from the Netherlands ( https://www.eevblog.com/forum/testgear/siglent-ssa3000x-spectrum-analyzers/msg3088322/#msg3088322  ), maybe you bought it from the same distributor and the problem concerns a specific series.

[Towlerar]

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. (if you don't feel comfortable with linux commands ask somebody else to help)

EDIT Jun 27th:
ATTENTION: You MUST do a "sync" command before rebooting to flush any pending file operation.

I see FW V2.2.1.2.8 was released 7/24 by Siglent for the SVA1032. Anyone know if the telnet hack still works for this revision? I'm hoping to get my hands on a SSA3032X Plus soon.

[Elasia]

It's not really a hack on these, its an ads file that runs a packaged shell file and is how they do it across all their product just about so you can either use it to get a console up or go in via the hard port in the back

As far as the patch i'll look it over here in a bit.. first i've heard of it

[Elasia]

SVA

New Functionality:
• Update EMI option to a new EMI measurement mode
• Added more VNA calibration kits with N/3.5mm type connectors to 4.5G/9.0GHz
• Added *.CSA file type to store instrument setup and calibration data in one file for easy recall and use of a saved state.
• Update user calibration data format. CAUTION: User calibration data taken with previous firmware revisions will no longer be compatible with the instrument after upgrading to V2.8. You will have to store new user calibration files if you update the instrument.
• VNA Port 1 output power and Port2 input Att adjustable
 
Improvements:
 • Improve TG output harmonic performance
• Update Help file
 
Solved Issues:
• Fix some ADC overload warning
• Fix Ch Power calculation bug in small span
 

SSA

New Functionality:
• Update EMI option to a new EMI measurement mode
 
Improvements:
• Improve TG output harmonic performance
• Update Help file
 
Solved Issues:
• Fix ADC overload warning
• Fix Ch Power calculation bug in small span

----

Great to see EMI improved!

[Elasia]

Post cross flash firmware update using SVA .7 firmware to stock SVA .8 firmware file confirmed working, have at it

[tautech]

New firmware for SSA3000X Plus models.

Version  V2.2.1.2.8
16.8 MB

https://int.siglent.com/upload_file/zip/firmware/Spectrum_analyzer/SSA3000XP_2.2.1.2.8_EN.zip

Release notes as below:

SSA

New Functionality:
• Update EMI option to a new EMI measurement mode
 
Improvements:
• Improve TG output harmonic performance
• Update Help file
 
Solved Issues:
• Fix ADC overload warning
• Fix Ch Power calculation bug in small span

[noreply]

For all who have FOLLOWED the SSA to SVA crossflash to realize a 'true' SVA device

- here is yet another 'posted' test of a regular SVA upgrade process
- nothing to 'patch'
- just perform the upgrade as though your device started its life as a SVA

Before you 'jump-in' do a full backup - a good practice.

[tomud]

Firmware upgrade done and it works fine 

[tubularnut]

Post cross flash firmware update using SVA .7 firmware to stock SVA .8 firmware file confirmed working, have at it

Updated the same, no problems 

[tv84]

Always do a FULL BACKUP of your equipment before crossflashing!

Script to make a NAND dump + RAM dump + firmdata0 backup on a SSA3000X+ is attached.  (Tested OK.)

Use a pendisk >= 1 GBytes.  It can take up to 20 minutes.

Edit: Now it should reboot after backup is complete.

[tv84]

Crossflashing to SVA1032X final step

For all those that want to get an official "SVA1032X" designation after having crossflashed their SSA3000X+, the only thing that you need to do is replace the firmdata0/NSP_trends_config_info.xml file with the attached one.

Reboot and voilá.

PS: This is a stock NSP_trends_config_info.xml taken from an "original" SVA1032X.

[Elasia]

I named mine as the TurboEncabulator_5000

[tautech]

SVA

New Functionality:
• Update EMI option to a new EMI measurement mode


SSA

New Functionality:
• Update EMI option to a new EMI measurement mode
 

A new SSAX Plus/SVA and SSAX-R User manual version E02A with chapter 7 for this new EMI mode on P134.
https://int.siglent.com/u_file/document/SSA_XP_SVA_UserManual_UG0703P_E02A.pdf

[Elasia]

EMI Chapter 7 on 134 Mr Typo

[maximevince]

Crossflashing to SVA1032X final step

For all those that want to get an official "SVA1032X" designation after having crossflashed their SSA3000X+, the only thing that you need to do is replace the firmdata0/NSP_trends_config_info.xml file with the attached one.

Reboot and voilá.

PS: This is a stock NSP_trends_config_info.xml taken from an "original" SVA1032X.

Hi tv84, thanks for the awesome work on this SSA/SVA crossflash!

* However, I suspect your attachment is wrong, it seems to be an .sh file (with the dumpnand script) instead of the NSP_trends_config_info.xml

* Also, I have crossflashed my device (to the latest 2.2.1.2., but still have XXXXXXXXXXXXXX as serial number / SN.
What's the way to do this right, while retaining all licenses as "Permanent" ?

Screenshot of my current system info is attached.

[maximevince]

Since it took a while to find all the relevant posts and files to get this conversion done, I am doing a small recap here:

None of this is by any means to my credit, I am just summarizing all the hard work of others here: 

SSA-3021X Plus -> SVA conversion

0. I did this on an untouched SSA-3021X Plus.
1. Get Telnet access to your device. Use tv84's SSA3000X_Plus_telnet.ADS for this (attached). Write that file to a FAT32 USB stick. On your SSA go to System -> System Info -> Firmware Update -> Select the ADS file. The "upgrade" (which is not a real upgrade, but a script that will run) will start, but never complete.
This should now work:
$ telnet <ssa-ip-here> 10101

-> Now you can follow the procedure outlined by tv84 in post #963 (https://www.eevblog.com/forum/testgear/siglent-ssa3000x-spectrum-analyzers/msg3084766/#msg3084766), which consists of these steps:

1. Telnet into the equipment

2. Remount filesystem as read-write:
$ mount -o remount,rw /usr/bin/siglent

3. Rename ecomb_p to ecomb
mv /usr/bin/siglent/ecomb_p /usr/bin/siglent/ecomb

4. in file /usr/bin/siglent/startup_app.sh change the line
   /usr/bin/siglent/ecomb_p &
   to
   /usr/bin/siglent/ecomb &
E.g. use "vi":
vi /usr/bin/siglent/startup_app.sh

To lower the risk you can do an additional step here which is to activate the telnet daemon in the startup script.
For example, add this line before the ecomb line:
/sbin/telnetd -l /bin/sh -p 10101 &

5. 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>
Again, use vi:
vi /usr/bin/siglent/config/NSP_config_upgrade_info.xml

5. Reboot:
$ sync && 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)
   I used 2.2.1.2.8, which also works. Get the FW image for the Siglent website, and perform System -> System Info -> Firmware Update again.
   Note that after this upgade, the telnet daemon is not being started anymore, since the startup script is overwritten by the firmware.
   Use the SVA1032X_telnet.ADS (also attached) to gain telnet access again. (You can add the telnet daemon to the /usr/bin/siglent/startup_app.sh again, now)

7. After having flashed your first SVA stock FW, the SSA has become a "true" SVA.


As always: do it at your own risk. (if you don't feel comfortable with linux commands ask somebody else to help)

[maximevince]

and part two:

Full permanent license unlock on your SSA-3021X Plus converted to SVA-1032X


Note that after this hack, your Serial is XXXXXXXXXX, and your device will be in "pro mode" (so without a license specific to your device serial number).
This will show more options than your HW will actually allow (such as real-time SA).
All unlocked options/licenses are permanent.


1. If you do not already have telnet access, use the SVA1032X_telnet.ADS file on USB stick, run firmware upgrade using System -> System Info -> Firmware Upgrade. The upgrade will "hang", but you'll have telnet access.
2. telnet to your SSA/SVA on port 10101.  No password required.
    $ telnet <ssa-ip-address> 10101

3. make (another) backup (it's adviced to also use tv84's dumpnand as well):
    $ cd /   
    $ cp -R /usr/bin/siglent/usr/backup /usr/bin/siglent/usr/mass_storage/U-disk0/SA-backup
    $ cp -R /usr/bin/siglent/firmdata0 /usr/bin/siglent/usr/mass_storage/U-disk0/SA-firmdata0

4. remount firmdata0 filesystem as rw:   
    $ mount -o remount,rw /usr/bin/siglent/firmdata0
   
5. Erase all existing licenses:
    $ cd /usr/bin/siglent/firmdata0/

- In NSP_sn_bandwidth.xml, erase the complete <license> .. </license> part.
    $ vi NSP_sn_bandwidth.xml
- Replace the contents of NSP_trends_config_info.xml with the one attached
    $ vi NSP_trends_config_info.xml

    $ mv nsp_data_b1 nsp_data_b1x   
    $ cd /usr/bin/siglent/usr/backup   
    $ mv nsp_data_b nsp_data_bx

6. Sync and reboot
    $ sync && reboot


This is enough to unlock all features!

If you want to take it further from here, to have the correct Serial number, you'll also need a way to generate the correct license info for your specific device's Serial + Host ID.
This can be done with some help from the forum, but the procedure is not public yet. 

In case you want to take that route:
1. Write the correct serial number back to your device, e.g. using SCPI command. I used pyVISA for this:

    import visa
    rm = visa.ResourceManager('@py')
    inst = rm.open_resource('TCPIP::<your-siglent-ip>')
    inst.write(":SRLN <your-serial-number>")
    print(inst.query("*IDN?"))

2. Reboot
3. Enter your serial-specific licenses using System -> System Info -> Load Option

[echo99]

If you want to take it further from here, to have the correct Serial number, you'll also need a way to generate the correct license info for your specific device's Serial + Host ID.
This can be done with some help from the forum, but the procedure is not public yet. 

Thanks for clarification. Starting to doubt myself after reading all the relevant threads 10 times over 

I also want to thank all the Members contributing to make this possible, especially tv84 

Crossflashing on my SSA3021x+ ordered from Batronix a few days ago (Callibrated date 2020-03-20) went smooth.. also no missing link here