Shallow Thoughts : : Feb
Akkana's Musings on Open Source Computing and Technology, Science, and Nature.
Fri, 23 Feb 2018
Dave and I are giving a planetarium show at PEEC tonight on the analemma.
I've been interested in the analemma for years and have
written about it before,
here on the blog
and in the SJAA Ephemeris.
But there were a lot of things I still didn't understand as well as
I liked. When we signed up three months ago to give this talk, I had
plenty of lead time to do more investigating, uncovering lots of
interesting details regarding the analemmas of other planets,
the contributions of the two factors that go into the Equation of Time,
why some analemmas are figure-8s while some aren't,
and the supposed "moon analemmas" that have appeared on the
of the Day. I added some new features to the analemma script I'd
written years ago as well as corresponding with an expert who'd written
some great Equation of Time code for all the planets. It's been fun.
I'll write about some of what I learned when I get a chance, but
meanwhile, people in the Los Alamos area can hear all about it
tonight, at our PEEC show:
The Analemma Dilemma,
7 pm tonight, Friday Feb 23, at the Nature Center,
admission $6/adult, $4/child.
[ 10:23 Feb 23, 2018
More science/astro |
permalink to this entry |
Sat, 17 Feb 2018
In the previous article I talked about
input/output using shift registers for a music keyboard project.
I ended up with three CD4021 8-bit shift registers cascaded.
It worked; but I found that I was spending all my time in the
delays between polling each bit serially. I wanted a way to read
those bits faster. So I ordered some I/O expander chips.
I/O expander, or port expander, chips take a lot of the hassle out of
multiplexing. Instead of writing code to read bits serially, you can use I2C.
Some chips also have built-in pullup resistors, so you don't need all
those extra wires for pullups or pulldowns.
There are lots of options, but two common chips are the MCP23017,
which controls 16 lines, and the MCP23008 and PCF8574p, which each
handle 8. I'll only discuss the MCP23017 here, because if eight is good,
surely sixteen is better! But the MCP23008 is basically the same thing
with fewer I/O lines.
A good tutorial to get you started is
To Use A MCP23017 I2C Port Expander With The Raspberry Pi - 2013 Part 1
2, Python and
3, reading input.
I'm not going to try to repeat what's in those tutorials, just
fill in some gaps I found. For instance,
I didn't find I needed sudo for all those I2C commands in Part 1
since my user is already in the i2c group.
Using Python smbus
Part 2 of that tutorial uses Python smbus, but it doesn't really
explain all the magic numbers it uses, so it wasn't obvious how to
generalize it when I added a second expander chip. It uses this code:
DEVICE = 0x20 # Device address (A0-A2)
IODIRA = 0x00 # Pin direction register
OLATA = 0x14 # Register for outputs
GPIOA = 0x12 # Register for inputs
# Set all GPA pins as outputs by setting
# all bits of IODIRA register to 0
# Set output all 7 output bits to 0
DEVICE is the address on the I2C bus, the one you see with
i2cdetect -y 1 (20, initially).
IODIRA is the direction: when you call
bus.write_byte_data(DEVICE, IODIRA, 0x00)
you're saying that all eight bits in GPA should be used for output.
Zero specifies output, one input: so if you said
bus.write_byte_data(DEVICE, IODIRA, 0x1F)
you'd be specifying that you want to use the lowest five bits for output
and the upper three for input.
OLATA = 0x14 is the command to use when writing data:
bus.write_byte_data(DEVICE, OLATA, MyData)
means write data to the eight GPA pins. But what if you want to write to
the eight GPB pins instead? Then you'd use
OLATB = 0x15
bus.write_byte_data(DEVICE, OLATB, MyData)
Likewise, if you want to read input from some of the GPB bits, use
GPIOB = 0x13
val = bus.read_byte_data(DEVICE, GPIOB)
The MCP23017 even has internal pullup resistors you can enable:
GPPUA = 0x0c # Pullup resistor on GPA
GPPUB = 0x0d # Pullup resistor on GPB
bus.write_byte_data(DEVICE, GPPUB, inmaskB)
Here's a full example:
You can also talk to an MCP23017 using the WiringPi library.
In that case, you don't set all the bits at once, but instead treat
each bit as though it were a separate pin. That's easier to think
about conceptually -- you don't have to worry about bit shifting
and masking, just use pins one at a time -- but it might be slower
if the library is doing a separate read each time you ask for an input bit.
It's probably not the right approach to use if you're trying to check
a whole keyboard's state at once.
Start by picking a base address for the pin number -- 65 is the lowest
you can pick -- and initializing:
pin_base = 65
i2c_addr = 0x20
Then you can set input or output mode for each pin:
and then write to or read from each pin:
val = wiringpi.digitalRead(pin_no)
WiringPi also gives you access to the MCP23017's internal pullup resistors:
Here's an example in Python:
on GitHub, and one in C:
Using multiple MCP23017s
But how do you cascade several MCP23017 chips?
Well, you don't actually cascade them. Since they're I2C
devices, you wire them so they each have different addresses on the
I2C bus, then query them individually. Happily, that's
easier than keeping track of how many bits you've looped through ona
Pins 15, 16 and 17 on the chip are the address lines, labeled A0, A1
and A2. If you ground all three you get the base address of 0x20.
With all three connected to VCC, it will use 0x27 (binary 111 added to
the base address). So you can send commands to your first device at 0x20,
then to your second one at 0x21 and so on. If you're using WiringPi,
you can call mcp23017Setup(pin_base2, i2c_addr2) for your second chip.
I had trouble getting the addresses to work initially, and it turned
out the problem wasn't in my understanding of the address line wiring,
but that one of my cheap Chinese breadboard had a bad power and ground
bus in one quadrant. That's a good lesson for the future: when things
don't work as expected, don't assume the breadboard is above suspicion.
Using two MCP23017 chips with their built-in pullup resistors simplified
the wiring for my music keyboard enormously, and it made the code
cleaner too. Here's the modified code:
What about the speed? It is indeed quite a bit faster than the shift
register code. But it's still too laggy to use as a real music keyboard.
So I'll still need to do more profiling, and maybe find a faster way
of generating notes, if I want to play music on this toy.
[ 15:44 Feb 17, 2018
More hardware |
permalink to this entry |
Tue, 13 Feb 2018
I was scouting for parts at a thrift shop and spotted a little
23-key music keyboard. It looked like a fun Raspberry Pi project.
I was hoping it would turn out to use some common protocol like I2C,
but when I dissected it, it turned out there was a ribbon cable with
32 wires coming from the keyboard. So each key is a separate pushbutton.
A Raspberry Pi doesn't have that many GPIO pins, and neither does an
Arduino Uno. An Arduino Mega does, but buying a Mega to go between the
Pi and the keyboard kind of misses the point of scavenging a $3 keyboard;
I might as well just buy an I2C or MIDI keyboard. So I needed some sort
of I/O multiplexer that would let me read 31 keys using a lot fewer pins.
There are a bunch of different approaches to multiplexing. A lot of
keyboards use a matrix approach, but that makes more sense when you're
wiring up all the buttons from scratch, not starting with a pre-wired
keyboard like this. The two approaches I'll discuss here are
shift registers and multiplexer chips.
If you just want to get the job done in the most efficient way,
you definitely want a multiplexer (port expander) chip, which I'll
cover in Part 2. But for now, let's look at the old-school way: shift
PISO Shift Registers
There are lots of types of shift registers, but for reading lots of inputs,
you need a PISO shift register: "Parallel In, Serial Out."
That means you can tell the chip to read some number -- typically 8 --
of inputs in parallel, then switch into serial mode and read all the bits
one at a time.
Some PISO shift registers can cascade: you can connect a second shift
register to the first one and read twice as many bits. For 23 keys
I needed three 8-bit shift registers.
Two popular cascading PISO shift registers are the CD4021 and the SN74LS165.
They work similarly but they're not exactly the same.
The basic principle with both the CD4021 and the SN74LS165:
connect power and ground, and wire up all your inputs to the eight data pins.
You'll need pullup or pulldown resistors on each input line, just like
you normally would for a pushbutton; I recommend picking up a few
high-value (like 1-10k) resistor arrays: you can get these in SIP
(single inline package) or DIP (dual-) form factors that plug easily
into a breadboard. Resistor arrays can be either independent
two pins for each resistor in the array) or bussed (one pin in
the chip is a common pin, which you wire to ground for a pulldown or
V+ for a pullup; each of the rest of the pins is a resistor). I find
bussed networks particularly handy because they can reduce the number
of wires you need to run, and with a job where you're multiplexing
lots of lines, you'll find that getting the wiring straight is a big
part of the job. (See the photo above to see what a snarl this was
even with resistor networks.)
For the CD4021, connect three more pins: clock and data pins (labeled
CLK and either Q7 or Q8 on the chip's pinout, pins 10 and 3),
plus a "latch" pin (labeled M, pin 9).
For the SN74LS165, you need one more pin: you need clock and data
(labeled CP and Q7, pins 2 and 9), latch (labeled
PL, pin 1),
and clock enable (labeled CE,
At least for the CD4021, some people
a 0.1 uF bypass capacitor across the power/ground connections of each
If you need to cascade several chips with the CD4021, wire DS (pin 11)
from the first chip to Q7 (pin 3), then wire both chips clock lines together
and both chips' data lines together. The SN74LS165 is the same: DS
(pin 10) to Q8 (pin 9) and tie the clock and data lines together.
Once wired up, you toggle the latch to read the parallel data, then
toggle it again and use the clock pin to read the series of bits.
You can see the specific details in my Python scripts:
on GitHub and
For wiring diagrams, more background, and Arduino code for the CD4021, read
For the SN74LS165, read:
74HC165 8 bit Parallel in/Serial out Shift Register,
Of course, you can use a shift register for output as well as input.
In that case you need a SIPO (Serial In, Parallel Out) shift register
like a 74HC595. See
Serial to Parallel Shifting-Out with a 74HC595
74HC595 Serial Shift Register with Raspberry Pi.
Another, less common option is the 74HC164N:
a SN74HC164N Shift Register With Raspberry Pi
For input from my keyboard, initially I used three CD4021s. It basically worked,
and you can see the code for it at
(older version, for CD4021 shift registers), on GitHub.
But it turned out that looping over all those bits was slow -- I've
been advised that you should wait at least 25 microseconds between
bits for the CD4021, and even at 10 microseconds I found there wasa
significant delay between hitting the key and hearing the note.I
thought it might be all the fancy numpy code to generate waveforms for
the chords, but when I used the Python profiler, it said most of the
program's time was taken up in time.sleep(). Fortunately, there's a
faster solution than shift registers: port expanders, which I'll talk
about in Multiplexing Part 2: Port Expanders.
[ 12:23 Feb 13, 2018
More hardware |
permalink to this entry |
Fri, 02 Feb 2018
When I work with a Raspberry Pi from anywhere other than home,
I want to make sure I can do what I need to do without a network.
With a Pi model B, you can use an ethernet cable. But that doesn't
work with a Pi Zero, at least not without an adapter.
The lowest common denominator is a serial cable, and I always
recommend that people working with headless Pis get one of these;
but there are a lot of things that are difficult or impossible over
a serial cable, like file transfer, X forwarding, and running any
sort of browser or other network-aware application on the Pi.
Recently I learned how to configure a Pi Zero as a USB ethernet gadget,
which lets you network between the Pi and your laptop using only a
It requires a bit of setup, but it's definitely worth it.
(This apparently only works with Zero and Zero W, not with a Pi 3.)
The first step is getting the cable.
For a Pi Zero or Zero W, you can use a standard micro-USB cable:
you probably have a bunch of them for charging phones (if you're
not an Apple person) and other devices.
Set up the Pi
Setting up the Raspberry Pi end requires editing
two files in /boot, which you can do either on the Pi itself,
or by mounting the first SD card partition on another machine.
In /boot/config.txt add this at the end:
In /boot/cmdline.txt, at the end of the long list of options
but on the same line, add a space, followed by:
Set a static IP address
This step is optional. In theory you're supposed to use some kind of
.local address that Bonjour (the Apple protocol that used to be called
zeroconf, and before that was called Rendezvous, and on Linux machines
is called Avahi). That doesn't work on
my Linux machine. If you don't use Bonjour, finding the Pi over the
ethernet link will be much easier if you set it up to use a static IP
address. And since there will be nobody else on your USB network
besides the Pi and the computer on the other end of the cable, there's
no reason not to have a static address: you're not going to collide
with anybody else.
You could configure a static IP in /etc/network/interfaces,
but that interferes with the way Raspbian handles wi-fi via
wpa_supplicant and dhcpcd; so you'd have USB networking but your
wi-fi won't work any more.
Instead, configure your address in Raspbian via dhcpcd.
Edit /etc/dhcpcd.conf and add this:
This will tell Raspbian to use address
its USB interface. You'll set up your other computer to use 192.168.7.1.
Now your Pi should be ready to boot with USB networking enabled.
Plug in a USB cable (if it's a model A or B) or a micro USB cable
(if it's a Zero), plug the other end into your computer,
then power up the Pi.
Setting up a Linux machine for USB networking
The final step is to configure your local computer's USB ethernet
to use 192.168.7.1.
On Linux, find the name of the USB ethernet interface. This will only
show up after you've booted the Pi with the ethernet cable plugged in to
The USB interface will probably start eith en
and will probably
be the last interface shown.
On my Debian machine, the USB network showed up as enp0s26u1u1.
So I can configure it thusly (as root, of course):
ip a add 192.168.7.1/24 dev enp0s26u1u1
ip link set dev enp0s26u1u1 up
(You can also use the older ifconfig
rather than ip
sudo ifconfig enp0s26u1u1 192.168.7.1 up
You should now be able to ssh into your Raspberry Pi
using the address 192.168.7.2, and you can make an appropriate entry
in /etc/hosts, if you wish.
For a less hands-on solution, if you're using Mac or Windows, try
USB gadget tutorial.
It's possible that might also work for Linux machines running Avahi.
If you're using Windows, you might prefer
ethernet gadget tutorial.
Update: there's now a
Part 2: Routing to the Outside World with a Part 3 on the way.
[ 14:53 Feb 02, 2018
More linux |
permalink to this entry |