Ringing in the changes... result?

So it had turned out there were a few issues with the rev00 design for the ring.  This went from very minor stuff, like a power trace not quite reaching the right place due to a software bug, down to some footprints being a little dicey (the ADXL335) to outright wrong (the LT3494).  Then there were the buttons.  I'd chosen some Omron ultra-miniature tactile buttons which while very neat, require a lot of force to activate... particularly when you don't have a firm grip on the device in question.

I also thought the buttons were too close together to make it easy to press individual ones.  It made sense to drop a button and then go with something slightly larger, that didn't require as much force.  I eventually found some ALPS detection switches which while not designed to be pressed by hand (and as a result may need replacement after a while), would probably work fairly well with a roll of a nail.  I also took the opportunity to space out the fourth button to the right so it could have a clear role as a "back" button, to return back to the main menu.

I'd started work a lot more on the software... I used MPLAB X for the development, which is quirky, if generally quite functional.  The framework is a simple bespoke thing which uses a Platform Application Layer (or PAL) to abstract away calls to the hardware - things like graphics, input/output and hardware initialisation... and did a Linux/OpenGL PAL to allow for faster development time (and not wear out the flash on the PIC so much!).  I also wrote a higher level library for graphics functions to sit on top, to handle font drawing... I made up a simple 3x5 font, and then later added a 5x7 font for stuff that needed to be more legible.

The main "app" for the hardware was to be a game called Colour Fill, based on Color Flood, which in turn was based on another game... so a clone of a clone(!).  Anna is familiar with this game on my N900 and it was ideal for the screen as it doesn't require high resolution or fast updates to work.

I was a bit generous with the number of moves that the game starts with, but I have a particular fondness for the number 42, as I'm sure a lot of D.Adams readers do... I'm sure it will be reduced downwards in due course!

A few more applications were planned... in particular, I'd wanted to do a calculator, but the lack of buttons/touchscreen meant it probably would have been very frustrating to use, short of somehow combining the accelerometer to make it easy to use... you'd probably look pretty daft waving your hand in various directions to enter numbers, but it might work... possibly.

So onto rev01...

 

PCB Pool have changed to an ENIG finish, which I much prefer, as I've had corrosion on chemical silver finishes before, in particular when packaged in paper that presumably wasn't acid-free.  I also think they may have changed their solder mask as traces didn't seem as liable to peel up as they do on the older boards.

This time the free stencil should be a lot more useful!  This is me lining it up for the two awkward leadless parts (middle and top left)...

I squeegee'd on the solder paste as best I could, and then placed the parts with tweezers.  From then it was a trip over to the hot air gun.  It went surprisingly well... the footprints must have been okay as the parts self-adjusted into place and apparently were cleanly soldered.

From here on, the boards were straightforward to build, aside from a new footprint fail with the new ALPS switches... it was only slightly out so I was able to work around it, but it is preferred to have the parts in your hand before having the design fabricated so there's no ambiguity about where the pads should go.  Ah well.

One thing I was noticing about the new board is that it didn't appear as stable as the old one.  I was experiencing occasional CPU resets for no obvious reason.  The amount of trace rerouting on the rev01 board was very small, so it seemed unlikely I'd upset it in some way, but nevertheless when hammered in tight pixel loops it was showing a propensity to lock up.

I looked over the PIC32 documentation and tried relaxing the timings, but it still didn't seem quite right.  So I looked at the parts I was using the rev00 boards vs. the rev01 board.  I wondered if some of the ferrites had been from the wrong application type... meaning it could be a relatively high DCR, low current rated ferrite in a highish current position... nope, they looked okay... DCR of around 0.1 ohms.

Next I looked at the inductors... the core voltage inductor (a Murata) on the original board was too large... I'd made it fit but it was also a bit too tall, raising the thickness of the entire board.  So I'd spotted a Taiyo Yuden which was also 10uH, similar DCR and current handling but much shallower, and put this on the Rev01 board.  Hmm.  I took off the Taiyo Yuden and put on the Murata.  Instantly the board is a lot happier... but still seems to be locking up on more occasions than Rev00.

I also found that when the OLED was drawing a considerable amount of power (worst case is a full white screen), the CPU seemed to stand a higher chance of locking up.  Normally I would say this was down to inadequate decoupling but had followed all the usual guidelines... and unfortunately didn't have much room left to add more.

Giving it a good hammering...

My "solution" in the end was quite brute force.  Raise the core voltage to 3.3V from the original 2.5V, just by dropping in a different converter.  I put in a MCP1603, mainly because they are inexpensive, freely available and do the job... yet another Microchip part.  Once I did this, the board was much happier, although from an engineering standpoint this is clearly a bit of a cop out...

To talk power consumption briefly... welll... it's rather more than I'd like.  At the menu screen, with the 2.5V regulator, it was 26mA for the whole device.  When I puts the 3.3V in, it shot up to 32mA.  The main reason for this is not enough time spent on the software... the device never "sleeps", it's constantly running at 40MHz, churning away.

In truth, there is no good reason to be running it this quick other than making it more responsive... I could halve the system clock and it wouldn't hurt anything, and might even more stable too... should have thought of that a bit earlier.  But the main thing is to read the docs a bit more and learn how to use the idle modes effectively between scheduled events.

This would be particularly useful for one application in particular... a clock.  Now, if you do the sums, with a following wind, at 40MHz constant with minimal screen activity you're looking with this battery of somewhere around 3 hours.  Which for a watch is pretty useless.  If you conserved power appropriately with the CPU, dimmed the OLED, etc, I figure it should be good for >15 hours... which is still not brilliant but a heck of a lot better... long enough to be able to charge up at the end of the day.

An OLED is not an obvious choice for a watch, though - as discussed, a Memory LCD would be a much better choice, or possibly E-ink in combination with a power-sipping processor... but it is still nice to do.  It's all a matter of time constraints, and I really wanted the ring to be ready in time for our anniversary... so on with the assembling... hot glue time!

  

And in preparation for the final step...

I'd bought a sterling silver ring, and had no idea how difficult it would be to solder to.  Normally jewellers use very high silver content solder (>40%) which has such a high melting point it needs to be brazed - I think the reason for this is so the silver content of the whole item is high enough to be hallmarked.

I was not fussed about such matters, providing it was safe for Anna to wear, so I decided to go the entirely other direction and used a Bismuth-based solder.  Bismuth is interesting stuff... not only does it have (in my opinion) a really beautiful natural formation structure, but it also has a very low melting point.  As lead has been phased out, Bismuth has taken a bigger role in low melting point solders, being commonly alloyed to tin, as it is in this case.

The reason I wanted to use a low melting point solder is that not only would it be easier to attach, but it would be a heck of a lot easier to remove and far less likely to cause the components on the other side of the board to fall off... which would have been very likely with a brazing solder.  And here it is... the "final" end result...

 

 

It's pretty chunky (23x30mm), but it works!

Putting all this geekery to one side, the most important thing... Anna said yes!  :-D

As I suspected, it's a bit chunky for her tastes so may turned be into a wristwatch... which will mean the battery life needs to improved somewhat...

In terms of future expansion, the USB is all wired up, so that could potentially be used to upload firmware or other stuff.  I've barely used the accelerometer other than a little app that shows coloured blocks depending on the angle, so lots of room for scope there.  It's quite a nice little compact platform!

To finish up, here's a picture of Anna showing off her (for now) hand accessory... :)

Let's get physical...

It didn't take too long to come up with a schematic...

The PCB took a lot longer.  Designing when tight for area is always tricky, but imposing restrictions like 2 layer does not help... I eventually ended up with a design I was reasonably happy with and sent it off to Beta Layout to be produced via. their PCB Pool service.  Beta offer great turnaround times (if there are no issues), but their boards are 1oz and really don't enjoy hand soldering much, in my experience... the tracks lift quite easily, so require considerable care.

The best solution to this is take advantage of the fact you get a certain minimum area of board, so can have some spares.  A few days wait, and then rev00 showed up in physical form...

... for your protection... less kaboom...

Out of the packet...

Beta give you a "free" stencil with your prototyping designs, which is very nice when you have the tools... particularly when dealing with pain in the backside packages like the LT3494 and the ADXL335.

I quickly started assembling the boards... it went well at first, only to realise I'd put entirely the wrong footprint on for the LT3494.  Arghhhh!

 

Target had a footprint for DFN, which I'd used, but the orientation of the pins was at 90 degrees to what the LT3494 used.  Okay... so at this point I knew there would almost certainly need to be a rev01... and was reminded of an important lesson from Dave Jones... always check your footprints, or better, design your own.

No matter, I can still get it up and running.  My first attempt didn't go so well... the tiny tracks were damaged beyond repair on the first attempt, trying to find a way to wire all the pins on that would keep the footprint flat to the board.

Another go, and I found it was best to just give up on mounting it flush and instead put the part at a right angle to the board, wiring the long ground pad to ground with a short wire, which could also offer some structural support.

Okay... so now we're getting somewhere... let's populate the rest of the board...

  

Great... the power seems to be working fine (after a slight mod to route it correctly, see if you can spot it in the pic)... and all the rails seem okay.  Let's try attaching the screen and programming it...

It works! (please excuse the blurriness)... great news... but the ADC test is producing funny results for the accelerometer.  Looks like there may may some other issues to fix... roll on rev01...

The ring cycle continues...

So back to the drawing board I went.  I knew it was very important that I kept the ring as small as possible... Anna likes dainty stuff, not big jewellery, but you need a particular size to make something useful... to use an engineering stereotype, we like building stuff that is functional rather than just ornamental.  I don't know if that's because engineers aren't good at making things pretty (not necessarily true!), but we know when something is functional... determining whether it's pretty is up to the beholder.

I figured that the maximum I could get away with was an inch square and a few mm tall (oops, forgive the mixed units)... ideally as narrow as I could possibly do.  The smallest battery I could find of suitable size with a LiPo unit of around 120mAh capacity.   The battery in the middle is quoted as 23mm square with a thickness of 3mm... that's just about tolerable.

The one on the right is tiny... but couldn't really run anything substantial.  It's about 30mAh which would be tons for a memory LCD but I was now aiming for something hungrier.  I wanted a colour OLED display so that I could display photos on the ring.  A bit of research led me to one from a company called Densitron.  I presume they get made by a far east company as multiple companies seem to badge the same display, but 96x64 pixels sounded just about enough.... in any case, I couldn't find anything else this small with a higher res!  I could put it in the portrait orientation to minimise the width of the unit, so 23mm width was still on...

It offers SPI-like and parallel interfacing.  I did fancy a parallel interface but recognised I might end up short of pins... here's it hooked up in a basic fashion using the official test board from Densitron...

Because it uses the SSD1331 controller, it offers some hardware acceleration of lines and rectangles, which is very handy when your processor is a bit weak.  However, I'd been having a think about the processor options available, and I quite fancied giving the PIC32 a go.  It features a relatively powerful MIPS based processor core at typical speeds of 40MHz or 80MHz, with more IO than you can shake a stick at... variants offer USB, Ethernet and I2S functionality.

The latter in particular might be useful for audio projects, so this might be a great opportunity to learn a new platform.  The chips are cheap enough and getting started in development should be fairly easy.  I had read of Microchip's policy of crippling the MIPS GCC compiler they distribute (disabled -O2 and -O3 optimisation), charging ~$1000 to fully remove the restrictions, but that didn't feel like a major stumbling block... I could live with -O1 optimisation to start with or if I really needed more speed, use a different compiler.

So I started off by ordering a PICkit 3 and a few chips, building myself a little development board.  I went for the PIC32MX250F128B.  This 32-bit microcontroller features a spacious 128KB (yes, a whole 128 kilobytes!) of flash and 32KB of RAM.  While it had plenty of RAM, the Flash felt like it might be a bit short for photos.. I had wanted to go with the many pinned 128D variant, in QFN form, but when I started the project they were unobtainium!  This meant I had to go with the 28 pin variant.  This was going to be tight...

I built a little prototyping board with the header, and hooked it up to the PICkit 3.  No go... it didn't seem to understand the PIC32MX250 series... it was not aware of their existence!  I tried updating the firmware but that didn't seem to help either.  Grr.  So I ended up buying a Microstick II.  Unlike the PICkit 3, this actually worked properly and recognised the chip... which is not that surprising as it was designed as a small development board and comes with PIC32 chips included, along with dsPIC, I think.

Getting a good battery life from such a chip wasn't going to be straightforward.  Unlike the lower end chips that Microchip produce, the PIC32 is a relative power hog in comparison... while there are sleep states, it isn't as advanced power management-wise as something like the Gecko controllers, which are Cortex-based.  I was aware of the Gecko, but it lacked the same degree of I/O and the whole developing package didn't seem as straightforward.

Starting at the charging side, the logical source of power to charge the lithium battery is a USB input.  A MicroUSB connector is very small and almost ideal for charging a small lithium battery at around 4.1-4.2V from  approximately 5V.  The charger chip I ended up going with is another Microchip part, the MCP73811.  I was not consciously trying to pick a Microchip part, but it is a little SOT23-5 device that is cheap and perfect for the job.  It gives you the choice of either charging at 85mA or 450mA with no resistors... from looking at the datasheet, it looked safe to leave the PROG pin floating, which defaults it to 85mA... if I ever want to use the project with a much beefier battery, I can tie it high instead.

So that's the battery charging sorted.  Now there are the requirements for the various parts.  To do that, I'd need to know what needed powering...

I hadn't decided entirely what I wanted on the ring, other than a display for photos.  Audio might have been an option, but space didn't really allow a decent speaker.  I noticed that Murata make some very funky flat piezo speakers that with a bit of work could probably produce adequate sound quality, but there wasn't really the room in the design... I had a width of 23mm and really didn't want to increase that any further.

What else... well, a microSD slot would be nice, then there would be no practical limit to the storable pictures!  With a 96x64 display, the processor would either spend most of its time resizing or the card would be mostly empty.  Hm.  While a slot could have been crammed on sticking the card out of the side, it would be tricky while keeping it to a 2 layer PCB... I didn't want to go to 4 layer not for cost reasons but for modifications... I didn't want to have to get the board remade many times so wanted to do one rev, fix the issues on the PCB itself, and then have a final rev... or in a really unrealistic world, get everything right first time... :)

Okay... so maybe not ideal.  What about an accelerometer?  Mmm... that sounds like it could be good.  It can be quite an effective control interface when done right, and they are compact and not too expensive.  I decided that I wanted to go with an analogue output one as it just felt more comfortable, and the packages weren't quite as evil... I ended up choosing the ADXL335 - this is a 3-axis +/- 3G accelerometer in a package which is only semi-evil.  They call it a LFCSP... and it's one of those blasted leadless things.  Thankfully most of the pins aren't used, and you could easily dead-bug it, but that isn't much good on a PCB.  I'd need a different approach...

In any case, the accelerometer is perfectly happy in the 2.5V to 3.3V range... great,same as the PIC32.  Looking at the OLED, that is also happy in the 2.5V to the 3.3V range.  Marvellous... looks like we're on for a 2.5V main digital rail.  There's a whole bunch of choices for buck converters with identical pinouts, but I ended up going for the TPS62205.  This is a high efficiency buck converter which looked on paper that it'd do a great job, and if it didn't, there were load of other options I could try in the same footprint.

Ah... the OLED doesn't have an integrated booster for the actual display.  From looking at the datasheet, it looks like it'll need 14V.  Hm.  Not ideal... I've not exactly got lots of room free on the PCB, so it needs to be a very small boost converter, with an equally small (and shallow!) inductor.

This time the ideal choice came from Linear Technology... a part called the LT3494.  The first thing to note about this part is that it's small.  Very small.

And all the pins are on the blessed underside... not only that, but it has a big grounding pad which you must connect.  So I did another search... and no, couldn't find anything else in a SOT23 that was quite as good.  Ah well... the only way this is really going to happen is with a hot air gun... so I bought one of the low cost Atten ones, as mentioned in a previous blog entry.  With some solder paste and a stencil, I might just stand a chance here...

Good.  So we have charging circuitry, power for PIC32, OLED VDD, OLED VCC, and the Accelerometer.  What else?  Well... if you want to use the USB on the PIC32, that wants a 3.3V supply for the transceiver module.  Okay, no problem... this will be powered directly off the USB port, so a linear LDO is fine, giving a smaller footprint than a switched mode one.  I went for a simple LP2985.

So that's the power done... what about input?  Well, a few physical buttons are definitely a good idea.  With the 28 pin package, I'm really limited for inputs, particularly given the analogue-out accelerometer, so how about a resistive divider?  Yep... sounds good.  Every button has a different pull down to ground from a known resistance to the digital rail.  Let's make it 100K to keep the efficiency nice and high.  Then the first (most commonly used, preferably) button can be 100K, next one, 50K, next one after than 25K, and so on.  The nice thing about this arrangement is that providing your A/D is not rubbish, you can get a good 5-6 buttons and also detect combinations of buttons too!  Nice.

Now there's a few buttons and an accelerometer.  But I really wanted a touch screen.  REALLY wanted a touchscreen.  The problem I found was that no-one made one this small... at least not that I could find - sure, I saw touchscreen phones with something suitably small, but they are both expensive and there'd be a chance I'd fail to reverse engineer the protocol, or just break the blessed thing, leaving me with an expensive piece of junk.

All I was after was a suitable overlay.  I could get hold of ITO film, but building a touchscreen is far more complicated than just taking a couple of sheets... you need a spacer layer as well, and then to fabricate the whole thing neatly.  It sounded like a step too far, but I thought I'd experiment anyway... I'd found a cheap watch on eBay (one of a few million you can probably get) - what made this one special is that it looked like it may have a proper touchscreen... reason being that I saw it had a calculator application, not just the whole touch left side, touch right side going on.

So I bought one... and waited... and waited.  After about a month or so, it eventually turned up...

Yep, seems to work, let's try the calculator...

Not too bad, actually!  Seems to work okay... but... mm... that's just a grid of conductive material, isn't it?  Let's have a look inside...

Simple piezo element in the back, classic epoxy bob of a processor, along with what you'd bet money on was a 32.678kHz crystal.  Let's see if we can take a peek at the actual display...

 

Okay... so a zebra connector down to the touch panel, which... yes... is a grid.  Bah.  If I followed the grid and the dimensions perfectly, I might be able to use it, but I just don't have enough IO pins for a row/column arrangement... at most I might have been able to multiplex with the accelerometer's 3 pins... so no go.  At least it was cheap... and there's always a little fun to be had reading the manuals for these things...

Not that my Chinese is anywhere near as good!

In any case, the I/O and power were finalised, so now could get on with the PCB...

Put a ring on it...

Me and Anna got engaged yesterday!  For a few years I've been trying to come up with an idea for a special ring that I could present to her... I wanted it to be something geeky, so a regular ring wasn't going to do... it had to have lights and stuff... otherwise who'd know what'd happen...

As these things often do, it started out quite simple.  I'd read about Charlieplexing before on Hackaday, and it seemed like a great way of doing a little array.  I figured I could just about get away with a 5x6 array on a board measuring 18x23mm... small enough to make into a ring.  It wouldn't need anything fancy... an 8-bit micro would be plenty enough to drive and display a few scrolling messages.

The schematic in progress ended up like this...

Using a QFN16 package let everything fit on neatly, with IO to spare to connect to other doodads when I actually figured out how to do it.  Processor was to be a PIC16F684.  There's quite a few pics of similar sizes, so I liked the idea of doing one with touch sensing.

The LTC3525 DC/DC converter went on the underside.  Power source was to be a supercapacitor, which was going to allow for very fast charging... a few amps for a few seconds, and you're done - excellent!  There are many companies who make these things, but after doing some research, the best I could find in small form factors were from an australian company called Cap XX.  They do them in prismatic packaging which allows for a very thin form factor... ideal for a design like this!

I bought a few and did some experiments...

This here is a series-stacked pair of HA130 cells, which are charged to around 5V with a very low power levelling opamp circuit, using the MAX4470... this works out to be much more efficient in terms of energy consumption than a lower resistance balancing ladder.  That small gap between the two bits of copper on the right hand side is a crude (but effective) resistive touch switch.  This controls a PMOS FET (with some gate protection circuitry) which allows current to pass to the LED.

While it worked pretty well on the bench, I noticed that the supercapacitors were discharging much faster than my simulations had anticipated.  After some discussion with CAP-XX, it turned out that self-discharge rate and leakage current are treated as two very different things... only the latter is specified.  The rate was so high that it wouldn't stay at a useful level for more than a few hours.... gah.  And paralleling cells instead doesn't help the standby current one jot as the discharge rate will be high on both cells.  A boost converter would allow a longer standby but the on time would be very short near the end.

Ah well.  It didn't look like this was going to be practical.  The thing was, if I started looking again at a conventional battery, pretty much anything would be overkill for just a few lights.  Hmm.  Maybe I could look at doing something a bit more complicated...