Remote control software for GW Instek GDS 2204

For PC type software that runs under some PC opsys.

Remote control software for GW Instek GDS 2204

Postby Doug Coulter » Wed Oct 19, 2016 9:03 pm

As part of the fusor data acquisition, we have a fast, 4 ch scope looking at some things were we want really good time resolution to tease apart causes and effects. So I purchased a really nice 4 channel 2.5GHz effective sample rate scope, a GDS-2204 for the setup. I also got the Ethernet and VGA addons for this so as to be able to both take video of what would have been on the screen (the built in screen is fine if you're in the room with it, but tiny for a pi camera), and control it somewhat during a run. By definition, I can't be in the room with this while the fusor is running, and last I checked, low noise scope preamp class gear that would let me send high impedance high frequency (in this case only 1 mhz) signals down coax to the operating position is around $2595 per channel (otherwise stated - more than that scope with addons, and it's faster too). [Citation Oct 2016 issue of Photonics magazine, Standford Research Systems Inc model SR560]

So! I wrote some perl (yes, I know, I have weird taste) to control some things from the remote operating position over Ethernet, and while it doesn't cover more than a fraction of the possible functionality, it's probably good enough for what we need during a run. We can always adjust things between runs too and save them remotely as defaults with this code. Or I can add more code to this, but even with 4 monitors, I'm not overwhelmed with extra pixels. The scope itself has a tree structure for many menus because there's only room for howevermany knobs (a lot). Same issues here, and I just needed good enough.

This code assumes Ethernet, 192.168.1.201:3000, but you could use my USB serial software and substitute port paths and $port for $socket in the code and it'd work that way too. Problem here is, USB isn't going to go as far as I am away from this when it's running. The main problem for anyone else to use this code is likely going to be getting all the perl modules it uses going with your linux distro (I recommend cpanminus and synaptic to get the dependencies sorted - in one case you need synaptic to get a C library's development version (see the cpanm build logs when you get errors). Sigh, it is what it is.
This software is in two files, one perl, one glade XML that defines the gui. It can create a preset file of any name you like, that will go in the same path as wherever the program files are (I use home/doug/bin, ymmv).

I have to say, that it's really cool to be able to develop this and watch it change things on the scope via a raspberry pi video camera over at the fusor - from here. Saves a lot of shoe leather.
And it's not totally ugly:
ScopeRemote.png
A nice view


Here's the bits - share and enjoy:
Scope.zip
Perl and glade for remote scope control
(6.37 KiB) Downloaded 17 times
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 2934
Joined: Wed Jul 14, 2010 8:05 pm
Location: Floyd county, VA, USA

Re: Remote control software for GW Instek GDS 2204

Postby johnf » Thu Oct 20, 2016 3:39 am

Keep at it Doug
you need to take a night off and watch a movie
And you can now download the new NZ movie
"Hunt for the Wilderpeople"
you will enjoy it!!!!!" as it looks like my back yard for a lot of it

Or with Halloween coming up
a Mockumentery on vampires

"What we do in the shadows"
which is shot in my local city
johnf
 
Posts: 375
Joined: Sun Aug 08, 2010 4:51 pm
Location: Wellington New Zealand

Re: Remote control software for GW Instek GDS 2204

Postby Doug Coulter » Thu Oct 20, 2016 10:07 am

Indeed, our back yards look a lot alike, too, despite being so far apart. Symmetry?
I did take a night off recently to watch "Lucy" -the one with Scarlett Johansson 2014. Part of it is a very realistic simulation of what an LSD trip is like (then they ruin it by hollywooding it up - only the other trippers experience the CGIs with the real thing...).
This deadpan delivery is right on: https://www.youtube.com/watch?v=vwObck9twes
And perhaps we scientists should consider more of it.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 2934
Joined: Wed Jul 14, 2010 8:05 pm
Location: Floyd county, VA, USA

Re: Remote control software for GW Instek GDS 2204

Postby Jerry » Fri Oct 21, 2016 1:49 pm

Since you have the VGA option you can just get one of these extenders that allow you to use cat 5 cable to remotely display a VGA display. good for 500 ft. https://www.startech.com/AV/Extenders/V ... s~ST121UTP
Jerry
 
Posts: 556
Joined: Sun Jul 18, 2010 1:07 am
Location: Beaverton, OR

Re: Remote control software for GW Instek GDS 2204

Postby Doug Coulter » Sat Oct 22, 2016 12:20 pm

Yeah, that's pretty cool. I'm kind of at the limit of what cables I can bury without hitting something (extensive use of metal detectors was already required) - it's busy under the yard these days, as all my other wiring (solare, generators, AC, DC, hardwire controls, battery and water monitoring) and plumbing is also down there somewhere (often under a metal junkyard). Good to know, it may become handy, and I could perhaps buy another switch and spare up one of the already-buried cat5's (2+ 1 cat6). I know, I should have made a map, but it kinda just grew over a few decades.
There is quite the mesh between the 4 buildings on campus here.

On the other hand, this setup records, in a very tightly shielded Pi, the video, as well as showing it to me in a split-screen preview with other cams (hint, see the Vivaldi browser that lets you tile tabs).
What happens is that the pi cams record full rez and speed, and I send a somewhat reduced rez and speed preview to the op position, and all those cams fit on one monitor. The other 3 do plots, command and control GUIs I've written, and so forth. When a run is done, those external cams are commanded to copy their vids to the main pi, which then copies them, along with the SQL database it's been replicating all along - to the op position for later analysis. Thus I have a bit of redundancy, which in this case seems a good thing. It's just amazing how well you can shield both ends (the source of EMI and these data aq computers) and still crash them. Of course, EMI isn't the only game here - we are making enough neutrons for disruption and transmutation, and all the fusor-local computers are considered "sacrificial" as a result (and backed up out the wazoo remotely for quick replacement). This setup crashes a PC using ddr3 more or less instantly by corrupting its memory in the absence of any EMI my scope can see - just neutrons/gammas knocking electrons around...turns out running out of "rom" or at least larger capacitors in ram is not stupid in this environment.

Before I got real religion around shielding EMI at the source, I fried two PC's that weren't even wired in - just the energy picked up by the mouse cable/power cable used as antennas was enough to fry - completely ruin - a modern PC that wasn't even turned on, of for that matter, wired into any of this.

It's not like you can completely eliminate some EMI when there's an arc (now rare...as I can make it). Things like ground loops are almost unavoidable, and worse, the stray capacity in the HV cables, feedthroughs and such tends to be VERY high Q, so peak currents (at ~~50kv) can be real serious. So even if I use series impedances, I can't do it for the parasitic stuff.

The end result of all this is supposedly going to be (not yet designed or written) data mining software that can show me time-accurate scope data acq, along with the other stuff (about 12 channels at 10hz or so) and room audio and a couple other cameras - in perhaps short (variable length) time-slidable loops on the collected data, which all winds up back at the op positions in near real rime. That way, if something really works well, even if in a burst and the computers over there all crash - I can know just what was going on up to the instant of the failure. If I'd had this before, I'd be done and there'd be no controversy about whether I'd done it (the huge output and Q) in the first place. Once bitten, twice shy. This time it's going to work. If it's overkill, fine. I put up with crap for quite some time while building this, I mean to put a stop to that - or have to go ahead and hang my head in shame (and...those who leaked against my wishes and created the controversy...will get theirs too).
It ain't science if you can't replicate, here and in other labs. The quest now is to do just that, and we'll be starting as soon as Monday.

BTW, the scope does have a data-dump function, but the tiny uP in there that just shares memory with the FPGA that does the real thing is limited to around 9600 baud. So, for this, useless. Since I can afford the bitrate (and resulting storage space), the video is much nicer. What I'm showing here in the preview is just the reduced resolution and framerate mjpeg. What I get in the end is full HD.
ScopeCam.JPG
Here's the remote end. Note, you can't see the half pound of ferrites we had to use along with the shielding to keep from violating the "mere" 500v or so common mode limit on ethernet. Can't really use wifi here - too much noise. A wire that long might as well be an antenna...

The led you might notice on the lower right of the display is for time-sync. The grid camera has one too. One problem I had was mere 2n4904's and 2n3906's wouldn't make a low impedance enough drive for my "clapboard" time sync signal such that emi wouldn't "re start" all the timing. I recently went to a 6 amp fet driver chip for that, which so far has been bulletproof.

And now, gee, if you've used a scope any to investigate something, you always want to twiddle the knobs a little, you almost never get them just so on the first go.
If you have to do a long round trip (here that can involve deep snow or mud some times, just to make it more fun) to try incrementing or decrementing one of the many knobs (and you know from experience that it's usually more than one try even when you're right there and the process is going) - this remote control looks like a very nice thing to have.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 2934
Joined: Wed Jul 14, 2010 8:05 pm
Location: Floyd county, VA, USA


Return to PC

Who is online

Users browsing this forum: No registered users and 1 guest