A cute acute triangle.

Category: Hardware

Nixie clock

If you're following my blog, you must have noticed that I like writing about ideas and projects which I develop from the drawing board to the finished product. This is a similar story, but this time it's about a real thing on the market, and this post is a behind-the-scenes of its creation. So - let's dive in!

The idea

It all started from a thread in HardwareBG. I was a huge fan of the nixie tubes even before that:


These indicators were manufactured in huge quantities during the sixties and seventies, until LEDs made them obsolete shortly after. In this post you'll understand part of the reasons for that.

Determined to make my own nixie clock, I joined forces with other similar-minded people, went to a local electronics shop which happened to have 4 tubes Mullard ZM1080 in stock and bought them.

First tests

At first glance, the nixie tube is a glass bulb, which contains about ten naked conductors; the impression from a working one is somewhere in-between an incandescent light bulb and a neon sign. Its Bulgarian name - "gas discharge indicators" - hint at their true nature: the air from the bulb is drawn out (like in a vacuum tube), and there's partial pressure of neon (and other helping gasses). The voltage between the terminals is too low to cause the familiar luminescence and you get glow discharge in characteristic yellow-amber colour, surrounding the negative cathode[1] (in this case we have 10 cathodes: naked wires, shaped like digits). The similarity with incandescent bulb is illusory - the nixie tubes don't emit any significant heat.

Besides the cathodes, the bulb contains a single anode (a positively-charged eclosing grid, which needs to be 160-180 volts more positive than the cathodes). In order to display a specific digit, you need to connect the anode to a high-voltage supply, and ground the respecitve cathode. If the high-voltage supply is just right, you'll get a pleasant lit digit:



In practice it's necessary to limit the current through the nixie tube, as otherwise it may burn out. This necessitates the 10k resistors you'll see in the schematics below. Gather 6 nixie tubes in a row, and you can make a digital nixie clock.

The need to provide high voltage is a mild nuisance[2], which takes some googling to resolve. I found out how to make a HV supply out of a 555, MOSFET and an inductor, and after soldering it I went on to think how to multiplex the nixie display.


What does multiplexing mean in this case? (advanced readers: you may skip the following explanations)
If two computers needed to communicate, and for some reason only light signalling was available, that wouldn't be much of a problem. One of them would have a light emitter, e.g. a LED, and the other would posses a light detector, e.g. a photodiode. With the use of a suitable serial interface that blinks the LED, the communication is all set. However, if a computer needs to communicate with a human ... nooo, a single LED is far from sufficient. You'd need tens and hundreds of light-emitting elements, of various shapes and arrangements... you, dear reader, are probably seeing these words displayed on an arrangement of such kind having at least half a million pixels.

And the problem is that when a computer processor needs to command a complex of light-emitting elements, their large number always complicates the design. Let's visualize this with 6 nixie tubes:


What we have here is a microcontroller with 60 commandable "grounding" pins (open drain outputs). We can light up any digit on any lamp.

There a couple of issues with that design, the smaller of them being that we'd need a MCU with at least 60 pins and 60 PCB traces, which would be a pain to route. The bigger issue is that such a MCU doesn't exist because of the high-voltage tolerance requirement - most MCUs these days employ low-voltage semiconductor processes, and can rarely withstand more than 20 volts, and most commonly the limit is even lower at 5.5V. And we're dealing with 160V... If you wired a normal MCU here, it would blow up immediately.

This necessitates the use of HV-capable transistors (e.g., BS108), which you command via TTL outputs of the MCU:


Now that's one ugly schematic: the number of PCB traces increased threefold, and just placing the transistors would require soldering 180 joints. Including the MCU and nixie tubes that's more than 300. Soldering such a PCB would be an incredibly dull and cumbersome deal.

To our rescue we can notice that the scheme above grants a lot of freedom on which digits we can light up, and most of that isn't terribly useful. For example, we can light both cathodes "2" and "6" in a single nixie tube, which would work, but would just look ... strange. What we really want from one indicator is to show any of the digits 0-9, or nothing at all. These 11 options can be conveniently encoded into 4 bits, which are decoded by a specialized IC like 74141:


74141 is a really useful chip[3]: the four inputs (labeled A, B, C, D) accept a binary number between 0 and 15. Each of the ten outputs (Q0-Q9) is the open collector of a high-voltage transistor inside. If you choose a number in 0..9 (e.g., you put 5 volts on C, and 0 volts on A, B, and D), the decoder will interpret the number ("4") and connect the respective output ("Q4") to ground. Input codes 10-15 are interpreted as empty - the nixie tube is unlit.

Using 6 pcs of 74141 (or their Soviet counterparts, К155ИД1), the number of solder joints decreases to 198 in total, the MCU needs only 24 I/O pins and the design looks more approproate. We haven't multiplexed anything yet, though.

Let's divide the nixie tubes into two groups of 3: odd and even. We'll put a diverting element on the anodes, which commands which group is active:


If the switch S1 lets the HV supply to the odd group only, we have a complete control over lamps #1, 3 and 5: the decoders command the cathodes of lamps 1+2, 3+4 and 5+6, respectively, but the even-numbered won't lit up as they lack anode voltage. If we want to show "18:33:40" on the display, we send "1", "3" and "4" to the decoders and the actual display would be "1_:3_:4_".
After that we switch S1 to supply the even group and simultaneously send "8", "3" and "0" to the decoders: the display would show "_8:_3:_0":

As you can see, if you switch between the two options fast enough, a human won't notice the flicker and would assume the display shows "18:33:40" with half of the normal brightness.

In fact, we can multiplex even more! 6 can be divided by 3:


Of course we can do a full multiplexing, too:


Are there any in drawbacks here? For one, the brightness diminishes: at full multiplexing it is just one-sixth of the nominal. Of course, we can compensate that by increasing the nixie tube voltage, but this puts the nixies into tougher operation[4].
Another issue is that whatever you gain by simplifying the low-side drivers (at the cathodes) you lose back by complicating the high-side drivers (at the anodes). It's actually worse, since the switch S1 requires discrete transistors - two per group - there isn't a convenient IC like 74141 for the high-side drive. A balance has to be made; look at this comparison table:


The 2x3 and 3x2 options seemed the best. To help me decide between the two I knocked up a quick prototype to check what % duty cycle looks OK as brightness when the lamps are supplied with 160 volts. Here's how it looked like:


The potentiometer serves to select the PWM duty cycle


The warm glow of the display technology of the sixties (the background features 5,760,001 pcs of the display technology of the new millenium - credits to espr1t)

In the end I chose the 2x3 scheme: 50% max brightness and three decoders were required in total.


So after that I was ready to transfer the high-voltage supply and the commanding logic to a PCB[5][6].

This was the first revision (v1.00):


First tests of the multiplexing in operation

As I wanted the PCBs to be compact, I used the "two-storey" design from the battery level meter. The bottom PCB holds the HV circuit, the MCU, buttons and the timer chip. The top board has the nixie tubes, the decoders and the odd/even switch (S1).

I was also quickly introduced to the struggle of finding nixie tubes: I had 4 pcs only. For a complete clock you need six; luckily, Private from the HardwareBG boards had some, and practically gave away 2 of them so the set was completed:


v1.00 with six nixie tubes

Try guessing which ones are Private's :)

v1.00 was soon abandoned, as I definitely haven't provisioned enough space between the pairs of bulbs. I also bought these russian guys:




In comparison...

The prolem here was that their pins were at the bottom, while the display part was at the top; i.e., they required to be mounted on a vertical piece of PCB, in order to be compatible with the ZM1080 design. The solution was to place them on a small slotket boards, like this:


The main board has holes for both the ZM1080, as well as a 12-pin connector to the slotkets:



Let's see whether that works:



... with 6 nixies

Up next was to put something to act as the colons separating the pairs of digits. There are some glim bulbs specially made for that, but I was able to find these: MTX-90. They aren't meant to be used for indication (they are a semiconductor device), but had pretty much the same colour and intensity, and the size was good, so I added them here:



Front view

During this time, the PCBs went through two revisions: 1.01 had a bunch of fixes to bugs, improper element layouts and pinouts... v1.02 saw the PCBs enlarged to their proper dimensions and the capability to host both types of nixie tubes. Revision 1.03 carried only minor fixes.


The bottom board also had a lot going on:

First prototypes

Alas, the functionality of the clock was there. Next task was making it more safe. Even though the two PCBs were just fine laid out one above the other, the design is not solid and also exposes a bunch of wires and conductors that carry the high voltage, so it was unsafe. Instead of looking for a suitably sized box and later on wondering how to cut the necessary holes, the isolation was achieved with suitably cut acryllic sheets:


The Z573M modification

My first idea was to use steel fasteners between the four surfaces, as shown above. What I didn't like was how the shiny metal contrasted with the otherwise black design, so I tried oxidizing them with acid to turn them black. However, the resulting effect (as above) wasn't looking too good, as it was more like genuine rust, and not really black:



Plan B: let's put a simple stud, affix it with several nuts at the end, and hide it behind plastic round spacers. Sadly, I needed some oddly uncommon lengths, and the only supplier that had them in white:



This worked, but I still wanted black and turned to ebay. There I found a length of black nylon tubing with the suitable inner diameter. You just need to cut it to lengths required. The spacers fabricated in this manner had two tell-tale signs of their origin: the labels, and the inherent curvature. And while the label paint is soluble in alcohol, straightening the pieces is all but impossible. Try finding it here:


The cutting of studs and spacers was an arduous and boring job:

Thus I finally made two complete clocks: one per each nixie tube type. As I suspected others could want to solder one themselves using the same design, we (including the colleagues) decided to create a soldering kit.

Series production

The first job was to accumulate some more serious quantities of nixie tubes and 74141 decoders, as they are no longer manufactured and are rare finds (new old stock). Their prices also fluctuate quite a bit. Looking through dozens of online shops, local offers, repair forums and various bulgarian and russian websites, at some point I had more than 100 nixies of various types and state:


Part of the collection...


This pack of ИН-12s said it was manufactured in March 1984...

The decoders proved more difficult to find, but luckily I was able to find a guy from Bulgaria, which apparently had some amount stocked; even better, the ones he had were practically new:


As both the nixie tubes and the 74141s are very old and, for that reason, unreliable, I had to devise a way to test them en masse. For the lamps I just repurposed the HV board from the first prototype, added an aligator clip for the anode and a DMM probe for the cathodes. With that arrangement you can quickly test all digits.
The decoders were more complicated and I made the following contraption:

It's a very simple scheme which is powered through the button and quickly tests out all outputs of the decoder.

Statistics from the tests was that most NOS components (miraclously) worked. The defective lamps tended to be completely gone, I haven't yet met a partially working one. The decoders are the reverse, and the bad ones tended to have only one faulty output, while the others worked fine. But in the end they also went to the trash bin.

The huge assortiment of elements of various sources led me to categorize and bin them into the following boxes:


Up next was packaging. The soldering kit isn't very big and after some short search through my computer junkyard I was able to find the following suitable box from a video card:


I measured its dimensions and went to a cardboard box manufacturer, where we had to find a template with similar dimensions. In theory, they can create a template speicifcally tailored to your requirements. But that was an expensive deal, so we went to choose a template that some other client had used for his own boxes and was quite similar to ours. The cardboard is cut there and you get a pack of 50-100 unfolded sheets:


which you need to fold afterwards into boxes. Here's how a populated box looks like:


Packaging the insides wasn't anything hard, as only the nixie tubes require special care, in the form of cardboard or bubble-wrap. For the resistors, transistors and the like, we used just some regular zip-lock slips[9]. The last thing was to figure out how to place ICs and sockets. When you get them from the electronic shop, they pack them in a tube, or a on a styrofoam pad. It turns out that Dynacord (an audio systems suppler) has some styrofoam sheets which they sell by the square meter and is quite cheap (it's used for soundproofing though, so our purpose is totally different). The big sheets are easily cut with an office knife into the smaller pads that were required.

After a while I became highly proficient in "aligning the Tetris", wasting less and less amounts of the material:


This is my masterpiece :)

And thus the first bigger batch was manufactured:


The labels:


As the production grew, it became harder and harder to keep track of all items, so, to that end (and to help us with the other products as well) I created a small internal system to account it all and automate generation of PDFs with barcodes and delivery-and-acceptance forms:


Up next was getting some well written documentation - an integral part of any "solder it yourself" kit. The long doc was heavily helped with corrections and clarifications by Alex, and thus the Assembly and User Manual was born.

Release was drawing near and I engaged in making a small webpage, showcasing the product, and I needed some promo materials. I didn't have much experience in product photography, but after some reading I knocked up a lightbox from spare sheets I had lying around and now I had the beautiful white background:



With a touch of post-processing

The set-up looked like this:



... one goes to great lengths in framing everything right ...

An important aspect here is the lighting. The CFLs emit a cool daylight, 6500K. This contrasts a lot with the normal warm-white 2700K lights I had everywhere else in the apartment; however when you apply the white balance for 2700K, the colour of the nixie cathodes turns into an unpleasant cold and violet hue.

With the pictures ready, I went on to see how those big, flashy full-screen websites are made (yes, the appearance is key here). Turns out that is simple - using Supersized I created a minimalistic page to showcase the product.

Up next was distribution and sales. To that end, our friends from Robotev jumped in, we agreed on terms and prices, I brought one batch to their office and the product entered their catalogue. We were up to wait for the first sales.

In order to prop up the popularity of this otherwise unknown product, I did two things; first of them being to spend my Google AdWords credit I was given as a present years ago.

While it is trivial to make a Google Ads campaign, targeting the right customers is tricky. If your keywords are the reasonably specific ones (nixie clock, gas-discharge lamps, nixie clock), then the visitors are really a tiny trickle.
Google was offering the keyword "clock", all by itself. I followed that advice, but it turned out to be a bad one - this stole away from the huge traffic of people looking for wrist watches. In that case, people were just not looking for this, and although the impressions increased a lot, the click-through rate fell dramatically. Soon I abandoned the campaign, it was definitely not heling.

The other thing which proved more successful is to give one demonstrational clock for display in Robotev's office. Do you remember the nice ZM1080 nixie tubes from the first prototype? Well, they ended up here:


Finished kits

Even though most of our clients wanted to solder the kits themselves, it turned out there's some interest into ready-made ones. I went to the packaging company again to look for bigger boxes:


The company's cat was giving me advice

The white colour of the boxes made it possible to create larger and flashier labels:


To support the product (on a tip from Robotev) I put up a forum. Also, I continued to try new elements and ideas. Here's one clock I crafted specifically for the round anniversary of a good friend of mine, this time using the ИНС-1 indicators for colon separators:


And another one, which I used to experiment with a different colour scheme:



This is not a clock - this is a decimal-to-binary converter :)


What did I learn:

The future:

  1. We need to find a way to export this kit from Bulgaria, since the market for these very geekish products here is very tiny. By the way, if somebody would like to cater for selling these over ebay - please contact me;
  2. Add a PIR sensor, so the wakeup from the screensaver happens on movement too, not just on loud noise;
  3. Tranfer the code to AVR, since it's definitely the platform for DIY enthusiasts, and most people have experience (and programmers) for that;
  4. Throw in a GPS for automatic time sync;
  5. and much more...

As with any other big project, this one could be expanded more ad infinitum. However, this post got overly long already, so I have to wrap it up. Congrats to all who reached here:) I must pay my HUGE thanks to the dozens of people which helped me to get traction with this project and turn it into reality. I won't enumerate them, the list is long - you guys know who you are! Thanks for helping my dream come true!

Posted in category Hardware -- clock 11 Dec 2016, 06:43, 3 comments



As it is well known, technologies can be helpful, but can also be just as annoying, as today's rant will show.

In the old days, PC and laptops provided 2 audio ports: an output one (for headphones), and an input one (for a mic). You can hardly make this simpler, but more importantly it worked well:


Well, in the last 4 years the trend is to combine these two ports into a single, four-pin (TRRS) one:


I can't for life understand why the laptop manufacturers thought this is a good idea - but the fashion came out from the smartphone world, where the space budget is tight and that sort of tricks actually make a lot of sense[1]. Anyway, the result of combining those two ports into one is that questions like this or this arise, and people are wondering how to connect their good ol' microphones to the laptops. The problem is that the combo port works for normal headphones, or for headphone+mic combos (and only if your specific combo has the correct pinout at the jack, as there are two competing standards for that). But just a plain mic doesn't work, as its pinout is completely incompatible.
The standard solution to this problem, as far as these threads on the web go anyway, smells of the characteristic 21st-century obtuseness: just buy a new USB microphone! It connects so easy and just works, etc.

That's great, but in my case I'm not connecting a mic. I'm connected a DIY light-to-sound converter, which I'm using to download the data from my Battery level meter. It connects via a 3-pin audio jack, but that's where the similarities with a mic end.

Of course, you can buy splitters like this one:


I had the necessary jacks so I crafted my own splitter, but it didn't work. Turns out, the laptop requires to sense that you have headphones connected, otherwise it'll assume the audio port is not occupied.

This was a bit too much. Out of spite, and led by a bout of OCD, I crafted the following scheme:
The 15-ohm resistors simulate the headphones :)

It fits on a very small perfboard:

The cable from the 4-pin jack arrives here; the other side of the board houses the resistors and the female 3-pin receptacle. The latter accepts a regular mic jack, whereas the 4-pin is for the stubborn laptop, which now "sees" a headphone+mic combo.

As I wanted the whole adapter to be a bit more rugged and safe, I crafted a box. The picture above was actually taken to provide a convenient way to sketch out the required sizes. After some CAD-ing on Blender:


Then I 3D-printed it and forced the board inside:


These thin wires would be a fragile spot in the future, so I fixed innards with a hot glue gun:


Which completed the adapter - the microphone circuitry in the laptop finally yielded and was happy to record. I still wonder if it was worth knocking up this contraption; it probably isn't, but I was furious about the shortsightedness of the Lenovo engineers. So this eccentric response serves them some poetic justice :)

Posted in category Hardware -- clock 23 Nov 2016, 06:37, 0 comments



Today I'll describe a tiny project that I did dome time ago, which finds a connection between TVs, infrared and some mints.

Introduction (sort of)

I'm thinking that school programmes, especially with regard to natural sciences, could be taught in a more intresting manner. The theory is often fine by itself, but the teachers miss to address some questions which are invariably going to occur to the kids (maybe not to all kids; just the more curious ones) and puzzle them later. xkcd has a very good example with the physics lesson where we learn about the "bird-inspired" airfoil shape, and how it manages to generate lift. Yet nothing is done to address the obvious question: airshows regularly feature fighter aircraft flying upside-down — but the plane doesn't fall down despite the wrong orientation. What's more, the explanation (regarding the angle of attack) can be trivially tested by any sixth-grader waving his hand outside the side window of a moving car!

It's probably expected that these questions are addressed after classes, but in our schools that generally doesn't happen, or, at least, very few ask the teacher questions outside the curriculum. And it's better if everyone is trained to ask questions and locate potential problems in the theory. The airfoil is not an isolated exaple - many times, the theory given is at least shallow, or there are obvious defects sticking out of it.

A similar experience of mine was the explanation of infrared rays. They told us that all things emit IR, amount depending on temperature. We were also told (but probably in a different class) that TV remotes also work with IR. What they didn't explain is how the TV-set differentiates between the former and the latter types of IR. Yes, in a calm room, the "background" IR are more or less static and I imagined, that the TV can differentiate that easily. But what will happen, if you put your TV opposite to a well-kindled fireplace? I've seen this thing happen and I imagined that the TV will change channels or enters menus or otherwise go awry. Nope.

It was after I got into electronics that I found out this powerful pattern of digital circuits. It's easy to generate a signal, a short one (from human point-of-view), yet sophisticated and specific enough that the nature has no chance to emit it ever, even in millions of years. What's more, these signals, at least for IR remotes, are well described and categorized, in tabular form. From there, some smart guy had taken upon the idea of creating an universal device, which can turn off any TV. You press a button, and, in the span of one minute, the codes for "On/Off" in all possible IR encoding schemes for every known TV are sent (there are more than 60 variants, as each manufacturer apparently created his own). The device is discreet enough to be hidden in a purse or a pocket, so you can surreptitiously turn off that annoying TV in the bar, because you've come here for an intellectual discussion while eating, and watching football (for example) just doesn't qualify...


So at some point I ordered the TV-B-Gone kit from Adafruit (there are ready-made units, but I wanted a custom one). Assembled, it comprises of a small circuit board with 4 protruding LEDs (with slightly different spectrum and sreading characteristics), a button, and a holder for 2xAA cells. However, this way it can't be easily carried arround. The protruding part would easily break off, and the gentle conductors to the holder wouldn't last long. So I thought about an enclosure - either polymer clay, or a ready-made from Farnell... Finally, a coworker saved me from wondering further by giving me one tin box from Altoids mints, which he apparently brought from the US. His exact words were - "I see that you do some electronics, this will help".

I had previously seen a lot of american hobby electronics sites and I wondered somewhat about their obsessive fixation on these boxes. As if there was nothing else with that purpose on the market! You made an emergency phone charger out of a nine-volt battery and 7805? Put it in an Altoids box. Headphone preamp? Altoids. Guitar Effect? Altoids.

It was after I fooled some with it that I realized how good it was. It has a lid. And it's held shut tight, the hinges are not some feeble plastic. You want to show what's inside? No problem:

TV-B-Gone exposed

And here's how it looks when shut closed:


What's more, the 2xAA holder fits exactly to the width of the box. The circuit board then fits just tight to the remaining length. Coincidence? I don't think so:


You might be wondering why the microcontroller (in this case, an 8-bit Atmel) doesn't command the LEDs directly, why there's a transistor per each. The reason is that the LEDs are powerful (that's why it's powered by AA, not AAA cells) - the idea being that the device can turn off a TV 50 meters away. It packs quite a punch, unlike a regular TV remote. Even more, if you look straight at the LEDs, in a dark room, you can even see how they blink. Who said humans cannot see IR?

Drilling holes for the LEDs and the switch is trivial, and in the end you have a wicked device, inconspicuously hidden in a box of breath mints:


I could hardly thought of a more treacherous device — victory for science (with a hint of cinnamon)!

Posted in category Hardware -- clock 15 Mar 2015, 10:42, 2 comments


Remote control (part 2)

In the previous post I promised to tell you more about the remote control of household loads I made. But first, some background...

Last January I had to do some small house renovation, and I contacted this guy, recommended by friends, who demanded some outlandish amounts for the work. Waay above the market average. It was my mistake, of course - I had told him what I did for living. In Bulgaria, it seems, a lot of people think that programmers dig boatloads of money, so no price is too high if you client is one of those. For that reason, the guys I actually hired later had it that I work as an Electrical Engineer. The cables, breadboards and soldering iron scattered around helped with that ploy ;)

Well, it was a bit unexpected when it came to laying and connecting power wires. The workers left that to me - after all, I should be very good at this kind of stuff. In my case, I ended up with a bunch of spotlights that I had no way of connecting: the only lightswitch in the kitchen was a simple one: a live wire comes from below, and a single wire continues toward the ceiling lamp. Even if I managed to bring neutral from somewhere, I had to dig channels in the walls to reach the spotlights.

For that reason I wired the lights to regular hidden wall sockets, with lazy switches to command them. But this was all meant to be a temporary solution; it was inconvenient to operate them, and I definitely wanted a centralized lighting control, from a single switch.

In the same time, I had bought some RF modules long ago (these ones). They use a 434 MHz band and are intended for hobby work, with pins to be directly inserted into a breadboard. They are capable of transmitting "1 pin" of information - whatever voltage you send to the input pin of the transmitter gets generated on the output pin of the receiver. So the idea I got was to create a circuit that stands in the way between the hidden sockets and the spotlights, where the receiver controls a few relays. And the sender would be used into a miniature circuit, that would fit into the wallswitch socket (without any mains connection there).

As mentioned, the 434 MHz modules are hobby-oriented, and even though the interface to them is very straightforward, the abstraction they provide turns out to be a really flaky one. First, the state transmission is discretized in time - 4800 bps - so it's quite slow. I didn't need speed, so this wasn't an issue, and I initially envisioned a purely "analogue" circuit without any logic - one side has a switch, directly controlling the transmitter, and the other and has the receiver hooked up to some transistors, which command the relays. Well, probably with a RC circuit in between, to filter out any noise. But I was told by somebody about the flakyness of these modules so I went on to check the feasibility of the idea.

Indeed. When the transmitter is turned off, the receiver gets some random noise. Even when the transmitter is powered (and it was expected to be only intermittently), there were bursts of wrong bits on the receiver side - so the necessity of digital logic, employing some kind of error-correcting code, was apparent, least not if I wanted a random disco in my kitchen :)

I prototyped the two parts of this thing on a breadboard first. The sender/receiver were communicating well, and as a guard against the random noises, the transmission starts with a fixed "magic byte", which is checked for correctness at the receive end. I turned off the transmitter and must have had forgotten the receiver running for half an hour, when, to my dismay, I saw that the test LEDs powered up. The noise from the ether had managed to create the magic byte, and the transmit side interpreted the noise afterwards as a command ...

I solved that by increasing the magic bytes to four, and I send the command byte twice, for consistency checking. That got it running, but now it was not reaching every time, especially if there was a wall between the devices (these are the cases with YOU SHALL NOT PASS). I.e., the random noise apparently changes some of the bits of the magic header and the receiver drops the message. To combat that: the message gets sent 10 times, hoping that at least one should gets through.

So the prototype was working, and I went on to solder a miniaturized version of the sender::


After trimming:

The idea is that the whole thing must fit into a wall hole for a light switch - which is very limited volume indeed. Luckily for me, the designers of the transmitter module obviously had applications like mine in mind and had made it quite compact:


The perfboard is just for convenience. I could have point-to-point soldered everything:


The thing is finally connected like this:


An interesting problem that took me a while was how to power the thing. The transmitter requires around 8 mA at ≥3V (it gladly accepts more). But at this usage, any normal battery would drain in a week, so I turn off the transmitter when not in use, ditto for the microcontroller, and they're woken up only when needed. The standby consumption is around 0.1 µA, but the active one is a bit high for coin cells like CR2032: under load it would drop below 3V, so they got out of the question. I thought about a 3-pack of silver-oxide SR44s, which would have worked, but their capacity was too small, the device would need replacements every year or two. A similar solution would have been to use an A23 battery, but it had the same issue, and it also required a regulator. A small lithium-ion cell would have been okay on voltage and capacity, but I doubt that a rechargeable one would hold the charge for more than a year. In the end, I found out what they use in the industry for exactly these kind of things: lithium thyonil-chloride. These beasts last for decades, losing only 1% of charge per year in standby, and pack a huge amount of energy per volume. The nominal voltage is 3.6 volts, which is also welcome. The downside of this chemistry is its intolerance to short circuits: it can explode, and its contents are quite toxic. I even got an order rejected from my electronics supplier for this reason - these batteries are considered hazardous materials, so are not readily shipped. Luckily, another supplier had them in stock, even if the smallest size he had was unnecessarily big for my application.

After the transmitter was ready and tested, I got to make the real receivers as well (I needed two, for the two sides of the kitchen).

Here the perfboard would have been ugly and dangerous - having line voltages on random tracks and sticking wire ends is a no-no. So I designed, and LUBO_1 printed me, PCBs for the purpose:


Added: relays, a rectifier, and a fuse holder:


The rest of the electronics:

In the beginning I fitted these fuses:

0.5 amp ones, which should have been enough for my 80 W spotlights. However, loads like this - lamps, especially incandescent ones - have a huge initial surge current, and the fuses blew almost right away. Lesson learned, I bought and installed slow-acting ones.

The receiver is ready:


I made two copies:


Note that the PCBs are identical - they both have tracks routed for four channels. The first board has a relay and transistor only for channel 1, the second has for channels 2 & 3.

The PCB solves the problem with the line voltages dangling around. Nothing can electrocute you on the upper side. For the back side, I had 4 adhesive rubber pads (which I had randomly picked from Lidl, one of these purchases where you regretted you didn't buy more), so the solder joints are also not touching anything potentially conductuve below. I realized afterwards that the fuse holder and the fuse itself are still at line voltages and went on to search for a solution... and indeed, they have standardized plastic covers for these holders:

plastic cover for fuse holder - standardization ftw

The two receivers, ready for mounting:


Channels 2 & 3:

Channel 1:

The digital control logic has its obvious advantages. I programmed a self-timer to turn off the lights if I forgot them for more than 1½ hours.

So this is the main system. For the fun of it, I decided to make a computer-controlled transmitter, as it was shown in the previous post. There are a lot of ways to connect a PC with a microcontroller, but one of the simplest is to use a parallel port. Sadly, these wonderful things are phased away, but I still have a somewhat old home server laying around... The interesting part here is how I managed to power the sending device from the parallel port directly. As you know, unlike USB, the parallel port interface has no power lines, but it's still possible to "steal" a small amount of current though the data pins. The limit is really small, like 2mA in the strictest specs, but usually you can get around 8-10 mA per pin. Just in case, I wired up four of the eight pins just for power (after a schottky diode each) - so I have 8-40 mA at my disposal for powering the transmitter. When you programmatically send a byte through the parallel port and you set the 4 least significant bits, my device there detects that it's fully powered and turns on the transmitter. The higher four bits/pins are used for communications. Commanding the parallel port is made easy by libieee1284, interfaced though a small C program on Linux. And, of course, I did a simple webinterface, that runs on an apache server. So now, I can control my spotlights (or any other load if I wish) via a wall switch, using a smartphone or a tablet, through ssh, or even periodically via cron...

The hardware of this thing is till on breadboard:


Here's the connection to the server:


I was slightly worried whether the RF would work, since the server and the receivers are in different rooms and the signal must go through two walls. Luckily, it seems that the send-ten-times thing works even here.


In the future I plan to utilize more high-level communication modules, e.g. ZigBee, since coding and debugging noise-proof protocols is not as much fun as it seems. For example, while testing the computer interface, I had a very weird issue. There was no way to turn on the first channel, only to switch it off, if you sent a command for switching off the THIRD one. And also, commands for channel 1 affected channel 2, and commands for 2 affected 3. In the beginning it seemed like a simple bug, but after reviewing each part of the stack that turned not to be the issue. It was just... the tranmitter sending out the bits slightly too fast (which I discovered through trial and error). This is a common theme actually - when you have only one pin for communication, you need to make your protocol self-clocking, i.e., you need to ensure that the two endpoints don't go out of sync. UART does this by employing start and stop bits, but I was sending bits verbatim, since, gee, what could possibly go wrong for 48 bits? In the end, slightly lenghtening one delay solved it. So indeed, are you still thinking that printf-debugging, or through a terminal with gdb is painful, ugly, and obsolete? Meh.

Posted in category Hardware -- clock 12 Sep 2014, 01:09, 4 comments


Remote Control (part 1)

How it looks like:

And what actually happens under the hood:

Finger: poke!

Touchscreen to driver: we have a registered press on row 16, line 3.
Driver: Will wait a bit to see what happens...

after a bit...

Driver to kernel: got a press, you interested?
Kernel: really? I was just about to send some very important data to NSA...
Driver: interrupt that for a while, the human is pressing something.
Kernel: what kind of press? Single, double, does it move?
Driver: no movement, it's a single press, coordinates are (36, 388)
Kernel: does he hold it?
Driver: no, he already got his finger off the screen.
Kernel: OK.

Kernel to UI layer: you have a single press at (36, 388)
UI layer: this is in the application area. Browser, you have a single press at (36, 356)

Browser: I have a press on one of the pictures, but it has an image map on it, with some javascript behind. And an onClick handler - Javascript, go ahead.
Javascript: first, can you please change the picture to "i/on.png"?
Browser: got it cached, will change it.
Javascript: second, please send this GET request to on the same site/folder. Parameters apply - channel=1&state=1.
Browser: sending right in, will notify you when I get a response.

Browser to kernel: can you open up a TCP connection to, port 80?
Kernel: OK

Kernel to wireless card: there you have this SYN packet, can you please forward it to Oh well, you're actually interested in its MAC address, it is, lemme see, 00:1C:C0:BF:87:A1.
Wireless card: done.

Invisible, inappreciable electomagnetic waves, indistinguishable from the surrounding ones, shoot up in to the ether amongst the rest of the natural and artificial noise. Microscopic, short-lived voltages reflect of the walls, fly through the air and wake up an unsuspecting router...

Router: whoa, a packet? It's not for me, though, but I know this 00:1C:C0:BF:87:A1 MAC - it lives at port 2, redirecting.

Switch/server room: incoming packet from port 5... addressed to 00:1C:C0:BF:87:A1. I know him, he's on port 1, redirecting.

Network card to kernel: you've got an incoming packet.
Kernel: this is an IP packet from The firewall says we have to let it in. What's in there? Aah, a TCP to port 80.
Kernel to webserver: you still listening?
Webserver: yes!
Kernel: good. Will send a SYN-ACK back.
Kernel to network card: A packet please, the destination is D4:22:3F:81:03:9E.
Network card: sending.

Switch/server room: now a packet from port 1... addressed to D4:22:3F:81:03:9E, I know him, he's on port 5, redirecting.

Router: a packet, D4:22:3F:81:03:9E is known - he's on the wireless interface.

Invisible, inappreciable electomagnetic waves, indistinguishable from the surrounding ones, shoot up in to the ether amongst the rest of the natural and artificial noise...

Wireless card to kernel: we've got a package from router.
Kernel to wireless card: great, they replied to our SYN. Send them an ACK.
Browser: send them this HTTP GET packet as well, pls.
Wireless card: I'm on it.

Invisible, inappreciable electomagnetic waves ... you get the drill

Router: two packets for 00:1C:C0:BF:87:A1 - port 2, redirecting.

Switch/server room: two packets for 00:1C:C0:BF:87:A1 from port 5, redirecting to port 1.

Network card to kernel: we've got two packets incoming
Kernel to network card: give them to me!
Network card: in what order?
Kernel: I don't care.
Network card: here's the first one.
Kernel: wtf? This is some data, from a connection that is not yet opened. Give me the other packet.... oh well, here's the ACK, it all makes sense now.
Kernel to webserver: incoming connection, do you want it?
Webserver: yes, please.
Kernel: here.
Webserver: okay, they want to fetch, with parameters channel=1&state=1. Looking at my config, this has to be a CGI script.

Webserver to Python: you've got an incoming connection, tell me what should I send back?
Python: where is this connection from?
Python: they are from the internal network, good. Are there any parameters?
Webserver: yeah, channel=1, state=1.
Python: okay, the channel is set. Is it in [0..3]? Yes. State? [0..1]? Yes. All good, time to call this small C program.

Small C program: huh, somebody started us. We've got parameters! First is '1', is it within [0..3]? Yes. The second? '1', it is in [0..1]. All good.
Small C program to kernel: can I access the parallel port?
Kernel: do you have the necessary privileges?
Small C program: yes, I'm from the apache group.
Kernel: Let's see... okay, have this port descriptor.
Small C program: I want exclusive access, and please send the value 0x5f to the port.
Kernel: deal.

Microcontroller/server room: yawn. Somebody powered me, I betcha they want me to do something. I've got power on three..., not - four pins. This is serious business, I'll power up the transmitter
Small C program: you ready?
Microcontroller/server room: yeah.
Small C program to kernel: send the value 0xdf to the parallel port.
Kernel: done.
Microcontroller/server room: look, they changed the most significant bit, so the command is real. Let's see... we need to set channel 1 to state 1...
Microcontroller to transmitter: can you please send this series of bits via the RF link?
Transmitter: I'm on it

Invisible, inappreciable electomagnetic waves, indistinguishable from the surrounding ones, shoot up in to the ether amongst the rest of the natural and artificial noise...

Reinforced concrete wall: YOU SHALL NOT PASS!

Microcontroller to transmitter: send them again, we can't be sure if the got through...
Transmitter: good.
Reinforced concrete wall: YOU SHALL NOT PASS!

Microcontroller to transmitter: once again...
Transmitter: OK

Microcontroller/kitchen: well, there's some activity lately, as if somebody tries to talk to us, but some of the bits are corrupted. Here, this is the third time I'm seeing the header... and... wait, this time it is OK! So there's a command, let's see. Channel 1 = on. We light up channel 1 then, it's currently off.
Microcontroller/kitchen to Q2: hey, transistor, how's it going?
Transistor Q2: I'm keeping the electrons at the source right now.
Microcontroller/kitchen: let them through.

Transistor to relay: there's a pack of electrons coming to you - just that you know.
Relay: Click!

Electricity: whoa, I've discovered a new path. What could be there? Let's see.... crap, a switching power supply. I hate switching power supplies!
Switching power supply to lights: shine you bastards!

As you can see, I'm having fun with RF modules and their use for some home automation/smart house things. Please visit part 2, where I'm describing the components of this system in more detail, along with pictures.

Kudos to Misho Stanchev for the JS part.
This post strives to be both fun and technically accurate. Report any errors in the comments.

Posted in category Hardware -- clock 10 Sep 2014, 01:17, 3 comments


Hardware random generator

I'm getting better at electronics :) When I decide to build something, it now takes me around six hours to complete it. This weekend was in a I'm-somewhat-sick-n-bored mood, so I decided to build a random generator.

And not just a random generator, but an arcade monster! With ridiculously big indicators and buttons! Blinking brightly and stuff...
It would be utilized in board games like The Settlers Of Catan, where you need to throw a pair of dice and sum their roll. In fact, the generator just "rolls two dice", and a jumper determines what to do with the outcomes.

Hardware random generator

Computers usually employ algorithms like LCPRNG (or more sophisticated), with the side effect that whenever a "supposedly random" lottery draw is done on a computer, you'd have a very hard time convincing the average joe that the drawing isn't manipulated :) Luckily, having a more close-to-the-metal access to the hardware allows you to code something like this:

	while not keypressed() {
	return (counter MOD 36);

What do we have here? A counter is incremented extremely fast (thousands and millions times per second). When the button is depressed, the counter immediately freezes at its last value, which is used to determine how did "the dice roll".

Now, imagine highway driving. And in additional to the usual per-kilometre signs, the asphalt is ruled finely, into metres and centimetres. Each centimetre tick has a number associated, and the numbers increase cyclically: 0, 1, 2, 3, ..., 34, 35, 0, 1, 2, ... While driving, you throw a steel ball out of the car. The ball lands somewhere and you take the number, associated with the closest centimetre tick. This is roughly what the code above does - the outcome is essentially random. Then one has to apply some 1:1 mapping between the 36 possible pair-of-six-sided-dice rolls and the numbers, and we're ready.


Here I'm testing some possible layout configurations. I got the huge button from SparkFun.
Image Image


The mandatory breadboard design phase:

Here I put a miniature counterpart of the big red button:


I swore that I'd never use a perfboard again, right? But this project would've been an overkill to do with a PCB, so I used something simpler: a stripboard (a.k.a. Veroboard). This is a prototyping board, which has parallel copper-clad strips. The elements are usually placed perpendicular to the strips, which leads to a characteristic order in the design - all paths are straight (in coherence with the inner peace of someone who grew up in Manhattan or Stara Zagora!).

My first job was to drill four holes with my new toy:

In retrospection, I wonder how I'd lived without a Dremel :)

Soldered some sockets:
Image Image

The strips in these these boards are very long, but are easily teared with a simple tool, so one horizontal may be used to connect several different groups of components. Here: we have to isolate the two sides of the MCU pins, and same for the indicators:


On the plus side for stripboards are: less soldering, very few custom connections, and error tolerance. If you mess up something, it can usually be fixed without desoldering. Run the tool to isolate the wrong part and reroute it somewhere else. On the other side: be careful with soldering, it's easy to introduce tiny "whiskers" of solder, that inadvertently connect neighbouring strips. I had two errors of this kind and debugged them for quite some time...

Filling up with resistors:

...and elements:

Please, install software:

Visibly progresses to near-finished:
Image Image

I decided to put the 7-segment indicators on sockets - they could be soldered directly, too, but that would make the huge space below them unusable.

Finishing touches

Test blink on the segments...:

... and some test digits...:

I imagined the finished thing to be like this:

However, I didn't like the power switch. It's big, and accessing it conveniently would've required drilling a big hole, and would need some redesign due to space constraints. However, I had these cute toggle switches...

So I put into action the other new toy:

Seemed like the drill bit was rotating lazily, but it drilled into the plastic as if it was butter...

Image Image


The timer is at 6 hours and a half after the first photo. Here's how it looks like with the lid closed:

Please, press the button:

Here, you're lucky:

And an useless sign:
something like the electrical equivalent of the code i++; /* incrementing i by one */

Here's it in action: YouTube

In the end, I wanted to make a random generator, but it turned like a lot like a timer-activated bomb (or probably has the looks that Hollywood formed in my imagination).

In conclusion



The C source code is available here.

I'm looking forward to the upcoming holyday season, there would be a lot of Catan, and I'm impatient to test my generator :)

Posted in category Hardware -- clock 9 Dec 2012, 16:09, 3 comments

Older posts >>




Open source


+ 2008 (9)
March '08 (2)
April '08 (2)
May '08 (2)
October '08 (1)
December '08 (2)
+ 2009 (8)
January '09 (2)
March '09 (1)
August '09 (2)
September '09 (1)
November '09 (1)
December '09 (1)
+ 2010 (9)
January '10 (1)
April '10 (2)
June '10 (1)
July '10 (1)
September '10 (1)
November '10 (1)
December '10 (2)
+ 2011 (10)
January '11 (3)
February '11 (1)
August '11 (2)
September '11 (2)
October '11 (2)
+ 2012 (14)
January '12 (3)
March '12 (1)
April '12 (2)
May '12 (3)
August '12 (1)
September '12 (1)
November '12 (1)
December '12 (2)
+ 2013 (1)
March '13 (1)
+ 2014 (3)
September '14 (3)
+ 2015 (5)
January '15 (1)
March '15 (3)
May '15 (1)
+ 2016 (4)
June '16 (1)
July '16 (1)
November '16 (1)
December '16 (1)

Last comments:

26 Dec 2016, 17:52 by Private
19 Dec 2016, 23:01 by ицаци
16 Dec 2016, 19:50 by Антон
8 Dec 2016, 01:23 by anrieff
8 Dec 2016, 01:06 by Николай
12 Jul 2016, 14:12 by anrieff

Valid XHTML 1.0 Strict


linkJoel on Software
linkRidiculous Fish
linkXKCD blag