Pete's Blog

Programming a Cookbook

2017-03-31T23:15:00.000-04:00

As my girlfriend Rima and I were cooking dinner we read over the recipe we'd made before. Soon we would struggle to recall if it was the lemon juice or the salt that we wanted to reduce or omit this second time around. Or was that an increase we had wanted? This was turning out to be the usual guessing game.

I also lamented the fact that my favorite meal recipes live exclusively in said girlfriends head. With this in mind, we came to the natural conclusion that we should write a cookbook; something for our own use. i.e. an aggregation of recipes we like from books, family, the internet, and even the ones that we've made up ourselves.

As I began mulling over cookbook writing options, it occurred to me to use LaTeX. LaTeX is a document typesetting system that is used primarily in the scientific field of document and book publishing. It is a very powerful tool to programmatically generate very clean documents. I have used it on many occasions when writing notes for various math classes, airplane checklists, reports, and more.

The decision to use LaTeX really came together when I discovered that someone has already written a LaTeX package for typesetting recipes. The package is called Cuisine and you can read more about that in the link. Below is a screen cap of some LaTeX to generate a recipe using the Cuisine package followed by the typeset output in the finished PDF book.

You can see from the image above that the recipes follow a format where a group of ingredients and an action to perform on the ingredients are linked. This is continued in chronological order with 1 or more ingredients listed and an associated action to perform with those ingredients.

I really like this order of listing ingredients. It succinctly communicates and compartmentalizes each step of the recipe thereby reducing confusion, errors, and even fatigue. It is tiresome to read a recipe that says "Add the cumin" and then you have to hunt thru the ingredient list to find how much cumin you need.

The first task was to design the LaTeX document. This entails setting margins, paper size, fonts, preparing a table of contents, a title page, etc. With the rough template sorted out, I turned my attention to entering recipes.

I got about 2 recipes deep before I realized a better way to enter recipes was needed. As you can see in the syntax above, there are a lot of brackets and braces and duplicate typing. It was clear that typing up a multitude of recipes in LaTeX was going to be a tedious adventure. This is where Perl comes in.

The idea was to casually type up a recipe as a text file that could be parsed and let Perl do all of the tedious and repetitive typing. This way, we can just type up a new recipe text file at any time, take a picture, and rerun the scripts to output a new copy of our nicely formatted cookbook. After all, who knows how many recipes we may come up with!

Below you can see an example of one of these user typed recipe.txt files. This file was used to generate the LaTeX that output the hummus recipe above. As you can see, the format is quite simplified when compared to the LaTeX. Write a line that starts with 't' for title, 'p' for picture filename, 's' for setup, 'i' for ingredient, 'a' for action - a cooking step, and 'n' for any note. These line type identifiers are separated by the '>' symbol for parsing.

The first three lines must be in all recipe text files. i.e. Title, Picture, and Setup. If no picture is wanted for a particular recipe, simply set the filename as "none". e.g. "p > none". This will omit the picture and placeholder image for a given recipe. If a picture is desired, then the filename should be entered on this line and the image file stored in the ./Latex/Images directory.

The subsequent Ingredient and Action lines must be in the order you wish them to appear in the recipe. When creating the recipe text file, write 1 or more Ingredient lines followed by an Action line that describes an action to perform with the previously listed ingredients. Continue the recipe by listing the next set of ingredients and an action to perform with them.

The Note designator must only come at the very end of the file, although if no note is required, simply omit the line and line type designator entirely. i.e. have no line that reads "n > ".

So, the Perl script can now parse these files and generate the LaTeX, but this alone does not a cookbook make. We need chapters, but which ones? What if a friend or family member wants to make a book, but doesn't want a desert chapter? Will we have enough soup recipes to warrant their own chapter or should we fold those in with the main courses? The penultimate scenario is strange to be sure, but clearly chapters must not be hard coded in LaTeX or Perl; we want all that code to remain unchanged even as the contents of the cookbook change.

To handle the changing needs of chapter definitions I went with a directory structure scheme. The directory "Chapters" is scanned for directories who's name should follow the convention "x-ChapterName" where x is any letter used to force an alphabetic order to the directories. The order that the chapters appear in the book is set alphabetically by the left "x-" portion of the directory name which is then discarded. The chapter names are generated by the Perl script using the right portion after the hyphen only. In the screencap below then it is clear to see that there will be 4 chapters in book order "Snacks", "Side Dishes", "Soups", and "Main Course". In this method chapters can be added, deleted, and renamed without the need to change any code.

From the above image you have probably already guessed that there are two recipes that will be included in the "Snacks" chapter. However, the only thing you can discern from this is the alphabetical order in which the recipes appear within the chapter. i.e. the filename is not used to title the recipe, however naming the files something descriptive is recommended. It might be hard to go back to edit your recipe for fig jam if the filename is 123.txt. The title of the recipe used in the cookbook is contained within the recipe text file itself on the line "t > 'Recipe Title'".

Toward the beginning of the book goes the front matter. This contains the author name, book title, and a preface. This front matter gets placed before the table of contents, and is generated from a user editable text file at ./latex/frontMatter.txt. It is parsed similarly to the files described above where the lines "a >" is for the author, "t >" is for the cookbook title, and "p >" is for the preface.

To make your own cookbook in this manner you will need Perl and LaTeX. Additionally, a sample cookbook structure is included in this Google Drive shared folder. It should just be a matter of downloading a copy the directory, editing your own frontMatter.txt, and recipe cards. Oh, and be sure to add some pictures of your tasty foods. With all of the edits in place, run the perl script then typeset the LaTeX and out comes your cookbook.pdf. If you are interested in taking a peek at our latest cookbook you can download it separately.

Well, I think that is about it. With only a couple evenings work we have a sustainable method of maintaining our own cookbook. Now, I am off to the kitchen to make a pizza. If it turns out well, it might make it into our recipes.

Watchmaking - My Beginnings

2016-05-31T13:33:00.002-04:00

I want to make a watch. More specifically, I want to make a watch movement. And I'm reasonably sure that I have yet to realize the magnitude of this aspiration, although with every project I undertake it becomes more clear.

I have been at this watchmaking thing for just about a year and a half now. In that time I have managed a few clock repairs, and even a few watch repairs. I've also failed several repairs by shooting tiny springs across the room, permanently deforming miniscule watch parts, and have rocketed a balance jewel to bounce off a wall before disappearing forever into the carpet, but as time goes by my skillset is improving.

Learning the oh-so-delicate touch required for successful micro-manipulation of watch components is something that I read about, and I am glad I did. But to get in there with a loupe and a pair of tweezers has taught me so much.

As you can see, I am barely a novice at this. Perhaps needless to say, if you are looking for proper watchmaking advice, look to one of the texts in the "Literature" section below. Still, I wanted to capture some of my watchmaking experiences so far. The general theme of which is a sort of dive right in and learn by doing.

Literature

Here is a partial list of reading materials that have helped me along the way. The list is in no particular order. If you google the title of the text you may find that there is a pdf online. I have many of these watchmaking pdf's, but since they are not mine to distribute I won't be linking them directly.

A Practical Course in Horology 1944
The Practical Lubrication of Clocks and Watches
The Complete Clock and Watchmaker Manual by Mary Booth
Riveting and Staking March 2012
A Treatise on Staff Making and Pivoting
TM 9-1575
Vigneaux Practical Watchmaking
Chicago School of Watchmaking

Additionally I have purchased these books:

Websites

Forums:

http://forums.watchuseek.com/f6/
http://www.watchrepairtalk.com/

Youtube:

https://www.youtube.com/user/bunnspecial
https://www.youtube.com/user/perplxr
https://www.youtube.com/user/spahlow
https://www.youtube.com/user/jewldood
https://www.youtube.com/watch?v=vTQT6PwgJTA
https://www.youtube.com/watch?v=ys4ChOWYNy8

Parts/Tools:

http://www.ofrei.com/page235.html
http://www.casker.com/
eBay is where I buy most of my vintage watchmaking tools.

Tutorials:

http://www.clockmaker.com.au/diy_seiko_7s26/

Terminology

As with any new hobby you have to learn the lingo. Here are some of the terms that I didn't understand at first.

Wheels are gears
Pivots are bearing journals ( burnished to size with a jacot tool, fyi. )
Staffs are axels
Jewels can be either female plain bearings, or in other locations pallet jewels or impulse pins.

Tools

When I started started this journey I had no suitable tools. Even my smallest "Jeweler" screwdrivers loomed ominous above the diminutive watch movements. I started with a "cheap" set of watchmakers screwdrivers, probably from eBay. I eventually purchased several more sets until finding a set of Starrett screwdrivers. These work for all but the very tiniest of screws, say on a hairspring stud or such. I also like them as I know Starrett is a quality brand.

For general work I use a binocular visor magnifier. It has a wide field of view and a long focal length. For oiling and other high magnification jobs I prefer a binocular microscope. Mine is an AMScope brand and works very well. You can see pictures of it in the Watchmaker bench section below.

Loups are also important. I have a Bausch & Lomb on a wire to strap it to my head. This loupe has a very short focal length, and a very narrow field of view. It is sometimes hard to get the part you want into focus. In fact, the stack of loups I bought from harbor freight might even suit me better than the Bausch & Lomb. I mean, they must be of a lower quality, but they have a wider field of view and sufficient clarity and magnification. Yes, I think I like them better.

Good tweezers are important. Did you know that you will be sharpening tweezers at some point? I didn't, but it is as simple as clasping a file or stone in the tweezer jaws to dress them up. At any rate, I find I use my brass tweezers the most often these days. The Excelta and WLXY tweezers below require more force than the others, and as a result have less feedback. They are still OK, but I use them much less often.

I also make frequent use of Rodico putty for cleaning, removing smudges, removing oil from screws, etc. I Prefer the blue case back remover ball better than the 3 jaw adjustable type. You can also see the black puffer bulb to displace rogue fibers and dust specks. You wouldn't blow warm moist air from your lungs onto a clean watch movement, would you? The puffer bulb is also good for giving a spin to a balance wheel to check its rotation. All of this is sitting on a green watchmakers mat. It is reasonably soft, yet firm, and helps parts from slipping around or disappearing from plain sight.

Below is a collection of some of my other tools. If you would like to ask about any tool in particular, please feel free to leave a comment.

Watchmaking tool gallery: https://goo.gl/photos/Bbgp44ysX8Nyt6zbA

Bench

When I very first started tinkering with watches I was using a standard height desk. I had to hunch over the watches and it cast a shadow over the work. This was less than Ideal. Since I had an old sewing table that I wasn't using, I decided to re-purpose it as a watchmakers bench. I added some risers to the feet to bring the desk height up quite a bit.

I also replaced the sewing machine with a watchmakers lathe.

Adding a positionable lamp with a CFL bulb, and a microscope on an arm really made this bench something useful. It might be a little on the short side still, but overall it is a very serviceable bench.

Here are some more photos of my Sewing table to watchmakers bench transition.
https://goo.gl/photos/5CESun2cBQigS22o7

Cleaning

It is important for me to keep track of where everything goes as i'm taking apart a watch. To that end I take photos as I go along. I also make use of these blue plastic watchmaker trays below. I currently have two, but a single movement can fill up both with no problem. It would be nice to take parts from one compartment, clean them, and move them to a new, clean tray. So, I have ordered two more trays from eBay.

The glass dome on the right of the picture below is a vintage movement cover. It is necessary to cover all movement parts any time you are away from the bench even for a short while. These protect against dust settling on the movement and accidental physical damage. I recently ordered 3 more of these vintage movement covers from eBay.

I am still working out my cleaning methods, but basically I use a combination of manual cleaning and ultrasonic.

The tools I use for cleaning in no particular order are:

Rodico - a blue/green putty
Harbor freight ultrasonic cleaner
Peg wood
Pith wood
An acid brush with cut down bristles
Paper
Kimwipes
Carburetor / MAF cleaner
A hybridizer - essentially a low temperature oven ~50 deg C

A watchmaking forum member once wrote to me on the subject of cleaning. Here is an excerpt from his advice.

IV. Cap jewels should be rubbed on lint free paper or tissue.
V. Holes must be pegged through from both sides.
VI. Pivots have to be rotated in pith.
VII. Wheel teeth and pinion leaves shall be carefully brushed.
VIII. Plates and bridges shall be rubbed, pegged, pithed and brushed.
VIV. Pallets and balance completes require single dip treatment. (I brush pallets and rub the faces with hard paper. Be sure to inspect the impulse jewel for dirt/damage.)

My cleaning method is as follows.

Exercise caution to avoid losing parts. This is always true, I suppose.
Process one group of parts at a time to keep them compartmentalized and help me remember where they go.
Generally I only clean screws with Rodico.
For really dirty or oily/greasy parts I may soak them in lighter fluid first.
Mechanically clean the parts with brushes, paper, peg/pith, etc.
Send the group thru the ultrasonic cleaner with hot water.
Rinse the parts in hot water.
Use carburetor cleaner to displace all of the remaining water.
Place parts in the low temperature oven for final drying. Note that the carburetor cleaner can evaporatively cool the parts below the dew point resulting in, well, dew on the part. This is why I favor the use of the oven.
The ultrasonic cleaner is probably not necessary, however my harbor freight model is inexpensive and can be used for other items around the house.

I do not use the ultrasonic cleaner or carburetor cleaner on any parts with shellac mounted jewels. This would include the balance staff with impulse jewel, and the pallet fork with its jewels. I have not yet had to replace a shellac mounted jewel, so I am rather cautious not to disturb them. I am looking forward to doing it one day though.

Once a part is clean you don't touch it with your bare fingers. I use nitrile gloves or latex finger cots.

Oiling

I am a little reluctant to write this section as there are many whom are rather passionate about oiling. Nevertheless, I will relay how I go about it.

I picked up this oil cup / decanter thing on ebay. It is nice. The yellow, and blue generic oilers came from Amazon, and suck. One was rusted and another was broken. I ordered a nicer set of Bergeon brand oilers that haven't arrived yet. They come in different color coded sizes corresponding the the amount of oil they can hold, that is to say the handle color does not necessarily match the oil color.

I use Moebius 9401 for mainsprings, and other "high load" areas such as mainspring barrel pivots, winding mechanisms, click springs, etc.
I use Moebius 8000 for smaller pivots and "low load" areas such as pallet fork jewels, roller jewel, etc.
The gear wheel train teeth do not get oiled.
I use a microscope for oiling, so I can really see what is happening. A loupe of sufficient magnification would be OK too.
The oilers work by dipping the oiler into some oil. They retain the oil due to surface tension and the shape of the oiler tip. Touching the oil laden oiler to a watch part will wick the oil from the oiler onto the pivot.

Here is some more information: http://www.ofrei.com/page951.html

Projects

Here I'll give a little description of some of the projects I've worked on, and link to the photos I took while working on them. They are in order starting from my earliest project to most recent.

Seiko 5

Here is a Seiko 5 which was my first experience disassembling a watch. I didn't clean this one as it was brand new. I didn't even oil it. I just took it apart, blued some screws, and polished some parts before reassembling it.

I followed this guide http://www.clockmaker.com.au/diy_seiko_7s26/ The tutorial is missing a couple pages at the end for reassembly, but it is easy enough to sort it out from the disassembly pages.

I lost the click spring on this one. It shot out from under a plate that I removed. Two days later I found it and was able to complete this watch. Each time I wear it I remember the trials and tribulations we have been thru together.

Here are some more photos: https://goo.gl/photos/E3SJgWmraomovewb6

Heuer Stopwatch

Stopwatches are good practice candidates as they are not as sought after as pocket watches, and as such can be purchased for less money. They are generally larger than wristwatches, too.

This Heuer stopwatch was absolutely filthy inside. It was also missing several pieces. I elected to only disassemble, clean, and oil this one, and not repair/replace missing broken/components.

During cleaning I lost a balance jewel on this one. Then, I found it in the carpet, only to lose it again.
In the end, I learned quite a lot from this project.

Here are some more photos: https://goo.gl/photos/1TAUbgpPX9aaYhNNA

Grandpa's Banjo Clock

I acquired this clock a while back. The movement was caked with a green gelatinous grease. Also, one of the pivot holes is severely worn. I gave this clock just a quick clean with partial disassembly to evaluate it. It hangs unwound on the wall awaiting the pivot hole repair. It will also need a winding key made.

Photos: https://goo.gl/photos/2z6A21fyzLEwG5v79

Dad's Dila

This is a watch that my father's mother gave him when he was a teenager. The mainspring broke not long after he had it, and it stayed broken for nearly 60 years.

I replaced the mainspring with a new old-stock steel spring. This new spring broke also, so back inside I went. This time I replaced the mainspring with a modern "white alloy" spring which has been running without issue. Dad wears the watch quite often now.

Here are some more pictures: https://goo.gl/photos/Wr178dHLkBhhwzs48

Raketa Big Zero

This watch is called the Big Zero because of the large 0 at the 12 o'clock position. I read that Mikhail Gorbachev used to wear one. At any rate, I think it looks pretty cool on the bracelet I ordered from Amazon..

While working on this watch I lost a balance jewel. I pinched it a little too hard, or at just the wrong angle so that it launched itself from my tweezers. I combed the carpet fibers for a while before resigning myself to it being lost. Then I went to eBay and purchased a lot of 3 non-running movements of the same type. These three 2906HA movements only cost $17 including shipping. I harvested a balance jewel from one of the donor watches, and finished the job.

On this watch I got a little carried away with the case polishing. There was a ding I was trying to buff out. As I was doing so I realized that the watch case is chrome plated brass. You can now see a bit of the brass poking out, but it's OK you and I are the only ones that will know.

More pictures: https://goo.gl/photos/u2mbcLh8URiWRq5aA

Waltham Model 1877

This Waltham Model 1877 was made in Waltham MA in 1883. A lot has changed in the world since then!

I bought this pocket watch from eBay. It would stop running depending orientation. It would run on its face, but stop when vertical.

After disassembling the watch I discovered it had a smashed out balance jewel. I think you can order drop in replacements, but I decided to go a different route.

I ordered an assortment of loose jewels from eBay. When they came in I searched thru them to find one of the correct inside diameter for the balance staff. Then I turned a brass chaton to hold the jewel.

A chaton will have a bore of specific depth, and a diameter to fit the OD of the jewel. The chaton will have an undercut outside the OD of the jewel to allow this material to be burnished over the jewel, capturing it in the chaton.

Between ordering parts, and several failed attempts at making a chaton, this watch took a while to complete. I think it took so long in fact that I forgot to clean it before reassembling it! This watch will have to come apart again for a cleaning before I can say this project is done.

Pictures: https://goo.gl/photos/BXawYhNaLnqD1f7U6

Elgin Aircraft Clock

This is an 8-day clock meaning that it will run 8 days on a wind. A coworker generously gave it to me after learning of my forray into horology.

This clock movement is about the size of a pocketwatch movement. I was pleased to discover all the parts were present. After a clean and oil the clock was ticking again. It was a minute off after a couple days, so I made a timing adjustment. It is on my desk at work, so we will see how the adjustment worked this Monday morning. I love the faint ticking sound at my desk.

I noticed this clock has two wheels to drive the second hand. One is attached to the second hand shaft, and the second is free to rotate about the second hand shaft. Both are driven by a pinion gear, there is a very light spring providing torque between the two wheels. This provides anti-backlash for the second hand so it won't be flopping back and forth between pinion leaves as you are flying around.

I lightly brushed the dial with soap, water and a toothbrush, and left the hands untouched. I wanted to leave a witness to the clock's vintage.

Additional photos: https://goo.gl/photos/ixytccCJ9S74TPZw9

Other Projects

I have a few other projects on the go too, but nothing to show for it yet. I am looking forward to trying out some more manufacturing techniques in the future to further work toward my goal of making a watch movement.

Words of Wisdom

The only advice I could offer is encouragement. Read as much as you can, but get in there and start doing it. Maybe start on movements that are not sentimental or otherwise valuable.

If you have any advice for me please leave a comment below. I am always eager to learn better ways to do things.

I am sure I have forgotten some things as I am tired while I write this. Perhaps there will be a follow up on the future.

Good luck on your horological adventures!

Digitizing Grandpa's Reel to Reel Tapes

2016-03-19T07:06:00.001-04:00

My grandfather had a bunch of these reel to reel tapes from the 60's. I thought it would be a good idea to digitize them to preserve the audio incase the tape began to deteriorate. Conveniently enough, my aunt gave me this reel to reel player a few months ago. I should have everything I need to manually transfer these audio tapes into digital format now.

But, there are quite a few of these tape reels, and my mind wanders. I wonder if I could make this a semi automatic process. The primary benefit would be that I don't have to be present during the entire recording process. Of secondary benefit, I get to play with electronics.

I want to be able to set a tape playing and the recording program will automatically stop the recording when the reel to reel player stops playing. Without automatic stopping of the recording, I am certain I would forget that I am recording and wander off to do something else while Audacity dutifully records silence at the end of each tape.

So, here is the setup. To get the audio into the computer I made a 1/4" phono plug to 1/8" phono plug cable. This cable runs from the reel to reel headphone jack to the computer's microphone input. I am running a program called Audacity on this computer to handle the recording of the audio signal.

Like many programs, Audacity has keyboard shortcuts. Press SHIFT + R to start/append a recording. The spacebar will stop a recording. Sending CTRL + SHIFT + E will open the audio export window. All of these commands can be sent to Audacity with a keyboard, but we are trying to automate, so our commands will come from an ATMega32U4 microcontroller instead.

To know when the reel to reel player is playing, and thus when to have the microcontroller tell Audacity to start recording, I connected a Light Detecting Resistor along with a fixed value resistor to form a voltage divider. The output of the divider is wired to the ADC on the ATMega32U4 uC.

The LDR ( Light Detecting Resistor ) is taped with blue painter's tape to the VU meter face. The voltage from this divider circuit is read into the uC and compared to a threshold. When the reel to reel is running, the VU meter turns on a tiny incandescent bulb inside. The LDR voltage divider provides a high voltage when it sees light ( reel to reel is running ) and a low voltage when it sees little or no light ( reel to reel stopped ).

Operation:

Initially the reel to reel is stopped and a reel is loaded. A new Audacity window is opened up by the operator. As soon as the reel to reel starts playing, the VU meter lamp in the reel to reel turns ON, and the microcontroller detects the LDR voltage. The uC then sends the keyboard shortcut SHIFT + R via USB to start Audacity recording. I am now free to do other tasks without worrying about missing the end of the reel to press "stop" recording.

When the tape reaches the end of its run, the reel to reel will shut off, the VU meter will go dark, and the uC will send out ASCII 0x20 for a spacebar command. This will stop the recording.

Then the uC sends out CTRL + SHIFT + E to open the audio export path dialog box. Here, everything will wait until I am available again. At which point I enter a suitable filename to save the recording, and setup the process for the next side of the tape.

Conclusion:

I have now digitized both sides of one tape. Everything went smoothly for the first side.

On the second side, however there was a small problem. The screen saver came on. When the recording was finished, the uC sent out the spacebar command to stop the recording. Instead of stopping the recording the screensaver consumed this keypress and woke up, so the recording didnt stop. Fortunately, I caught this problem early and have disabled the screensaver for the duration of this project.

An alternative solution to this problem could be to send a keypress that Audacity does not recognize before sending the STOP recording shortcut. The first keypress would cancel the screensaver, then the spacebar keypress could stop the recording. If the screensaver was not on, the first keypress is benign and only the spacebar command will be acted upon.

Here is a short sample of some of the audio I captured while setting up this system. It ends abruptly because I was just testing the start/stop commands from the uC:

https://drive.google.com/file/d/0B1CPUkh94AtmcHR3OGNmQkMwc0k/view?usp=sharing

Let me know if you have success digitizing some reel to reel tapes using this method or perhaps you have a different method?

Microcontroller Code:

// running on an arduino pro micro

#include 

int ledPin = 17;    // Onboard the arduino pro micro
int ldrPin = A0;    // light Detecting Resistor input

int adcRaw = 0;

#define OFF_THRESHOLD 512
#define HYSTERESIS 25

#define KEY_LEFT_CTRL  0x80
#define KEY_LEFT_SHIFT 0x81
#define KEY_LEFT_ALT   0x82
#define KEY_LEFT_GUI   0x83
#define KEY_RIGHT_CTRL 0x84
#define KEY_RIGHT_SHIFT    0x85
#define KEY_RIGHT_ALT  0x86
#define KEY_RIGHT_GUI  0x87

#define KEY_UP_ARROW   0xDA
#define KEY_DOWN_ARROW 0xD9
#define KEY_LEFT_ARROW 0xD8
#define KEY_RIGHT_ARROW    0xD7
#define KEY_BACKSPACE  0xB2
#define KEY_TAB        0xB3
#define KEY_RETURN 0xB0
#define KEY_ESC        0xB1
#define KEY_INSERT 0xD1
#define KEY_DELETE 0xD4
#define KEY_PAGE_UP    0xD3
#define KEY_PAGE_DOWN  0xD6
#define KEY_HOME   0xD2
#define KEY_END        0xD5
#define KEY_CAPS_LOCK  0xC1
#define KEY_F1     0xC2
#define KEY_F2     0xC3
#define KEY_F3     0xC4
#define KEY_F4     0xC5
#define KEY_F5     0xC6
#define KEY_F6     0xC7
#define KEY_F7     0xC8
#define KEY_F8     0xC9
#define KEY_F9     0xCA
#define KEY_F10        0xCB
#define KEY_F11        0xCC
#define KEY_F12        0xCD

int ledToggleCounter = 1;

void setup()
{

  Serial.begin(9600);
  
  pinMode(ledPin, OUTPUT); // onboard LED

  
}


void loop()
{


adcRaw = analogRead(ldrPin);

// if the player is ON
if( adcRaw > OFF_THRESHOLD + HYSTERESIS ){
  
  ++ledToggleCounter;
}
else if( adcRaw < OFF_THRESHOLD - HYSTERESIS )
{
  // player is off
  //digitalWrite( ledPin, HIGH);

  delay(1000); // Wait a bit to make sure the reel to reel is really off.

  // If the signal is still low.
  if( adcRaw < OFF_THRESHOLD - HYSTERESIS ){
    
    Keyboard.write(0x20); // Send the spacebar to stop the audacity recording
    delay(500);
    Keyboard.press(KEY_LEFT_CTRL);  // Send CTRL + SHIFT + E to export the audio
    delay(100);                     // Audacity will wait for a filename to be manually input.
    Keyboard.press(KEY_LEFT_SHIFT);
    delay(100);
    Keyboard.write('e');
    Keyboard.release(KEY_LEFT_CTRL);
    Keyboard.release(KEY_LEFT_SHIFT); // CTRL + SHIFT + E complete. 

    // Stay here  until the reel to reel turns on again
    while(analogRead(ldrPin) < OFF_THRESHOLD ){
      // Blink fast because we are stopped.
      digitalWrite( ledPin, !(digitalRead(ledPin)));
      delay(200);
    }
    
    // The reel to reel has turned ON! Start recording.
    Keyboard.press(KEY_LEFT_SHIFT);   // Send SHIFT + R to Start/Append the audacity recording.
    delay(100);
    Keyboard.write('r');
    Keyboard.release(KEY_LEFT_SHIFT);
  }
  

}
else{
  digitalWrite( ledPin, LOW);
  }

  // toggle the LED at 2 Hzbecause we are recording.
  if( ledToggleCounter % 10 == 0 ){
    digitalWrite( ledPin, !(digitalRead(ledPin)));
    ledToggleCounter = 0;
  }

  Serial.println(analogRead(ldrPin));
delay(100);

  
}

tgimboej

2016-03-18T22:11:00.003-04:00

tgimboej is an acronym for The Great Internet Migratory Box Of Electronics Junk, which is pretty much what it sounds like. You can sign up to receive one of the boxes; participation is free - you just have to pay to ship the box to the next person. When you receive the box, you can take out a few bits, and put some back in before sending it to another recipient.

You can read more here: http://tgimboej.org/Main_Page

They say one man's trash is another's treasure, but that doesn't really apply here. I found the components in the box of very high quality. I was quite pleased with the selection. I even found an immediate use for one of the switches I acquired!

Here is a photo of the bits I took.

As you can see I got some sweet switches, a stepper motor, some gear motors, an audio jack, binding posts, SMD to PTH adapters, perf board, a piezo buzzer, and a key switch. Thank you to the donors!

Here are some photos of some of the things I added.

I hope you will sign up. It was a rather fun experience.

A GUI Makeover

2015-05-30T08:22:00.000-04:00

I've been wanting to play around with a different look for this blog for a while now. I thought the previous layout looked a bit passé. I also didn't like the color scheme for unclicked hyperlinks vs clicked hyperlinks; they were hard to read and not distinct enough to be useful.

And, so I made a few changes. It was a painful process; I don't consider myself to have an eye for the artistic. Basically, I just poked around at color schemes and backgrounds for an hour until I got bored.

This new layout is definitively different and subjectively more satisfying to the eye. Below is a pic of the old layout so that you can be the judge.

Ok, so I just checked the preview of this post before...posting, and I have to laugh a bit. I guess the new and the old look are not as contradistinctive as I had led myself to believe. We'll keep it anyhow.

Nixie Tube Clock

2015-05-25T23:24:00.002-04:00

If you've poked around the internets where electronics hobbyists collect, it is likely that you are acutely aware of our incontrovertible affinity for building timekeeping clocks. It is similarly unlikely that you have been able to evade the plenitude of nixie tube based projects. There is a reason for this.

Nixie tubes are cool. They have great aesthetic appeal with their difficult-to-photograph, warm orange glow, and dem curvy numerals. They add an organic je ne sais quoi to a hobby with ostensibly digital design cues. Further, they pose technical challenges in the way of producing and switching the ~175 V DC needed to light each tube element. ~~And as far as I am aware, there are no new nixie tubes being produced~~; as such, procurement can be a challenge unto itself. My N.O.S. nixies came from Russia thru Ebay, and only 3 were duds. Incidentally the seller replaced those 3, FOC.

The ~~strike thru~~ text above results from a tip from +nicholasStock who points out new nixie tubes ae in fact being produced: http://www.daliborfarny.com/ The linked tubes are really impressive from a technical standpoint as well as asthetics. They seem to amplify all of the design cues we love about NOS nixies and the results speak for themselves. Might still be an issue with procurement, however...

Nixie Tubes and HV Driver
From Russia with love

K155ID1's are shipped in stacks bound by rubber bands

Fortunately, not all nixie tube clocks are implemented the same. In fact, look around at all the schematics for nixie clocks, and you will realize there are more permutations in methodology than there are models of nixie tubes. This is how it should be. We ( DIY electronics people ) like to put our own spin on things.

My version of the Nixie Clock has a few of its own nifty features. The list includes:

Single microcontroller design.
Software based RTC.
Software driven boost converter for ~175 V DC supply.
Time, Date, and behavior configuration via USB
Windows application for clock configuration.
Time, Date, Temperature, and AC Power line frequency display.

The Name

I was working on the PCB layout and thought it would be cool to write "Nixie Tube Clock" in Cyrillic script, so I did a google translate. You can see the translation on the top right of the PCB. Well, it turns out that "Nixie" translates to something of a shapeshifting water-woman. So, I call this the mermaid clock now. Thanks to the native language speakers that pointed this out to me.

Downloads

The clock firmware can be found on GitHub here: https://github.com/pilotingpete/Nixie-Tube-Clock

The Nixie Clock Communicator code can be found on GitHub here: https://github.com/pilotingpete/nixieClockCommunicator

An Electronics Bill of Materials - Please notify me of any errors: BOM

The KiCad schematic and board files. Also, a collection of datasheets, and some logfiles from when I calibrated my prototype clock. Perhaps there are some other files in this archive that I thought were useful while I was working on this project too: Electronics Package

Here is the current schematic in PDF in case you don't have KiCad installed.

Researching Nixie Tubes online I learned about Cathode Poisoning. I don't know a whole lot about it, but suffice to say an unused or seldom used nixie element will deteriorate over time. I read that you can sometimes reverse this deterioration by applying a higher than normal voltage to the element for a period of time. I also read that you can try to make sure all elements get some ON time to prevent or slow the deterioration of elements.

The last paragraph should be read as "We have an opportunity to do some neat blinky stuff with our tubes!" Hence, the video below. This pattern occurs every 30 minutes - at the top and bottom of each hour.

RTC

Four short years ago I posted about a method for building your own microcontroller based realtime clock. This is essentially a method to calibrate your xtal to more closely match real time, and some code to keep track of the time and date. The benefits of a uC based RTC include a reduction in components and everything that comes with that; increased reliability, cost reduction, real estate savings, &c. We can also achieve accuracy in timekeeping greater than that specified in stand alone IC RTC's datasheets.

In the aforementioned post, we only discussed the theory and showed a proof of concept example. There were no software provisions for calendar with leap year, 12/24 hr format, etc. That is, the finishing touches to make a useful RTC for a clock were left out. This nixie clock builds upon the methods for coding your own RTC and shows the implementation to make a useful clock. This code could easily be recycled into any number of clock projects with LED, LCD, OLED, displays too.

The core RTC code can keep track of the time and date, account for leap years, and report the day of the week. One could expand this to take care of DST, but I go into detail about why I don't in the previous post.

While designing the hardware for the clock I added a "zero cross detector" to the incoming AC power line. We can use this in lieu of the calibrated xtal to keep time - users choice.

All those nixies controlled with just 3 uC lines. Thanks, shift registers!

USB Interface

Using the ATMega328's built in UART we are able to communicate with the firmware via an FTDI USB cable to configure clock settings and behavior parameters. These parameters can also be read back out of the clock and/or stored to the internal eeprom of the ATMega328. Parameters stored to eeprom are read into memory at boot up, so that the clock's configuration is persistent thru total power loss.

For example, open a terminal to 56700 baud and type "celsius=1" and hit enter. This will set the clock to display the temperature on the Celsius scale. Setting this parameter to 0 would result in the Fahrenheit scale i.e. "celsius=0".

If you were to type "hours?" the clock would reply with "Hours: nn" where nn is the currently displayed hours. There are also parameters for "showFreq", "showDate", showTherm; each of which are set to display its unique parameter value at the top of each minute or not. i.e. if you type "showtherm=1" then at the top of each minute the temperature will be displayed - in Celsius or Fahrenheit as previously discussed.

Below is a screenshot of the available commands. At the terminal type "help" and hit enter. The column labeled "command" shows you the available parameters to configure. "Set/Read" column suggests that you may set a value with '=' and read the value with '?'. The "Low Lim" and "High Lim" columns show the range of acceptable values to input.

USB Terminal Interface

"getall" returns a csv line of all current parameter values. The order can be verified in the firmware.
"ramtoeeprom" will store all current parameters to eeprom so that they are recalled after a total power removal. Time and date are excluded - view the firmware to confirm all parameters that get stored.
"poke" returns the clock serial number - mine is S/N: 100; what will yours be?
"pwrok", "hvfeedback", "battvoltage", and "rectifiedac" return system voltages. Refer to the schematic for voltage points.
"doecho" is a UART echo and is useful for typing at a terminal; it lets you see what you are typing. It is not so useful when using the NCC app and should probably be turned off i.e. "doecho=0"
"nixiesleepstart" and "nixiesleepend" set the time that the nixies turn off and on at night. We dont need to burn up valueable nixie time while we are sleeping. If nixiesleepstart is 0, then they will never sleep and nixiesleepend is necessarily ignored.
"toggleled" if set to 1 then the LED on PD7 will toggle at 1 Hz. Set to 0 and no more toggling - the LED will remain in its current state. It is neat, although power wasteful, if toggleled=1 and a power outage occurs. The LED continues to toggle letting you know the clock is still running.

Wouldn't it be cool if we had a PC app to handle all the communication? So that we can just click a button and the app would send the current PC time to the clock, for instance? I think so too, and more on that below.

A video showing the time, date (2015.05.29), temperature (28.93 C), and AC Frequency (59.991 Hz).

Boost Converter

The boost converter utilizes one PWM channel and one ADC channel on the ATMega328. A function is called at 1 kHz to check the voltage coming out of the boost converter and thru a voltage divider. If the voltage is higher than a setpoint, then the PWM duty cycle is reduced. If the voltage is too low, the duty cycle is increased. The resultant ~175 V DC is quite stable.

*I discovered that stopping the timer is not a suitable method of turning the boost converter off. The state of the output pin can sometimes come to rest at ON. The result is a direct short thru the boost converters inductor. Many fuses gave indication to a problem here. The solution is to disconnect the pin from the PWM timer in software and then set the output low. Check the firmware and code comments for more information.

Reflow soldering the SMD components

Kapton Solder Paste Screen

Hardware

There were/are a couple of mistakes made when I designed the PCB.

First, the datasheet I have for the nixie tubes was incorrect. I used the datasheet to make PCB footprints in KiCad and never checked the physical tube before sending the PCB to manufacture. They were in the mail at the time. The physical tubes are a full 180 degrees upside down compared to the datasheet. I corrected this in KiCad and sent the new gerbers to be manufactured again.

The new boards came back ready to go. Or as it would turn out, ready for me to find more mistakes. Like R8, which is supposed to be a pullup resistor for the DS18B20 temperature sensor, not a pulldown as I drew originally. I discovered this one when I couldn't get any temperature readings. Rather than remake the boards I drilled out R8's via to GND and added a wire jumper to VCC. You can see this fix below.

Drilled out VIA to disconnect R8 from GND

Red Jumper for R8 to VCC

The R8 pullup/pulldown error has been fixed in KiCad and included in V1.1 as REV A.

Prior to discovering the pullup/pulldown mix up on the DS18B20, I had discovered that my linear voltage regulator supplying VCC was overheating. I had underestimated how much current the HV driver IC's would consume - they doubled the circuit total. I also underestimated the voltage that would be coming out of my 12 V AC adapter. It is approaching 18 V DC after rectification.

To salvage this embarrassingly obvious oversight I ordered 10 premade buck converters from ebay for about $10 total. They are based on the LM2596 IC and are voltage output adjustable. Now, I feed that ~18 V DC into the buck converter and send ~6.5 V DC out to the linear regulator. Hopefully, I will remember this lesson and incorporate buck converters appropriately in the future.

Below are some pictures showing the repair/mistake. Since this photo was taken I have potted the linear regulator and wires to prevent shorts or strain failures.

LM2596 Buck Converter

Buck Converter Wiring

I currently have several of these nixie clock boards as spare. If you would like one, send me an email and I can figure out how much they cost. Although I did drill out R8's VIA on all boards they are subject to needing the R8 jumper to VCC fix still, and the buck regulator fix described above.

SW1

There is an unpopulated tactile switch on my PCB. I put it there "just in case" but I don't have a need for it. Perhaps it could be used to cancel an alarm or put the nixies to sleep/wake them up? Let me know if you end up coding anything for it!

Battery Backup

In the picture below you can see the battery backup schematic. BATT-4.5V is just a 3x AAA battery holder. I resisted the urge to use a CR2032 battery or similar in lieu of the larger AAA batteries. My reasoning being that I have plenty of real estate inside the clock case, and weight was not a concern. Also, I always have AAA batteries on hand, and they are cheap.

So, this battery pack is connected to VCC via a schottky diode such that the battery is not a source so long as VCC is at a greater potential. When power is lost, and VCC is at a lower potential than BATT_VOLTAGE, the diode allows the battery backup to conduct and keep the circuit alive seamlessly.

Here, BATT_VOLTAGE goes to the ADC on the ATMega328 and allows us to measure the voltage of the battery pack. Presumably, we could work out a way to determine when battery replacement is necessary. For now, we just read the voltage.

AC Frequency Measurement

Below you can see a schematic showing the method of digitizing the AC input waveform. There is a nominal 12 V AC on L1 and L2. AC_FREQ goes to a pin with internal pullup on the ATMega328. Therefore, this pin is normally high and pulled low once per positive AC cycle. Say, for an AC sine wave input somewhere between 0 and Pi there is a square pulse output.

I included this part of the circuit mainly because I wanted to measure the ac frequency of the power line. I have never done his before, and thought it would be a good opportunity to do so. There is the added benefit that you could use this AC input to drive the clock if you were so inclined. The software would just need to count up 60 cycles ( or 50 in some countries ) and tick over the seconds.

EDIT: As I wrote the previous paragraph I realized that I should just take a break and code the AC frequency as a timekeeping source. To run the clock in this mode, you can now type "acclock=1" at the terminal.

I am partial to the xtal calibration method described in the RTC section above ("acclock=0") , but I do recognize that method takes some level of commitment to implement. Certainly, both timekeeping methods have their merit based on the expected usage environment of the finished product.

When a power outage occurs and acclock=1 the xtal will step in and keep time. Yet another good reason to run the calibration procedure anyway...

I tried to get a scope cap of what this looks like in operation, but it didn't come out very well because the AC and DC sides of the circuit don't share a ground. Anyway here it is. You can see blue half of the AC sine wave and the digitized red trace that we can feed to the input of the uC.

Counting up the rising edges of the red trace until we get to our nominal AC frequency ( 60 Hz in the USA ) then ticking over our seconds. So far this has been quite acceptable for accuracy although I have not run this mode for more than a week or so.

The AC/AC Transformer

Clock Case

Functionally, a clock case is very important. It needs to provide thermal stability for the clock innards, mechanical protection from bumps and dings, light splash protection from water, and protection from dust, or rather a surface to collect dust that is easier to clean than the populated PCB alone.

Putting on my humility hat I attempt to create a clock case from wood. Sycamore; locally harvested to be precise. It is a work in progress, but my vision for the case involves dovetails, radii, and a glass front panel - possibly etched. I hope to continue on the case soon - I imagine the wood quipping that it could have grow itself into a clock case faster.

Local Sycamore

Table sawing the 1-1/8" thick boards to half thickness for case sides.

Marking and cutting out dovetails

Admiring the Sycamore grain

Windows Application

The purpose of the Nixie Clock Communicator app ( NCC ) is to simplify the setting, and calibrating of this nixie clock. It is not required for use, but is handy - particularly during development and debug.

For instance, to set the time I could open a terminal and connect. Then type "hours=12" [ENTER], "minutes=55" [ENTER], "seconds=13" [ENTER] and the nixie clock would be set to 12:55:13.

No problem. But with the NCC app, I can click the "Send PC Time" button and the app will look at the current system time, wait for a new second to tick over ( mS = 0 ), and then immediately send the seconds, minutes and then hours.

Additionally, the app can datalog the time and date that the clock thinks it is, concatenate this with the PC time and date, and log this to a text file. Using this information we can derive a calibration value such that the long term accuracy of the XTAL is compensated to drive the clock very near to real time. More on this in the "Calibration" section below.

The app is written in C# using Microsoft Visual Studio 2013. Although the code compiles, runs and does it's job, it is very much a work in progress - I am currently trying to work out some bugs where there seem to be some phantom characters triggering my serialRead event handler. I am sure there is a logical explanation, but I have not sorted it out just yet. If you do, please let me know!

Nixie Clock Communicator ( NCC ) app for Windows.

Calibration

Before you attempt to calibrate the clock it should be placed in a suitable enclosure. One that is vented yet free from drafts. The idea being that you want to keep ambient thermal excursions from affecting the temperature of the xtal case. Direct sunlight might be desirable to avoid.

It does not greatly matter what the temperature of the xtal is, so long as it is stable over the long term. Having said that, if one were to have a choice of temperatures to put the xtal near, it would be wise to select one nearest to 25 C, however do not neglect the benefit inherent to a stable temperature.

It might save you some frustration to have tested out the battery backup before now. However, if power outages do occur during calibration, the outcome may be an improper calibration value. It occurs to me now that there should be a firmware counter that keeps track of the number of times the clock enters battery backup mode. If that number is > 0 while calibrating, a new calibration should be performed.

Steps:

With the clock in its case, and the case with the clock placed in its preferred place of use, set "mscal = 0" and set the time and date precisely and accurately. Use time.gov or something similar.
Allow the clock to run continuously for at least 1 week. Longer calibration periods get a greater average of environmental changes and potentially a higher degree of calibration precision. Allow the clock to experience all environmental changes expected during normal operation - if you have a programmable thermostat let it run its course etc.
Optional - use the NCC app to data log the nixie clock time, and host PC time/date to a log file. I set my logfile up in a google drive folder so I can check the progress anywhere.
When the clock has run for a week or more, compare the current real world time to that of your nixie clock. This is particularly easy if you've been using the NCC app.
If the nixie clock is running faster than the real world time, set "xtalisfast=1", otherwise "xtalisfast=0".
Compute the time error in Parts Per Million by (realWorldTime / nixieTime)^-1
Compute the mS Calibration value by mscal = F_CPU / (F_CPU * PPM_ERROR)
Set "mscal=nnnn" where nnnn is the calibration value calculated above
Read back your values to be sure you set them right: "mscal?" and "xtalisfast?"
Store the values to EEPROM so they will be remembered even thru a total power loss by typing "ramtoeeprom" and hit [ENTER]
Optional - remove power, reapply power and check that mscal and xtalisfast have been stored properly.

Below is a screen cap from some notes I took while calibrating my prototype clock. The first 2 lines were generated by the NCC app and serial nixie data. The nixie clock sends out the time/date that it thinks it is on the right at the top of a minute. The NCC app prepends the current system time/date on the left then logs this to a file. The last value on each of the first 2 lines is the current temperature. In the example below, you can see my mscal value is 21180 and xtalisfast should be set to 1.

To be more explicit, the format of the top 2 lines in the screen cap below is as follows. PC Date, PC Time, Nixie Clock Date, Nixie Clock Time, Clock Temperature in Celsius.

Since the proof is in the pudding, as they say I wanted to log some real world data to see how well this calibration scheme would work. So, I stored "mscal=21180" as found from above, and ran the clock with the NCC app logging data again. After 45 days it was revealed that the nixie clock was running 8.698 seconds fast which is about 2.24 ppm.

That's pretty darn good I'd say. For reference, 2.24 ppm is about 70 seconds in 1 year, and somewhere around 46 seconds in 8 months. Since I adjust for DST in intervals < 8 months, it is clear that the nixie clock should never be a full minute off from real time.

Miscellaneous

If you're thinking about skipping the fuse in the circuit, please don't. It is remarkably important. I once thought of using a PTC, but even that is a bad idea here. You really want total separation from the power source and a deliberate reapplication. To that end, do not move past a burned fuse until you fully understand why it blew. Read the section on the boost converter and look at the schematic if you need further convincing.

This project has taken somewhere around 6 months to date. I have to admit that I am a little surprised by how challenging this project has been. It has also been a lot of fun. If you have any questions, please feel free to email me or leave a comment.

Mobile Radio Power Controller ( MRPC )

2014-10-10T01:06:00.001-04:00

Before I began the installation of my Yaesu FT-8800 in my car I knew I wanted automatic power ON / OFF. This is a feature that I have always felt was lacking in my other mobile rigs as I am forever leaving my ham radio on long after I have departed the car.

Let's start with an action packed video of the finished product, then we can talk about how we got there.

First, I set out to determine if my radio has such a feature natively, and I found the following. Per the FT-8800 user manual, there is an Automatic Power Off ( APO ) feature. Below is a screen cap from the manual describing this operation.

As you will read, this feature can be used to turn OFF the radio, but not back ON. And for the APO to turn the radio OFF there are several specific requirements including leaving the radio in a non-scanning mode - not necessarily something I can commit to. In the end, I determined this APO is not helpful to me in its current form.

Recalling that my radio will return to its last known power state meant that I only have to apply power to the radio when the car is ON and disconnect the power when the car is OFF to achieve my goal.

Having ruled out the APO feature on the FT-8800 I set out to see what products already exist on the market to automatically toggle my radio power. Surely there should be something for <$50.

Wrong. I did find this for ~$100 and this for ~$60, but these prices made me bristle with antagonism. I was quickly learning that this would be a DIY project. ( As a point of reference I ended up shelling out $8.23 in parts for my MRPC. )

And so began what I hope to be my very last PCB design using Eagle CAD. I have several specific opinions related to my disappointment with Eagle, but I won't go into it today. ( ok, I recently learned the hard way that Eagle uses proportional fonts. They look good in Eagle, but send your board to fab and they are converted to fixed-width vector fonts. The result is the word "controller" is partially cut off my silk screen layer. )

So, as I was saying, I won't go into my issues with Eagle today, but after designing a board in KiCad and having it manufactured, I can say what a massive improvement. I am probably still a bit slow with KiCad, but I imagine my proficiency will improve as I move to exclusive use of KiCad over Eagle.

Ok, back to business. Below is a screen cap of the schematic drawn in Eagle. VBATT_IN is the 12 V DC car battery power. It is fed into D2 for reverse polarity protection before heading to a 5 V DC regulator. Prior to D1, the VBATT_IN voltage is also feeding a voltage divider of R1 and R2 and 48 Hz LPF with R2 & C2. The resulting voltage is an attenuated analog of VBATT_IN fed to the ATTiny85 microcontroller ADC.

With the ATTiny85 able to measure system voltage, it can now determine when the car is running ~14 V DC with the alternator running, ~12 with the engine off. We will talk about the program some more later on.

R4 feeds the base of Q2 which pulls down the gate of U1, which is otherwise held high by R3. U1 is an IPD90P03P4 mosfet. It has an RdsON of only 4.5 mOhms which; in testing, allowed me to comfortably pass about 200 watts at ~13.5 V with no heat sink.

Further down is a link to the Mobile Radio Power Controller ( MRPC ) Bill of Materials ( BOM ). The voltage regulator I used is an obsolete part. You should select a new one if you decide to build a MRPC board. Another reason to select a different regulator would be because the one I use draws a shameful 5 mA quiescent current. I might recommend something like an LD1117.

I had these boards fabbed thru the OSH Park service. It was my first time using OSH Park, and at the time of this writing, 50% of of my OSH Park orders have been for MRPC boards.

If you would like to order one of the boards, well you can't, you have to order 3. It's the OSH Park rules. The good news is that those 3 boards will only cost you $9.05, at the time of this writing, for each multiple of 3. For the record, I am not affiliated with OSH Park and no money goes to me if you do purchase a board thru them. Here is a link to the PCB order page https://oshpark.com/shared_projects/jAyTdKon

The circuit board is housed in a custom enclosure I designed in AutoCad. The *.stl was exported, sliced in Slic3r and printed on my Prusa 3D printer. The material I used is Red PLA. I have uploaded the *.stl files so you can print your own at http://www.thingiverse.com/thing:495167

The software is pretty straight forward. Basically, the code tells the processor to sleep forever. This is to reduce power. The watchdog timer will wake the processor up once per second. At this time an ADC conversion is initiated. If the system ( car ) voltage is above a threshold, the event is logged. If the voltage exceeds the threshold for a period of time, the mosfet is switched ON. If neither threshold is met, the mosfet stays OFF appropriately. Everything should be commented, but if you have any questions, feel free to email me.

Downloads:

Here you can download the project archive.
Here you can download the Eagle PCB files
Here is the link to order a PCB

I think that's about it. Let me know if you end up building one for yourself!

blueShift - An OpenXC LED Tachometer

2014-07-06T08:04:00.002-04:00

An Arduino, some addressable LED's, a bluetooth module, code and a 3D printer come together to make blueShift - An OpenXC LED Tachometer. blueShift is so named for the Bluetooth protocol used for data communication, and the use of a tachometer to indicate when to shift your car. It may be amusing to note that the driver and passengers traveling in this car would observe Blueshift when peering thru the windscreen, provided their velocity was sufficient.

About a month ago I picked up a new car. It's a Ford Fiesta with a 1 liter, turbo, eco-boost engine. It achieves roughly 2.5 times greater fuel efficiency than my Jeep. This fuel efficiency was my primary impetus to purchase, but the new tech in automotive electronics is a pretty cool bonus.

It took a couple days driving around to figure out all the bells, whistles, and electronic gizmos in the Fiesta, and just that quickly, I was looking for something more. What that turned out to be was Ford's OpenXC API. OpenXC is part hardware, part software. It is open source, as the name suggests and aims to ease us into integrating vehicle data into our android apps, and in case of blueShift, embedded hardware.

Let's take a brief, but closer look at OpenXC and the potential it provides. For quite some time now, auto manufacturers have provided an OnBoard Diagnostics port. This OBD2 port, as it is sometimes called, is a digital interface to engine management parameters and chassis/body status. To the typical hobbyist, an OBD2 ports data is relatively inaccessible. You would need to know manufacturer proprietary PID's for the CAN messages you were viewing to discern "air intake temperature" from "outside air temperature" for instance. Likely, the information you were able to decode is specific to one vehicle make/model or worse, ECM batch.

Under the OpenXC umbrella, Ford has developed a hardware module called a Vehicle Interface or VI. This VI plugs into your OBD2 port, and interprets engine parameters and chassis/body info. These data are then packaged into JSON format, and relayed out over Bluetooth SPP. If you were to look at the OpenXC Data set you would discover that listening to this Bluetooth connection provides you with a plethora of vehicle specific information in real time. For instance, you can read your accelerator pedal position, fuel level, odometer, brake pedal status, and of course engine speed. The list goes on.

blueShift aims to utilize these engine speed data to drive a set of LED's in an easy to interpret, graphical manner. The circular nature of an off-the-shelf LED strip lends itself to this project nicely. What's more, these LED's are individually addressable, RGB LED's. This means that we can set any LED on the ring to just about any color we like, at any time we like. blueShift takes advantage of these addressable WS2812B LED's to create an interesting and informative display.

At first glance it may seem a second tachometer in my car is superfluous. I can say after having used blueShift, quite the opposite is true. The LED's are much easier to read with peripheral vision than the stock tachometer needle. Likewise, blueShift would be very useful for someone who races Ford automobiles. Additionally, blinky LED things are just plain cool, and no further justification for this project is therefore necessary.

The only wired connection to blueShift is for power. All data transfer is accomplished over Bluetooth SPP. Presently, this power is derived from my vehicles on-board USB power. I have plans to derive power from the OpenXC VI power port in the future. This will require a small regulator to convert the vehicle ~14 V DC to a microcontroller compatible, regulated 5 V DC supply. This supply will also need to supply power for the LED ring, so current consumption should be considered.

3D Printed Enclosure:

Sometimes a project will take you to unanticipated places. In the case of blueShift, that ended up being the land of 3D printing. Typically when I make a new project I am left to drilling and milling existing enclosures, and sometimes tupperware. What I am left with is a finished product that looks less than finished. When I was envisioning how I wanted blueShift to look, it deviated rather drastically from the prototype seen below.

Once it was decided to build a 3D printer to print blueShift's housing, I started down the path of designing a 3D printer of my own. I had a basic layout and construction method in mind when I started looking for approximate pricing on parts. I soon discovered that the constituent parts of my 3D printer design were approaching the cost of a 3D printer kit. This led me to purchase a Prusa i3v from Maker Farm, and I am glad I did. The kit was assembled in a few evenings. The decision to build a kit saved substantial time over designing a printer. The first prints were the requisite calibration cubes and then some other items. There is probably still some fiddling to do with the printer setup, but I am pretty pleased with the print quality so far.

Here is a photo of the partially finished 3D printer.

I designed the 3D models for blueShift in AutoCad 2014. I then exported the models as *.stl files and uploaded them to Thingiverse for sharing. You can download the *.stl files to print your your own blueShift enclosure, or I think companies like Shapeways may print them out for you if you don't have a printer ( yet ). I have no experience with that.

Below are some photos of the enclosure in various states of printing, and drawing revisions. The portions of the print that have large gaps and look like a lattice are intentional. This makes up supporting structure for parts with overhangs while printing. It is designed to break off easily, and in practice this is sometimes true.

I am really enjoying 3D printing. Even with it's obvious limitations, I feel that I will make good use out of this tool. I see many opportunities to print things that may or may not be necessary, but ultimately I am having a great time with it.

Electronics:

Part List:

I am using an RN-42 Bluetooth module from Sparkfun called a BlueSMiRF . One of the first things to do is connect to the modem and configure it for Auto-Connect Master Mode (SM,3). The AT Command sheet will walk you thru this process. For more detailed information on how to connect the Bluetooth module, and enter into command mode, refer to the Sparkfun tutorial.

With the Bluetooth module configured, we can wire up the rest of the circuit and tuck it into the blueShift housing. Here are a few pictures that show this process. Great care should be taken to avoid short circuits. Currently I power the blueShift from an FTDI USB cable.

The little tactile switch will perform a function in future software revisions. For now, it does nothing in software.

The two red wires with header pins are for the bluetooth modem power. This is represented as a SPST switch on the schematic labeled "HEADER". It is necessary to unpower the modem when uploading new firmware to the Arduino. This should be shorted out while operating blueShift to power the Bluetooth Module, and disconnected for uploading new firmware to the arduino.

This would be a good time to install the software and verify everything works. If you need to re-solder anything, it is better to find out now. The author may have experience that lead to this warning.

In the picture below, this semi-opaque, 5mm thick disk is possibly polypropylene. I purchased the stock from an unknown bin at a shop and belt sanded it into shape. There are 3 equally spaced clearance holes drilled into this lens to accommodate the M3 mounting bolts which we are about to install. Drop the lens into the outer housing and line up the holes.

Insert the assembled and tested inner housing into the outer. Line the three M3 bolts up and screw the entire assembly together.

Screw the Ram Mount to the back of blueShift. This will now suction cup to your windshield and plug the FTDI USB cable into a USB port in your car. If you don't have a USB port onboard, there are 12 volt outlet to USB adapters available.

Software:

You can download the Arduino code here.

When blueShift first turns on, there is a brief pause. During this time, we are waiting for the Ford OpenXC VI to boot up, and for blueShift to establish a connection to the VI. For a bit of fun, we display the "Waiting for Bluetooth Throbber" that you can see below.

Once a connection is established and valid RPM data is coming thru, the display changes to "Run Mode". In this state, RPM is displayed as a green LED trail. It grows clockwise as RPM increases, with the final LED being displayed in red for a bit of visual interest.

This final LED, the highest LED displayed, is "sticky". That is to say, as your RPM begins to decay, the peak RPM read will continue to be displayed as a single red LED. This will either persist until 3 seconds have elapsed since the peak measurement or once a positive rate RPM is detected.

Since OpenXC provides with boolean headlamp status on the same bluetooth connection, we can implement auto-dimming of blueShift. As soon as your headlamps come on, blueShift will dim. When your headlamps return to the off state, blueShift will regain full brightness. This is not just a nicety - it is rather important. These LED are quite bright and without dimming at night the result is a well lit car interior.

The sticky LED telltale can be seen in the video below. You can also see the auto-dimming feature towards the end of the video. It's a little hard to see when the headlights turn on because its still light out, but you can see blueShift get dimmer. You can also hear the headlight knob click on.

At the time of this writing, blueShift is hard coded to a specific RPM span. That is to say, if you wanted the first LED to light at 500 RPM and the final LED to light at 6000 RPM, you would need to reflash the firmware. After I get a few more miles on my car I will want to change that so, I will probably use that tactile switch as a way to program the RPM span without reflashing firmware.

To implement this I think it would be good to have a "programming mode" where say you enter program mode and blueShift will keep track of the highest RPM read. You press the button once to set this as the lower RPM span. Now, rev your engine and blueShift will remember the highest RPM achieved. Press the button to store this as the high RPM span. These new values will be saved to EEPROM and recalled at the next power on cycle.

Additional firmware upgrades include moving to JSON parsing. Right now I just read the full JSON line and manually parse the string for the values I want. If something were to change in the VI firmware, it is possible to break my code.

Are you making a blueShift? Send me a message, I would love to hear how it's going. Happy making!

DIY Pick and Place Machine - Part 3

2014-04-21T12:53:00.001-04:00

*Update*
Be sure to check out the other posts in this series below.
Part 1
Part 2

Now we are starting to make some headway into making this stock ShapeOko kit into something resembling a CNC Pick and Place Machine. I am quite pleased with the progress so far, and I am learning a lot along the way. For instance, I have discovered that blunt tip dispensing needles with luer lock connections are non-concentric, but more on that later. For now, let's talk about some of the parts that are making this PnP take shape; specifically the head unit and the PnP fixture.

Head Unit:

The purpose of the head unit on this PnP machine is to facilitate the following operations:

Advance the component tape to present a new component for placement.
Vacuum grip to pick up a component for placement.
Rotate the picked up component to the correct orientation for placement on the PCB.
Hold a syringe of solder paste for robotic solder paste dispensing.

When designing the head unit I wanted it to be made from primarily off the shelf parts. This speeds up development and allows a distributed approach for duplication should any reader wish to replicate the same. I was able to achieve this ideal save one part, which I turned on a lathe. The rest of the parts for the head unit came from online retailers that are listed below.

Here are a few pictures of the head unit assembled.

Below is a photo of the head unit prior to assembly. It is annotated with numbers which will correspond to a descriptive list.

Refer to the image above and the list below for part numbers &c. I see now that I left off an annotation number for the bottle of loctite. It is slightly optional, but probably a good idea for many of the fasteners as stepper motors can be a bit vibratey. All of the parts ( except #9 ) came from the following vendors: McMaster-Carr, Servo City, SDP/SI, Clippard, and eBay.

A 10-32 threaded female luer lock adapter and blunt tip dispensing needle from McMaster Carr. Respective P/N's: 51465k151 and 75165A682 and 75165A677
6-32 nuts. I had these. They measure 0.245" across the flats.
6-32 x 3/8" Long, Button Head Cap Screws. I purchased these from a local hardware store.
6-32 x 1/4" Long, Button Head Cap Screws. McMaster P/N: 98164a106
#6 Washers. McMaster P/N: 98032a436
Wood Screws to hold the maple block ( #7 ) to the head.
This is a v-cut block of wood for holding the solder paste syringe.
A flat channel bracket from Servo City P/N: 585468 and a pair of Servo City 90 deg. dual mounts P/N: 585470. All of this is held together with screws ( line item #4 ) and washers ( line item #5 ).
I turned this shaft out of some 8 mm bar stock ordered from McMaster-Carr P/N: 1272t38 A drawing to make this part is below.
A Clippard pneumatic cylinder, plus a hardware store washer. This is for drag feeding the SMD tape. Clippard P/N: FSR-05-1 1/2
Two 1/4" I.D. bearing mounts from Servo City P/N: 535110
1" x 1" 80/20 Extrusion. I cut mine slightly shorter ( < 3.75" ) than the Servo city bracket this is mounted to.
3.75" Aluminum channel from Servo City P/N: 585443
GT2 Timing belt and 2 disparate pulleys from SDP-SI P/N: A6R51M093060, A6Z51M036DF0608, and A6Z51M036DF0605
A NEMA 17 stepper from eBay, plus a stepper motor mount from Servo City P/N: 555152
An arbor shim kit for setting the end play of the diameter 8 mm shaft ( line item #9 ). McMaster P/N: 3088a928

In the assembled head unit photos you can also see a brass spool valve for diverting the CO2 flow betwixt the solder paste syringe or pneumatic cylinder. I probably should have just ordered another solenoid, but the diverter valve is Clippard P/N: HTV-3F.

Lets begin assembling the head unit by attaching the aluminum channel from Servo City ( line item #13 ) to the 80/20 extrusion ( line item #13 ). You will notice I used non-standard mounting methods here. I drilled and tapped the 80/20 extrusion for 40-40 BHCS ( Button Head Cap Screws ). This was necessary because the standard 1/4-20 BHCS plus t-slot nuts came too close to my pulleys and belt for my liking. One way around this would be to select a smaller tooth number pulleys and belt, while maintaining the same center to center distance.

Next up, attach the bottom bearing mount using some 6-32 x 3/8" BHCS's, washers and nuts as shown below.

Below, you can see the pneumatic cylinder installed. Note the hole position, and don't forget to install the GT2 belt prior to continuing, otherwise you are likely to gain the authors experience in re-assembly.

In the next photo you can see the stepper motor installed with the stepper motor mount from Servo City.

Install the diameter 5 mm I.D. GT2 pulley on the stepper motor shaft.

Prepare the aluminum plate and brackets as shown.

And install the solder paste syringe holder using wood screws. For this, I countersunk the aluminum plate so that the wood screw heads were below the surface.

Attach the solder paste syringe holder assembly to the front of the aluminum channel using 6-32 x 1/4" BHCS's as shown. It is important to do this now, as it could affect the vertical clearance on the vacuum shaft. The author was able to install qty 3, 6-32 screws during this operation before discovering the stepper motor was blocking one of the screw holes. It was decided to move on with life instead of trying to increase the number of fasteners further.

Ok, the steps shown below are the most complicated, but I think you will manage to follow along just fine. Temporarily install the vacuum shaft and top bearing mount. You may elect to install this with one screw. Slide the shaft axially to detect end float. Measure, if you can, this displacement. Mine was 0.015". Otherwise, you can attempt an iterative process of fitment.

Remove the top bearing plate, install the dia 8 mm I.D. GT2 pulley, and install one of the shims from the arbor shim kit. Since I knew my end float was 0.015", I selected a 0.012" shim. This would leave me with 0.003" clearance.

Bolt the top bearing mount in place, and check that the shaft rotates freely and there is minimal, but perceptible end float. Mine was predictably measured to be 0.003" axial clearance after assembly. If you cannot rotate the shaft, or cannot detect/measure end float, you should select a smaller shim and repeat.

Below you can see the luer lock adapter and blunt dispensing needle installed ( line item #1 ).

Here is the assembled head unit interfaced to the ShapeOko gantry via an 80/20 extrusion angle bracket.

Remember that spool valve I mentioned earlier? here it is installed to the head unit with a Servo City P/N: 545424

This is where I discovered just how bent/curved/or otherwise not straight the vacuum needle was. When I rotated the head unit with the stepper motor, the needle spun around and orbited too. So, I bent the needle a little and was able to get it pretty concentric. Then I removed the needle, and re-installed on the second start thread only to discover the needle was non-concentric again. For now, I will continue with this setup, but it may be worth investigating some precision needles at some point - probably making them.

If you recall the shaft that needs to be fabricated, below you can find a drawing. Basically the length of the diameter 8 mm shoulder is going to be determined by your particular setup. As it is drawn below worked well for me, but you may do well to have a measure of your system first.

The PnP Fixture:

You have probably seen the aluminum plate with milled slots, clocking holes, a shoulder register and a bunch of tapped holes. This is my vision for making a low volume, home pick and place machine. I can make as many different plates as I need based on the circuit board I want to fabricate.

The design is made pretty universal. There are 4 tracks for resistors or transistors, two tracks for capacitors, one for a regulator and one for a mosfet. I selected these parts and subsequently the track dimensions based on the boards I wanted to populate first. If I have a new board design in the future, and this setup does not have tracks for the correct parts, I can make a new fixture.

Here is how I envision this fixture working. I say envision, because I am still learning how to write G-Code, and I am not sure how to do what I want just yet. At the time of this writing, I am currently working on the programming I am about to describe.

If you look at the fixture you will see two countersunk holes for flat head screws. This fixture will be bolted to the ShapeOko MDF work surface here.

Inboard and towards the front, you will see two round bores of different diameters. They would have been the same size, but I messed one up while machining. Since the fixture is unlikely to ever be bolted down, perfectly aligned with the machine coordinates, I am trying to do the following. Probe each of these two holes, calculate the angle between the machine coordinate system and the line made by joining these two center points, and rotating a new set of coordinates for the machine to use that are aligned with this fixture.

There is an X-Y register for locating the circuit board. This X-Y ( 0,0 ) is located 5.000" right and 0.500" toward the rear from the bottom left probe bore. Using this new origin I know where my circuit board pads are ( from the gerber files ), and I also know where to tell the machine to look for each type of component to place.

To hold the circuit board in this register, orienting it's X-Y ( 0,0 ) I used a piece of an old coping saw blade. Held in place on one end by a Jarrah wood clamp, the other end applies enough spring pressure to keep the board steady and registered during assembly.

Things are starting to look like this might just work. I still have a long way to go with G-Code and tuning the machine operations. I haven't even fed any parts yet! Never the less, I keep chipping away at the subcomponents on this job.

Incidentally, I will probably be showing this machine off at the Ann Arbor Mini Maker Faire, so if you are in the area, be sure to stop by.

DIY Pick and Place Machine - Part 2

2014-04-15T13:24:00.000-04:00

*Update*
Be sure to check out the other posts in this series below.
Part 1
Part 3

Ok, so we are moving right along with this project. Parts are coming in weekly, and other parts seem to be endlessly delayed, so we make do. Since the last post I have been concentrating my CNC PnP education on the following areas:

Automagic Z-Axis probing for setting the machines vertical zero position relative to your PCB.
Wiring in an emergency stop. This should have been done before starting the first time.
Configuring LinuxCNC's HAL for digital outputs.
Investigations into robotic solder dispensing.

Much of this work has been around the back of the machine, so here is a picture of that, and lets discuss.

Above is the back side of the machine. Along the top is a piece of DIN Rail that extends from the left and right of the ShapeOko frame. This is where the majority of parts are installed. Below this, you see a grey vertical surface with parts mounted. This is a long steel L-Bracket, surplus from some IKEA furniture, that I screwed to the ShapeOko MDF work surface.

Working ( approximately ) from left to right, here is a list of parts:

Green parallel port breakout board. This gives screw terminal access to your PC parallel port. To this we attach stepper drivers, digital outputs, digital probe inputs etc. Phoenix Contact P/N: FLKM-D25.
DIN Rail mount Terminal Block. Multicomp P/N: SPC10564
I colored some of the above terminal blocks red or black with a sharpie. These are electrically connected with Mulitcomp P/N: SPC11891 jumpers
Big Easy Stepper Drivers - sold by SparkFun P/N: ROB-11876
The two yellow circles are 3-way pneumatic valves. Clippard.com P/N: EC-3-12 for the valve and P/N: C2-RB18 for a connectorized lead. One of these will be used for solder dispensing/component tape advancing, and the other is for the vacuum pickup system.
Connected to the above valves, via blue tubing ( clippard P/N:
URH1-0402-BLT-050 ), is a pressure regulator, clippard P/N: MMR-1N.
The valves and regulator do not come with fittings so I also ordered clippard P/N: 11752-5-PKG
Next you can see a circuit board. This custom job contains electronics for Opto-isolation, transistor amplification, and Back EMF suppression. All of which allows us to switch inductive loads like relay coils and solenoids from our PC parallel port safely.
Further to the right is a 12 V DC relay for switching the 110 V AC vacuum pump on and off. The second set of contacts will eventually drive the vacuum solenoid to either create vacuum in the pickup needle line or vent to atmosphere. I'm not sure if these are available or not, mine is scavenged from an old project Omron P/N: MK2P-S-DC12
On the very far right you can see a blue snubber that is wired across the aquarium ( vacuum ) pump. I added this to reduce EMI on the 12 V Rail. It was necessary. ITW P/N: 104M06QC100.

So, that's kind of an overview of some components, that make the subsystems. Let's talk a little more about some of the details of setting up the machine and how I intend to make this a useful robot instead of a list of cool parts. This post will discuss setting up the Z-Axis probing and robotic solder paste dispensing.

Z-Axis Probing:

In case it wasn't already obvious, this entire project has been made so easy by those who have gone before me and were willing to write up their own findings. Clearly, the best example of this is LinuxCNC, without which, nothing on my machine would be moving this early in the game. LinuxCNC is powerful and customizable. And thru adding some text to the configuration files, we can setup the probe functionality built into LinuxCNC, or perhaps more correctly G-Code.

7xCNC.com wrote up an article on how to setup Z-Axis probing. This will allow me to know how high my pickup needle and solder dispensing needles are relative to the top of my circuit boards. This is important because later on, when I write G-Code programs for the PnP I will need to reference the top face of the PCB. Of course you could set the Z-Axis manually, but why would you want to?

Have a look at the picture above, and I will try to explain what happens when we probe the Z-Axis. The aluminum block you see is 0.75" thick. The wire connected to this aluminum block via a ring terminal is connected to the PC's parallel port ground. The alligator clip, clipped to the same electrical point, is connected to the parallel port pin 13 on the other end. What I just described is a closed switch as LinuxCNC sees it. If we were to clip the alligator clip to the conductive needle instead, we would have a switch that closes when the end of the needle touches the aluminum block's top face.

If you were to call a probe command in G-Code it may look something like this:

  
G38.2 Z-2.500 F15

G38.2::G38.5 are probing codes. In the case of the above code it reads: ( G38.2 ) Probe towards work piece, Stop on contact, Signal error if failure. adding ( Z-2.500 ) means that if you get to Z-2.500 before touching the probe surface, stop; something is awry. The F15 is your feed rate.

So, F15 is fast for probing, right? Especially when you consider that 7xCNC.com's tutorial implements debouncing for the probe signal. IIRC, the debounce routine is 100 iterations of the base thread. Say our base thread runs at 1 mS, well 100 iterations would be 100 mS, and 100 mS at F15 inches per minute equates to 0.0025". In other words, if you just zoom down into the aluminum block and set Z = zero ( or 0.750" rather ), you will be 2.5 thou too low. the answer is to slow down that feed rate and consequently decrease the overshoot.

Since we don't want to wait ages for a slow feed rate if we are a long way away from our aluminum probe block, I wrote the G-Code subroutine for probing as below. If you read the comments you will see that essentially the code quickly probes down to the block, comes up a bit, then probe down slowly to get an accurate Z-Axis reference.

  
o100 sub

( Set current Z position to 0 so that we will always be moving down )
G10 L20 P0 Z0.0

( quickly probe down to touch off plate )
G38.2 Z-3.0 F15

( switch to relative coordinates )
G91

( rapid up 0.1 )
G0 Z0.05

( probe slowly to get a more accurate zero )
G38.2 Z-0.2 f0.5

( set Z0.0 to be 0.75 above work surface - this is due to the touchoff plate thickness )
G10 L20 P0 Z0.75

( switch back to absolute coordinates )
G90

( rapid to Z1.0 - probe tip is now 1" above work surface )
G0 Z1.0

o100 endsub

Below is a video of this Z-Axis probe action.

Now, after making my way thru the probe tutorial above, and modifying the G-Code subroutine for faster probing, I learned enough about how to make buttons appear on my LinuxCNC GUI, and more importantly, make those buttons do something useful. So, I set out to make some more buttons to speed up the machine setup. I made buttons for zeroing the X and Y axes as well as one to turn on my solder paste solenoid for 3 seconds to purge any dry solder paste from the needle.

To make this happen, I edited myCNCconfigName.ini such that the HAL UI MDI commands look like below:

 
[HAL]
HALUI = halui
HALFILE = 4axis_PnP.hal
HALFILE = custom.hal
POSTGUI_HALFILE = custom_postgui.hal

[HALUI]
# add halui MDI commands here (max 64) 
MDI_COMMAND = o100 call 
MDI_COMMAND = o101 call 
MDI_COMMAND = o102 call 
MDI_COMMAND = o200 call

Then I edited custom_postgui.hal to contain the following:

 
net remote-o101 halui.mdi-command-01 <= pyvcp.o101
net remote-o102 halui.mdi-command-02 <= pyvcp.o102
net remote-o200 halui.mdi-command-03 <= pyvcp.o200

And finally, I added the following to custompanel.xml

 
[HALUI]
# add halui MDI commands here (max 64)

So, when you press one of these buttons on the LinuxCNC GUI the respective subroutines below are called:

 
o101 sub

( Set current X position to 0 )
G10 L20 P0 X0.0

o101 endsub

 
o102 sub

( Set current Y position to 0 )
G10 L20 P0 Y0.0

o102 endsub

 
o200 sub

M64 P1 ( DO 1 ON )
G04 P1.0 ( dwell seconds ) 
M65 P1 ( DO 1 OFF )

o200 endsub

I will be revisiting this creation of buttons again soon. I am thinking of how to probe the X and Y axes instead of manually setting the zeros.

Robotic Solder Paste Dispensing:

To start with this robotic solder paste dispensing problem, I decided to rig up a manual pneumatic dispenser. With a switch connected to a solenoid, I was able to selectively apply CO2 to my syringe of solder paste. The solder paste naturally escapes thru the dispensing needle, and the hope is, that the correct amount makes it onto the correct solder pad.

This sounds easy enough. We have a fixed orifice, and a fixed pressure ( 40 PSI of CO2 ), so we should have a constant flow, and with a constant time, a deterministic volume dispensed. What I don't have, however, is a fixed viscosity fluid. My solder paste varies from dry to entirely too wet. The reason for this, I think is that the paste is 2 years old, and it has a shelf life of 6 months.

All this means is that my time based experiments in this area are largely useless at this point. I have ordered a new tube of solder paste. This has proven to be a good learning experience.

Eventually the human operated switch was replaced by an opto-isolated, transistor amplified, and back EMF protected circuit, that means that I can now write G-Code to turn on and off this solenoid for a specific time period with the code:

 
M64 P1   ( turn D0 ON solder solenoid )
G04 P1.5  ( dwell seconds ) 
M65 P1   ( turn D0 OFF - solder solenoid )

Strap the digitally controlled solder paste syringe to the pick and place gantry, and you can do this:

Below is a picture of solder paste dispensing onto a piece of paper. The 5 dots on the left were dispensed with a 1.5 second period, and for the 5 dots on the right the CO2 solenoid was open for 2 seconds.

Here is a video of the dispensing in action. You can notice that the first pad does not get enough solder dispensed onto it. Given the viscosity disparity of this expired solder paste tube, and my elected method of application, i'd say these results are pretty good.

While the solder was being placed on the circuit boards, I was hand populating the components. The resulting boards are just as good as they ever have been using a solder paste screen. And certainly, one of the coolest features of robotic solder paste application is that I can make new boards while never having to purchase a ~$200 solder paste screen again.

Ok, well I can't think of anything else to talk about on this topic. It's all pretty prototypical at this point, but I'd say its moving in the right direction. And if you've made it this far into the reading, thank you; you're doing better than me.

DIY Pick and Place Machine - Part 1

2014-03-16T23:00:00.002-04:00

*Update*
Be sure to check out the other posts in this series below.
Part 2
Part 3

Well, it sure has been a while since i've posted anything, but that does not mean i've been idling my time away. One of my projects since my last post has been starting AirPatchCable.com. AIR Patch Cable was setup because I was disappointed with the selection of Aviation Intercom Recording cables on the market. Everything was either way over priced, of such poor quality, or both, that I didn't want to plug them into my camera, let alone a planes intercom.

For AIR Patch Cables I designed a cable with capacitive coupling and passive attenuator pad to make interfacing to the airplanes intercom simple and sound great. To fit everything into the phono jack backshell meant that I had to put the attenuator and capacitive coupling passives onto a circuit board. Below is a picture of these circuit boards. P.S. If you or someone you know is a pilot, you should check out AirPatchCable.com.

So, how are all of these SMD circuit boards going to get populated? Well, to start out, by hand. That is no easy task, however, and so I decided to build a robot to make these boards for me while I attend to other things.

In actuality, this machine probably needs supervision, but there are other benefits to robotic assembly even if I have to sit there and supervise the robot. A robot, or perhaps more accurately named a "Pick and Place Machine" in this case, is unlikely to place a 100 ohm resistor where the 1000 ohm resistor is supposed to go, or put that diode in backwards, thus rendering the entire circuit useless. Perhaps the biggest benefit is that my eyes and neck will remain in relative comfort.

OK, so this is where we are so far. I titled this post "... Part 1" because my machine does not pick nor place just yet. But what I have achieved is a milestone. I have programmatic computer control over a 3 axis machine. This would be considered a starting point for many projects. From here you could make a laser cutter, a CNC mill, a 3D printer, or in my case a pick and place machine.

Lets cut to the chase and put up the video and we can talk about it a little more later.

Below you can see a shot of the overall setup. I'll break it down a little later. For now, just enjoy the pics.

In the top pic you can see the mechanical setup and the computer that controls the stepper motors. The next pic down you can see the stepper motor drivers. Finally, in the third pic is a photo of the software, LinuxCNC which are the brains of the operation.

An over simplified explanation of operations is that LinuxCNC reads a G-Code program that you wrote. LinuxCNC then controls the host computers parallel port where the stepper motor drivers are connected. The stepper motor drivers are electrically connected to the stepper motors which are in turn mechanically coupled to the XYZ or 3 axes of the machine.

Mechanical:

When I first considered making a PnP ( Pick and Place ) machine, I started looking at linear bearings from the usual suspects. Thompson and Igus, namely. I quickly found out what I already suspected. Linear bearings are expensive. During my search however, I came across a 3 axis mill kit for about $300.

I could not pass this up. It would suit all of my design criteria for this project and cost less than if I designed my own. The kit is called a Shapeoko 2, and it is sold by a company called Inventables. Here is a link the kit. If you are planning to build the same robot I did, keep in mind I only ordered the mechanical kit as the electronics didn't really suit my needs.

The kit was pretty easy to assemble. I don't really know how long it took because I did it over the course of a while. I would strongly consider building future rigs with the "maker slide" linear bearings that Shapeoko 2 uses. Aluminum extrusions are plenty stiff for this project and I suspect many others.

The mechanical kit from Inventables does not come with all the mechanical components. I ordered MXL belting and pulleys from ebay to complete the mechanical side of things.

Electrical:

I decided to use the Big Easy Driver for driving my stepper motors. This is a stepper motor driver designed by Brian Schmalz and sold by Sparkfun Electronics. Brian was very helpful when I emailed him about some compatibility questions I had.

There is a potentiometer onboard each Big Easy Driver to set the motor current. Too low and the motor is uncontrollable. Too high and the driver gets too hot. This fact must me accomidated for when you are setting up your motors, one by one.

I ordered 5 of the Big Easy Drivers to go with the quantity five, NEMA 17 motors I ordered from ebay. I am told that NEMA 17 is about the biggest motor the Big Easy Driver should be used for.

I was really impressed with the torque these NEMA 17 motors have when paired with the Big Easy Driver. I couldn't pinch the 5 mm output shaft with my fingers to stop the motor from turning. I offer that anecdotal statement in lieu of data sheets or a torque measurement.

Software:

I am using LinuxCNC for stepper control. I was really impressed with how easy everything was to set up. I'll go ahead and post a couple of setup photos with parameters I have found to work with the Big Easy Driver.

Oh, LinuxCNC runs on Ubuntu 8.04 or 10.04, so be prepared to downgrade. Having said that, 10.04 is a dream to work on. You can even download Ubuntu 10.04 with LinuxCNC pre-compiled. That's what I did.

Below are some screen short of my configuration thru StepperConf in LinuxCNC.

I wrote a CNC program to control the PnP machine. I stuck a pen on its Z axis, and below are photos of the result. Pretty good so far I'd say. The first word I wrote was Gangsta., because, you know, G-Code. After that, I had my PnP machine pen the Japanese phrase "Domo arigato", leaving off the presumed "Mr. Roboto".

Next Steps:

OK, so we have computer control of a 3 axis machine now, but what is left to make this a pick and place machine? Well, quite a bit actually. I need to tidy up the wiring, and properly mount things like the stepper drivers. We need a method to feed the SMD tape. A vacuum needle for picking up the parts. An "A" axis for rotating the picked up part about the Z axis. Oh, and I'm planning to make this a robotic solder past dispenser too. Machine vision is a lofty goal that I may revisit a a tertiary upgrade.

If you have any questions or comments, feel free to leave a comment below or send me an email from the "About Me" section in the right pane.

LaTeX Airplane Checklist

2013-09-28T05:39:00.000-04:00

The use of checklists is one of the tenets of aviation. We have them for pre-flight inspections all the way thru shut down procedures and even emergency procedures. Aviation checklists are so pervasive that they have even sprung up a cottage industry around their sale. You can purchase colorful, durably laminated checklists for around $15, and you can buy iPhone/iPad or Android checklists too. Although I am iEquipt and Android enabled, at this point I am preferring the paper checklists.

At any rate, if you are a student pilot like myself, you may have been given a few checklists from your CFI or FBO. And if your FBO is anything like mine, your checklist probably contains some vestigial entries from equipment long gone. For example, the checklist I was given for my plane had checks for an autopilot system which does not exist. It also had IFR procedures, but my plane is not currently IFR legal and I doubt it is a priority to make it such. I found these superfluous entries distracting and they disrupted the flow of my procedures.

Well, for better or worse I am a DIY type of guy, and so I reject the pre-made checklists - both old and new and decided to roll my own using LaTeX. LaTeX ( pronounced latek ) is a typesetting system primarily used in technical and scientific writing. I am pretty new to using LaTeX, but the more I use it the more I like it. My pedagogical interest in LaTeX quickly turned utilitarian and it is rapidly filtering thru my life, both professionally and in academia. The end result of all this is a really classy looking document with none of the formatting hassle associated with WYSIWYG editors such as MS Word or OpenOffice Text Document.

Here is a LaTeX code snippet from my checklist. I basically just copied the checklist from my FBO, making changes where appropriate. For example, I tried to maintain consistency in language throughout the list. My brain is happier when I am not identifying inconsistencies in my checklists. Having said that, if you see any typos please let me know. I am also going to ask my CFI to double check the final checklist before we fly next.

  

\subsection{Before Takeoff - Run-Up}

 \begin{enumerate}
 
  \item Cabin Doors and Windows - \textbf{Closed \& Locked}
  \item Parking Brake - \textbf{Set}
  \item Flight Controls - \textbf{Free \& Correct}
  \item Flight Instruments - \textbf{Set}
  \item Fuel Selector Valve - \textbf{ON - Fullest Tank}
  \item Elevator Trim - \textbf{Takeoff}
  \item Mixture - \textbf{Rich or As Required}
  \item Throttle - \textbf{2000 RPM}
   \begin{enumerate}
    \item Magnetos - \textbf{Check}
    \item Carburetor Heat - \textbf{Check}
    \item Engine Instruments \& Ammeter - \textbf{Check}
    \item Suction Gauge - \textbf{Check 5"$ \pm $0.1}
   \end{enumerate}
  \item Throttle - \textbf{Idle, then 1000 RPM}
  \item Radios - \textbf{Set}
  \item Transponder - \textbf{Set, then Altitude}
  \item Throttle Friction Lock - \textbf{Adjust}
  \item Fuel Pump - \textbf{ON}
  \item Lights - \textbf{As Required}
  \item Parking Brake - \textbf{Release}
 
 \end{enumerate}

And the result of this code output looks like this screen cap from the PDF.

Here is a picture overview of the checklist. You can download a PDF checklist and the LaTeX code to make your own down further.

One of the main advantages to having this template setup is that I can quickly make adjustments to the checklist contents. If I need to add or clarify anything it is quick and easy and the formatting stays the same.

If you would like a copy of the LaTeX code you can download it here. You are welcome to download the output from the code aka my checklist, but I imagine you would want to customize your own checklist. Either way, here is the PDF checklist I made for the plane I usually fly.

Robotic Instagram Timelapse Video

2013-06-23T13:23:00.002-04:00

As you are probably already aware, Instagram has enabled video uploading. You are limited to 3-15 second clips and can't upload previously recorded videos. The record button in the Instagram app is non-latching, so you have to hold the button down all the while you want to record. At the end, all of your little clips ( up to 15 seconds ) are stitched together into a video ( with sound please remember ) that you can then add a distinctly Instagram-esque filter to and upload.

Working within these boundaries I have devised a method to make timelapse videos using a servo actuated, simulated finger to press the record button in the Instagram app at somewhat deterministic yet not entirely accurate intervals. Let it be said that the future may hold software solutions for timelapse in instagram, but for now, I am making timelapse videos in Instagram before they are cool?

This project had a couple of interesting things. For one, this was my second time using the Arduino platform for prototyping. I had purchased an Uno R3, LCD shield and prototype shield for an upcoming project, but decided to borrow the hardware for the Instagram robot instead. Although I am not a big fan of the abstraction that Arduino provides I was able to quickly prototype with the equipment I listed above. From concept to build to first timelapse video took all of about 4 hours.

In the above photo you can see values on the screen for sv_in which is the servo angle when the simulated finger is pressing the record button. The variable for interval is milliseconds until the next record button press. You can also see a 'P' for pause, in the lower right corner which is toggled 'R' for run when a button is pressed. The servo " in " position and interval time are adjustable by buttons on the front panel. I guess now would be an appropriate time to mention that the record button press duration is 150 mS.

At any rate, the other interesting part of this project was the simulated finger for pressing the record button. I used some conductive foam, shipped with IC's jammed into the end of an Exacto knife holder. The blade, of course was removed. The handle of the exacto knife was then electrically tied to the negative supply of the Arduino. This activated the screen quite well, however my first hardware design had the simulated finger " swipe " to come into contact with the screen aka tangentially. The Instagram app did not respond to tangential activation and I had to redesign the servo configuration to allow more perpendicular action.

~~I will post a video of the results as soon as Youtube snaps out of the mood its currently in.~~

Learning to fly and Perl for METAR Decoding

2013-02-16T11:20:00.002-05:00

One of the ways I have been occupying myself is with flight training for a private pilot license or more correctly called a private pilot certificate. It's been off and on lately because I have had to take some time off to focus on other projects, but next month I will be resuming at as fast of a pace as my pocketbook will allow. Since I needed some pilot/flying related activities to keep my interest during this down time I decided to write a Perl parsing script for aviation weather reports called METAR's. But, first how did I find myself in the left seat of an airplane for the first time? Well, read on.

About a year ago as a birthday present I was given a "discovery flight" by my parents. A discovery flight is where a certified flight instructor sticks you in the pilot seat, guides you to take off and fly a plane around for about an hour before landing at the airport where you took off from. This is akin to the "visitation" rooms at the humane society where they let you play with the puppies and cats, all the while knowing that the puppy ( or aircraft, rather ) that you have been playing with is soon to become your highest priority.

That's how it happened with me anyway. On my discovery flight I pushed the throttle forward. We soon accelerated to 50 knots and when I pulled the yoke toward my chest, the Cessna 152 parted the runway and I became speechless; my breath had been taken thru amazement of the reality of flight. It is one thing to understand the physics of flight and totally different to experience it. General aviation or small aircraft flight isn't anything like the experience of large commercial airplanes.

In fact, I was so taken by this flying that I decided to continue flight lessons, working towards a private pilot certificate. As I mentioned above I have experienced quite a few training delays along the way including taking time off to start Lakeside Electronics, LLC, so in the interim I wanted to come up with some activities related to flying.

Early on in my flight training I recognized the impact and importance of weather on general aviation or I should say, aviation in general. There are even aviation specific weather reports such as METARs that pilots access for preflight weather planning. You can look up a report for an airport near you using their ICAO station identifier code here http://aviationweather.gov/adds/metars/.

Here is an example METAR string from the airport I fly out of in Ann Arbor, Michigan: KARB 021653Z 34015G23KT 10SM OVC033 04/M03 A2996 RMK AO2 SLP150 T00441033.

As you read the above report you can probably make out what some of the sub-strings mean. For example, before researching I postulated that " OVC033 " meant overcast, but I did not fathom that the second half was referring to cloud height in 100's of feet. Could " SLP150 " be something to do with slip? Nope, Sea Level Pressure - in tens, units and tenths to be added to 1000 hPa no less. In other words, 15.0 hPa + 1000 hPa = 1015.0 hPa. However, if the string were a high number like SLP965 you would add that value ( 96.5hPa ) to 900 hPa instead for a reading of 996.5 hPa. Yes, its a strange little protocol...

Almost certainly I needed to study up on how to interpret this METAR report. Fortuitously, it would seem, I had concurrently begun learning the programming language Perl. A perfect storm, it would seem, to write a Perl based parsing script for METAR weather reports and display these data in a more human readable format was afoot.

The goal of course is two fold. A) To learn Perl and B) to memorize a method of METAR interpretation for when I need to read the raw string. Quite obviously there are numerable ways to accomplish these tasks. There also exists METAR decoders and even a Perl Module for this task, but this would violate my goals as set forth and thus decided to write my own Perl METAR parsing script.

When I turned to Google for information about the METAR protocol I found this page http://www.met.tamu.edu/class/metar/quick-metar.html helpful indeed. If you recall, we discussed the sub-string for sea level pressure above. There are too, other little gotchas along the way when trying to programmatically decode METAR reports. For instance, some data are always reported, some data are optionally reported and within the raw string as a whole, the sometimes reported data is intermingled with the always reported data. I also have reason to believe that the information contained in the remarks ( RMK ) section can partially exist as plain English, and so that is where my parsing stops - before we get to the optional remarks. I may look into further coding of the remarks, but for now I am satisfied with the script.

This Perl script uses Curl to fetch a METAR string from weather.noaa.gov. Then it parses the string, does some formatting and a couple of calculations for Celsius to Fahrenheit conversion then writes the data to a text file. Using a program on my macbook called GeekTools I am able to display the contents of the Perl generated text file on my desktop. It looks like this on my desktop.

Before continuing, I must say that you shouldn't use this script for flight planning and also, that it is largely untested. Please report any bugs that you may find. Part of my ongoing memorization of METAR syntax is to read the string and my scripts output and look for errors.

If you want to play along, install Geektools from the link in the previous paragraph. You will also want to copy the Perl script from below. Save the Perl script in a folder somewhere on your computer. I named my folder "metar" and located in ~/Documents/Weather/. Start up GeekTools and configure like so...

The command in the above screen cap is "cat ~/Documents/Weather/metar/metar_datafile.txt" without quotes. Change this as required for your particular path and file name.

Below is the code. It is definitely a work in progress. Every time I spot an error I correct it but I haven't seen any errors in a while now. Let me know if you do.

  
#!/usr/bin/perl -w

# this program gathers METAR data from NOAA, decodes it and does some formatting before writing the data to a text file
# this file is monitored and displayed on my macbook desktop using GeekTools
#
# Under no circumstances should you use this for flight planning.  Also, no guarantee is made that this software even works at all.
#
# Below is an example of the metar_datafile.txt after the curl command.  There are 2 lines as you can see.
#
# 2012/10/27 11:53
# KARB 300153Z AUTO 35018G34KT 10SM OVC095 06/M05 A2978 RMK AO2 PK WND 35034/0144 SLP090 T00561050
#
#

#while( 1 ){
my $ICAO_STATION = "KARB"; # airport nearby

my $raw_metar_data = `curl --silent http://weather.noaa.gov/pub/data/observations/metar/stations/$ICAO_STATION.TXT`;

chomp $raw_metar_data;

my  ( $date_time, $current_metar_line ) = split /\n/,$raw_metar_data;

chomp $date_time;
chomp $current_metar_line;

# put the METAR string into an array 
my @metar_array = split / /, $current_metar_line;
my $array_index = 0;

open (MYFILE, '>metar_datafile.txt'); #open for write >> would be for apend

#
# print the full array we are about to decode separated by spaces
print MYFILE "@metar_array\n";

#
# print the station ID as read
print MYFILE "ICAO Station ID: $metar_array[ $array_index ]\n";
++$array_index;

#
# print the day of the metar transmission
my $day = substr( $metar_array[ $array_index ], 0, 2 );
print MYFILE "Day: $day";

# print ^st, ^nd, ^rd or ^th at the end of the date just for a bit of fun
#my $right_digit = substr( $day, 1, 1 );

#$day = "3";



if( ( scalar $day == 1 ) || ( scalar $day == 21 ) || ( scalar $day == 31 ) ){
 print MYFILE "st\n";
}
elsif( ( scalar $day == 2 ) || ( scalar $day == 22 ) ){
 print MYFILE "nd\n";
}
elsif( ( scalar $day == 3 ) || ( scalar $day == 23 ) ){
 print MYFILE "rd\n";
}else{
 print MYFILE "th\n";
}


#
# print the time of the metar transmission in zulu time aka 0 GMT
my $zulu_hours = substr( $metar_array[ $array_index ], 2, 2 );
my $zulu_minutes = substr( $metar_array[ $array_index ], 4, 2 );
print MYFILE "Report Time ( Zulu ): $zulu_hours:$zulu_minutes\n";

++$array_index;


#
# decode and print report type ( auto or corrected or none )
#
# test String
# $metar_array[ $array_index ] = "COR";


if( $metar_array[ $array_index ] eq "AUTO" ){
 print MYFILE "Report Autonomy: Automatic - No human intervention.\n";
 ++$array_index;
 }
elsif( $metar_array[ $array_index ] eq "COR" ){
 print MYFILE "Report Autonomy: Corected observations.\n";
 ++$array_index;
 } 
else{
 print MYFILE "Report Autonomy: Human observer or Automatic with human oversight.\n";
}


#
# decode and print wind data

print MYFILE "Wind Condition: ";

# the first three characters are either VBR or they contain wind direction
my $wind_direction = substr( $metar_array[ $array_index ], 0, 3 );

# the next two characters always contain wind speed
my $wind_speed = substr( $metar_array[ $array_index ], 3, 2 );

if( $wind_direction eq "VBR" ){
 print MYFILE "Direction variable at $wind_speed knots.\n";
 ++$array_index;
}
# else if the string contains a 'V' for variable wind over 6 knots...
elsif( $metar_array[ $array_index ] =~ /V/ ){
 print MYFILE "Wind from $wind_direction degrees at $wind_speed knots - ";
 my $dir1 = substr( $metar_array[ $array_index ], 9, 3 );
 my $dir2 = substr( $metar_array[ $array_index ], 13, 3 );
 print MYFILE "Variable between $dir1 and $dir2 degrees.\n";
 ++$array_index;
} 
# else if the string contains a 'G' for gust
elsif( $metar_array[ $array_index ] =~ /G/ ){
 print MYFILE "Wind from $wind_direction degrees at $wind_speed knots - ";
 my $gust_speed = substr( $metar_array[ $array_index ], 6, 2 );
 print MYFILE "Gusts to $gust_speed knots.\n";
 ++$array_index; 
}
else{
 print MYFILE "Wind from $wind_direction degrees at $wind_speed knots.\n";
 ++$array_index;
}


#
# decode and print visibility

print MYFILE "Visibility: ";

# remove "SM" from the end of the string leaving the visibility in statute miles
my $visibility = $metar_array[ $array_index ];
chop $visibility;
chop $visibility;

# if the string still contains an 'M' after the chops there is a special case
if( $visibility =~ /M/ ){
 print MYFILE "Less than 1/4 statute miles.\n";
} 
elsif( $visibility eq 9999 ){
 print MYFILE "Greater than maximum recorded value.\n";
}
else{
 print MYFILE "$visibility statute miles.\n";
}
++$array_index;



#
# decode and print runway visual range if reported
# this string should contain a forward slash if it contains runway visual data
#
# test string
# $metar_array[ $array_index ] = "R16/P20000VM211FT";

if( $metar_array[ $array_index ] =~ /\// ){
 
 print MYFILE "Runway Visual Range: ";
 
 my( $runway, $range ) = split /\//, $metar_array[ $array_index ];
 
 # remove the 'R' from the runway number
 $runway =~ s/.//;
 
 # remove "FT" from the range(s)
 chop $range;
 chop $range;
 
 # there is a 'V' in $range_a if the visual range is variable
 if( $range =~ /V/ ){
  my( $range_a, $range_b ) = split /V/, $range;
  print MYFILE "Runway $runway has a visual range between ";
  
  # check for the M or P modifier
  if( $range_a =~ /M/ ){
   #remove the 'M'
   $range_a =~ s/.//;
   print MYFILE "less than $range_a and ";
  }
  elsif( $range_a =~ /P/ ){
   # remove the 'P'
   $range_a =~ s/.//;
   print MYFILE "greater than $range_a and ";
  }
  else{
   print MYFILE "$range_a and ";
  }
  
  if( $range_b =~ /M/ ){
   #remove the 'M'
   $range_b =~ s/.//;
   print MYFILE "less than $range_b feet.\n";
  }
  elsif( $range_b =~ /P/ ){
   # remove the 'P'
   $range_b =~ s/.//;
   print MYFILE "greater than $range_b feet.\n";
  }
  else{
   print MYFILE "$range_b feet.\n";
  }
  
  
  
 }
 else{
  print MYFILE "Runway $runway has a visual range of ";
  
  # check for the M or P modifier
  if( $range =~ /M/ ){
   #remove the 'M'
   $range =~ s/.//;
   print MYFILE "less than $range feet.\n";
  }
  elsif( $range =~ /P/ ){
   # remove the 'P'
   $range =~ s/.//;
   print MYFILE "greater than $range feet.\n";
  }
  else{
   print MYFILE "$range feet.\n";
  }
    
 }
 ++$array_index;
}



#
# decode and print weather phenomena if it exists
#
# test string
#$metar_array[ $array_index ] = "+RAPRTS-DRPL";

my $weather_phenom = $metar_array[ $array_index ];

# if the current string does not contain cloud cover data then it is weather phenomena

if( $weather_phenom !~ "SCK" & $weather_phenom !~ "CLR" & $weather_phenom !~ "FEW" & $weather_phenom !~ "SCT" &
 $weather_phenom !~ "BKN" & $weather_phenom !~ "OVC" & $weather_phenom !~ "VV" )
 {
  print MYFILE "Weather Phenomena: ";
  
  my $string_index = 0;
  my $string_length = length $weather_phenom;
  
  while( $string_index < $string_length ){
  
   my $sub_string = substr( $weather_phenom, $string_index, 2 ); 
   
   if( $sub_string =~ /\+/ ){    
    print MYFILE "Heavy ";
    ++$string_index;
   }
   elsif( $sub_string =~ /\-/ ){
    print MYFILE "Light ";
    ++$string_index;
   }
   #else{
   # print MYFILE "Moderate ";
   #}
   
   $sub_string = substr( $weather_phenom, $string_index, 2 );
   
   # hash lookup
   
   %weather_type = ( "VC" => "Vicinity ",
        "MI" => "Shallow ",
        "PR" => "Partial ",
        "BC" => "Patches ",
        "DR" => "Low Drifting ",
        "BL" => "Blowing ",
        "SH" => "Showers ",
        "TS" => "Thunderstorm ",
        "FZ" => "Freezing ",
        "DZ" => "Drizzle ",
        "RA" => "Rain ",
        "SN" => "Snow ",
        "SG" => "Snow grains ",
        "IC" => "Ice crystals ",
        "PL" => "Ice Pellets ",
        "GR" => "Hail ",
        "GS" => "Small hail ",
        "UP" => "Unknown ",
        "BR" => "Mist ",
        "FG" => "Fog ",
        "FU" => "Smoke ",
        "VA" => "Volcanic ash",
        "DU" => "Widespread dust ",
        "SA" => "Sand ",
        "HZ"  => "Haze ",
        "PY" => "Spray ",
        "PO" => "Well developed dust/sand swirls ",
        "SQ" => "Squalls ",
        "FC" => "Funnel clouds including tornadoes or waterspouts ",
        "SS" => "Sandstorm ",
        "DS"  =>  "Duststorm ",
        );
        
   print MYFILE "$weather_type{ $sub_string }";
   
   # see if there is another weather code
   $string_index += 2;
  }
  
  print MYFILE "\n";
  ++$array_index;
}


#
# decode and print the cloud cover data ( always present )
#
# test string
#$metar_array[ $array_index ] = "BKN120";

print MYFILE "Cloud cover: ";

# if there are multiple cloud conditions which can occur...
while( $metar_array[ $array_index ] =~ /(SCK|CLR|FEW|SCT|BKN|OVC|VV)/ ){
my $sky = 0;
my $cloud_height = 0;
 

if( $metar_array[ $array_index ] =~ /VV/ ){

 $sky = substr( $metar_array[ $array_index ], 0, 2 );
 $cloud_height = substr( $metar_array[ $array_index ], 2, 3 );
}
else{

 $sky = substr( $metar_array[ $array_index ], 0, 3 );
 $cloud_height = substr( $metar_array[ $array_index ], 3, 3 );
}


%sky_condition = ( "SCK" => "Sky Clear ",
     "CLR" => "Clear sky",
     "FEW" => "Few clouds ",
     "SCT" => "Scattered clouds ",
     "BKN" => "Broken clouds ",
     "OVC" => "Overcast clouds ",
     "VV" => "Vertical visibility ",
     );
     
print MYFILE "$sky_condition{ $sky }";

# if $sky has clouds in it then report the cloud height.
# if skies are clear, do not report cloud height

if( $sky =~ /(FEW|SCT|BKN|OVC|VV)/ ){
# cloud height is given in hundreds of feet
$cloud_height *= 100;

print MYFILE " at $cloud_height feet. ";
}
++$array_index;
}   

#
# decode and print the temperature and dewpoint ( always present )

my( $temperature_c, $dewpoint_c ) = split /\//, $metar_array[ $array_index ];

# if it is a negative number
if( $temperature_c =~ /M/ ){
 # remove the 'M' from the temperature
 $temperature_c =~ s/.//;
 $temperature_c *= -1; # and make it a negative number
}

if( $dewpoint_c =~ /M/ ){
 # remove the 'M' from the dewpoint
 $dewpoint_c =~ s/.//;
 $dewpoint_c *= -1; # and make it a negative number
}

my $temperature_f = $temperature_c * 1.8 + 32;
my $dewpoint_f = $dewpoint_c * 1.8 + 32;

print MYFILE "\nTemperature: $temperature_c degrees C / Dewpoint: $dewpoint_c degrees C.\n";
print MYFILE "Temperature: $temperature_f degrees F / Dewpoint: $dewpoint_f degrees F.\n";

++$array_index;


#
# decode and print atmospheric pressure ( always present )
#
# test_string
#$metar_array[ $array_index ] = "Q1234"; 
#$metar_array[ $array_index ] = "A1234"; 

my $atm = $metar_array[ $array_index ];

# if our pressure is reported in mb aka hPa
if(  $atm =~ /Q/ ){

 # remove the 'Q' from the pressure
 $atm =~ s/.//;
 print MYFILE "Atmospheric Pressure: $atm hPa\n";

}

# if our pressure is reported in mb aka hPa
elsif(  $atm =~ /A/ ){

 # remove the 'A' from the pressure
 $atm =~ s/.//;
 
 my $whole_inhg = substr( $atm, 0, 2 );
 my $frac_inhg = substr( $atm, 2, 2 );
 
 print MYFILE "Atmospheric Pressure: $whole_inhg.$frac_inhg inHg\n";

}

++$array_index;



#
# decode and print


close (MYFILE); 

#sleep( 60 );
#}

Ok, onward and upward. Clear for takeoff.

Thor - A Programmable Brake Light Modulator

2012-09-04T09:19:00.000-04:00

I have been rather busy developing products for my new company Lakeside Electronics, LLC and as such, haven't had much time to post anything in the way of projects over here. This is OK however, because despite the massive amount of work involved in bringing a product like Thor to market, it turns out to be pretty fun too.

Of course, I still have a few irons in the hobby fire, and with Halloween coming up there are bound to be some scary, or at a minimum, vaguely direful ideas cropping up in my yet-to-be-zombified mind. But, first, I have some microcontrollers to program for a Boy Scout Troop. I was recently contacted by (them) and I am quite pleased to help them out making Halloween Spooky Eyes. Anytime someone is interested in learning new things I think it is fantastic.

Ok, so back to Thor - A Programmable Brake Light Modulator and Lakeside Electronics. If you have been reading my recent posts you are probably already aware of what a brake light modulator is. If you have any feedback, I'd like to hear it.

And finally here is the video for Thor.

More Flashing Brake Lights

2012-08-01T21:20:00.000-04:00

It seems like summer is the season for brake light flashers and Greg, a reader of Pete's Blog just emailed me to show me what he has been up to. After reading my original post Tenty LED Brake Lights which is a brake light modulator and LED light engine integrated onto perf board, Greg set out to make a version for his Yamaha V-Star 1100.

I'm impressed with Greg's craftsmanship which you can see in the photos below, but what you can't see is that he used an Arduino to program the ATTiny85 with the original code which can be found here. This is cool because if you have an Arduino laying around, but no programmer, you can still make a modulating LED brake light for yourself. Greg said the following links were useful to him in using his Arduino as a programmer http://hlt.media.mit.edu/?p=1229 and http://hlt.media.mit.edu/?p=1695 but ended up not changing the default 1 Mhz clock on the ATTiny85 and instead changed the delay between flashes in the code from 25 mS to 75 milliseconds.

Have a look at video and pics below to see for yourself how cool Greg's flashing LED brake light turned out. I really like the pattern the LED's make on the tail light lens. If you have any pictures or video of a project you have made with the help of Pete's blog, send me an email, I'd like to see!

Betelgeuse Brake Light flasher by Lakeside Electronics, LLC

2012-07-25T08:43:00.002-04:00

It's been a couple months since I have posted anything and that's because I've been hard at work developing a product and starting a company called Lakeside Electronics, LLC. The first product available thru Lakeside Electronics is a brake light flasher to add conspicuity to motorcycles primarily, but also cars, trucks, trailers or even custom vehicles. Actually, Betelgeuse - A Programmable LED Brake Lamp is an LED brake light using 4 Cree X-Lamp LED's with an integrated flash pattern controller.

Check out the video below to see some of the different flash or strobe patterns Betelgeuse ( pronounced BeetleJuice or Betel Juice ) can display. Betelgeuse can even modulate the LED light in a way to look like old school filament bulbs. If you are interested in purchasing Betelgeuse you can head over to the product page at LakesideElectronics.net and hit "add to cart".

Betelgeuse is really cool because it requires no wiring modifications, you just twist the bulb in and you are done. It is fully configurable by using only your brake lever for changing and storing the flash pattern. It also has a recording feature where you can record your own flash or strobe pattern by recording your brakes. The recording time is fixed at 10 seconds which is plenty of time to tap a brake light message in Morse Code. Of course, Betelgeuse can also act as a traditional LED brake light with no flashing too.

If you are interested in the full details you can download the Betelgeuse owners manual from the downloads page to see how capable this modulating brake light really is.

Currently Betelgeuse comes in type 1157 dual filament type bases. Of course, dual filament bulbs fit is several bases in addition to the 1157. There are a couple versions of Betelgeuse brake light strobes in the works, so if you are interested keep checking back to see what's new. I'm really excited about Betelgeuse - A Programmable LED Brake Lamp and I hope you are too.

LED Stroboscope from a Clapper Lamp Prototype

2012-05-27T13:19:00.004-04:00

A little while ago a writer for Popular Science magazine approached me asking if I would be interested in collaborating with them write a " How To " article based on my Clever Clapper post the other month. Well, of course I would, that sounds awesome! And so, I made another Clapper lamp, this time leaving out the laser activated moon lamp so as to better fit the magazine space.

Clapper Demo

Party Mode Demo

Fast forward a few months and you can find in the June 2012 issue, the " Diy Clapper " article on page 80. You can see an online version of the article and links to software etc on the Popular Science page here.

All in all, it was a pretty cool experience, but I am left with another clapper lamp now. And worse, dueling clapper lamps that have no mechanism by which to synchronize themselves. Two claps may or may not turn on both the new clapper lamp and original Clever Clapper leaving me with flip flopping lights until I have to resort to manual control of one or the other lamp.

The non-necessity of having multiple clap activated lamps in my house prompted me to make an LED Stroboscope with the latest lamp - utilizing as much of the hardware as possible. I only added a potentiometer to set the strobe frequency.

I would not design a stroboscope with this hardware from scratch, but it is a good reuse of the lamp and circuit that would otherwise sit idle. For instance, a fairly big drawback is the 8-bit timer in the ATTiny85. The frequency step changes are quite noticeable and I would prefer a 16-bit timer like the ATMega328 has.

And of course with those extra uC pins I could add a display to show the frequency rather than relying on an oscilloscope for measuring the output frequency. Having said that however, with a lack of crystal on the ATTiny85, using the internal RC oscillator instead, it is probably better to measure the frequency externally rather than an internally calculated frequency display.

You can see the hardware changes from the Clapper lamp outlined in the schematic below. I disconnected a few connections and added a potentiometer, that's about it.

The software for the stroboscope can be downloaded here. It isn't the prettiest of code as, but it should suffice until I can build another stroboscope with a more concentrated effort.

To operate the stroboscope you just turn it on and the lamp is strobing somewhere between ~4 Hz and ~31.3 kHz. The maximum flash rate is high enough so as not to be noticed. So you can use it as a reading lamp. Pressing the tactile switch shuffles thru a loop, changing the timer presets thus decreasing the flash rate by 2 times, each press until it loops back to the beginning. Find your range with the tact switch then turn the potentiometer to set the exact frequency required to stop motion.

In the video below, there are on screen comments noting the points where the strobe frequency is a multiple of the fan speed. It is advantageous to use a mark on symmetrical parts to determine when the strobe frequency is a multiple of the part frequency or spot on. I marked this fan blade with a sharpie so I know that if the rotational motion appears stopped and I see two arrows ( sharpie marks ) then the strobe frequency is 2x the fan speed. It should follow that one sharpie mark showing means the strobe is 1x the fan speed. This is the basic principle of stroboscopes, but for a more in depth look have a look at this wikipedia entry.

I am pretty pleased with the results and knowing the limitations of this stroboscope I can still see it being useful to me. Of course I look forward to making a more full featured model with improved timer hardware etc, but for now I can inspect all kinds of rotating or oscillating mechanical bits in pseudo slow motion. I can also measure the speed of unknown objects easily as well as prototype some zoetropes or similar.

As an aside, have a look at this scope my Mother bought me out of the blue the other day - just in time to use it for this project too! How cool is that?

Tenty LED Brake Lights

2012-04-15T21:39:00.000-04:00

UPDATE:
This project was so overwhelmingly well received that it has spawned a commercial interest. The version available for purchase varies somewhat in it's flash patterns and also in the ability to record and play back your own flash patterns. If you would like to check it out take a look at Betelgeuse - A Programmable LED Brake Lamp at my new company Lakeside Electronics, LLC.

I Purchased a motorcycle about two weeks ago. Interestingly, whenever I tell someone this news, they immediately proceed to tell me the most gruesome injuries and stomach turning plights that they or someone they know, has fallen victim to while motorcycling. In some cases, these raconteur's briefly pause to look over their shoulder, presumably scanning for small children or otherwise offendable ears, before delivering the goriest details.

One commonality in these stories, aside from the macabre and arguably poor timing involved in telling them to me is that many accidents come down to a lack of visibility of motorcycles and their riders. Less than Argus-eyed motorists often pull out into the path of a motorcycle and with insufficient time for evasive action, that quickly an accident has occurred. Other times, drivers may focus on the car ahead of the motorcycle and in the event of stopping at a red light or similar, fail to leave enough room for the motorcycle, unfortunately rear ending him or her.

In the photo below, you can see that I am in one piece and the bike is also. Let's see what we can do to help keep things that way.

To partially combat the lack of visibility I decided to make a replacement brake light for my bike; one that would strobe briefly when I applied the brakes then stay solid on. I got this idea when I noticed a similar strobing effect to the brake lights on an ambulance that I was following near to, but not immediately behind. Those lights really got me to notice the ambulance which I had largely ignored up until that point.

I would also want a way to be able to disable the brief flash before the brake light stays solid on. This could be useful if the flash was ever to cause a safety hazard to other drivers or if I am ever stopped by the police for having this system I can easily disable the strobe part and still have a functioning brake light; I do not want to be stranded. I wrote the software so that if you turn the key on while you have the brakes applied, the flash is disabled. You must turn the key off, then back on, without the brake applied to restore the flash functionality.

Here is a video of the prototype Tenty LED Brake Light installed and operating. In the video, I demonstrate the flashing brake light 3 times and then key off. Then I disable the strobing part by turning the key on while holding the brake on, demonstrate that several times and key off again. Finally I re-enable the strobing functionality by key on with the brake off. For the purposes of the video, I lengthened the duration of the flash on and off times. This is so the camera can better capture the flashes.

In order to keep this system reversible should I ever have the need to put it back to stock, here is how I mounted the circuit board inside the tail light lens. I bought some replacement bulbs at a local auto parts store, broke out the glass and desoldered the filament. I replaced the filament by soldering wires to the tail light power, brake light power and ground. I ran a file over the solder blobs just enough to level them out so they would make good contact with the socket. I then filled the bayonet base with epoxy and inserted an 8-32 stainless steel screw into the base being careful not to touch the screw to any metal, accidentally making the screw a conductor. Below are a few pictures of this process.

After installing the modified bayonet screw mounts I threaded two nuts on each and jammed them together. This is what the back of the circuit board will rest on. You can see several pictures of the final assembly below.

Circuit:

The circuit is basically a large array of really bright red LED's ( Light Engine ) and an ATTiny85 microcontroller to tell the LED light engine how to behave. There are also two high brightness LED's that shine downward onto the license plate. They are solid on all the time as required by the Michigan vehicle code. The red LED's, made by Optek have a 100 degree viewing angle and output 8000 mlm each - there are 16 of them. The brake light switch delivers it's ~12 V signal translated thru an 2n3904 transistor to pull a microcontroller pin low. I usually use 14.4 V when doing calculations for operating voltage on 12V systems like this. Total current draw with all LED's at maximum brightness is less than 500 mA. I ordered the logic level mosfet IRLU3410PBF from mouser.com also, which is used for the PWM control of the light engine. Below you will find a screen cap pic of the schematic.

Software

There are two modes of operation to this brake light - flashing and non flashing. The non flashing brake light is activated by turning the key on while holding the brake and behaves just like a stock brake light would. Flashing mode is enabled by default so key on with brake off and you are good to go. In this mode, the LED light engine strobes briefly upon initial application of the brake then is a steady on light. I set the period of the flashes to be higher for the videos so the camera could pick them up, you can see in the code below that the flash period is twice as fast in the operational version of the software. Feel free to use the code as you see fit.

/*
Program Description: 

This program controls an LED light engine used as a brake light on a motorcycle.
When the brakes are applied the tail light flashes several times off then on before
being a steady on brake light.

The program also has a feature to disable the flashing brake light and the brake light will
behave like a standard lamp ie no flashing.  This mode is enabled ( flash mode disabled )
by turning the motorcycles key on while holding the brake on.  The state is reset after a power 
cycle.

Legal Note:  I read the entire vehicle code for my state.  It does not address brake light flashers, but
does prohibit " rotating, oscillating or flashing red lights ".  I believe a brake light flasher
differs from " rotating, oscillating and flashing " lights in the implied duration of operation.  
My state did not respond to emails I sent requesting clarification.  
Basically, modify your vehicle at your own risk.

Change Log
2012.4.21 - added 1 mS debounce to brake switch in main loop - Pete


A circuit description and other details can be found at http://petemills.blogspot.com

Filename: led_brakelight_main.c
Author: Pete Mills
petemills.blogspot.com
2012.4.15

Int. RC Osc. 8 MHz; Start-up time PWRDWN/RESET: 6 CK/14 CK + 64 ms

*/



//********** Includes **********

#include <avr/io.h>     
#include <util/delay.h>   



//********** Definitions **********

// Output to LED Light Engine

#define LED   PB0  
#define LED_PORT PORTB
#define LED_DDR  DDRB


// Input for Brake Switch

#define BRAKE_SWITCH  PINB4  // bit is clear when brake switch is pressed
#define BRAKE_SWITCH_PORT PINB
#define BRAKE_SWITCH_DDR DDRB



// PWM Preset Values

#define TAIL_LIGHT_PWM  25
#define BRAKE_LIGHT_PWM  255



//********** Function Prototypes **********

void setup( void );
void brake_alert( uint8_t number_of_flashes );



//********** Global Variables **********

uint8_t disable_flash = 0; // if 1, the flashing part of the brake light will be disabled


int main(void)
{


setup();

_delay_ms( 5 );



// if the brake light is held on during boot up, disable the flashing
// flashing can only be disabled during boot up ( key on ) and is reset after power down ( key off )
// this could be useful if you suddenly learn your flashing light is causing a problem for other motorists 
// or citizens employed to monitor the adherence to legislation and cite violations for deviation from such 


if ( bit_is_clear( BRAKE_SWITCH_PORT, BRAKE_SWITCH ) )
{
 disable_flash = 1; 
}



 while(1)
 { 
  
  
  if ( bit_is_clear( BRAKE_SWITCH_PORT, BRAKE_SWITCH ) )  // if the brakes are applied
  {

   _delay_ms( 1 ); // filter time aka debounce

   if ( bit_is_clear( BRAKE_SWITCH_PORT, BRAKE_SWITCH ) )  // if the brakes are actually applied
   {  

   // if we are allowed to flash, do
   
   if( disable_flash == 0 ) 
   {
    brake_alert( 5 );
   }
  

   // if the brakes are still applied, hold the LED light engine to a brighter output
   // until you release the brakes
   
   while( bit_is_clear( BRAKE_SWITCH_PORT, BRAKE_SWITCH ) )
   {
    OCR0A = BRAKE_LIGHT_PWM;
   }
   
   _delay_ms( 100 ); // debounce the brake switch release ( break )
   
   }   

  }
  
  OCR0A = TAIL_LIGHT_PWM;  // restore the tail light on
  
  
  
  /*
  // demo mode
  for( ;; )
  {
  brake_alert(6);
  OCR0A = BRAKE_LIGHT_PWM;
  _delay_ms(2000);
  OCR0A = TAIL_LIGHT_PWM;
  _delay_ms(4000);
  }
  */
   
 }
}




//********** Functions **********

void setup(void)
{



 //********* Port Config *********

 LED_DDR |= ( 1 << LED);   // set PB0 to "1" for output 
 LED_PORT &= ~( 1 << LED );   // turn the led light engine off

 BRAKE_SWITCH_DDR &= ~( 1 << BRAKE_SWITCH );   // set BRAKE_SWITCH pin to 0 for input
 BRAKE_SWITCH_PORT |= ( 1 << BRAKE_SWITCH );   // write a 1 to BRAKE_SWITCH to enable the internal pullup



 //********** PWM Config *********
 
 TCCR0A |= ( ( 1 << COM0A1 ) | ( 1 << WGM01 ) | ( 1 << WGM00 ) ); // non inverting fast pwm
 TCCR0B |= ( 1 << CS00 ); // start the timer
 
 
}




void brake_alert( uint8_t number_of_flashes )
{
 // here we create a visual alert that the brakes have been applied
 // pass this function the number of flashes desired ( off then on = 1 )
 
 //uint8_t delay_between_flashes = 50; // for video demonstration purposes ( video aliasing issues ) 
 uint8_t delay_between_flashes = 25; // every day use
 uint8_t alert_pwm_min = 2;   // minimum and max values to flash between during the alert
 uint8_t alert_pwm_max = 255;
 
 
 for( int i = 0; i < number_of_flashes; i++ )
 {
  OCR0A = alert_pwm_min;
  _delay_ms( delay_between_flashes );
  OCR0A = alert_pwm_max;
  _delay_ms( delay_between_flashes );
 }

}

Legal Note:

I'm not too sure what to say about the legality of this project. I read the entire vehicle code for my state. There was no reference to brake light flashers for cars or motorcycles. The vehicle code for Michigan does prohibit " rotating, oscillating or flashing lights " on non-emergency vehicles, however I believe my brake light does not qualify as the clear intent in the vehicle code was " rotating, oscillating or flashing " lights that continue to do so for an extended period of time as emergency or police vehicles do. Really, my device is no different than tapping your brake pedal several times before stopping your motorcycle. In the end, I did send an email to the state of Michigan requesting clarification. At the time of this writing there has been no response. I think the bottom line is, don't modify your vehicle unless you are willing to accept full responsibility for any outcome.

Here are a couple pictures of the build process. The abstract looking pictures are of the LED light engine shining thru my desk magnifier onto the ceiling.

ATTiny Candle

2012-02-05T10:17:00.000-05:00

The ATTiny Candle is an LED candle. It uses a high brightness LED and some software to mimic the look of a traditional candle without the dangers associated with an open flame. I imagine they could be useful as movie props where you cannot afford to have a candle go out during a take or in your home in places not suitable for traditional candles such as in a wall niche or alcove.

I have wanted to make an LED candle for some time now, so when I was approached by a work colleague about making one, I was provided the yeast to give it a go. I figured the hardest part of this project would be making the flicker look realistic, so I decided to let nature do that part for me. I made this candle with a Light Detecting Resistor ( LDR ) and a fixed resistor acting as a voltage divider. This is fed to one of the ATTiny85's ADC inputs and sampled at discrete time intervals. At this time, the sample rate is 100mS. These 8-bit light level values are then stored to EEPROM so that the candle can recall the flicker pattern to play back on the LED that is connected to a PWM channel after being turned off. You only need to program the pattern once, but you can program it over and over again with just the push of a button.

What I have really created here is a datalogger for light levels. Albeit, a datalogger with fairly small storage space of 500 bytes for the ATTiny85. Never the less, 500 bytes @ 100mS sample rate gives me a loop of ~50 Seconds. This is sufficiently long to not see a pattern repeating in the flicker pattern. I guess there is a transformation that occurs when you jam the whole thing into the middle of a candle it becomes an electronic LED Candle instead. Below is a picture of the aforementioned transformation process.

I did not mention yet, that I used a perfectly functional LED candle as the housing for my ATTiny Candle. It was about 50c from the thrift store, so it is a cheap enclosure. I also scavenged the high brightness LED from the original circuit. Not knowing the specs on the led I set out to measure the forward voltage. I lit the LED with a high value resistor in series. In the picture below you can see I am using an LED tester I made that has probably an R860 or 1k0 resistor in it. The LED plugs into some female header sockets. Measuring the voltage across the LED legs shows I have a forward voltage of 2.01v. I will assume 20mA max and select my series resistor based on 3, 1.5v ( nominal ), AA batteries. So, ( ( 3*1.5v ) - 2.01Vf ) / 0.02mA = R124.5. I guess the closest value I had on had was an R220 because that is what I used so the LED current is now ~11mA.

Here is a picture of the schematic and one of the assembled circuit about to be installed ( hot glued ) into the inside of a candle.

//Software &c

Here is a listing of the current working code. I have several improvements I would like to add in the future, but I will outline them later.

/*
Program Description: This program reads a light detecting resistor thru an internal ADC and stores the value, 
after scaling it, to eeprom.  This ADC value is sent to a PWM channel with attached led.  This is essentially a data logger
for light and replay by LED.  If, if you aim the LDR at a flickering candle during its recording phase, you have a flickering 
led candle.  

A circuit description and other details can be found at http://petemills.blogspot.com

Filename: ATTiny_Candle_v1.0.c
Author: Pete Mills

Int. RC Osc. 8 MHz; Start-up time PWRDWN/RESET: 6 CK/14 CK + 64 ms

*/



//********** Includes **********

#include <avr/io.h>     
#include <util/delay.h>   
#include <avr/eeprom.h>




//********** Definitions **********

// LED for flame simulation

#define LED   PB0  
#define LED_PORT PORTB
#define LED_DDR  DDRB



// Light Detecting Resistor for recording a live flame

#define LDR   PINB3 
#define LDR_PORT PINB
#define LDR_DDR  DDRB



// Tactile Switch Input

#define SW1   PINB4
#define SW1_PORT PINB
#define SW1_DDR  DDRB


#define ARRAY_SIZE 500  // size of the flicker array
#define SAMPLE_RATE 100  // ms delay for collecting and reproducing the flicker



//********** Function Prototypes **********

void setup(void);
void toggle_led(void);
void program_flicker(void);
void led_alert(void);
void eeprom_save_array(void);
void eeprom_read_array(void);
void scale_array(void);
uint8_t get_adc(void);
uint8_t scale( uint8_t input, uint8_t inp_low, uint8_t inp_hi, uint8_t outp_low, uint8_t outp_hi);
uint8_t is_input_low(char port, char channel, uint8_t debounce_time, int input_block);




//********** Global Variables **********

uint8_t flicker_array[ ARRAY_SIZE ] = { 0 };
uint8_t EEMEM ee_flicker_array[ ARRAY_SIZE ] = { 0 };


int main(void)
{

uint16_t replay = 0;

setup();

eeprom_read_array();



 while(1)
 { 
 
  
  
  
  if( is_input_low( SW1_PORT, SW1, 25, 250 ) )
  {
   
   // program the flicker
   // after entering and upon completion, a predetermined flash pattern will occur as described in led_alert()  
   // aim the ldr at a flickering candle or any other light source ( like a laser ) you want to record during this time
   // and upon completion the values are stored to eeprom.  They are played back immediately as well 
   // as being recalled from eeprom upon first start up
   
   led_alert();
   program_flicker();
   scale_array();
   eeprom_save_array();
   led_alert();
  }
  
  
  
  // replay the recorded flicker pattern 
  
  OCR0A = flicker_array[ replay ];
  ++replay;
  
  if( replay >= ( ARRAY_SIZE - 13 ) ) // if the end of the stored array has been reached
  { 
   replay = 0;          // start again from the beginning
   //led_alert();
  }
  
  _delay_ms( SAMPLE_RATE );
  _delay_ms( 3 );    // ADC Conversion time
   
 }
}




//********** Functions **********

void setup(void)
{



 //********* Port Config *********

 LED_DDR |= ( 1 << LED);   // set PB0 to "1" for output 
 LED_PORT &= ~( 1 << LED );   // turn the led off

 LDR_DDR &= ~( 1 << LDR );   // set LDR pin to 0 for input
 LDR_PORT |= ( 1 << LDR );   // write 1 to enable internal pullup

 SW1_DDR &= ~( 1 << SW1 );   // set sw1 pin to 0 for input
 SW1_PORT |= ( 1 << SW1 );   // write a 1 to sw1 to enable the internal pullup



 //********** PWM Config *********
 
 TCCR0A |= ( ( 1 << COM0A1 ) | ( 1 << WGM01 ) | ( 1 << WGM00 ) ); // non inverting fast pwm
 TCCR0B |= ( 1 << CS00 ); // start the timer
 
 
 
 //********** ADC Config **********
 
 ADMUX |= ( ( 1 << ADLAR ) | ( 1 << MUX1 ) | ( 1 << MUX0 ) );  // left adjust and select ADC3
 ADCSRA |= ( ( 1 << ADEN ) | ( 1 << ADPS2 ) | ( 1 << ADPS1 ) ); // ADC enable and clock divide 8MHz by 64 for 125khz sample rate
 DIDR0 |= ( 1 << ADC3D ); // disable digital input on analog input channel to conserve power

}




void toggle_led()
{
    LED_PORT ^= ( 1 << LED );
}




uint8_t is_input_low( char port, char channel, uint8_t debounce_time, int input_block )
{

/*
This function is for debouncing a switch input
Debounce time is a blocking interval to wait until the input is tested again.
If the input tests low again, a delay equal to input_block is executed and the function returns ( 1 )
*/
        
 if ( bit_is_clear( port, channel ) )
 {
  _delay_ms( debounce_time );
   
   if ( bit_is_clear( port, channel ) ) 
   {
    _delay_ms( input_block );
    return 1;
   }
 
 }

 return 0;
}




uint8_t get_adc()
{
 ADCSRA |= ( 1 << ADSC );   // start the ADC Conversion
 
 while( ADCSRA & ( 1 << ADSC ));  // wait for the conversion to be complete
 
 return ~ADCH; // return the inverted 8-bit left adjusted adc val

}




void program_flicker()
{ 
 // build the flicker array
 
 for( int i = 0; i < ARRAY_SIZE; i++ )
 {
  flicker_array[ i ] = get_adc();  
  _delay_ms( SAMPLE_RATE );
 }

}




void led_alert()
{
 // this is a function to create a visual alert that an event has occured within the program
 // it toggles the led 10 times.
 
 for( int i = 0; i < 10; i++ )
 {
  OCR0A = 0;
  _delay_ms( 40 );
  OCR0A = 255;
  _delay_ms( 40 );
 }

}




void eeprom_save_array()
{ 
 for( int i = 0; i < ARRAY_SIZE; i++ )
 {
  eeprom_write_byte( &ee_flicker_array[ i ], flicker_array[ i ] );
  
 }
}




void eeprom_read_array()
{
 for( int i = 0; i < ARRAY_SIZE; i++ )
 {
  flicker_array[ i ] = eeprom_read_byte( &ee_flicker_array[ i ] );
  
 }
}




uint8_t scale( uint8_t input, uint8_t inp_low, uint8_t inp_hi, uint8_t outp_low, uint8_t outp_hi)
{
return ( ( ( input - inp_low ) * ( outp_hi - outp_low ) ) / ( ( inp_hi - inp_low ) + outp_low ) );
}




void scale_array()
{
 uint8_t arr_min = 255;
 uint8_t arr_max = 0;
 uint8_t out_low = 20;
 uint8_t out_high = 255;
 
 
 
 // find the min and max values
 
 for( int i = 0; i < ARRAY_SIZE; i++ )
 {
  if( flicker_array[ i ] < arr_min )
   arr_min = flicker_array[ i ];
   
  if( flicker_array[ i ] > arr_max )
   arr_max = flicker_array[ i ];
 }
 
 
 
 // now that we know the range, scale it
 
 for( int i = 0; i < ARRAY_SIZE; i++ )
 {
  flicker_array[ i ] = scale( flicker_array[ i ], arr_min, arr_max, out_low, out_high );
 }
 
}

After I programmed a flickering candle to the EEPROM using the above code I read back the data. Below is 500 bytes of candle flicker data just in case you don't care to have a reprogrammable flicker you could use this static one.

:10000000777B7D7B78BA95535E3E3E4352353E7595
:100010004B657B5263586B5562777287858C5D7A2E
:10002000535D5062556F6758784E55956B6D7D7373
:100030007D5B6B686A6A606B7777987A87605B6BC9
:10004000534A5368453B65679C6067537375638A81
:100050007F8388806358586B7A787B838A878A8508
:1000600083888A8A8A8A8A8C8A8A8A8A8A88837F0B
:100070007D7B7A78777570707270704D416D6860B5
:1000800035353D3B4145525E41535D60656A5048A0
:100090004B4E3535313333363B40504E525D605315
:1000A000564B352D2E2E353838393B383158406077
:1000B0004D505A5D434053585A554E31312B2E33D3
:1000C0003136353638393938404A413B506240364E
:1000D000292D455E5D523E333B433545383531333E
:1000E00036363936383B4136363039332B29335A98
:1000F0006356413D5052556065553B302E303B4E66
:10010000362E2B3B393D4A503D45584E4B4E4A45C5
:10011000584B555D5B56585E60775E385A52464B79
:10012000504A4A354E412E363638524B463B3340C4
:100130004E605A504D434A504B48403D4046525BFA
:100140006263635B52465B43554526353B5B434DDB
:100150004056585A5D50464545413B437287908A08
:100160008F979D9573656B4D464555554156555531
:10017000565A5A5B5E56625565585A62686D6D6B89
:10018000686A6F656D316F55485055675A41555EC5
:100190006065686863606A60676A7F838C8788923D
:1001A0008D8F888C8C85826A4E35231119433B4193
:1001B000674A4A3B2E3045414A5848705B6D72622F
:1001C0007567565A5E554D77532D36415D55404003
:1001D0004040403E415E82928888909488857B634F
:1001E000555356555053550334013A7EFF01603E36
:1001F0003E28018EFFFFFFFFFFFFFFFFFFFFFFFF16
:00000001FF

Here is a video of a LDR programmed candle flicker. I was blowing gently on the candle flame during recording so that it would be a lively flicker for the video. It reminds me of a candle on the porch when a storm is coming in. Of course, it can be reprogrammed with a more subtle flame, the light from a bonfire or fire place, a laser pointer or even your hand shading light from the LDR. You could take a walk thru the woods and record the sunlight shining thru and shadows coming from the treetops. I have found the best results when programming the ATTiny Candle in a darkened room.

The list of improvements...

A) I would get the lower power version of the ATTiny85 to allow operation from 2 AA batteries. I only had ATTiny85-20PU in stock so I had to use 3 batteries. The black box external to the candle is the battery box. Unsatisfactory, really.

B) Once the batteries are tucked away and the switch is no longer accessible it may be a good idea to put the candle to sleep instead of switching it off. It could, for example, turn itself off after an hour or two of operation too. Then it could wake up with an external interrupt. And what would interrupt it? Improvement C of course.

C) A "blow" detector to be able to blow "out" and back "on", the candle. I did some quick experimentation with a piezo to detect a "blow" ( I guess ), although it worked, I abandoned the idea, saving it for later iterations. I couldn't find a location for the large piezo speakers I have, so I will have to order some smaller ones.

D) If you have any ideas please leave a comment!

Here are a couple more photos. Let me know if you have any success building an ATTiny Candle yourself.

The Clever Clapper

2012-01-14T22:49:00.000-05:00

The other day when I was at the reuse center I came across a few ikea lamps. I picked up two low voltage spot lights for $2 total. I think they came from this lamp. I also bought a moon lamp for $0.86 and I am still not sure why they charged such an odd amount for it. I wasn't too sure about the moon lamp, but I knew right away what I would do with the spot lights. It wasn't even 12 hours prior that I was trying to sketch up an idea on my slate chalkboard in low light conditions and thought I needed some task lighting. That distraction was what spawned this project.

Surely these lights would do great on their own with just an on/off toggle switch, but where is the fun in that? So, I decided to make a clapper circuit that turned out to be something a little more too.

A "Clapper" is a device that will turn on or off an AC appliance that is plugged into it, such as a lamp or fan when it "hears" you clap twice in approximate succession. They were originally sold in the mid eighties and it appears you can still buy them today.

In my version of the clapper if you clap twice within one second, the circuit toggles the lamp output. On becomes off and vice versa. If you clap three times within one second, the lamps begin dimming up and down via PWM until a fourth clap is detected or a one minute timeout occurs, whichever comes first. The brightness value is then stored and restored for subsequent toggling of the lights on/off with the two clap event. I also added a relay output to turn on and off the moon lamp. To trigger this relay, you shine a laser beam at the circuit to toggle it. Laser beams begets moon beams. It's science.

Here is a video of the Clever Clapper in action.

In case you are confused by the title of this post being the Clever Clapper and the text on the chalk board that says The Dandy Dapper Clapper you should know that the Clever Clapper is the hardware that a Dandy Dapper Clapper uses to clap his or her way to optimal lighting conditions.

These spot lamps didn't come with anything other than the lamp and holder. I needed a way to hold the holder so I banged a couple of nails into a some poplar wood to attach the lamp holder to. Ok, so I didn't "bang" these framing nails into the 1" x 2" bit of poplar wood so much as I drilled a hole slightly smaller than the O.D. of the nail and pressed them in, but you get the idea. This is not a finished installation; just the prototyping stage.

Here is a pic of the lamp, lamp holder, lamp holder holder and the lamp holder holder holder ( aka wall ).

Since we are talking about mechanical stuff, below is a picture of how the circuit and moon lamp are mounted to a piece of red oak. The wood board was drilled and tapped to accept aluminum standoffs to screw the circuit board and TIP120 heatsinks to.

Here are a couple of pictures showing the inside of the moon lamp. I added this black box with relay inside to control the hot AC line of this lamp with a microcontroller.

You can download a .rar of the ATTiny2313 code and Clever Clapper circuit schematic here.

There isn't much to say about the software except that there may be some "legacy" code in it still. That is, variables and the like that I didn't delete when changing things around or removing functionality so the program would fit into the available program space.

Below is a picture of the schematic. Starting at the top left you can see an electret microphone and it's filtered power supply. This is fed into one half of an LM358 Op-amp setup for 100x amplification. The 100k0 potentiometer is used for clap detection sensitivity adjustment. There is a connection to PD3 here that is no longer used, but more on that later. Then, the signal, or more accurately, part of the signal passes thru a low pass filter and on to the other half of the LM358 setup as a comparator. The output of this comparator stage is fed to the ATTiny2313. Otherwise the circuit is pretty straight forward, standard 7805 power supply and uC accoutrements, TIP120 darlington transistor with pulldown resistors. Oh, and don't forget that 1n4004 flywheel diode across the relay coil or you will be replacing your uC in very short order.

Here is a close up of the circuit. You can see the electret mic in the lower middle. There are two phototransistors on the board but only one is connected. They are the clear things with one at the center top of the ATTiny2313. There is also a red tactile switch who's input to the microcontroller is interpreted as two hand claps. This is used in the event you want to be quiet and still toggle the lights on and off.

When I first started this project I knew that I wanted to detect hand claps. As a human, I am quite good at this but, I had no idea how to describe a hand clap to a microcontroller. So, to "see" as a digital device would, I opened Audacity and started clapping my hands. Below is a picture of the spectrum analysis. To help prevent false triggers, it appears I can easily block non-clapping frequencies above ~5khz. This significantly improved the reliability of the circuit.

As I alluded to earlier I was not able to implement all of the features I wanted in my clapper. This is because I ran out of program memory. The last build used 100.0% of the available space. Of course I could have re-written the code trying to optimize for space or more likely I will just use a different uC in subsequent hardware iterations, should I decide the current implementation is prosaic. I feel code and hardware optimizations are a worthy subject of focus, but too, sometimes you just want to get the job done.

Here is a video of one feature that didn't make the cut due to the lack of program memory space. This mode would have been activated by a succession of four claps. In this mode, the raw speaker input ( pre-lowpass filter ) is fed to the microcontroller and modulates the PWM output to the lamps. The light looks like it is "talking" to you. It is a little hard to see in the video as I think the automatic white balance function of the video camera takes some of the resolution away. I was sad to see this feature go.

Over all I am quite pleased with the Clever Clapper. It is a lot of fun walking into a room and command-clapping lights to turn on - to your desired brightness value no less. I have yet to decide if I want to remake the hardware to allow for more features. I may, as one feature I wanted was clap programmable clap codes for instantly setting different lighting moods.

// clap off

Capricious Clock

2011-12-11T15:43:00.004-05:00

A couple of months ago I took a break from working on a precision pendulum clock project to build this. I call it a capricious clock for reasons that will be obvious after watching the video below. It ticks and tocks in an unnerving and aperiodic or spasmodic manner that anthropomorphically demands your attention. Even as the author of the software, I find myself lured in, staring the capricious clock down, face to face, anticipating and wondering when and sometimes if, the next tick will occur. Mercurial, you say? Precisely, but alliteration won out and "Capricious Clock" it is.

The most marvelous part of all of this, of course, is that the clock keeps accurate time over the long term. Neglecting inaccuracies inherent to quartz clocks, this clock could conceivably be off by no more than 8 seconds at any point in time. However, at no point in time do you ever feel the displayed time is something to be believed. I would like to place this clock in a public area to gauge peoples reactions. For now, it is on a show and tell basis, hanging on a wall at home.

Here is a video of the Capricious Clock running next to a regular AC wall clock. In the video, I fast forward by 500% at 1:12 until near the very end. This video is illustrative of the erratic ticking of the capricious clock on the right next to a smooth AC clock motor sweeping second hand.

The idea for a mind-melting ticking machine came from the author Terry Pratchett. There is "Lord Vetinari's Clock" in the series Discworld. I'm not exactly sure how, as it seems everyone around me is familiar with Discworld , but I am just finding out about it now. Actually, it was a similar clock that someone else built that got me thinking about how I would go about making something like this for myself.

That is the what and why, now on to the how...

In the pictures below you can see how the quartz clock movement was modified to intercept the 1pps signal and output my own clock "motor" drive pulse. I cut the traces going to and from the "black blob" IC on the circuit board for the 1pps signal and motor drive pulse. These were then soldered to fine gauge enameled wire and brought out to a strip PCB for later access.

In the picture below you can see how the quartz clock movement works. The black cylinder on the end of the white plastic gear is a magnet. It's poles are aligned perpendicular to its axis of rotation. When the movement is assembled, the copper wire electromagnet is pulsed once per second, alternating polarity and consequently magnetic poles to drive the movement. The relative location of the gear magnet and electromagnet ensure that the clock moves in the clockwise direction usually. It is possible with different electromagnet pulse durations to sometimes generate an anticlockwise tick. Nothing reliable enough for an open loop system like this though.

Below is the quartz movement with enameled wire soldered to the cut PCB traces. You may notice this is a different quartz movement than the one finally installed in the clock. I had to modify a new movement after accidentally applying 5v to one of the black blob IC traces and consequently rendered it useless.

Here you can see the fine enameled wire brought out to some blank PCB for more robust attachment of wires that will be controlling the clock and receiving the 1 pps signal.

At this point you could jumper the correct traces back together and the quartz motor would function as originally intended, but next a microcontroller comes in to modify the 1 pps to something a little less phlegmatic.

Here is the schematic for what we have done so far to the quartz movement and what is to come by adding a uC.

I mention in at least 4 places ( here included ) that after programming the chip you have to set the RSTDISBL fuse if you want to use PB5 as an IO pin. Once you do this, you cannot use ISP programming and instead have to do high voltage programming to bring the reset line up to 12v. For this reason, I have yet to test my code using PB5 as the intended "Mute" switch. I want to use it to toggle on or off the ability for the uC to make a tick-tock sound with the piezo. Until I am happy with the code, and I think I am nearly, I don't want to commit to the RSTDISBL fuse programming. I guess this capricious clock is not currently mutable?... 0_0

One way around the RSTDISBL / PB5 issue I describe is to use a boot loader on the ATtiny. I may do this because I don't like the idea of not being able to easily change the firmware at a later date and I have never used a boot loader on an ATtiny before and it may be fun.

A couple of other ideas I had for erratic ticking I had were to tick faster from 0s-30s and slower from 30s-60s as if the clock was operating in a larger gravitational field than its surroundings and the motor just barely keeps up. Or, the same erratic ticking over a longer time though so that it drifts +/- 5 minutes an hour or so. I think this will eventually catch someones attention, but it would take longer to notice. For these reasons I think I have just convinced myself to remake this project with an added bootloader on the ATtiny85.

Here are a couple of pictures from the inside of the clock. This clock made it really easy to shoehorn the additional electronics inside.

// software

The code keeps track of the 1pps pulses coming from the quartz clock movement, it delays for a random period of time then moves the second hand. If the "Real Time" elapsed is greater than the displayed time the program will delay anywhere from 1-0.125s to catch up to the "Real Time". If the display time is faster, the program will select a random time from 1-8s to slow down so that "Real Time" can catch up.

Rather than just turning the thing on and letting it run in an endless loop I used external interrupts, nested interrupts and the watchdog timer with power down sleep mode to wake up from a sleep period to update the display.

Using the aforementioned capabilities of the ATtiny85 was necessary for the reliability of counting the 1pps pulse and the ability to conserve battery power - a very important thing to do in battery powered devices. You can see in the calculations below the clock will theoretically run for ~225 days or ~61.6% of a year before needing new batteries. Now, that is theoretical and does not account for sleep current, wake up current and time or battery self discharge. However, in this case, where the ratio of active to sleep current is so great, you can safely ignore those calculations. By entering into power down sleep mode the battery life is extended by nearly 3 months.

Here is the code. As previously stated the switch on PB5 is commented out in the code so it will not work. I did this because I am not done using the ISP and will probably use a bootloader in the end.

/*

Program Title: Capricious Clock
Author: Pete Mills
Date: 2011.12.09
petemills.blogspot.com

Filename: capricious_clock_v1.0_main.c

Int. RC Osc. 8 MHz; Start-up time PWRDWN/RESET: 6 CK/14 CK + 0 ms
ck div by 8 for 1MHz system clock

Set RSTDISBL fuse after programming to allow use of PB5
After setting RSTDISBL you will have to use HV programming to reprogram the AVR - no more ISP

*/

// Includes

#include <avr/io.h>     
#include <util/delay.h>    
#include <avr/interrupt.h>
#include <avr/sleep.h>


// Definitions

#define IO_PORT  PORTB
#define LED   PB0  // LED pin PORTB Pin 4
#define BUZZER   PB1  // piezo output buzzer
#define PPS_IN   PB2  // 1 Hz input signal
#define SEC_MOT_1 PB3  // output to drive seconds motor coil on quartz clock
#define SEC_MOT_2  PB4  // another output to seconds motor coil on quartz clock assy
#define MUTE_SW  PB5  // input switch for muting piezo and ...?


// function prototypes

void setup(void);
void toggle_led(void);
void inc_sec(void);
void tick_tock(void);



// Global Constants


volatile uint32_t rt_sec = 0; // actual time elapsed
volatile uint32_t my_sec = 0; // seconds displayed on the clock
volatile uint8_t  do_tick = 0; // decide to tick or not



int main(void)
{

setup();
sei(); 
set_sleep_mode(SLEEP_MODE_PWR_DOWN);



 while(1)
 { 
  /*
  // turn on or off the ticking sound
  if ( bit_is_clear( PINB, MUTE_SW ) ) 
  {
   ++do_tick;
   
   if( do_tick > 1 )
   {
    do_tick = 0;
   }
  
  }
  */
  
  asm("nop");  // ISR's return to main to execute a minimum of one instruction 
  asm("nop");  // before executing pending interrupts
  
  sleep_mode(); // go back to sleep
  
 }
 
}




// functions

void setup(void)
{

// Port Configuration

 DDRB |= ( ( 1 << SEC_MOT_1 ) | ( 1 << SEC_MOT_2 ) | ( 1 << BUZZER ) | ( 1 << LED ) ) ;  // set PB1::PB4 to "1" for output 
 IO_PORT &= ~( ( 1 << SEC_MOT_1 ) | ( 1 << SEC_MOT_2 ) | ( 1 << BUZZER ) | ( 1 << LED ) ); // set the outputs low

 DDRB &= ~( ( 1 << PPS_IN ) | ( 1 << MUTE_SW ) ); // set PB0 and PB5 to "0" for input
 IO_PORT |= ( 1 << MUTE_SW );      // enable internal pullup on input switch
 

// Interrupt Configuration

 // External Interrupt INT0 ( INT0_vect )
 
 // low level on INT0 causes interrupt
 
 GIMSK |= ( 1 << INT0 ); // enable external interrupt on INT0
 
 
 // Watchdog Timer Interrupt ( WDT_vect )
 
 WDTCR |= ( ( 1 << WDCE ) | ( 1 << WDE ) );
 WDTCR &= ~( 1 << WDE );
 
 WDTCR |= ( 1 << WDIE ); // watchdog timeout interrupt enable
 WDTCR |= ( ( 1 << WDP0 ) | ( 1 << WDP2 ) ); // half second sleep

}


void toggle_led()
{
    IO_PORT ^= (1<<LED);
}



// function to drive the quartz clock motor
void inc_sec()
{

 if( my_sec % 2 == 0 )
 {
  IO_PORT |= ( 1 << SEC_MOT_1 ); 
 }
 else
 {
  IO_PORT |= ( 1 << SEC_MOT_2 ); 
 }
 
 _delay_ms(30); // empirically derived pulse duration
 
 IO_PORT &= ~( ( 1 << SEC_MOT_1 ) | ( 1 << SEC_MOT_2 ) );

}



// making the tick tock escapement sound
void tick_tock()
{

 if( rt_sec % 2 == 0 )
 {
  IO_PORT |= ( 1 << BUZZER );
  _delay_us(200);
  IO_PORT &= ~( 1 << BUZZER ); 
 }
 else
 {
  IO_PORT |= ( 1 << BUZZER );
  _delay_ms(1);
  IO_PORT &= ~( 1 << BUZZER );  
 }
 
}




// this ISR is called once per second as the quartz clock movement outputs its pps signal 
ISR( INT0_vect )
{
 ++rt_sec;
 
 if( do_tick )
 {
  tick_tock();
  //toggle_led();
 }

 
 while( bit_is_clear( PINB, PPS_IN ) )
 {
  // stay in ISR until input signal is high again to stop multiple triggers
 }

}



// this ISR is called to update the output display
ISR( WDT_vect )
{
 sei(); // allow this interrupt to be interrupted...
 
 uint8_t rand_num = (uint8_t) rand();
 uint8_t case_sel = 0;

 ++my_sec;  // increment displayed time counter
 inc_sec();  // move the second hand
 
 rand_num = (uint8_t) rand();
  
  
  case_sel =  rand_num % 4 ;
  
  if( my_sec > rt_sec )
   case_sel += 3;
  
  
  switch (case_sel)   // set sleep time
  {
   case 0: 
    WDTCR &= ~( ( 1 << WDP3 ) | ( 1 << WDP2 ) ); 
    WDTCR |= ( ( 1 << WDP1 ) | ( 1 << WDP0 ) );     // ~0.125s sleep
   break;
   
   case 1: 
    WDTCR &= ~( ( 1 << WDP3 ) | ( 1 << WDP1 ) | ( 1 << WDP0 ) ); 
    WDTCR |= ( 1 << WDP2 );          // ~0.25s sleep
   break;
   
   case 2: 
    WDTCR &= ~( ( 1 << WDP3 ) | ( 1 << WDP1 ) ); 
    WDTCR |= ( ( 1 << WDP2 ) | ( 1 << WDP0 ) );     // ~0.50s sleep
   break;
   
   case 3: 
    WDTCR &= ~( ( 1 << WDP3 ) | ( 1 << WDP0 ) ); 
    WDTCR |= ( ( 1 << WDP2 ) | ( 1 << WDP1 ) );     // ~1.00s sleep
   break;
   
   case 4: 
    WDTCR &= ~( ( 1 << WDP3 ) ); 
    WDTCR |= ( ( 1 << WDP2 ) | ( 1 << WDP1 ) | ( 1 << WDP0 ) ); // ~2.00s sleep
   break;
   
   case 5: 
    WDTCR &= ~( ( 1 << WDP2 ) | ( 1 << WDP1 ) | ( 1 << WDP0 ) ); 
    WDTCR |= ( 1 << WDP3 );          // ~4.00s sleep
   break;
   
   case 6: 
    WDTCR &= ~( ( 1 << WDP2 ) | ( 1 << WDP1 ) ); 
    WDTCR |= ( ( 1 << WDP3 ) | ( 1 << WDP0 ) );     // ~8.00s sleep
   break;
   
   default: 
    WDTCR &= ~( ( 1 << WDP3 ) | ( 1 << WDP0 ) );      // should never occur
    WDTCR |= ( ( 1 << WDP2 ) | ( 1 << WDP1 ) );     // but set the WDT for 1s if it does
   
  }
  
}

Arcade Push Button Light Switch Redux

2011-09-08T13:48:00.003-04:00

I got a lot of feedback on my post from a couple days ago about making an Arcade Push Button Light Switch. Mostly that this task could be easily accomplished with a single DPDT 110VAC relay. While this true, the original post was really about using what I had on hand at the moment to remake something I saw online.

Never the less, while I was at Grainger this morning picking up supplies for another project I also grabbed a DPDT relay, part no. LY2-AC110/120, to make another version of the arcade button light switch. This is how I would make the switch if I was going to be purchasing parts for it.

Here is a schematic. This sort of design has been around for ages. I guess people used to use relays for all kinds of control applications and called it Relay Logic.

* Update *

A few people have asked for more pictures of what wires go where. Unfortunately, I do not have any photographs that would be useful. I did draw the picture below, though and I know of at least one person that built this switch based on it. If you are unfamiliar with working with 120v household wiring be sure to ask someone who is in the know for some help. Getting a shock from 120vac is unpleasant.

Below is a picture of the microswitches in the arcade pushbuttons. As you can see they are more than capable of switching the voltage and current required for this design.

So, wire it all up, apply some hot glue and drink some coffee.

And then take an action video. I am switching my frequency counter in this video. It is kind of handy anyway as the power switch for the counter is on the back of the unit. I don't always use my frequency counter, but when I do, it's a pain to turn it on. Well, not anymore.

Arcade Pushbutton Light Switch

2011-09-06T20:16:00.006-04:00

UPDATE: If you would like to see different circuit design, have a look at version 2.

I was poking around the internets on Labor day when I came across this. It is a wall switch intended to replace a boring old toggle switch in your arcade room. My single arcade machine does not warrant its own room, but I do like the idea of an arcade button light switch. So, in an effort to get up and do something I made this arcade button switch for switching an extension cord. I have it plugged into the magnifier with fluorescent lamp on my electronics bench.

Since it was a holiday, I wanted to use only parts I had on hand so that I could finish this project the same day. Fortunately, I have a pretty large selection of bits that included arcade buttons. Sadly, I had no triacs, though and settled for a relay instead.

There are quite a few ways that you could make a set/reset flipflop circuit for this purpose. I settled on a 555 timer setup with relay. The flipflop could have just as easily been two NPN transistors, but I felt like reminiscing with the venerable 555 timer.

Download the schematic here if you like...

I very slowly drilled two holes in a cover plate.

Circuit assembly began with the relay I had on hand. I soldered some leads to the normally open contacts on the relay and put heatshrink on the solder joints. The unused, normally closed, pin on the relay was snipped off flush and insulated with a dab of hot glue. Otherwise, this pin would have been an exposed hot leg of 110VAC. Not a huge deal as everything is inside a plastic box, but it is a good idea to do.

Circuit assembly continued on a piece of perf board and was hot glued to the top of the relay which, in turn, was hot glued betwixt the arcade push buttons.

In the picture below, you can see where the hot lead of the extension cord is interrupted by the normally open contacts on the relay. You can also see a knot tied into the extension cord in the top left of the picture as strain relief.

Below you can see everything fits into the box nicely. What isn't too apparent is a pair of black wires coming out of the box too. I chose to use a wall wart transformer to power my circuit instead of the 110VAC coming into the box as this is just a bench top installation and not an, in the wall, permanent fixture.

Here is a video of the switch in action. You can see the camera adjusting it's auto white balance as the lamp I have the switch plugged into is turning on and off.

This project was a fun way to spend the afternoon. It certainly adds some geek cred to my electronics bench. I think I am more interested in a monostable 555 circuit attached to the relay output, however. That way, I could turn things on for a period of time and have them turn off automatically, instead of returning a day or two later to find out I left my soldering station on again.

Guitar Pickup Winder

2011-08-28T13:52:00.003-04:00

This projected started in June of 2011. Remember the Google Doodle commemorating Les Paul's 96th birthday? Well, that got me thinking about how electric guitar pickups work. I had a general idea about how they work, postulating they are essentially variable reluctance sensors, but doing a bit of research, I kind of got bitten by the electric guitar bug and dove right into the research of solid body electric guitars as a whole.

I have been primarily focused on guitar pickups and passive electronics at the moment. In short order however, I would be requiring a test bed for these pickups. That is why I made the decision from the very beginning that I would not only try my hand at building electric guitar pickups, but a complete scratch built guitar; wood has been harvested. Later posts will focus on other topics about solid body electric guitar building. Here, I will try to stay on the topic of an electric guitar pickups, but more specifically the pickup winder I built to wind my own pickups.

After announcing my new obsession to anyone who would listen, an electric guitar was given to me to experiment with. It is a smaller than average guitar, possibly for a child, but it will do just fine to test my pickups with a full guitar still being built down the road. Below is a picture of the pickguard with the old electronics installed.

Since I was going to be using an microcontroller to count the turns and stop the machine when the predetermined number of turns has been reached, I could make this winder do more stuff too. So, I made this pickup winder into more of a pickup winding station. Here is a feature list:

-Pickup Winding with turn counting, RPM, ETA and auto stop
-Stroboscopic guitar tuner
-Ohm meter for coil resistance measurement
-Gaussmeter for measuring polarity and magnetic flux density of pole pieces

I decided to use an Arduino to control my guitar pickup winder. I figured it would be a good way to put it into use. I bought the thing years ago and have only used it a couple of times. It really just gathers (figurative) dust as was the graphic LCD I used here too. I was glad to put some inventory to use in this project.

The code is ~850 lines so probably a bit much for inline posting with syntax highlighter. Instead, you can download the arduino "sketch" (code) below. Also, there is a link to a collection of free PDF's I came across while doing research for this project. There is some good information in there about guitar pickups. I also put a schematic for wiring my guitar in there too as I found the pictorial "schematics" confusing.

Files:

You can download the pickup winder schematic here.
You can download the v1.5 Arduino code here.
You can download the guitar electronics schematic plus PDF collection here.

The need for a pickup winder is obvious when you take a look at the construction of an electric guitar pickup. Essentially, there is a bobbin made from AlNiCo rod magnets and insulating material. Around this, there are ~6,000 to ~10,000 turns of 42 ga wire. Depending on the pickup, the number of turns of wire and the wire gauge will differ, but this approximation will illustrate the need for a machine that can turn the bobbin and reliably count the completed turns.

Here are some pictures showing the complete bobbins and the Jarrah wood spacers and tools for assembly. Everything is sitting on my tree stump anvil that I collected while sawyering in the above youtube video. The magnets are appropriately called "pole pieces" and this configuration is called "staggered". The height of the pole piece corrects for volume as the fretboard is radiused.

Also, 42 ga wire is tiny and fragile! Here is a microscopy photo showing the copper 42 ga wire on the right next to a hair from my head.

O Kapton! My Kapton! I wrapped the bobbins with Kapton tape to prevent possible abrasion from wearing thru the wire insulation and shorting out the pickup. I also super glued the inside joint where the alnico 5 rod magnets meet the flatwork to discourage pressing them thru and abrading the coil wire.

I looked up some commercially available pickup winders to get an idea of what I was trying to make. The speed ranges were all around 1000 RPM and variable. Some of the commercial winders have a thru axle offering "reverse" winding capabilities. I decided I can achieve "reverse" winding by mounting the pickup to wind "upside down" and the direction of wind will be opposite. This way I do not have to worry about motor direction control.

I found a variable speed motor in the form of a sewing machine motor in one of my many junk boxes. I made an infrared non-contact tachometer to measure the no load speed of this motor and was rather surprised to find that it turned at 10,000 RPM. Clearly this is way too fast even with the variable speed throttle pedal.

I did not give up on sewing machine motors, though and went to the ReUse center and found an old Remington sewing machine for $5. This machine was too sweet looking to hack apart so I decided to keep it as a sewing machine after a bit of tuning it up and make up an adapter to make it work for pickup winding too. Also, leaving the sewing machine in tact gives me the benefits of mechanical gear reduction, friction to help slow it down, a flywheel and a face plate area to mount an adapter for putting the pickup bobbins. It's a win-win situation.

Here is a drawing of the adapter jig. It mounts in the flywheel on the end of the sewing machine with three rare earth magnets as seen in the picture below. A ferrous piece of material, such as steel is screwed on to the aluminum jig to allow the pickup bobbin to be mounted with it's Alnico 5 magnets.

I found that the pickup bobbin mounted magnetically to the steel bar did not have a high enough coefficient of static friction; it would rotate with a small amount of torque applied yet it had quite a strong magnetic attraction to the steel bar. I tried a piece of duct tape, sticky side towards the steel plate, and it helped, but the real solution was gluing a couple pieces of sand paper on the outer edges of the steel bar, atop the duct tape as shown below. This allows for secure winding.

Below you can see how I mounted the pickup bobbin in "standard" orientation. This allows what is known as clockwise winding. The picture also shows how I used a straight edge to line up the wire guide stops. Those wire guide stops are mounted to a 3/8" diameter rod from the hardware store. The rod is held in place by a magnetic base dial indicator stand. All sewing machines that I am aware of have a flywheel on the side that rotates the same direction. Using the picture below for reference, the top of the flywheel moves to the left. This is anti-clockwise as you look at the front end of it.

In the following pictures you will see how I mounted the bobbin to the faceplate to allow "reverse" or anti-clockwise winding. I pressed some rare earth magnets into a piece of Jarrah wood. The pickup bobbin is charged magnetically so it's alnico 5 rod magnets are attracted to the opposite poles on the rare earth magnets. The rare earth magnets hold the Jarrah wood spacer and bobbin to the steel bar on the faceplate.

Did you happen to notice a piece of black electrical tape across the flywheel in any of the pictures above? That is for the infrared non-contact tachometer. You can check the schematic for more details on that. Since I am measuring rotation events over time (RPM), it is a trivial matter to count the total number of events (rotations) or coil winds. I am also able to calculate estimated time to completion based on current RPM and number of winds left. The software opens a relay when the number of winds is greater than or equal to the desired number of winds. This cuts the power to the sewing machine so it stops when you have the correct number of winds. Of course, inertia adds a few winds, but you can compensate for that by lowering the number of winds desired or just unwinding a few turns when you see how many over the machine went. It seems to overshoot by 10-15 turns due to inertia so I just set the desired turns number lower. That is a pretty complete description of the coil winder operation. There isn't much to it, but there is a lot of information on the internet and in books about coil winding that are worth a read.

You can see a picture of the non-contact IR tach sensor below. It has 2 magnets to attach to the cast iron sewing machine body.

Even with the gear reduction offered by keeping the sewing machine in tact and the added friction, I found the flywheel where my adapter jig is mounted still rotated too fast. I found it necessary to slow the motor down further and I did this by adding a "resistor" for the AC hot line of the sewing machine motor. I used a 100-watt light bulb for this purpose and now the final speed at the flywheel is a manageable maximum of ~1000 RPM. The throttle pedal still controls speed and the light bulb is inserted in the circuit with standard 110ac 2 prong plugs so it can be removed for high speed sewing. Below is a picture of the dimly glowing bulb acting as a resistor.

Here is a short demo video.

Stroboscopic tuner:

The stroboscopic guitar tuner works by flashing an LED at the resonant frequency of an in-tune guitar string. I made a guitar pick with an led on it to pluck a guitar string. An LED plectrum if you will. The pick was etched using the sharpie and ferric chloride method. It says "LED Guitar Tuner" on it. You aim the led at the string while it vibrates and turn the tuning machines of the guitar until the string appears to be still. Below is a picture of the LED pick and a video of the tuning in progress. It is a little difficult to see in the video but in person, the strobe tuner is quite effective. The video is taken after the pickups I made were installed in this guitar. The sound you are hearing is coming from an LM386 audio amp I made for a different project.

I have found in practice that the stroboscopic guitar tuner is much easier to use on the lower frequency strings. Like the low-E at 82.41 Hz. The video above is of the G string at 196 Hz and it is easy enough to see in person too. I guess, as with anything, practice is helpful to getting it right. You can use relative tone matching by ear for tuning the higher frequency strings. There is nothing to say you cannot strobe tune all strings with the strobe tuner, however.

Gaussmeter:

I think it will be useful to know the relative Gauss strength of the pickup pole pieces and knowing the polarity, north or south, will be paramount to success. Many websites on pickup making suggest using a polarity tester for determining polarity but, using a continuous, ratiometric hall effect sensor I can measure the magnetic flux density of the pickup pole pieces at 1.3mV/G as well as the polarity. This is an uncalibrated value, but it is sufficient for my purposes. The sensor I used is an Allegro A1302 hall effect sensor. In the gaussmeter mode, peak gauss values are recorded and instantaneous values are reported.

It is important to note that if the gaussmeter displays the polarity as "North", that means you have a "South" pole of a magnet facing it and your pickup is a "South" polarity pickup. This is the same as how a compass would work.

Ohm Meter:

Not too much to say here. There is a voltage divider circuit made with a 10k0 resistor and the guitar pickup under test. The instantaneous ohmic value is reported and peak value stored and displayed. I remember measuring the resistance of a coil right after winding. It measured ~6k2. After leaving it for some time it went down to 6k0. I believe the friction from my hand when winding caused the temperature to rise enough to cause this.

I had originally planned to make this pickup winder have an automatic wire feed traversal so it could wind coils on its own. I may get back to doing that at some point but for now I will "hand" wind them. That is, feed the wire to the spinning bobbin by hand. This seems to be the preferred method of winding of some musicians anyhow. I left a PWM channel available to connect a servo motor to at some point for this purpose should I choose to implement it.

Once the pickups are wound and wire ends soldered to the eyelets they are was potted. I wrap one round of kapton tape around the coil wire before potting in 20% beeswax and 80% by mass of gulf wax. I put the jar in a bath of ~160 Deg F water to melt the wax. I put the pickup in the wax and wait for it to come up to temperature. You can see in the video below that the pole pieces are that last to warm. The whole thing locally cools the was and it solidifies. Within about a minute, depending on the relative thermal masses the pickup is up to temperature and all the wax around it is remelted.

Once they are up to temperature I apply a partial vacuum to the jar removing air and replacing it with wax in all the nooks and crannies of the coil winds. Besides being good practice for durability of this tiny wire this also stops what guitar players refer to as microphonic pickups.

Here is a shot of the pickups wax potted and ready to be installed into the guitar. The black wire is the ground. I make the ground wire whichever eyelet is the coil finish so that the outer coils of the pickup can act as a shield also.

I wound my middle pickup to be opposite of my neck and bridge pickup. It will be reverse-wound, reverse-polarity for hum cancellation in guitar switch positions 2 and 4.

As far as charging the pole pieces goes it's pretty easy. Alnico is very coercive. I bring the assembled and potted pickup into contact with one pole of a strong rare earth magnet. I use a 3-inch diameter 400 lb pull magnet. I suspect you can get away with a much smaller magnet, that is just what I had on hand. So, if I want a "North" polarity pickup I bring the top of the pickup into contact with the "North" side of the charging magnet. The approach and withdraw is axial. Then I do the same on the other side bringing the bottom of the pickup close to the magnets' "South" pole. This makes the top of the pickup "North" and thus attracts a compass "South" needle, thus a "North" polarity pickup.

I installed the new pickups I made into the old pickguard. I had to whittle away some of the bass wood of the body cavity to fit an extra tone potentiometer. As I stated earlier, I have a reverse wound, reverse polarity middle pickup here. I wired them up according the the schematic I drew up and linked to above. I think this is the standard "Strat 2-tone wiring".

So, in the end, everything seems to have worked. It makes noise anyway. I am waiting for someone who knows how to play a guitar to come over and test it out, but I think I am off to a good start. If you have any suggestions on how to improve my pickups let me know. Or, if you have any tips on scratch building guitar bodies/necks that would be appreciated too. I still need to make a better case for the Pickup winder electronics. Probably a wooden box to set the plexiglass in to keep fingers and 110 vac separate.

A final "finished product" picture... for now anyway. Also, the missing string has been replaced already.