Siglent SSA3000X and SSA3000X-Plus Spectrum Analyzers

[Elasia]

Is the hardware identical?

Yes...

SSA3021X Plus, SSA3032X Plus, SVA1032X this is the same hardware, only restrictions have been introduced using the firmware.

https://www.siglenteu.com/spectrum-analyzers/ssa3000x-plus/
https://www.siglenteu.com/spectrum-analyzers/sva1000x-spectrum-vector-analyzer/

Yep... the main difference is the executable and factory calibration files

A physical difference spotted in the wild is the lacking of the extra sma cable to interconnect the boards for SVA use... thats rather trival to fix.. out of everyone that has done this i believe only one forum member ran into this so far

[tomud]

A physical difference spotted in the wild is the lacking of the extra sma cable to interconnect the boards for SVA use... thats rather trival to fix.. out of everyone that has done this i believe only one forum member ran into this so far

As it is sometimes in Chinese equipment, it can only be the usual case that in the factory someone forgot to install the cable and in the case of SSA in the tests there was no problem.

Available for VNA anyway, calibration should be done every time we change wires and connectors - so here is no problem. Although I'm waiting for some SVA holder to do a nand memory dump and make it available for comparison.

[noreply]

Been testing some RF amplifiers – and came across something interesting …

Is there a ‘normalization’ noise floor??


What do I mean by the above term?


Well, when you normalize the signal path when using a TG – you expect any ‘anomalies’ to be eliminated – and the resultant response should be FLAT (or as close to flat as possible)


When using a default SSA and we simply connect the TG output to the RF input AND normalize – we get a relatively FLAT response – with NO NOISE – something you expect after naomalization.


I have a relatively unusual set-up

– with 50dB attenuation in my signal path (unfortunately required when working with high power RF).


When performing a default TG normalization

– with my 50dB attenuator in the signal path

– I got LOTS OF NOISE in my normalization – not a straight ‘flat’ response as one would expect.



This made me wonder is there is a ‘normalization’ noise floor??


I guess when doing a normalization – you need some raw numerical data to perform the normalization math function.

When performing math functions in software

– you need to work with either interges or floating point numbers.


If these ‘numbers’ are extremely small

– because of the massive attenuation in the signal path

– then there might be a problem if extended numerical precision is not used in the math calculations.


Remember I have the following attenuation in the signal path …

TG default setting -20dBm

RF attenuation set at -20 db

My own attenuation - 50db

So I have -70dB of pure attenuation and a small signal from the TG (-20dBm)


This means that the ‘data’ we are trying to normalize

– may not be possible to fully quantize

– because the SSA simply cannot collect sufficiently accurate (enough precision) information to be successfully used in the normalization math function.


Anyway – I hope you are able to see what I mean by normalization ‘noise floor’


Personally I never came across such a term

– and one would expect the signal to be normalized – no matter what.


If the data to be normalized is so ‘small’

(due to the high attenuation in the signal path)

then rather to work with extremely small numbers which the software cannot handle

– why not simply make it ‘ideal’ and zero the result anyway

– since we have such a high attenuation

– instead of trying to calculate and result is massive noise floor??



What do you think?

Is there such a thing as a normalization noise floor?

Or is today simply a start of a bad day for me – and I am doing something stupid 



I have attached some screen shots

Screen shot 1

TG and RF both at their default values – with my 50dB attenuator in the signal path.
Here you can clearly see the normalization noise – it is not a flat response!


Screen shot 2   

Both TG and RF (built-in) attenuation set at 0 (zero) – and still the 50dB attenuator in the signal path – after normalization – got ‘flat’ response – as expected – with little or no visual noise.


Screen Shot 3   

Here I removed the -20dB build-in attenuation and set the TG to -10dBm instead of the default -20dBm. I still have the 50 dB attenuation in the signal path. It can be seen clearly that the ‘noise’ level in the normalized result is still there but much smaller – confirming that we are heading in the correct direction by reducing the overall attenuation in the signal path.

[1design]

I would say you are discussing dynamic range, that is the difference between your source power and your noise floor. The term normalization noise floor is not a thing.

The closer you get to your noise floor, the more the noise floor causes errors and introduces uncertainty(noise) into your measurement.

Reduce your RBW when doing the measurement, lower the SA reference level and increase your TG power. All of these changes will increase your dynamic range by lowering your noise floor and increasing your source power. This should minimize the noise you see in your measurement.

[noreply]

The term normalization noise floor is not a thing.

Thank for your feedback  

Yeah – I suspected that the term ‘normalization noise floor’ is not a thing 


My gut feeling was that I must have somehow hit the SSA noise floor

– because of the massive attenuation in the signal path (-70dB)

– BUT because I was NORMALIZING the output

– I expected the ‘noise’ to be normalized i.e. ‘flattened’

 
Obviously, this is not how the normalization function works

– it simply cannot process the noise
– in effect zero it
– as its most likely outside the SSA's numerical limits??


After thinking about it

– my next step

– like you rightfully suggested

– was to try to reduce the SSA noise level in the signal path by changing the VBW to 1Hz

– giving me a VBW/RBW of 0.001

With this I was able to plot a relatively noise free response for all of the attenuators in the signal path

– see figure 1 (Normalized)


Unfortunately because I used RBW of 100KHz – my sweep time was a massive 460.928 sec 


I changed the RBW to 1MHz and the VBW to 10Hz (maintaining the VBW/RBW of 0.001) , this gave me a much faster sweep time of 46.285 sec, whilst generating a noise free response.

- see Figure 2 ( Before Normalization)


Fortunately the SSA still has a sufficiently low noise floor

– if you are prepared to slow down the sweep time by a massive amount

– to produce good ‘clean’ results even with a > 70dB attenuation in the signal path 


To safeguard myself from future problems with high attenuation

– I am keen to get a decent RF amplifier

– which has a fairly flat response 50-500MHz with at least 30dB gain

– to put the TG signal through for some positive gain

– something like a ZHL-5W (Mini Circuits)

– but when checking the $$ - OUCH 

 They are not cheap!


I need to look around for something more affordable. (any suggestions welcome    )


Be warned

– the cost of the SSA is only the beginning, if you are planning to make some meaningful ‘real life’ measurements

– prepare to spend some more $$   

[tautech]

....................

Fortunately the SSA still has a sufficiently low noise floor

– if you are prepared to slow down the sweep time by a massive amount

..........................

Normal ^^^ SA behavior over a full Span sweep !
Typically we narrow the sweep to a Span of interest when using low RBW/VBW or engage some averaging.

Even VNA mode benefits from a reduced Span........why have info returned from outside you frequencies of interest ? 

There are several tools in the box to get good results and once we become familiar with the instrument we might use different ways to get similar results.

[Precut]

yeah i got smoked, stuck at boot screen and also the prior system key trick doesnt work

I'll have to console it later and see what its doing now

I came across a situation similar to yours after crossflashing a ssa3021x+ to sva... 
How can you recover the bricked device? 

[tv84]

I came across a situation similar to yours after crossflashing a ssa3021x+ to sva... 
How can you recover the bricked device? 

What did you do?

Now, you have to open it and access the UART port and check its boot log to see where it stands.

[Elasia]

yeah i got smoked, stuck at boot screen and also the prior system key trick doesnt work

I'll have to console it later and see what its doing now

I came across a situation similar to yours after crossflashing a ssa3021x+ to sva... 
How can you recover the bricked device? 

You will need to open the back shell and expose the uart pins

Once direct connected to the console, login and look in your /usr/bin/siglent folder and see if you got both executables

Also do a df -k and see if all your drive space was consumed

If so then delete them and rerun the contents of the ads file manually

thats the jist of it

[Precut]

I came across a situation similar to yours after crossflashing a ssa3021x+ to sva... 
How can you recover the bricked device? 

What did you do?

Now, you have to open it and access the UART port and check its boot log to see where it stands.

I followed the steps you provided in post #963 and crossflashed my SSA with SVA FW (SVA1032X_2.2.1.2.5_EN). These steps successfully unlocked all options but failed to convert it into SVA or "SSA3032X Plus". Also, it's no longer accessible via telnet after crossflashing.

I tried crossflashing it back to SSA through the Firmware Update menu but did so without changing the product_code back to 11405... with no luck, nothing was changed except that all the options became trial licences. After a few round of soft booting, it even bricked... 

[Precut]

yeah i got smoked, stuck at boot screen and also the prior system key trick doesnt work

I'll have to console it later and see what its doing now

I came across a situation similar to yours after crossflashing a ssa3021x+ to sva... 
How can you recover the bricked device? 

You will need to open the back shell and expose the uart pins

Once direct connected to the console, login and look in your /usr/bin/siglent folder and see if you got both executables

Also do a df -k and see if all your drive space was consumed

If so then delete them and rerun the contents of the ads file manually

thats the jist of it

Which uart pins to connect?

[Elasia]

Scope decodes at 115200, 8N1

You can make up a 4 pin 0.1 header with the following pinout

GND RX TX PWR

You only need the first three, ignore power

[noreply]

Is there a way to display dB 'power gain' on the Y axis instead of dBm ?

In the Amplitude menu - you can set display units - but NO dB setting??

I may be missing something here   

and yes , dB is the preferred units for measuring power gain

- many of my specification sheets always use dB as a measure of power gain.

As an example - the spec sheet for an NXP MRF101AN - shows  gain as 21.2 dB

Is there a way to display this when doing a sweep within a span of , say 25Mhz?

So you will be able to see the max power gain at a 'peek' marker within this range.

I know you can always convert the units - but it would be nice to have these on the screen natively 

[noreply]

Help me PLEASE

I am having serious problems in trying to set-up my SSA’s display parameters …

Here is what I am trying to do …

Measure various high power RF amplifier gain vs. frequency response(s) – typically above 100W but less than 250W – hence the high attenuation in the signal path

I have set the SSA’s internal attenuation to the default -20dBm

I also have an additional 50dB in the signal path – so TOTAL attenuation of the signal is 70dB


First problem for me

– SSA displays gain as dBm
– the attenuation outside the SSA is 50dB
– that’s reducing the signal by 100,000 times
– is it correct to still interpret this as 50 dBm
– I guess the answer is YES
– since the dB part is correct
– but we are looking at ‘power’ so the ‘m’ ??



Correct me if I’m wrong (I think I am wrong in my interpretation)

– but all of the ‘internal attenuation’ settings in the SSA are automatically taken into account when the SSA displays the resultant ‘dBm’ value at the marker for a given frequency??

Is this correct??



What I am trying to do is to have the SSA display the resultant ‘dBm’ value it sees at the marker – taking into account ALL of my attenuation in the signal path – this includes the additional 50dB which sits ‘outside’ the SSA which is in the signal path.

What do I need to do to achieve the above??

Is there a way to configure the SSA to achiveve the above??

If so - how ??


To explain once again with additional detail ...

I have dumped some plots of a RF amplifier


Plot 1

This shows the gain vs. frequency response of the RF amplifier – with marker 1 at the peak gain (zoomed-in).
Here we can see that the amplifier has the peak gain at approx. 17Mz

The SSA shows that M1 is 17.066667MHz 27.65 dBm

I have set the display line to show 0 dBM

I have also set the Offset to be 50dB
– my understanding
– to move the graph (the 0 dBm line) to be roughly in the centre of the display

Now here is the question –
 
The plot shows the default -20 dBm as the Att value

The plot also shows 27.65 dBm as the Marker 1 value

But, the SSA does not know that I have an additional 50 dB in the signal path – because I have not ‘told it about the additional attenuation’

– thus the displayed 27.65dBm would need to have an additional 50 dB added ( the value which was attenuated )
– giving a value of 77.65 dBm??

I cannot believe this is correct as there is no way the amplifier will have this much gain!

So, here is my confusion …

The displayed 27.65 dBm must have -20 dBm removed (the built-in attenuation) giving a true value of 7.65 dBm

BUT because there was an EXTERNAL attenuation of 50dB

– then the REAL true value of the gain at Marker 1 is 50 dB greater than 7.65 dBm – giving a value of 57.65 dBm


Is this correct??


Plot 2

This is the full span sweep of the RF amplifier
– it drops off very quickly
– it’s VERY non linier!

Plot 3

Full span plot with RF Amplifier ‘powered off’
– so can see the rough noise floor of the SSA with the RF Amplifier still in the signal loop

[seronday]

Correct me if I’m wrong (I think I am wrong in my interpretation)

– but all of the ‘internal attenuation’ settings in the SSA are automatically taken into account when the SSA displays the resultant ‘dBm’ value at the marker for a given frequency??

Is this correct??

The SSA does take all internal attenuation and gain into account automatically so the value shown at the marker will be correct.
You have told the SSA about the external attenuation when you use the Reference Offset.
If there was an external pre-amp in use, the Reference Offset would need to be a negative value.

What input level is being applied to the RF amp ?
Would I be correct in assuming that the RF amp is being driven by the SSA tracking generator ?
If so, then the gain of the RF amp will be the difference between the TG level and RF amp output level as shown on the SSA screen.

First problem for me

– SSA displays gain as dBm
– the attenuation outside the SSA is 50dB
– that’s reducing the signal by 100,000 times
– is it correct to still interpret this as 50 dBm
– I guess the answer is YES
– since the dB part is correct
– but we are looking at ‘power’ so the ‘m’ ??

The dB scale is used to compare the relative signal levels between to points in a circuit.   There is no absolute value.
You can use the dB scale to measure absolute values if you first define a reference level and a reference impedance.

When using dBm, the reference level is 1mW and in the case of the SSA, the reference impedance will be 50 ohms.
So 0dBm will be 1mW into 50 ohms.

Hopefully this has not confused things even more for you.

Regards.

[Precut]

Here is the boot log, any idea? Many thanks.



U-Boot 2014.07-svn32893 (Jul 23 2018 - 14:42:02)

Board:  Xilinx Zynq
I2C:   ready
DRAM:  ECC disabled 128 MiB
NAND:  256 MiB
MMC:   zynq_sdhci: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
int board_late_init(void)+++++
int board_late_init(void)-----
Net:   Gem.e000b000
Hit any key to stop autoboot:  0
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
USB1:   ULPI request timed out
zynq ULPI viewport init failed
lowlevel init failed
       scanning usb for storage devices... 0 Storage Device(s) found
Copying Linux from USB to RAM...
** Bad device usb 0 **
** Bad device usb 0 **
Copying Linux from NAND flash to RAM...

NAND read: device 0 offset 0x780000, size 0x400000
 4194304 bytes read: OK

NAND read: device 0 offset 0xb80000, size 0x80000
 524288 bytes read: OK
## Booting kernel from Legacy Image at 02080000 ...
   Image Name:   Linux-3.19.2-omg-xilinx-svn35686
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3121840 Bytes = 3 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!
zynq-uboot>

[Elasia]

Eww.. thats not pretty, you nuked your os partition 

I never had to get into a deep restore on it yet..

[Precut]

Get the following boot info when booting it with a usb stick (with files or empty).  I tried to crossflash it with ssa FW from sva fw. Obviously, it still looks for the files associated with sva fw instead of those coming with ssa fw. 


U-Boot 2014.07-svn32893 (Jul 23 2018 - 14:42:02)

Board:  Xilinx Zynq
I2C:   ready
DRAM:  ECC disabled 128 MiB
NAND:  256 MiB
MMC:   zynq_sdhci: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
int board_late_init(void)+++++
int board_late_init(void)-----
Net:   Gem.e000b000
Hit any key to stop autoboot:  0
(Re)start USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
USB1:   ULPI request timed out
zynq ULPI viewport init failed
lowlevel init failed
       scanning usb for storage devices... 1 Storage Device(s) found
Copying Linux from USB to RAM...
reading boot_uImage
** Unable to read file boot_uImage **
reading sva1000x_udiskEnv.txt
** Unable to read file sva1000x_udiskEnv.txt **
Copying Linux from NAND flash to RAM...

NAND read: device 0 offset 0x780000, size 0x400000
 4194304 bytes read: OK

NAND read: device 0 offset 0xb80000, size 0x80000
 524288 bytes read: OK
## Booting kernel from Legacy Image at 02080000 ...
   Image Name:   Linux-3.19.2-omg-xilinx-svn35686
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3121840 Bytes = 3 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!
zynq-uboot>

[Elasia]

I've surmised its possible to make a boot stick with whats around but never went into that, tv84 might be able to help and see if you can at least get a kernel loaded and reflash your backup in, assuming you have backup images

[tv84]

I've surmised its possible to make a boot stick with whats around but never went into that, tv84 might be able to help and see if you can at least get a kernel loaded and reflash your backup in, assuming you have backup images

My advice would be to do it interactively on the uboot prompt.

Nonetheless, I'm available to unpack and pack a package to reflash the necessary NAND part.

BUT, i won't be able to help in creating/testing the necessary scripts because that requires a good knowledge of the update scripts and a machine to do the hands-on experimentation.

[noreply]

Hopefully this has not confused things even more for you.

Regards.

Thanks ... you sure did clarify quite a few things 

I guess there are always some concepts which are hard to get your head around - especially when this is the first time in the driver's seat with a new SSA 

I’m about to pull the trigger on a RF signal generator ( either Siglent SSG3021x or Rigol DSG815 ) – if you have any insights – they would be most welcome 

[Precut]

I've surmised its possible to make a boot stick with whats around but never went into that, tv84 might be able to help and see if you can at least get a kernel loaded and reflash your backup in, assuming you have backup images

backup images... sadly, no. 

[Precut]

I've surmised its possible to make a boot stick with whats around but never went into that, tv84 might be able to help and see if you can at least get a kernel loaded and reflash your backup in, assuming you have backup images

My advice would be to do it interactively on the uboot prompt.

Nonetheless, I'm available to unpack and pack a package to reflash the necessary NAND part.

BUT, i won't be able to help in creating/testing the necessary scripts because that requires a good knowledge of the update scripts and a machine to do the hands-on experimentation.

>My advice would be to do it interactively on the uboot prompt.
Thanks for your advice. uboot prompt is currently the only way available to me to work with the device.

>Nonetheless, I'm available to unpack and pack a package to reflash the necessary NAND part. .
any hints on doing this step? require dealing with the FW .ads file? Many thanks.

>BUT, i won't be able to help in creating/testing the necessary scripts because that requires a good knowledge of the update scripts and a machine to do the hands-on experimentation..
I will give it a try, no idea concrete at the moment though. 

[noreply]

I've surmised its possible to make a boot stick with whats around but never went into that, tv84 might be able to help and see if you can at least get a kernel loaded and reflash your backup in, assuming you have backup images

backup images... sadly, no. 

If you are desperate - perhaps there is a way to share a NAND image from similar a device 

[tautech]

There is a recovery package coming  When IDK.