Bald Wisdom

Announcing the formal release of BootDrive for Arduino. If you’ve been reading the blog, you know that I’ve been working with Justin Shaw of Wyolum labs to enable their I2SD (Arduino clone with a micro-sd card) to bootload a program onto another Arduino. After battling several issues, mostly related to porting avrdude code to the Arduino (assumptions about infinite memory, etc!) it’s working well enough people can fool around with it.

Right now the code looks for a single file (“program.hex”) and waits 5 sec and then blasts it into the target arduino. Details about setting up to try this yourself follow the video.

Here’s a demo of it in action:

If you’d like to try this with a couple of Arduinos, you’ll also need an SD card (or micro-sd) interface such as the Adafruit Micro-SD breakout. This board is great because it has onboard 3.3v conversion so it’s safe to use with 5V (stock) Arduinos. Download the code from github: https://github.com/osbock/Baldwisdom/tree/master/BootDrive
or a zipped version here

Hook up your Arduinos like this:

I

The basic setup is:

Arduino Control:
Master Digital Pin6  –> Target reset
GND                                –> GND
MASTER Digital Pin1 –>Target Digital Pin2
MASTER Digital Pin2 –>Target Digital Pin3

SD Card Interface:
 Master Digital Pin 10 –> SD-breakout CS
Master Digital Pin 11  –>  SD breakout DI
Master Digital Pin 12  –> SD breakout DO
Master Digital Pin 13  –> SD breakout CLK
Master GND                    –> SD breakout GND
Master 5V                       –> SD breakout 5V

Optional debugging serial interface (This lets you see error messages and the like)
Master GND    –> FTDI cable Pin 1 (GND)
Master Digital Pin 4 –> FTDI cable Pin 5 (diagram is wrong, but you can change it in the code if you need to)

Here are the defines you can change to swap the pins around:

#define BOOT_BAUD 115200 // This is the Arduino UNO’s bootloader baud rate. Other boards are different!
#define DEBUG_BAUD 19200 // for software serial debugging
#define txPin 4
#define rxPin 5 // not really used…
#define rstPin 6

Also if you want to put your SD card on a different line (or are using a shield that uses a different chip select) change this:

const int chipSelect = 10;

Action!

Right now, 5 seconds after initialization, the program blasts a file called “program.hex”. You can add your own user interface to select amongst multiple programs.
Just call:

void programArduino(char *filename)

with the filename, e.g.”

programArduino("program2.hex");

You can build new hex files by grabbing them from the Arduino build directory. Make sure you have the IDE set up for your target board and press the “compile/verify” button.

From http://arduino.cc/en/Hacking/BuildProcess:

The .hex file is the final output of the compilation which is then uploaded to the board. During a “Verify” the .hex file is written to /tmp (on Mac and Linux) or \Documents and Settings\<USER>\Local Settings\Temp (on Windows). During upload, it’s written to the applet sub-directory of the sketch directory (which you can open with the “Show Sketch Folder” item in the Sketch menu)

Note on Windows7, the base directory is \users\<USER> \appdata\local\Temp\build<some bunch of numbers>.tmp\<sketchname>.cpp.hex

Note that if you want to load an Arduino other than UNO, you’ll need to change the baud rate. You can find that in “hardware/arduino/boards.txt” in the arduino directory. This won’t work on MEGA based Arduinos as they use the stk500v2 protocol (thanks westfw!)

Breaking through!

It’s been a while since the last update, but some progress has been made. I discovered that SoftwareSerial library doesn’t work really well at 115200 baud, so I switched the wiring around to use software serial for debugging, and the hardware uart pins (Arduino pins 1 and 2) to talk to the bootloader on the target. This is a little bit of a pain, as you have to unplug the connection to the target to download code to the “programmer” but it does work now.

I had a little trouble getting sensible responses from the bootloader until I put in a delay after resetting. In retrospect this makes sense as the AVRdude code reminded me that there are capacitors on the Arduino reset line. I was probably trying to talk too soon.

What bootloader, speed, protocol?

There have been several different bootloaders in the history of Arduino, and the source code for the current “canonical” loaders is included in the Arduino software distribution.  The bootloader is a little piece of code that allows you to program the flash memory of the Arduino’s atmega328p via serial or USB instead of using an ICSP programmer.  These bootloaders implement a subset of the STK500 8bit protocol (not to be confused with STK500v2) which is documented at www.atmel.com/atmel/acrobat/doc2525.pdf

Arduino MEGA (1280 and 2560) use yet another bootloader, one that uses the stk500v2 protocol instead.

The source code for the bootloader used by the diecimila, duemilanove, and a few other clones  is in …\arduino-1.0\hardware\arduino\bootloaders\atmega. Many clones use this, or a variant hacked by Lady Ada (Limor Fried).

The UNO and other later Arduino variants use a much smaller bootloader called Optiboot (more room for your code!). A little secret is that you can actually burn this bootloader into your older arduinos (at least at atmega168 and greater) and then just refer to the board as an UNO.

Adafruit Forum user westfw (one of /the?) author of  optiboot points out:

Optiboot also supports the mega8. However, you can only call a board an Uno if it at has a m328 cpu in it. For m8 and m168s with optiboot, you’ll need to make a new entry in boards.txt that copies the Uno bootloader parameters, but has the correct “build.mcu” specification (and fuses, if you want to program the bootloader using the IDE.)

The code for this is in …\arduino-1.0\hardware\arduino\bootloaders\optiboot. If you need to change the processor or baud rate, the settings are in the Makefile. This version is very stripped down, and doesn’t support, for example, writing to EEPROM. I’m choosing to use this as my initial target. Most of the code will still work on the older bootloader, but may require a slightly different command set.

The latest and greatest optiboot can be found at it’s Google code site: http://code.google.com/p/optiboot/

Which is also the preferred place for bug reports and to check for newer versions (atmega1284 is now supported!)

Because of varying clock rates, and different bootloader code, the various boards use different baud rates to talk to the IDE. This information is found in the …\arduino-1.0\hardware\arduino\boards.txt file. The UNO programs at 115200 baud, the Duemilanove (with ATmega328p) programs at 57600 baud. The Diecemila or Duemilanove with ATmega168 programs at 19200 baud.

Looking at the actual protocol

After the Arduino IDE compiles everything down to a intel hex file for downloading to the target Arduino, it uses the avrdude command to program the Arduino. The upload protocol is also specified in the boards.txt file and is called arduino, which is a slight variant of avrdude’s stk500 protocol. Most of the commands are from the stk500 module, except the signature reading is slightly different. For now, I’m adapting the avrdude code directly for the Arduino. This requires some minor porting (eliminating fprintfs, removing some of the indirection that links it to the avrdude programmer framework). I may simplify some of this code later as I’m a little nervous about running out of room.

As I mentioned in my last post, I downloaded a trial version of AGG Software’s Advanced Serial Port Monitor, and recorded the conversation between avrdude (controlled by the Arduino IDE) and the UNO target board. I stayed up late last night annotating the conversation:

DTR and RTS are both toggled from High to low several times

Avrdude then sends the GET_SYNCH command, thows away whatever comes back and sends it again a couple of times
Avrdude/Arduino IDE:#30#20 STK_GET_SYNCH, Sync_CRC_EOP
Target/Arduino UNO:  #14#10 STK_INSYNC, STK_OK
Avrdude/Arduino IDE: #30#20 STK_GET_SYNCH, Sync_CRC_EOP
Target/Arduino UNO:  #14#10 STK_INSYNC, STK_OK
Avrdude/Arduino IDE: #30#20 STK_GET_SYNCH, Sync_CRC_EOP
Target/Arduino UNO: #14#10 STK_INSYNC, STK_OK

Get the version number of the bootloader (in this case it’s 4.4) we could use this to branch to different variants of protocol.
Avrdude/Arduino IDE: #41#81#20 STK_GET_PARAMETER, STK_SW_MAJOR, SYNC,CRC_EOP
Target/Arduino UNO: #14#04#10 STK_INSYNC, 0×04, STK_OK
Avrdude/Arduino IDE: #41#82#20 STK_GET_PARAMETER, STK_SW_MINOR, SYNC_CRC_EOP
Target/Arduino UNO: #14#04#10 STK_INSYNC, 0×04, STK_OK

The next two commands are consumed but ignored (probably used by a real programmer to retrieve device specific stuff.)
Avrdude/Arduino IDE: #42#86#00#00#01#01#01#01#03#FF#FF#FF#FF#00#80#04#00#00#00#80#00#20(This is a STK_SET_DEVICE Command that is consumed but ignored by the bootloader)
Target/Arduino UNO: #14#10 STK_INSYNC, STK_OK
Avrdude/Arduino IDE: #45#05#04#D7#C2#00#20 STK_SET_DEVICE_EXT (also ignored)
Target/Arduino UNO: #14#10 STK_INSYNC, STK_OK

Enter Programming mode.
Avrdude/Arduino IDE: #50#20 STK_ENTER_PROGMODE, SYNC_CRC_EOP
Target/Arduino UNO: #14#10 STK_INSYNC, STK_OK
Avrdude/Arduino IDE: #75#20 STK_READ_SIGN, SYNC_CRC_EOP (read device signature)
Target/Arduino UNO: #14#1E#95#0F#10 STK_INSYNC, (three byte signature), STK_OK

The next four commands are consumed but ignored. I won’t bother to reproduce them in my code.
Avrdude/Arduino IDE: #56#A0#03#FC#00#20 STK_UNIVERSAL,0xA0,0×03,0xFC,0×00 SYNC_CRC_EOP (This is a pass through command that is supposed to be used to perform arbitrary native SPI commands. In this case, and the next 3, they are Read EEPROM byte commands They are consumed but ignored by the bootloader)
Target/Arduino UNO: #14#00#10 STK_INSYNC, (last byte written by the Universal command, STK_OK
Avrdude/Arduino IDE: #56#A0#03#FD#00#20 STK_UNIVERSAL,0xA0,0×03,0xFD,0×00,SYNC_CRC_EOP (Ignored by the bootloader)
Target/Arduino UNO: #14#00#10 STK_INSYNC, (last byte written by the Universal command, STK_OK
Avrdude/Arduino IDE: #56#A0#03#FE#00#20 STK_UNIVERSAL, 0xA0,0×03,0xFE,0×00,SYNC_CRC_EOP (Ignored by the bootloader)
Target/Arduino UNO: #14#00#10 STK_INSYNC, (last byte written by the Universal command, STK_OK
Avrdude/Arduino IDE: #56#A0#03#FF#00#20 STK_UNIVERSAL, 0xA0,0×03,0xFF,0×00,SYNC_CRC_EOP (Ignored by the bootloader)
Target/Arduino UNO: #14#00#10 STK_INSYNC, (last byte written by the Universal command, STK_OK

Here’s where we actually get started. This specifies the address in Flash where the follwoing PROGRAM_PAGE data goes.
Avrdude/Arduino IDE: #55#00#00#20 STK_LOAD_ADDRESS, 0×0000, SYNC_CRC_EOP
Target/Arduino UNO: #14#10 STK_INSYNC, STK_OK
And then the actual data. Note that the data is in the same order as the bytes in the Intel Hex file
Avrdude/Arduino IDE:
#64#00#80#46#0C#94#61#00#0C#94#7E#00#0C#94#7E#00#0C#94#7E#00#0C
#94#7E#00#0C#94#7E#00#0C#94#7E#00#0C#94#7E#00#0C#94#7E#00#0C#94
#7E#00#0C#94#7E#00#0C#94#7E#00#0C#94#7E#00#0C#94#7E#00#0C#94#7E
#00#0C#94#7E#00#0C#94#9A#00#0C#94#7E#00#0C#94#7E#00#0C#94#7E#00
#0C#94#7E#00#0C#94#7E#00#0C#94#7E#00#0C#94#7E#00#0C#94#7E#00#0C
#94#7E#00#00#00#00#00#24#00#27#00#2A#00#00#00#00#00#25#00#28#00#2B
#00#00#00#00#00#20
STK_PROGRAM_PAGE, 0×0080 (page size), ‘F’(flash memory), data bytes…,SYNC_CRC_EOP
Target/Arduino UNO: #14#10 STK_INSYNC, STK_OK

And then we repeat – set address, program page, etc.
Avrdude/Arduino IDE: #55#40#00#20 STK_LOAD_ADDRESS, 0×0040, SYNC_CRC_EOP
Target/Arduino UNO: #14#10 STK_INSYNC, STK_OK
Avrdude/Arduino IDE: STK_PROGRAM_PAGE, 0×0080 (page size), ‘F’(flash memory), data bytes….,SYNC_CRC_EOP
Target/Arduino UNO: #14#10 STK_INSYNC, STK_OK
.
.
.
Then it reads several pages (probably to verify what it wrote)

Avrdude/Arduino IDE: #55#00#00#20 STK_LOAD_ADDRESS, 0×0000,SYNC_CRC_EOP
Target/Arduino UNO: #14#10 STK_INSYNC, STK_OK 

Avrdude/Arduino IDE: #74#00#80#46#20 STK_READ_PAGE,0×0080 bytes, ‘F’ for flash, SYNC_CRC_EOP
 Target/Arduino UNO #14 STK_INSYNC
Target/Arduino UNO #14#10 STK_INSYNC, STK_OK
#0C#94#61#00#0C#94#7E#00#0C#94#7E#00#0C#94#7E#00#0C#94#7E#00#0C#94#7E
#00#0C#94#7E#00#0C#94#7E#00#0C#94#7E#00#0C#94#7E#00#0C#94#7E#00#0C#94
#7E#00#0C#94#7E#00#0C#94#7E#00#0C#94#7E#00#0C#94#7E#00#0C#94#9A#00#0C
#94#7E#00#0C#94#7E#00#0C#94#7E#00#0C#94#7E#00#0C#94#7E#00#0C#94#7E#00
#0C#94#7E#00#0C#94#7E#00#0C#94#7E#00#00#00#00#00#24#00#27#00#2A#00#00
#00#00#00#25#00#28#00#2B#00#00#00#00#00 

#10 STK_OK

repeat several times at different addresses

.
.

And then leaves programming mode
Avrdude/Arduino IDE: #51#20 STK_LEAVE_PROGMODE, SYNC_CRC_EOP
Target/Arduino UNO #14#10 STK_INSYNC, STK_OK

Then we’re done! Avrdude then toggles DTR/RTS to reset

When I originally posted about the Auto-programmer I was pleased to see several people on my Google+ stream and in the Adafruit forums were interested. Justin Shaw of Wyolum labs was interested in the idea of reading the program off the SD card, but instead of programming a microcontroller chip directly, program another Arduino compatible (specifically one of his gorgeous clocks!)

He’s already made an Arduino compatible SD card reader board he calls I2SD (it speaks I2C) that also speaks TTL serial, so it would be perfect. I’m putting the Auto-programmer on hold to make …. drum roll please…. The Boot Drive for Arduino!

I promised a blow by blow, and I’ve been working on this for a couple of sessions. I’ve read through all the docs (8 bit stk500 protocol, optiboot source code, AVRDUDE source.) and It looks fairly straight forward. Essentially the “programming arduino” stands in for the IDE.

The optiboot source code is pretty cleanly documented (used in most newer arduinos, like the UNO). It’s pretty tiny and does only the bare minimum to get the job done. Since it’s fairly stateless (not completely, as there are timeouts that cause you to jump to the user program), I needed to get an idea of the actual sequence.

I downloaded a trial version of AGG Software’s Advanced Serial Port Monitor which lets you “listen in” on the conversation between a computer (i.e. the Arduino IDE) and a device (the Arduino.) I collected sample program downloads for the UNO and for the Duemilanove (they have different bootloaders). There were no surprises, but it was nice to confirm the sequence. If people are interested, I could post about this later. Drop me a line on my Google+ stream.

Here’s how I have it wired (using regular Arduinos until I can get my hands on an I2SD).  Note I haven’t set up the Adafruit MicroSD breakout board yet.

I’ve got pins 2 and 3 configured as software serial on the “Master” Arduino hooked in a null modem configuration with pins 0 and 1 of the “Target” Arduino. I chose to do this, so I can send debugging info down the USB serial channel. I’m doing this at 115200, because that’s what the UNO bootloader operates at. I also hooked a digital pin from the Master to the Reset of the Target. If I read the code correctly, you have a very short period of time to start sending STK500 commands before the bootloader times out and jumps to user code after RESET. The Arduino IDE asserts reset by toggling the RTS line (well, actually a software call on the USB-serial driver). The RTS output of the FTDI chip (or equivalent on the UNO) is tied to RESET.

Now comes the frustrating part, I haven’t been able to get them to talk. I get bytes back but they aren’t what I expect, and I’m not sure where they are coming from if I’m not properly entering the bootloader.

I also tried setting up dummy programs, the Target sending “Hello” in a loop, and the “Master just trying to receive it and print it out. That doesn’t work either.

I’ll keep you posted. I’m also going to try talking to a TTL serial Arduino clone (one of the WIBLOCKS Pico boards).

Instructables.com is one of my favorite sites, offering step by step instructions for all kinds of projects.

Instructables author Randofo created a cool Arduino shield for programming 8 pin attinys. In a brilliant move to get more instructables submitted, he offered one for free if you submitted an Arduino or AVR instructable. Well, that pushed me over the edge and I submitted my first one:

http://www.instructables.com/id/Turn-a-TV-B-Gone-into-a-super-camera-remote/

And this is what they sent me! Cool stickers and a badge! Now I just have to come up with a Nerd sash!As an added bonus, my instructable got featured on the home page and they rewarded me with a pro membership!

Now that’s the way to develop motivation to provide content!

Since getting the shield, I’ve already hacked it. It can’t program attinys with an external clock, so I added one, and put up this instructable:

http://www.instructables.com/id/Using-the-8Pin-ATTINY-programming-shield-with-an-e/

I’m a little reluctant to release this, as the police may use it on the occupy protestors. This is one annoying sound!

It was pretty hard to hear what the circuit sounded like in the video, so I modified it to have a line level output and recorded it on my computer. At first I was baffled, as the volume kept going up and down, and there were weird compression artifacts until I figured out the  sound card in my computer was doing all sorts of noise reduction and signal processing on the microphone input! I turned it off and here’s the raw sound:

I’d seen several projects on the net to make analog synthesizers, including the classic Atari Punk Console. I’m anxious to design something of my own, but I’m still learning, so I thought I’d start small. While this is not something that hasn’t been done before, I did it entirely from scratch. I read datasheets, and experimented with values for components.

Here’s a little video overview:

I did this project iteratively, first implementing a single oscillator controlled by a variable resistor or potentiometer. The capacitor I chose (220 pF) was somewhere in the middle of the range recommended by the data sheet, though I tried several other values. I have a cheap analog scope, and I could see the oscillation, but when I tried to attach a speaker, it went dead.  I hooked up a piezo element and it could drive that, but it wasn’t very loud. I stuck in a 2N2222 transistor, and used a pot to determine the optimal (loudest) bias resistor for the base, and replaced it with a fixed value.

Next, I replaced the pot with a photoresistor. This was fun, but the tone was pretty boring (plain square wave). I then hooked up another gate to drive an LED. Pointed at the photo resistor, but some distance away, it provides a cool beat, while the “average frequency is determined by the other light hitting the photoresistor. The frequency of the beat is controlled by a potentiometer like in the first circuit.

Here’s the schematic:

One tip: You’ll notice R3 in series with the potentiometer. This is because the pot goes all the way to zero, and at zero resistance the cap won’t charge and discharge properly setting up the oscillation. This sets some non-zero base value that you can set experimentally based on what you want that end of the frequency range to be.

The DangerousPrototypes Blog had a quick post on a deal that Texas Instruments was offering a Watch/development kit for their low power processors for only $24. I’ll be telling you more about this in a future installment, but while I was grabbing the deal, I saw this neat little development kit for their low-power value-line processors. It cost all of $4.30, includes two processors and all the tools you need to get going.

First, while this is an extremely cheap USB enabled development board, this is NOT an Arduino. It is however, an excellent way to introduce yourself to real “on the metal” microcontroller programming.

I downloaded all the tools, and visited their site for pointers to example code, etc.

First, TI is really trying to do the community thing, with a wiki, and featuring other people’s content.

They also have a curated portal that has links to some really cool projects too at :

http://e2e.ti.com/group/msp430launchpad/w/default.aspx

They also have a really good, structured workshop with videos and labs to really give you an overview of the platform. So far, I’m about a third of the way through the workshop, and I’m really impressed so far.

Installing Code Composer studio took a long time. It needs work on it’s installer code, as it gave all sorts of scary warnings about User Account Control in Windows 7, but in the end it worked out fine.

This eclipse based tool is TI’s flagship micro development platform and is usually licensed for a $500 or more. This
free version limits you to 16 K of code, but that’s about the biggest device in the MSP430 value line.

It’s also really nice having hardware debugging support. No more Serial printlns! Set breakpoints and examine variables. Awesome!

These processors feature super low power features. In fact the other thing I bought, the chronos watch development platform uses the same line of processors. I won’t go into all the modes here (covered very well in the workshop) but these processors know how to sip power! We’re talking microwatts or less.

The MSP430 processors feature an extremely flexible clock architecture. This allows you to do all sorts of clever things, using different clocks for different parts of the chip, or even driving external circuitry. I’m just starting to wrap my head around all this, but it’s one of the cool things my fpga friends brag about, and now I can play too!

The Von Neuman memory map (single address space for everything) is much easier to use than the atmel’s harvard architecture. No more PROGMEM weirdness. Of course you still have to be ginger about writing to flash memory (constrained to write in blocks in self programming mode the same as AVR’s).

It has pretty advanced analog to digital conversion  with DMA, so you can set it up to transfer directly to memory. Not all the chips have this but many do, and some have fancy compariters to use for pid control, etc.

All in all, I’m very impressed. I think it will be a lot of fun, and a good learning tool. It really isn’t as easy as the Arduino, so I wouldn’t recommend it for “Toe dippers” or folks looking for a quick and easy automation tool.

If they keep offering it at this price though, it could be a great teaching tool. The processors (2!) it comes with are pretty small (both in IO and memory, 2K) so it will be hard to squeeze a lot of Arduino like library in there, but for some small teaching type challenges, it may be good enough, and you can always upgrade the processor for under $3.

A week later, I also ordered the CapSense booster pack, a shield to demo the chip’s built in (no additional hardware needed) ability to handle Capacitive  touch controls. I’ll probably post more about this once I’ve had the chance to play with it.

I removed a delay in the 1.2 version of the supernikon code, so it should be more reliable now.
I also did an initial implementation of a canon remote, but I don’t have a Canon DSLR, so I haven’t tested it yet. Looks ok on the scope.

Here’s a link to the Canon code

and the Updated Nikon Zip

also available as a git repository: https://github.com/osbock/Baldwisdom

I left work a little early (around 4pm) to finish up the Cylon pumpkin.  The carving went pretty well, but it was starting to get dark by the time I put the electronics in.

If you want to do this project, please don’t do as I did with scratch building, and just buy the kit. When I put the electronics in the pumpkin, they didn’t work. I pushed my fingers around on the back of the board and I could get it to work sometime.

Back upstairs, I x-acto’ed between traces where there was already corrosion (I didn’t clean the flux very well) and resoldered a few things. Whew! Got it working 1 minute before the first trick or treater came!

And here’s the whole display. I hope you enjoyed it!

We’ve been so busy this season, there’s been little time for extra things. I used to go all out for Halloween, but this year we decided we couldn’t do much more than help the kids with their costumes. Well, this bothered me, and I decided to at least try to do a cool jack-o-lantern.

I’ve mentioned my love affair with EvilMadScientist.com before. They have a ton of quirky, always fun projects. (I’m still trying to convince Joyce we need an eggbot!)

They have a very nice, inexpensive kit to do a “Larson Scanner” which is  a row of LED’s that scan back in forth, like in the Glenn Larson TV shows Knight Rider, and Battlestar Galactica. They also love Halloween, and published a list of their Halloween related projects. The first Cylon Pumpkin they did, was a simple slit in the pumpkin to show off the scanner, but more recently they did this awesome carving:

The project linked to this picture uses an older circuit, not the EMSL kit...

Now I haven’t carved mine yet, and I wasn’t thinking ahead. It would have been much easier to just order their kit ($13) but I had most of the parts lying around, and I stayed up late laying it out and soldering it (badly) to a proto-board. My local electronics store doesn’t have a very good selection of proto-boards, but they had a cheap (<$3) proto-board laid out like a solderless breadboard.

I’m sure this is old hat to most folks, but I realized that I could squeeze the IC in, not in the middle where it’s supposed to go, but toward one side by cutting the traces between the rows of pins for the socket.

I didn’t want wires on the front, so I tacked them from the back, and that was hard, and a little messy, as it’s very cramped especially in the middle of the attiny micro.

Once again, this whole project wouldn’t have been possible without my adafruit usbtiny ISP programmer. I used an Evil Mad Scientist minimal target board to program the chip.

EMSL’s code is a thing of beauty and a lot can be learned by studying it. Hopefully I’ll be back after tomorrow night with pictures of the finished Cylon-O-Lantern.