Close
0%
0%

ReTest-yg

YG's own version of Mateng's ReTest, but with different features and a palindromic project number!

Similar projects worth following
As I'm playing with miniature relays from another age, I find that some of them have significant variance from the rest, which might create problems in the sensitive circuits I design.
I need to "bin" them and an automatic test rig is required.
Mats did something close but that is not adapted: I need current/voltage measurements to characterise the coil. And I don't use arduinos so I though "I'm just going to build a RPi adapter."

Well, 2 years later, I come back to this project and I simplify it, get rid of the RPi, use a mouse as input device (to read the relay output) and exploit the programmability of my latest digital PSU, so I can do everything on my main Linux laptop, over USB...

20181108 : project reboot !
The text below is a bit outdated but the purpose is still the same: test relays. However I only measure the hysteresis voltages now.


The РЭС15 are low-voltage small-signal relays built in Soviet Russia, brought to us by the magic of eBay. I use a certain quantity in #AMBAP: A Modest Bitslice Architecture Proposal and #SPDT16: 16-bits arithmetic unit with relays

In another page (Pre-Biased, or Hysteresis Relay Logic) I gather some measurements and find some outsiders that diverge about 20%. In practice, this can be enough to destabilize the circuit, particularly the latch bits that rely on magnetic hysteresis.

@matseng has designed his own relay timing analyser: #ReTest - Relay timing tester which I'm not able to replicate and doesn't provide me with data I need (such as coil voltages and currents).

I'm more comfortable with the Raspberry Pi (first generations) and this project is a good opportunity to play with some 74HC parts, precision current generators and other funky analog and digital circuits...


Logs:
1. Sampling
2. SPI Interface
3. Programmable current generator
4. Reboot !
5. Relevant datapoints
6. Got mouse.
7. And the PSU (bis)
8. First automated ramps
9. Relay labelling
10. Increase the resolution again...
11. Mouse button handling in C
.

buttons.c

asynch. read the status of the 3 mouse buttons and tells if something changed.

text/x-csrc - 1.69 kB - 11/19/2018 at 03:15

Download

FP23.c

fixed point 2.3 ascii format conversion in C

x-csrc - 2.34 kB - 11/18/2018 at 09:13

Download

AN3.c

convert between integer and base36 marking

x-csrc - 1.35 kB - 11/18/2018 at 08:00

Download

octetstream - 1.12 MB - 11/07/2016 at 23:55

Preview
Download

octetstream - 7.61 MB - 11/06/2016 at 21:24

Preview
Download

View all 8 files

  • Mouse button handling in C

    Yann Guidon / YGDES11/18/2018 at 15:24 0 comments

    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.

  • Increase the resolution again...

    Yann Guidon / YGDES11/18/2018 at 06:09 0 comments

    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 ?

  • Relay labelling

    Yann Guidon / YGDES11/18/2018 at 03:21 0 comments

    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");
    }
    

    ..

  • First automated ramps

    Yann Guidon / YGDES11/12/2018 at 05:08 0 comments

    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.

  • And the PSU (bis)

    Yann Guidon / YGDES11/11/2018 at 19:55 0 comments

    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.

    .

    .

  • Got mouse.

    Yann Guidon / YGDES11/11/2018 at 07:07 0 comments

    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...


    Update : 20181118 see log 10.Mouse button handling in C

  • Relevant datapoints

    Yann Guidon / YGDES11/09/2018 at 03:02 0 comments

    Given the new situation and hardware availability, what should it do and how should it work ? What is the characteristic that determines then binning ?

    So far, I think that the meaningful data is the average between the open and closed voltages. The early measurements show that there is a significant variation of those characteristics and the operating margin is reduced when the max. release voltage in a group gets near the min. latch voltage of another relay, whose coil has characteristics shifted toward the lower voltages.

    The algorithm I consider will take the dump of all the measurements, in the form of a file (in CSV or JSON) containing the min and max voltages, followed by the serial number.

    From these values, calculate the average (or sum?) and difference (the margin).

    Sort all the values by the difference, and remove the lowest ones (which provide the least operating margin).

    Then sort all the values by the averages, such that bins can be easily made by splitting the list in roughly equal sub-lists.

    And there you have it : a list of lists of serial numbers of the relays that will be soldered together.

    For the 8×8-bits register set, that's 8 bins, and I suppose at least half of the measured relays will be rejected so more than 120 relays must be measured. The resulting sets will be more resilient to power supply variations.

    Now I have to build the test rig, write the software, and get to work by measuring 4 boxes of relays...

  • Reboot !

    Yann Guidon / YGDES11/08/2018 at 03:22 4 comments

    I should return to this project since #YGREC8 makes progresses !

    I'm considering a much simpler approach where the relays are tested "in condition", as a latch. No more voltage measurement or current control. In fact, things have changed since the last logs : I now have a computer-controllable PSU that can receive orders from my laptop !

    I'm also avoiding RPi now. I haven't powered one up for more than a year and I don't miss it. I like the convenience of my computer and it can already do some limited IO with the digital PSU. So what's remaining is the input... I don't have a SPI input on that PC so I must also use a USB serial adapter :-(

    What will I measure ? I reduce the system to its basic purpose : measure the voltage where the relay latches and releases (if possible, a few cycles to get a better average). The input is just a single bit, coming from the relay's contact. It must then be possible to hack a USB thingy to act as that binary input. A keyboard ? No. A mouse ? ah, we're getting somewhere :-)

    So let's take a USB mouse with 2 buttons. The rotary encoder is left alone, and one button orders to start the test sequence, and the 2nd input is the output from the RUT (Relay Under Test). Our program will poll the buttons and talk to the digital PSU, ramping the output voltage up and down. When the sequence starts, the output voltage will slowly increase until the relay closes, then decrease until the relay opens. The cycle is repeated a few times and each value (except the first ones because hysteresis has not settled) are sampled and computed.

    A serial number is allocated and marked on each relay while their characteristics are stored in a file. After testing tens of relays, the file can be analysed, sorted and binned.

    That sounds like an ice plan.

  • Programmable current generator

    Yann Guidon / YGDES11/01/2016 at 15:10 0 comments

    The last time I designed a test rig, it had a crude but cute 4-bits R/2R ladder with a 2N2219 (metal can with hfe=100) for current amplification. It was nice enough to inject increasing amount of current into the DUT's Vcc input in 17 steps (0..15 and full-on with a 5th bit, so yeah, 5 bits DAC).

    For this system, I need something more accurate and more resolution : ideally sub-mA resolution (100µA resolution but not necessarily accuracy since accuracy will be relative and correlated between all the measurement). Maximum required current in 100mA so a 1024 steps generator works to measure significant data.

    But this is not as easy as it seems, each chosen topology has their own inconvenients.


    The original R/2R-Ladder version is not precise or accurate, but this was not the purpose, I just wanted to inject "some current". It was actually not that inaccurate, BTW, but the BJT can drift with temperature and power supply voltage... Furthermore, the bipolar transistor's threshold voltage of approx. 0.7V means that the very first steps are ineffective.

    I've used a trick though : the NPN transistor is mounted "high side" so the initial current is actually the 1/100th base current coming from the R/2R ladder. Short circuits are very easy to spot early withouth any damage. The ladder is powered from a 74HCT273 (octal latch with reset) tied to 5V so full-scale will provide 5V on the BJT's base, and the DUT's voltage can be measured (a high-side resistor heps infer the actual current).

    Maximum supplied voltage is around 5-0.7=4.2V (depending on Rsense drop), full 5V is then provided with a P-MOSFET to short all that when we're sure the circuit's ramp-up curve is clean. It's pretty neat and safe to detect shorts on the power rails but not suitable for coil characterization.


    In the current case, I need accuracy and resolution. Hence, some kind of feedback. Also, from past experiences, I must reduce the count of reference voltages to the least possible. A single 4.096V reference should be enough, so all the drifts are proportional and cancel each others. After all, I want to group relays in "similar" bins, I don't have an "absolute" requirement, they should be as close to each other as possible.

    The same device (ADC) must measure the coil voltage and the current. Using Ohm's law, we can make a simple string, for example with a sense resistor on the lower side, and the DUT just above.

            Rsense      coil       Transistor
    0V |----\/\/\/----o  DUT  o--------T-----| 5V
              10      ^  39   ^
                     V1       V2
    The coil voltage is relative but not critical, it can be obtained from V2-V1. V1 gives an absolute reading of the current .

    This simplifies the grounding and there are only 2 voltages to measure. This topology is easy on the DAC because these nodes are low impendance, which should reduce the inaccuracies created by high-impedance transmission. A 12-bits ADC with 4.096V reference will have a 1mV bit-step, or 100uA step. Very nice.

    The Rsense is easy to calculate: given maximum 100mA and 1V drop (leaving 4V headroom for the DUT+Transistor), Rsense=1V/0.1A=10 Ohms.

    Do I have 0.1% 10 Ohms resistors in stock ? I found 1/2W 10 Ohms resistors that should fit but I can't validate the absolute value and accuracy with my lousy tools. Power would not exceed 1V×0.1A=0.1W so 1/2W provides a comfortable margin. Current-induced temperature drift will be low thanks to the ceramic package.

    (Just in case, I ordered some 1% parts)

    OK I got 1% 10 Ohms resistors. How can I get a better precision ? A series-parallel connection can even out the little differences. It takes 4 resistors, but can also sustain 4× more power.

    |----\/\/\/-------\/\/\/---|
    |                          |
    |----\/\/\/-------\/\/\/---|

    Well, that was the easy part. The hard part is how the heck am I going to feed the current into this R-DUT chain ?

    A high-side transistor is required. I'm not sure what kind, yet, though, but more important is how to control it.

    I don't trust the PWM output of the Pi for a cheap/crude DAC, nor the previous R/2R ladder. Ideally,...

    Read more »

  • SPI Interface

    Yann Guidon / YGDES11/01/2016 at 13:46 0 comments

    The RPI is not a true real-time system, unlike a common microcontroller.

    How do I evenly sample the inputs ? RPi SW can have some serious jitter (been there, done that...) but I have solved this for some years now, using the FIFO of the SPI port.

    At a reasonable speed (in the 100K/1MBps range), the 16 bytes are enough to shield the system from interferences. JUST AVOID INTERLEAVING READS AND WRITES TO THE I/Os or the bus turnaround time will give you a penalty of 1/2µs.

    In non-interruptible task mode, running as root, the kernel will interrupt the task once per second, which is well above the 5ms sampling time of a transition. Just don't forget to yield to the kernel after each sequence (nanosleep() ?) and you'll be safe.

    How many data points do we actually need ? I believe 1K is the most that is required. Current is more important for binning with my logic topology. I can use a real computer screen to show the histogram (in framebuffer mode ?)

    The other cool thing about the SPI port is the variable speed, which can be pretty finely tuned with the clock generator. But the UGLY secret of this port is the 9-bit scheduling, which inserts one dead bit cycle for every byte (I'm not kidding you, check with your scope !) so the actual sampling rate must be calculated carefully !

    .


    .

    (to be continued)

View all 11 project logs

Enjoy this project?

Share

Discussions

Yann Guidon / YGDES wrote 11/18/2018 at 07:47 point

Oh ! a cute little page about the РЭС15  :-D
http://www.155la3.ru/res15.htm

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/01/2016 at 13:37 point

Hopefully, this system will be a good basis to build the Ge PNP tester because I have even more transistors to test/bin for #Germanium ECL :-D

  Are you sure? yes | no

matseng wrote 11/01/2016 at 12:36 point

How would it work with using two mcu/cpu timers/counters, one of them driven with an inverted signal (unless the counter can increment on both rising and falling edges).  Then one could simply check the counter values to determine if any bouncing has occurred since the last poll of the counters.

One pair of counters would be required each for the NC respective NO contacts.

Of course there would be issues with the minimum high/low time of the counter clock, so really short pulses could be missed anyways, but a reasonably nice ARM mcu should(?) have counters that can operate in the range of 10's of MHz I guess.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/01/2016 at 12:41 point

what if the counter(s) wrap around ? They have to saturate, and we don't actually care about the count, so it goes back to a set/reset latch :-)

  Are you sure? yes | no

matseng wrote 11/01/2016 at 12:57 point

Well, if it was an 8 bit counter you'd be able to detect it anyways, as long as you don't get exactly 256 pulses between the samples). And with 16/32 bit counters there's basically no way that there will be that many pulses between samples.

Anyways you'd probably acquire data for a number of actuations  so even the 1/256 chance of losing a period of bounces between two 10us (or whatever period) samples wouldn't be a big deal.


I'd consider the ability of programmatically adjust the coil voltage and also measure the coil current and the back emf voltages to be more pressing issues if I'd make a new revision.


And for the measurement of coil voltages and currents there probably is a need for peak-hold circuity before the A/D's unless sampling at a really high speed....

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/01/2016 at 13:09 point

I'm not looking at microcontrollers so I'm not trying to work around their idiosynchrasies :-) Of course a 32 bits counter will be hard to overflow but you'd need 4 of them and this gets us into high-end MPU world (whereas a 74HC74 costs close to nothing, when you have one).

Yes, a hundred cycles will get a good picture of the bouncing behaviour but it also depends on your resolution and we're back in the sampling theory :-)

My approach to drive the coil is with a programmable current generator, I'm trying to figure that out now. I've already done a 4-bits current generator for another test rig but I'd need 256 steps of 0.25mA to get a reasonable resolution. The relays shouldn't need more than 64mA to turn on, otherwise they're "not good".

Because I'll control the coil current, I will only need to measure a stable voltage at the coil's pins. Back EMF peaks depend on the current change speed so it's not worth measuring (too application-specific).

I have a few more logs to write now :-D

  Are you sure? yes | no

matseng wrote 11/01/2016 at 13:19 point

Aha...  That's a kinda interesting approach to drive them with constant current - as long as the compliance voltage is high enough to get a reasonable constant current.

But would you drive the relays with constant current in a real operating situation?

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/01/2016 at 13:33 point

Not exactly constant current but have a look at these logs:

https://hackaday.io/project/14628-ambap-a-modest-bitslice-architecture-proposal/log/45484-my-first-pre-biased-relay-logic-gates

https://hackaday.io/project/14628-ambap-a-modest-bitslice-architecture-proposal/log/45438-pre-biased-or-hysteresis-relay-logic

The coil current becomes an important factor, and it drifts under use so 20% of initial variation in the relay can upset some bits when the machine heats up. I store bits with hysteresis (cheap! fast! easy!) and I don't want them to be altered :-)

Additionally, I try to optimise the power consumption which is affected a lot by the high-fanout control signals. If I set the driving current to 65mA for a string (absolute worst case to turn all relays on), I consume more energy than if I set it to 55mA (worst case for most relays). That's why I need to bin with current.

Back EMF is not a concern with my topologies: my scope shots show no overshoot. A small cap helps, but the bias resistor provides a reasonable dissipative current path (no diode) and the current swing is lower than usual systems, so less energy to evacuate.

My pre-biased relay system is more or less a curren-driven one, in fact, so yes it's important to measure it :-)

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates