Binary clock project

[thezic]

Hi!

I would like to ask for some feedback on my clock project before i start laying out the pcb.

It was ages since last time I designed something, so anything could be wrong

Edit 2016-10-18: Updated schematics
Edit 2016-10-19: Updated schematics
Edit 2016-10-24: Updated schematics

[FreddyVictor]

could be wrong, but doesn't TX + Rx wires between ATmega + FTDI need to be crossed over ?

[thezic]

Thanks! Good Point!

You are completely right, I've missed that.

[thezic]

Well, now i've routed the board.
What do you think?

https://bitbucket.org/thezic/binaryclock/overview

[Kalvin]

Could you export the PCB gerbers as PDF and provide a link to the PDF?

[thezic]

Done!

I've added them aswell to the git repo

[daqq]

The 74x237 seems a bit redundant - you have enough pins available to do without the demux. Also, considering the current (5mA per LED, only one column active at any given time) you should be able to drive this directly with the GPIO without any of the transistors.

[Ian.M]

20mA if all the LEDs in a column are on, is a little high to drive directly from CMOS logic without voltage droop which causes undesirable brightness modulation, so I'd keep the high-side MOSFETs.  However, what's with latching the column address and calling the latch signal 'PWM'?

Assuming 5V supply to the high side drivers, I'd ditch the bipolar drivers and use a 74HC138 (with PWM to one of its enable pins if you want brightness control), directly driving the P channel MOSFET gates. 

[thezic]

You are right! Of course the pwm should go to an enable pin, not to the latch.

I did remove all all transistors in a later edit, but I guess I havn't updated the exported pdf of the schematics. But you think I need them? Then I'll add them again!

I only have a supply of 3.3V. (Aiming to drive this thing from 3 AA batteries). I tried to find a solution without the extra bjts, but in every simulation i did, i couldn't get the the mosfets to turn of without them. I used the mosfets in the first place to reduce the voltage drop as much as possible, otherwise i would have used bjts to drive the leds instead.

the leds have a Vf pf 2.85V at 5mA, so 3.3V should be enough.

Please correct me if i'm wrong

@daqq: I do have enough io pins, but I kept the 74x237 in order to adjust the brightness with only one PWM signal.

[Ian.M]

You've got problems.  The 3.3V rail is going to start drooping when the battery is somewhere around 1.15V/cell, which is only going to let you use about 60% of the nominal capacity of AA Alkalines.  If you run the LEDs off the unregulated rail, and you want the MOSFETs to turn off properly without needing the NPNs, run the CMOS decoder from the unreg rail as well.  Worst case you may have to use a diode + pullup resistor level shifter on its inputs, but up to 4.5V Vdd, its inputs should be compatible with lightly loaded 3.3V CMOS logic.

[thezic]

You are right, have to take a step back the drawing board I guess... But i'm grateful i got this input now and not after I've sent the board for manufacturing. Thanks!

I will also drive this from usb when usb is connected, so if i run it directly from the unregulated rail, the voltage would go up to 5.25 in worst case. So input voltage will be about 3-5.25V.

I don't really get how I would make a level shifter with a diode and a pullup resistor?
Also with this setup i would get quite big difference in brightness along with the drop of battery voltage. But that I could solve by measuring the battery voltage and regulate the pwm signal accordingly.

What do you think about exchanging the linear regulator with a buck/boost converter instead, that always outputs 3.3V?

[Ian.M]

How confident are you that your first cut at a buck-boost layout will work with no problems?  Do you have the demo board for the chip you propose to use on your bench right now?  Its a great idea for battery life, but getting it running reliably is going to need some prototyping before you design your clock board.

A simple diode level shifter is a diode, cathode to the signal source + a pullup resistor on its anode.  It adds 0.6V to both the logic 0 and 1 levels, which  reduces your logic '0' margin and boosts your logic '1' margin by 0.6V.  That's enough to  give you a logic '1' of 3.8V, possibly 3.9V, which is 78% of 5V. However, depending on the actual worst case logic thresholds that may not be good enough @5.25V Vin so we are back to the need for level shifters for the high side P-MOSFETs, unless you choose to use proper level shifters between the MCU and the 3=>8 decoder, e.g. SN74LV4T125

[thezic]

I'm not confident at all, I haven't used a buck/boost converter before. I don't have an evaluation board.

But I was thinking about something like this: http://www.mouser.se/ProductDetail/Murata-Electronics/LXDC2SCAAB-352/?qs=sGAEpiMZZMt6Q9lZSPl3RWy%2fP16X%252bSj3cP6zvG409s62S1iPeDTZIw%3d%3d

Looking at the data-sheet, it seems quite straight forward to use, and it doesn't require any external components. But I don't have so much experience in this field, so you probably know this better than me.

I also was thinking, how big difference would it really make to drive the LEDs from the unregulated rail? The voltage will drop down to about 2.9V if i run it from regulated rail. But it would drop to about 3V if I run it from the unregulated grid, so the difference would only be about 0.1V, right?

[Ian.M]

So its an integrated module with its own caps, inductor etc, not a raw SMPS chip.  That make it a lot easier - as long as you use a ground plane and put the decoupling caps near the module, it should be OK.  However its "Wide Input voltage range : 2.8~5.0V" is of some concern - assuming 3xAA and a Schottky series diode (for isolation from USB Vbus), that isn't going to get you below 1V/cell.  Also that center 0.5mm ground pad is going to be a PITA to hand solder.  Are you set up to do reflow soldering?

Running the LEDs from the unregulated rail saves a lot of hassle with regulator dissipation if you are using a linear LDO.  However as soon as you go for a switching regulator with enough current capability, it becomes a bad idea - in addition to the complications with needing to sense the rail voltage for the PWM brightness control, you have the added complexity of level shifters to get the gate drive up where you need it + it wastes battery power - as long as the battery voltage * regulator efficiency > 3.3V, it will draw less current for the same average LED current if you power them from the regulator output.  The 3.3V rail limits you however.  You probably need to allow about 0.3V total drop in the high side MOSFETs + the low side  ATmega output pin drivers, and you'll need to budget min. 20% of the remainder for the drop across the current limiting resistors for them to be effective at equalising the LED currents, which leaves you with a max LED Vf of 2.4V, which rules out white and blue LEDs.  Personally I think a blue LED binary clock would look absolutely hideous, and white would be plain boring so IMHO there is little loss there.

[thezic]

It's obvious I have to rethink a bit. I might go for red LEDs instead. I also think I'll go for the switching regulator.

I haven't done any reflow soldering before, but I've planned buying a hot air station for quite some time, so maybe it's time now

Do you mean I should put a separate ground plane under the regulator, or just not putting any traces/components under it?

What would happend if I don't drop 20% over the resistors?

[Ian.M]

If you really want to use 3V+ Vf LEDs, why not simply boost from 2xAA to 5V, and run the MCU, logic and LEDs from 5V?  USB power can feed in to the regulator output via a simple Schottky diode, with a circuit to activate the boost chip's inhibit pin when USB 5V is present, and if you want to get fancy, you could use a LiPO for the battery and add a LiPO charger IC.  The less the voltage drop across a LED's series resistor, the more small variations in Vf affect the LED current and thus the brightness.

If you dont drop 20% in the resistors, and you want them all to have the same brightness, you'll have to hand match the LEDs for Vf @5mA If, and use matched ones for each row.  Ideally you'd match all the rows, but you can trim the brightness on a per-row basis via the PWM.

An alternative on the LED side of things would be to use Neopixels.  They are smart, fully dimmable RGB or RGBW LEDs with a daisy-chained serial interface, and run from a 5V power bus.  Available in a variety of form-factors including individual SMD or thru-hole, and prepackaged matrixes, bars and flex strips.  You could do all sorts of effects, e.g. making the colours reflect the time of day - dim cool blue-white (simulated moonlight) at night, reds and oranges for dawn and disk and bright yellow-white for daytime. 

Put a ground plane under and round the switching regulator module, 'stitch' the ground tracks to it with plenty of vias, and keep logic level tracks away from it.  Otherwise it will probably give you hell with lots of EMI.

[thezic]

I chose 3.3V to for lower power consumption. But with a switching regulator, it might not do any difference, because I won't use so much current anyway. I'll see how i'll do. Now I have something to think about for a while, until the next time I have time for this project...

Thanks for the help!

neopixels are cool, I might use them in a future project

[Ian.M]

If you do go LiPO with a simple boost converter you have to consider the low battery shutoff requirements.  A simple boost converter will continue to feed the MCU with Vbatt - 1 Schottky diode Vf via its inductor and rectifier drop even with the converter shut down.   If your MCU can run at 2.8V, you can have it monitor the battery voltage (hint: use a potential divider with Megaohm resistors + a micropower low voltage CMOS OPAMP powered from the regulator output to buffer the divider for the MCU's ADC), and at about 3.1V it can shut off the LED display, and the boost converter and blink a separate low battery LED (high efficiency of course) with a very low duty cycle (e.g 10ms in 2 seconds) until USB power is detected while still maintaining timekeeping. 

If you *really* want to protect the LiPO, you'll either add a protection IC and series MOSFET to hard disconnect it at 3.0V or choose a MCU with an internal reference, calibrate it against the 5V rail (which is likely to be much more accurate than the reference) as soon as low battery is detected, before shutting off the boost converter then use it to continue to read Vbatt after shutting off the boost converter, so it can enter its lowest power sleep mode when the battery drops to 3.0V and sod the timekeeping!

[thezic]

I finally got some time to think about this again.

I kept the LDO, but go for 2.7V instead of 3.3V. I also ditched the blue LEDs and use some ordinary red ones instead. I thought about going for a LiPo, but decided to keep that for another project.

Now I drive the MCU directly from the unregulated rail, so I can turn off the LDO when the power goes down, to keep the time when I no longer can drive the LEDs

What do you think?

I've updated the schematics in the first post.

[Ian.M]

I think it sucks worse than the previous version.   You aren't supposed to apply VCCIO to the FT232R unless its VCC pin is powered.  There's a note in the datasheet to the effect that VCCIO must be derived from USB VBUS if the FT232R VCC is derived from VBUS.

Personally, I'd ditch the regulator as there doesn't see to be anything that needs a regulated supply, and maintain constant LED brightness by modulating their duty cycle to compensate for changes in the supply voltage, which can be determined by running the ATmega328P ADC from the unreg. supply, measuring the internal bandgap reference and solving for AVCC using the known reference voltage.

[thezic]

Ok. How about now then?

I know I can measure the bandgap, but I want to measure the battery voltage even if USB is connected, so I don't see how I would use the bandgap for that.

I did the math, and you are right, I can run everything from the unregulated rail, so i removed the LDO.

[Ian.M]

Looks sane.  You may want to add a large cap across the battery to keep the rail up long enough to retain the time while you change batteries.  Its only got to give five minutes timekeeping from your low battery threshold to do its job.

I know I can measure the bandgap, but I want to measure the battery voltage even if USB is connected, so I don't see how I would use the bandgap for that.

The general technique is to connect the battery via an extremely high impedance potential divider (e.g. a pair of 4.7Meg resistors) and a CMOS rail to rail micropower OPAMP buffer, to an ADC input.  You may be able to get away with a direct connection like you have  but it would be advisable to stick a 1K series resistor in there + a 0.1uF decoupling cap to Gnd at the ADC pin to minimise the risk of ESD damage when the batteries are being changed and to protect you from your own idiocy if you accidentally make the pin an output during development.

First read the bandgap and calculate the rail voltage using it.  (You need to do this anyway as USB Vbus voltages are all over the place even though they are nominally 5.0V) Then, if USB powered, read the buffer output and calculate the battery voltage (or read the direct battery voltage).

The OPAMP approach is needed if Vbat can ever be more than 0.3V above the MCU supply voltage. Done right, it only adds about 10maH/year to your power budget - negligible compared to the battery self-discharge and the MCU's deep sleep consumption.

[thezic]

One more.

I also added a charge circuit for a LiPo, in case I some time would like to use that as power source instead of the 3 AA batteries.