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.
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.
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 equipment2. 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.
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 - 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 equipment2. 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.
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.
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=1Hmmm, 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
Don't feel too bad, your instructions would just confuse someone. Here is the startup_app.sh
startup_app.sh.txt
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
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
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
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.
Gentlemen, test please.
And thanks to tv84 no longer a unidentified (flying) object
And to show a hybrid SVA: