- Silicon Labs Community
- Welcome and Announcements
- Silicon Labs Knowledge Base
- 8-bit MCU
- 32-bit MCU
- Bluetooth / Wi-Fi
- Other Products Category
- Optical/RH/Temp Sensor
- Other Products
- Hardware and Software Tools
- Simplicity Studio and Software
- General Discussions and Suggestions
- Chinese Forum
- Software Libraries
- Development Kits
- Reference Designs
- Third Party Tools
- White Papers
- Official Blog of Silicon Labs
- Chinese Blog
01-31-2013 02:01 AM - last edited on 11-28-2014 08:15 AM by Nari
OTM-02 is an open source watch module designed using KiCad. The project has a strong focus on using readily available off-the-shelf recent or latest technology, from global suppliers. That sentiment seems like it should be quite obvious, however it was only six months ago that the MemoryLCD which this module has in common with the SlimWatch project was even available as samples to most people. For the last few years I have eagerly awaited this period in time when really cool ultra-low power technology is readily available to the masses - so it's only right that a huge thanks goes out to Sharp Microelectronics for developing the MemoryLCD technology and that an equally huge thanks goes to Energy Micro for not only supplying their ultra low power range of MCUs, but for having a level of customer support in place that even a relative novice like me feels they might just about be able to make something quite exciting. Within the Energy Micro team I would like to pay special thanks to Anders, Filip and Adam, without whose heavy-lifting work they've done with code for MemoryLCD technology, my current MemoryLCD code would not be as efficiently integrated with EM's MCUs. Right enough waffle, you're here about a watch...
Only an early development prototype exists - no prototype PCB has been manufactured. A prototype should be made by the end of Feb 2013.
- Create a watch module that enables the end user to have complete control of its functionality and user interface,
- Discover the benefits - and any detractions - of (potentially selling) a product developed from the outset in true open source hardware style,
- Discover how much technology can be crammed into a wristwatch designed - and possibly manufactured - 'on the living room table',
- Design a module that with only a little extra effort, could form the basis of other devices, eg cycle computer, dive computer, data logger, etc.
The project utilises the following parts and features:
- EFM32LG332F256 - A USB enabled, Energy Micro ultra low power Leopard Gecko,
- A 128x128 pixel (23.2 x23.2mm visible area) ultra low power Memory LCD from Sharp Microelectronics,
- Recharge and programming via USB Micro B connector,
- Programming via ARM Serial Wire Debug (SWD) protocol also available,
- 150mAh Li-Po Battery + on-board battery fuel gauge IC,
- Vibratory Motor,
- Piezo Electric diaphragm,
- Five miniature right-angle tact switch buttons, (By MCU pin assignment and feature-set native to the EM MCU, with minor board layout editing, provision exists for alternate UI methods such as capacitive touch buttons.),
- Provision for a LED based planar light-guide type back light (utilising a 0.4mm high right-angle Avago ChipLED and laser engraved light guide. (N.B. This is highly experimental and yet to be fully developed. Any derivatives of OTM-02 with commercial intent should be aware this technology is heavily patented.)
- Possible feature additions in modules developed subsequently include: accelerometer, Bluetooth LE, ANT+, GPS
LCD and primary PCB area: 30.5 x 26.8 mm Including protruding Micro USB connector: 30.5 x 30.75 mm
Thickness: 6.5 to 7mm, including battery and piezoelectric diaphragm
Note: PCB is a four layer board and thickness is 1mm. Minimum track thickness is 0.125mm, used in connection with controlled impedance required for USB data lines. Most tracks are 0.15 or wider.
A non-waterproof, DIY 3D printing optimised case design is at an intermediate stage of development:
Other cases designed to be 3D printed in metal or other high-resolution materials are also being worked on as time permits.
The intention is to publish the source CAD data for at least one DIY 3D printable case design before the end of April 2013, earlier if possible.
Files and Images
The launch of this project on github is suffering a temporary setback due to internet connection issues. In the meantime, the initial release PCB design files and more images are all available at bit.ly/mtmpublic
A big thank you to the following people and organisations
(without whose experience and guidance this would have taken much, much longer.)
Mark Burton - SmartAvionics.com
Chris Middlemiss - Würth Elektronik
Paul Oliver - Würth Elektronik
Anders, Filip and Adam - Energy Micro
And special thanks for putting up with my often ironic obsession with watch making: My family, friends and colleagues.
OTM-02 is Open Source Hardware licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License and, excluding any proprietary files subject to third party copyright, will be open source firmware, probably released under the GNU Lesser General Public License v3.0 You are strongly encouraged to improve upon and hack OTM-02.
Will be posted here as time permits. Also keep an eye on the project repo at Github: https://github.com/hairykiwi/OTM-02.git
05 February 2013 - 01:35 AM: Image of PCB Rev.K replaced with Rev.L to reflect KiCad initial public release design data available on Github.
Latest edit: Reference to 'JTAG' programming corrected to read 'SWD'.
01-31-2013 10:37 AM
And thanks for sharing this with us!
01-31-2013 11:02 AM
02-04-2013 09:21 PM
Quick update: The initial public release files (Rev.L) are now available on github: https://github.com/hairykiwi/OTM-02.git
Just be aware that you'll need a recent version of KiCad to view or modify them. The schematic might load in the KiCad current stable release (kicad-2012-01-19-BZR3256), however the PCB itself will almost certainly not.
As recommended by AdamSch in another conversation, the schematic will appear on upverter.com/hairykiwi, just as soon as the guys at upverter have modded their conversion script to import the newer KiCad file format.
uSasha - Thank you - To be honest, back in September I was so deeply engrossed in designing the case you see in my first post - for showing the 3D printing bureaus exhibiting at the TCT Show - that I completely missed the competition. C'est la vie. I only discovered your project a few weeks ago - and much kudos to you! (initially, I just wanted a watch that behaved the way I wanted. I certainly never thought of adding an accelerometer to enable the kinds of bio-analysis your project aims to provide.) So after reading the rules, I decided any submission I made would be too close in its intent to yours. Also, I believe a product is ready when it is - so the competition is a bit of a time distraction. That maybe sounds a bit arrogant, but actually I'm just trying to manage my time the best I can. If you can utilise any aspect of OTM-02 for your own project - please do, I'd be delighted. Equally, I think it's possible that by ditching the LED backlight mosfet on OTM-02, and if a backlight is needed, driving the LED direct (with PWM), just enough PCB area could be freed up on OTM-02 to add one of the accelerometers mentioned on your project page. The physical challenge as far as I can see, would be getting the required SPI lines past the power supply ICs. Signal integrity wise - I'm completely in the dark.
Anders and AdamSch - I can't thank you enough for all your tech support, suggestions and ideas over the last 18 months of experimenting, learning and developing. The aspect that took the longest with this project was finding the technology and then the companies who sell the technology off the shelf - so I was was really happy to be able to fit a vibratory motor in the design - perfect for an alarm system, either when working in a noisy environment where a piezoelectric buzzer can't be heard - or where a discrete alarm is required. I agree, charge pad technology + Thinergy-type battery technology is going to be really exciting in the years ahead. Also relevant and very interesting are the micro energy harvesting systems you brought to my attention a while back: body temperature powered devices will be very awesome.
Rasmus - The short answer is no - I don't yet have an accurate indication of battery life/charge cycle for this design. There are too many variations, additional loads and quiescent currents to consider when comparing the dev prototype (below) with the OTM-02 module. But I do have a ballpark expectation of battery life of two to 4 weeks with a 1Hz display refresh. This is based on the STK3300 + 3V coin cell powered dev prototype below, which uses the earlier, but more efficient, 96 x 96 pixel 5V/3V Memory LCD LS013B4DN01. With no correction included for battery self discharge, using the STKs AEM feature, (and with my own inefficient code for driving the Memory LCD) I estimated battery life of 2 years for one display refresh per minute, and 2 months at 1Hz refresh.
By comparison, OTM-02 uses two sub-uA-quiescent-current LDO linear regulators to drop the (nominal) 4.2V supplied by the Li-Po battery - one is always on to supply 3V VMCU, the other, for backlight and vibratory motor is enabled as required. The battery life calculation is further complicated by changing voltage regulator efficiency, which starts around 70% for a fully charged battery (3V / 4.2V x 100%) and increases as battery voltage drops toward VDO (≅ 25mV).
So how does this look:
Assume 70% of battery energy is available (should be worst case, but still excluding self-discharge)
150mAh x 0.7 = 105mAh
Power requirement to display static image on 128 x128 Memory LCD = 60uW
60uW / 3V = 20uA
∴ display refreshed every minute ≅ 25uA average (guesstimate, based on prior experience)
105mAh / 25uA = 4200h
4200h / 24h/day = 175 days
1Hz refresh vs 1 min refresh, factor = 12 (based on empirical evidence - and best recollection - could be be better or worse)
175 days / 12 = 14.58 days
Now 14.58 days, according to a study Anders or AdamSch shared some time back, is about 7.5 days longer than most people need to loose a charger. Which is another good reason for including a micro USB connector in the watch itself, rather than depending on some kind of proprietary nonsense connector that none of your friends or colleagues ever has in an emergency. Speaking of Micro USB connectors, it will also be quite exciting when this splashproof MicroUSB connector from TE becomes more readily available.
Perhaps someone can share some good rules of thumb for applying average discharge-cycle battery voltage to the above calcs? In any case I'll do some tests as soon as I've built a prototype.
Also, I did try finding an ultra-low power buck regulator as they tend to be more efficient. However, the best low power ones I found still had a quiescent current of around 30uA - which would more than double the average current measurements I've seen, and so efficiency would actually drop to 50% or less. More recently, I've wondered if a hybrid buck-linear regulator might be worth experimenting with - where the MCU is used to control the switching mosfet (fully on at reset) connecting battery to linear regulator via inductor - but I'm getting out of my depth now.
As much as I like the idea of aiming for a watch with long battery life, (24 months) because of what the module was intended to be used for - an instrument rather than jewellery - I don't think battery life is the major issue. However there's no reason why battery life couldn't be extended significantly by sleeping the display when the watch is either not moving, (requires accelerometer) or between certain hours set by the user i.e night time, or by user-determined time-out. Display wakeup could be by shake of the wrist (with accelerometer) or button press.
(I'm not a qualified engineer, so please question anything that looks like nonsense - it could well be.)
02-05-2013 12:42 AM
Also, I did try finding an ultra-low power buck regulator as they tend to be more efficient. However, the best low power ones I found still had a quiescent current of around 30uA
Linear Technology LTC3388, 0.72 uA quiescent current
Linear Technology LTC3104, 2.6 uA quiescent current
Linear Technology LT3991, 2.8 uA quiescent current
02-05-2013 02:26 AM
Given the above, I'd possibly need to ditch both linear regulators. So the question is then, 'Is it good practice or even advisable to power the vibe-motor (with typical intermittent draw of 75mA) from the VMCU supply?'
Also, I've just been discussing my rough Li-Po battery / linear regulator efficiency calcs with a design engineer friend, and he had the following thoughts to share: In one of his his products, he considers his Li-Po battery to be charged at 4.15V and discharged at 3.55V - and the voltage fall to be reasonably linear within in that range.
So (compared to my earlier worst case assumption of 70% efficiency) approximate efficiency might increase as follows:
Approximate average voltage during battery discharge is:
3.55 + ((4.15V - 3.55V) / 2) = 3.85V
∴ approximate efficiency is:
3.0V / 3.85V = 0.78%
That's nearly +1.5 days run time over the 70% efficiency figures - or half the increase a buck regulator might provide.
So the buck vs linear regulator issue is looking like it's not really worth worrying about - but If I'm way out somewhere, please say.
02-05-2013 02:01 PM
What I am curious about is the memory lcd consumption estimates... Have you really measured it to be around 20 uA, or is that a datasheet number? Was this with the lowest possible refresh-rate of the com-inversion pin ( 0,5 - 1 Hz)? What we have found while working on the application note an0048, is that consumption when showing a static image shouldn't be much more than 200-500nA of the display alone. You can actually leave this com-inversion pin toggling at 1 Hz, even if you update the display faster. We just configured the LETIMER to toggle the com-inversion pin of the memoryLCD at 1 Hz, no need to worry about it in software. I think the 60 uW number in the datasheet is for 60Hz toggling of this pin... correct me if I'm wrong!
Total consumption of the software in an0048, displaying a digital watch face with a few lines updated every second, consumes only 4-5 uA, -> should give batterylife of more than 2 years (given 70% discharge, but not taking self discharge of lipo into account, probably more accurate for non rechargeable lithium cells, than lipo.)
02-05-2013 02:43 PM
I should point out that I haven't yet got my firmware configured for the 128 x 128 MLCD running on my earlier dev board as it was using 'software com-inversion' - it seemed easier / less risky at the time. Right now I have too many other priorities to convert it. In any case, the prototype OTM-02 should be ready soon enough.
02-05-2013 02:59 PM
I'm very excited about this project hairykiwi! I'm looking forward to the next prototype!
02-05-2013 09:35 PM
Sharp makes a 3V version of the 1.35 inch memory LCD, but it's only 96x96 resolution.
02-05-2013 10:20 PM
For a while during early development I used it to power the earlier version of the 1.35' 5V + 3V 96x96 MLCD: OTM-01 schematic
After the 3V model came out, I decided to experimented with my 5V + 3V version by removing the 5V charge pump circuit and running the display entirely from 3V3 VMCU. Even now it functions just fine - and more efficiently according to the figures from AEM. Perhaps the larger displays really need 5V, but I would be intrigued to see if you see any (noticeable) difference. Of course there's always the chance that running a 5V device at 3V is not going to do it any good.
02-05-2013 10:28 PM
02-06-2013 01:03 PM
In the process of doing 'one last check' prior to sending the board for prototyping, I began to question the way I'd powered the Maxim 17043 fuel gauge IC.
The MAX17043/17044 datasheet is not especially clear on how the one cell (1S) 17043 device may be powered - only giving info on how the two cell (2S) 17044 must be powered. As a result, I think I did a bit too much mixing and matching of the two recommended topologies.
Even after calling Maxim tech support in the States last night, I didn't feel much more enlightened - and it was only after casually browsing the internet this morning that I discovered Maxim released a more efficient, smaller (2 x 2 mm) version in Oct 2012, the MAX17048/17049 - available off the shelf.
As a massive added benefit, these newer devices can, in addition to active mode, (23uA typ.) be placed into either sleep (3uA typ.) or hibernate (0.5uA typ.) modes while continuing to track a battery's state of charge (SOC) quite accurately.
After reading the datasheet for these newer devices, I'm only now better understanding how the entire family of these battery fuel gauges function; the datasheet actually explains with graphs how the device determines SOC and also the impact the lower power modes have on accuracy.
So prior to prototyping, I'm going to rework the PCB design to incorporate the newer part... after all, It's only a (nother) 5 minute job
02-06-2013 04:32 PM
The watch is controlled by the efm32 itself, so you have fairly high degree of control of the current consumption at all times. This means that by accurately measuring the battery voltage, you can also make sure that you to a certain extent know the drain from the battery while taking the measurements. The efm32 also has an integrated temperature sensor which can adjust for temperature. The maxim SOC doesn't really do much more than analyzing voltage changes against temperature and correlating with an internal battery model to figure out the SOC of the battery at any given moment. I would guess that this could in theory be done even more accurately within the efm32.
Since you can control the current consumption while measuring the battery voltage, you could even measure internal cell resistance, which is one of the best ways to estimate how close the battery is to end of life, and detecting early end of life problems. Would also be easier to adapt to different battery chemistries if the soc estimator is just software running on the main processor.
Main obstacles to this approach I guess would be the research required to figure out a good battery model... Would be great if any other forum users have knowledge or feedback on this?
For now I think the solution you have with the maxim circuit is great. And if anyone know of any algorithm that could be run on the efm32, or want to make it themselves, it would be cool to compare the two methods. I guess the maxim soc circuit takes a bit of real estate on the board, and is a bit costly probably...?
02-06-2013 05:45 PM
*As the vibratory motor or LED are the heaviest current drains, a SOC measurement could even be initiate a few minutes after (to allow for any voltage settling) each had been operated to ensure a more accurate battery SOC indication is maintained.
Can you or anyone recommend an ultra-low power reference circuit for measuring battery voltage using the EFM32?
This switchable one looks sensible: microbuilder.eu/Tutorials/Fundamentals/MeasuringBatteryVoltage.aspx - but the ideal would of course be a self contained IC with the same functionality.
As I've 'lost' the three components I mentioned, I might just be able to find room for a measuring circuit like the one above. It would then be relatively straight-forward to compare in real time, the abilities of the EFM32 vs MAXIM.
02-07-2013 10:59 AM
02-07-2013 11:58 AM
Yesterday, I did find one dual mosfet package which looks like it might be ideal for the job of switching a resistor divider for ADC battery voltage measurements:
ON Semi - Power MOSFET 8 V, ±3.3 A, Load Switch with Level-Shift P-Channel, TSOP6 - Datasheet
It's not single a IC solution, but it should reduce component count to four, compared to seven in the discrete-based topology in the microbuilder.eu link I posted earlier. In terms of component count, that's an improvement over the MAX17043, and the same as required by the MAX17048.
It did get me thinking though - what's the longest distance over which an ADC voltage measurement can be reliably made - compared to the I2C solution? There you go - a good question for you to answer in your new thread
02-07-2013 07:24 PM
I just tie the high end of the resistor divider to the battery, the low end to a GPIO, and the middle to an ADC input. When measuring the battery, I drive the GPIO low and enable the ADC. The rest of the time I disable both pins, so that there is no current through the resistor divider.
02-08-2013 10:37 AM
I don't understand why you need any MOSFET(s) at all.I just tie the high end of the resistor divider to the battery, the low end to a GPIO, and the middle to an ADC input. When measuring the battery, I drive the GPIO low and enable the ADC. The rest of the time I disable both pins, so that there is no current through the resistor divider.
But this solution would violate the maximum ratings for the EFM32. When no current is flowing in the resistor divider, the voltage at the ADC input and GPIO will be higher than Vdd+0.3V, and probably higher than 3.8V as well. Even if no current is flowing into the pins, this could damage the efm32 in the long run because the high voltage might end up at the gate of a transistor inside the chip. Transistor gates are sensitive to high voltages.
02-08-2013 08:41 PM
Perhaps you could solve the problem by adding a nFET in the middle of the voltage divider, with the gate tied to the EFM Vdd, and the ADC input connected to the node between the nFET and the lower resistor. The nFET will stop conducting as the voltage approaches Vdd. The circuit has only three components, two resistors and an nFET. However, I haven't tried this or even simulated it.
02-11-2013 10:51 AM
02-21-2013 09:28 AM
Ten days ago, after some last-minute tweaks, I finalised the first PCB at Rev.M and sent the files off for manufacturing. You can probably still hear my wife whooping for joy because it means we're also another step closer to more house renovations being [s]started[/s] completed.
Of course, as soon as I sent the board for manufacture, all my silly mistakes came out of hiding; there goes the house renovations for another month. Never mind, right now I'm feeling as excited as kid waiting for Christmas - and I think some of it is even rubbing off on my wife. Or is that her brave face?
So what changed in Rev.M?
Special thanks to uSasha for his great idea of fitting an accelerometer to a watch, and especially for sharing the existence of the ADXL362 ultra-low power accelerometer. As well as potentially doing the kind of cool stuff he's working on with his lifestyle-monitoring-wrist-watch project, it should also help save battery life by initiating EM2 in the EFM32 (Deep Sleep mode with RTC retention) when the watch isn't being used, before entering its own 270nA motion-activated wakeup mode.
Anders, your self-discharge analysis and suggested solution for 'roll-your-own' battery SOC monitoring sounds very practical - it's sometime easy to get carried away with saving every last uA. It wasn't so much a decision of fitting either the accelerometer or resistor divider network, I just ran out of enthusiasm for ripping up and relaying PCB tracks, 'just one more time'. But it will be a nice feature to experiment with and 'just a 5 minute job' for Rev.N
Soon after the files were sent for manufacture I began finalising components and suppliers - and that took way longer than expected. Even though I'd started researching component availability months ago, I'm beginning to appreciate just how fickle component sourcing can be. Anyway, at long last, here is the BOM for OTM-02-RevM. You'll find the PCB issues / bug tracker there too, (it will move to github eventually) and also a hint at where Rev.N might be going after the discovery of some really nice, super-low power absolute pressure gauges from Bosch - thanks to chickenHeadKnob over at the EEVBlog forum.
By early next week I should have enough components to start PCB assembly. It will be my first time using the hotplate-reflow technique, with temperature control courtesy of the osPID.com project - something I've been really looking forward to experimenting with.
I mentioned earlier I'd made a few silly mistakes. Some of them might have been avoided if I'd tweaked the colour settings in gerbv - or for a bit more fun - used the free 3D gerber viewer webapp at mayhewlabs.com/3dpcb, (renderings below).
It's not able to render the true board outline, possibly because it doesn't handle outlines using arc segments. Also, there's an anomaly with the top solder resist rendering in some places and not others, (compare the 2D gerbv screen capture below) but besides that, it's a very welcome addition to my 3D gerber-viewing tool box.
I also discovered zofzpcb.com in the last few days - another free, gerber renderer project using Direct3D - with the capability to do fly-through animation effects. It's still in early release, but if nothing else, for adding a bit of bling to a project video, it's worth checking out the demo video: youtu.be/3VZUVkK4ZNc
Below are the Mayhew Labs generated images. Spot the problem with the <0.1mm clearance between some of the solder paste stencil holes on the motor mount, top right. Doh!
And another annoying mistake, below. I added some PTH to the battery connector footprint, to remove dependency and improve flexibility of the design, (especially while testing) and in the process obliterated some of the OSHW logo text.
Rev.M gerbv screen capture for comparison.
I'm out and about at the moment and having problems pushing any updates to github - github.com/hairykiwi/OTM-02 from public wifi (using gitbash under Windows - what a PITA!) So Rev.M design files and BOM converted to csv will appear sometime next week; along with photos of the first board all being well.
02-26-2013 12:25 AM
Do you remember when you counted the passage of time as sleeps until Christmas, you were so excited? Well all going well, I reckon another 2 or 3 before you'll see an assembled board. Then a few more before the existing firmware and graphics are massaged enough to display anything useful on the newer model Memory LCD. Then we might just have to have a party. After all, I've only been patiently waiting for access to all this technology for the last 7 years.
Here's some of the larger components in position, plus one lonely 0402 (1005 metric) capacitor, just above the largest pad - where the EFM32 will live.
02-26-2013 09:09 AM
Great progress, can't wait to see the Gecko in its natural habitat.
03-13-2013 10:47 PM
03-15-2013 07:50 PM
A quickie update. No assembled boards to show yet, sorry - but I have survived a week of hardcore experience with the osPID controller connected to a 20€ hotplate and practicing with a dummy PCB + Pb-free solder. Silly to wreck £90 worth of components for the sake of rushing a job. I think I did well to avoid burning down the house or worse, smoking the cat, (wife was safely away at the time). The problem is the temp differential across the PCB - approx 30 degC. Which translates into just about burning the bottom of the board when the solder paste on the top surface just melts at around 218degC. I could try Sn-Pb solder with its lower melting point, but that's too easy, and contains lead - *and* I'm crazy enough already. More fun to try a mini-oven connected to the same osPID controller. Pics and more details to follow next week.
It so exited to read your updates!
04-05-2013 08:17 PM
Yesterday evening around 19:50UTC, and after six hours of PCB assembly involving getting comfortable with some new tools and assembly methods, (and patching my trusty old IBM T23 Thinkpad with five years of XP updates just to get the USB microscope to work) the first assembled OTM-02-RevM popped out of the oven on to the [s]dining-room[/s] in-home-workshop table!
I was really happy with the resulting registration of the MBO 305SAC solder paste - and it really does last 18 hours+ at room temp prior to assembly, without drying out. The PCB is 1mm thick and jig material is made up from a few old membership club cards approx 750um thick (not ideal but it worked) taped to the backing board on which the stencil was delivered. The next stencil will be much better optimised for volume of solder paste on every pad - in much the way it is now for the EFM32 QFN64 package. Thermal / GND vias for the two linear regulators and EFM32 were filled with peelable silicone mask. This appears to have been a good solution to stop any solder-wicking.
Tools of the trade: ESD mat, scalpel, angled tweezers, needle, hand vacuum pickup - hacked to run off a 200l/hour aquarium pump operating with valve reversed. Dispensing needles for vacuum pick-up are 25 gauge (blue) and 23 gauge (black). Vacuum strength/needle size was perfect, in that when each component was placed, the solder paste has enough stickiness to retain the component without needing to release the vacuum pressure. Currently I'm operating the valve (a tee-junction) with my right index finger, but after discovering how easily this method works, I'll relocate the valve back to the pick-up tool body, which then frees my right hand for steadying duties. (The original concern was that releasing the pressure with a body-mounted valve would unduly nudge each component as it was released.) USB microscope is 'only' 640x480 30FPS, higher resolutions available with less FPS - but perfectly adequate. Adafruit sell them for USD149. I found the same one(?) on eBay for USD79 - delivered from the UK or USA, so no import duty to pay either. Assembly drawing has colour coded components; BOM lines were coloured to match, printed and affixed to the component cards (on top of oven at right). Thanks to MikesElectricStuff for all the tips and tricks in his video - all a huge help.
I'll let the following images (mostly) speak for themselves:
Relative location of the 3kHz piezoelectric diaphragm, (brass disc) which will be attached to inside cover of the watch case-back - on top of the battery. Battery leads yet to be terminated in a connector body, (not shown) which in turn will mate to the white PCB mounted connector, (JST PCB header).
The above and more images are available in full resolutionhere (All content CC-BY-SA-3.0 Hamish Mead)
After years of dreaming and months of designing, it really felt completely surreal last night to be touching and holding this - much - technology! (Some of the ICs are only a few months in production.) And even more so to think, 'I made it.' At home. Baked in an oven costing less than £30! So time for another huge thanks to everyone who has helped me get to this stage - thank you, thank you, thank you!
It hasn't yet been powered up, but I I've learnt so much in the last 6 weeks, and in the last 24 hours especially, that I don't really care if this prototype does or doesn't work - I now know it can be done.
I'll post some more regarding my experience with the reflow hotplate and oven - trials and tribulations of the last few weeks - in another post. Right now it's beer o'clock.
04-08-2013 09:56 AM
When you get far enough to run code on the efm32, it would make for an awesome demo if you just run the memory lcd code we have released in appnote an0048. Includes analog/digital watchfaces and some more screens with animated sliding between. Feel free to use it/modify it as you like!
04-08-2013 01:40 PM
04-20-2013 02:46 PM
Allow me to go off on a pie-in-the-sky tangent: I'd love to get my hands on one of these bad boys to try and code up a gesture-based alarm feature. That is, if someone's planning to produce a few of these in the future - sadly I'm too lazy/unskilled at the moment to make one myself
Onto the alarm stuff: Timex have this 'easy set alarm' thingy, where you can set an alarm by just adjusting the watch's bevel and pulling one of the pins. Problem is the guys stopped producing the model that vibrates, so what I'm left with is the one that makes way-too-loud piezo noises - not exactly usable at work, for example.
I wonder if OTM2's accelerometer will be noise-free enough to be able to support some kind of gestures - say a flow like:
Now, depending on the SNR of the accelerometer, this might result in an intuitive, precise alarm setting with minimal movement, or me swinging my arms around like a mad man. But it's worth a shot, methinks
Man, I'm definitely putting this thread on watch. Cheers for doing this project, mate!
04-20-2013 07:19 PM
Thanks for your enthusiastic interest in the project
It's nice to see the project getting a mention around and about - thanks for sharing the CNX link!
Pie-in-the-sky tangents are all very welcome here. I think it's one of the greatest attributes of the OSHW philosophy that anyone's free not only say, 'what if?', they can actually have a go at making it happen, learn something in the process and share that knowledge for the common good. This project is in fact a bit of a tangent from my original idea for a watch, but more about that in another post - back to your really cool idea...
I have to admit I have absolute no idea whether the SNR of the ADXL362 accelerometer is up to the task for implementing your idea; half the time I'm just a novice trying to run faster than I can walk. The EM guys might have some thoughts, and so might uSasha - and also my good friend and design engineer Mark Burton at SmartAvionics.com (I'll ask him and get back). One way or another, we'll find out soon enough and either way, I'd be happy to sell you one of the assembled prototype boards - but only after I'm happy the first one works with at least basic functionality as intended; I've no interest in wasting anyone's money or time by selling junk.
BTW, after reading the CNX blog post you linked to, I just remembered an error I need to correct in my very first post - 'JTAG' should instead read ' Serial Wire Debug - (SWD) protocol' as one of the programming interfaces, the other intended one is 'USB bootloader'. Thanks for the reminder
Right, back to eating time - and hopefully an interesting update in a few days.
04-20-2013 09:43 PM
04-21-2013 10:38 PM
I'll also take the opportunity to apologise for the github PCB data being one revision older than the prototype (RevM) manufacturing data. I'm playing catchup - and at the same time trying to push things forward. I'll attend to the revision update as soon as the first software is running with basic LCD + button functionality. Things got a bit out of synch between laptop, PC and github after I never managed to push updates to github via WiFi when I was out on the road. So I just need a quiet moment to sort things out.
In the meantime, thanks for your interest. And patience.
04-22-2013 07:27 PM
The 128 x 128 Sharp Memory LCD LS013B7DH03 is now in stock at Mouser!
Mouser Part Number: 852-LS013B7DH03
At £14.68 each for one or £13.22 each for five they're an absolute bargain!
04-23-2013 09:56 PM
The product I'm developing uses the 2.7' 400x240 display (LS027B7DH01), which uses about 50uW static. However, it needs 5V so a charge pump is needed to get 5V from our 3V supply. It's difficult to get high efficiency at such a low current, so we end up using about 100uW for the static display.
04-24-2013 09:24 AM
04-24-2013 10:35 AM
This is interesting as we measure around 300 nA consumption for static display at 3V that is less than 1 uW. The difference must be because of a difference in frequency on the com-inversion line that this display requires. This triggered me to investigate a bit further, why don't Sharp use the best possible consumption value for static image?
Turns out that the latest datasheet available from mouser (the one brouhaha linked to) have different minimum specs for the com-inversion frequency than the earlier dated datasheet (or rather Technical Literature as they call it) that we have used. The document we have used here at Energy Micro is dated October 19, 2011, doc number: LCP-2111042. The one at Mouser is dated September 6, 2012 and with doc number LCP-1112045.
The newer LCP-1112045 document has much more information about timing of signals etc. and seems to be more rigorous on these specs. The peculiar part about the EXT-COMIN frequency is that is has changed minimum value from 1/2 Hz in LCP-2111042 to 54 Hz in LCP-1112045. But in LCP-1112045 there is also a note that EXT-COMIN frequency must be less than the frame-rate frequency. Minimum frame rate frequency is given at 54 Hz. For a static image the frame rate is obviously 0 Hz, there is no toggling of the chip select signal. If EXT-COMIN still should be more than 54 Hz in this case is unclear, but it seems that Sharp has chose to do this for their consumption measurements.
I've added some shapshots of the information in the two documents, I'm not sure if the eariler LCP-2111042 is easily accessible on the internet or not. The change-log in each document state that it is the first release. Would be great if someone could shed some light on this as it affects current consumption quite a bit. We have run several memory LCD's here at energy micro for over half a year without problems at the low 1/2 Hz EXT-COMIN frequency.
04-24-2013 12:58 PM
It has ended up on hackaday: http://hackaday.com/2013/04/23/otm-02-is-a-3d-printed-wristwatch/ congrats hairykiwi!
Cheers AdamSch! Thank you and Anders and everyone at Energy Micro again - for your tech-support and guidance during the past couple of years in helping to get the project off the ground.
And thank you to everyone dropping by for your interest - please do keep on sharing the project
I can't promise the end result will be anything particularly special - or if the prototype will even work - but I do promise the core OTM-02 module designs will always be open source to the fullest extent possible, and that hacking and re-utilising the design will always be encouraged.
04-24-2013 06:52 PM
In the meantime, brouhaha and Anders have filled in the blanks and Anders has added some interesting detail. Thanks Guys.
Looking in AN0048 at the bottom of page 10 it says, 'The profiler output for the digital watch is shown in Figure 4.3 (p. 11) and the average current consumption is only 4.4 μA.' So that would be 14.5uW at 3.3V.
AN0048 is full of excellent info about Memory LCD useage - and it might even provide a better idea of real world power consumption for a range of typical usage scenarios than the Sharp datasheet; notwithstanding Anders recent cautionary comment about the impact the apparent change in spec to the minimum COM frequency would have. So I also agree with Anders that Sharp's latest COM refresh frequency figures need some explaining in view of both his and my experience with, in my case the earlier model Memory LCDs running on development hardware for 2+ years, albeit intermittently, and with no noticeable problems. For the meanwhile, I don't intend increasing COM frequency on these new displays; lets see how it goes.
From my own experience, 14uW, possibly a little less, is about right for the AN0048 digital watch_demo (i.e. a limited area, 1Hz display refresh rate) running on the STK3700. I mention 'STK3700' because I did notice the light sensor, when left uncovered, is contributing to the project's total current draw - see the image below.
Finally! Some tangible progress in the software department:
'Sanity Insurance', with energyAware Profiler in the background. The difference in Energy Mode 2 (Deep Sleep) current draw i.e. the current drawn between the display refresh spikes, between left (28.5uA) and right (3.43uA) side of the energyAware Profiler window, is the result of covering the STK3700 light sensor for a 'half window' period, prior to pausing the Profiler.
As an interim step, a few days ago I thought it would be prudent to get the AN0048 touch and watch demos running with the new 128x128 LS013B7DH03 display fitted to the original STK extender board, after modifying the extender board to align pin assignments with the AN0048 schematic. I'm hoping it should provide some 'sanity insurance' against the really nasty head-scratching that can occur with a new hardware+new firmware design.
Also another small but joyous milestone just yesterday evening: I finally achieved building the AN0048 watch_demo from source using emIDE, an open source IDE based on the Code::Blocks IDE. Until now I've been quite spoilt by IAR's very capable, but 32KB code size limited EWARM Kickstart IDE. After running into that code size limit when I first tried building the watch demo in EWARM KS, I have Anders and AdamSch to thank for giving me the kick in the pants (via PM) I needed to get an open source toolchain up and running for the project. It was not without some learning pain, but worthwhile - and far more appropriate for an OSHW project in any case.
The first toolchain they recommended me was Eclipse+GCC. Energy Micro has a nicely detailed, well paced tutorial (AN0023) to help in setting it up. I did eventually get Eclipse+GCC working, but the idea of telling anyone else they need to read a 23 page manual as a prerequisite to getting started, didn't really appeal. So when I rediscovered emIDE via the thread by Kjell E, I was sold. Thankfully, Kjell E also supplied an emIDE template project file in his first post, so that further reduced the adoption-pain barrier. That project file interfaces with a project make file - and I did find it a bit of a pain getting the two aligned. But the makefile approach does, AFAIU, at least ensure OS independence.
Compared to Eclipse+GCC, I found emIDE much less hassle to install and get the first blink project working. Additionally, it's lightweight (48MB), cleaner looking, (easier on the eye) and Segger's J-Link is very nicely integrated, thanks to some work Segger did for the project.
Unfortunately I haven't yet got the integrated J-Link gdb server to load binaries to the STK3700, but the binaries produced via emIDE are functional after being loaded with EM's energyAware Commander. I'm sure it's not a big problem to sort, (according to Gelmi in this thread - just another 5 minute job to attend to.
The only cause for concern regarding emIDE so far, is the relatively large watch_demo binary size it's generating compared to what I presume is an IAR EWARM generated one as supplied in AN0048.
AN0048 watch_demo.bin size
emIDE: debug 80KB | release 76KB
IAR (precompile) 48KB
As this post has evolved into an update, I should also mention the prototype OTM-02 successful powered up, without code, a couple of weeks ago. So it looks like the board could be in good shape for our next stop - Hello World!
On that note, it's back to the grindstone.