Advertisements

Archive for category Software

Cylindrical Cell Adapters

An octet of Eneloop AAA cells arrived, I wanted to measure their as-delivered charge (the package says “Factory Charged With SOLAR ENERGY”, so you know it’s good), and discovered I’d given away my AAA cell holders. You can actually get inter-series adapters on eBay, but what’s the fun in that? Plus, I didn’t want to delay gratification for a month; you know how it is.

Soooo:

AAA to AA Adapter - top - Slic3r

AAA to AA Adapter – top – Slic3r

It’s basically an AA-size sleeve that fits over the AAA cell, with a lathe-turned brass post conducting juice from the + terminal of the inner cell outward:

AAA to AA Adapter - parts

AAA to AA Adapter – parts

Not much to look at when it’s assembled:

AAA to AA Adapter - assembled

AAA to AA Adapter – assembled

The AAA cell fits deliberately loose, because this goes into a metal clip holding everything firmly in place for the battery tester:

AAA to AA Adapter - in use

AAA to AA Adapter – in use

The source code tabulates the sizes of several cylindrical cells, exactly zero other pairs of which have been tested; I expect most won’t work correctly. In particular, the table entries should include the contact button OD and thickness for each cell, so that I can turn out the proper terminal for each pair of cells. If I ever need a different adapter, I’ll beat some cooperation out of that, too.

Discovered I needed an adapter after breakfast, started testing cells after lunch. Life is good!

The OpenSCAD source code as a GitHub Gist:

The original doodle:

AAA to AA Adapter - sketch

AAA to AA Adapter – sketch

Advertisements

4 Comments

Patient Sign-In FAIL

We must announce our arrival at the dentist by signing in through a web-based iPad app:

Dentist iPad sign-in - network fail

Dentist iPad sign-in – network fail

You’ll note the signal strength indicator in the upper left shows as much RF as one might reasonably expect from a router within line-of-sight across the room.

FWIW, I’m getting really tired of the hipster dark-gray on light-gray design ethos.

2 Comments

Raspberry Pi Slowdown

At first, the yard camera worked fine, but a few days later the stream of JPEG images would unpredictably stall. I connect to it through a public-key SSH session and, sometimes, the login would stall for tens of seconds and, with a session set up, various exciting operation like, say, htop would unpredictably stall; if I waited long enough, they’d complete normally.

This seemed familiar:

Samsung 16 GB Evo MicroSD card

Samsung 16 GB Evo MicroSD card

It’s a known-good card from a reputable supplier, not that that means much these days. The camera flash highlights the gritty silkscreen (?) texture of the orange overlay, but the production value seems high enough to pass muster.

Popping the card in my desktop PC showed:

  • It remains functional, at least to the extent of being mount-able and write-able
  • 3probe --time-ops /dev/sdb showed it still held 16 GB
  • fsck -fv /dev/sdb[12] shows no problems
  • Both partitions looked good

So I shrank the main partition to 7.5 GB, copied the image to the desktop PC’s SSD, fired up the Token Windows Laptop, ran the Official SD Card Formatter, and discovered that it thought the card had only 63 MB (yes, MB) available. That’s the size of the FAT boot partition, so I returned the card to the desktop PC, unleashed gparted on it, blew away the partitions, reformatted the whole thing to one 16 GB FAT32 partition, and stuck it back in the laptop, whereupon the Official Formatter agreed it had every byte it should.

A format-with-overwrite then proceeded apace; the card doesn’t support format-with-erase.

Back in the desktop, I copied the saved image back onto the card which, en passant, blew away the just-created FAT format and restored the Raspbian partition structure. The 8 GB of that copy proceeded at an average 12.1 MB/s. I did not watch the transfer closely enough to notice any protracted delays.

Back in the Pi, the card booted and ran perfectly, sending an image every second to the laptop (now running its usual Mint Linux) on the guest network:

Turkey flock in driveway - 2017-03-21

Turkey flock in driveway – 2017-03-21

SSH sessions now work perfectly, too, and commands no longer jam.

So it seems a good-quality MicroSD card can experience protracted delays while writing data, to the extent of tens of seconds, stalling the Pi in mid-operation without producing data errors or any other symptoms.

It’s not clear the Official Formatter does anything that simply copying the image back to the card wouldn’t also accomplish, although overwriting the entire 16 GB extent of the card exercises all the cells and forces the card controller to re/de/un/allocate bad blocks. If, indeed, the blocks are bad, rather than just achingly slow.

Moral of the story: Don’t use MicroSD cards as mass storage devices, at least not for industrial applications that require consistent performance.

,

6 Comments

Vacuum Tube Lights: Duodecar Rebuild

You’ll recall the LED atop the 21HB5A tube failed, shortly after replacing the bottom LED and rewiring the ersatz plate lead, which led me to rebuild the whole thing with SK6812 RGBW LEDs. So I printed all the plastic parts again, because the duodecar tube socket’s pin circle can fit into a hard drive platter’s unmodified 25 mm hole, then drilled another platter to suit:

Duodecar disk drilling

Duodecar disk drilling

The hole under the drill fits the 3.5 mm stereo socket for the ersatz plate lead, so it’s bigger than before.

I’ve switched from Arduino Pro Minis with a separate USB converter to Arduino Nanos with an on-board CH340 USB chip, because the fake FTDI chips on the converters are a continuing aggravation:

21HB5A base - interior

21HB5A base – interior

Adding those wire slots to the sockets definitely helps tidy things up; the wires no longer need a crude cable tie anchoring them to the socket mounting screws.

I wanted to drive the LEDs from the A7 pin, rather than the A3 pin I’d been using on the Pro Minis, to keep the wires closer together, but it turns out that A6 and A7 can’t become digital output pins. So I used A5, although I may come to regret the backward incompatibility.

In any event, the 21HB5A tube looks spiffy with its new LEDs in full effect:

21HB5A with RBGBW LEDs - cyan violet phase

21HB5A with RBGBW LEDs – cyan violet phase

I dialed the white LED PWM down to 32, making the colors somewhat pastel, rather than washed-out.

The Arduino source code as a GitHub Gist:

, , ,

1 Comment

Raspberry Pi Yard Camera

The yard camera I mentioned a few days ago consists of a Raspberry Pi 3 with an Official V2 Pi Camera peering through two layers of 1955-era window glass into our back yard:

Back Yard Camera setup - 2017-03-13

Back Yard Camera setup – 2017-03-13

Yes, that’s black duct tape holding it to the window pane. The extension cord draped across the floor gotta go, too.

This being a made-in-haste lashup, I used the streamEye MJPEG HTTP streamer, started from /etc/rc.local in the usual way:

logger -s Starting camera streamer
sudo -u pi sh -c '/home/pi/yardcam.sh' &
logger -s Camera running

The yardcam.sh script feeds one moderate-quality frame to the streamer every second:

/home/pi/streameye/extras/raspimjpeg.py -w 1280 -h 720 -r 1 -q 80 | streameye

MJPEG has a lot to dislike as a streaming video format. In particular, without any hint of inter-frame compression, the network usage gets way too high for any reasonable frame rate.

But it got the camera up & running in time for the March snowfall:

Fun in Snow - 2017-03-15

Fun in Snow – 2017-03-15

In a nod to IoT security, the Raspberry Pi’s wireless interface sits behind the router’s firewall on our guest network, with no access to the devices on our main network. The router passes a one-port peephole from the Internet to the Pi, which protects all the other services from unwarranted attention.

The router maintains a dynamic DNS record with a (not particularly) mnemonic URL, which seems better than an ever-changing dotted-quad IP address.

Because the router doesn’t support hairpin connections from the main network to the guest network, I can’t monitor the video from my desktop through the outwardly visible URL. Instead, I must fire up a laptop, connect to the guest network, then connect directly to the camera at camera.local.

You do not have a Need To Know for the URL; I’m sure it’ll appear on Shodan. I plan to take it down when the snow melts.

4 Comments

Raspberry Pi Streaming Radio Player: OLED Display

With the OLED wired up to the Raspberry Pi, the LUMA.OLED driver makes it surprisingly easy to slap text on the screen, at least after some obligatory fumbling around:

RPi OLED Display - Plenitude

RPi OLED Display – Plenitude

Connect the hardware, install the driver, then the setup goes like this:

import textwrap

from luma.oled.device import sh1106
from luma.core.serial import spi
from luma.core.render import canvas
from PIL import ImageFont

… snippage …

font1 = ImageFont.truetype('/usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf',14)
font2 = ImageFont.truetype('/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf',11)

wrapper = textwrap.TextWrapper(width=128//font2.getsize('n')[0])

StatLine = 0
DataLine = 17           # allow for weird ascenders and accent marks
LineSpace = 16

Contrast = 255          # OLED brightness setting

serial = spi(device=0,port=0)
device = sh1106(serial)
device.contrast(Contrast)

The Python Imaging Library below the LUMA driver supports Truetype fonts that look much better than the default fonts. For these tiny displays, DejaVu Sans comes close enough to being a single-stroke (“stick”) font and, being proportional, packs more text into a fixed horizontal space.

The textwrap library chops a string into lines of a specified length, which works great with a fixed-width font and not so well with a proportional font. I set the line length based on the width of a mid-size lowercase letter and hope for the best. In round numbers, each 128 pixel line can hold 20-ish characters of the size-11 (which might be the height in pixels) font.

It also understands hyphens and similar line-ending punctuation:

Felix Mendelssohn-
Bartholdy - Piano
Concerto No.01 in

It turns out whatever library routine blits characters into the bitmap has an off-by-one error that overwrites the leftmost column with the pixel columns that should be just off-screen on the right; it may also overwrite the topmost row with the bottommost row+1. I poked around a bit, couldn’t find the actual code amid the layers of inherited classes and methods and suchlike, and gave up: each line starts in pixel column 1, not 0. With textwrap generally leaving the rightmost character in each line blank, the picket-fence error (almost) always overwrites the first column with dark pixels.

Display coordinates start at (0,0) in the upper left corner, but apparently the character origin corresponds to the box around an uppercase letter, with ascenders and diacritical marks extending (at least) one pixel above that. The blue area in these displays starts at (0,16), but having the ascenders poke into the yellow section is really, really conspicuous, so DataLine Finagles the text down by one pixel. The value of Linespace avoids collisions between descenders and ascenders in successive lines that you (well, I) wouldn’t expect with a spacing equal to the font height.

The display has a variable brightness setting, called “contrast” by the datasheet and driver, that determines the overall LED current (perhaps according to an exponential relationship, because an α appears in the tables). I tweak the value in Contrast based on where the streamer lives, with 1 being perfectly suitable for a dark room and 255 for ordinary lighting.

The LUMA package includes a scrolling terminal emulator. With maybe four lines, tops, on that display (in a reasonable font, anyhow), what’s the point?

Instead, I homebrewed a panel with manual positioning:

def ShowStatus(L1=None,L2=None,L3='None'):
  with canvas(device) as screen:
    screen.text((1,StatLine),Media[CurrentKC][0][0:11],
             font=font1,fill='white')
    screen.text((127-(4*font1.getsize('M')[0] + 2),StatLine),'Mute' if Muted else ' ',
             font=font1,fill='white')

    screen.text((1,DataLine),L1,
             font=font2,fill='white')
    screen.text((1,DataLine + 1*LineSpace),L2,
             font=font2,fill='white')
    screen.text((1,DataLine + 2*LineSpace),L3,
             font=font2,fill='white')

Yeah, those are global variables in the first line; feel free to object-orient it as you like.

The LUMA driver hands you a blank screen inside the with … as …: context, whereupon you may draw as you see fit and the driver squirts the bitmap to the display at the end of the context. There’s apparently a way to set up a permanent canvas and update it at will, but this works well enough for now.

That means you (well, I) must mange those three lines by hand:

ShowStatus('Startup in ' + Location,
           'Mixer: ' + MixerChannel + ' = ' + MixerVol,
           'Contrast: ' + str(Contrast))

Chopping the track info string into lines goes like this:

if TrackName:
  info = wrapper.wrap(TrackName)
  ShowStatus(info[0],
             info[1] if len(info) > 1 else '',
             info[2] if len(info) > 2 else '')
else:
  ShowStatus('No track info','','')

Something along the way ruins Unicode characters from the track info, converting them into unrelated (and generally accented) characters. They work fine when shipped through the logging interface, so it may be due to a font incompatibility or, more likely, my not bothering to work around Python 2’s string vs. byte stream weirdness. Using Python 3 would be a Good Idea, but I’m unsure all the various & sundry libraries are compatible and unwilling to find out using programming as an experimental science.

The Python source code as a GitHub Gist:

,

3 Comments

SK2812 RGBW LED: Test Fixture

[Edit: The SK2812 in the title and elsewhere should be SK6812. If I change the title, then all the other links break. So it goes.]

An envelope of RGBW LEDs, allegedly with SK6812 controllers, arrived from halfway around the planet:

SK2812RGBW LEDs - as received

SK2812RGBW LEDs – as received

The yellow phosphor sauce poured atop the blue LED on the left that makes it glow white leaves the upper loop of two wire bonds sticking out, but I can’t fault ’em for that. The overall build quality looks better than the ill-fated WS2812 LEDs, although it’s hard to tell by looking.

I conjured a test stand from the vasty digital deep by tweaking the WS2812 mount:

SK6812 LED Array Test Fixture - Slic3r preview

SK6812 LED Array Test Fixture – Slic3r preview

Wiring up a 5×5 panel went as before:

SK2812RGBW test fixture - rear

SK2812RGBW test fixture – rear

The array test code adds another pixel channel and runs another raised sine wave with another random period, accomplished without much hackage.

With the warm-white LED at full throttle (MaxPWM = 255), the panel tends toward the pallid end of HSV space:

SK2812RGBW test fixture - front - W PWM255

SK2812RGBW test fixture – front – W PWM255

Dialing the white MaxPWM back to 32 crisps things a bit:

SK2812RGBW test fixture - front - W PWM32

SK2812RGBW test fixture – front – W PWM32

Of course, the RGBW data stream isn’t compatible with the RGB data stream, so vacuum tubes with SK6812 chips require a slightly different driver and I can’t mix the two chips on a single tube.

The Arduino source code as a GitHub Gist:

, ,

2 Comments