IceTube / Make the boost convertor less noisy

[sircus]

I have a nicely-working IceTube. Over time, I found the few seconds a day that it loses to be irritating. I'm in Germany, so I decided I'd like to attach a DCF77 receiver to make the clock radio-synchronized. I bought a receiver and have attached it to the clock (via a bread board for the moment). The two pins available to me for getting the data from the DCF77 to the clock were PC4 and PC5 - I took PC5. Because my DCF77 receiver has a push/pull output, only capable of sinking/sourcing 5uA, I've put PC5 into High-Z state - the pullup isn't active.

When I have the DCF77 receiver powered, but not connected to the IceTube board, I see nice square waves outputting the DCF77 signal on my oscilloscope. If I connect the receiver's data pin to PC5, I see square waves (and can read these with a modified firmware) for about 45 seconds - but they're increasingly degraded. Normal DCF77 is pulses of 100ms or 200ms followed by a 900/800ms pause. After 45s, I'm seeing lots of little 20ms/50ms highs/lows and very little DCF77 signal. The highs and lows are nevertheless largely square waves.

I figured - PC5, pin 28, is right next to the inductor. Inductors induct. The receiver is operating with a weakish signal and tiny amounts of current. The inductor is probably causing enough noise on the line to the receiver that the receiver itself is getting confused - i.e. it's the receiver outputting those square waves, but rather than being based on the DCF77 signal, it's getting (somehow) overwhelmed by whatever the inductor is doing.

I'd be perfectly happy turning off the boost convertor and not having visible digits for the time it takes to get an initial sync to DCF77 (about a minute). I could also modify the firmware to repeat this procedure once every 24 hours (at 4am, say) so that the clock stays in sync.

To prevent noise from the VFD driver, I've raised the VFDBLANK line. (I'm mostly debugging with the tube disconnected, but I connected the tube and checked - digits are indeed blank after doing this.)

To deal with the boost convertor, I've raised the BOOST line, figuring that if the transistor is always "on", the voltage across the inductor never changes and this should be the least noisy mode for it. I've also set OCR0A to zero in the hope of preventing the PWM from mucking with the BOOST line.

I still see the same effect on PC5 (lots of short pulses). On BOOST, I'm not seeing pulses, but frequent spikes at between 3v and 5v. They appear to be irregular.

At this point, my woolly theorizing about what might be going on is at a loss. Is my theory about the inductor likely to be right? If so, what's the best way to get it to be as quiet as possible?

[jarchie]

To deal with the boost convertor, I've raised the BOOST line

Hmmm... Maybe try disabling the display with

Code: Select all

            TCCR0A = _BV(WGM00) | _BV(WGM01);
            PORTD &= ~_BV(PD6);  // boost fet off (pull low)
            PORTD |=  _BV(PD3);  // MAX6921 power off (pull high)


And reenabling with

Code: Select all

            TCCR0A = _BV(COM0A1) | _BV(WGM00) | _BV(WGM01);
            PORTD &= ~_BV(PD3);  // MAX6921 power on (pull low)


[jarchie]

I'm curious. Did that code work?

[sircus]

jarchie, sorry, been quite busy, so I haven't finished with experimentation. It certainly helped, but doesn't seem to be the whole story. The DCF77 module wants at most 30mV of ripple on its supply. I suspect that this is currently not being achieved. My current plan is to first try it attached to three AA batteries, to see that I do get a decent output when there's no ripple. Assuming that works, I then plan to try and ensure super-clean power right next to the module.

I'll update this thread when I've got some kind of result. Thanks for your help so far!

[jarchie]

jarchie, sorry, been quite busy, so I haven't finished with experimentation.

There's no need to apologize! I was just curious.

My current plan is to first try it attached to three AA batteries, to see that I do get a decent output when there's no ripple.

That sounds like a smart approach.

Assuming that works, I then plan to try and ensure super-clean power right next to the module.

If the problem is power ripple, I suspect the Ice Tube Clock power supply circuit is not able to sufficiently filter noise from the AC adapter. I suspect that noise filtering, as you suggest, is the most logical solution.

I'm not sure how much ripple is due to the power usage from the various ATMEGA chip subsystems, but shutting down USART, SPI, and the timers might be worth trying. I cannot write the code off the top of my head but can figure it out pretty quickly by looking at the ATMEGA168V datasheet, if you're interested. And if you are interested, please let me know which firmware you are using. Many of the alternative firmware projects have their own quirks...

I'll update this thread when I've got some kind of result. Thanks for your help so far!

You're welcome, and thank you for the update. I will look forward to learning how the project turns out.

Good luck!