(updated again)

Here it is !

The first plot of the Von/Voff of 90 RES64A relays, found on vseste's eBay store in Moldavia:

The range is extended because the relay is in series with 4×2K Ohm resistors, the ratio is about ×5. Add another ×100 ratio because I count in steps of 10mV. What matters is that ALL the parts are tested in the exact same conditions and we have a pretty good scatter pattern. I still have 60 parts to test and 110 should arrive in the coming weeks.

I have uploaded the script on the files section.

153 relays have been tested and the results are looking good. 1 relay was DOA and will be sacrificed during an autopsy.

I have uploaded the raw data as RES64.152ok.log and here are some early plots :

X-Y plot

gnuplot script:

set xtics 0.2
set ytics 0.2
set xr [0:5.5]
set yr [0:3.5]
set xlabel 'Von'
set ylabel 'Voff'
d(x)=x
plot "RES64.log" using ($2/500):($3/500) w points pt 7, d(x) notitle with lines linestyle 2

 I have traced the diagonal line because the distance from the point to the diagonal indicates the hysteresis.

There are two applications for the relays and they are in 2 zones of the dot cloud :

1. Amplifier/buffer : this requires a low Von so it's the leftmost dots
2. Latch/flip-flop : they require a large hysteresis so they are furthest from the diagonal line.

The "dots" will be allocated later when I have the whole stock but we can already see some of them used for specific purposes.

Hysteresis

gnuplot script:

set ytics 0.5
set xtics 10
set ylabel 'Hysteresis'
set xlabel 'Part sn#'
set yr [0:5]
set xr [0:153]
plot "RES64.log" using 1:(($2-$3)/500) w points pt 7

Apart from a few outliers, hysteresis is well between 1.5 and 3.5V.

• The low hysteresis parts are suited as buffers, to lower the source's required swing
• The high hysteresis parts are suited as latches, for better reliability

Candidates for the buffers can be selected by first sorting the list by hysteresis, then sorting by Von.

Margin

gnuplot:

set xr [0:153]
set yr [0:6]
set ytics 0.2
set xtics 10
set xlabel 'Part sn#'
set ylabel 'V'
plot "RES64.log" using 1:($2/500) title "Von" w points pt 7, "RES64.log" using 1:($3/500) title "Voff" w points pt 7

Even with the occasional outliers, we see the other major benefit of reed relays : there is a much larger "gap" between the Von and Voff clouds, compared to the RES15. The larger the gap, the less sensitive to parasites ! There is at least 1V of margin so the power supply can be less filtered => cheaper and more reliable !

OTOH the "outliers" can be used as buffers.

Register set supply voltage

gnuplot:

set ytics 0.5
set xtics 10
set ylabel 'Hysteresis'
set xlabel 'Part sn#'
set yr [0:5]
set xr [0:153]
plot "RES64.log" using 1:(($2+$3)/1000) w points pt 7

The question of the voltage to apply to the register set is critical as well, since reliability/retention are affected, but easy to evaluate : it's simply the average of Von and Voff, and is shown to be in a band centered around 3.2V. This means I can reuse the rails of the Numitron-based display modules, using -3.3V-0V-+3.3V. Or a 6.6V unipolar supply. Neat.

The band's medium value and width will change once the "sensor" parts are taken out of the pool. Overall it's a great news because the comfortable margin (compared to the RES15-based R7) greatly simplifies the design of the power supply. Not only has the current dropped (thus reducing the size of the filtering capacitors as well as the self-heating-related drifts) but there can be only one regulator and tuning point (instead of one per board). And because the load is constant, the working point is set with a simple rheostat in series, of a lower rating than what was planned for the previous version that used RES15s.

The register set will use a pair of relays for each bit and the first plot (XY) will help select the pairs : they are closest from each other. Maybe I can come up with some sort of automatic partitioning...

"Matching" relays further increases the resilience : when the power supply fluctuates, both relays will behave almost identically and this will prevent one bit from flipping while the other half didn't change.
.

I created a new program : file_buttons.c

It solves a problem I discovered : some events are not sent when the program starts so it would miss critical events in the previous system I considered.

Now, the program is run in parallel with the script, which can read the values of the files button_left, button_middle and button_right.

It's still missing a safety/check to prevent more than one instance from running.

In the past, I have coded and uploaded FP23.c to convert the numbers and strings to a fixed point format that is recognised and written by the KA lab PSU series.

I think I'll use bash anyway so any way to avoid C code is welcome :-) And I have decided to stick to a fixed 4-digits format, that is easily converted to the 5-digits&dot format used by the PSU. A couple of bash functions do the trick !

function convertAmperes () {
  echo -n $1  | sed 's/^\([0-9]\)\([0-9]\)\([0-9]\)\([0-9]\)/\1.\2\3\4/'
}

function convertVolts () {
  echo -n $1  | sed 's/^\([0-9]\)\([0-9]\)\([0-9]\)\([0-9]\)/\1\2.\3\4/'
}

From there, it is easy to create simple loops and high resolution ramps :

for V in $( seq -w 0 6000 ); do
  echo -n "VSET1:"$( convertVolts "$V" ) > $TTY
  sleep .1
done

I'll try to characterise a batch of RES64 and the quantity is smaller than the RES15 so I don't think I need a crazy AN3 labelling format.

Some changes are happening !

The RES-15 has a pretty low hysteresis and high power draw. The RES-64 is bulkier and only SPST but who cares ? The hysteresis is more than 2V under 2mA only so it is better suited, more stable and resilient, less power-hungry...

The testing strategy does not change but some electrical parameters do. Mainly it's the series resistor and the voltage range. The RES64 has a 2K ohm coil so a 10K series resistor increases the resolution by ×6 and the voltage shoots up to max 36V.

I just added a 3rd C file that reads the status of the mouse button. It follows the precedent log 6. Got mouse.

It tries to be reasonably clever but be careful, it's a quick and dirty hack, like the other files :-D

At least it reads the event source in a non-blocking way so the main program can poll the buttons at the desired state.

The 100 ohms resistors in series with the coil increase the voltage required to operate the relay.

100 ohms + 40 ohm max for the coil makes the relay close at about 8V for certain units, instead of 2.3V max for the lone coil. This is good because the resolution of the measurement is increased, the digital PSU has 10mV steps so the virtual resolution is around 2.5V. I intend to almost double this resolution with another 100 ohms resistor in series, just to be safe :-P

The max voltage might increase to 15 or 16V for certain outliers.

The max. current will be set to 50mA because that's the maximum that the 1/4W resistor can handle:
P=R×I² => I²=P/R => Imax = sqrt(P/R), and here we have P=1/4W and R=100.

This also means that my C code must handle input and output of fixed point numbers in ASCII, while the internal resolution is an integer number of mV. I get a "fixed point 2.3" format (2 digits for Volts and 3 digits for millivolts) that fits in an unsigned short int (16 bits => 65.536V, while the PSU is limited to 61V) and this is useful for the current as well (in mA).

I have added another C source code file that handles the conversion to/from ASCII format and integer millivolts. What else should I code now ?

I'll have to automate many aspects of the binning process. However I still have to manually handle the parts.

The computer will generate and store the characteristics with SSV log files, but the relays might be loose in bags or boxes. The relays must be marked, manually, because I have no fancy automated marker. There is only me and a fine marker. The marking must be short and practical...

I decided to use an alphanumeric code : 2 or 3 digits, 0-F and A-Z. There are 36 codes per digit, which is the standard capacity of a box of RES15. This allows me to mark boxes with a prefix for easier lookup in the future.

36×36=1296 relays : this is more than I think I can test myself so 2 digits are enough in the beginning but 3 is still possible (up to 46656 codes) because I own more than 1296 relays at this moment.

The test software is written in C because of interfacing and timing constraints. Let's now write the conversion functions :

• alpha to integer is required so the program knows where to start counting, from the command line or by scanning the previous log files.
• integer to alpha because the computer must output the code on screen and on the log file.

Beware, it's ugly but quickly coded.

/*
file AN3.c (c) 20181118 Yann Guidon whygee@f-cpu.org
Alphanumeric3 code : 3 digits code up to 46656 values
Not really foolproof but good enough for a hack or two.
*/

#include <stdio.h>

// the character string MUST be terminated
// (by zero or space for example)
int alphanum3_to_integer (char *a) {
  int val=0, i=0;
  char c;

  while (1) {
    if (i>3)
      return val;

    c=a[i++];

    if ((c >= '0') && (c <= '9')) {
      val = val*36;
      val += c-'0';
    }
    else {
      if ((c >= 'A') && (c <= 'Z')) {
        val = val*36;
        val += (c+10)-'A';
      }
      else
    return val;
    }
  }
}

// error can be checkd by looking if a[0] changed
void integer_to_alphanum3(int val, char *a) {
  int div, rem;

  if (val >= 46656)
    return;

  div = val / 1296;
  if (div < 10)
    a[0]=div+'0';
  else
    a[0]=(div+'A')-10;
  val -= div * 1296;

  div = val / 36;
  if (div < 10)
    a[1]=div+'0';
  else
    a[1]=(div+'A')-10;
  val -= div * 36;

  if (val < 10)
    a[2]=val+'0';
  else
    a[2]=(val+'A')-10;
}

A small test shows it works:

int main(int argc, char ** argv) {
  int i, j;
  char buff[6];

  for (i=0; i<46656; i++) {
    integer_to_alphanum3(i, buff);
    buff[3]=0;
    j = alphanum3_to_integer(buff);
    if (j != i)
      printf("%s : %d != %d\n", buff, i, j);
  }
  printf("\n");
}

..

I soldered the test board and tested the whole hardware :-)

Not visible is the thick cable to the PSU to reduce losses (unlike the previous tests with a breadboard and ohmic losses here and there... Some measurements were off by maybe 10%)

There were a few issues, for example the mouse would continually reset when connected to the hub at the same time as the PSU. So I found a new USB cable... and now it works. There is no flow control with the PSU so I have to insert wait statements everywhere...

The following script is a crude example:

# configure and check PSU
TTY="/dev/ttyACM3"
ls $TTY
stty 9600 cs8 raw -echo -echoe -echonl -echoprt -echoctl -echoke -parenb -F $TTY
sleep .1
echo -n "*IDN?" > $TTY
sleep .1

#test the mouse souris
MOUSE="/dev/input/mouse1"
ls $MOUSE

#start in another terminal : od -An -v -w1 -t x1 $MOUSE

#turn off:
echo -n "OUT0" > $TTY
sleep .1
#set max current
echo -n "ISET1:0.060" > $TTY
sleep .1
#set output voltage
echo -n "VSET1:0" > $TTY
sleep .1
#turn on:
echo -n "OUT1" > $TTY
sleep 2

for i in 0 1 2 3 4 5 6 7 8; do
   echo -n "VSET1:"$i >> $TTY;
   echo $i"V";
   sleep .6;
done

for i in 7 6 5 4 3 2 1 0; do
   echo -n "VSET1:"$i >> $TTY;
   echo $i"V";
   sleep .5;
done

I won't go much further with Bash, because it's not practical enough. I'd use Python if I was better but I'll stick to C. 

Here is how it works so far :

At the end of the script, one terminal window shows that the mouse has sent 2 packets that indicate the relay closing and then opening : success !

Things to know : I have increased the series resistor to 100 ohms because it increases the resolution. The PSU can only set the output voltage with 10mV steps and a higher resistance increases the voltage required to latch the relay, so I get an equivalent resolution of 2.5mV (approx.). All the relays will be tested under the same conditions so the actual voltage doesn't matter, as long as the measurements cluster the values of similar coils.

The mouse has 3 buttons so I wired 3 sockets for the relays and I could test 3 sockets in parallel (with the appropriate SW)?

I have already observed pretty significant variations in the latching voltages of 3 relays... But better SW is required now.

A year ago I started to use my new digital PSU and the early logs are there : https://hackaday.io/project/20733-hot-logic/log/56927-and-the-psu. Today I have set it up again and these logs and the files are very helpful :-)

But first I had to connect my computer to the lab PSU, which are more than 2m apart. Fortunately I found in my stock a hub and enough AtoB USB cables to connect the PSU and the mouse close to the bench. It should be moderately practical :-)

Plugging the PSU through the hub :

[1069116.978946] usb 2-1.3: new full-speed USB device number 28 using ehci-pci
[1069117.058694] usb 2-1.3: New USB device found, idVendor=03eb, idProduct=3301
[1069117.058708] usb 2-1.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[1069117.058714] usb 2-1.3: Product: Standard USB Hub
[1069117.061972] hub 2-1.3:1.0: USB hub found
[1069117.062213] hub 2-1.3:1.0: 4 ports detected
[1069117.348953] usb 2-1.3.2: new full-speed USB device number 29 using ehci-pci
[1069117.461864] usb 2-1.3.2: New USB device found, idVendor=0416, idProduct=5011
[1069117.461878] usb 2-1.3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1069117.461884] usb 2-1.3.2: Product: USB Virtual COM
[1069117.461889] usb 2-1.3.2: Manufacturer: USB Vir
[1069117.461894] usb 2-1.3.2: SerialNumber: NT2009101400
[1069117.465957] cdc_acm 2-1.3.2:1.0: ttyACM3: USB ACM device

yup, the same /dev/ttyACM3 as before :-)

From now on, everything must be done by root, or the user should be added to the relevant group.

export TTY=/dev/ttyACM3

Then configure the serial port : file serial9600.sh

#!/bin/bash
#1 start, 8 data, 1 stop, no parity

TTY=/dev/ttyACM3
stty 9600 cs8 raw -echo -echoe -echonl -echoprt -echoctl -echoke -parenb -F $TTY

 And now we can talk !

on one terminal, display the port's output with

# od -An -v -w1 -t c /dev/ttyACM3 

 In another terminal, send a SCPI command :

echo -n "*IDN?" > $TTY

I get the following result :

[root@localhost yg]# od -An -v -w1 -t c /dev/ttyACM3 
   K
   O
   R
   A
   D
   K
   A
   6
   0
   0
   2
   P
   V
   2
   .
   0
  \0

It's working !

The relevant vocabulary is quite simple :

• Identify :

  echo -n "*IDN?" > $TTY

• Turn output off :

  echo -n "OUT0" > $TTY 

• Turn output on :

  echo -n "OUT1" > $TTY 

• Set max. current to 0.42A :

  echo -n "ISET1:0.42" > $TTY

• Read back the max. current setting :

  echo -n "ISET1?" > $TTY 

• Read the actual output current :
  

  echo -n "IOUT1?" > $TTY 

• Set the output voltage to 12.34V :

  echo -n "VSET1:12.34" > $TTY

• Read back the voltage setting :

  echo -n "VSET1?" > $TTY 

• Read the measured output voltage :

  echo -n "VOUT1?" > $TTY 

• Read the status :

  echo -n "STATUS?" > $TTY

  (the result is binary and the bits must be interpreted)
  

• Some more commands exist (see the references in the previous log) but I'll only play with the voltage.

.

.

The new ReTest uses a mouse.

A nicely hacked mouse because I only need one input bit. Apparently this one can provide 3 so I could test 3 relays at the same time :-P

I found a used USB mouse with its wires and it perfectly fits my needs.

I only have to replace the buttons with the relay contacts :-) I leave the casing/wiring work for later...

Software is a different matter though, but not as difficult as it could have been. That's why using a mouse (a very common and mundane peripheral) is a great solution : cheap, widely used and very well documented.

First I had to disable it in Xorg : it's a matter of 1) finding the right peripheral 2) writing the right file at the right place. 1) is solved easily with dmesg, xinput, cat /proc/bus/input/devices ...

$ xinput list
⎡ Virtual core pointer              id=2   [master pointer  (3)]
⎜   ↳ PS/2 Generic Mouse            id=12  [slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad    id=13  [slave  pointer  (2)]
⎜   ↳ Logitech USB Optical Mouse    id=17  [slave  pointer  (2)]
...

$ dmesg
[1015128.994372] usb 2-1.3: new low-speed USB device number 86 using ehci-pci
[1015129.078062] usb 2-1.3: New USB device found, idVendor=046d, idProduct=c077
[1015129.078069] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[1015129.078073] usb 2-1.3: Product: USB Optical Mouse
[1015129.078077] usb 2-1.3: Manufacturer: Logitech
[1015129.083902] input: Logitech USB Optical Mouse as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.0/0003:046D:C077.0007/input/input62
[1015129.084707] hid-generic 0003:046D:C077.0007: input,hidraw1: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-0000:00:1d.0-1.3/input0

$ cat /proc/bus/input/devices | grep "Name\|Handlers"
...
N: Name="Logitech USB Optical Mouse"
...
$ less /proc/bus/input/devices
...
I: Bus=0003 Vendor=046d Product=c077 Version=0111
N: Name="Logitech USB Optical Mouse"
P: Phys=usb-0000:00:1d.0-1.3/input0
S: Sysfs=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.0/0003:046D:C077.0006/input/input61
U: Uniq=
H: Handlers=mouse3 event17
...

The last command shows that the device is handled by /dev/input/mouse3 and /dev/input/event17. This is easily verified.

2) the right file is a new file in /etc/X11/xorg.conf.d/01-no_optical_mouse.conf

Section "InputClass"
   Identifier     "Desactive souris Logitech"
   MatchIsPointer "on"
   Driver         "evdev"
   MatchProduct   "USB Optical Mouse"
   MatchVendor    "Logitech"
   Option         "Ignore" "true"
EndSection

 After I restarted the X server, the mouse is now mute and deaf, but I still can read data from it !

sudo od -An -v -w1 -t x1 /dev/input/mouse3
 09
 00
 00
 08
 00
 00

 that's the binary dump when I press and release the left button.

The binary protocol is really straight-forward so now I focus on the PSU...