Siglent SDS1104X-E and SDS1204X-E: Bode plot with a non-Siglent AWG

[awakephd]

Excellent!

[das_strobel]

I will take a look at the existing forks do an assessment of where to start from.

You have a pull request from me regarding the support of Rigol DG800/900/1000Z siggens. Let me know if it works for you. Thanks!

PS: I've sent the PR to this repo https://github.com/hb020/sds1004x_bode. I hope it is the right one?

[bateau020]

Great! I knew there was something wrong with that correction, but hadn't taken the time yet to check it. Thanks.
Merged.

[Knutselaar]

 Best awakephd,

Did you change  on line 12 of esp_config.h:
#define AWG FY3200
in
#define AWG FY6900

The last compiling I did was with the FY3200.

Knutselaar

[bateau020]

@Knutselaar: the problem is that the espbode code uses TCP for both `rpc_server` and `lxi_server`. This works with the SDS1000 (non HD) series, but does not work with the newer HD series (SDS800 HD or SDS1000 HD), that awakephd has.
These newer scopes require UDP for `rpc_server`, and require dynamic changes to the port assigned to `lxi_server`. This is not really a big surprise: many other LXI/VXI devices have the RPC portmap service listening on TCP and UDP.

It however means that a rather serious adaptation of the espBode network code is needed in order to make it compatible with the HD series scopes.

Now I can help with that, the code is not that complicated. But this would need to be a group effort, as I no longer have a SDS1000 (non HD) series scope, and I do not have a serially controlled AWG (although all of that can be simulated). As a result, I really prefer to do so via github, not via zip files.

[awakephd]

Best awakephd,

Did you change  on line 12 of esp_config.h:
#define AWG FY3200
in
#define AWG FY6900

The last compiling I did was with the FY3200.

Knutselaar

Yes, I did change it to #define AWG FY6900, but as bateau020 says, the problem seems to be the need for the UDP connection.

However, your fix for the FY6900 in an earlier post, or something like it, seems to be needed in the sds1004x_bode python code:

 

The problem of frequency adjustment in the new FY6900 60MHz mentioned by bigpriap a few posts back:

I have changed in esp_fy6900.cpp line 64 and 73 from

snprintf(command, 19, "WMF%08lu000000\n", frequency);

 Into

snprintf(command, 19, "WMF%08lu\n", frequency);

[awakephd]

Can you test the other fy driver: fy6600? 

...

EDIT: found a stupid bug (missing one letter in a function name). The "fy" driver should be better now. Tell me if it works.

bateau, the python code works better now with the fy driver, in that it does not crash, and it does attempt to respond to the settings coming from the SDS804X oscilloscope. However, as I alluded to in the post just above, the version of the FY6900-60M that I have (firmware 1.5.4) does not recognize the frequency setting as it is currently formatted:

Code: [Select]

Waiting for connection request...

Incoming connection from 192.168.0.201:810.
VXI-11 CREATE_LINK, SCPI command: inst0
VXI-11 DEVICE_WRITE, SCPI command: C1:BSWV?
VXI-11 DEVICE_READ, SCPI command: None
VXI-11 DESTROY_LINK, SCPI command: None
VXI-11 moving to TCP port 9014

Waiting for connection request...

Incoming connection from 192.168.0.201:810.
VXI-11 CREATE_LINK, SCPI command: inst0
VXI-11 DEVICE_WRITE, SCPI command: C1:BSWV FRQ,2234.4898
C1:BSWV FRQ,2234.4898
Warning: WMF00002234489800 did not produce an expected response after 2 retries
VXI-11 DESTROY_LINK, SCPI command: None
VXI-11 moving to TCP port 9015

If I try sending the FY6900 the command as WMF2234.4898\n it works perfectly - yes, with the decimal point, no leading or trailing zeros. When it gets something like WMF00002234489800\n it sets the frequency to 60 MHz.

I note also in the fragment above that the oscilloscope appears to be asking for some feedback - where it issues the command C1:BSWV? - I can't tell whether the program is giving it the desired feedback, or simply ignoring this, and I don't know if it matters. I forgot to run it with VERBOSE = True, so I will report back when I have a chance to do that in case that gives more information.

I also tried it with the fy6600 driver. It produced similar results, i.e, unsuccessful results - one difference being that it did not report back whether the frequency setting was successful, but as I watched the FY6900 screen, it clearly was not successful. I'm guessing it uses the same formatting as the fy driver does. Here is a bit of the output:

Code: [Select]

Waiting for connection request...

Incoming connection from 192.168.0.201:810.
VXI-11 CREATE_LINK, SCPI command: inst0
VXI-11 DEVICE_WRITE, SCPI command: C1:BSWV?
VXI-11 DEVICE_READ, SCPI command: None
VXI-11 DESTROY_LINK, SCPI command: None
VXI-11 moving to TCP port 9018

Waiting for connection request...

Incoming connection from 192.168.0.201:810.
VXI-11 CREATE_LINK, SCPI command: inst0
VXI-11 DEVICE_WRITE, SCPI command: C1:BSWV FRQ,4295.71429
C1:BSWV FRQ,4295.71429
VXI-11 DESTROY_LINK, SCPI command: None
VXI-11 moving to TCP port 9019

I have worked my way through the espBode code, but have only begun on the sds1004x_bode code; however, I feel like the combination of UDP fix from the latter plus frequency format fix from the former may prove successful!

[bateau020]

Uploaded a new version with a specific fy6900 driver. Tell me how it works.

About C1:BSWV?: it is indeed not implemented right now, as it seems to be ignored by the scope.

[awakephd]

Many thanks! I may have jumped the gun - I tried making one change in the set_frequency method of the FYgenAWG class:

previous version:

"%014u" % uhz,

my change:

"%.6f" % freq,

and ... drum roll ... it works!

I was going to attach a screenshot ... but I can't seem to get it to attach.

[awakephd]

Ah, got it - I was misunderstanding the way the forum handled the image attachment. Here it is! Simple low-pass RC filter (330Ω resistor, 10nF capacitor).

[awakephd]

Uploaded a new version with a specific fy6900 driver. Tell me how it works.

About C1:BSWV?: it is indeed not implemented right now, as it seems to be ignored by the scope.

Haven't had a chance to try the new FY6900 driver yet, but took a quick look at it. Looks like you did something similar to what I have above. I am not overly familiar with python, but I'm curious about the format specification you used - "%08.6f" - doesn't this mean a total of 8 characters wide, with 6 digits after the decimal? What happens if the frequency is 100Hz or higher - does python "override" the width specification to allow additional digits before the decimal? Or have I totally misunderstood (highly likely given how little I know python!)?

[awakephd]

Well, now that this is working, I have two things to work on:

#1 - get the espBode version to work, and
#2 - figure out why my plot shows the phase starting out flat at around -7° when I was expecting it to be at or close to 0°. Other than that, the plots look exactly like what I predicted based on the component values. Equipment error?? An error in the way I set it up / measured / something??

Sorry for so many posts in a row. Can you tell that I am very excited to see this working?

[tautech]

Well, now that this is working, I have two things to work on:

#1 - get the espBode version to work, and
#2 - figure out why my plot shows the phase starting out flat at around -7° when I was expecting it to be at or close to 0°. Other than that, the plots look exactly like what I predicted based on the component values. Equipment error?? An error in the way I set it up / measured / something??

Sorry for so many posts in a row. Can you tell that I am very excited to see this working?

Yep, congrats.

More can be learnt here:
https://www.eevblog.com/forum/testgear/siglent-sds1x04x-e-bodeplot-ii-(sfra)-features-and-testing-(coming)/

[awakephd]

Thanks, Rob. I've started looking at that thread. Clearly the UI for the Bode plot on the 1000x-e is quite different than the one for the 804x, so that has been a bit confusing, but I shall persevere ...

[awakephd]

A bit of progress and a request ...

---------------

First, the request: As described below, I have done some work on the espBode code ... but only on my local copy ... because I am a git / github neophyte. I have known how to do a "git clone" for years, but have never ventured beyond that. I did watch a couple of tutorials last night, but am still not entirely sure how to use it to create a fork from one of the existing github repositories - I am thinking a fork is the best approach, as what I am envisioning, and have done so far, is a pretty thorough rewrite from the current C code to take advantage of C++ classes. I'd also like to incorporate, or at least allow for, the greater functionality of the sds1004x_bode python program as updated by bateau020.

Of course, yet another question is which repository to start from - there are at least 5:

https://github.com/sq6sfo/espBode           last commit was 5 years ago; includes only FY6800; does not include telnet; only for ESP8266
https://github.com/timkoers/espBode        forked from sq6sfo; last commit was 4 years ago; adds FY6600, FY6900
https://github.com/Hamhackin/espBode     forked from timkoers; last commit was 3 years ago; adds JDS2800; adds telnet
https://github.com/hankst69/espBode       forked from Hamhackin; last commit was 1 year ago; no added features, but code cleaned up
https://github.com/Switchleg1/espBode     forked from sq6sfo; last commit was 9 months ago; adds FY6600; allows ESP32 or ESP8266

As the list above shows, sq6sfo seems to be the originator, but there are two separate "families" - the one leading to hankst69, and the one by Switchleg, which has had much more recent activity, but leaves out the additions made by timkoers, Hamhackin, and hankst69.

And then there are the tweaks that Knutselaar added, but I haven't found a github repository for those, and I can't tell which version he started from - presumably either Hamhackin or hankst69, since he includes telnet.

I propose forking from hankst69, adding in the tweaks from Knutselaar, and seeing if Switchleg caught any bugs that the others missed. Now I just need to figure out how to create the fork. I have set up a github account. I'd prefer to do the editing on my local machine. I know there is some way to link the local git directory to the github repository, but I am still confused about which variation of command(s) to use. If anyone has a simple, 1-2-3 guide to point me to, I would be most, most appreciative!

----------------

Now, the progress: Before I get too far down the road of re-writing the espBode code to use UDP, I wanted to be sure that my ESP-01 plus the adapter I made (to regulate the 5v to 3.3v and route the serial lines) were actually communicating with the FY6900. I reworked the .ino file of the espBode project to add a selectable "passthrough" mode via the telnet connection. In the process, I reworked the loop function to use a simple state variable, thus allowing the telnet processing to continue to work even while it is waiting for a connection from the scope. I have attached the result to this post.

I compiled and uploaded this (along with the rest of the existing espBode project), and after a few rounds of debugging, it works beautifully - and more importantly, I can now verify that the ESP-01 is successfully communicating with the FY6900. I connect to the ESP-01 via telnet, enter passthrough mode by sending the word passthrough, and then I can issue the various commands, such as WMF1000 or RMF or so on. It seems to work flawlessly! Sending the word passthrough again turns off passthrough mode, and it is ready to listen for the oscilloscope. But of course, before it can "hear" the SDS804X, I need to implement a UDP option. And that leads back to the request above ...

-------------

On edit: I've made a fork from hankst69 in github: https://github.com/awakephd/espBode. Now if I can just figure out how to coordinate that with my local editing ...

[bateau020]

Now if I can just figure out how to coordinate that with my local editing ...

Easy. github is just a remote repo with a web interface added. But it remains a regular git repo.

Steps:
* add your ssh public key to your github profile setting (https://github.com/settings/keys)
* clone the repo to your PC: git clone git@github.com:awakephd/espBode.git  (from the green "code" button top right in your repo)
* edit and test locally
* when done, git commit and git push, as usual. If you've never done git, sorry, the learning curve is steep, but there are loads of tutorials.
* If you use vscode with platformio (recommended) an extension like "Git History" can be helpful.

[awakephd]

Knutselaar, where did you get the code base you started from?

The question comes from re-thinking my plan. I more-or-less have github and git sorted out, at least enough to get going. But I am still puzzled by the various forks and revisions of code. I had wanted to start with the code base that Knutselaar used. Why? Because his report of success is the most recent I've seen. However, I can't find the repo from which it seems to have been drawn. None of the ones listed in my recent post above include the FY3200, but the code that Knutselaar used did include that. Obviously there's some other code out there, either not in the github repos, or (equally likely) I haven't figured out how to find it.

I did find one other repo: https://github.com/AgentLintZeal/espBode - this repo does not indicate the origin from which it forked, but appears to stem from the same starting point as all the rest. However, it has shifted to platform.io, and seems to be targeting only the jds8000.

Meanwhile, my re-thinking has led me to the conclusion that it makes more sense to do a start-over rather than attempting to edit and update the existing code. Obviously the start-over would depend on both espBode and sds1004x_bode, but the former is in C and the latter is in python, and my goal is to write a C++ version ... mostly because that is where I am most comfortable. (Though it has been 40 years since I wrote software for a living, in the years since I have occasionally taken on an in-house, single-developer project, and nearly all of that has been C++.)

So, now I have a question about etiquette. If I do a complete do-over, essentially starting from scratch even while drawing on the insights from the former versions ... what is the best way to represent that in github? Should I start a new repo, with a title such as espBode2.0 or something like that, and refer back to the earlier efforts in the README without actually forking from any of them? Or is it better to stay with the espBode name, fork from a previous repo, and then create a new branch? Yes, clearly I am still learning my way around github and so on. As I said, all of my coding up to now has been single-developer - me! - and not something that could or should be shared.

Another part of the puzzle: before I do the start-over version 2, I am greatly inclined to see if I can tweak Knutselaar's version just enough to get the UDP communication working. That would definitely seem to be best done in the context of a forked version of espBode ... but once again, I can't figure out where Knutselaar's version was forked from. Knutselaar, any help you can give to point me in the right direction will be most appreciated!

[shabaz]

Unless you're using that feature every day wouldn't it be easier/cleaner to simply use a PC and automate if from there? This is what SCPI programmability is intended for. Then you can precisely tailor the behavior and the output to the task at hand, and tweak as required.
I don't understand how programming an ESP to act as a sort of translator (if my understanding is correct) is more flexible or convenient.

[awakephd]

Shabaz, a fair question. Here is my understanding, which may be flawed, as I am still new to both the Siglent SDS804X and to the FY6900 AWG.

1) The Siglent does not recognize the FY6900, and the FY6900 does not speak SCPI. Therefore, though it would be possible to connect them physically via USB cable, it is not natively possible to have the Siglent generate an automatic Bode plot.

2) The FY6900 does not have any wifi or LAN connection. It can be connected to a PC or other device via USB, and will respond to a fairly simple text-based command set sent via a terminal program such as PuTTY. While this works flawlessly, it is not particularly convenient to have yet another cable to organize; simply for the sake of controlling the AWG from the PC, it would be far more convenient to have a wifi connection.

3) The FY6900 includes a connector with TTL-level serial plus 5V and GND; connecting to this bypasses the USB but allows the same communication with the AWG. This begins to answer your question - at the most basic level, use of an inexpensive ESP-01 board plus a small interface board (to convert the 5V to the 3.3V needed by the ESP8266) allows one to outfit the FY6900 with a wireless interface. That's a nice upgrade, for the grand cost of about $2!

4) Some years ago, work began on the sds1004x_bode project. This is a python program intended to run on a PC, which will connect to a Siglent scope via wifi, then connect to any of several inexpensive AWGs including the FY600 via USB (more strictly speaking, via a serial connection). This program is indeed, just as you suggest, a translator. It listens for connection requests from the Siglent scope and responds to its ID request in such a way that the Siglent thinks it has connected to a Siglent AWG. The Siglent then can send out the SCPI commands to control the AWG in order to generate a Bode plot; the sds1004x_bode program translates these commands into the commands that the FY6900 (or other AWG) can understand. Voila! Now the Siglent scope can generate a Bode plot using a non-Siglent AWG.

5) Put 3 and 4 together: while the sds1004x_bode program works beautifully, it is not particularly convenient - not only must one (once again) use a USB cable, but now one must also find a place for the PC. Surely the relatively simple task of translation could be handled by a small microcontroller? Yes indeed - and now we get to the espBode project. This will allow the Siglent to connect to the FY6900 (or other) via wifi, thinking it has connected to a Siglent AWG, and it can generate a Bode plot without having to manage an additional cable (for the USB) or find a place for the PC.

[shabaz]

I see.. I think I understand now. I didn't realize the sig-gen didn't natively support SCPI.
If the sig-gen were to look like a SCPI device (e.g. via an ESP32 configured to have SCPI one side, and appropriate UART protocol on the other end), then both the 'scope and the sig-gen (through that SCPI adapter) could be controlled via (say) labVIEW, or Python, and then a bode-plot program could be executed on the PC, i.e. no need for messages to pass through the 'scope to a sig-gen.
Example screenshot below was created using a different 'scope and sig-gen, both of which support SCPI, just to show an example of the benefit of that. Since it is entirely under PC control, I could tweak the script to meet exact needs (e.g. only test at specific frequencies, or display with larger text and so on).
However if the ESP is required anyway to do the conversion to SCPI, then I can also see why one may as well try to set it so that the 'scope handles the communication and leave the PC out.

[awakephd]

Ah, that makes sense. If / as this revision develops, it would be interesting to see how far we could go to offer generic SCPI control.

[awakephd]

Quick update: I have moved forward with the github repo (https://github.com/awakephd/espBode). I went back and forked it from the Hamhackin version, rather than the newer hankst69 - I concluded that it would be easier to proceed down the path I have planned starting from there. I have now updated that code base with a new commit, incorporating the changes that Knutselaar made (and the FY3200 code that his version included) as well as my own updates. Most of what I have done is to add a passthrough command to the telnet interface, and in the process reorganize the logic of the loop() function. Some other minor tweaks and updates as well. At this point, I will try to do a quick-and-dirty implementatiion of the UDP connection needed for the SDS804X and verify that it works. Once that is done, I will create a new development branch and start work on a complete rewrite.

[bateau020]

In order to make espbode (or the python script) into a siglent emulating SCPI frontend for any AWG, that respects at least some of the standards, 3 loops/threads/processes are needed:

• 1 that does portmap on UDP (this part is used for broadcasts/discovery and by the HD scopes)
• 1 that does portmap on TCP (this part is used by direct VISA communication, as with the non-HD scopes
• 1 that does the VXI-11 communication (on TCP)

The latter should switch to a new port after every LINK_DESTROY, and communicate the new port to the port mappers.

Made this work in the python version, in today's commit. Previously it only ran 1 of those loops at a time, which messed up communication with other SCPI tools.
Haven't really looked yet at how espbode does it.

[Knutselaar]

Hi  awakephd,

Before my first post I have searched all corners of the internet and found a espbode-master with date 8 december 2020, I think from Github.

I am sorry, I did search today, and I can not repoduce the origin of espbode-master I have used.
I think I have used Youtube:


Text under this video:
************************************
Vastgezet door Tim's Electronics Lab
@TimsElectronicsLab
3 jaar geleden (translation: 3 years ago)
I have created a pull-request on GitHub (https://github.com/sq6sfo/espBode/pull/4) that enables the full FY6900 instruction set. It hasn't been merged yet, so feel free to clone my repo (https://github.com/timkoers/espBode) until it is merged.
************************************
I think that I used one of these links, but they dont exist any more.


I took the espbode-master that worked with the old FY6900.

In my first post reply #112 I explained the path I followed.

Because I also own a FY3224S I took the working driver of the FY6900 and adapt it for my FY3224S.

In the espbode-master attached at  reply #113 I made a different solution of the frequency send to the FY6900 than described in post #112.



Maybe it is best, to be complete, to include also the driver for the old version of the FY6900 for those who have the old FY6900.
attatchment: old FY6900 driver:

[awakephd]

Thank you, Knutselaar. I think I have generated a repository that does a reasonable job of incorporating the elements that were in the base you used, along with your updates plus mine. I agree that we should have the old FY6900 as an option; thanks for sending it! timkoer's repository is one of those that I looked at, but as best I recall it does not include the FY3200 as an option. At this point I can't determine where that code came from.