Black Lives Matter - Action and Equality. ... Adafruit is open and shipping.
0

Yet another Ice Tube Clock Problem...
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

Yet another Ice Tube Clock Problem...

by gmulhollan on Sun Jul 27, 2014 8:10 pm

Hi Adafruit-Folks,
I just got my clock soldered up. It passed the voltage regulator, HV boost and 'beep' test. I then did the rest of the assembly and it now mostly works, but with two 'extras'. First the good: it responds to push buttons, can be set for time, date, display brightness, etc. The bad: now instead of a simple beep at power up (even if I pull the MAX6921) I get a two-tone modulation out of the piezo. This persists regardless of alarm on-ness or off-ness. Also, the bottom display segment (only when another part of the segment is lit) comes on, so a 1 appears like an inverted "ell" or "L", however you care to state it. Clearly the boost voltage is there and controllable. As the piezo only derives its drive from the microcontroller, I am at a loss to understand its behavior unless the microprocessor went partially bad, as the sound is sort of a PWM-sounding rather than a constant tone (I have not put a scope on it yet to see what the drive actually looks like). I have pulled the microprocessor and checked the socket for spurious connections to anything else (esp. pins 15 and 16, the two piezo drives). My guess is that a couple of lines in the microcontroller went bad. Is there anything else anyone can think to check before I go to the effort to burn a new microcontroller chip? I am guessing I can get the firmware from one of the ice tube clock 'hack' sites. Thanks in advance for any suggestions. I don't see any bridges, etc. Oh yes, I have re-checked the supply and still get 5V regulated out and about 62V out as 'raw' HV, so both are good.
Cheers,
Greg M.
gmulhollan
 
Posts: 4
Joined: Sun Jul 27, 2014 7:55 pm

Re: Yet another Ice Tube Clock Problem...

by adafruit_support_bill on Mon Jul 28, 2014 5:50 am

The spurious display segment sounds like a short somewhere. It could in the tube itself or elsewhere. If you post some photos of the boards, we can take a look for anything visible.

The piezo problem is one I haven't heard of before. Without actually listening to it, it is difficult to speculate on possible causes. If you do have access to a scope, that might tell us something about the cause. One possibility might be something loose in the piezo itself that is resonating.

adafruit_support_bill
 
Posts: 78209
Joined: Sat Feb 07, 2009 10:11 am

Re: Yet another Ice Tube Clock Problem...

by gmulhollan on Mon Jul 28, 2014 8:26 am

Below are the requested photos. Not so great, I will try to do better when I get home this evening and have more time. I just checked with a 2nd power supply and same 'noise' from the piezo. I will have a look at the tube+board later since I want to find the first fault in the chain if possible. I have gone over the circuit board with an eye-loop and find no bridges. Plenty of rosin, but no bridges. Thanks for the help.
Regards,
Greg M.
FrontCropped.jpg
FrontCropped.jpg (94.3 KiB) Viewed 768 times

BackCropped.jpg
BackCropped.jpg (323.03 KiB) Viewed 768 times
gmulhollan
 
Posts: 4
Joined: Sun Jul 27, 2014 7:55 pm

Re: Yet another Ice Tube Clock Problem...

by adafruit_support_bill on Mon Jul 28, 2014 8:41 am

No obvious problems there. It looks like a pretty clean build. Can we get a shot of the solder-side of the tube board also?

adafruit_support_bill
 
Posts: 78209
Joined: Sat Feb 07, 2009 10:11 am

Re: Yet another Ice Tube Clock Problem...

by gmulhollan on Mon Jul 28, 2014 8:22 pm

Next update: I pulled the ATMega168V and with a good bench supply, powered it up on 5V (pins 7 and 8). I had (before powering it up) connected the microcontroller back to pins 15 and 16 of its socket which lead to the piezo on the board. Result: the same alternating buzzing from the piezo, so that problem is strictly due to the ATMega168V itself and not any external circuitry. I reassembled the enclosure (with the ATMega168V and the MAX6921 in their respective sockets) and I can just make out what sound like 'tics' at the seconds clocking over, all overlaid by the much louder alternating buzzing. In any event, it appears that the ATMega168V is putting out something on the piezo driver pins (15 &16) even with the alarm switch off and the alarm set a long time off from local and I should/will replace it. I will try to get some good pictures of the tube socket board a bit later. I did find one tiny solder blob on it with my eyeloop, but scraping it off had no effect, so it probably was not an issue. I also examined the interior of the tube (there are so many wires!) and but for one contorted connection in that little tube, nothing at the glass/metal wire seal even looks near to shorting inside. The contorted connection is not shorted. I will need to measure the pin-to-pin resistance across all the tube leads to check for actual interior shorts, but don't have time to do it this evening.
Regards,
Greg M.
gmulhollan
 
Posts: 4
Joined: Sun Jul 27, 2014 7:55 pm

Re: Yet another Ice Tube Clock Problem...

by jarchie on Mon Jul 28, 2014 9:56 pm

Some time ago, a user with a faulty Q3 noted an odd buzzing from the piezo in addition to a display problem. At the time I discounted the piezo noise as a fluke, but there might have been more to it. So if you're running out of ideas, consider bypassing Q3 to see if that resolves the issue. Probably a long shot, but might be worth trying.

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

Re: Yet another Ice Tube Clock Problem...

by gmulhollan on Thu Jul 31, 2014 11:19 am

I would like to thank everyone for their help. I did take a photo of the tube-end circuit board, but decided that there was not much to see there, so went along the header pins and checked for any shorts. All looks fine, with only the two ground pins being common. Of course that is at the DVM test voltage which is not the VFD voltage, but it seems unlikely that a tube internal short is the issue. I also carefully looked at the display and the lowest segment of the display is only spuriously lit when a "1" (one) is displaying. If it were an internal short, then the same thing should happen when a "4" (four) is displayed as they share the same two right-most vertical segments when lit. The "4" is just fine. So I am back to suspecting microcontroller issues. If you see my earlier post, I did get the funny piezo drive with the microcontroller pulled (only powered externally and hooked to just the piezo pair), which indicates to me microcontroller issues. I have since sort-of verified this by (attempting) to program an ATMega328P-PU with the "iv.hex" from the github depository (# **Ice Tube Clock firmware with GPS & working Auto DST support** #). I used that one as it explicitly states 328P support. As I am a newbie to microcontroller programming, I used the following avrdude commands (Omega Arduino MCU programmer shield, hence the avrisp call):
1. To set the fuses:
avrdude -p atmega328p -P /dev/cu.usbmodemfa251 -b 19200 -c avrisp -u -U lfuse:w:0xE2:m -u -U hfuse:w:0xC1:m -u -U efuse:w:0x06:m

2. To upload the program:
avrdude -p atmega328p -P /dev/cu.usbmodemfa251 -b 19200 -c avrisp -U flash:w:iv.hex

Both were reported by avrdude as successful. When the 329P was plugged in (no tube), I got the nice "beep" as from the first go-round with the original ATMega microcontroller. However, upon power off and then on again (now with tube circuit board installed), no beep and the display only showed a couple segments lit. Back to original ATMega and same (but mostly working) conditions. So I have a question, programming-wise: is the "iv.hex" file I used going to function (all else being correct) in a "stock" ice tube clock? If not, which one should I grab? I figure I will likely see the expiration of a couple more microcontrollers before I find the culprit, so I really would like to do the flash myself.

I think, aside from getting a correct microcontroller flash performed (correct .hex file that is), I have to get onto the board and look at voltages. Don't worry, I work on high voltage circuitry all the time (famous last words from an experimental physicist!) and have all the safety protocols hardwired into my back brain by now. And also I should check all socket pins for anything untoward, connection-wise. I will update my findings as I go since I know sometimes even the worst written diagnosis history may someday help one other person.

Cheers,
Greg M.
gmulhollan
 
Posts: 4
Joined: Sun Jul 27, 2014 7:55 pm

Re: Yet another Ice Tube Clock Problem...

by jarchie on Thu Jul 31, 2014 12:13 pm

The display problems you describe are exactly what you'd expect from a bad Q3, so it's probably worth trying the Q3 bypass test.

As far as programming goes, what you tried should work. The fuses are correct for the ATmega328p that you are programming, but not the ATmega168v that came with the kit. But when I program an ATmega328p with the Adafruit firmware, I usually initialize the EEPROM, but suspect that is optional step.

Code: Select all | TOGGLE FULL SIZE
avrdude -p atmega328p -P /dev/cu.usbmodemfa251 -b 19200 -c avrisp -U eeprom:w:iveep.hex

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

Re: Yet another Ice Tube Clock Problem...

by jarchie on Thu Aug 07, 2014 4:22 pm

Did you have any luck with the Q3 test?

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

Re: Yet another Ice Tube Clock Problem...

by jarchie on Fri Sep 05, 2014 8:34 pm

Did you ever find the solution to this problem? Another user wrote me privately about a similar issue with noise on the piezo, so I'd definitely like to know how things worked out for you. Even if you haven't had time to get your clock working, I'd certainly appreciate knowing that.

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

Please be positive and constructive with your questions and comments.