The hardware was originally going to be based around a Gecko G210F128, but when I prototyped with a G210F128, I had problems with the E-ink timings that were not happening with the LG... for that reason it was decided that despite the cost, it was more sensible to stick with a solution that actually worked!
The challenge with the LG was that it is a more complicated part which has a higher number of pins... the original targeted Gecko part only had 32 pins and was a small QFN package. I'm generally not a fan of leadless packages as it makes it much harder to see whether the part has soldered correctly, but it woud help to conserve precious PCB space. The smallest LG I could find was 64 pins, which is quite a lot... thankfully the LG was also available (albeit with limited availability) in QFP format... pins - great! This is particularly helpful as it is allows for hand soldering.
Soldering
In any case I had decided already that this project would be a great opportunity to try out reflow soldering, so had purchased a Chinese reflow oven from eBay. These ovens are very good value for money but have two major problems... the first is that the software is terrible... highly unresponsive and the temperature quoting is dicey at best... the second is that the controller board is electrically insulated from the main oven with a large quantity of masking tape. The masking tape gets hot and then the adhesive starts to stink, as it is not designed for high temperatures. The usual fix for this is to remove all the masking tape and replace it with kapton tape, which is designed for high temperature - thankfully the eBay seller had already done this.
When I got the unit, I had a look inside and decided to also add a 1-wire temperature IC by where the temperature probe comes in... this allows for better temperature compensation and as a result the unit temperatures could be made more accurate. This is no use without new software, though! Thankfully an enterprising engineer has reverse engineered the oven and come up with a complete firmware replacement... this is as simple as using a serial cable and pulling a test pin high. The firmware flashing worked perfectly, although it was a little disconcerting that the oven and fan were on full blast during the process!
 |
| Unmodified board |
 |
| Cold junction compensation added |
A few things on this... the "Soda" paste has a somewhat unknown provenance (at least to me) and I couldn't find any published temperature profile. Profiles can vary anyway depending on the thermal mass of particular designs, so I started with a low temp profile and then modified it. I haven't checked the oven calibration, but it seemed to struggle to reflow my fairly small boards, so I ended up using a leaded profile... a higher peak temp than bismuth should need, but still much lower than a usual lead free which can peak above 240C.
I did have some problems with areas where the paste was excessive or where there wasn't enough. At least part of the blame for this is to do with the footprints for the parts.
Power
In terms of the rest of the design, we needed some kind of power source. So initially coin cells were considered... particularly the ubiquitous CR2032 cell. While the CR2032 has a very impressive capacity for its size and very low self-discharge, it has fairly high ESR which makes it poor for applications which require high pulses of current. Just pulling 10mA creates a voltage drop of 200mV near the beginning of the cell life, and towards the end of cell life, the ESR increases substantially causing a much bigger voltage drop.
Part of the problem could be worked around using a supercap, but if the system ever got into a loop where the pulse rate could not be managed, the cell could get very hot and unmanageable. Paralleling cells would reduce the ESR problem but is not an ideal solution, and if using disposables is also quite wasteful.
So my thoughts turned to using a lower ESR power source without these problems... two major candidates - lithium ion/poly cells or low self discharge modern NiMH batteries.
Lithium ion cells are widely prevalent and not too expensive on the whole, but the big concern was with discharge... when a lithium battery is abused, it can be ruined, and then replacement becomes an issue. NiMH has considerably lower energy density than lithium cells, but are freely available and easy to replace if they are damaged, so with the modern LSD technology looked like a good option - their typical self-discharge is also considerably lower than a typical lithium cell... very important for an application where the battery won't be used for periods.
The significant disadvantage of NiMH is that they are complicated to charge well... there are a couple of techniques, one of which requires monitoring temperature, and the other (delta V) looks for a voltage drop to indicate the battery is full. This only works well when the battery is charged at a fairly high current, otherwise the drop is much more difficult to detect.
Doing a discrete circuit for this is a real hassle... a microcontroller can handle a lot of the burden, but should the code crash or something else go wrong, you can quickly end up with a ruined battery. For this reason an off the shelf solution was preferred. After a bit of research, the LTC4xxx looked to be a good option. Expensive, but fairly straightforward to implement.
One mistake I would discover later on was omitting any voltage regulator from the MCU supply. This was not an obvious mistake as such, as all components should tolerate up to 3.6V on the core, and for two NiMH cells, that is comfortably beyond what you should charge them at, but what I found out very late on is that at startup, the voltage can exceed this and fry the MCU. As a result I decided to leave off the charging circuitry... a clamping zener would have probably made things safe but they need something to work against... which in turn would require a polyfuse... that equals more voltage drop, more leakage current... the desire was to be able to connect the battery directly to the VMCU and use the naturally low consumption of the MCU to be the main draw beyond the battery itself.
The intended size for the unit was based around the dimensions of the EPD, which is roughly a 2.7" display... while the unit could be thick, I didn't want the batteries to completely cover the rear panel as that could make it difficult to access headers, ports, etc... it also adds more mechanical strain... as a fridge magnet, I wanted to attach the device magnetically and this is easier with a lighter weight. For this reason, I chose 2xAAA cells over 2xAA, which would be able to have roughly 3x the capacity. In any a case, a battery life exceeding a month was considered plenty, though it will be almost completely down to how many display updates and BTLE negotiations are done...
My order
ReplyDelete