I'm following their example here:
https://siglentna.com/application-note/programming-example-sdg-waveform-creation-with-python-and-sockets-no-visa/
Running this example directly seems to have the same problem.
I get the expected output initially, but as soon as I introduce a 0x0A anywhere in wave_points, then the written wave gets truncated.
For example:
wave_points = [0x0000, 0x0000, 0x0000, 0x0000, 0x0a40, 0x0040, 0x0040, 0x0040]
wave1.bin then contains (hex): 00 00 00 00 00 00 00 00 0a40 00 40 00 40 00 40
data.decode('latin1') on line 75 doesn't actually do much here - merely transform the bytes into a string. The 0x0a just becomes a '\n'.
Have I missed something obvious?Tim, I'll make contact by email with some stuff.
I'm following their example here:
https://siglentna.com/application-note/programming-example-sdg-waveform-creation-with-python-and-sockets-no-visa/
Running this example directly seems to have the same problem.
I get the expected output initially, but as soon as I introduce a 0x0A anywhere in wave_points, then the written wave gets truncated.
For example:
wave_points = [0x0000, 0x0000, 0x0000, 0x0000, 0x0a40, 0x0040, 0x0040, 0x0040]
wave1.bin then contains (hex): 00 00 00 00 00 00 00 00 0a40 00 40 00 40 00 40
data.decode('latin1') on line 75 doesn't actually do much here - merely transform the bytes into a string. The 0x0a just becomes a '\n'.
Have I missed something obvious?Tim, I'll make contact by email with some stuff.
I'm having the same issue with arbitrary waveforms including 0x0a ("\n") over the TCP socket interface. Let's get in touch?
I'm following their example here:
https://siglentna.com/application-note/programming-example-sdg-waveform-creation-with-python-and-sockets-no-visa/
Running this example directly seems to have the same problem.
I get the expected output initially, but as soon as I introduce a 0x0A anywhere in wave_points, then the written wave gets truncated.
For example:
wave_points = [0x0000, 0x0000, 0x0000, 0x0000, 0x0a40, 0x0040, 0x0040, 0x0040]
wave1.bin then contains (hex): 00 00 00 00 00 00 00 00 0a40 00 40 00 40 00 40
data.decode('latin1') on line 75 doesn't actually do much here - merely transform the bytes into a string. The 0x0a just becomes a '\n'.
Have I missed something obvious?Tim, I'll make contact by email with some stuff.
I'm having the same issue with arbitrary waveforms including 0x0a ("\n") over the TCP socket interface. Let's get in touch?This was the feedback from HQ Tech support:
I think the customer uses the Socket communication. Is it right?
The '0A' is the terminating symbol. When the data inlcude '0A', it will stop the transmission.
I advise to use the usbtmc or tcpip by visa at the moment.
We will try to solve this problem.
Has anyone had success using usbtmc mode in pyvisa? If so, what version and configuration are you using? I see that binary writes to a USB:INST session never terminate as though pyvisa isn't asserting termination correctly
Hello guys. Not sure if this issue was raised before, if so, sorry about duplicate. If not, can someone throw an opinion , please ?
Unlocked successfully the SDG to 120 MHz, works, but the signal level starts to drop from 80 MHz, falling to half at 120 MHz. I have the HW revision 02-xxxx, not the 05-xxxx, brand new, under warranty, etc., freshly imported through the Netherlands trade point. Not sure why it isn't the 05 version though.
I did verify the signal levels using different cables, one that should work up to the GHz ranges. Tested with the unlocked SDS and an older analog Hitachi scope. May not be mV accurate, but still the same proportianal decrease in signal level, from 80 to 120 MHz, the signal gradually drops to half.
Oscilloscope bandwidth is defined as the frequency at which the amplitude of the observed signal drops by -3 dB (or drops to 70.7% of its actual value) as we increase the test signal’s frequency as plotted on the amplitude-frequency characteristic curve (Figure 1).
I did verify the signal levels using different cables, one that should work up to the GHz ranges. Tested with the unlocked SDS and an older analog Hitachi scope. May not be mV accurate, but still the same proportianal decrease in signal level, from 80 to 120 MHz, the signal gradually drops to half.
Hello guys.
Unlocked successfully the SDG to 120 MHz, works, but the signal level starts to drop from 80 MHz, falling to half at 120 MHz. I have the HW revision 02-xxxx, not the 05-xxxx, brand new, under warranty, etc., freshly imported through the Netherlands trade point. Not sure why it isn't the 05 version though.
I did verify the signal levels using different cables, one that should work up to the GHz ranges. Tested with the unlocked SDS and an older analog Hitachi scope. May not be mV accurate, but still the same proportianal decrease in signal level, from 80 to 120 MHz, the signal gradually drops to half.
What happens if you set the output voltage to 1V peak to peak?
It would be nice if others running the latest firmware version (V2.01.01.37R3 released past month) could check for the frequency counter bug and post their hardware version and results, so we can report it to siglent for them to fix it.
To check for the bug, just run the frequency counter:Code: [Select]Utility -> Counter -> State "ON"
The device should start to feel laggy/unresponsive as the time passes and once "num" reaches between 700-1200 counts the device freezes.
To speed up the process you can enable fast counting under setup:Code: [Select]Utility -> Counter -> Setup -> Type "Fast"
Just like firmware V2.01.01.37R3, V2.01.01.37R6 fails to install on my SDG2042X (hardware version 02-01-00-40-00).
Are they only for the newest hardware versions?