Shallow Thoughts

Akkana's Musings on Open Source Computing and Technology, Science, and Nature.

Thu, 02 Nov 2017

Programming an ATtiny85, Part 1: Using C with a USBtinyISP

[ATtiny85 and USBtinyISP programmer] Arduinos are great for prototyping, but for a small, low-power, cheap and simple design, an ATtiny chip seems like just the ticket. For just a few dollars you can do most of what you could with an Arduino and use a lot of the same code, as long as you can make do with a little less memory and fewer pins.

I've been wanting to try them, and recently I ordered a few ATtiny85 chips. There are quite a few ways to program them. You can buy programmers specifically intended for an ATtiny, but I already had a USBtinyISP, a chip used to program Arduino bootloaders, so that's what I'll discuss here.

Wiring to the USBtinyISP

[ATtiny85 and USBtinyISP wiring] The best reference I found on wiring was Using USBTinyISP to program ATTiny45 and ATTiny85. That's pretty clear, but I made my own Fritzing diagram, with colors, so it'll be easy to reconstruct it next time I need it. The colors I used:
MISO yellow VCC red
SCK white MOSI green
RESET orange
or red/black
GND black

Programming the ATtiny in C

I found a couple of blink examples at electronut.in, Getting Started with ATtiny AVR programming, and in a Stack Exchange thread, How to program an AVR chip in Linux Here's some basic blink code:

#include 
#include 

int main (void)
{
    // Set Data Direction to output on port B, pins 2 and 3:
    DDRB = 0b00001000;
    while (1) {
        // set PB3 high
        PORTB = 0b00001000;
        _delay_ms(500);
        // set PB3 low
        PORTB = 0b00000000;
        _delay_ms(500);
    }

    return 1;
}

Then you need a Makefile. I started with the one linked from the electronut page above. Modify it if you're using a programmer other than a USBtinyISP. make builds the program, and make install loads it to the ATtiny. And, incredibly, my light started blinking, the first time!

[ATtiny85 pinout] Encouraged, I added another LED to make sure I understood. The ATtiny85 has six pins you can use (the other two are power and ground). The pin numbers correspond to the bits in DDRB and PORTB: my LED was on PB3. I added another LED on PB2 and made it alternate with the first one:

    DDRB = 0b00001100;
[ ... ]
        // set PB3 high, PB2 low
        PORTB = 0b00001000;
        _delay_ms(500);
        // set PB3 low, PB2 high
        PORTB = 0b00000100;
        _delay_ms(500);

Timing Woes

But wait -- not everything was rosy. I was calling _delay_ms(500), but it was waiting a lot longer than half a second between flashes. What was wrong?

For some reason, a lot of ATtiny sample code on the web assumes the chip is running at 8MHz. The chip's internal oscillator is indeed 8MHz (though you can also run it with an external crystal at various speeds) -- but its default mode uses that oscillator in "divide by eight" mode, meaning its actual clock rate is 1MHz. But Makefiles you'll find on the web don't take that into account (maybe because they're all copied from the same original source). So, for instance, the Makefile I got from electronut has

CLOCK = 8000000
If I changed that to
CLOCK = 1000000
now my delays were proper milliseconds, as I'd specified. Here's my working attiny85 blink Makefile.

In case you're curious about clock rate, it's specified by what are called fuses, which sound permanent but aren't: they hold their values when the chip loses power, but you can set them over and over. You can read the current fuse settings like this:

avrdude -c usbtiny -p attiny85 -U lfuse:r:-:i -v
which should print something like this:
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as FF
avrdude: safemode: Fuses OK (E:FF, H:DF, L:62)

To figure out what that means, go to the Fuse calculator, scroll down to Current settings and enter the three values you got from avrdude (E, H and L correspond to Extended, High and Low). Then scroll up to Feature configuration to see what the fuse settings correspond to. In my case it was Int. RC Osc. 8 Mhz; Start-up time PWRDWN/RESET; 6CK/14CK+ 64ms; [CKSEL=1011 SUT=10]; default value and Divide clock by 8 internally; [CKDIV8=0] was checked.

More on ports and pins

There's more info on ATtiny ports in ATTiny Port Manipulation (Part 1): PinMode() and DigitalWrite()

Nobody seems to have written much about AVR/ATTINY programming in general. Symbols like PORTB and functions like _delay_ms() come from files in /usr/lib/avr/include/, at least on my Debian system. There's not much there, so if you want library functions to handle nontrivial hardware, you'll have to write them or find them somewhere else.

As for understanding pins, you're supposed to go to the datasheet and read it through, all 234 pages. Hint: for understanding basics of reading from and writing to ports, speed forward to section 10, I/O Ports. A short excerpt from that section:

Three I/O memory address locations are allocated for each port, one each for the Data Register - PORTx, Data Direction Register - DDRx, and the Port Input Pins - PINx. The Port Input Pins I/O location is read only, while the Data Register and the Data Direction Register are read/write. However, writing a logic one to a bit in the PINx Register, (comma sic) will result in a toggle in the corresponding Data Register. In addition, the Pull-up Disable - PUD bit in MCUCR disables the pull-up function for all pins in all ports when set.

There's also some interesting information there about built-in pull-up resistors and how to activate or deactivate them.

That's helpful, but here's the part I wish they'd said:

PORTB (along with DDRB and PINB) represents all six pins. (Why B? Is there a PORTA? Not as far as I can tell; at least, no PORTA is mentioned in the datasheet.) There are six output pins, corresponding to the six pins on the chip that are not power or ground. Set the bits in DDRB and PORTB to correspond to the pins you want to set. So if you want to use pins 0 through 3 for output, do this:

    DDRB = 0b00001111;

If you want to set logical pins 1 and 3 (corresponding to pins 6 and 2 on the chip) high, and the rest of the pins low, do this:

    PORTB = 0b00001010;

To read from pins, use PINB.

In addition to basic functionality, all the pins have specialized uses, like timers, SPI, ADC and even temperature measurement (see the diagram above). The datasheet goes into more detail about how to get into some of those specialized modes.

But a lot of those specialties are easier to deal with using libraries. And there are a lot more libraries available for the Arduino C++ environment than there are for a bare ATtiny using C. So the next step is to program the ATtiny using Arduino ... which deserves its own article.

Tags: , ,
[ 18:01 Nov 02, 2017    More hardware | permalink to this entry | comments ]

Thu, 26 Oct 2017

Reading an IR Remote on a Raspberry Pi with LIRC

[IR remote with Raspberry Pi Zero W]

Our makerspace got some new Arduino kits that come with a bunch of fun parts I hadn't played with before, including an IR remote and receiver.

The kits are intended for Arduino and there are Arduino libraries to handle it, but I wanted to try it with a Raspberry Pi as well.

It turned out to be much trickier than I expected to read signals from the IR remote in Python on the Pi. There's plenty of discussion online, but most howtos are out of date and don't work, or else they assume you want to use your Pi as a media center and can't be adapted to more general purposes. So here's what I learned.

Install LIRC and enable the drivers on the Pi

The LIRC package reads and decodes IR signals, so start there:

$ sudo apt-get install lirc python-lirc python3-lirc

Then you have to enable the lirc daemon. Assuming the sensor's pin is on the Pi's GPIO 18, edit /boot/config.txt as root, look for this line and uncomment it:

# Uncomment this to enable the lirc-rpi module
dtoverlay=lirc-rpi

Reboot. Then use a program called mode2 to make sure you can read from the remote at all, after first making sure the lirc daemon isn't running:

$ sudo service lirc stop
$ ps aux | grep lirc
$ mode2 -d /dev/lirc0

Press a few keys. If you see a lot of output, you're good. If not, check your wiring.

Set up a lircd.conf

You'll need to make an lircd.conf file mapping the codes the buttons send to symbols like KEY_PLAY. You can do that -- ina somewhat slow and painstaking process -- with irrecord.

First you'll need a list of valid key names. Get that with irrecord -l and you'll probably want to keep that window up so you can search or grep in it. Open another window and run:

$ irrecord -d /dev/lirc0 ~/lircd.conf

I had to repeat the command a couple of times; the first few times it couldn't read anything. But once it's running, then for each key on the remote, first, find the key name that most closely matches what you want the key to do (for instance, if the key is the power button, irrecord -l | grep -i power will suggest KEY_POWER and KEY_POWER2). Type or paste that key name into irrecord -d, then press the key. At the end of this, you should have a ~/lircd.conf.

Some guides say to copy that lircd.conf to /etc/lirc/ andI did, but I'm not sure it matters if you're going to be running your programs as you rather than root.

Then enable the lirc daemon that you stopped back when you were testing with mode2. In /etc/lirc/hardware.conf, START_LIRCMD is commented out, so uncomment it. Then edit /etc/lirc/hardware.conf as specified in alexba.in's "Setting Up LIRC on the RaspberryPi". Now you can start the daemon:

sudo service lirc start
and verify that it's running: ps aux | grep lirc.

Testing with irw

Now it's time to test your lircd.conf:

irw
Press buttons, and hopefully you'll see lines like
0000000000fd8877 01 KEY_2 /home/pi/lircd.conf
0000000000fd08f7 00 KEY_1 /home/pi/lircd.conf
0000000000fd906f 00 KEY_VOLUMEDOWN /home/pi/lircd.conf
0000000000fd906f 01 KEY_VOLUMEDOWN /home/pi/lircd.conf
0000000000fda05f 00 KEY_PLAYPAUSE /home/pi/lircd.conf

If they correspond to the buttons you pressed, your lircd.conf is working.

Reading Button Presses from Python

Now, most tutorials move on to generating a .lircrc file which sets up your machine to execute programs automatically when buttons are pressed, and then you can test with ircat. If you're setting up your Raspberry Pi as a media control center, that's probably what you want (see below for hints if that's your goal). But neither .ircrc nor ircat did anything useful for me, and executing programs is overkill if you just want to read keys from Python.

Python has modules for everything, right? The Raspbian repos have python-lirc, python-pylirc and python3-lirc, and pip has a couple of additional options. But none of the packages I tried actually worked. They all seem to be aimed at setting up media centers and wanted lircrc files without specifying what they need from those files. Even when I set up a .lircrc they didn't work. For instance, in python-lirc, lirc.nextcode() always returned an empty list, [].

I didn't want any of the "execute a program" crap that a .lircrc implies. All I wanted to do was read key symbols one after another -- basically what irw does. So I looked at the irw.c code to see what it did, and it's remarkably simple. It opens a socket and reads from it. So I tried implementing that in Python, and it worked fine: pyirw.py: Read LIRC button input from Python.

While initially debugging, I still saw those

0000000000fda05f 00 KEY_PLAYPAUSE /home/pi/lircd.conf
lines printed on the terminal, but after a reboot they went away, so they might have been an artifact of running irw.

If You Do Want a .lircrc ...

As I mentioned, you don't need a .lircrc just to read keys from the daemon. But if you do want a .lircrc because you're running some sort of media center, I did find two ways of generating one.

There's a bash script called lirc-config-tool floating around that can generate .lircrc files. It's supposed to be included in the lirc package, but for some reason Raspbian's lirc package omits it. You can find and download the bash script witha web search for lirc-config-tool source, and it works fine on Raspbian. It generates a bunch of .lircrc files that correspond to various possible uses of the remote: for instance, you'll get an mplayer.lircrc, a mythtv.lircrc, a vlc.lircrc and so on.

But all those lircrc files lirc-config-tool generates use only small subsets of the keys on my remote, and I wanted one that included everything. So I wrote a quickie script called gen-lircrc.py that takes your lircd.conf as input and generates a simple lircrc containing all the buttons represented there. I wrote it to run a program called "beep" because I was trying to determine if LIRC was doing anything in response to the lircrc (it wasn't); obviously, you should edit the generated .lircrc and change the prog = beep to call your target programs instead.

Once you have a .lircrc, I'm not sure how you get lircd to use it to call those programs. That's left as an exercise for the reader.

Tags: , ,
[ 11:21 Oct 26, 2017    More hardware | permalink to this entry | comments ]

Thu, 12 Oct 2017

Letter to the New Mexico Public Education Department on Science Standards

For those who haven't already read about the issue in the national press, New Mexico's Public Education Department (a body appointed by the governor) has a proposal regarding new science standards for all state schools. The proposal starts with the national Next Generation Science Standards but then makes modifications, omitting points like references to evolution and embryological development or the age of the Earth and adding a slew of NM-specific standards that are mostly sociological rather than scientific.

You can read more background in the Mother Jones article, New Mexico Doesn’t Want Your Kids to Know How Old the Earth Is. Or why it’s getting warmer, including links to the proposed standards. Ars Technica also covered it: Proposed New Mexico science standards edit out basic facts.

New Mexico residents have until 5.p.m. next Monday, October 16, to speak out about the proposal. Email comments to rule.feedback@state.nm.us or send snail mail (it must arrive by Monday) to Jamie Gonzales, Policy Division, New Mexico Public Education Department, Room 101, 300 Don Gaspar Avenue, Santa Fe, New Mexico 87501.

A few excellent letters people have already written:

I'm sure they said it better than I can. But every voice counts -- they'll be counting letters! So here's my letter. If you live in New Mexico, please send your own. It doesn't have to be long: the important thing is that you begin by stating your position on the proposed standards.


Members of the PED:

Please reconsider the proposed New Mexico STEM-Ready Science Standards, and instead, adopt the nationwide Next Generation Science Standards (NGSS) for New Mexico.

With New Mexico schools ranking at the bottom in every national education comparison, and with New Mexico hurting for jobs and having trouble attracting technology companies to our state, we need our students learning rigorous, established science.

The NGSS represents the work of people in 26 states, and is being used without change in 18 states already. It's been well vetted, and there are many lesson plans, textbooks, tests and other educational materials available for it.

The New Mexico Legislature supports NGSS: they passed House Bill 211 in 2017 (vetoed by Governor Martinez) requiring adoption of the NGSS. The PED's own Math and Science Advisory Council (MSAC) supports NGSS: they recommended in 2015 that it be adopted. Why has the PED ignored the legislature and its own advisory council?

Using the NGSS without New Mexico changes will save New Mexico money. The NGSS is freely available. Open source textbooks and lesson plans are already available for the NGSS, and more are coming. In contrast, the New Mexico Stem-Ready standards would be unique to New Mexico: not only would we be left out of free nationwide educational materials, but we'd have to pay to develop New Mexico-specific curricula and textbooks that couldn't be used anywhere else, and the resulting textbooks would cost far more than standard texts. Most of this money would go to publishers in other states.

New Mexico consistently ranks at the bottom in educational comparisons. Yet nearly 15% of the PED's proposed stem-ready standards are New Mexico specific standards, taught nowhere else, and will take time away from teaching core science concepts. Where is the evidence that our state standards would be better than what is taught in other states? Who are we to think we can write better standards than a nationwide coalition?

In addition, some of the changes in the proposed NM STEM-Ready Science Standards seem to be motivated by political ideology, not science. Science standards used in our schools should be based on widely accepted scientific principles. Not to mention that the national coverage on this issue is making our state a laughingstock.

Finally, the lack of transparency in the NMSRSS proposal is alarming. Who came up with the proposed NMSRSS standards? Are there any experts in science education that support them? Is there any data to indicate they'd be more effective than the NGSS? Why wasn't the development of the NMSRSS discussed in open PED meetings as required by the Open Meetings Act?

The NGSS are an established, well regarded national standard. Don't shortchange New Mexico students by teaching them watered-down science. Please discard the New Mexico Stem-Ready proposal and adopt the Next Generation Science Standards, without New Mexico-specific changes.

Tags: , ,
[ 10:16 Oct 12, 2017    More politics | permalink to this entry | comments ]

Thu, 05 Oct 2017

Tarantula Under Glass, and Micro-Centipedes

Every fall, Dave and I eagerly look for tarantulas. They only show up for a few weeks a year -- that's when the males go out searching for females (the females stay snug in their burrows). In the bay area, there were a few parks where we used to hunt for them: Arastradero, Mt Hamilton, occasionally even Alum Rock. Here in semi-rural New Mexico, our back yard is as good a place to hunt as anywhere else, though we still don't see many: just a couple of them a year.

But this year I didn't even have to go out into the yard. I just looked over from my computer and spotted a tarantula climbing up our glass patio door. I didn't know they could do that!

Unfortunately it got to the top before I had the camera ready, so I didn't get a picture of tarantula belly. Right now he's resting on the sill: [Tarantula, resting after climbing up our glass patio door] I don't think it's very likely he's going to find any females up there. I'm hoping he climbs back down the same way and I can catch a photo then. (Later: nope, he disappeared when I wasn't watching.)

In other invertebrate news: we have a sporadic problem with centipedes here in White Rock. Last week, a seven-inch one dropped from the ceiling onto the kitchen floor while I was making cookies, and it took me a few minutes to chase it down so I could toss it outside.

[Tiny baby centipede] But then a few days later, Dave spotted a couple of these little guys on the patio, and I have to admit they're pretty amazing. Just like the adults only in micro-miniature.

Though it doesn't make me like them any better in the house.

Tags: ,
[ 18:47 Oct 05, 2017    More nature | permalink to this entry | comments ]

Thu, 28 Sep 2017

Audio Output from a Raspberry Pi Zero

Someone at our makerspace found a fun Halloween project we could do at Coder Dojo: a motion sensing pumpkin that laughs evilly when anyone comes near. Great! I've worked with both PIR sensors and ping rangefinders, and it sounded like a fun project to mentor. I did suggest, however, that these days a Raspberry Pi Zero W is cheaper than an Arduino, and playing sounds on it ought to be easier since you have frameworks like ALSA and pygame to work with.

The key phrase is "ought to be easier". There's a catch: the Pi Zero and Zero W don't have an audio output jack like their larger cousins. It's possible to get analog audio output from two GPIO pins (use the term "PWM output" for web searches), but there's a lot of noise. Larger Pis have a built-in low-pass filter to screen out the noise, but on a Pi Zero you have to add a low-pass filter. Of course, you can buy HATs for Pi Zeros that add a sound card, but if you're not super picky about audio quality, you can make your own low-pass filter out of two resistors and two capacitors per channel (multiply by two if you want both the left and right channels).

There are lots of tutorials scattered around the web about how to add audio to a Pi Zero, but I found a lot of them confusing; e.g. Adafruit's tutorial on Pi Zero sound has three different ways to edit the system files, and doesn't specify things like the values of the resistors and capacitors in the circuit diagram (hint: it's clearer if you download the Fritzing file, run Fritzing and click on each resistor). There's a clearer diagram in Sudomod Forums: PWM Audio Guide, but I didn't find that until after I'd made my own, so here's mine.

Parts list:

And here's how to wire it: [Adding audio to the Raspberry Pi Zero]
(Fritzing file, pi-zero-audio.fzz.)

This wiring assumes you're using pins 13 and 18 for the left and right channels. You'll need to configure your Pi to use those pins. Add this to /boot/config.txt:

dtoverlay=pwm-2chan,pin=18,func=2,pin2=13,func2=4

Testing

Once you build your circuit up, you need to test it. Plug in your speaker or headphones, then make sure you can play anything at all:

aplay /usr/share/sounds/alsa/Front_Center.wav

If you need to adjust the volume, run alsamixer and use the up and down arrow keys to adjust volume. You'll have to press up or down several times before the bargraph actually shows a change, so don't despair if your first press does nothing.

That should play in both channels. Next you'll probably be curious whether stereo is actually working. Curiously, none of the tutorials address how to test this. If you ls /usr/share/sounds/alsa/ you'll see names like Front_Left.wav, which might lead you to believe that aplay /usr/share/sounds/alsa/Front_Left.wav might play only on the left. Not so: it's a recording of a voice saying "Front left" in both channels. Very confusing!

Of course, you can copy a music file to your Pi, play it (omxplayer is a nice commandline player that's installed by default and handles MP3) and see if it's in stereo. But the best way I found to test audio channels is this:

speaker-test -t wav -c 2

That will play those ALSA voices in the correct channel, alternating between left and right. (MythTV has a good Overview of how to use speaker-test.

Not loud enough?

I found the volume plenty loud via earbuds, but if you're targeting something like a Halloween pumpkin, you might need more volume. The easy way is to use an amplified speaker (if you don't mind putting your nice amplified speaker amidst the yucky pumpkin guts), but you can also build a simple amplifier. Here's one that looks good, but I haven't built one yet: One Transistor Audio for Pi Zero W

Of course, if you want better sound quality, there are various places that sell HATs with a sound chip and line or headphone out.

Tags: , , , ,
[ 15:49 Sep 28, 2017    More hardware | permalink to this entry | comments ]

Sun, 17 Sep 2017

Screen Brightness on an Asus 1015e (and other Intel-based laptops)

When I upgraded my Asus laptop to Stretch, one of the things that stopped working was the screen brightness keys (Fn-F5 and Fn-F6). In Debian Jessie they had always just automagically worked without my needing to do anything, so I'd never actually learned how to set brightness on this laptop. The fix, like so many things, is easy once you know where to look.

It turned out the relevant files are in /sys/class/backlight/intel_backlight. cat /sys/class/backlight/intel_backlight/brightness tells you the current brightness; write a number to /sys/class/backlight/intel_backlight/brightness to change it.

That at least got me going (ow my eyes, full brightness is migraine-inducing in low light) but of course I wanted it back on the handy function keys.

I wrote a script named "dimmer", with a symlink to "brighter", that goes like this:

#!/bin/zsh

curbright=$(cat /sys/class/backlight/intel_backlight/brightness)
echo dollar zero $0
if [[ $(basename $0) == 'brighter' ]]; then
  newbright=$((curbright + 200))
else
  newbright=$((curbright - 200))
fi
echo from $curbright to $newbright

sudo sh -c "echo $newbright > /sys/class/backlight/intel_backlight/brightness"

That let me type "dimmer" or "brighter" to the shell to change the brightness, with no need to remember that /sys/class/whatsit path. I got the names of the two function keys by running xev and typing Fn and F5, then Fn and F6. Then I edited my Openbox ~/.config/openbox/rc.xml, and added:

<keybind key="XF86MonBrightnessDown">
  <action name="Execute">
    <execute>dimmer<execute>
  </action>
</keybind>
<keybind key="XF86MonBrightnessUp">
  <action name="Execute">
    <execute>brighter<execute>
  </action>
</keybind>

Tags: ,
[ 19:57 Sep 17, 2017    More linux/laptop | permalink to this entry | comments ]

Mon, 04 Sep 2017

Jumpstarting the Raspberry Pi Zero W: Now Available via Humble Bundle!

[Raspberry Pi Zero W] My new book is now shipping! And it's being launched via a terrific Humble Bundle of books on electronics, making, Raspberry Pi and Arduino.

Humble Bundles, if you haven't encountered them before, let you pay what you want for a bundle of books on related subjects. The books are available in ePub, Mobi, and PDF formats, without DRM, so you can read them on your choice of device. If you pay above a certain amount, they add additional books. My book is available if you pay $15 or more.

You can also designate some of the money you pay for charity. In this case the charity is Maker Ed, a crowdfunding initiative that supports Maker programs primarily targeted toward kids in schools. (I don't know any more about them than that; check out their website for more information.)

Jumpstarting the Raspberry Pi Zero W is a short book, with only 103 pages in four chapters:

  1. Getting Started: includes tips on headless setup and the Linux command line;
  2. Blink an LED: includes ways to blink and fade LEDs from the shell and from several different Python libraries;
  3. A Temperature Notifier and Fan Control: code and wiring instructions for three different temperature sensors (plus humidity and barometric pressure), and a way to use them to control your house fan or air conditioner, either according to the temperature in the room or through a Twitter command;
  4. A Wearable News Alert Light Show: wire up NeoPixels or DotStars and make them respond to keywords on Twitter or on any other web page you choose, plus some information on powering a Pi portably with batteries.

All the code and wiring diagrams from the book, plus a few extras, are available on Github, at my Raspberry Pi Zero Book code repository.

To see the book bundle, go to the Electronics & Programming Humble Bundle and check out the selections. My book, Jumpstarting the Raspberry Pi Zero W, is available if you pay $15 or more -- along with tons of other books you'll probably also want. I already have Make: Electronics and it's one of the best introductory electronics books I've seen, so I'm looking forward to seeing the followup volume. Plus there are books on atmospheric and environmental monitoring, a three-volume electronic components encyclopedia, books on wearable electronics and drones and other cool stuff.

I know this sounds like a commercial, but this bundle really does look like a great deal, whether or not you specifically want my Pi book, and it's a limited-time offer, only good for six more days.

Tags: , , , ,
[ 13:21 Sep 04, 2017    More writing | permalink to this entry | comments ]

Sun, 27 Aug 2017

Total Eclipse

[2017 Solar eclipse with corona] My first total eclipse! The suspense had been building for years.

Dave and I were in Wyoming. We'd made a hotel reservation nine months ago, by which time we were already too late to book a room in the zone of totality and settled for Laramie, a few hours' drive from the centerline.

For visual observing, I had my little portable 80mm refractor. But photography was more complicated. I'd promised myself that for my first (and possibly only) total eclipse, I wasn't going to miss the experience because I was spending too much time fiddling with cameras. But I couldn't talk myself into not trying any photography at all.

Initially, my plan was to use my 90mm Mak as a 500mm camera lens. It had worked okay for the the 2012 Venus transit.

[Homemade solar finder for telescope] I spent several weeks before the eclipse in a flurry of creation, making a couple of solar finders, a barn-door mount, and then wrestling with motorizing the barn-door (which was a failure because I couldn't find a place to buy decent gears for the motor. I'm still working on that and will eventually write it up). I wrote up a plan: what equipment I would use when, a series of progressive exposures for totality, and so forth.

And then, a couple of days before we were due to leave, I figured I should test my rig -- and discovered that it was basically impossible to focus on the sun. For the Venus transit, the sun wasn't that high in the sky, so I focused through the viewfinder. But for the total eclipse, the sun would be almost overhead, and the viewfinder nearly impossible to see. So I had planned to point the Mak at a distant hillside, focus it, then slip the filter on and point it up to the sun. It turned out the focal point was completely different through the filter.

[Solar finder for DSLR, made from popsicle sticks] With only a couple of days left to go, I revised my plan. The Mak is difficult to focus under any circumstances. I decided not to use it, and to stick to my Canon 55-250mm zoom telephoto, with the camera on a normal tripod. I'd skip the partial eclipse (I've photographed those before anyway) and concentrate on getting a few shots of the diamond ring and the corona, running through a range of exposures without needing to look at the camera screen or do any refocusing. And since I wasn't going to be usinga telescope, my nifty solar finders wouldn't work; I designed a new one out of popsicle sticks to fit in the camera's hot shoe.

Getting there

We stayed with relatives in Colorado Saturday night, then drove to Laramie Sunday. I'd heard horror stories of hotels canceling people's longstanding eclipse reservations, but fortunately our hotel honored our reservation. WHEW! Monday morning, we left the hotel at 6am in case we hit terrible traffic. There was already plenty of traffic on the highway north to Casper, but we turned east hoping for fewer crowds. A roadsign sign said "NO PARKING ON HIGHWAY." They'd better not try to enforce that in the totality zone!

[Our eclipse viewing pullout on Wyoming 270] When we got to I-25 it was moving and, oddly enough, not particularly crowded. Glendo Reservoir had looked on the map like a nice spot on the centerline ... but it was also a state park, so there was a risk that everyone else would want to go there. Sure enough: although traffic was moving on I-25 at Wheatland, a few miles north the freeway came to a screeching halt. We backtracked and headed east toward Guernsey, where several highways went north toward the centerline.

East of Glendo, there were crowds at every highway pullout and rest stop. As we turned onto 270 and started north, I kept an eye on OsmAnd on my phone, where I'd loaded a GPX file of the eclipse path. When we were within a mile of the centerline, we stopped at a likely looking pullout. It was maybe 9 am. A cool wind was blowing -- very pleasant since we were expecting a hot day -- and we got acquainted with our fellow eclipse watchers as we waited for first contact.

Our pullout was also the beginning of a driveway to a farmhouse we could see in the distance. Periodically people pulled up, looking lost, checked maps or GPS, then headed down the road to the farm. Apparently the owners had advertised it as an eclipse spot -- pay $35, and you can see the eclipse and have access to a restroom too! But apparently the old farmhouse's plumbing failed early on, and some of the people who'd paid came out to the road to watch with us since we had better equipment set up.

[Terrible afocal view of partial eclipse] There's not much to say about the partial eclipse. We all traded views -- there were five or six scopes at our pullout, including a nice little H-alpha scope. I snapped an occasional photo through the 80mm with my pocket camera held to the eyepiece, or with the DSLR through an eyepiece projection adapter. Oddly, the DSLR photos came out worse than the pocket cam ones. I guess I should try and debug that at some point.

Shortly before totality, I set up the DSLR on the tripod, focused on a distant hillside and taped the focus with duct tape, plugged in the shutter remote, checked the settings in Manual mode, then set the camera to Program mode and AEB (auto exposure bracketing). I put the lens cap back on and pointed the camera toward the sun using the popsicle-stick solar finder. I also set a countdown timer, so I could press START when totality began and it would beep to warn me when it was time to the sun to come back out. It was getting chilly by then, with the sun down to a sliver, and we put on sweaters.

The pair of eclipse veterans at our pullout had told everybody to watch for the moon's shadow racing toward us across the hills from the west. But I didn't see the racing shadow, nor any shadow bands.

And then Venus and Mercury appeared and the sun went away.

Totality

[Solar eclipse diamond ring] One thing the photos don't prepare you for is the color of the sky. I expected it would look like twilight, maybe a little darker; but it was an eerie, beautiful medium slate blue. With that unworldly solar corona in the middle of it, and Venus gleaming as bright as you've ever seen it, and Mercury shining bright on the other side. There weren't many stars.

We didn't see birds doing anything unusual; as far as I can tell, there are no birds in this part of Wyoming. But the cows did all get in a line and start walking somewhere. Or so Dave tells me. I wasn't looking at the cows.

Amazingly, I remembered to start my timer and to pull off the DSLR's lens cap as I pushed the shutter button for the diamond-ring shots without taking my eyes off the spectacle high above. I turned the camera off and back on (to cancel AEB), switched to M mode, and snapped a photo while I scuttled over to the telescope, pulled the filter off and took a look at the corona in the wide-field eyepiece. So beautiful! Binoculars, telescope, naked eye -- I don't know which view was best.

I went through my exposure sequence on the camera, turning the dial a couple of clicks each time without looking at the settings, keeping my eyes on the sky or the telescope eyepiece. But at some point I happened to glance at the viewfinder -- and discovered that the sun was drifting out of the frame. Adjusting the tripod to get it back in the frame took longer than I wanted, but I got it there and got my eyes back on the sun as I snapped another photo ...

and my timer beeped.

I must have set it wrong! It couldn't possibly have been two and a half minutes. It had been 30, 45 seconds tops.

But I nudged the telescope away from the sun, and looked back up -- to another diamond ring. Totality really was ending and it was time to stop looking.

Getting Out

The trip back to Golden, where we were staying with a relative, was hellish. We packed up immediately after totality -- we figured we'd seen partials before, and maybe everybody else would stay. No such luck. By the time we got all the equipment packed there was already a steady stream of cars heading south on 270.

A few miles north of Guernsey the traffic came to a stop. This was to be the theme of the afternoon. Every small town in Wyoming has a stop sign or signal, and that caused backups for miles in both directions. We headed east, away from Denver, to take rural roads down through eastern Wyoming and Colorado rather than I-25, but even so, we hit small-town stop sign backups every five or ten miles.

We'd brought the Rav4 partly for this reason. I kept my eyes glued on OsmAnd and we took dirt roads when we could, skirting the paved highways -- but mostly there weren't any dirt roads going where we needed to go. It took about 7 hours to get back to Golden, about twice as long as it should have taken. And we should probably count ourselves lucky -- I've heard from other people who took 11 hours to get to Denver via other routes.

Lessons Learned

Dave is fond of the quote, "No battle plan survives contact with the enemy" (which turns out to be from Prussian military strategist Helmuth von Moltke the Elder).

The enemy, in this case, isn't the eclipse; it's time. Two and a half minutes sounds like a lot, but it goes by like nothing.

Even in my drastically scaled-down plan, I had intended exposures from 1/2000 to 2 seconds (at f/5.6 and ISO 400). In practice, I only made it to 1/320 because of fiddling with the tripod.

And that's okay. I'm thrilled with the photos I got, and definitely wouldn't have traded any eyeball time for more photos. I'm more annoyed that the tripod fiddling time made me miss a little bit of extra looking. My script actually worked out better than I expected, and I was very glad I'd done the preparation I had. The script was reasonable, the solar finders worked really well, and the lens was even in focus for the totality shots.

Then there's the eclipse itself.

I've read so many articles about solar eclipses as a mystical, religious experience. It wasn't, for me. It was just an eerily beautiful, other-worldly spectacle: that ring of cold fire staring down from the slate blue sky, bright planets but no stars, everything strange, like nothing I'd ever seen. Photos don't get across what it's like to be standing there under that weird thing in the sky.

I'm not going to drop everything to become a globe-trotting eclipse chaser ... but I sure hope I get to see another one some day.

Photos: 2017 August 21 Total Solar Eclipse in Wyoming.

Tags: ,
[ 20:41 Aug 27, 2017    More science/astro | permalink to this entry | comments ]