Saturday, 21 September 2013

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




No comments:

Post a Comment