Another Ice Tube Clock Design for the Holidays

by jarchie on Fri Sep 20, 2013 10:17 pm

I'm planning to do a redesign of the Adafruit Ice Tube Clock to give family members this Christmas. Unfortunately, I have basically no experience designing hardware, but I've done some preliminary work and would be grateful for any feedback on my ideas thus far...

I have an initial redesign of the Ice Tube Clock board in Eagle CAD, which I ordered from OSH Park. Because I needed to move the power connector and battery slightly, I had to make a new case design, which I ordered from Ponoko. The assembled prototype is pictured below and uses no Adafruit parts:

Image

The prototype pictured above incorporates the following features:

  • IV-18 tube driven to specifications: Driving the display to specifications eliminates the dim digit issue and allows for more consistent illumination (see this thread).
  • Automatic dimming: A photoresistor allows automatic dimming as appropriate for the ambient lighting (see this thread).
  • 25-fold reduction in sleep current: Unless the clock is without power for over a year, the battery should never need replacement (see this thread).
  • Solder points for GPS mod: Solder points allow easier connection of an external GPS unit for GPS timekeeping (see this thread).
  • Reliably programmable: The original Ice Tube Clock cannot be programmed reliably via the ISP header. A new jumper forces the clock into sleep mode, allowing reliable programming (see this thread). UPDATE: I believe that I was mistaken about the original clock not being reliably programmable, so it is not necessary to use this jumper when programming this clock.
  • Robust microcontroller environment: The microcontroller now has a decoupling capacitor and 10K pull-up on the !RESET pin.
  • DS18B20 temperature sensor (not yet used): A temperature sensor allows for the microcontroller to compensate for temperature-related timekeeping error. I have unposted preliminary results that show this will improve timekeeping accuracy, but have not yet implemented this feature in the software. I will post these preliminary results to the Adafruit Clocks forum upon request. UPDATE: The temperature sensor is working quite well in the latest firmware; see this thread for details.
Unfortunately, this design breaks compatibility with existing Ice Tube Clock firmwares. The firmware I'm currently using is my xmas-icetube available via GitHub.
Last edited by jarchie on Fri Jan 17, 2014 4:34 pm, edited 2 times in total.
--John <www.jarchie.com/email>
jarchie
 
Posts: 331
Joined: Sun Jun 24, 2012 1:16 pm
Location: Santa Cruz, California, United States

Re: Another Ice Tube Clock Design for the Holidays

by PhilD13 on Sat Sep 21, 2013 3:10 pm

Grabbed the files, gave the board a quick look and It looks great! I like the idea of standing the regulator up, saves a lot of board space.
I'll give it a better look over tomorrow when I have more time.
PhilD13
 
Posts: 149
Joined: Mon Sep 10, 2012 12:05 pm

Re: Another Ice Tube Clock Design for the Holidays

by jarchie on Sun Sep 22, 2013 1:03 pm

I moved the firmware for this prototype to the xmas-b branch on GitHub. I would like to avoid accidentally breaking things for the majority of users who have the Adafruit kit.

PhilD13 wrote:I'll give it a better look over tomorrow when I have more time.

That would be awesome! Thank you!
--John <www.jarchie.com/email>
jarchie
 
Posts: 331
Joined: Sun Jun 24, 2012 1:16 pm
Location: Santa Cruz, California, United States

Re: Another Ice Tube Clock Design for the Holidays

by PhilD13 on Sun Sep 22, 2013 7:50 pm

I like the design. It looks good overall to me and am thinking of ordering some boards from OSH to play with. Out of curiosity, did you upload gerbers or use the upload the board file option?

I take it that C11 and R9 are installed from the bottom?

Missing a value for the ptc fuse so with the added stuff like GPS, are you planning a .250 or a .300 ptc?

No suggested part types (value) for the cathode supply transistors. might add those.

Since the software looks like it supports it, where is it intended to add on Maxim DS32kHz support to the board? or did I just miss that, EDIT: or is that the two pins/pads above C10 next to IC4? Would designing in a place on the bottom of the board for an soic version of the chip be practicable? As small as they are, they seem to take up a lot of real estate?


General questions
If I eliminate R7, R8 (replace with jumpers) could ZVP2110A and ZVN2110A fets be used? I have a few laying around.

In general, a question on the light sensor with your software. The adafruit master schematic shows a 1k pullup (shown as 1.0k in value) which I think would be more sensitive when used with a photocell? So why the 10K decision in hardware/software? I'm currently using a 1k with your software and it works ok, but wonder if I can optimize the code somehow for the 1k?

Would changing the 60v zener to a higher value (max 70v) help anything?

EDIT: On the temp sensor. If you could compensate in software for the average temp difference between inside the case and outside the case you could probably also display temp.
PhilD13
 
Posts: 149
Joined: Mon Sep 10, 2012 12:05 pm

Re: Another Ice Tube Clock Design for the Holidays

by jarchie on Mon Sep 23, 2013 11:50 pm

PhilD13 wrote:I like the design. It looks good overall to me and am thinking of ordering some boards from OSH to play with.

Thank you so much for the extensive feedback!

It's easiest to get sets of three from OSH Park and Ponoko. If you're willing to reimburse my costs, I could send you a single board and case. Email me if that arrangement would suit you better.

PhilD13 wrote:Out of curiosity, did you upload gerbers or use the upload the board file option?

I uploaded the board file directly. I also shared the project ("xmas-icetube prototype b" / "REV B" / "xmas-b") on OSH Park, so anyone can order the exact same board.

PhilD13 wrote:I take it that C11 and R9 are installed from the bottom?

Installing them from the bottom would probably work just fine, but I intended for those parts to be installed from the top in the dead space within the surrounding socket:

Image

PhilD13 wrote:Missing a value for the ptc fuse so with the added stuff like GPS, are you planning a .250 or a .300 ptc?

I'm using the same 200 mA fuse (RXEF020) as in the original kit. But I think you're right: a larger fuse would have been a better choice. The 200 mA fuse will probably work fine with the Adafruit Ultimate GPS module, but other GPS modules might consume too much current.

I'll look into it.

PhilD13 wrote:No suggested part types (value) for the cathode supply transistors. might add those.

Good call. Those transistors are numbered PN2222 and PN2907A.

PhilD13 wrote:Since the software looks like it supports it, where is it intended to add on Maxim DS32kHz support to the board? or did I just miss that, EDIT: or is that the two pins/pads above C10 next to IC4? Would designing in a place on the bottom of the board for an soic version of the chip be practicable? As small as they are, they seem to take up a lot of real estate?

Because I couldn't fit the through-hole version of the DS32kHz on the board, I will be using a DS18B20 temperature sensor to do software temperature compensation instead. I wrote the code for that yesterday and it seems to be working okay. I expect accuracy to be comparable to the DS32kHz (fingers crossed). But the code is neither well tested nor posted to GitHub. But the code will be posted to GitHub soon under the xmas-b branch.

If anyone is interested in why I think I can get similar accuracy with a DS18B20, just let me know: I'll post those preliminary data and explain my reasoning in another thread. Unfortunately, those data are sufficiently extensive and independent to warrant their own thread--at least in my opinion--so I don't want to discuss those here.

For those with their heart set on using the DS32kHz, the GPS holes provide access to the battery, ground, and regulator voltage. So without a GPS module, users could use those holes for the DS32kHz and glue it on the battery--just like the original TCXO hack, but with easier solder points.

The idea of using the SOIC version on the bottom of the board did cross my mind when designing the board, but I didn't think I could make it work. I'd be delighted and amazed if someone can find a way to make it work.

PhilD13 wrote:If I eliminate R7, R8 (replace with jumpers) could ZVP2110A and ZVN2110A fets be used? I have a few laying around.

System power is already lowish due voltage drop across D2. If you think that the voltage drop across those FETs will be negligible, they might work. But I have not had good luck with FETs; they always seem to have a fair bit of drop. But, sorry... I have no experience with those particular FETs, so I just don't know.

PhilD13 wrote:The adafruit master schematic shows a 1k pullup (shown as 1.0k in value) which I think would be more sensitive when used with a photocell? So why the 10K decision in hardware/software?

The best resistor value would depend on the range of your photoresistor. For the Adafruit CdS photoresistor, other people were using a 10k, so I tried that. My code assumed (and still assumes) a simple linear correlation between ambient brightness (voltage from the photoresistor) and display brightness. Because a 10k worked extremely well, I never tried anything else.

PhilD13 wrote:I'm currently using a 1k with your software and it works ok, but wonder if I can optimize the code somehow for the 1k?

That should be fairly straightforward. Brightness is controlled in the display_autodim(void) function in display.c:

Code: Select all
    int16_t grad_idx = (display.bright_max << 3) - (((display.photo_avg >> 8)
             * ((display.bright_max - display.bright_min) << 3)) >> 8);

The grad_idx variable controls brightness, with 0 being minimum brightness and 255 being maximum brightness. The display.photo_avg variable is a running average of the photoresistor voltage and ranges from 0 (zero volts) to 65536 (system voltage); display.bright_min is the minimum brightness as set through the menus; display.bright_max is the maximum brightness as set through the menus. If grad_idx is less than zero, it will be set to 0; if grad_idx is greater than 255, it will be set to 255.

Please excuse all the bit hacking in the code above. I wrote the code that way because it converts efficiently to AVR machine language. If anyone needs a more human-readable equivalent of that line, let me know. I'll translate.

PhilD13 wrote:Would changing the 60v zener to a higher value (max 70v) help anything?

The IV-18 specifications recommend 50v with 70v as the absolute maximum. To me, that means the tube was designed for 50v, but you can go up to 70v without blowing it. So I'd actually recommend less than 60v. I'm currently using a 56v Zener diode, and the boost circuit with Zener diode drain provide a fairly consistent 52v.

But switching to a 70v diode might help get some extra life out of a well-used IV-18 tube with fading phosphors--just make sure the corresponding Schottky diode, D3, can handle 70v.

PhilD13 wrote:EDIT: On the temp sensor. If you could compensate in software for the average temp difference between inside the case and outside the case you could probably also display temp.

That is something I'd like to look into eventually. My initial tests showed that the average temperature difference is not consistent enough to gauge ambient temperature. If the inconsistency is due to something like display brightness, then I might be able to compensate for it in software. But if the inconsistency is due to air movement in the room (i.e. whether-or-not my ceiling fan was on), it might not be possible to reliably calculate room temperature. I just don't know yet... sorry!


Thank you again, PhilD13, for all the wonderful feedback!
--John <www.jarchie.com/email>
jarchie
 
Posts: 331
Joined: Sun Jun 24, 2012 1:16 pm
Location: Santa Cruz, California, United States

Re: Another Ice Tube Clock Design for the Holidays

by PhilD13 on Tue Sep 24, 2013 7:03 pm

Your welcome on the comments.

If anyone is interested in why I think I can get similar accuracy with a DS18B20, just let me know: I'll post those preliminary data and explain my reasoning in another thread. Unfortunately, those data are sufficiently extensive and independent to warrant their own thread--at least in my opinion--so I don't want to discuss those here.
I would be interested, so start a new thread for it.

I didn't remember if 70 volts was better or not, but 60 volts is within specs and is fine with me.

Perhaps making a few holes in the back panel at the top would provide some natural circulation, decreasing the heat buildup and the effect on the sensor?

I saw the area of code but didn't fully understand it as I don't really read c very good
The photo cell I have is one with these specs.
Cell Resistance (Min) @ Dark 200 kOhms @ 10 seconds
Cell Resistance @ Illuminance 3 ~ 11 kOhms @ 10 lux
It seems to work ok if I set the min/max to the ends of what your allowing the settings to be in the firmware.
PhilD13
 
Posts: 149
Joined: Mon Sep 10, 2012 12:05 pm

Re: Another Ice Tube Clock Design for the Holidays

by PhilD13 on Tue Sep 24, 2013 8:56 pm

About the boards, I was just going to order them from the shared link on OSH Park, along with a couple other things.
PhilD13
 
Posts: 149
Joined: Mon Sep 10, 2012 12:05 pm

Re: Another Ice Tube Clock Design for the Holidays

by jarchie on Thu Sep 26, 2013 6:49 pm

PhilD13 wrote:I would be interested [in software temperature compensation], so start a new thread for it.

I was looking for an excuse to post those. :-)

PhilD13 wrote:Perhaps making a few holes in the back panel at the top would provide some natural circulation, decreasing the heat buildup and the effect on the sensor?

I'll try that when I have some time.

Also, the regulator gets warm, but is still comfortable to touch. Eventually, I'll also try diverting some of that heat outside the case. I'm thinking about putting a hole in the case to match the regulator hole and diverting the heat through a brass screw attached to a largish washer on the outer side of the case.

PhilD13 wrote:I saw the area of code but didn't fully understand it...

That particular area is packed with bit hacking, compiler macros, and AVR-specific extensions to C--all of which make it quite difficult to understand.

The idea is simple, however. Display brightness varies from a minimum of 0 (barely visible) to a maximum of 10 (brightest possible). For autodimming, brightness is set by a linear relationship:

b_auto = b_min + (b_max - b_min) * (1 - v_photo / v_system)

The user sets the minimum autodim brightness (b_min) and maximum autodim brightness (b_max) through the clock menus. The automatic display brightness (b_auto) is updated from the photoresistor voltage (v_photo) which ranges from 0 volts to system voltage (v_system). So if photoresistor voltage is at system voltage, the display is at the user-set minimum brightness. If the photoresistor voltage is 0, the display is at the user-set maximum brightness. Anything between those extremes is linearly interpolated.

PhilD13 wrote:The adafruit master schematic shows a 1k pullup (shown as 1.0k in value) which I think would be more sensitive when used with a photocell? So why the 10K decision in hardware/software?

EDIT: I removed my previous description of photoresistor pull-up choice because I made an error in reasoning. Oops!

I'll assume a typical value of 6k at 10 lux for a CdS photoresistor. According to the photoresistor datasheets referenced by Adafruit the relationship between brightness and resistance is linear on a log-scale with a slope of -0.6 log-ohms/log-lux: log(ohms) = 4.4 - 0.6 * log(lux). The photoresistor and pull-up combination forms a voltage divider, with the output of that divider being fed to the ATmega328P analog to digital converter (ADC). In my firmware, the photo_avg variable is a 16-bit running average of the ADC output and is proportional to the input voltage: photo_avg = photo-ohms / (photo-ohms + pull-up-ohms) * (2^16 - 1).

photo-sens.jpg
photo-sens.jpg (19.77 KiB) Viewed 1321 times

The above graph shows the effect of various pull-up resistor choices on brightness measurement; the list below describes my interpretation of the log-lux scale.

  • -1: outdoors at night with bright stars and new moon
  • 0: outdoors at night with a clear sky and full moon
  • 1: outdoors during sunrise when the colors of objects are easily discernible
  • 2: indoors with reasonably good lighting
  • 3: indoors near a sunny window
  • 4: outdoors during midday with indirect sunlight
  • 5: outdoors during midday with direct outdoor sunlight
I've noticed people using 10k, 1k, and 20k pull-up resistors for the autodimmer mod. Because electrical noise from the boost converter limits ADC accuracy, I want excellent brightness discrimination across the entire indoor brightness range (log-lux between -1 and 3, with 0 to 2 being most important). A 10k seems to do a good job, although 5.6k is probably better. But a 1k pull-up does not provide good discrimination in the low-light range.

It's certainly possible hack the xmas-icetube firmware to make the 1k work better across the indoor brightness range, but switching to a larger resistor should be easier and provide better results.

PhilD13 wrote:About the boards, I was just going to order them from the shared link on OSH Park, along with a couple other things.

Cool. Although it's more expensive for you to order three boards, thank you for saving me the trouble of preparing and mailing a package. :-)
--John <www.jarchie.com/email>
jarchie
 
Posts: 331
Joined: Sun Jun 24, 2012 1:16 pm
Location: Santa Cruz, California, United States

Re: Another Ice Tube Clock Design for the Holidays

by PhilD13 on Mon Sep 30, 2013 3:44 pm

Thanks for the explanation on the photocell. The photocell being used is the PVD-8001 which is the first datasheet on the referenced Adafruit page.
While the 1k works good enough, I am going to try a 5.6K resistor and see what the response difference is with that on the next board I build. The environment varies greatly between a dark room, better than average (office) indoor lighting, and a combo natural + artificial lit room.

I appreciate the offer made to send just one of your boards but wanted a couple to play with and was already ordering a modified clock board that I can install either a FET or a transistor/resistor for Q3 without having to solder the resistor to the transistor leg. I want to make sure the board works before I share it. I plan on putting together a couple tube boards that I can plug/unplug from various boards without having to take the clock I use apart all the time. Something I found that will make ordering boards cheaper provided you only really need one board such as the main board, is to separate the main board and the tube board and upload to different OSH projects. If you don't need both boards you can save money, and you also don't have to cut the two boards apart.
PhilD13
 
Posts: 149
Joined: Mon Sep 10, 2012 12:05 pm

Re: Another Ice Tube Clock Design for the Holidays

by jarchie on Mon Oct 07, 2013 7:35 pm

In the xmas-icetube git repository, the xmas-b code branch has been merged back into master. The master branch now contains the most recent code for both the Adafruit Ice Tube Clock as well as the xmas board revision.

PhilD13 wrote:Thanks for the explanation on the photocell.

You're welcome!

PhilD13 wrote:The photocell being used is the PVD-8001 which is the first datasheet on the referenced Adafruit page.
While the 1k works good enough, I am going to try a 5.6K resistor and see what the response difference is with that on the next board I build. The environment varies greatly between a dark room, better than average (office) indoor lighting, and a combo natural + artificial lit room.

I'm using the same photoresistor and will also try a 5.6K on my next build. For now, I've updated the schematic to specify a 5.6K resistor and PVD-8001 photoresistor.

PhilD13 wrote:Something I found that will make ordering boards cheaper provided you only really need one board such as the main board, is to separate the main board and the tube board and upload to different OSH projects.

Good idea. I've split the boards into two separate projects.

PhilD13 wrote:If you don't need both boards you can save money, and you also don't have to cut the two boards apart.

I wondered if that would be a problem. When I ordered my first design (revision A) from OSH park, they didn't separate main and side PCB, but there was a tiny notch in the side of the board as if the cutting tool "tried" to cut the boards apart. OSH Park did cut the boards apart for my second design (revision B), but the cut was slightly wider than I would have liked.

For revision C, I've done schematic updates, separated the boards into two projects, labeled the GPS/TCXO expansion pins on the bottom silkscreen, and made tiny adjustments to the board size and ground flood. These schematics and board updates are now available on GitHub, but I have not yet tested the new design.
--John <www.jarchie.com/email>
jarchie
 
Posts: 331
Joined: Sun Jun 24, 2012 1:16 pm
Location: Santa Cruz, California, United States

Re: Another Ice Tube Clock Design for the Holidays

by PhilD13 on Tue Oct 08, 2013 12:37 am

I got the rev. B boards today and they were separated and will work fine, though it is very close to not. OSH needs a separation space of 100 mils (.01in) as that is the smallest mill bit the board house uses for cutting. In order to separate the boards properly you will need at least that much space between the two board edges. Since I'm still using the free version of Eagle, I could not make that space wider, so I separated the boards which I decided was a good idea anyway. As far as width, if done properly, you can make a board as wide as 1.052 and it will still fit the clock case from Adafruit.

Something I did on my copy of your board (which I did not order any of) and my boards besides separate the two boards was move the pads for the photocell so they are parallel with the board edge. This makes sense and makes installing the photocell a lot easier. On your board, just swing R8 up at a 46 degree angle and move the upper photocell pad down. Adjust and route accordingly.


Though I would love to make one, I'm not sure when I will get one of the boards built, been busy lately and I want to build a project I sort of designed to see if it works first, but I have the parts for both clocks (yours and my Q3 transistor version inspired by Russell 27 and the discussions on the FET). Once my board is built and tested it will be available on GitHub and on OSH Park for any interested.
PhilD13
 
Posts: 149
Joined: Mon Sep 10, 2012 12:05 pm

Re: Another Ice Tube Clock Design for the Holidays

by jarchie on Tue Oct 08, 2013 2:26 am

PhilD13 wrote:I got the rev. B boards today and they were separated and will work fine, though it is very close to not.

My rev. B boards arrived the same way, but once I soldered and assembled everything, I was delighted with the end result. (I never built rev. A, which had a design flaw.)

PhilD13 wrote:OSH needs a separation space of 100 mils (.01in) as that is the smallest mill bit the board house uses for cutting.

I didn't know that... definitely useful information.

PhilD13 wrote:In order to separate the boards properly you will need at least that much space between the two board edges. Since I'm still using the free version of Eagle, I could not make that space wider, so I separated the boards which I decided was a good idea anyway. As far as width, if done properly, you can make a board as wide as 1.052 and it will still fit the clock case from Adafruit.

The version I'm using has the same restrictions, and I didn't think to divide the clock into two projects, until you suggested it.

PhilD13 wrote:Something I did on my copy of your board (which I did not order any of) and my boards besides separate the two boards was move the pads for the photocell so they are parallel with the board edge. This makes sense and makes installing the photocell a lot easier. On your board, just swing R8 up at a 46 degree angle and move the upper photocell pad down. Adjust and route accordingly.

I'll add this to my idea list. After revision C, I'm planning to take a break from board design, but I'll get back to it eventually.

PhilD13 wrote:Though I would love to make one, I'm not sure when I will get one of the boards built, been busy lately and I want to build a project I sort of designed to see if it works first, but I have the parts for both clocks (yours and my Q3 transistor version inspired by Russell 27 and the discussions on the FET). Once my board is built and tested it will be available on GitHub and on OSH Park for any interested.

There's certainly no rush, but I'll enjoy seeing what you've done whenever you have time to build and post it. :-)

And thank you again, PhilD13, for the extensive feedback!
--John <www.jarchie.com/email>
jarchie
 
Posts: 331
Joined: Sun Jun 24, 2012 1:16 pm
Location: Santa Cruz, California, United States

Re: Another Ice Tube Clock Design for the Holidays

by jarchie on Tue Oct 15, 2013 8:26 pm

I received the Rev. C boards this weekend and they work fine. (The Rev. C design can be downloaded from GitHub.) The only noteworthy differences from Rev. B are that the main and side board are separate projects and the bottom silkscreen now has labels for the expansion holes. On my last build, I tried the GPS mod and hardware TCXO mod using the expansion holes; both mods work fine. I also used a 5.6k pull-up for the photoresistor; the 5.6k is a definite improvement to autodimming response, albeit a minor one.

Unfortunately, I discovered an issue with the to-spec hack used in the xmas board revisions: voltage across the VFD filament is far below the 5 volts required by spec (details). But the software temperature compensated timekeeping is, anecdotally, exceeding my expectations for accuracy (details).

Given the issue with the to-spec hack, I might try to do one more board revision before Christmas...

PhilD13 wrote:If I eliminate R7, R8 (replace with jumpers) could ZVP2110A and ZVN2110A fets be used? I have a few laying around.

Please ignore my prior comments regarding these FETs. I now suspect that these FETs would be significantly better choices than my choice of BJT transistors. But I'll play with these FETs and let you know!
--John <www.jarchie.com/email>
jarchie
 
Posts: 331
Joined: Sun Jun 24, 2012 1:16 pm
Location: Santa Cruz, California, United States

Re: Another Ice Tube Clock Design for the Holidays

by jarchie on Thu Oct 17, 2013 12:20 pm

PhilD13 wrote:If I eliminate R7, R8 (replace with jumpers) could ZVP2110A and ZVN2110A fets be used? I have a few laying around.

These FETs do work better than the BJTs! I used the ZVP2110As for Q4 and Q6 and the ZVN2110As for Q5 and Q7. The FETs should be installed backwards from the silkscreen for Rev. B or Rev. C (photo attached). In that configuration, voltage across the filament is 3.64 volts, still well below spec but a major improvement over the original Adafruit design.
Attachments
xmas-fet-mod.jpg
xmas-fet-mod.jpg (37.98 KiB) Viewed 1032 times
--John <www.jarchie.com/email>
jarchie
 
Posts: 331
Joined: Sun Jun 24, 2012 1:16 pm
Location: Santa Cruz, California, United States

Re: Another Ice Tube Clock Design for the Holidays

by jarchie on Wed Nov 06, 2013 11:48 pm

I apologize for the fourth reply to myself in this thread... In my defense, the flaw in my design was concurrently discussed in another thread... but I wanted to post in this thread that the issue has, to my knowledge, been resolved.

The workaround (described in the other thread) eliminates the need for voltage regulators in the TO-220 packages which, I believe, gives the clock a cleaner look:

Image
Image


Okay... now for some unpleasantries...

To those who have already emailed me for parts or "kits" of my xmas-icetube design: I will honor everything I promised in my personal emails to you. I will send everything promised.

To everyone else: If you email me asking for a "kit," my answer will be "no"...unless of course I already know you as a friend. I apologize for the inconvenience, but I am not in the business of providing kits or parts. :-( I realize that there are some known issues in the Adafruit Ice Tube Clock kit, but be patient. Adafruit has demonstrated support for open hardware, and I'm sure they will revise the Ice Tube Clock kit in time. Be patient.

EDIT: Everything necessary to build an xmas-icetube clock is described on GitHub. That includes a full list of parts, where those parts can be purchased or made to order, and general assembly tips. Building a single clock would be quite expensive due to minimum order quantities, shipping charges from multiple venders, and the added cost of small quantity orders. But if you can find two other people who would like to build their own clocks, parts for three clocks should run around $100 per clock (very rough estimate).

I am still willing to mail ATMEGA328Ps programed with my xmas-icetube firmware (for ~$3 + shipping), since that's the only part that cannot simply be bought. But programming chips is a useful skill, so learning to program chips yourself is preferable. The only extra tool you need is a programmer like the Adafruit USBtinyISP.
--John <www.jarchie.com/email>
jarchie
 
Posts: 331
Joined: Sun Jun 24, 2012 1:16 pm
Location: Santa Cruz, California, United States