Products > Test Equipment
Siglent SDS1104X-E and SDS1204X-E: Bode plot with a non-Siglent AWG
bateau020:
--- Quote from: awakephd on September 15, 2024, 12:19:41 am ---Now if I can just figure out how to coordinate that with my local editing ...
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version