Cute little thing

Aww, isn't that just a cutest little thing?

Of course, what goes in and comes out is a bit less cute:

Yellow is what's going in, green what's coming out. Pay attention to scales!

The signal comes directly from a signal generator so the power of the output signal is essentially nonexistent. Still, when dealing with such high voltages, I'm not putting my hands anywhere near that thing when it's connected. I get really nervous (and very very careful) whenever dealing with large voltages (anything over 50v or so), and really, that's how it should be. Electrical burns aren't fun - been there, experienced that.

There's just one thing that's more dangerous that high-voltage source, and that is high current source. 100v at 1 milliamp may burn your circuit or give you a nasty shock, but even 1 millivolt at 100 amps through wrong thing will ruin your day. And since the voltage is low, it's too easy to forget that and be a bit too sloppy.

That being said, now what can I do with this little thing...

Clogged extruder

It was bound to happen one day. Extruder in my 3D-printer clogged up and had to be cleaned.

After quick reading I found out that there is essentially two common ways to clear the extruder: Acetone bath and blowtorch. I'm not fond of playing with fire so I went for the first option. And I actually had acetone on my shelf - I needed it years ago with some lure painting experiments.

So down to jar of acetone the extruder went.

I don't know if PLA as material is more resistant to acetone than ABS, or if acetone I had was aged badly (bottle was easily more than ten years old), but it didn't do anything. So it was time to consider option number two again.

As it happens, I don't actually have a blowtorch. I do have a gas-powered (as in propane/butane, not gasoline) soldering iron but there was the aspect of fire, still.

Taking a look around I noticed my hot air blower. This is no hair dryer, no, even the low setting says 350 degrees Celcius and high setting apparently is more than 500 degrees C. Or so the label says at least.

It still isn't something one should play inside as pointing this thing towards wrong things might cause some serious damage (I use it mostly on low setting to shrink shrink-fit tubing.)  It actually came with this piece you could attach to the business end of it to limit air flow, but thata ctually melted (well, softened enough to become misshapen) the first time I used it. Great quality there (or maybe instructions said that it's only for low power setting - dunno, never did read them.)

So out I went, armed with pliers, side cutters, metal bowl (actually quite thin cover of metallic box that originally contained a small drill) and the blower.

And what do you know, this thing worked perfectly. It took less than half a minute for plastic to almost drop by itself from the extruder. After that it was time for another acetone bath, although I'm not sure if that actually did anything, but at least the printer is fine again.

Yes, that is wood there underneath. It's fine though as (long as) hot air isn't blown towards it, and extruder (only hot part in direct contact with metal bowl and thus indirectly wood) doesn't have sufficient thermal mass to even warm the wood. The white blob of PLA is actually just barely visible on the photo, right next to cutters' blades.

 Another nice way to clean the extractor. And I'd prefer this over the blow torch any day.

PCB design fails - and rules to avoid them

Even with experience mistakes happen. Some time ago I ordered a new tester board; nothing really fancy, a fairly simple and quick two-layer design that I needed only a few boards total. And of course I somehow completely forgot to add few signal lines. Not route, that would have been visible with airwires; signals weren't connected at all on schematic level.

There was no point making new boards, so I just added jumper wires. Processor has 0.5mm pin pitch, chip at other end (a common mux/demux) 0.65mm. Not greatest solder job but good enough for now. And dab of glue will keep wires at place.

At the lower right of the MCU there is a fix for in-system programming header. Somehow I got two signals mixed up and had to fix that with wires, too.

Obviously I have fixed schematic and layout too, in case I actually do order new batch at some point, however unlikely that actually is.

With this kind of screw ups I've make a mental list of some rules for PCB design to avoid this kind of issues.

Rule #1: Take your time.

After board is "done" I still open it for quick review few times during a week or so. Although you are done with the board, your brain is still working on it, subconsciously, and may suddenly remember some things that you have missed. Similarly looking at the board after few days allows you to note some stupid mistakes you might have made.

This of course applies also to schematic phase. Your mind will be working on it even if your body is out taking a walk or whatever, but since schematic is done before layout, so you can return to schematic while working with layout, so it is less critical at that point.

Even in middle of design it can help to take a break and not actively even think of it. Take a break, really, you will return to work refreshed and with added energy later on.

Of course you might not always have time to spare, but that is another issue completely.


Rule #2: Use ERC.

This I might have said already, but the design check tools in your CAD package are there for a reason. When you first run it, it might look frustrating when you get tens or hundreds of errors, but they are there for a reason.

On schematic side the tool is ERC, or Electric Rule Check. It will allow you to note stupid errors like this where one of the supposed ground pins actually isn't connected to ground. The other error is stupid; when I designed connector I for some stupid reason or another defined to have value. It shouldn't, and in schematic I haven't defined value (value typically meaning resistor's resistance: 1k [Ohm] for example) so it complains. But when you down to errors you know you can ignore, all is good.

 Rule #3: Use DRC.

On layout side counterpart for ERC is Design Rule Scheck, or DRC. Running it costs almost no time but allows you to fix errors immediately. Later, after you have routed dozen signals at the same area it will become a lot more difficult. So use it early and use it often.

Another stupid issue, but there is plenty to space to fix this. There two examples here are actually artificial (aside the value issue with connector); I created them on finished board as an example. But trust me, there were plenty of real similar issues before I got to this point.

You might notice that the partially visible via is close to red track. There is no error there, as DRC indicates; that via on between layers 1-2, but red track (and its via) is on layer 15. So no error there. (four-layer board with layer names being 1-2-15-16, don't ask.)

Rule #4: Show me the signals!

I adapted this rule because the very first error I showed at top of this post. When board is completely done it is a good idea to issue "show signal" commands (in Eagle, your CAD package might have different command for that) for each and every signal there is. ERC should catch this too but I guess I got lazy there. Violation of rule #1 too. Lesson learned.

This can of course be run earlier too, but it is less useful before board is "finished".

This is the result after "show out1" command. Only one pad on MCU is highlighted, nothing else on board (note that there is no airwire; I cropped out rest to allow focusing on this point here).  There is obviously some problem here, either "OUT2" was mistyped at other end or never connected to anywhere. Either way it won't work very well like this.

In addition of noticing things like this you may note that things like analog signal being routed through a noisy part of the board, or high-frequency signal (like auxiliary clocks) taking a way too long and complex (read: slow and potentially noisy) route around the board.

Rule #5: Take your time!

No, really. This is worth repeating, and applies to all engineering (and other fields too). Take a break now, both you and the design will thank you later.

Placing bypass capacitors

Bypass caps seem often to be kind of black magic to beginners. But really they aren't, that designation is reserved for RF stuff, they just serve a purpose so common and essential that often they get ignored with a "just because". And beginners get confused.

Bypass capacitor is smallish capacitor that should be placed right next to chips' power supply pins (be they memory, microcontroller or any other IC.)  Exact value depends on situation, but in my use 100nF is quite common these days. For beginners they are often explained with little more than "just put them there" so it's easy to get confused about them.

A quick search gives you lots of examples on how to (and how not to) place them, but reasons for this are not often provided. As it happens Dave Jones did a video just a few days ago explaining the reason, without delving too deeply to details. If you don't know about why yet, I'd recommend that you watch that video, it should help a lot.


For a simple chip bypass caps are easy to place - there may be just one supply and one ground pin, so that one bypass capacitor is easy to place. And supply trace must go through the capacitor (well, positive pin/pad of capacitor), otherwise that capacitor is effectively bypassed (dare I say it - ironically enough) by signal and thus completely useless.

As chip grows in complexity it may have easily 10 or even 20 supply pins and equal amount of ground pins. Each of supply pins should be bypassed separately. Now things are starting to get a bit annoying, having to place so damn many caps.

And if chip has several supply voltages, say 3.3v for logic and 1.8v for core? Even more annoying - first you have to figure out how to route both supplies (with space left for actual signals), and how to find space for caps. And large FPGAs? Well, let's just say that there is a reason why those boards often use 10+ layers...

But how about BGAs? This is the point where I'm starting to get seriously annoyed (not least because I don't really have much experience with them yet.)  Often the ground and supply balls are placed in somewhere in middle of the chip so you really can't either route supplies from outside there nor place bypass caps next to the chip itself. Often when you find yourself having to deal with BGA, you'll need at least 4-layer board, even if said BGA is relatively tiny (I think something up to 4x4 balls might be manageable with just two layers, anything larger is really pushing it.)

Often this means in practice that capacitors must be placed on the other side of the board so that first supply is passed from supply layer cap's layer, passed through its pad and then back on the other side of board to supply ball of chip.

Not like this, mind you:

This is from a board I've had half-finished for two years now but has been pretty low in my priority list. Red balls are obviously enough BGA balls on top layer; highlighted U-shaped trace is one of the supply voltages; inside it is another supply voltage (yes, two) and in center ground. Damn this is annoying pin layout, not made any easier by the fact that large parts of other side is pretty much untouchable - can't move things around there at occupied places (just take my word for it, please.)
Mind you, this is essentially my first board with BGAs, so they are a bit of unfamiliar territory to me to begin with.

Now, two years ago when I last worked with this board I had clearly noticed that supply rails need more bypass caps. So I had added one on the other side of the board, circled with yellow. Notice how it is in middle of trace (passed through the board with that green via), but to "side" of it?

When I noticed this I just had to whack myself on the head. That capacitor is completely useless.

Now, note the another capacitor on right, marked with purple? That's newer addition. Another supply rails comes in from right (thicker red trace), goes on the other side of the board, through cap's pad and then back on this side, towards left side. Still not great placement, but way better than the other, at least it helps a bit to smooth transitions.

Note, this board uses 4 layers with blind vias so the via overlap you might  see there is actually not a problem. It however makes prototyping damn expensive - small-run boards with blind vias are expensive.

Since noticing this I've fixed the supply routing, but I'm still not happy with it. Hopefully it is sufficient - although I'm not really pushing the capabilities of this chip here so even less than perfect supply structure might be sufficient. We'll see when I get this board made.

How to buy tools

When you need - or think that you need - a tool there is always temptation to either buy the cheapest possible or the most expensive possible one. I've found out that neither of these strategies are really good, so for reference here is my rules of tool purchases - be they for work or hobbies.

1. Be absolutely sure that you need the tool.

There usually is a lot of temptation to buy some handy-looking tool when browsing through the catalog or shop shelves, but as with everything you really should be sure you'll need it before investing to it. Tool that is never used is just waste of money. Generally these days I don't buy any tools until I really need it.

2. When unsure, limit your spending.

So now you are in a situation where need a tool. A wrench set, a soldering iron, an oscilloscope, a screwdriver, a spectrum analyzer, whatever. If this is the first time needing that type/kind of tool you should not spend much, unless you have an expert at hand (not some random internet person!) who can recommend you a specific tool based on your situation.

That being said, never ever buy the cheapest one you can get, no matter how little you have available. Even tools at approximately same price range as the cheapest should be avoided. Go one price class up and pick one from there. That way you avoid the absolute worst kind of junk products (the kind that are horribly unreliable and/or unsafe) and at same time you avoid spending too much to a tool you end up using only once or twice.

3. When that breaks, go for the best.

Most of the tools you buy with rule 2 above will last you for life. Excellent!

Then there are some tools you use often enough that they break, prove unwieldy to use or just are otherwise insufficient for your needs. These are the tools that you use most and should be replaced with best quality tools you can afford without overspending. Now you also have enough experience with the tool to know what you need and what you don't, allowing you to prioritize features for your own usage.

Although I mentioned buying the best, it doesn't mean the most expensive - this means that you don't need to waste money on features you will not be needing. For example a shiny 1 GHz oscilloscope might be very tempting, but if your signals never go past 100 MHz that 1 GHz spec is just waste of money - get 200 MHz one instead.


There you have it. Three simple rules that ought to save you some hard-earned money and frustration.

The future of Shengen region

I think that the Schengen agreement is great for Europe, current refugee situation aside. For those unfamiliar with it, it essentially means completely free movement inside Schengen region (including most EU countries (but not all) and few countries that aren't part of EU). In practice this means situations like this:

This is from 2004 when we rented bikes at Seefeld, Austria and drove to Garmisch-Partenkirchen, Germany (and took train back). Fun little bike trip, although I was quite exhausted after it. Only way to know that we passed from Austria to Germany was this sign (for those now speaking German it says "Country border".)

I'd really hate to see either EU and Shengen agreement to go, but like said, at the moment there is a flood of refugees coming in which is causing lots of trouble all around Europe and making many many people less than happy about open internal borders. There of course is border control when coming inside the region, but at the moment outside borders are leaking pretty badly due to sheer volume of refugees.

The political situation is very touchy and I fear that unrest at Syria and surrounding region isn't making it any better. But I remain hopeful that things will improve yet. At the moment it is all I can do. That, and watch how some people seem to be deliberately doing whatever they can to escalate situation there even more.

Secure and confidential

Just some days ago I received an email, with contents indicating that this is Confidential message for recipient only (yes, with capital C.)  And to read the actual message I would need to click through onto a web page (which in turn is secured by SSL, according to message.)

In this case this isn't a fraud or virus, but actual message from an official agency (sorry, I'll keep the exact details a bit vague.)  Of course I verify that the link is valid (or at least looks valid enough) before clicking it, and click it, expecting to need some kind of authentication - this being a Confidential and Secure message after all.

And there is nothing.

No verification at all. No authentication. Just the message, available to anyone who'd open that link in non-encrypted email. What, exactly, is the point?

Message wasn't even that important, just confirmation about minor detail. Worst of it was, though, it wasn't even meant to me! Subject was vague enough so it could plausibly be for me, but only after reading contents I noticed that the recipient address of email wasn't mine, but it only came to me as I use catch-all email address on our domain. Whoever sent it screwed up and dropped a letter from intended address. No harm done though this time, as this was company business and not something more private.

So overall, this Secure and Confidential message wasn't really either. Good job there, boys and girls, good job. (insert slow clap here)

Now, this kind of secure messaging system seems to be becoming more common around here as banks and insurance companies seem to be using this kind of system; you'll receive only a notification of pending message with email, no details included, but at least those require you to actually authenticate before they let you (or anyone) to read the messages. So far I haven't received anything really important through these systems, just some confirmations and notifications, but on positive side they at least are more secure than this charade.

But just to mention that security-wise this (banks' system, not this failure of one I described) is correct: having no separation of important and non-important messages is a good thing. When everything is encrypted, the bad guys (be they government or private) have to spend considerably more effort to get to the good stuff. Yes, I really think everything should be encrypted and decentralized all the time (latter pretty much invalidates all current messaging services as they are way too easily compromised by single National Security Letter or equivalent.) I just hope email security (PGP and variants) would be become easy enough for absolutely everyone to use it all the time, as there really aren't any real alternatives at the moment. Of course PGP doesn't hide the infamous metadata (just the contents) but that is another issue...

Do-What-I-Mean programming

Occasionally I run onto some minor syntax annoyance with language I happen to be currently using and for a brief moment think that damnit, the compiler should be able to figure out what I mean. This time I was playing with Android and OpenGL ES 2.0, which happens to be just different enough from OpenGL 3.2 I use on desktop to make by stumbling first steps there somewhat annoying.

After few hours of trying to figure out where my simple triangle vanished I tried another version of shaders, and it fails to compile when I tried to assign a vec3 to gl_fragcolor (which is vec4). At that moment I was for a vanishing moment annoyed by compiler - it should be able to know that I don't need alpha at the moment.

Like every time in the (recent) past this thought passed immediately. No, I don't really want compiler to guess what I mean. Quite contrary, I prefer my compiler to be just about strict as possible - dot every i, cross every t kind of strict. Compiler guessing what I want is bad. Each and every time. As it will guess wrong at some point, and then the proverbial shit will hit the equally proverbial fan.

Some time ago I saw sowewhere someone (vague, huh?) saying that speech (or maybe that was handwriting) recognizing algorithms are at the moment around 90-95% accurate. That is, they get every 20th or at best every 10th word wrong. While this honestly is an excellent achievement (after all, both of those are very difficult things!), in practice this means that those aren't really usable at the moment. What good is a secretary whose work I have to proofread everything? None at all.

The same applies to compilers, but even more so. And better guess rate here is actually worse. If the compiler guesses the intent right 95% of the time it just means that my code will randomly fail approximately every 20 times (that is 20 compilations, not 20 program executions). So when you do some minor change elsewhere things suddenly break in unexpected ways as compiler ever so slightly alters its guesses. Not fun. And when compiler is 99,9% sure? Well, then the occasional hiccup will be really fun to figure out.

I once spent full day figuring out why the code suddenly stopped compiling. I had to go as far to examine full (C++) preprocessor outputs to find the reason, which turned out to be some bug in Visual Studio's preprocessor (might have been with precompiled headers, exact details escape me at the moment, as does the exact version of VS used; also, offending code was generated build-time by third-party code generator and intermediate .cpp files were not kept so this wasn't as easy as "diff two build snapshots to see what changed".)  Eventually I figured out that if some project headers were included in certain order in this one file, Visual Studio somehow dropped one (or maybe it was two, can't remember) from the build completely. "Fixing" it was simple (reorder headers) but it took a long time to get there. I imagine that figuring out compiler guessing your intent would be as fun as that specific wasted day.

On positive side, all this also means that my employment should be safe for many years to come - I don't expect artificial intelligences to be sufficiently smart to catch even close to all subtle issues in their instructions anytime soon, so real programmers will still be needed for long long time to tell computers exactly and explicitly what needs to be done.