Technical Difficulties

v6, maybe we'll make a few

2017-01-23T19:09:36+00:00

So, it’s been a while since I bothered to document anything, but if you’ve been following the git repo, you’d know that the work continues apace. v5 has come and gone; I made substantial changes to the layout, built a version with working pushbuttons, and wore it for a while there. Then, life caught up with me and I didn’t work on anything fun for a while, but now I’m back at it.

One day, while I was contemplating if I should add yet another feature, I thought that it really sucks that to add any features I have to change the board layout, wait two weeks for a board, and then see if what I’ve done actually works. Then I thought, why don’t I just break out a bunch of GPIOs and make Ourglass like a dev kit? That’s how v6 was born.

I’ve shared the new boards on OSHpark for the curious. Version 5 was an incremental improvement on 4, but rebuilt from scratch. All of the parts were moved around, and some features with interrupts were added. Version 6 is based on version 5, but the l-shape has been changed to a rectangle, the expansion header added, and now the design is double sided.

The sharp-eyed may notice a few other things: there are test points and fiducials on this version. Version 6.5 is the first pass at making Ourglass production ready. I’d like to produce somewhere between 200-1000 boards, which seems to be a sweet spot for this kind of run. If I’m selling just the board (no battery, no screen, and no case) they’d cost about $60 in that quantity (to buy; manufacturing cost is about half that). With battery, case, and screen, it’s more like $100. This would have to be a limited run, since to make a real commercial product I’d also have to have FCC certification. I could see doing 1000 at a time, though. Crowdsupply or Massdrop, with a laminate case, similar to the early prototypes. Notably, you can get silicone laser cut to spec; I think that would be really interesting.

Also a part of the work of getting to a product: Getting the software toolchain up and running. Out of the blue, around the beginning of December, someone from the Apache Mynewt project reached out to me. They have a fully open-source RTOS based on the NRF51/52 including bluetooth stack. There’s no compatibility with Arduino, which was a goal of mine, but I think there are two ways to go with that: either write a bunch of tutorials for working with MyNewt in the openocd toolchain, or figure out what’s needed to build a compatibility layer. I think both are doable.

In an ideal world, you’d be able to upload a program over USB or BTLE from the Arduino IDE; this lowers the bar for beginner-level entry. Then, for advanced users, the source for the whole stack is available, and it can be programmed over SWD. My bet is that most users will want to tweak a little, and some people will want to build a whole interface from the ground up. I want Ourglass to be a platform that enables that kind of experimentation.

how to build v4

2015-10-15T05:19:52+00:00

This post is part of what I hope to be a series that will de-mystify and put in one place all the things I’ve learned constructing these things, and at the same time lay out the steps to building a working version of the watch as it is now. First, we’re going to talk about tools, and then I’ll lay out the current BOM, and how to go about getting some of the parts and material that are hard to find.

Tools

note: I don’t get any referral money from any of my links; wherever possible, I link to where I got something, or a known reputable source. A lot of these links will be to Adafruit, because they have all the best stuff.

The difference between a good tool and bad tool is measured in the hours of frustration the bad one will cause you. Yes, you can accomplish a lot with minimal tooling, and the good stuff doesn’t have to cost a lot. For example: this pair of tweezers is really very good, and very reasonable at less than $4. So, the list, with some annotations:

Soldering Iron – Why would you need one of these for a surface mount project? There are four through hole joints to be made, but you’d need it anyway, to clean up the inevitable bridges.
Solder wire – For the through hole joints. If you’re in the EU, you’ll want the lead free ROHS compliant stuff: here.
Solder Paste – This stuff is kinda amazing. It’s a low-temp solder paste that makes SMT work a lot easier to control. Instead of a precise reflow curve to avoid damaging components, you just heat till it’s all liquid, wait ten seconds, and turn off the heat. If that link dies, search digikey for “SMTLTLFP”. It’s also ROHS compliant!
No clean Paste Flux – Another thing that’s cheap and handy to have around. It helps solder flow onto a joint, or onto your solder wick.
Solder Wick – This is a braid of fine copper wires which wicks away solder when you heat both at the same time. You can remove excess solder, or even desolder some components with it.
Tweezers – I actually have two of these on hand, because I don’t want to do without them if I mislay them somewhere in the junk pile that is my desk. You’ll use them for placing all of the components, removing stray hairs from the board, plucking hot components from molten solder (don’t worry, we’ll get there).
Soldering Iron Stand – Nobody ever told me how great these were, so I’m telling you. A stable place to put your iron while it’s hot is essential. Note: Sometimes the spring on the inside will pop off; just push it back on. It’s safe to use that way, but not as stable as having both springs.
Hot Air Rework Station – This is probably the only really big ticket item on the list. You might be able to do without it, but remember what I said about frustration?
Halogen lamp – This is what is going to heat the whole board up for reflow. Note that the Home Depot is bad at online ordering; you’re better off going to a store. Any single bulb, 500w lamp should do the trick. SAFETY WARNING: hot lamp is hot all over, except maybe on the handle and base. It will set fire to things that touch it, so use caution.
Programmer – You can also use an arduino with the chip pulled, both methods are very similar.
Wire Snips – Another item I did without for years, a good pair of flush cutters. Their usefulness can’t be overstated.

Parts

Now that we’ve talked about the specific tools, there are a few parts that are peculiar to this BOM that can’t just be stuck in a spreadsheet.

The PCB – This link is to v4.4, which will soon be replaced by 4.5. That said, 4.4 is fully functional, but the screen folds the wrong way. I'm fairly sure it'll fit in the case still (target was < 4mm). I'll update the link when it's there. 4.5 is there! New balun, fixed screen connector. OSHpark is the best, and given the size of these traces, I wouldn’t recommend any of the cheaper options for PCB fab.
The paste stencil – Not required, but without a stencil, putting paste down takes about half an hour. With it, it takes about a minute. You’ll have to grab the cream layer from the Github Repo and upload it yourself, since oshstencils doesn’t have shared projects.
Battery – These are often out of stock, I don’t know why. There’s a 110mah version that you could also use.
Case – No link, because this is one of the places the ‘Y’ in DIY happens. Also, my case designs are rubbish, and I don’t have any for the v4 series movement. I’ll probably post an STL when we get to that phase of the howto.
RFduino – This is the brains of the operation. To get the chip with a bootloader, you’ll need to buy one of these and desolder the RF sheilding, and then desolder the chip itself. This is where you’ll be glad you got the hot air station, or borrowed a friend’s. You may be able to hear up the RFduino on the halogen light to desolder it; it’s worth a try. After desoldering, you usually have to clean some solder off the center pad with solder wick.

The rest of the BOM is here, but some of the links are stale. I last updated that for version 4.1, and we’re at 4.4. The BOM is pretty stable at this point; I don’t see changing it much.

And that’s it! probably a $200 investment, if you can borrow a hot air station, or more like $300 with it. Order 10 or more of the components that cost less than a dollar, since they’re cheaper that way, and you’ll need extra.

gave a talk at magmaconf

2015-06-22T06:50:15+00:00

Blogger’s note: I wrote this shortly after coming back from magmaconf, and then forgot about it. Oops.

This last week I’ve been in Mexico, giving a talk at Magmaconf . The conf was awesome. I genuinely enjoyed all the talks I saw, and was sorry to miss the ones that I was in the pool or at the beach for. There were two other hardware talks, and I got a lot of compliments on mine; The guys from Hybrid Group, especially Ron, got everyone hyped up about the hardware future, and then I came in later that morning and showed everyone how to get started making that future.

Here’s the genius of the conf: the pool/beach are really the hallway track, but with beers and relaxation. Sun, heat, cool off in a pool, wade into the ocean. You might be thinking “That sounds like a recipe for some harassment nightmare,” but no, they have a strict anti-harrasment code of conduct, posted right on the home page. Very cool, and AFAIK there were no issues.

Anyway, the v4 work continues apace. I assembled a rev0 board and discovered some errata. The footprint I made for the quartz crystal was wrong, and there was also schematic error. I had the wrong part number, and so was wiring the power regulator wrong. Rev1 is at the fabricators now, and it should be done maybe a week from friday? I also put up a github repo: mattmills/ourglass that has the schematics and code that I’m currently using. It’s missing all the older iterations, but that’s not a huge loss. Anyway, it’s 2am and I’ve been up far too long.

Also notable: After four revisions, I finally have a decent handle on version 4. I may do a fifth, but the fourth is working. The screen didn’t work for the first three, but that’s because I reversed the order of the pins on the screen connector part. Yr. hmbl-er blogger.

v4 at the fab

2015-05-12T04:49:27+00:00

So, I changed my mind again. I was about 2/3 of the way through breadboarding the fourth version of the watch circuitry, and I decided I didn’t want to build a SPI bus with multiple slaves. That, and 8mhz was really too slow. So, I went back, and re-designed with the NRF51822. It’s a fine chip, and somewhat reduces my part count.

I’ve sent the board version off to the fab, but not much else has changed. I’m going to desolder the NRF from one of my RFduinos, to skip building a bootloader for now. It’s a pretty simple matter, but there aren’t any open source examples that I can find, and so I’m taking the easy route. If I ever produce more than one of these at a time, I’ll build a bootloader from scratch, and try to make it as open as possible. The softdevice that runs the radio is a blob, which is unfortunate, but there’s nothing I can really do about that, unless I end up making tens of thousands of these things, and can hire someone to build an open version. I’ve looked around for alternative ARM M0 chips with bluetooth, and there aren’t that many. NXP makes this one , but it also has a blob for the BT stack. There is an open-ish bootloader for it, in active development, but there isn’t really any reason to switch at the moment. I’m sort of thinking the next version will have wifi, but the power requirements for that are nuts.

Things I need to write about: Using KiCad, from schematic to board. It’s actually not that bad, once you figure out a few things. Also, design considerations for manufacture, which I’ve mostly been ignoring. Through hole components are bad, and dense packing is bad. I don’t have any ground planes in the current board, which means that I’ll probably have weird intermittent faults, if it works at all.

arduino micro as ISP for atmega1284

2015-01-20T06:09:38+00:00

TL;DR- use the labeled hardware SPI pins and AVRdude, and life is good.

This is a tale of woe, of how I tore apart a day’s work trying to get to the bottom of something, and then solved it sitting at the bar waiting for trivia to start. Basically, I have some stuff on hand to build a breadboard version of the v4 Ourglass. I need to do this to validate my circut design, as well as measure some things about power consumption and timing (see previous post). There are a bunch of resources on how to build a “boarduino” online, but a couple of my parameters are out of the ordinary, and threw me off.

First, I’m using an Arduino Micro , which isn’t like all the other Arduino boards. The hardware SPI is on the ICSP header. So, the setup is something like:

Arduino Micro	→	1284p (pin numbers)
MOSI	→	6
MISO	→	7
SCK	→	8
D10 (reset)	→	9

You also need to connect the VCC, both GND pins, and AVCC; those are well known, and left as an exercise for the reader (seriously, consult the data sheet). Once everything is hooked up, you’ll need to decide how to set the fuses. I used this online fuse calculator (edit: be careful, and read around about how to set your fuses properly, I’ve bricked my chip since getting it to work by messing around). There are probably others, and of course, you can just stare at the data sheet and figure out 3 bytes yourself. I’m using the internal oscillator, and setting the brownout to 2.7 (since I’m running at 8mhz and 3v). In reality, I could probably disable this altogether, since the battery I’m using has a pretty sharp cuttoff, but it’s strongly reccomended here to leave it on if you’re using a bootloader at all (also covered more in depth here).

I picked a bootloader mostly at random, from this post about bootloading the 1284p (using an uno, which lead me to waste half a day). I may regret this; I haven’t verified that it works, but avrdude reported success loading it onto the chip at least. Edit: still waiting on the final verdict, as I need an external oscillator for serial communication.

So, in the Arduino IDE, there’s an example sketch called ArduinoISP. You’ll need to change the line “#define RESET SS” to be “#define RESET 10”. Then load it onto your micro, and you should be able to use avrdude to load your fuse configuration and bootloader. You can also use the IDE, although I haven’t tested that; you need add the hardware descriptions to your personal ~/Documents/Arduino/hardware/ (on mac) and restart the IDE to get the board type. This will also set the fuses based on what’s in the boards.txt, so make sure that reflects what you want.

Of course, since getting this more or less working, I’ve managed to brick the thing, so now I have to wait a week for another chip to come in.

january update

2015-01-19T05:04:19+00:00

Let’s see… last time, I was struggling with what processor to use, now I’m struggling with how the hell to keep this thing charged. The idea is to use a couple solar cells to make it autonomous. I’ll have to figure out how to flash firmware over the air too, but that’s not super hard… the hard part, as usual, is power. I ordered one batch of cells to try, but they were too delicate and only had one solder point on each cell. I should have known not to order from Edmund Scientific. After destroying those, I started working on a boarduino that’s more or less equivalent to what I’m planing on for v4.

So, let’s talk about v4. It’s based arount the atmega 1284p, and the nordic NRF80001. Same accelerometer and RTC as version 3, and for now the power supply is mostly the same. They may change as soon as the second round of solar cells come in, but the charge IC I’m using now might work, at least if I’m reading the spec sheet right. I have been wrong before. For example: I thought I was going to run this version at a much lower clock speed, to save power. As it turns out, I wouldn’t ever be able to put the processor to sleep if I ran it that slow, so I’m stuck using it at 8mhz. I may try it anyway; 1/2 the power means 1/2 the surface area of solar cells to keep it charged. I’m also hoping that the AVR is more effecient than the nordic. We’ll see.

I do have most of a schematic for it down in eeschema, kicad’s circuit design program. I don’t have the bluetooth part or the buttons. The buttons are trivial, and the radio is based on the reference design in the data sheet. So, mostly copying that over and tailoring it to fit my needs. FCC certification is a problem for when it goes on sale, if ever. My luck, it’ll be leaky in all the bands, and require massive sheilding. TBH, I think that’s how a lot of designs go, those little folded metal covers over parts of the board.

I have some preliminary thoughts for the shape and dimensions, too; hopefully thinner, but roughly the same area as the current iteration. This board version should have a cutout for the battery, and thus be a bit thinner overall. I’ll also probably farm out a 3d-printed version of the case, and use thinner plastic for the face of it. 8mm is the target, not counting the strap lugs. The solar cells may be links on the band, too, but that’s just a concept for now. I need to see them to know if I can use them that way or not.

Next post: how to use an arduino micro as ISP for a ATMEGA 1284p. If I feel up to it.

further work on v4

2014-12-02T23:47:32+00:00

So far, there’s not a lot to show for v4 of the watch, just a lot of ideas. I’ve figured out the hook, though: a smart watch that you never have to charge. Basically, I have to pull about 500uA/hr (maybe as low as 100uA with the right sleep modes) out of thin air, and it’ll never have to be plugged in. You can’t get something for nothing, but most of the time people have an energy source all around them: Light. A calculator solar cell like this one (second one on the page) will, I think, produce enough power.

To get there, you have to do a bunch of stuff. The accelerometer I’m using has sleep modes, so we’ll turn those on when we’re not taking a measurement, and disable the power hungry gyroscope altogether. The processor can be slowed down to 1mhz and also slept for intervals. The RTC doesn’t have any low power modes, but it’s already pretty low-powered. The screen hardly uses any power, but LEDs for backlighting will; we’ll need to be careful about those. The radio, according to the data sheet, only consumes a lot of power when it’s advertising; once paired, it’ll be in the 10uA (average) range. Processor, radio, accelerometer, clock, screen, backlight.

walkin blues

2014-11-10T07:04:49+00:00

The work continues apace. I’ve decided to go with an AVR, mostly because the other processors under consideration either require some closed source stuff, or libraries wouldn’t be compatible, require a lot more software to get something running. Not that I’m running stock anything, really, but example code and well-written libraries are a great start.

Speaking of well-written, the code for counting steps is coming along. At first, I was doing dumb stuff that didn’t work at all, and now I’ve got some slightly smarter stuff that may work with some more tuning… we’ll see. I’m aiming for greater than 95% accuracy, and right now I’m getting about 50% steps, and 10% false positives, at least on days where I walk a normal ammount for me (about 4 miles). I’m using a moving average over 5 seconds, and counting anything that’s more than a standard deviation from the mean as a step. I’ve set a lower bound on the g forces, as well.

There are a couple things I can do to improve on this; I’ll put out the library (probably a couple statistics classes and a step-specific logic class) once it’s in a better form. Right now, it’s jsut One Big Method, which I know is dumb. Things to tune: how much history we have, and how we compare it to past things we thought might be steps. I have ideas, but I am sleepy so they may all be dumb. We’ll see in the morning.

Accelerometers and processors

2014-11-03T06:43:51+00:00

First, some good news: the mark 3/4 (I’ve lost track a bit) is done, and looks fairly identical to the mark 2. It has some nice internal differences, though. To start, it has a working accelerometer. This means that I can, in theory, implement a simple pedometer and sleep monitor. Unfortunately, all the howtos for that are not on the public internet, at least not that I’ve found yet.

I can think of a couple of ways to do it. The first approach I tried was to just count up a step when the g forces go over a certain threshold. To save you time: That doesn’t work.

The next thing I though of was doing bayesian analysis, saving the last few seconds of movement, and deciding with some logic if the numbers look like a step. This isn’t impossible, but I’m afraid it’d eat processor cycles and memory. If I ever get the phone app running, I can dump the data to a CSV and do visualization and patern mapping in ruby, which has nicer libraries for that sort of thing. Deriving them from first principal souds like a pain in the ass.

The other, simpler method, is to extend the first non-working method a bit: I also have a gyroscope, so I always know where down is; I could subtract the 1g of force that gives me, and then the spikes up and down should be really obvious. Also, it’s cheaper in the processing department. I’ll probably try that next.

Speaking of processing… I’ve just about outgrown the RFduino. I was going to use a shift register to make up for the lack of I/O, but there are a number of other problems with it:

It’s close source. This isn’t a technical problem, but I don’t like it.
Lack of compatibility; every library I use has to be modified, sometimes drastically.
Size: it takes up a lot of board real estate, which means I can’t arrange things as I see fit.

There are two contenders to replace it: either an AVR like the ATMEGA1281, or a STM32F405RG underclocked and running micropython . It would be insanely cool to be running python. It’s enough of a hook that writing all the libraries over from scratch doesn’t seem so bad. But “Arduino compatible watch” also has a nice ring to it. There’s plenty of info to make designing either into the watch not bad, and I could then use an nRF8001 for the bluetooth. The chip cout stays roughly the same, but with a ton more flexibility.

another status update

2014-10-08T01:17:44+00:00

So, we’re on par for a status update a month. I’m OK with that. Version version 2.2 (major.board) is my daily watch now. It’s in pretty good shape, for a DIY watch. It’s not smart, not really, and that’s where I’ve got a ton of programming to do, still.

I’ve updated the ‘github’:http://github.com/mattmills/oswatch with a bunch of changes. First, the latest gerbers are there; the board is now very different. The new accelerometer is a LSM9DS0 , in a weird little package that turns out to be footprint compatible with QFN-24, the same as my shift register. The shift register has an interrupt pin that can send an intterrupt from any of the other pins when they change, so I’ve hooked up that, as well. Interrupts for everyone! The updated software also has some minor updates to the watchface, which now shows the day and date, and the markers no longer overlap the hands. I have a really convoluted ruby script for generating all the data to draw those rectangles; I didn’t want to think about doing floating point math in the machine.

I’m thinking for the next version, I’m also going to reduce the battery size again. 500mah is nice, but thinner is also nice, and charging isn’t really a hardship. Also, right now, it lasts more than 6 days; more than two days is fine. I might need a 3d-printer, to make a waterproof case. Making millimeter-accurate bends in sheetmetal isn’t easy, but a 3d-printed case would be able to do that, and have grooves for o-ring seals.

finally a working power supply

2014-09-16T05:00:59+00:00

so, since I last updated here on the blog, a lot has been going on. I got the 2.1 revision of the board, single sided, and it had another couple errors in the power supply, and I discovered while hacking that I’d also ordered the wrong power regulators, 3v instead of 5v. So, I ordered another round of boards, this time re-reading all the datasheets and example circuts twice. I got it right.

The circut board with hand-applied solder paste. Had to do a bit of cleanup on this one.

That said, the board still has some errata. The shift register isn’t properly configured, and so it eats power, and the accelerometer is also wrong in a couple ways. Also, the screen connector is too close to the edge of the board. I’m working on these defects and some improvements; LED lights for the screen side of the board, to serve as backlights, a different accelerometer altogether, and maybe a vibration motor, for notfications.

Exploded v2.2, before I’d build the first enclosure. The ribbon cable on the display is super delicate; I’ve reinforced mine with tape.

I have managed to make a much smaller, fuller featured version than the old one. The current version uses the real time clock, has a 3x larger battery, and is 5mm thinner. I’ve removed the shift register, and the whole thing is on track to run through wednesday evening, having been last fully charged on saturday at 6pm. If I’m a little lucky, it’ll run through thursday morning.

Case #4, with rubber sides. I wasn’t a huge fan of the rubber, so…

On the software front, I’ve written a new analog watchface, with rectangular hands instead of lines, and nicer hour markers. As I mentioned above, I got the RTC working with this board release, so now I shouldn’t have to reset it every morning, assuming I don’t let the battery die all the way. I’m to the point where I need to take an inventory of the parts on hand; I have a probably 2/3rds of the next watch here already, just a few leftovers to pick up (a couple more sharp LCDs, maybe another extra rfduino).

Case #5, with plexiglass on 5 sides. It’s a little chunkier, but not bad. Stainless steel back, and corners for strength.

I think that’s all for now. Keep an eye on the twitter for more frequent updates.

project status

2014-08-11T06:42:21+00:00

So, currently, the project is a bit all over the place, with a lot of things happening all at once. I’m hopeful that by writing them all down, I can get some sleep. edit: totally worked!

First things first: the board design I was so happy about turned out to be unworkable, mostly because the battery was backwards on the schematic, so I connected a bunch of stuff to ground that shouldn’t have been. I reworked it, but I’m holding off on publishing a revision until I know it works this time. The new version is larger, taking up the full area of the screen, roughly. It’s also one-sided; the bottom of the board only has some traces. This will make it thinner overall, so that’s a bonus.

While I’m waiting for that to come in, I’ve been thinking about what constitutes ‘done’ for this watch. I’d like to do one more prototype, at least, with a backlight and a more sophisiticated accelerometer. I’m hopeful that the real time clock will let me actually put the watch in low power mode between updates, and save battery. So ‘done’ for me is dark readable, waterproof, no dissassembly to upload new firmware. Battery life somewhere in the range of 5-7 days, which I may have to acheive with a larger battery.

Case design is another area that needs some work. I’m thinking in a lot of directions here, and there are some interesting engineering limitations. RF and metal cases don’t go well together, but I may test using metal anyway, to see what kind of attenuation I get. The face will be open and nonconductive, at least. I’d also like to do a women’s version, but it’ll have to be a two-sided, four-layer board. I have no idea what I’d use for a display; I’d want something roughly 1/3rd the size of what I’m doing now. It’s different enough that it should probably be shelved in favor of getting something done. Maybe size isn’t even an issue, and it’s just style.

A word about solder paste and tiny packages with pins hidden under the chip: use less. That said, you can hand solder 0.5mm traces, using the methods in this video. My first pass with the reflow oven, I had a ton of solder bridges; I used too much solder, and I was a little sloppy putting it on. So, don’t do that. Syringes seem like a good idea, but really, the toothpick method works really well; I used a needle, and it gives pretty good control of where paste goes and how much you apply.

The other thing I’ve learned is about supplies: the adage “If you need one, order 10” is completely true for small components. I’ve been wrong about a lot of things, including the number of resistors and capacitors I needed. 0401 parts are tiny, and I’ve also lost at least one of them. I damaged one ZIF connector as well. So: always order extra. I’d say order ten of anything that costs less than a dollar, or is smaller than 2mm^2.

That’s all for now. The new boards arrive tomorrow, so look for a post on tuesday with photos and hopefully a new, working prototype.

minimum viable reflow oven

2014-08-11T02:43:08+00:00

So: I totally stole the idea for this thing from all over the place. There are dozens of tutorials about how to build a reflow oven with a toaster oven. By far the coolest is the Halogen Lamp reflow with low-temp solder paste, but assuming you only have regular paste, what I’ve done will also work. Note: I’m moving to the low temp stuff for future builds because it’s faster and easier to work with.

The breadboard all wired up. The big green phone wire is running to the power relay.

First, supplies: You’ll need a toaster oven. I ordered one from the big river , but anything that’s functioning and has both top and bottom elements should work just fine. Don’t use it for food afterwards; not only is the metal in solder toxic, but the fumes from the flux are also not great. There’s probably an MSDS around somewhere, possibly from wherever you can buy solder paste, that describes the precautions you should take.

Second, you’ll need some way of measuring the temperature inside the oven accurately. I got a thermocouple and an amp from adafruit, but you could also hack a kitchen thermometer. They’re less accurate, but cheaper. I went for accuracy here.

Oven in use.

Third, you’ll need some way of turning the power off and on. Some people have observed that toaster ovens have perfectly good knobs on the front, and you can get away with just turning it off and on that way. I’m lazy, and I have a short attention span, so I got a powerswitch tail. It’s a pretty nifty isolated relay; it connects to a digital pin, and when you bring it high, it turns on the power.

Lastly, you’ll need a microcontroller of some sort. I used a Spark core, because it was on hand and easy to program. I didn’t even change the firmware. I used the tinker firmware and some ruby code to talk to the spark API. I could have used a raspberry pi, an arduino, whatever; the requirements for this project are super minimal. Really, you need about one-second resolution on the thermocouple, and the same on the power. My code is here: https://gist.github.com/mattmills/746bc1e8fed75ea413ae (note that I’ve taken out my access tokens). Note that the values for temperature are probably unique to my oven and room temperature; if you make one of these, definitely do a test run.

A finished board. There were a few bridges, but this was the first effort.

Assembly: I didn’t even bother with a permanent board. The Spark core is dead useful, and I don’t want it tied up in one device. I stuck it in a breadboard, wired up the amp to power and an analog pin. Wired the powertail’s control lines to a digital pin and ground, and plugged everything in. I ran the code once, tuned when to stop heating for both stages, and then ran it again. The curve was in the bounds of workable, so I put in a test board, and it worked :)

a tour of version 2.0

2014-07-10T15:58:50+00:00

So, after many weeks slaving at the computer every night, I’ve managed to produce a circut board design for v2 of the watch. The design is a little rough around the edges, but I think it’s worth walking through things at this point. First, some general considerations: I decided not to give a shit about cost per component in this design. I’m working with a lot of other constraints, mainly board speace, my time, and my ignorance. So almost all of these components are things that I’ve seen used in kits, things that are dead simple, and usually the smallest available version. Where possible, I’ll link to resources that have helped me along the way. The software that I ended up using was the one with the easiest learning curve, Fritzing . The biggest drawback is that it can only do 2-layer boards. I could probably make the board 20% smaller with a four layer design, but I’m unwilling to pay for eagle, and KiCAD was impossible to install when I was trying. I did later get a binary version to work, but the drag-and-drop simplicity of Fritzing sold me.

The heart of this board is the RFduino, a mostly Arduino compatible ARM M0 system-on-chip with 7 GPIOs that runs at 3V. It was chosen for it’s size and ease of programming; there are a ton of libs and code that work out of the box for it. Also, it’s very small; smaller than a microduino, and has blutooth built in. It was suggested to me by my friend @mojinations . Originally, I was going to do something very similar to the OSWatch, just build the Amtel and the bluetooth into the same board. When I found the RFduino, I knew it was the right part, just based on size alone. The drawback being that it’s SMT only, which has made prototyping interesting, to say the least. Also, it only exposes 7 of the processor’s available 30-some GPIOs. I understand there’s a space constraint, but it would still be nice to have a few more (not to mention reducing my part count and complexity even further).

Moving on to power, I’m using a lipo battery like this one from Adafruit. This feeds a Maxim MAX1724EZK30 regulator, which was chosen for its very low quiescent current, although it was a bit more costly than other switching regulators.The board also will charge the battery over USB. It uses a MCP73831 charging IC and a power sharing circut described here ; basically it uses a MOSFET transistor to switch to the USB power when it’s connected. As an aside, I found that page looking at photos of other people’s DIY watches. His is pretty rad.

Next is the screen. Sharp makes a family of low-power memory displays, which are like e-paper, but with fast refresh rates. I decided to build around one of these instead of a more typical OLED because I always want the display to be on, telling the time. If a watch is about displaying essential information, it shouldn’t need a button press to see it. I got the idea from the Adafruit breakout board, which isessentially a level shifter and a voltage regulator hooked directly to the screen. There are actually two displays that are interchangeable here; one 96×96 and one 128×128. They’re physically about 1mm different, and the connector is the same. Unfortunately, they’re also backordered everywhere; I’ve been forced to buy breakout boards to get the part.

On the I2C bus, we have three chips. First there’s an accelerometer, which I have no idea if it’s the right one, but it’s at least widely supported. This will allow the watch to do activity tracking and shake gestures. Second is the real time clock. I went with the Maxim DS3231MZ+, which has an internal oscillator, so reduces the BOM by 1 part. I could probably get away without a RTC, I mean, my current version doesn’t have one. That said, it’s pretty essential that the watch keep time. Last on the I2C bus is a I/O expander, which has 4 pads exposed for buttons, and another two for shits and giggles. I should probably make the extra two pads the I2C bus.

The full BOM is in this google doc . There are some various capacitors, resistors, and such that do things like power conditioning, pullups, or config. Nothing super crazy. The full set of gerbers is in the github repo, along with the code I’m currently using. Astute readers will note that none of the new hardware is implemented at all yet. It’s on my todo list, as soon as I build it.

some words about a case

2014-07-03T05:41:19+00:00

So, I’ve made like three cases so far, “case” being the lingo for the container a watch goes in. I don’t have a 3D printer or a machine shop, so I’m limited to what I can hand fabricate. That said, I have a long history making things with my hands, and I’ve been able to make a couple different things, the last of which is actually not that bad.

The first one was metal, which was ok, except I was holding the circut boards in with tape, and metal blocks radio signals. Not ideal, but for the time that I was just wearing it as a timepiece, it was ok. The band was attached with wires looped through holes; imagine a staple, wrapping around the band and through the metal.

The next case was all acrylic; I had the idea to make a laminate case by cutting the inside holes with a dremel; this turned out to be way too much work. Acrylic kind of sucks as a material for fine work. You can cut arbitrary streight lines pretty easily, so I made a bunch of rectangles, and made that into a box with some superglue. One side I left open, with a bit of the two sides sticking out, and cut grooves so I could make a slide-in cover out of aluminum. I noticed after wearing it for a bit that it had super sharp corners, so I sanded all the edges so they don’t gouge random people on the bart (or my wife).

Then, of course, I broke that. I was trying to drill holes for buttons, and the top came off. So, instead of trying to fix it, I went back to the drawing board, and thought for a little while, and came up with my favorite so far. A laminate design like the second case, but instead of using acrylic for the middle sections, I used gasket material, which is cuttable with an X-acto knife. The top and bottom are acrylic, and it’s held together by the four bolts you see in the picture.

I could continue to work on little stuff like this indefinitely, but to make new features, I need to add to the circuts, which has become inpossible on the perf board. It’s overworked and out of room. I’m calling a halt to development on this iteration, and focusing on the schematic and board for the next major version.

buttons buttons buttons

2014-06-30T01:05:49+00:00

So, with the watch assembled and largely working, work on it slowed a bit. I didn’t want to break it. I added some buttons, that didn’t do much, and left it, stable, for a week or so. I worked on the schematic for version 2.0, a.k.a. the DVT. I routed the copper for most of it, too; I have some things left to add. Using I2C for a lot of things, since there are only 7 I/O pins on the RFduino, and I’m still one pin short. There are tools for that, at least.

Speaking of I/O, buttons! In order to get things working, I couldn’t just hook up one side of the switch to 3v and the other to the digital pin. That would be too easy. There are a lot of factors in play here. This is worth a little diversion. I come from software, where by comparison we live in a world of platonic ideals, where 1 always equals 1. Hardware is harder. For starters, the digital pins don’t read 0v when in their natural state. You have to use either a pullup or a pulldown resistor to get a 1 or a 0.

Then, interrupts, oy! Somewhere in the libraries I’m using, there’s some interrupt driven thing that was causing the watch to freeze randomly after pressing the button. Not all the time, but probably 1 time in 10. I wrapped my whole loop function in noInterrupt() to fix it. The code is on github here: https://github.com/mattmills/oswatch . It will probably change a lot while I’m adding features and improvements.

Next up, hopefully in the next couple weeks, I’ll have the DVT schematic and gerbers. There’s not a ton left to do, basically wiring in the screen and accelerometer, and maybe a RTC if there’s room. 8 mil traces are tiny, but I’m leaving basically half the case for battery. The original plan was for a 35×35mm final board, and I’ve got that down to 35×18mm, which will make the whole watch thinner and more wearable. I’ll also post the Fritzing files, which may be of use if anybody wants to roll their own hardware. It’s limited to a 2 layer board, which kinda sucks, but it’s doable.

That’s all for now. More news when there’s more to report.

Desoldering braid is magic (or, Building prototypes is hard)

2014-06-17T12:52:43+00:00

So, to kill any suspense that may have been building over the last couple weeks, I’ve managed to complete a first prototype of my open watch. As it turns out, a lot of people have built these over the last couple years, as hobby parts get more sophisticated and smaller. It’s now possible to take a bunch of off the shelf stuff and build a smart watch in any number of configurations. It’s not long before you can build a phone, similarly.

I hesitate to go into too much detail. There’s a lot of this that’s arbitrary, or an accident of me painting myself into some corner through mistakes early on, or simply unexamined. I’m sure there are several lucky breaks I don’t know about, in addition things like the fact that the display breakout I’m using has a voltage regulator. You can see from the photos that it took a lot of working and re-working. What I’d like to do is to teach the knack that helped me know where to look for problems when they came up. How to work through a decision tree of what parts to use, where, and when, what connections to make,

As hinted in an earlier post, the heart of the beast is an RFduino, an Arduino compatible ARM and Bluetooth LE system on chip (SoC). The prototype is built on an an Adafruit perma-proto, but you could proably use any standard perf board. The display is this one, which I’m also using for it’s voltage regulator. VIN goes to the display, and the rfduino is powered from the 3v pin. I’m using one of their tiny LiPo batteries, the 150mAh, but I think power consumption may be an issue when I get to the radio-using phase, so I also have a 500mAh ready to swap in.

The first draft of thie prototype was… messy. I sat and thought about every connection, then soldered, then sat and thought some more. This is not a fast way to build a watch. This version of the setup worked, for a loose definition of ‘work’. I used really long jumper wires, and tried to pack them all together, so, of course, there were shorts. It also made the whole package considerably bigger than I thought it would be. So, kind of a dud.

The second version was a little better; I shortened a bunch of wires, but the RFduino had a pad separation on the reset pin, which meant that it was kaput. I had bought 2 of them, luckily, so I wasn’t dead in the water. Not that the pad separation was my fault; these are SMT complonents, meant to be reflowed (soldered) once only. I knew I was pushing my luck, and it didn’t work out.

Version three I sort of took the experiences of the first two and combined them. I made the proto board a little longer, and soldered little legs to the rfduino, which I made out of wire wrap wire. They’re tiny, and a little flimsy, but in aggregate, give enough tension to hold the chip securely. I wired the power/programmer side so that I could plug it in directly and power everything off of it, for debugging purposes. You may notice, if you look closely, that Rx and Tx are switched from the circut diagram I posted in my last post; that’s because I screwed up drawing it.

So, what have I learned so far? There is a metric ton of information on how to do all of this stuff out there on the internet. If you have a question, someone else already has, and has posted on a forum about it, and been derided for being a noob. Then, someone knowledgeable will come along and actually answer the question, sometimes clearly, and sometimes in an offhand way that has you googleing again. Skim the trolling, look for answers. Then, there are the manufacturers’ data sheets, which are supposed to tell you everything you need to know to use their product. They give away perfectly good designs, so you get to benefit.

But seriously, solder braid really is magic. There’s more to say, and a ton more to do, but that’s enough for now.

Programming an Rfduino with an FTDI friend

2014-06-04T15:58:19+00:00

There comes a time in every man’s life when he buys a thing, thinking he won’t need accessories, only to find out later that he does, in fact, need them. This was one of those times.

I’d tweeted about building a bluetooth-enabled watch,and a friend linked me to the RFduino, a device that seemed to fit all my requirements. It’s small, low power, has enough GPIOs, and was supposedly open source. I’m not entrely sure that’s true, as I know that you need a proprietary toolchain to build the bootloader currently, but the bootloader itself is at least open. So, I decided to forge ahead with experiments anyway. I ordered two of the SMT versions.

When they arrived, I was stoked. They’re freaking tiny . My level of stoke only lasted until I started trying to find out how to program it; there wasn’t much information at first, other than to use their programmer. A look at the data sheet told me that it was just a USB → serial interface, and I had one of those, Adafruit’s FTDI Friend.

To get it working, there are some steps. The Friend is already configured for 3v logic, but you have to solder some jumpers on the back to expose the right signal lines, and make Vcc 3v as well. In the picture, you can see I’ve bridged the DTR jumper pads with a surface mount part; that’s a small value capacitor I had laying around. You don’t have to do it that way, it just needs to be in series with the DTR line.

I derived most of the schematic from the datasheets for the parts involved, and then from some forum postings figured out the capacitor. It’s pretty simple once you get to the end point, but took me a while to get here. Recommended but not required is a filter capacitor wired in parrallel between VCC and Ground. On my breadboard currently, there’s also a pullup resistor from reset to Vcc, but that’s not required. I was trying to troubleshoot… anyway. Protip: Command-u is not the same as Command-shift-u.

You could replicate the above with any of the FTDI programmers out there; sparkfun sells one, and there are clones all over. Just make sure it exposes the DTR line, and you’re set. One last photo: this is the current setup, with filter caps and a sneak peek at the display of the watch I’m working towards. You can see what loook like three hands; the one pointing to 12 is actually a bug in the redraw code. We’ll pretend it’s a second hand.