Soltec HM-102S: unboxing a 30 year old multimeter

Graham Green had a stall at Make Change yesterday. Graham’s the former manager of Active Surplus, the much-missed Toronto surplus emporium. He had some military-surplus multimeters that hadn’t seen daylight since I was in school. That’s a while back: this (unfortunately) was #1 the week I left school. So I bought one of Graham’s meters just to see what was inside …

Neatly packed in mil-spec cardboard with a date code of 7/86. There’s a fair chance that Papa Don’t Preach was on the radio somewhere when this was sealed …
Inside the box, the meter’s sealed in a pouch. Mil-spec doesn’t allow anything to rattle about, after all. Unlike some surplus stuff, this looks 99.999% mouse-piss free
Under the meter was this battery pouch, which exhibited the qualities of both “crunchy” and “squishy”. Neither of these are things I look for in a battery, so these weren’t going in the meter
Battery pack dated January 1986. This isn’t going to be good.
Daylight — for the first time in 31 years! On first glance, everything looks okay, but three decades of phenolic off-gassing was much in evidence — pew!
Despite the hermetic seal, the elastic band had rotted to dry pasta consistency. Note expired band ichor on the manual cover
The test leads are still bright, shiny and very pliable. I suspect they might be silicone-encased, as PVC of this age has a habit of turning brittle (ask me about my late lamented Konix Navigators)
The meter. unpacked. A clear (if small) dial, complete with mirror scale to reduce parallax error in reading. Hidden under the frosted cover is a small “Made in Korea” mark
Handy-dandy fold-out carrying handle that also doubles as a stand
Inside the case, ancient tooling marks. The plastic is thick and seems fairly robust. The captive mounting screw was a nice touch
A very analogue meter. Lots and lots of 1% tolerance resistors on the main board, plus a great big thumbwheel potentiometer for zero adjustment. The foam battery pad up top was as good as new
Up and running: no auto-off battery saving mode here! The test lead jacks didn’t have the shrouding we’d expect these days, so you won’t be able to use newer probes without modifying them
Things I Don’t Miss from Analogue Meters, #1: setting the 0 Ω point. Expect fiddliness and drift.
The test subjects: a 3.6 V Li/SOCl₂ ½-AA NVRAM battery (new: tests at 3.68 V on an Agilent U1242B meter), a 7.5 kΩ ± 5% resistor (tests at 7.52 kΩ) and a 39 kΩ ± 10% resistor (tests at 41.3kΩ)
Battery test: the Soltec reports 3.8 V, or within 5% of expected. This is where I really miss auto ranging
Not so good is the 7.5 kΩ resistor: the Soltec reads just under 6 kΩ. Blame faulty zero setting from me, as it really is fiddly and I just set this up quickly.
The 39 kΩ resistor (which is really more like 41 kΩ) indicated 34 kΩ on the Soltec. Again, my dodgy zero set is most likely to blame, but reading this little log scale isn’t the easiest

Would I recommend the Soltec as a general purpose meter? Not really. There are more capable multimeters available for about the same price, and you don’t need to go as far as the unbelievably expensive Agilent DMM I use (or even the strictly ornamental analogue ex-Forces Bach-Simpson 635 multimeter that graces/clutters my workbench). It would need a video to show where analogue meters excel: in showing changing values and getting a rough idea of the limits. It would make a great battery tester, or — if coupled with a micro-controller with PWM or DAC ouput — part of a demo rig. If nothing else, it’s a great way to learn how to appreciate modern test gear and all it does for us.

I’m probably going to regret this, but here’s a scan of the Soltec HM-102s manual:

PDF link under image. I say I regret doing this, ‘cos every cheapo ebay seller of these things is now likely to download this and splat their own horrid watermarks over it, making the file huge and ugly. But the market’s gonna market, and I wouldn’t want to make a free manual inaccessible with DRM. By contrast, my watermark’s quite tasteful and doesn’t interfere with readability in any way …
Postscript: you think I’d just throw away that expired battery pack without peeking inside? If so, allow me to call you Wrongo McWrongison of that erroneous ilk! The ‘Hipower Super’ cells weren’t looking so super: the leaked electrolyte had dried into a gritty, stinky layer. I couldn’t even find the terminals on the 9 V battery to try and test it, so grotty was the corrosion. Amazingly, the slightly-less-nasty AA cell at the front tested at 1.52 V, almost as good as it could have been in the mid-80s. Doesn’t mean it’s not going in the HHW bin with the others, though.

The All-Seeing Googly Eyes of Lisa Frank

… or what you get if you video concentric RGB LED rings and put them out of focus.

No shortage of lens flare here

fritzing: Generic 4×4 Keypad part

This needs work, but I made this keypad part for Fritzing:

Part file (zipped): Generic_4x4_Keypad.zip

You’ll see these parts described as variations on “4×4 Matrix 16 Keypad Keyboard Module 16 Button” on ebay. They’re very simple: if you press a button (say S7), the row pins (R1-4; R2 for S7) and the column pins (C1-C4; C3 for S7) are connected. So pins R2 and C3 are connected when S7 is pressed. You can use the Arduino Keypad library to talk to these, but do remember they use up 8 I/O pins.

It’s not internally routed in Fritzing, and you likely won’t be able to use it for any kind of schematic work, but who uses Fritzing for anything other than pretty pictures?

Teensy USB Keypad

in which I finally learn about Fritzing’s wire alignment facility …

I’ve had a couple of Teensy boards for a while, but a misunderstanding that they needed a load of of extra software installed (they need one thing, and it’s easy) had kept me away. They’ve got really impressive specs, and they’re especially easy to turn into USB devices like keyboards.

Super-heavy CEECO keypad

Here’s a little demo that turns a phone keypad — in my case, a ridiculously solid CEECO solid metal keypad designed for institutional use — into a simple USB keyboard. Plug it into any machine (including a Raspberry Pi) and it will be identified as a keyboard. No drivers are required.

The code is based on the standard Arduino Keypad library basic demo. That code was meant for a different keypad, so I eventually found a configuration that worked in the Sparkfun 12 button keypad datasheet. Rather than printing characters to the serial port, I used calls to Teensy’s USB Keyboard library instead.

There’s no reason why this wouldn’t work with those very cheap 4×4 button matrix keypads for Arduino too with only minor modifications. Those keypads use 8 data lines, and they’re arranged (I think) as rows 1-4 on pins 1-4 and columns 1-4 are pins 5-8.

The Teensy USB keyboard isn’t limited to sending single characters: a single button press could trigger sending a whole string. I haven’t yet thought out any major uses for this (except “Crypto!”, which is my usual idea when I have no idea what I’m doing), but you might have better plans.

SuperLanterns Last All Summer Long

I’m Scottish. For Hallowen, it’s traditional to make lanterns out of turnips. How this was done before power tools, I’ll never know.

In 2015, I decided to make a traditional neep (that’s Scots for turnip) lantern. Yes, I used a holesaw, and turnip goo went everywhere.

Neep Lantern — Age: 0 days

It looked pretty good on the day:

Neep Lantern — Age: 1 day (Halloween)

Unlike pumpkins, turnips last. I left it out in the front garden.

Neep Lantern — Age: 43 days

It went very wizened:

Neep Lantern — Age: 124 days

It disappeared towards the end of May 2016. This was the last time I saw it:

Neep Lantern — Age: 203 days

Creating a systemd user service on your Raspberry Pi

Flushed with success from yesterday’s post where I made my first systemd service, I got carried away and wanted to show you how to create a service that runs as a regular user.

A fairly common question on the Raspberry Pi Forums is “How do I run a script every time I reboot?”. The traditional answer (and one I’ve given more than once) is to add a @reboot clause to your crontab. This will indeed run a command when the computer reboots, but it will run pretty early on in the boot sequence when there’s no guarantee of network or time services. So the usual remedy is a bit of a kludge:

@reboot sleep 60 && 

This waits a full minute after rebooting, then executes the command. Network and time services are really likely to be available, but it’s not very elegant. Cron also has some weird gotchas with PATH settings, so while it’s ubiquitous and has worked for decades, it’s not easy to get working. Systemd, however, has a much better way of doing it, and better yet, you can do it all without ever hitting sudo.

I’ll take as a basis for this post the forum query “python and crontab”. The asker wanted to log the time when their Raspberry Pi had rebooted, but they’ve hit the usual problem that the clock didn’t have the right time when their script was triggered, so the log was useless.

(I’m not going to do exactly what the forum poster did, but this is more a demo of a systemd user service than recreating their results.)

First off, here’s the script to log the time to a file (saved as ~/bin/boot_time.py):

#!/usr/bin/python3
from time import strftime
with open("/home/pi/logs/boot_time.txt", "a") as log:
 log.write(strftime("%d-%m-%Y,%H:%M:%S\n"))

I’d have done this as a shell script, but the OP used Python, so why fight it?

FUN FACT: Under most Linux flavours, if you create a bin folder in your home directory, it’s automatically added to your path. So I could just type boot_time.py and the shell would find it.
(You might have to log out and log back in again for the shell to review your path.)

In order to get that to run, I need to do a little housekeeping: make the script executable, and make sure the logs folder exits:

chmod +x ~/bin/boot_time.py
mkdir -p ~/logs

Now we need to do the bits that pertain to systemd. First off, you must make a folder for user services:

mkdir -p ~/.config/systemd/user

NOTE: mkdir -p … is useful here as it makes the directory and any parent directories that don’t exist. It also doesn’t complain if any of them already exist. It’s kind of a “make sure this directory exists” command. Make friends with it.

And here’s the service file, which I saved as ~/.config/systemd/user/boot_time_log.service:

[Unit]
Description=boot time log
DefaultDependencies=no
After=local-fs.target time-sync.target

[Service]
Type=oneshot
ExecStart=/home/pi/bin/boot_time.py

[Install]
WantedBy=default.target

The service file does the following (even if I’m slightly mystified by some of the headings …):

  • Unit
    • Description — a plain text name for the service. This appears in logs when it starts, stops or fails.
    • DefaultDependencies — as this service runs once at boot-up, it doesn’t need the normal systemd functions of restarting and shutting down on reboot. Most service files omit this line.
    • After — here we tell systemd what service targets must be running before this service is started. As we need to write to a file and have the right time, the local-fs.target and time-sync.target seem sensible.
  • Service
    • Type — this is run once, so it’s a oneshot rather than the usual simple service.
    • ExecStart — this is the command to run when the service is required.
  • Install
    • WantedBy — tbh no idea what this does, but if you omit it the service won’t install. Found the answer in this SE, and it works. So I guess what it does is make the service not fail

Finally, you enable the service with:

systemctl --user enable boot_time_log.service

Next time you reboot, the time will be appended to the log file ~/logs/boot_time.txt.

Unlike most (that is, Type=simple) services, it’s perfectly fine if this one spends most of its time inactive:

$ systemctl status --user boot_time_log.service
● boot_time_log.service - boot time log
 Loaded: loaded (/home/pi/.config/systemd/user/boot_time_log.service; enabled;
 Active: inactive (dead) since Sun 2017-10-22 22:17:56 EDT; 1h 5min ago
 Process: 722 ExecStart=/home/pi/bin/boot_time.py (code=exited, status=0/SUCCES
 Main PID: 722 (code=exited, status=0/SUCCESS)

It has executed successfully, so the process doesn’t have to stick around.

Combined Restart / Shutdown Button for Raspberry Pi

A very simple systemd service for Raspberry Pi that provides a software-controlled restart / shutdown button. Code: scruss/shutdown_button

Use

Default behaviour is:

  • your Raspberry Pi will reset if the button is held for more than two seconds but fewer than five seconds;
  • your Raspberry Pi will shut down if the button is held for more than five seconds.

By default, the software assumes the switch is connected to pin BCM 27. Both the pin and the timing can be changed in the Python source file.

Requirements

Hardware

  • A Raspberry Pi (tested on a model 2B, 3B and Zero, and on a model B after minor software modification)
  • A normally open, momentary contact button. I use surplus ATX power buttons (as used on desktop PCs), as they’re cheap and come with a handy set of wires and header connectors. Virtually any button will do the job, though. Just make sure it’s normally open (push to close).

Software

  • A Debian-based operating system that uses systemd (tested on Jessie and Stretch)
  • the python3-gpiozero package to provide GPIO Zero (tested on version 1.4.0)

Installation

Hardware

40-pin GPIO connector (B+, 2B, 3B, Zero)

Connect the button between GPIO 27 and GND. If you use an ATX power button and a Raspberry Pi with a 40-pin GPIO header, connect it across the seventh column from the left:

            -
· · · · · ·|·|· · · · · · · · · · · · · 
· · · · · ·|·|· · · · · · · · · · · · · 
            -

This shorts GPIO 27 (physical pin 13) to ground (physical pin 14) when the button is pressed.

26-pin GPIO connector (models B and A only)

GPIO 27 is not exposed on the original Raspberry Pi header, so GPIO 17 is a reasonable option. If you use an ATX power button and a Raspberry Pi with a 26-pin GPIO header, connect it across the fifth and sixth columns of the second row:

 . . . . ._. . . . . . . .
 . . . .|. .|. . . . . . .
          -

You will also need to change [line 7 of shutdown_button.py](https://github.com/scruss/shutdown_button/blob/master/shutdown_button.py#L7) to read:

use_button=17

Software

The software is installed with the following commands:

sudo apt install python3-gpiozero
sudo mkdir -p /usr/local/bin
chmod +x shutdown_button.py
sudo cp shutdown_button.py /usr/local/bin
sudo cp shutdown_button.service /etc/systemd/system
sudo systemctl enable shutdown_button.service
sudo systemctl start shutdown_button.service

Troubleshooting

Enabling the service should produce output very similar to:

Created symlink /etc/systemd/system/multi-user.target.wants/shutdown_button.service → /etc/systemd/system/shutdown_button.service.

You can check the status of the program at any time with the command:

systemctl status shutdown_button.service

This should produce output similar to:

● shutdown_button.service - GPIO shutdown button
   Loaded: loaded (/etc/systemd/system/shutdown_button.service; enabled; vendor 
   Active: active (running) since Sat 2017-10-21 11:20:56 EDT; 27s ago
 Main PID: 3157 (python3)
   CGroup: /system.slice/shutdown_button.service
           └─3157 /usr/bin/python3 /usr/local/bin/shutdown_button.py

Oct 21 11:20:56 naan systemd[1]: Started GPIO shutdown button.

If you’re seeing anything other than Active: active (running), it’s not working. Does the Python script have the right permissions? Is it in the right place? If you modified the script, did you check it for syntax errors?

The output from dmesg will show you any error messages generated by the service.

Modifications

If you use a HAT/pHAT/Bonnet/etc. with your Raspberry Pi, check pinout.xyz to see if it uses BCM 27. If you do need to change the pin, best to pick one that doesn’t have a useful system service like serial I/O or SPI. If you’re using an ATX button with a two pin connector, make sure you choose a pin physically adjacent to a ground pin.

If you modify the timing, please ensure that you keep the shutdown button press duration longer than the reboot one. Otherwise you’ll only be able to shut down.

Notes

You should not need to reboot to enable the service. One machine of mine — a Raspberry Pi Zero running Raspbian Stretch — did need a reboot before the button worked.

The reboot code is based on the Shutdown button example from the GPIO Zero documentation.

This is not the only combined shutdown/reset button project to use GPIO Zero. gilyes/pi-shutdown also does so, but pre-dates the implementation of the various hold time functions in GPIO Zero.

GPIO 27 was used, as it’s broken out onto a physical button on the Adafruit PiTFT+ display I own.

This is my first systemd service, and I’m still at the “amazed it works at all” stage. The service file may not contain the ideal configuration.

Connector Pinouts

From GPIO Zero’s pinout command

40 pin

   3V3  (1) (2)  5V    
 GPIO2  (3) (4)  5V    
 GPIO3  (5) (6)  GND   
 GPIO4  (7) (8)  GPIO14
   GND  (9) (10) GPIO15
GPIO17 (11) (12) GPIO18
GPIO27 (13) (14) GND   
GPIO22 (15) (16) GPIO23
   3V3 (17) (18) GPIO24
GPIO10 (19) (20) GND   
 GPIO9 (21) (22) GPIO25
GPIO11 (23) (24) GPIO8 
   GND (25) (26) GPIO7 
 GPIO0 (27) (28) GPIO1 
 GPIO5 (29) (30) GND   
 GPIO6 (31) (32) GPIO12
GPIO13 (33) (34) GND   
GPIO19 (35) (36) GPIO16
GPIO26 (37) (38) GPIO20
   GND (39) (40) GPIO21

26 pin

   3V3  (1) (2)  5V    
 GPIO0  (3) (4)  5V    
 GPIO1  (5) (6)  GND   
 GPIO4  (7) (8)  GPIO14
   GND  (9) (10) GPIO15
GPIO17 (11) (12) GPIO18
GPIO21 (13) (14) GND   
GPIO22 (15) (16) GPIO23
   3V3 (17) (18) GPIO24
GPIO10 (19) (20) GND   
 GPIO9 (21) (22) GPIO25
GPIO11 (23) (24) GPIO8 
   GND (25) (26) GPIO7