0

Another Ice Tube Clock Design for the Holidays
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

Re: Another Ice Tube Clock Design for the Holidays

by jarchie on Tue Jul 23, 2019 4:48 pm

adafruit_support_bill wrote:Thanks as always jarchie for generously sharing your expertise with these clocks.

Glad to help. And I appreciate being allowed to use these forums even though the Ice Tube Clock is a discontinued Adafruit product. So thanks to you and Adafruit also!

nix_clk_dd wrote:Maybe this is more of an advanced question, but how would I determine the test points by looking at the schematic? Just making some guesses: +9V is the input and +UB is the output?

Correct. +UB is the right place to get the 50-60 volts. The other end of the multimeter would be connected to the ground.

nix_clk_dd wrote:So the test points would be between D3/D5 and some other spot? Why does C5 or C6 not come into play?

I only mentioned D5 because it was an easy place to make the measurement. You could have just as easily taken the measurement across C5 or C6, because one end is connected to +UB and the other to GND--just like D5. Or you could have gotten the +UB from the cathode of D3 or the VBB pin on the MAXIM chip. The GND could have come from any ground connection in the circuit.

EDIT: Ah, I see adafruit_support_bill beat me to this. He's 100% right about my reasoning on D5, by the way.

jarchie
 
Posts: 591
Joined: Sun Jun 24, 2012 2:16 pm
Location: Santa Cruz, California, United States

Re: Another Ice Tube Clock Design for the Holidays

by nix_clk_dd on Wed Jul 24, 2019 4:02 pm

Thanks again for the tips!

Getting close now. With the VFD tube connected, I'm getting extremely low brightness (even in a dark room). Is this normal if I've compiled the code with the light sensor feature enabled and have yet to install the buttons, battery backup, and light sensor? Still measuring ~56.8V across D5 with the tube connected.
I've also noticed a loud whining noise coming from the circuit that can be heard from the other side of the room. I think this is normal because my IN-14 tube clock also "whines", but it is faint and you can only hear it when you are within one foot of the clock.

It's very difficult to see from the photo, but try the video. You should be able to hear the whining and see the lit segments change around.

https://youtu.be/ujscsXWDNRI

Image

nix_clk_dd
 
Posts: 36
Joined: Tue May 21, 2019 2:15 pm

Re: Another Ice Tube Clock Design for the Holidays

by jarchie on Wed Jul 24, 2019 4:51 pm

nix_clk_dd wrote:Getting close now. With the VFD tube connected, I'm getting extremely low brightness (even in a dark room). Is this normal if I've compiled the code with the light sensor feature enabled and have yet to install the buttons, battery backup, and light sensor?

Yes, this is normal. The firmware defaults to using the light sensor to control brightness, and if the sensor is not connected, the clock will "think" it is in a completely dark room. When you install the buttons, you will be able to manually set a fixed brightness or go back to the automatic brightness control through the menus.

nix_clk_dd wrote:I've also noticed a loud whining noise coming from the circuit that can be heard from the other side of the room. I think this is normal because my IN-14 tube clock also "whines", but it is faint and you can only hear it when you are within one foot of the clock.

This is also normal for some tubes and is due to driving the filament with AC. If the whine is at all bothersome, check out the "to-spec filament driver method" section of config.h. There are options to reduce or eliminate the sound. The best way to reduce the sound is probably to play with different values for FILAMENT_FREQUENCY_DIV. If I recall correctly, one user changed the value to the maximum possible (255) and was happy with the result for what sounded like a particularly noisy tube.

EDIT: Even though a whine is normal, it usually isn't loud for the dozen or so tubes I've seen used in this circuit. So if I had a tube that could be heard more than a couple feet away from the clock, I'd definitely, play with FILAMENT_FREQUENCY_DIV at some point.

nix_clk_dd wrote:It's very difficult to see from the photo, but try the video. You should be able to hear the whining and see the lit segments change around.

Excellent! And congratulations on getting everything to work thus far!


By the way, adafruit_support_bill's link to the Adafruit design reminded me that the original Adafruit docs contain an excellent design section that is very helpful in understanding the inner workings of this clock. Almost all of this explanation still applies to the xmas hardware revision.

jarchie
 
Posts: 591
Joined: Sun Jun 24, 2012 2:16 pm
Location: Santa Cruz, California, United States

Re: Another Ice Tube Clock Design for the Holidays

by nix_clk_dd on Fri Jul 26, 2019 12:40 am

jarchie wrote:Yes, this is normal. The firmware defaults to using the light sensor to control brightness, and if the sensor is not connected, the clock will "think" it is in a completely dark room. When you install the buttons, you will be able to manually set a fixed brightness or go back to the automatic brightness control through the menus.

That makes sense. I found that the best settings for automatic brightness are a minimum of "2" and maximum of "8". Would "10" be more damaging to the tube over time?
At brightness level "1', it seems that the G segments are dimmer than most of the others.

.AAA.
F.....B
F.....B
.GGG.
E.....C
E.....C
.DDD.....H


jarchie wrote:This is also normal for some tubes and is due to driving the filament with AC. If the whine is at all bothersome, check out the "to-spec filament driver method" section of config.h. There are options to reduce or eliminate the sound. The best way to reduce the sound is probably to play with different values for FILAMENT_FREQUENCY_DIV. If I recall correctly, one user changed the value to the maximum possible (255) and was happy with the result for what sounded like a particularly noisy tube.

EDIT: Even though a whine is normal, it usually isn't loud for the dozen or so tubes I've seen used in this circuit. So if I had a tube that could be heard more than a couple feet away from the clock, I'd definitely, play with FILAMENT_FREQUENCY_DIV at some point.

Thanks! I should have looked into the documentation a bit more :)
I will try the tweak this weekend and maybe figure out the correct voltage to reduce some of the red glow as seen in the photo I've attached below.

Can I overwrite the firmware using the same "make install-all" commands, or do I need to erase the microcontroller first?

jarchie wrote:Excellent! And congratulations on getting everything to work thus far!

By the way, adafruit_support_bill's link to the Adafruit design reminded me that the original Adafruit docs contain an excellent design section that is very helpful in understanding the inner workings of this clock. Almost all of this explanation still applies to the xmas hardware revision.

Of course it's mostly thanks to you and the Adafruit team. The help is very much appreciated!

Installed on a temporary bamboo plywood stand :)

Image
Image

Edit: Yikes, I didn't notice that huge blob of solder on one of the tube wires.

nix_clk_dd
 
Posts: 36
Joined: Tue May 21, 2019 2:15 pm

Re: Another Ice Tube Clock Design for the Holidays

by jarchie on Fri Jul 26, 2019 2:11 am

That's a very beautiful clock!

nix_clk_dd wrote:I've also noticed a loud whining noise coming from the circuit that can be heard from the other side of the room. I think this is normal because my IN-14 tube clock also "whines", but it is faint and you can only hear it when you are within one foot of the clock.

While tube whine is normal and does not indicate a problem, I've only been able to hear it with my ear close to a tube. Since you describe the noise as being loud, it's probably worth tweaking some configuration settings.

The other person who told me about having a noisy IV-18 tube was forum user Russell 27. Russell built an xmas hardware revision clock and even created his own surface mount redesign, so he knows this circuit and tube inside and out. Several years ago, he wrote the following in an email to me regarding the noisy tube, which I am reposting here with permission:

Russell 27 wrote:For the past several days I've used a frequency of 60 hz, [215 division] in your clock. I found this to be quite quiet. On the flip, a frequency of 6K5, [2 division] has a very pronounced resonance. Since I have a quantity of tubes, I tested several driven by your filament driver at the 60 hz. One was almost inaudible. I can't say I've pin pointed a definite physical trait, but the filament tensioners on the quiet tube have a slight difference. Generally the tensioners are not perfectly parallel, but on this particular tube, the parallel variance between the two is greater, which makes the connection point a slightly different axis.

You can make this change by uncommenting and setting the value of the FILAMENT_FREQUENCY_DIV macro in config.h and reprogramming the clock:

Code: Select all | TOGGLE FULL SIZE
#define FILAMENT_FREQUENCY_DIV 215
I have one tube where I can hear a slight whine from about one foot away. It's the noisiest of three tubes that I have access to right now. If I make this change, I can barely hear anything when I put my ear directly to the tube. With vacuum fluorescent displays, lower alternating current frequencies sometimes cause flicker, but I have never noticed any flicker on the xmas revision. So fussing with this macro is definitely worth a try.


And as a last resort, try defining the FILAMENT_CURRENT_DC_FWD macro (or the FILAMENT_CURRENT_DC_REV) macro to drive the tube filament with direct current. This will completely eliminate any noise from the alternating current. On vacuum fluorescent displays, direct current creates a brightness gradient, but the IV-18 is rather resistant to this effect when the grids and digits are driven with 50-60 volts, as in the xmas redesign. So if the noise is still bothersome after fussing with FILAMENT_FREQUENCY_DIV, I would recommend uncommenting one of the direct current macros:

Code: Select all | TOGGLE FULL SIZE
#define FILAMENT_CURRENT_DC_FWD
// #define FILAMENT_CURRENT_DC_REV
This is probably more detail than you need, but I hope it helps reduce the noise.


nix_clk_dd wrote:That makes sense. I found that the best settings for automatic brightness are a minimum of "2" and maximum of "8". Would "10" be more damaging to the tube over time?

Under normal usage, these tubes become less bright over time due to phosphor degradation. The brighter the display, the faster the degradation. Setting the brightness to range from 2 to 8 will give you some room to increase the brightness as the tube becomes dimmer. In a room that is not too bright, I would guess a tube could last for 10 years.

nix_clk_dd wrote:Can I overwrite the firmware using the same "make install-all" commands, or do I need to erase the microcontroller first?

This will work; FLASH erasure will happen automatically. But since you have everything else configured, you only need to do a "make install-flash". That will be faster and will leave your EEPROM alone (mostly menu settings).

nix_clk_dd wrote:I will try the tweak this weekend and maybe figure out the correct voltage to reduce some of the red glow as seen in the photo I've attached below.

The reduced voltage options operate by rapidly turning the filament on and off which can also create whine. This is best done at high frequency to prevent the filament from cooling off too much between pulses. If the filament gets too cool during operation, it will wear faster and might not last as long. If you do wind up using these options, I would suggest only using the FILAMENT_VOLTAGE_3_3 and keeping FILAMENT_FREQUENCY_DIV to a smallish number. To ensure tube longevity and eliminate whine, the filament glow at 5 volts might be worth tolerating. After all, it's part of the charm of these tubes. :-)


Good luck and happy hacking!

jarchie
 
Posts: 591
Joined: Sun Jun 24, 2012 2:16 pm
Location: Santa Cruz, California, United States

Re: Another Ice Tube Clock Design for the Holidays

by nix_clk_dd on Fri Jul 26, 2019 12:59 pm

jarchie wrote:To ensure tube longevity and eliminate whine, the filament glow at 5 volts might be worth tolerating. After all, it's part of the charm of these tubes. :-)
Good luck and happy hacking!

I do admit the red glow is actually pretty cool. It's really only visible when the room is dark and I might not even try to minimize it.
Once again, thanks for all of the information. I will add another post to this thread when I get around to changing the firmware.

If it helps anyone, I made a reference sheet (attached) to go along with the clock building instructions. A couple times I missed a component from the schematics :)

Edit: Using the same USB port on the computer I originally flashed the code with returns the error:
Code: Select all | TOGGLE FULL SIZE
MacBook-Pro-2:firmware rbadm$ make install-flash
avrdude -B 4 -P usb -c usbtiny -p atmega328p   -U flash:w:icetube_flash.hex:i
avrdude: Error: Could not find USBtiny device (0x1781/0xc9f)

avrdude done.  Thank you.

Makefile:144: recipe for target 'install-flash' failed
make: *** [install-flash] Error 1
Same error on a 2nd computer.
Process (same as my first firmware flash):
1. Start with VFD and external power disconnected.
2. USB VCC jumper installed on the USBTINYISP. ICETUBE jumper not installed. Also tried with USB VCC jumper disconnected.
3. Connect ISP header to 6-pin cable.
4. Connect external power.
5. Run command.
Attachments
IV-18 Build Steps.pdf
(69.85 KiB) Downloaded 11 times

nix_clk_dd
 
Posts: 36
Joined: Tue May 21, 2019 2:15 pm

Re: Another Ice Tube Clock Design for the Holidays

by jarchie on Fri Jul 26, 2019 9:38 pm

nix_clk_dd wrote:Using the same USB port on the computer I originally flashed the code with returns the error: avrdude: Error: Could not find USBtiny device (0x1781/0xc9f)

That's strange. It looks like avrdude does not see the programmer attached to your computer. This is the same error you would see if the programmer was not connected to the computer at all. Try connecting the programmer to the computer but do not attach the programmer to the board. Do you see the USBtinyISP in the System Report tool?

[Apple symbol in upperleft of screen] -> ["About this Mac"] -> ["System Report..."]

It might be worth connecting the programmer to a different USB port or connecting through a USB 1.0 or 2.0 hub if you have one lying around. Some keyboards or monitors have hubs built in. As far as programming goes, I would suggest programming with the USB VCC jumper removed. With this jumper installed, it is remotely possible that the USBtinyISP is overloaded by trying to supply too much power to the clock when the clock is unplugged.
Attachments
Screenshot-USBtinyISP.png
USBtinyISP in System Report
Screenshot-USBtinyISP.png (133.96 KiB) Viewed 158 times

jarchie
 
Posts: 591
Joined: Sun Jun 24, 2012 2:16 pm
Location: Santa Cruz, California, United States

Re: Another Ice Tube Clock Design for the Holidays

by nix_clk_dd on Fri Jul 26, 2019 10:21 pm

jarchie wrote:
nix_clk_dd wrote:Using the same USB port on the computer I originally flashed the code with returns the error: avrdude: Error: Could not find USBtiny device (0x1781/0xc9f)

That's strange. It looks like avrdude does not see the programmer attached to your computer. This is the same error you would see if the programmer was not connected to the computer at all. Try connecting the programmer to the computer but do not attach the programmer to the board. Do you see the USBtinyISP in the System Report tool?

[Apple symbol in upperleft of screen] -> ["About this Mac"] -> ["System Report..."]

It might be worth connecting the programmer to a different USB port or connecting through a USB 1.0 or 2.0 hub if you have one lying around. Some keyboards or monitors have hubs built in. As far as programming goes, I would suggest programming with the USB VCC jumper removed. With this jumper installed, it is remotely possible that the USBtinyISP is overloaded by trying to supply too much power to the clock when the clock is unplugged.


The computer sees the "USBtiny" device on both USB 3.0 ports and with a USB 2.0 hub connected.
For it to be recognized in System Report, I need to have (1) the VCC jumper installed or (2) VCC jumper removed and external power connected.

Not sure why it worked perfectly the first time I flashed the firmware :\

nix_clk_dd
 
Posts: 36
Joined: Tue May 21, 2019 2:15 pm

Re: Another Ice Tube Clock Design for the Holidays

by nix_clk_dd on Sat Jul 27, 2019 1:13 pm

I gave it another try on Windows, this time after installing the Adafruit drivers.
It can see the USBtiny but returns this error:
Code: Select all | TOGGLE FULL SIZE
$ make install-flash
avrdude -B 4 -P usb -c usbtiny -p atmega328p   -U flash:w:icetube_flash.hex:i

avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.


avrdude done.  Thank you.

make: *** [install-flash] Error 1
I have no explanation why it randomly stopped working on OS X; I still can't get it to detect the USBtiny despite being visible in System Information.

nix_clk_dd
 
Posts: 36
Joined: Tue May 21, 2019 2:15 pm

Re: Another Ice Tube Clock Design for the Holidays

by jarchie on Sat Jul 27, 2019 4:23 pm

I just updated my Apple to MacOS 10.14.6, and am now seeing the same error from avrdude ("Could not find USBtiny device"), so it must be some incompatibility introduced in the update. I haven't tried to find a solution yet, but wanted to let you know that you're not alone here.

jarchie
 
Posts: 591
Joined: Sun Jun 24, 2012 2:16 pm
Location: Santa Cruz, California, United States

Re: Another Ice Tube Clock Design for the Holidays

by nix_clk_dd on Sat Jul 27, 2019 4:43 pm

jarchie wrote:I just updated my Apple to MacOS 10.14.6, and am now seeing the same error from avrdude ("Could not find USBtiny device"), so it must be some incompatibility introduced in the update. I haven't tried to find a solution yet, but wanted to let you know that you're not alone here.


I guess it's possible that the update broken something because I believe that I updated OS X between flashing the firmware for the first time and trying a second time.
Still odd that Windows 10 does not want to flash when I use cygwin64. "avrdude: initialization failed, rc=-1"

I'll keep trying things :)

nix_clk_dd
 
Posts: 36
Joined: Tue May 21, 2019 2:15 pm

Re: Another Ice Tube Clock Design for the Holidays

by jarchie on Sat Jul 27, 2019 5:10 pm

For reference, "initialization failed, rc=-1" is the error I usually see when I forget to connect the programmer to a board or when I forget to power a board. It indicates that the USBtinyISP was unable to initialize the microcontroller. So at least your Windows system recognizes the USBtinyISP and is communicating with it. My guess is that the error on Windows is due to a different issue.

On the Windows side, you might try to slow down the programming speed. (Another user once told me this worked for him.) The line to change is listed in "Other Programming Failures" in the firmware/README .

I'll look into the MacOS side of things when I have some time... later tonight maybe.

jarchie
 
Posts: 591
Joined: Sun Jun 24, 2012 2:16 pm
Location: Santa Cruz, California, United States

Re: Another Ice Tube Clock Design for the Holidays

by nix_clk_dd on Sat Jul 27, 2019 9:31 pm

jarchie wrote:For reference, "initialization failed, rc=-1" is the error I usually see when I forget to connect the programmer to a board or when I forget to power a board. It indicates that the USBtinyISP was unable to initialize the microcontroller. So at least your Windows system recognizes the USBtinyISP and is communicating with it. My guess is that the error on Windows is due to a different issue.

On the Windows side, you might try to slow down the programming speed. (Another user once told me this worked for him.) The line to change is listed in "Other Programming Failures" in the firmware/README .

I'll look into the MacOS side of things when I have some time... later tonight maybe.


Still no luck:
Code: Select all | TOGGLE FULL SIZE
$ make install-flash
avrdude -B 25 -P usb -c usbtiny -p atmega328p   -U flash:w:icetube_flash.hex:i
avrdude: Error: Could not find USBtiny device (0x1781/0xc9f)

avrdude done.  Thank you.

make: *** [install-flash] Error 1
I can't help but think that I'm missing something obvious (I wouldn't be surprised).
1. Should the piezo speaker still beep once when I connect the external power after connecting the ISP?
2. Is it OK to leave the button cell battery in the clock during the programming process?
3. Do the jumper pins on the clock PCB have anything to do with the programming?

Once again, I really appreciate you taking the time to help and I hope the questions aren't too bothersome.

nix_clk_dd
 
Posts: 36
Joined: Tue May 21, 2019 2:15 pm

Re: Another Ice Tube Clock Design for the Holidays

by jarchie on Sat Jul 27, 2019 10:18 pm

I still haven't had time to look into this yet, but just some quick replies:

nix_clk_dd wrote:1. Should the piezo speaker still beep once when I connect the external power after connecting the ISP?

The xmas firmware will only beep when power is restored after a microcontroller reset. Waking up from sleep will not trigger a beep. Programming will trigger an external reset, so the clock will beep after programming. Sometimes attaching or disconnecting the programmer can trigger an external reset.

If you're curious, a full list of reset conditions is listed in the firmware/README under "Reset and Diagnostic Messages".

nix_clk_dd wrote:2. Is it OK to leave the button cell battery in the clock during the programming process?

Leaving the battery in won't hurt anything but don't forget to plug in the clock during programming. The battery will not always provide sufficient power for chip programming which can result in an incorrectly programed chip. And accidentally programming while on battery power will drain the battery pretty quick.

nix_clk_dd wrote:3. Do the jumper pins on the clock PCB have anything to do with the programming?

Yes, but this jumper is not really useful for the USBtinyISP, so leave the jumper off.

Installing that jumper tricks the xmas firmware into always staying asleep. This allows you to power the clock through the programmer instead of plugging the clock into an outlet. Without the jumper installed, the clock might try to run on USB power from the programmer. This can overload the programmer. For the USBtinyISP, this will not damage the programmer, but other programmers are more delicate. The AVR Dragon was a $100-$200 programmer that could be turned into a paperweight this way...

nix_clk_dd wrote:Once again, I really appreciate you taking the time to help and I hope the questions aren't too bothersome.

I'm happy to help, although you've currently got me puzzled. :-)

jarchie
 
Posts: 591
Joined: Sun Jun 24, 2012 2:16 pm
Location: Santa Cruz, California, United States

Re: Another Ice Tube Clock Design for the Holidays

by jarchie on Sun Jul 28, 2019 12:42 am

It turns out that I only get the "Could not find USBtiny device" error when I use the version of avrdude that comes with CrossPack. When I use the version that comes with MacPorts, everything works fine. So it looks like the MacOS 10.14.6 update only broke the CrossPack-supplied avrdude, and the USBtinyISP still works.

Perhaps the older avrdude is attempting to access the USBtinyISP in a way that is no longer supported by OS X. If I don't find a workaround, I might have to switch to the MacPorts AVR tools. Oh well.

jarchie
 
Posts: 591
Joined: Sun Jun 24, 2012 2:16 pm
Location: Santa Cruz, California, United States

Please be positive and constructive with your questions and comments.