[Ground-station] "Hello World" acceptance testing for test equipment

[Drew Arnett]

I wonder if that HTTP protocol is safe from Little Jonny Drop Tables.
:-)  (You know the old xkcd reference to sanitizing your input.)

If you use python and one of the standards based interfaces:  SCPI
over any one of TCP, telnet, serial, then the test software will run
on anything.  Windows, linux, osx, pi, whatever.  No need for drivers
of good or bad quality just to control the instrument.  Looks like
those Rigol and even that Minicircuits meets my standard.  A simple
thin abstraction and you don't care what the underlying transport for
the SCPI is.

Put all that test gear on a private lan and only with a trusted host
with access to it.  Then don't worry about the security of the test
equipment.  Unless you don't trust the test equipment.  :-)  Maybe
firewall up?

Telnet is just fine in some cases, but yeah, it has to be passwords in
the clear are OK and no authentication needed kind of cases.  :-)

Still not a fan of the HID 'trick' to try to make USB easy.  We've had
libusb forever now.

Drew

On Wed, Nov 4, 2020 at 5:04 AM Paul Williamson via Ground-Station
<ground-station at lists.openresearch.institute> wrote:
>
> > On Nov 3, 2020, at 7:50 PM, Drew Arnett <arnett.drew at gmail.com> wrote:
> > Hello world for SCPI instruments is ask("*IDN?"), no?  What are you
> > thinking about?
>
> I was thinking about something a little more instrument-specific. Make a meaningful measurement, exercise some of the neat features.
>
> > Are you accepting the gear or are you accepting the
> > users for remote controlling of the gear?
>
> My notion was just to get the gear tried out right away, even if it wasn’t needed for any urgent testing requirement. If there’s a DOA we can get it fixed or replaced before it becomes a bottleneck. (Coincidentally this provides an excuse to play with the gear as it arrives!)
>
> Keeping those quick tests handy is a good idea, too. When things aren’t working and we start to suspect the test gear, it’s really useful to have a set of known-working procedures to run against the instruments. They may also be useful as basic programming examples for lab users to refer to. For instance, that power meter comes with examples for USB and Windows. If we want to talk SCPI/Ethernet and Linux, we will have to translate.
>
> I’m not thinking about accepting users in the sense that they’d have hoops to jump through before being allowed access. There’s no need for that. I just want to provide whatever resources we can in order to make it easy to get started and be productive.
>
> > Side note:  I usually put test equipment on a private test equipment
> > LAN.
>
> That’s pretty much a given, since we have to provide our own access control.
>
> >  If folks need to use the gear remotely, they can remote into the
> > test control PC that is multihomed on the test equipment LAN.
>
> That’s one good way to do it, but it might not always be the best. I’m thinking that a Linux box can do access control and also provide VPN access to the test equipment LAN. I’m prototyping that right now with a Raspberry Pi 4, which may well end up being sufficient for production. Some tests will probably be easier to run on the Pi and some will be easier to run on Windows or whatever else we have.
>
> > Touch screen with gestures?  Sorry, not a fan of touch screens on test
> > gear.
>
> Not so easy to remote a touchscreen, so the feature is pretty much wasted on us.
>
> > But SCPI over telnet works just fine, too.
>
> Telnet! This is why access control is important.
>
>   -Paul