The Desk Clock Lives Again… sort of…

Well, all the parts arrived — well, those I ordered, at least — and sat around for a week or two until I had the opportunity to assemble it.  So it's together … ish … and hanging on my wall.  The "ish" part…  This is what happens when you indecisively and experimentally add and remove parts over a year and a half or so, without really expecting it to become a reality any time soon, and then suddenly decide, "you know, I'm going to make this a thing."

Being a low-priority "I'd like to get around to doing this some time" project, I wasn't necessarily paying the closest attention to details, and a lot of things were left in the "to check later" basket, which was more of a mental note thing, than a proper tracked project thing — and it's not hard to figure out how that will end.  Sooo…  here's the round-up (and I'm making a proper check-list now):

• The cutout I added for the EtherTen's Ethernet port, was about 1mm too low, requiring me to take a file to the PCB.  I've now raised the top edge of the cut out, and lowered the bottom edge slightly just for a touch extra clearance, and I'm mighty glad I'd moved the track that was originally wrapped fairly snugly around the cut-out.  Still…  All things considered, not too bad for a tape measure measurement.
• The RGB LED component I used, was a standard library footprint.  I remember thinking, "you know, common ground on pin 1 doesn't quite seem right... I'll have to check that later."  But I'd only put the component on the schematic to test out an idea — mainly to check whether I have enough ųC pins for it — and I hadn't actually decided to actually include it yet, the one on the original breadboard version was a little over-poweringly bright at times, so making sure it was the right part to what I might be using some time down the track, wasn't real high on the priorities.  Unfortunately, of course, I didn't check the footprint.  So my RGB LED, is presently a GB LED — turning the red segment off provides a false ground (back through the ųC) for the other two segments, at twice the resistance (which actually looks quite okay, and is plenty bright enough as is).  Needs some further experimentation.
• The Clock display also seems to have developed a fault in the past week or four — which I don't think is actually my fault, for a change; I thought it was just a couple wires had come loose on the breadboard again, that was making a few digits fail, but, it was something more.  One of the LEDs is leaking when reverse biased, and the driver chip is failing.  I'm not sure which failed first, but there's definitely faults in both; when I transplanted the Clock display onto a breadboard and tested it manually, all the segments worked properly, but I noticed connecting power across the commons for digit 3, and one of the others, would cause that other digits D segment to light dimly, which leads me to think digit 3's D segment is permitting reverse current flow.  I surmise from that, that it's doing nasty things to the driver chip, causing it to progressively fail, leading to the gradually increasing dead segments over the past couple weeks.  I have one more driver, but only the one display, and not sure which of the two caused the initial problem, but knowing the display certainly has a problem, I'm loathe to plug in my other driver to test the theory — and so since I'm going to need to rev the board anyhow, I'd rather hunt down a replacement display, and keep the second chip for the new board.

Conclusion at it's present state: I need callipers, and definitely need to keep a proper TODO list.  Really, most of the problems stemmed from those two.  I've been poking at this project in very brief stints, over several years, and it was only a fairly whimsical project to begin with, that has suffered scope and feature creep almost every time I've touched it — typically, playing with some random thought or idea was the reason for touching it again to begin with.  The bigger problems, footprints I had to design, the schematic layout itself, were all fine, and the general concept seems to work as intended.  So on the whole, the board layout was a significant success, and a rev 2 was pretty much expected, as this entire thing is mostly experimental.



On the software side, it's sending room temperature, light level data, and button presses, over MQTT.  The RGB LED glows blue during "daylight" hours, and turns off at night, which is something of an inbuilt test of the light sensor.  I did have the green segment blinking once per second, based off the clock chip's 1Hz output (which drives the internal time keeping), but that got annoying — which is a thing, I'm really not sure I want the LED there at all — though I might keep it purely as a network addressable indicator, even if I don't give it a purpose within the clock itself.  I've removed the clock display driving code, because there's presently no display attached, though I'll have to re-activate that just so it takes up it's slab of space…  And I need to fit the external temperature sensor — going to need an extension cord for that, too.  And of course the entire menu system is going to have to wait until there's a display for it to use, and even then I'm very dubious it's going to fit on the device at all, so that may well end up being offloaded to the server in any case — sounds like fun either way.



The current TODO list basically goes:

• Fit the external temperature sensor (with extension), and get it sending data.
• Decide whether I really want that RGB LED there or not…
• Experiment some more with the light sensor to improve it's sensitivity range.
• Get the proper push buttons for it… the current ones are under-sized.
• Order new displays — the one I'm using is remarkably difficult to find in a colour I like.
• Re-activate the display driving code…
• Finish the coding — need to see if everything will even fit!

In the meantime, my present automation infrastructure, is lacking in actual infrastructure, so I'm in the process of fixing that.  Once I have that updated and better integrated, I'll put that light sensor data to use turning off my lamp when it's not needed, and actually storing the temperature and light data so I can draw pretty graphs and what-not — although I'm fairly certain Hass.io and the likes have components for doing just that, but still, you learn more if you do it yourself first, and that's what this entire project is about, after all — migrating to Hass.io or it's ilk, will be an adventure in it's own right, and there's a plenty long enough TODO list already.

A final note…  I also need a cleaner project management system.  With a single project potentially spanning KiCad board designs, Arduino firmware, R.Pi based scripting, and potentially online components hosted on my GAE project, along with general notes and reference materials… having the separate bits living within their own little environments is, troublesome.

A little automation…

Okay, so a bit of time has passed, and my room has just a little bit of automation going on…  Nothing particularly impressive, and still so much to do, but piece by piece…

Firstly, there's a Sonoff Wifi switch on the bed-side lamp.  It's hooked up to a rather crappy Python automation script, but it is none the less "automated", somewhat.  However, as I wasn't able to find an API for the Sonoff, and I haven't yet been brave enough to try re-flashing it with something like Tasmota, the only way I could find to control it was to use IFTTT as an intermediary — so a quick bash script lets me turn it on or off, issuing web requests to IFTTT, which in turn communicates with the device's server, and then back down to the device — that's probably quite literally doing a lap around the globe, just to send a simple on/off signal about 1.5m.  It's on the list of things to fix.

Also, several months back I pulled out a 1m strip of RGB LED's — 60 5V APA102C's — which I've had for about a year, but hadn't taken out of their sealed package.  Hooked those up to an EtherTen (Arduino Uno, with built in Ethernet from Freetronics), and laid the strip along underneath my monitors.  Right now as I type this sentence, it's displaying a fairly standard sweeping dot sequence.  These are nice LED's, because they're 4-wire SPI-style, but… they don't do dim.  At all.  You try to dim them past about medium, and they just get annoyingly flickery, and any colour other than pure red, green, or blue, breaks down — as it is in the sweep pattern, when it's showing a non-pure colour, you get pixels in the tail that are showing just one of the component colours, making it stand out occasionally, albeit briefly with the relatively fast fade.

Initially, it was a regular Arduino Uno, running a simple demo program that cycled through a set of demo patterns.  But I decided I wanted control over it, so it was fairly quickly swapped for the EtherTen with a very crude web server.  This allowed me to manually change the pattern, brightness, and I'd added the ability to turn it on and off (fading in and out).  That was then followed quickly by a Raspberry Pi, and the introduction of MQTT, with a cron script bumping the pattern every 10 minutes.  The MQTT server offers a very basic web server, which allowed the creation of a basic web interface — you can find plenty of examples of doing so online, which was an excellent way to get started.  Up to this point, it's mostly just running example and tutorial code off the web.

But then, as always, I decided to make it my own — it's undergone major reworking since, as I struggled against the tight confines of the Uno core (32KB Program, 2KB RAM), while also adding extra features like being able to reserve LED's from either end and set them independent of the running pattern, as a means to show indicators.  There's also a pixel clock overlaid on top of the pattern — red dot for hours, green dot for minutes, and blue dot for seconds.  So the basic set of patterns (there's a couple extras of my own), are still mostly the code you see all over the place, but I've tweaked some of them a little, plus I had to re-work them all a little to support the indicator feature (the pattern down-sizes to fit the unreserved space).  The rest of the code, however, has been ripped out and replaced utterly.  There's more I want to do yet, starting with replacing the current hue shifting, with colour palettes — the stock ones, a couple extras of my own, and support for a custom — and expanding the indicator support to add fading (ran out of space to implement that).  Though that's on the back-burner at the moment, it works, and there's other things that need doing.

Speaking of which, as I said, it's being driven by a script on a Raspberry Pi running the MQTT server, and I presently control it though script commands over SSH terminal — it's very much still a work in progress.  There's also a script that turns off the light if I leave the house, and turns it back on when I come back, though it needs light level awareness, which is planned to be sourced from my desk clock.  I'm also planning to transition to something like Hass.io on the second R.Pi, and depreciate my rather gruesome and not particularly well meshed Python and bash scripts.

Also coming, I plan to replace having to control it by SSH (or even web, once I decide to sort out Hass.io), with a satellite Arduino Uno (I'll have one spare when I swap the one from my desk clock, with the spare EtherTen), with power and RS-485 data, and maybe an LCD — I haven't used an LCD for anything yet.  There's also the bedroom window — that winder most definitely needs to be automated.  Cue the hunt for an electronic window winder…  To the TODO list…!

A clock, for my desk, revisited…

So, back when I was a wee kid, I wanted to make the obligatory LED clock — back then, it wasn't ųC's, it was decade counters and 7400 series logic gates.  Never did actually make it, though…  So when I got my first Arduino, the desk clock (with a few extras) was the first thing I made after the obligatory learn-to-Arduino style Blinky.  But as I mentioned in an earlier post, it died a sad, sad, death.

I've done my non-Arduino Blinky, too, nice little (7)555 on a board, got me a taste of KiCad and SMT.  Now it's time to resurrect my DeskClock project; this time, I'm planning to make it an Arduino shield, much the same as before, but with an actual real time clock module thrown in for bonus points.  (Next version, I think, will be an all-in-one, maybe I'll add a buzzer there for an alarm option, maybe the external temperature sensor I was considering adding also, so many things…)

Now, onto the project.  So I've got me that nice blue 4-digit 7-segment clock display, and a simple MAX7219 display driver.  The driver's not really what I want, I want (at least) per-digit brightness, the 7219 only does global brightness, but it's what I've got, so I'm going to see if I can make it do what I want, see if I can flip the digits on and off quick enough to pretend.  Though from an initial poke, I gotta say I'm a little dubious…  Still, current step is to get the display running, then try it and see.  But there appears to be a small problem, it seems my common-cathode display, mayhaps isn't.  Started with a simple library and demo program on the Arduino, with just the MAX7219 and the display wired up, and nada.  Well, not exactly nada, all the digits were on, all the time.  Seems kind of obvious now, but after poking at it for a bit, and verifying that the program is spitting out the data it's supposed to be, I think my common-cathode display might actually be a common-anode one, or if I'm lucky, perhaps the documentation I found just has the anodes and cathodes backwards — I would have noticed that when I was building my clock the first time around, but I was just experimenting and playing with it at the time, and wasn't particularly keeping notes.  (This is why project diaries are good — they save you from wasting time later on.)

(… later …)

Well, it turns out the display is indeed common-anode.  Still, that wasn't going to stop me.  A little confusing wiring, and some tricky coding to transpose the bits, and it's displaying digits just fine — little annoying I can't use the display trim to render just the four digits, but it works just fine.  Added an RTC module (so it doesn't slip a minute a day like it used to), and stepped it up to two buttons this time, and it's been running quite happily on my shelf for the past couple months.

(… much later …)

Its RTC module is still holding time just fine, though it's hard to read the digits through the tangle of breadboard wires, so it's been sitting there running, but mostly neglected — the interface connected to those buttons is still mostly undone.  Well, I've finally decided to push it along again.  I've got a spare EtherTen board, and that clock has a temperature sensor stranded on the device and not available to my growing room automation system … I'm sure you know where that's leading.

However, that does change the plan a bit.  I'm not quite to the point of designing PCB's with Ethernet just yet, so I've designed a PCB version of the circuit as an Arduino shield, parts and board (finally) ordered, just waiting for it all to arrive.  It also raises a fresh problem; my prior little project, very quickly exhausted the ATmega328P's (the chip at the heard of the Arduino Uno) rather meagre code and data resources — so I'm not at all confident that after dropping in the Ethernet library, there'll be enough room left for everything else, and I'm certain it won't fit an NTP client on top.  I'm fully expecting it'll fit the basic clock and temperature functions, but I may need to off-load the menu's with their settings — on the upside, since I never designed a buzzer into the PCB, I'll just have to implement the alarm by having a Raspberry Pi play an audio clip.

(… to be continued …)

Bootstrapping another sojourn in web-design land…

It happens that the government of Australia decided to enforce plain packaging on smoking products, and even more frustratingly, to in some cases, also hide the prices of said products from the consumer (or maybe that's just the individual shop)…  And while I'm not a smoker, I rather frequently found myself purchasing smoking products, and keeping track of the current cheapest pack was a constant nightmare, especially with it often being cheaper to buy two half-sized packs, and such.

So what did I do?  I built myself a web application in Google App Engine to make the job easier.  It lets me track the prices of various sized packets in my favourite store, prompting me to enquire about the current price of packets I haven't checked in a while, and offering the ability to quickly discern how best to obtain either the most smokes for a given sum of money, or spend the least money for a given number of smokes.  And it worked very well indeed…

… but it was so hideous!!!  It was built around a fairly basic HTML and CSS template I'd put together myself for an earlier project, and my CSS skills, well, they're not the best.  And viewing it on a phone — as I typically was while at the shop counter where I needed it — was, interesting; zooming out to see the page, then zooming in to select a field or press a button, back and forth a couple times.  It was still fantastically useful; though you still needed to ask at the counter, just to make sure there wasn't a new option you didn't yet know about, particularly when faced with someone who wasn't familiar with the various smoking products on offer (which was rather often in my favourite supermarket), it would often beat their suggestion.

In any case, that was what spurred me into investigating responsive web design.  At first, I wanted to learn to do it myself — of course — but, well, it's nasty.  (Even nastier than my still-in-the-1990's web page designs.)  So I started looking at toolkits instead, and ran across Bootstrap — I'd heard of it before, and it was coming up in my searches as seemingly fairly popular (they certainly think so, too…!), so I decided to take a look.  Unfortunately for the smoking app that started this, I was no longer needing to purchase smokes by this point, so though I'll probably have to dig into it again when I start Bootstrap-ifying the template it's built from — it's going to need some fairly radical changes to it's UI, and I can't see that happening — so I'll probably just be giving it a flattened copy of its present template and leave it on ice, while everything else on that branch of the site moves on into the 2010's, finally.

So, I wanted to learn Bootstrap, but the smoking app wasn't the place — in fact, it's not even a particularly pleasant memory, those damn cancer sticks are getting horribly expensive, and at an increasingly alarming rate — so what to do…  Ah huh!  Light bulb moment!  Time to breath some new life into my old 1990's style homepage…!  (It's also on a branch of the GAE site which holds a couple "learn to GAE" tutorial examples, and doesn't have any existing templates.)  And so it was reborn (and probably isn't yet finished being reborn), with a fancy new Bootstrap interface — presently in the guise of something kind of sort of resembling part of a resume … with a link to this blog … do I really want this blog on my resume … ?  (On the other hand, if you've been following the various links in this post, you may have noticed my "homepage" has some minor variations, depending on exactly what name you reach it by…)

Now at the end of all this, what do I think…?  Bootstrap is rather nice.  It's not too invasive, and the great majority of it works just fine without any scripting at all — though I did finally give in and add the JavaScript components, so I could add a couple little tooltips in one section, and if it ever gets long enough to need a navigation bar, I'll be employing the "you're here" marker script too (which I did briefly test out, of course).  I haven't gone down the path of compiling my own style sheet yet (though it is referencing a mildly themed version rather than the default), but that's mostly only because my site presently doesn't have any build mechanics — it just gets deployed as written.  (And something I plan on fixing, when time and sanity permit.)  But I have to say I rather like Bootstrap, and it wasn't at all difficult to use.

On GUI's in Python and D…

I recently wrote a forum post regarding my experience with finding a suitable GUI in which to build a small toolkit.  My primary need, was for something I could hit the ground running on (because I already had a partially built application, but was wasting too much time fighting the toolkit), and which I could dump on a friend to just click and run.  Not the best of selection criteria, nor did I do a particularly exhaustive search for options (some very good ones of which were pointed out by other posters on that forum), but these things happen out there in the real world — sometimes your selection is legacy, and/or even just plain comes down to "the devil you know", though I don't think that was the majority case in this instance.  Anyhow, I'm going to re-post that post here, more or less…

Anyhow, here goes:

I've just recently gotten back into building applications with GUI's myself, after a 20 year lull.  Back then, it was Linux with GTK2; GTK3 and Glade were pretty new and a little too flaky to be worth the effort.  Now, just a couple weeks ago, I found myself wanting to throw together a small Modding GUI toolkit for a friend who's, well, not the most technically minded.

So I started with what they already have installed, Python and its Tkinter…  Well, that was a horrendous experience.  The Python→TCL→TK hop-skip-and-jump routine is, frustrating, and at the end of it, TK's not exactly the most capable of GUI's.  Don't get me wrong, I love TCL, it's a fantastic language, which I was very deeply into back in Uni, getting right into the guts of the language.  But TK…  While it kind of works in TCL, it's frustrating as heck in Python.  Take for example, checking to see if a tree item is hidden, and it returns a '0'.  Not a boolean, or even a number, it returns it as a string.  If you forget to explicitly cast it to an int, you get True (in TCL, it's a number with an optional string representation, and it'll do an implicit cast if necessary in any numeric context, but when translating it to Python, you just get the string rep, which is True if not empty).  As for the other Python GUI options, both myself and my friend are presently in Windows and, well, getting many of them to actually install cleanly was… problematic.  And if I had trouble getting those toolkits to install…

So I started looking for better options.  And I came across one I think well worth mentioning.  GtkD.  D really is a better C/C++ (I remember being rather disappointed when a YouTube'r I follow dismissed D offhand as merely — not a quote, the real quote would be shorter — "D is just a C++ as C plus 1 makes D, pointless naming rubbish", seemingly without actually looking at the language itself); it's an absolutely beautiful under-rated language, IMHO, which pretty much covers the useful parts of C#, without feeling like the proverbial "everything and the kitchen sink" that's all too common with Microsoft frankencreations (don't get me wrong, I use their OS, and some things they do are absolutely brilliant.  It's just that, some, well, go a little overboard, and/or just plain miss the mark entirely).  And paired with GtkD (which has a few minor gaps still, but nothing serious) bringing with it GTK3/Glade, has been a comparative delight to work in.  I did miss GTK, but I didn't miss C (though it was certainly educational in the ways of OOP back in the day), and this combination is just delightful.

Now, I think I'd rather be using Dgui — I'm pretty sure it would be far more effective — rather than GTK through a layer of D wrappers (where all that CTFE goodness has very little to chew on), though it's also a much younger GUI (which might or might not matter), and when I was poking around for options which just work so I could get on with re-implementing that toolkit, it was throwing page fulls of errors with the basic Hello World example, and very little idea what the problem was.  Plus I don't know if it had a GUI builder, though I think there may have been something to do with Visual Studio — which I'm not using mostly on account of it's rather large install size (gvim is my present IDE at the moment).  But, I needed something I could get up and running with now, and more importantly, that just worked for my friend, too.  I'll have a look at Dgui again later, because I'm sticking with D for my personal projects now, but GtkD was the easiest option to get going in again; partly due to my prior familiarity to GTK, and I just had to give my friend the GTK3 runtime installer, along with my compiled binary (a shared Dropbox folder would work wonders, down the line, until I have either reason or inspiration to sort out something better), and they were good to go.

I Made A Blinky! — Version 2

So, finally pulled together the pocket cash, and sent off my orders for the necessary bits and bobs.
The second revision of the board (which I introduced here) cost about $8.50 (US$6.50 + a crappy AU$ exchange rate), with some minor layout improvements, space for a push button (because taking the battery out all the time was getting to be a pain), I removed the positive copper fill on the battery side because I considered that a bad idea when the negative terminal of the battery is scraping over the solder mask on every insertion and removal, and a little piece of test art (the profile graphic I use here on this blog).

Removing the positive fill on the battery side I think was good, I had considered moving the negative fill to the back instead, since the negative terminal of the battery gets pressed against the board, but during insertion of the battery it's likely the positive terminal that does the scraping (since it wraps over and around the battery), so although it should be clear once inserted, there could potentially be an issue in the meantime.  Just not having a copper fill on that side at all is, I think, the better choice.  One big slip-up however, was my misreading of the shop description on the on/off switch I chose; I thought "on/off switch" meant press to turn on, press to turn off.  No.  It means (it appears) that the internals of the switch have a clicky mechanism that makes a nice solid on state when pressed, and a nice solid off when released, rather than the wishy-washy you get with carbonised rubber on PCB style buttons.  Lesson learnt.  It's also the minimum of what I need for this project, since that "switch" is simply sitting between the battery and the rest of the circuit — press it, the circuit has power, release it, it doesn't — so being a toggle (what I'd wanted), or a momentary action (what I got), at least the on/off part is right, plus the added bonus that the extra buttons will come in handy for other projects anyhow.  Again, if this were a real project where it really mattered, acquiring some samples would have been on the cards, or finding someone who already knew, etc. — but this is pure learning experience ground, it was the first component footprint I've drawn up by hand, and it fit first go, so I still consider it a win.

Components for the board, namely the push buttons and SMT LED's (which I totally forgot to put in the order first time around, so the first board has a big ol' through-hole LED attached sideways), came to about $10 — mostly the push buttons, which were minimum 10 quantity, so I have plenty of spares!

But talking about those LED's, they're the most hideous things to solder!  (Even worse than the capacitor.)  One fell apart on me, the second one just would not sit straight while I soldered it, and then there's the whole issue of installing it in the right direction — just trying to figure out which end was the cathode was a nightmare in itself; a quick search on the web yielded several marking options, with the caveat that some manufacturers do it the other way around, so mostly useless anyhow.  But even then, none of the markings I saw described were on the ones I'd bought, instead they just had a bevelled top edge on one end (and the notch that was suggested as a common marking, well, they had a notch kind of thing at both ends!).  I'd tested the board by tacking down a regular LED again, so I knew the board worked, and figured if I could just hold the SMT LED to the pads, I should be able to determine it's orientation.  But, that didn't work.  Not entirely sure why, whether it just wasn't making contact, or whether my metallic tweezers I have were bridging the terminals, or what, but I couldn't get an indication that way.  In the end, I just took a punt, and soldered it down.  And after fighting to get that thing soldered down reasonably, it didn't work.  Neither, did holding a regular LED over the ends, which seemed rather disturbing (had I accidentally damaged something else on the board?).  So all I could do was take it off, and try again with a new LED, hoping that bevelled edge was, at least, the cathode.  And it was, and it worked!  I now had a working Blinky v2!!!  New and (ever so slightly) improved (assuming you don't mind holding down the button)!

That wasn't the end of my purchases, though.  Along with those $10 parts, was another $60 in extras, most notably a much needed flux pen, and one of those nifty "helping hands" gizmo's with the little gripper claws and an attached magnifying glass.  Awful lot better than taping the board to the tabletop with double-sided tape, as I did the first time around — although next time I might still tape down the helping hands gizmo itself.  There's also a lot of other very basic gear I still have to get, like cutters, non-metallic tweezers, a decent soldering iron… but I'll pluck that stuff off my wishlist with each successive purchasing round as I go along.  The important part, is that progress was made!

I Made A Blinky!

Okay, so, getting back to Electronics.  I decided, last year, to try and dig my way back from the nothingness that's plagued me for over a decade.

A couple months ago I came across the free tutorial Getting To Blinky from Contextual Electronics.  Now, I can't afford the fee's he's wanting for the classes, but he has been nice enough to release a few freebies here and there, and I've been wanting to learn KiCad for a while now, so this was perfect.

Following along with the tutorial, I drew up the circuit (making my own version of the 7555 schematic design along the way), flipped that over into the PCB designer (and making another footprint), had the boards made up by OSH Park (who doesn't love purple PCB's!!!), and watched the tutorial episode where Chris realised he goofed up and had to get medieval on the 7555.  Thanks Chris.  Anyhow…  Ordered the components while I waited for the boards (and forgot the LED's), and then left it all sitting here in my desk for several months.  Yeah, life, it happens, what can you do.

Then this morning I woke up absolutely determined to put the thing together.  Pulled out my crappy cheap soldering iron, perched myself in front of the corner of our TV entertainment unit by the window, with the bits and pieces laid out in front of me; components, tweezers, scissors, solder, de-soldering braid, and my phone, with it's 4x camera zoom in place of a magnifying glass.  No flux, no clamp for the board (used double-sided tape to hold it down instead), but it was enough.  The solder joints look horrible, and I'm sure there's at least one or two on the IC that are only barely holding on, but after I was done, and I'd cleaned up the bits of packaging and put most of the stuff away, I pulled out a spare coin cell battery and threw it into the holder, and it blinked!  To my utter astonishment, the darned thing actually worked!  There it was merrily blinking away at me…  I Made A Blinky!

So now I have a fully functioning Blinky.  After over a decade of feeling like I need to get back into it but never quite getting there, I can't say that enough — as simple and small a start as it is, with so far yet to go to relearn what I've not used in so long, I'm happy.  I've learnt to use KiCad (including making custom schematic components, and footprints), order the board through OSH Park, find and purchase the parts required, and managed to assemble it successfully with barely adequate gear (and SMT to boot).  Most importantly, I've proven to myself that I can — and that little spark of confidence regained, is what Blinky was all about.

Where to now…  Well, first, I'd fixed up the little mistake from the tutorial in the design files, right after having ordered the boards.  So I think I'll order up a new set rather than persist with the nasty clipped IC leg hack I had to do with this one.  That, and purchase some flux, decent tweezers, a 10x magnifying loupe to check the joints and read part numbers, a clamp to hold the board rather than the horrid double-sided tape, and a hands-free magnifying lens so I can actually see what I'm doing.

Beyond that, I think, it's back to my desk clock with better display driving, an RTC module, and some updates to the firmware I've been planning.  Get that going on an Arduino prototyping shield, then off to OSH Park again (what can I say, I like purple!) for a single-board version.