Products > Test Equipment
Siglent SDS1104X-E and SDS1204X-E: Bode plot with a non-Siglent AWG
awakephd:
I have just gotten a FeelTech FY6900-60M (running firmware version 1.5.4), and was eager to try connecting it to my SDS804X-HD scope using either of the methods discussed in this thread. I first tried the espBode route, making a simple adapter board to connect to the TTL power and serial connector on the back. I downloaded Knutselaar's code, as it seemed to be the most recent (and has a recent success) and uploaded it to an ESP-01 using the Arduino IDE with no problems. I then connected it to the FY6900. I am getting the 3.3v power out of my regulator, and the ESP-01 is connecting to my network. I can ping it with no problems. But the scope refuses to recognize it when I set up the wifi to connect to the ESP-01.
I tried using telnet to connect to the ESP-01. The connection appeared to be successful. However, I could not generate any response from the FY6900 regardless of the command I tried to send it. I am not at all confident that this approach would work in any case ... or should it?
So, I have just now tried the python sds1004x-bode program, the version by bateau020 that adds the ability to talk with the SDS804X. I'm running on Ubuntu 24.04.
I was able to start the program, and it appears to connect to the FY6900, or thinks it does ... and the SDS804X can connect successfully. But apparently the FY6900 is not responding to the commands:
--- Code: ---sudo python3 bode.py fy -udp
Initializing AWG...
AWG: fy
Port: /dev/ttyUSB0
IDN: fy
AWG initialized.
Starting AWG server...
Listening on 0.0.0.0
RPCBIND on UDP port 111
VXI-11 on TCP port 9010
Creating sockets...
Waiting for connection request...
Incoming connection from 192.168.0.201:809.
VXI-11 CREATE_LINK, SCPI command: inst0
VXI-11 DEVICE_WRITE, SCPI command: IDN-SGLT-PRI?
VXI-11 DEVICE_READ, SCPI command: None
VXI-11 DESTROY_LINK, SCPI command: None
VXI-11 moving to TCP port 9011
Waiting for connection request...
Incoming connection from 192.168.0.201:809.
VXI-11 CREATE_LINK, SCPI command: inst0
VXI-11 DEVICE_WRITE, SCPI command: IDN-SGLT-PRI?
VXI-11 DEVICE_READ, SCPI command: None
VXI-11 DESTROY_LINK, SCPI command: None
VXI-11 moving to TCP port 9012
Waiting for connection request...
Incoming connection from 192.168.0.201:809.
VXI-11 CREATE_LINK, SCPI command: inst0
VXI-11 DEVICE_WRITE, SCPI command: C1:OUTP LOAD,50;BSWV WVTP,SINE,PHSE,0,FRQ,15000,AMP,2,OFST,0;OUTP ON
C1:OUTP LOAD,50;BSWV WVTP,SINE,PHSE,0,FRQ,15000,AMP,2,OFST,0;OUTP ON
Warning: WMF00015000000000 did not produce an expected response after 2 retries
Traceback (most recent call last):
File "/home/uwake/Software/FY6900/sds1004x_bode-master/sds1004x_bode/bode.py", line 45, in <module>
server.start()
File "/home/uwake/Software/FY6900/sds1004x_bode-master/sds1004x_bode/awg_server.py", line 120, in start
self.main_loop()
File "/home/uwake/Software/FY6900/sds1004x_bode-master/sds1004x_bode/awg_server.py", line 140, in main_loop
self.process_lxi_requests()
File "/home/uwake/Software/FY6900/sds1004x_bode-master/sds1004x_bode/awg_server.py", line 244, in process_lxi_requests
self.parser.parse_scpi_command(scpi_command)
File "/home/uwake/Software/FY6900/sds1004x_bode-master/sds1004x_bode/command_parser.py", line 49, in parse_scpi_command
self.parse_bswv(args, channel)
File "/home/uwake/Software/FY6900/sds1004x_bode-master/sds1004x_bode/command_parser.py", line 80, in parse_bswv
self.awg.set_amplitude(channel, ampl)
File "/home/uwake/Software/FY6900/sds1004x_bode-master/sds1004x_bode/awgdrivers/base_awg.py", line 42, in set_amplitude
raise NotImplementedError()
NotImplementedError
--- End code ---
Some additional information in case it is relevant:
Ubuntu "sees" the scope, connecting to it as /dev/ttyUSB0. This port is in the dialout group, of which I am a member - but shouldn't matter in any case since this is being run under sudo.
I tried running the FY6900 software via wine. It runs ... but no matter what I do, I can't get it to recognize the FY6900. I tried running the software in a Windows 10 VirtualBox, enabling the USB device. And ... it runs just fine, controlling the FY6900. So apparently the FY6900 USB port is operating correctly, at least with Windows.
I thought about trying to run the python program under Windows, but the README.md file only seems to reference a Linux environment, so I was unsure whether that was possible. And in any case, I don't particularly want to have to run this through a VirtualBox instance. For that matter, my ultimate goal is to run it via the ESP-01.
Help! Does anyone have any suggestions, tricks, or helpful questions to offer?
The FY6900 is the 60M version, running version 1.5.4
awakephd:
A bit more data: I was able to connect to the scope attached with USB via a terminal program (putty, gtkterm) both in Windows and in Linux - I can type in a command and see the change on the FY6900. So I do have connectivity, at least through USB. For the ESP-01, perhaps I am running into the issue of needing to adjust the resistor(s) feeding the TX and/or RX lines? Is there any way to do this on my adapter board, rather than inside the unit? I am not completely opposed to opening it up, but I would prefer to hold off until I am sure that I will keep the unit.
But that still would not explain why the sds1004x_bode program does not work. Again, any help will be most appreciated!
bateau020:
Can you test the other fy driver: fy6600?
That "fy" driver is really new, and I haven't been able to test it (don't have a FY AWG), and this is indeed a bug.
Also, this is better for discussions in github than here. I have created an issue in github and will do some debugging in the coming days by mocking the fy AWG.
Can you set "VERBOSE = True" (instead of "VERBOSE = False" as it is now) in the fy or the fy6600 driver? That can help debugging.
About Windows, it should work, but that is unlikely to solve the issue. Absolutely no need for virtualbox. This is really basic, in theory it should even run in a raspi.
I avoid WiFi as much as I can in the lab, so I haven't looked at ESP-01, but I will be able to help porting it. I am just not sure which fork to get, there are multiple forks and I see nothing that regroups all efforts.
EDIT: found a stupid bug (missing one letter in a function name). The "fy" driver should be better now. Tell me if it works. Still willing to work on ESP-01, but what fork should I start from?
awakephd:
bateau020, you are not only a gentleman and a scholar but also a saint to take this on! Many thanks. I am away from my "lab" (aka, desk piled with things in a corner of my house) at the moment, but will check out both the updated fy and the fy6600 drivers. I will also check on how to respond on Github.
On the ESP-01 code, I used the link provided by Knutselaar about 10 posts back in this thread. As best I can tell, his tweaks have not been ported back to Github, and I maybe shouldn't have started with that code - my thinking was that this represented a recent successful attempt.
What I missed until now is that he is using an SDS1104X, and that is what the code is set for. As I was digging through the espBode code last night I realized that 1) it does not include the UDP adjustment that you made to the python code, and 2) the code could use some improvement - at least in my ever-so-humble opinion. Currently, the code is essentially C, even though written in a C++ environment. I think it could be made much less confusing with judicious use of some C++ classes - for example, a class that "automaticaly" handles the endian-swap needed to go between the network and the ESP, rather than having to call the swap routine at various points on various pieces of the data. And don't get me started on the uint8_t **data parameter that is passed into the receiveRpcPacket function ... which then uses malloc to create a memory block without checking to see if it succeeds, which is then passed back to the calling function, which has to remember to free it ... even if it wasn't actually created. Yikes!
All that to say, I have already been thinking about taking on an update of the espBode code, both to include the SDS804X, and to make it easier to use going forward. Any interest in collaboration? I have to confess that I have never collaborated on something like this before, so I don't know how it would work, and I certainly won't be offended if you'd rather not.
bateau020:
--- Quote from: awakephd on September 12, 2024, 12:45:48 pm ---All that to say, I have already been thinking about taking on an update of the espBode code, both to include the SDS804X, and to make it easier to use going forward. Any interest in collaboration? I have to confess that I have never collaborated on something like this before, so I don't know how it would work, and I certainly won't be offended if you'd rather not.
--- End quote ---
Sure, no problem. Collaborating is easy with github.
One of the problems I have is that I cannot test all of the code, as I only have 1 AWG. Collaboration will help here.
Another problem is that I no longer have my SDS1000 (non-HD). I ported the python code when I had both scopes. Am thinking about making the code really VXI compliant (opening both UDP and TCP ports), and my lack of test subjects is really hampering. Collaboration will again help here.
I will take a look at the existing forks do an assessment of where to start from.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version