Notey starts to become real...

I had always intended to do two revisions.... a prototype and a production one.  This is because the probability of no mistakes seemed pretty low.

The schematic for the prototype v0.1 board needed to be done very quickly as there was a very limited amount of time.  I made use of application notes to decide how to lay out the USB power switchover and support circuitry, but had some snap decisions to make with regards to minimising development effort...

Bluetooth compromise

As previously discussed, I wanted to use the nRF8001 for the high level of simplicity... and had originally intended to do my own implementation - it does not require that many support components, and there is at least one balun specifically tuned to the requirements of the nRF8001 to give best RF performance (a lot safer than using a bunch of individual passives, and probably better), plus a chip antenna.  However, once again, time constraints were against me.  Doing my own BTLE solution was introducing another potential thing to go wrong, even if there were some good reasons to do it (higher performance, lower cost).... they were a number of suppliers of pre-tested nRF8001 modules using a PCB antenna and all the soldering and passives already done.

I had originally tested with an Adafruit module but for production decided to go with Olimex as they offered a quantity discount.  There was another advantage to using an off the shelf BTLE module... it meant the main PCB could be made much smaller, which reduced cost to somewhat offset the module expense.  From looking at the Olimex board, the best way to connect to another PCB was through the double sided test header pads.  The two boards are connected through a simple 2.54" header... a small routing indent in the PCB was made for the plastic connector spacing to sit, so that the profile was not made any bigger than necessary.

The Olimex BTLE module

Prototype Schematic and PCB Design

I did the board in Target 3001 as I usually do... this was my first design with the new V17 - a few things are better but it's still as quirky as ever and not exactly the most stable piece of software I've encountered, but it is my favourite of all the ones I've tried.

For the first attempt at a schematic, I definitely erred on the safe side when it came to most design decisions, but for the PCB I did need to make the board as small as possible to keep the cost down, and also limited to double sided copper.

v0.1 Schematic

v0.1 PCB Layout

The PCB layout was a bit of a challenge... Anna's wedding ring was difficult, but this was at least as dense and producing quite a few of them!  While 0402 components are small, they have the disadvantage that you cannot run traces between the pads very practically, so you don't save as much as you might think.

I normally try to avoid 0402 capacitors, but to keep the board to a 40x40mm size, there was no option to just use 0603... the EPD alone requires 16 support capacitors and numerous discrete transistors.which makes the design quite tight.  One good thing about 0402 is that it makes it easier to put the caps exactly where they are needed, which simplifies the layout... on a small board, the last thing you want is to need multiple vias just to route a decoupling cap... while most of the support caps do not require super low inductance as are not for high frequency use, it is still good practice to try and minimise it.

While I could use both sides of the board for components, it didn't seem practical to reflow the board on both sides (the risk of components falling off on the second reflow unless you use a solder paste with a different melting temperature), so the display side would all be hand-soldered.

Rendering of (mostly!) completed v0.1 board

So I sent off the board files for a super-quick turnaround and got them back the same week...

Prototype PCBs

PCB with the nRF8001 for size/location reference

So onto aligning the stencil... this is a real pain to do when you have multiple parts with 0.5mm pitch, particularly on the QFP as it has to be right in both directions.  When I was happy it got stuck down with kapton tape using some other 1.6mm thick PCBs as spacers.

Stencil alignment

Applying the paste was tricky.  It helps to stir the solder paste to warm it up a bit as then it flows a bit better.

Applying solder paste

The end result of the squeegee action was a bit rough and ready.  I wouldn't quite call it a "high definition" result but it was a first attempt after all.  Made me think quite a few solder bridges were likely...

PCB with paste applied

Well, I'd find out soon enough.  Time to place some components - I used my tweezers to carefully start putting all the major components into position.

Just Enough Essential Parts?

And into the reflow oven it goes... now it's a waiting game...

Low temperature reflow profile in progress

A few minutes later, the oven beeped and I opened the drawer to have a look..

Dodgy reflow...

Ah.  Not quite the outstanding success I was hoping for.  A few of the SOT-23 transistors have reflowed, but almost nothing else.  Gah.  Okay, so the low-temp profile clearly isn't hot enough, either due to the oven temp sensor being off or due to the paste having different characteristics.  There didn't seem to be any harm in giving the old-school leaded solder profile a try just to get something up and running - the temp is still much lower than lead free and should put less stress on the components.

Dodgy reflow of a different kind

Well... it's definitely reflowed, there's no question of that.  Unfortunately my fears regarding the paste and the tight pitch spacing was very much confirmed - lots and lots of solder bridges!  This had to be sorted out by hand with some flux and some desoldering wick.  The profile and footprints will definitely have an influence on this, but it could be that the consistency of the paste is not well suited to such fine work.  In any case, I needed to try and get a prototype board working...

Notey design and production aspects

And so to the matter of creating a real design...

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

In order to prevent PCB damage, I'd decided to try using Bismuth-based solder paste rather than the usual lead free mix that is mostly tin... the Bismuth based paste is available on eBay fairly cheaply and has a much lower melting point.

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...

Prototyping the notey

At this point I had a reasonable idea what hardware was going to be involved, so could try testing some of it out...

The screen

Getting the e-ink working was very easy with an Arduino, but proved to be more difficult with the EFM32... there was some source code available, but it was for an older version of the display which was both quite incompatible with the newer B13 release, and also used a comical amount of RAM as relied on a framebuffer and a graphics library for rendering text.

Even though I was developing on the LG, I wanted to be able to target a regular Gecko with only 16KB of RAM and 128KB of Flash, and no USB capability... this was a much cheaper part (about half the price) which would greatly reduce the BOM.  It also can only run up to 32MHz but in theory that should have been okay.  Makes things trickier with the screen, though.

So what I did was take the Arduino library that worked and ported it to the EFM32... as an AVR has virtually no memory, this slashed the memory requirements down to a line buffer.  The SPI was a bit fiddly but eventually got it working.

A note on the e-ink screens... these are really closer to an analogue device than any other traditional digital screen... in order to get a clear picture it is required to write first in a particular pattern to clear any ghosting from the previous image, and then depending upon temperature, draw the image a particular number of times with suitable delays.

If you just try to draw an image once, you will still be able to see what was previously written in the same space, just a bit faded (this one has been stopped mid-write for the new frame, which causes an interesting bleed effect...).

 The thing is, the longer you spend updating the screen, the more power you are consuming... and there is also a balancing act between how fast you run the processor (which will affect the SPI transfer speed) and the total power consumed to update the screen.  Looking at power measurements, it seemed that running the processor flat out was most efficient in terms of total power consumption for a screen update... then sending it back to sleep as soon as possible.

To get a really clear image may take 4 redraws, but a perfectly readable image is normally possible in 2, with some degradation.  This is both quicker from a UI perspective and also consumes much less power, but eventually the ghosting of previous images will reduce the contract to the point when a full  clear is necessary.  This generally involves an inverse image of what was previously drawn, and then alterating solid black and white... the Pervasive Displays datasheet has more information.

Something that isn't covered in great detail is the endian-ness... I found it was necessary to flip about bytes but that was quite easy to do as a lookup table.

One note about the ghosting... some e-ink displays have greyscale capability... the Pervasive unit is not designed for this, but in theory you could probably get a few shades out by carefully understanding the persistence of the image and how it varies with temperature.  I decided this was beyond the scope of the favours as was up against it in terms of time!

The Bluetooth

I bought another module off the shelf to help with development... first, the Adafruit nRF9001 unit...

It is clearly targeted towards the Arduino crowd as has a 3V regulator and level translation... neither is desirable in the Notey but for a prototype it is fine.  The example code for the Adafruit module talks to the Bluetooth module via. ACI, which is a simple high level interface.  I was able to take the essence of the Adafruit code onto the EFM32, translating on the way into straight C, and replace the ACI section with the EFM32 port.

I've had a few issues with dropped connections, but generally the nRF8001 is a plug and play solution for sending messages across BTLE, and importantly, has a free application available for both Android and Apple devices.
In terms of supporting BTLE, Apple were in early as an iPhone 4S or later is all that is required... Android is rather more fragmented.... v4.4 is required for stable support.  I picked up second hand an iPhone 4S and also a Moto G for testing.  Both are relatively inexpensive now, particularly, the G which had a cracked front glass, but still perfectly functional.

Software

While there were a lot of challenges ahead just to get the hardware finished, I needed to at least make a start on the software, so worked on some font rendering.  It had been a while since I'd had to do any font stuff, but decided to go slightly more advanced than I had with the engagement ring and splash out with.... wait for it... proportional fonts.  No, not exactly earth shattering but means the fonts wouldn't look silly.  I did consider custom kerning as well but that was really a "nice to have" rather than an essential item.

A bit squashed at the first attempt, but it works...

I found a helpful .NET application which would convert TrueType fonts into bitmaps along with size and proportioning information.  These were then brought into the main code as const char arrays.

I brought in three fonts... a 12pt, a 24pt, and a 32pt.  In hindsight, the 24pt is too big, as it only gave an extra row of text, but it seemed like a good idea at the time!

At this point I had some basic BTLE and display test applications working, it was time to get cracking on the real hardware...
 

Wedding favours... that seems like a good idea...

So... another big blogging gap - work had a fair amount to do with it, but the main thing most of this year has been getting ready for the wedding!

The beginnings of the Notey...

To catch up where we left off, Anna said yes.  This was wonderful news, but meant a wedding needed to be planned!

I'm not entirely sure where the idea originally came from, to be honest - someone probably mentioned web favours and that set the ball rolling... we have enjoyed some lovely stuff like home made fudge, and while I like to think I'm a pretty decent baker, felt I wanted to do something a bit more techy to go with the engagement ring.

While it would have been quite simple to do something with flashing lights and an Arduino, I wanted something that could serve a useful purpose... that would see use after the wedding day.  Since doing the engagement ring, I had been researching low energy screens and this seemed like it could be a prime candidate.  I liked the idea of a display that could be put on a fridge and updated remotely from a phone or tablet, to leave messages or make lists.

The microcontroller

I had done the engagement ring with the PIC32 because it was a powerful, cheap microcontroller with a simple IDE... its big weakness was power management, which unfortunately in this project was a critical requirement.  So a change would be needed...

For low power with reasonable speed, ARM is an obvious option... there are a variety of cores available with different power/performance footprints, and for my requirements, a Cortex M3 seemed about right.  I had got an EFM32 evaluation board about a year previously but had never taken the time to get to know it... this seemed like as good a time as any!

The one in particular I had was a Leopard Gecko... this one has an M3 core along with 256KB Flash, and 32KB of RAM.  The maximum speed is 48MHz, which requires a dedicated crystal, rather lower than what the PIC32 can do, but that doesn't matter much for this application - the critical thing is that the sleeping is very efficient.  The EFM32 has several energy level modes... EM0 is when the processor is active, EM1 is for collecting data (CPU sleeping) and EM2 has most things disabled, but will wake up on an interrupt... this is the mode I needed the application to spend most of its time in to have any hope of a long battery life (consumes only uA).

It might be nicer to use a smaller (cheaper) one if I can get away with it, though!

The screen

There are two main choices for low energy screens... e-ink screens (EPDs) or memory LCDs (from Sharp).... both have their advantages and disadvantages,  EPDs have zero power consumption when not being updated... the disadvantages are that they are relatively hungry when being updated, and also suffer from effects like ghosting, and are much more complicated to drive, requiring a great number of capacitors in order to work the charge pumps.  Memory LCDs are much simpler, can run off a single voltage rail, and require very few capacitors... their primary disadvantages are 1) significantly more expensive, 2) some current required to maintain display and 3) fairly poor contrast ratio.

In the end, cost was the deciding factor... I was initially intending to make a wedding favour for all the guests, so the display being about half the price was a big deal.  I plumped for one provided by Pervasive Displays, via. Embedded Artists.  EA offered an evaluation board which was a useful kickstart to getting up and running, and also a reference point for implementing the display... While there was some circuitry I could drop by keeping things 3.3V or below, ultimately I would need to keep most of what was on there not only for the display to work, but also to control leakage current and turn the display supply off when not updating. 

The communication

Bluetooth LE was always going to be the thing that made the project possible, as conventional Bluetooth is far too power hungry.  BTLE has been sold as the solution to the "internet of things" as it allows monitoring devices to be decoupled from the mains and run off very small batteries... in some cases even coin cells!  I loved the idea of potentially running the "fridge note" off a coin cell as that is something widely available and easy to replace.  (I didn't like the disposable nature but that's another matter).

So I wanted a BTLE solution... in a perfect world, I'd get the CPU integrated with the BTLE module... and EnergyMicro/Silicon Labs had a solution coming called Blue Gecko which sounded exactly like what I wanted... unfortunately it was due for launch around September time, when the wedding was!  Samples were going to be available earlier but I wasn't too keen to be on the end of inevitable errata, having been burned  by "rev 0.1" silicon before.

So, a mature two chip solution was safer even if rather more costly and more power consuming.  So needed a chip to partner the EFM32... I looked at a few but eventually settled on the nRF8001.  The primary reason being that it's very, very simple (designed to be hooked up to microcontrollers) and has example code available.  I even found example code for use with the EFM32!  Great... that will do nicely.  Nordic do sell a BT module with an ARM core but I decided to stick with what I knew rather than jumping to a completely unknown IDE and uC with unknown idiosyncrasies.

Now the basic parts were decided, I could get on with the design...