So far, I have been acquiring data in the lab through a LabView program, managing the communication with different instruments connected to that computer. Since covid-19, and the necessity to alternate presential and remote working, this solution was not ideal. It would necessitate to remote-control the local computer (through VNC or RDP), that forwards a lot of unnecessary data to perform and analyse a few experiments.

I recently came up with a new setup, that I hope will be easier to manage remotely through robust technologies.

The control/data acquisition instruments are all connected to a linux server via LXI (lan extension for instrumentation), and controlled via a suite of python programs, activated via ssh. This now allows me to connect to the server from any location to control my data acquisition setup, while transmitting only a few bits of text data. I decided to get rid of a monitor to actively prevent myself from carrying graphic measurements from this local server that would be hard to access remotely.

My setup is now structured as follows:

  • a linux server, connected to:
    • lan to the university network, with a fixed IP
    • a lan switch connected to all other equipments
  • the LXI equipments, connected to the lan switch
  • every other computer connected on the University network (or vpn), from which I can send commands to the server. Here, I could have connected all the LXI to the main University network, but I preferred keeping this switch for safety reasons.

Since I have no monitor on the server, managing the communication can be quite tricky. Here are a few commands to connect to a new ethernet server: The nmcli program has a unified interface to take care of this. Everything can be done in ssh without fear of losing the connection (as long as you operate on the right interface. You can use nmcli device show to get information about the connected devices, and nmcli connection show to get an overview on the active connection profiles:

~ :
julien $ nmcli connection show
NAME              UUID                                  TYPE      DEVICE          
profile_PCIeth    d718ee0c-548b-4d17-a4a4-0eaee2f0f22b  ethernet  enp0s31f6       

~ :
julien $ nmcli device show
DEVICE           TYPE      STATE         CONNECTION       
enp0s31f6        ethernet  connected     profile_PCIeth   
enxa0cec8c0b3b3  ethernet  disconnected  --               
lo               loopback  unmanaged     --               

So far, I have one ethernet cable (enp0s31f6) connected on the PCI card, with an active connection, and a USB-eth interface (enxa0cec8c0b3b3) detected, but not connected to the network. The next step is to add a connection profile to the USB-eth interface. This is achieved with the command nmcli connection add:

~ :
julien $ sudo nmcli connection add type ethernet con-name profile_USB_eth0 ifname enxa0cec8c0b3b3 
Connection 'profile_USB_eth0' (d94e30c2-ced0-41c9-85c8-0937ccc89f0e) successfully added.

Now I can add this profile to the interface. I chose a fixed IP address: 192.168.0.10 for the server, assuming that all the equipments on that line will have an IP in the range 192.168.0.[0-255].

~ :
julien $ sudo nmcli con mod profile_USB_eth0 ipv4.method manual ipv4.addr "192.168.0.10" ipv4.gateway "192.168.0.1" ipv4.routes "192.168.0.1/24 10.10.10.0"

And I activate the connection with the following profile:

~ :
julien $ sudo nmcli con up profile_USB_eth0
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/24)

I am now connected to the eth interface. A quick check would give me:

~ :
julien $ nmcli con
NAME              UUID                                  TYPE      DEVICE
profile_PCIeth    d718ee0c-548b-4d17-a4a4-0eaee2f0f22b  ethernet  enp0s31f6
profile_USB_eth0  d94e30c2-ced0-41c9-85c8-0937ccc89f0e  ethernet  enxa0cec8c0b3b3

~ :
julien $ nmcli dev
DEVICE           TYPE      STATE      CONNECTION
enp0s31f6        ethernet  connected  profile_PCIeth
enxa0cec8c0b3b3  ethernet  connected  profile_USB_eth0
lo               loopback  unmanaged  --               

The next step now is to individually set up all the LXI equipments connected to the switch, with the following configuration:

  • IP addresses: 192.168.0.[0-255]
  • Subnet mask: 255.255.255.0
  • Gateway: 192.169.0.1

To check that they are all connected, I am using the simple tool arp-scan that allows to scan for MAC addresses on a subnet. On Debian-based distributions, it can easily be installed with sudo apt-get install arp-scan.

~ :
julien $ sudo arp-scan --interface=enxa0cec8c0b3b3 --localnet
Interface: enxa0cec8c0b3b3, type: EN10MB, MAC: a0:ce:c8:c0:b3:b3, IPv4: 192.168.0.10
Starting arp-scan 1.9.7 with 256 hosts (https://github.com/royhills/arp-scan)
192.168.0.2	00:01:29:82:00:aa	DFI Inc.
192.168.0.3	08:00:11:20:00:aa	TEKTRONIX INC.
192.168.0.3	08:00:11:20:00:aa	TEKTRONIX INC. (DUP: 2)
192.168.0.4	08:00:11:20:00:aa	TEKTRONIX INC.
192.168.0.4	08:00:11:20:00:aa	TEKTRONIX INC. (DUP: 2)
192.168.0.5	80:2f:de:00:00:aa	Zurich Instruments AG
192.168.0.6	80:2f:de:00:00:aa	Zurich Instruments AG
192.168.0.7	80:2f:de:00:00:aa	Zurich Instruments AG
192.168.0.8	80:2f:de:00:00:aa	Zurich Instruments AG

9 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.9.7: 256 hosts scanned in 1.949 seconds (131.35 hosts/sec). 9 responded

Here I have the dilution refrigerator and magnet controller, connected on IP 102.168.0.2; two Keithley Sourcemeters on IPs 192.168.0.3-4 and 4 lock-ins from Zurich Instruments on IPs 192.168.0.5-8.