Pentax IR Interval Timer

Hey, look at that, my blog website is still alive and working. Last post was Sep 2010, a long time ago.

I’m planning a trip to the desert, and one of the things I wanted to make for myself were time lapse movies of sunrise or sunset, and the night sky. My DSLR does not have a wired remote capability and Hoya has decided not to include an interval timer on their low end DSLR

I could have purchased a timer off ebay, that claims to be compatible with every DSLR ever made but those claims make me skeptical. I also did not care for their user interface. So, many months ago, I tore apart one of the Pentax IR remotes, to see what makes it tick. It was a simple design on the inside, a rather large micro-controller with external clock, a transistor, a capacitor, a few resistors and an LED. The trigger button was one of those resistive pad-switch types. Originally I thought I could just trigger the remote by pulling one side or the other end of the button high or low. This did not work, and when I scoped it, I discovered a handshake was employed between the two terminals of the switch, both leading to micro-controller pins. So it looks like Hoya didn’t want people hacking the remote directly.

Switching to plan B, I tore apart an old pioneer cd changer and harvested its IR decoder chip. Following some arduino code from Lady Ada, I tried to capture the timings of the IR signal using a PIC. This worked to a degree, and probably warrants further study down the road, but I couldn’t get the pulse train quite right and so the camera would not respond.

Abandoning the learning-remote line of thought, I connected the IR decoder to my o-scope and manually measured the pulse train. It was only 26 msec, and consisted of 15 transitions. 13 msec on, 2.8 msec off, and then 1 msec on/off repeated eight more times. Using the 12F683 chip (one of my favorites), I had access to an 8MHZ internal clock and a hardware PWM module. Microchip claims the hardware pwm maxes out at 20khz, but I had no trouble getting a stable 37khz carrier out of it. Then I whipped up a little subroutine in proton basic which toggled the carrier on and off with the appropriate timings. I had setup the pic’s pwm output on channel 1 of the scope, and output of the ir decoder on channel 2. I could fire the pentax remote at the decoder and compare it to my pulse train from the pic. When they were an exact match, I got the camera and presto, it started snapping pictures.

Cam Remote Schematic

That schematic is what I’ve worked out for a bare-bones version of the remote. A single button is used to program the interval, there’s a status led and room for two IR emitters. My current prototype is only using one emitter, because that is all I have right now. I’m also using a 2N3904 which isn’t ideal, but it was working on the breadboard and now it’s soldered in place. I just now looked up the specs, and the poor thing is only rated at 200ma collector current – that could explain the lack of output power I’m seeing on the emitter.

In interest of saving time, I didn’t make a PCB for this revision, but I’ll probably do that for the next prototype. All point to point wiring, I tried to be neat. I used a tiny SMT resistor to drive the transistor, it worked out real handy.

The timer and two AA batteries fit in this mint tin I’ve been saving for years. I don’t know if they are still in production; I would like to get a few more.

I field tested the timer at tonight’s sunset – I’m trying to figure out how to convert a bunch of jpeg’s into an avi now – stay tuned!

Update: Here’s the video, turns out Picasa can generate a timelapse … only 8 seconds, need more frames!

Mint Tin Bike Light Continues

As the (normal) bicycling season draws to a close for my latitude, I’m nearing completion on my bicycle taillight project. I sent out a few weeks ago for some professionally fabricated pcbs and as usual, they look great. There were a few bugs that were entirely my fault, but nothing serious enough to stop the pcb from doing its job.

bicycle taillight pcb assembled

I added two “features” to the pcb before sending the design out, both of which were untested in the initial prototypes. The main feature I wanted to have was “motion detection”, so the taillight would shut down should the bike become idle for a period of time. No need to be wasting precious photons while the bike is leaned up against a tree or parked in a bike rack. Motion detection is provided by a roller ball switch, intended to replace the old fashioned mercury switch. A tiny gold plated ball rolls around in a plastic and metal cage, completing electrical circuits during its travel. The light’s micro-controller recognizes these impulses and continues to let the light function. As soon as the tilt switch stops changing state, resting as either a short or open circuit, the uC begins a count. When that count totals some arbitrary number, the light returns to a standby mode with the SMPS in shutdown. The uC then watches the tilt sensor for the state to change again and upon a change, resumes the previous operational mode.

The second feature is a battery minder circuit. Using a 2.5v precision reference, the micro-controller samples the battery voltage using its on board ADC. The idea is to detect a weak battery condition and operate the SMPS at a lower duty cycle, to make the most of the remaining power. The assumption here is that some light is better than no light in terms of safety. One of my pcb bugs lies in this circuit. The Microchip 12F683 uC I selected for this project is an 8 pin device. Its voltage reference pin is also multiplexed with the programming clock. In my design, I had made the error of connecting the vref pin directly to the voltage reference output, which is biased with a 1k resistor to the Vdd rail (bat +). So effectively, I have a very strong pull-up to 2.5v on that pin. This made programming the PIC impossible as it could not detect clock transitions. I will try salvaging these PCBs by changing to a 10k or 20k bias resistor on the reference, or cutting the trace leading to the Vref pin and soldering a 10k+ resistor in series, since we don’t need any current on that pin, just voltage.

Once I polish the code a bit more, I’ll be looking for a few folks to send a sample units to in exchange for reviews and feedback, down the road I would like to sell these either as a kit or a pre-assembled unit.

Mint Tin Bike Light 3

I completed PCB revision three of the mint tin bike light on Tuesday, but due to lack of batteries for the camera, no pictures were taken! Luckily I’ve found and recharged a second set of batteries and the camera is once again operational.

Feature-wise, this revision adds nothing over the previous light, all the changes are in board design. Firstly, the artwork was redone using polygon pours instead of straight point to point wiring (traces). The revision two switcher was running pretty warm, mostly because it didn’t have much copper to dump the heat into.

The switcher’s ground pin is now tied directly into a very large copper pour, as are the Vin and Switch pins. Using a burning finger temperature probe, the chip remained at or below Tbody even operating in constant on mode at full power. Compared to the revision two board which saw the switcher running quite hot in constant on mode.

The current sensing resistor was moved a lot closer to the feedback pin. With a feedback voltage of 190mV, the tiny resistance of the trace was actually affecting output. Shortening the trace to roughly 1mm has helped a great deal.

Finally, the layout for the battery clips was fixed, and generous polygon pours were drawn around the pads. The spring clips are now soldered down very firmly and hold the batteries quite well. I have yet to take this unit on the trail, so we’ll see if a rubber band is required or not to retain the batteries while bouncing along.

I plan on making one more prototype before sending the design off to Custom PCB or Gold Phoenix. I think I’ll eliminate the battery clips on the chance excessive force could cause one to separate from the laminate and severely damage the pcb. I also want to try a board that hosts both driver circuit and LEDs. Additionally, I plan to add a tilt / vibration sensing switch (roller ball switch), so inactivity of the bike can be detected and the light switched off to save on batteries.

Thanks for reading!

Mint Tin Bike Light

I started this project a little more than a year ago, but shelved it because it wasn’t working right and I didn’t have the correct components. It was a seasonal project that would have little use over the winter, so I sort of forgot about it.

This year I’ve been going on a lot of bike rides with friends, sometimes on public roadways, sometimes after dark. My bike has a nine watt 500 some odd lumen headlight, which makes it easy to see where I’m going, and definitely makes me visible head on. The tail of my bike however still has the stock reflector, plus the little reflector stripes in my shoes, not exactly high visibility. Not wanting to pale in comparison to the headlight, the taillight is a three watt 140 lumen beast powered by three AA rechargeable batteries.

The light is based on a boost converter from National Semiconductor, the LM3410. I’m using the 525kHz SOT-23 version, the LM3410Y. Originally I had trouble with the chip self destructing, as discussed on the Linear1 forums. It was hypothesized either the inductor was underrated or the diode was too slow. Ordering parts for another project later in 2008, I bought some better inductors and diodes, which more closely resembled the specs of parts used in National’s web bench simulator. So, lacking sufficient rear light, I rekindled this project and have a “working prototype” that’s gone on two rides with me so far.

bike taillight schematic small

The basic function is fairly simple. The 3410 is a constant current boost (step-up) driver. A small inductor is used to ramp up the input voltage, from 3.6vdc nominal to 15.4v at approximately 200mA. The current is monitored by a one ohm resistor. A pair of output capacitors help smooth out the ripple and an input capacitor helps the batteries cope with the high demand current (as high as 1.5a in some cases). I’m using nickle metal hydride batteries, which have a rather low internal resistance – they’re designed for high demand applications and when fresh, barely sag at all under the load.

bike taillight pcb layout small

Originally I had planned on carrying the batteries directly on the PCB, using some through-hole spring clip battery holders I found in the Sparkfun library. However, AA batteries must be bigger in Colorado than they are in Michigan, because using Sparkfun’s layout gave me about a quarter inch gap between the spring and the battery. The pads were also woefully undersized for physically mounting the clip and holding it securely enough to survive the stress of batter insertion and extraction. So I dropped their layout and drew my own that looks exactly like it, but is based on measurements from a real AA battery.

Along for the ride is a Microchip PIC microcontroller, the 12F683. It provides a bit of user interface for the light, creating different blink patterns as well as putting the light into a “stand by” mode, with the switcher shut down. I’ve programmed several blinking patterns, and somewhat organized them into “modes” which I can select using the little button.

A year ago, I didn’t have any sort of enclosure in mind. The led array was assembled on a ‘standard’ sized protoboard, so I probably thought about using a plastic or aluminum prototype enclosure. However, this year, I was thinking it would be a nice fit for a large mint tin. After printing out some mock-ups and messing around with battery configurations, I settled on using three batteries and having the electronics crammed into one side of the tin with the led array mounted in the lid of the tin. This setup might have worked, except for the battery snafu. I’m using a plastic three cell holder right now, and the extra thickness it adds is preventing the lid from completely closing. It closes enough that the light is easily held shut by some big rubberbands, and it survived bouncing around under my seat for two short rides. The next revision will have the battery situation resolved and I might have a better mounting solution by then too.

Overall I’m very pleased with the outcome of this project. I have more parts on order to make a few more lights for my other bikes and friends, and I want to experiment with other array configurations and colors. There are a two videos of the light on my youtube channel, but they’re nothing to get excited about.

Thanks for reading!

LED Cube

I was trying come up with something impressive to write about, after having the blog dormant since July. I tossed around a lot of different ideas… Although I haven’t been writing, I’ve been dabbling in a number of different projects. None of them are really in a state I’m ready to write about. That brings me to something I saw a few months ago on MAKE:. Bre and associates had constructed a simple 3x3x3 led cube, re-purposing a POV toy to drive the leds.

I figured this would be a good easy project I could finish in a day, so I drilled out a piece of pine board and set to soldering up some 3mm leds. I wasn’t very careful, so the little matrices look kind of ugly, but it all works and you can’t see the wires in the dark!

3x3 led matrix building

It didn’t take very long to toss three of these nine led matrices together. Assembling them into a twenty-seven led cube was a bit trickier. I used some gator clips to hold parts of the cube while I soldered it. Eventually I finished all the connections and had a passable cube with fairly even spacing.

3x3x3 led cube finished

Assembling the matrix is a pretty straight forward task. All you really do is tie all the cathodes together. Each matrix will become one row in the finished cube. Electrically, the cube is built as a 3×9 array, three rows and nine columns. You could probably build it the other way around, anode rows and cathode columns, but it is easier to sink a large current than source it. I think the MAKE: software only lights one led at a time, since they’re relying on the microcontroller to both source and sink current. My design is a bit different. The mcu sources current to each anode column, and N channel fets sink current for the entire row. The N channel is easily able to sink a few amps, so the cube can light an entire row at once without having to multiplex the individual leds.

In order to keep the PCB layout simple, the connections are spread all over the place in terms of the registers inside the pic. It would have been cleaner to organize eight of the nine columns as a single 8bit register on the pic, leaving only one bit left over to deal with. Instead, I’ve created symbols for each column, and set them individually from 9bit numbers.

Each anode column is current limited by a 75 ohm resistor. The value chosen was rather arbitrary, since the leds have such a low duty cycle, a lower value would have afforded me more brightness when the cube is battery powered. I can tweak the brightness a bit in the software, changing the scan rate the rows are multiplexed at.

That’s pretty much it. I’ve found there’s not a lot you can do with only 3x3x3 and 1 color, but it’s still kind of fun. Trying to think in three dimensions while drawing the animation frames is kind of tricky. I started with excel, but that wasn’t very useful – I spent more time copy and pasting formulas than I did ‘drawing’. Luckily my buddy Dan helped me out with that. He whipped up an awesome little php script that lets you draw animations 27 leds at a time, and it formats the resulting numbers so I can copy and paste them right into the code.

There’s a few videos of the cube doing various things on my Youtube Channel. Here is perhaps the most interesting one so far.

Thanks for reading, and Happy New Year!

LED Clock; Firmware taking shape

The firmware for my LED Sign / Clock project is taking shape.  I’ve worked out my initial wishlist of features, and put together a basic menu structure.  I figured a menu is the  easiest way to access a lot of options, while only relying on two buttons.

The basic menu consists of options for setting the time and date; minute, hour, day, date, month, year.   The basic options are pretty self explanatory.  I have also planned some more advanced options:

1. Adjustable display brightness – Varying the duty cycle and refresh rate of the matrix can effect its brightness.  I need to make a simple scale for these variances to allow for two or three brightness levels.

2. Adjustable scrolling speed – The program draws the same information several hundred times per ‘scroll’, changing this counter affects how fast the display appears to scroll.

3. Selectable time format – User can choose between 12 hour AM/PM time and 24 hours ‘Military’ formats

4. Message Mode – User can enable / disable scrolling messages as well as display a single message, a random message or messages in sequence.

Other than that, the code is still pretty basic.  I’ve completed a bunch of internal fixes, like the scrolling code now handles messages of variable lengths. up to sixteen characters.  I’ve also created i2c eeprom reading routines to extract menu prompts and other text strings I’ve stored in the eeprom to save flash space on the chip.

LED Sign has a purpose!

The single character LED sign I had been playing with now has a purpose! Shortly after discarding several ideas of having it as a serial display for PC/Server status, or hooking it up to the internet and a webcam, I came up with an actual useful purpose. The sign can be a clock! I have two ‘modes’ planned; traditional numbers and binary. All geeks love binary clocks, but most of us are lazy and would rather read regular ‘ol numbers.

To facilitate the role as an clock, I had to redesign the circuit quite a bit. Two new ICs were added, allowing the LED Sign to keep time, and providing some much needed storage.

led matrix sign clock rtc microcontroller schematic

The first of the new ICs is a Real Time Clock. Because I’m cheap, I chose the M41T80 from ST Micro. It’s an inexpensive clock, similar to the Dallas DS1307 but lacking a few minor features. First, the clock has no power-on reset detection. It just starts up as soon as power is supplied. The Dall 1307 has a stop bit which gets set if the clock experiences a POR, so the firmware can test if the clock needs to be initialized or not. The T80 datasheet mentions some registers may get set to default values on power up, so I’ll have to read it a few more times to see if there is a way I can check for a POR. Second, the T80 has no support for a separate backup battery. Instead, ST recommends you place a diode in series with the clock, and use a large capacitor to provide backup power. Last, there is no automatic leap year / leap second correction, oh well!

The second IC is a 16 kilobit serial eeprom, similar to the Microchip 24C16, I chose one from Catalyst semiconductor due to lower costs. The eeprom is arranged as eight banks of 256 bytes each. The chip contains a 16 byte write-buffer, I’m not sure if it can cross a bank boundary or not, I’ll program my firmware assuming it can not. The eeprom will be storing character strings related to operation of the LED Sign as a clock, as well as user programmed messages and possibly simple graphics.

I’ve also added some micro switches for adjusting the clock and changing settings, also a 32.768kHz crystal was added to providing the timing source for the RTC.

pcb layout led sign clock

At this point, the layout of the printed circuit board has become pretty complex. I tried making one of these at home, but didn’t have the patience to exactly align the top and bottom layers of my press and peel sandwich. So, I decided to try a pcb prototyping house. There are a lot of board houses to choose from, many of which cost an arm and a leg. All of the domestic board houses are ruled out, I’m sure they do a fine job, but they cost too darn much. I settled on Spark Fun’s BatchPCB service. They’re not the cheapest board house out there, but their cost is fair. They include a lot of features most other board houses charge extra for, like double sided silkscreen and solder mask, 8 mil pitch and spacing, 20 mil holes, etc. I placed my order on the 6th, and had the PCBs by the 22nd. All the time in between, by mind set to wandering, and I made some POV toys. Once the pcbs showed up, I incurred another delay. Turns out I hadn’t ordered my RTC chips yet! So, another few days wait brought goodies from Mouser (man they are quick, and inexpensive!)

batchpcb led clock circuit board

The boards from batchpcb look awesome. Nice bright green solder mask, tinned pads and holes, smooth clean edges. This is the ‘top’ side of my led sign. There are a few passives on this side, along with the two new ICs. This side is covered by the LED matrix once the board is fully assembled. Don’t mind the flux smeared everywhere – I did clean it off before soldering the matrix down.

led clock circuit board

The bottom of the board contains the PIC processor, mosfet column drivers, a crystal for the clock and some microswitches. Pin headers for power and programming the microcontroller have also been installed. The module is a bit thick at this point, thanks to the socketed IC and the pin headers. On the finished version, I’ll solder the IC straight to the circuit board, and probably use wires instead of a header to supply power.

led sign clock done

The firmware is in the early stages right now, so my next post on this subject will try to cover whatever features I’ve decided on. Right now I know I want a few things:

1. Scroll the time
2. Occasionally scroll the date
3. Occasionally scroll short messages, either randomly or programmaticlly
4. Support some sort of software brightness control

I’ve made some revisions to the design since I had these boards fabricated. One big oops I made was forgetting the pull-up resistors for the i2c bus! Luckily there’s plenty of room on the board, and both i2c lines ran near the Vcc rail. So a little quick scraping action to peel back the solder mask and presto, new lands for 0603 sides resistors. I’ve also added a diode and big capacitor for the RTC’s backup power.

I hope to work on the firmware more this week, so I should have more details about how the clock works next time!

EDIT: Added a quick video of the time scrolling

POV Toy

I recently had the urge to create some “eye candy”; Thinking along the lines of my LED Sign (it’s not dead, just waiting on parts!), I chose to create a similar effect, using only a single line of leds, instead of a 5×7 array.

Persistence of Vision is some sort of effect, either psychological or biological in nature, that allows our eyes and brain to ‘see’ motion and patterns in a sequence of rapidly stills (hence a movie projection). This effect can be exploited using basic digital electronics to create a virtual LED sign, which the viewer will ‘see’ when the pov toy is put in motion.

Commercial POV toys are usually some sort of led matrix attached to a spinning contraption, and display either a fixed or scrolling message. Those are fine, but the technical aspects of motorizing the display make it beyond the scope of a simple project. Therefore, my project relies entirely on elbow grease – swing the wand and watch the messages appear.

Revision one of my POV toy is compact. It measures approximately 2.25″ length wise by 1.1″ width wise. The circuit consists of an inexpensive Microchip PIC 12F683 microcontroller, and a 74HC595 serial shift register. The display consists of eight 3mm leds, I chose blue for the first unit, but I’ll probably make a few more with different colors, I especially want to see green and amber – those leds don’t see a lot of action in the world of consumer electronics.

pov led microcontroller shift register schematic

The circuit is very simple. A tiny microcontroller provides the brains, a simple and inexpensive shift register provides the brawn, and a switch and hall effect sensor provide some control. My first unit has no hall sensor, so power is controlled with the push button switch. When “off”, the pic is in a ultra-low power sleep state. Come to think of it, I could have put the shift register into a tri-state mode when “off”, but for now, it holds its gates at Vdd, which provides no bias across the leds, so there shouldn’t be much current going anywhere. The hall effect sensor will eventually control the power to the display, as well as provide some synchronization. Right now when swinging the wand, the message is legible in one direction, and backward in the next. I plan to try putting a small round magnet in a tube, and gluing it behind the hall sensor. When swung in one direction, the magnet will be forced over the sensor by g-force. When the wand is swung back, the magnet will be forced away from the sensor. This should let the microcontroller know not only to blank the leds during the ‘backward’ swing, but also how much time it has to render the entire message, speeding up the display for a quick swing, or slowing it for a long swing.

The circuit board is a single layer layout with two jumpers. I went with as many SMT components as I could afford, since I hate drilling holes in my home-made circuit boards. Power is currently provided by a 3.7 volt 1600mAh lithium ion cell.

I tried making some video of the unit in operation, but my camera wouldn’t play ball. Next weekend I may have more time to fiddle with photography and try to get some ‘action shots’.

Although version one has been a great success, and was easy, I was unsatisfied. The eye candy just isn’t sweet enough. Version two takes the flash factor up a notch, with RGB leds. I’m working on a ‘full color’ POV wand toy. Version 2.0 has been built, but it has some flaws – and is the subject of my next blog entry. Here is a video of “2.0” running a test pattern on its 24 led array.

LED Sign; Now With Scrolling!

This morning I hammered out a quick and dirty method to scroll a message on my single character LED sign. The scrolling is based around a few subroutines. A text message of 12 characters is passed to the scroll subroutine, along with the number of loops to make. The scrolling routine breaks the text message down into individual bytes, and loads up a static 60 byte message buffer based on data from the font table. Each “scroll” iteration causes the program to copy data from the message buffer into a 5 byte display buffer. The message buffer address is offset by one byte each iteration. Since one byte equals one column on the display, this action cause the display to appear to scroll. Another sub routine watches the address pointer, and wraps it around to the beginning when appropriate.

Single Character LED SIGN

We’ve all seen the various sites where someone put a massive led sign online, and they let people abuse it. What I’ve managed to build is a “single character” led sign. I don’t know if I’ll be able to get my sign online, but I’ll take a stab at it.

After wasting a lot of time to convert a font table I borrowed from somewhere, my little sign finally had a built in character generator. It can generate any of the printable original ascii characters (dec 32 to 127), and display them on the matrix. Data feeds into the sign at 4800 baud (I think i mentioned 19200 earlier – way too fast), and is displayed on the matrix for a few seconds.

If the display sits idle for too long, a basic screen saver (screen waster?) kicks in, and does a simple animation. Any received characters replace the animation and reset the screen saver timeout.

Although exposed, I haven’t implemented the i2c interface yet. This pc board has some issues, and is too large. I don’t like the connectors sticking out to the side like that, so it’s back to the cad package to try and re-arrange things a bit. I think I will fork this design into two separate paths. One async serial (rs232), and one sync serial (i2c / spi). The sync version would be used as a display for other projects. The async version would be hooked up to a PC, and programmed with a simple message. Once detached, the display would just repeat the message over and over. One problem I ran into is storage. I had hoped to store text strings and the font table in eeprom, but the processor I chose, the 16f737 has no on-board eeprom. So instead, the font table is stored in the flash program space along with a few short text strings. The next revision(s) of the board will include a spot for a so8 ‘seeprom’ for extra storage.