Just ordered a SDG1032X today... so much to read and learn!
Thanks.
I have no problem connecting to the AWG and I can issues the *IDN? command and get teh model and serial numbers, but it does not respond when I enter SCOPEID?.
Any suggestion?
Never mind. I figured out you have to enter the model number as SDG1000X, not SDG1032X.
All good now and reporting as and running as a SDG1062X!
So, in improving my SDG1032X to SDG1062X performance, I followed this procedure
1. Telnet on port 5024 to the device. Your telnet app should be setup for local echo.
2. Issue a MCBD? query. This will return your current licence key. Record this for later.
3. Issue a MD5_SRLN? query. This will return you serial number. Record this too.
4. Issue a MD5_PR? Query. This will return your model number (should be SDG1000X)
5. Update the python script (below) such that SCOPEID and SN are set to your serial number.
6. Run the script. It will return keys for a number of options. Make sure the key for 30M matches the key you recorded in step 2 above.
7. If your key and the 30M key match exactly then note the key for 60M. This is the one you will use.
8. Back at the telnet session issue the command MCBD 0123456789ABCDEF where 0123456789ABCDEF is whatever the python script returned for the 60M key.
9. Issue a *IDN? Command. It should return a string that now identifies your unit as a SDG1062X.
import hashlib
SCOPEID = '0123456789ABCD' # Set to your serial number
SN = '0123456789ABCD' # Also set to your serial number
Model = 'SDG1000X'
# 'SDG1000X', 'SDS1000X-E', 'SDS2000X-E', 'SDS2000X+', 'SDS5000X', 'ZODIAC-'
bwopt = ('25M', '30M', '40M', '50M', '60M', '70M', '100M', '150M', '200M', '250M', '300M', '350M', '500M', '750M', '1000M', 'MAX')
otheropt = ('AWG', 'WIFI', 'MSO', 'FLX', 'CFD', 'I2S', '1553', 'FG', '16LA')
hashkey = '5zao9lyua01pp7hjzm3orcq90mds63z6zi5kv7vmv3ih981vlwn06txnjdtas3u2wa8msx61i12ueh14t7kqwsfskg032nhyuy1d9vv2wm925rd18kih9xhkyilobbgy'
def gen(x):
h = hashlib.md5((
hashkey +
(Model+'\n').ljust(32, '\x00') +
opt.ljust(5, '\x00') +
2*(((SCOPEID if opt in bwopt else SN) + '\n').ljust(32, '\x00')) +
'\x00'*16).encode('ascii')
).digest()
key = ''
for b in h:
if (b <= 0x2F or b > 0x39) and (b <= 0x60 or b > 0x7A):
m = b % 0x24
b = m + (0x57 if m > 9 else 0x30)
if b == 0x30: b = 0x32
if b == 0x31: b = 0x33
if b == 0x6c: b = 0x6d
if b == 0x6f: b = 0x70
key += chr(b)
return key.upper()
for opt in bwopt:
print('{:5} {}'.format(opt, gen(SCOPEID)))
for opt in otheropt:
print('{:5} {}'.format(opt, gen(SN)))
I'm trying to "upgrade" my just acquired SDG1032X to SDG1062X using the above procedure to no avail. Everything seems to work OK until step 8: I telnet MCBD with the correct output for 60M from the script but when I do the next step 9 (*IDN?) it's still an SDG1032X:
Siglent Technologies,SDG1032X,SDG1XDEX6R----,1.01.01.33R3
Is this version incompatible with the hack? (HW Version 03-00-00-24-00)
I'm stuck!
Nevermind!... I figured out what the problem was: You have to supply the python code output with
lowercase letters! not uppercase as per the script.
Now running a SDG1062X
There seems to be an issue with the SDG1000X handling SCPI commands to enable SWEEP or BURST modes as described in the document
SDG Series Arbitrary Waveform Generator Programming Guide.
https://int.siglent.com/u_file/document/SDG_Programming%20Guide_PG02-E05B.pdfSpecifically, the command "C1:SWWV STATE,ON" does not turn on the sweep mode. See page 27 of the manual.
Similarly, the command "C1:BTWV STATE,ON" does not turn on the burst mode. See page 48 of the manual.
The listing below illustrates the issue. The commands and responses were handled by TestController. Some comments have been inserted inside [] marks.
[First, we query the AWG to verify the latest firmware version.]
*idn?
;; SDG1062X: Tx <*idn?>
;; SDG1062X: Rx <Siglent Technologies,SDG1062X,SDG1XCAX3R0000,1.01.01.33R3
>
;; Siglent Technologies,SDG1062X,SDG1XCAX3R0000,1.01.01.33R3
[Next, ask whether sweep is ON or OFF.]
C1:SWWV?
;; SDG1062X: Tx <C1:SWWV?>
;; SDG1062X: Rx <C1:SWWV STATE,OFF
>
;; C1:SWWV STATE,OFF
[It says sweep is OFF, so send a command to turn it ON.]
C1:SWWV STATE,ON
;; SDG1062X: Tx <C1:SWWV STATE,ON>
[Did that work? Sweep should be ON now. What does the AWG report?]
C1:SWWV?
;; SDG1062X: Tx <C1:SWWV?>
;; SDG1062X: Rx <C1:SWWV STATE,OFF
>
;; C1:SWWV STATE,OFF
[The sweep is still OFF. That is not expected behavior.]
And the same exercise for Burst gives the same results.
[First, we query the AWG to verify the latest firmware version.]
*idn?
;; SDG1062X: Tx <*idn?>
;; SDG1062X: Rx <Siglent Technologies,SDG1062X,SDG1XCAX3R0000,1.01.01.33R3
>
;; Siglent Technologies,SDG1062X,SDG1XCAX3R0000,1.01.01.33R3
[Next, ask whether burst is ON or OFF.]
C1:BTWV?
;; SDG1062X: Tx <C1:BTWV?>
;; SDG1062X: Rx <C1:BTWV STATE,OFF
>
;; C1:BTWV STATE,OFF
[It says burst is OFF, so send a command to turn it ON.]
C1:BTWV STATE,ON
;; SDG1062X: Tx <C1:BTWV STATE,ON>
[Did that work? Burst should be ON now. What does the AWG report?]
C1:BTWV?
;; SDG1062X: Tx <C1:BTWV?>
;; SDG1062X: Rx <C1:BTWV STATE,OFF
>
;; C1:BTWV STATE,OFF
[Burst is still OFF. That is not expected behavior.]
A fix will be required in the next firmware release. Perhaps this is not far off, since it has been about 18 months since 1.01.01.33R3 came out.
I confirn that the python method above works. Copy-paste from python output to SCPI telnet without issues.
Turned the device into a 1062X, works, no problem.
May God give the guy who leaked the hashkey one thousand years of happiness!
A fix will be required in the next firmware release. Perhaps this is not far off, since it has been about 18 months since 1.01.01.33R3 came out.
Hopefully they will correct the external clock issue too. <crossed fingers>
This problem was reported right after the LAST firmware update was released, close to eighteen months ago!
WoD
New version available:
EasywaveX -1.1.0.23R8Looks like there's some new things. Digital Wave catched my eye.
Looks very interesting. Thanks for the info.
New version available: EasywaveX -1.1.0.23R8
Looks like there's some new things. Digital Wave catched my eye.
The SDG7000A has digital channels...
And there's an SDG8000A listed on the new version of the EasyWave that I assume is yet to be released since I can't find it on the web
New version available [for EasywaveX]...
Speaking of new versions, we are overdue for a new version of SDG1000X firmware, which seems to be running well behind the releases for the other generators in the family (like the SDG2000X, for example).
@tautech: Rob, are you picking up any rumblings from the factory about new firmware for the SDG1000X?
HI , May somebody able to help,
I was switch on the SDG1032(62) and the "SIGLENT" screen remains, not boot correctly, is somebody has a firmware what is bootable, or any other methode to live this again? Thanks
User
tautech is often very helpful in such situations, he might turn up here soon, or send him a message.
Speaking of new versions, we are overdue for a new version of SDG1000X firmware, which seems to be running well behind the releases for the other generators in the family (like the SDG2000X, for example).
Any special reason to wait for such an update ? Any expected feature or bug fixing ?
Speaking of new versions, we are overdue for a new version of SDG1000X firmware, which seems to be running well behind the releases for the other generators in the family (like the SDG2000X, for example).
Any special reason to wait for such an update ? Any expected feature or bug fixing ?
For those who might be new to this thread, here is a list of some of the outstanding bugs reported here for the SDG1000X that need to be addressed in the next firmware release. The "reply number" shown in parentheses identifies the post in this thread where the issue was discussed.
- SCPI commands to turn on SWEEP or BURST don't work. (#303)
- The SDG1000X won't sync correctly to an external 10 MHz reference. (#240, #272, #286, #298)
- SWEEP mode has a bug in start/stop settings. (#199)
- The display of LOAD R has inadequate resolution. (#185)
- Low-level amplitude settings of a modulated wave are incorrect. (#184)
There may be some other issues; these are just some that came to mind.
HI , May somebody able to help,
I was switch on the SDG1032(62) and the "SIGLENT" screen remains, not boot correctly, is somebody has a firmware what is bootable, or any other methode to live this again? Thanks
You have a PM, please reply via email.
HI , May somebody able to help,
I was switch on the SDG1032(62) and the "SIGLENT" screen remains, not boot correctly, is somebody has a firmware what is bootable, or any other methode to live this again? Thanks
You have a PM, please reply via email.
Thanks email sent
Please see further PM with typo correction.....I need a holiday !
Having noticed a discussion of issues with frequency sweep behavior in the 2042X thread, I thought it would be interesting to see if the same behavior exists in the 1062X.
Short answer -- the amplitude step that is present in the 2042X is not present in the 1062X. That is the good news.
The less good news is that the lowest couple of octaves of the 1062X sweep have frequency errors.
A test was set up as follows:
- A table was created in Excel to generate the ideal frequencies at 100 points of a log sweep from 1 kHz to 10 MHz. These points were indexed by time, assuming a 100 msec sweep time.
- The SDG1062X was set up to sweep accordingly. Its trigger out was used to trigger the scope.
- The reference AWG, a Keysight 33521B, was set up with the same parameters, and triggered by the SDG1062X in order to display a time-synchronized sweep for comparison.
- The scope's zoom, delay, and measurement functions were used to take snapshots of the AWG outputs at selected points corresponding to the Excel sample points.
- The results of swept frequency versus time were plotted against the ideal curve.
The first chart shows the Siglent response. Anomalies are seen in the first 10-12 msec of the sweep.
The second chart shows the reference (Keysight) response. This matches the expected curve pretty closely.
The third chart shows a comparison of both AWGs versus the ideal.
Discussion:
During the first 12 -15 msec of the 100 msec sweep the frequency remains at roughly the starting frequency. Thereafter, it snaps to the correct value and continues the sweep without further issue. The changeover can be seen in the scope image at about 12 msec into the sweep.
This behavior suggests an issue with the SDG1000X sweep firmware. The AWG is running 1.01.01.33R1B6.
This is very interesting. Thanks for sharing your findings.
What happens at lower frequencies like 20Hz? or 100Hz?
What happens at higher sweep times? For example if you set the sweep to 10 seconds, do you still get 15ms error or the error is more in the hundreds ms region?
Thank you for the heads-up.
I can confirm this behavior also for "improved" SDG1032X(1.01.01.33R3).
Additional testing showed that the generator is able to handle the log sweep for 3 decades maximum. If it is more, then this phenomenon start and the time of keeping the lowest frequency seems to correlate with the range over these 3 decades.
Siglent released new Firmware for the SDG1032X:
Hopefully the external clock issue IS fixed. It's been a two year wait.
Anyone try it yet? The long wait for a fix annoyed me enough to stop using mine even though there was a workaround. It's hanging from the ceiling in the shop. It's gotten a lot of inquiries. I thought about using it as a Piñata.
WoD
Firmware 1.01.01.33R8 has fixed a number of bugs. Nice work.
Unfortunately, a new bug has been introduced. When “Mod” is enabled on a square wave, if the modulation is FM then the square wave rise time is slowed dramatically. For example, at 1 MHz carrier, rise time goes from < 5 ns to >99 ns.
This is shown in the scope capture image below:
- Channel 1 is an unmodulated square wave from one channel of the SDG1062X. It has an indicated rise time of 4.0 ns.
- Channel 2 is a square wave of the same frequency, but with FM modulation engaged, using the parameters shown on screen. This comes from the other channel of the SDG1062X. Note that the rise time has slowed to 99.2 ns.
This only appears on FM modulation of a square wave; other modulation types and/or other waveforms act as expected.