Take a break. Really.

Here in Europe the "live-to-work" attitude so common at America or (eastern) Asia isn't really that widespread. For example in Finland work week is 40 hours, anything above that is overtime (and there are legal limits to that, too), and people working have up to six weeks of vacation over year, not counting official/bank holidays (like eastern, Christmas, independence day or so on.)

Some people still do work more, though, and right now I have to admit that I haven't had a real vacation this summer either. Granted, since weather has been very hot (close to 30 degrees C for several weeks straight - essentially unheard of here as one or two days, maybe one week of sequential 25+ degree days is more typical), and air conditioning isn't really widespread, it's nicer to sit in office with AC on than at home anyway.

I've been really busy working out final kinks out of our new product. This isn't first time I've made a new product either, but even then amount of work needed to finalize a product still catches me every time. All the small details, previously postponed, suddenly turn very important.

Even during this process I multitask. By necessity of course - many very different things to do (including upkeep of older products) - but I don't really mind that. It's actually good. It allows taking a bit of distance to certain things.

For example, I've had this damn annoying random crash issue with one product for some time I couldn't figure out. It just crashed, seemingly for no reason. It's been there for a long time. Previously I just gave up, deemed it to be minor enough issue that it could be postponed and went with it; the product, after all, recovered gracefully (as designed) and resumed operation after a second or two.

Spoiler alert: It turned out not to be minor at all. Constant issues, especially unexpected, seemingly unconnected ones. Crap.

However, several months of break with that code base allowed a completely new, fresh perspective on the bug hunt. So after only a few days of troubleshooting I had the answer. Interrupts within interrupts. They behaved badly in this codebase. Had always done so, but before, the module did much less, and interrupts managed to interrupt other interrupts much less often, so issues were much less frequent, almost hidden.

Few very small tweaks and problem appears to be gone. Now there is just the issue of distributing the fix, to devices that are not field-upgradeable... D'oh. But thas is beside the point I'm trying to make.

And this is something I've said before.

The fix here was the same as so many times before. And you know it too. All the week you've been banging your head onto an issue, without solution, working overtime. On weekend you go home, get wasted or whatever, return to work on Monday and the problem is obvious and fixed in no time whatsoever.

Can you see the solution here? It's time actively not working on the issue.

Take that break! Go to have a long weekend! Throw the keyboard on the wall and walk away! The problem will be there when you come back after a few days - or weeks - and by then you'll probably know the solution to it already. And that will be only by not working on it.

Your brain has this amazing capacity of background processing. Use it wisely, and you will never have to work past that magical 40 hour mark - or maybe 30 hours even - to finish your work.

Tiny drone

Some time ago I bought, mostly out of curiosity, a tiny drone from verkkokauppa.com, named RedBird Nano Cam. It wasn't too expensive, but then again, it isn't too great at flight either - fairly unstable and hard to direct even in best circumstances.

Here's the thing, without propellers (rotors?), with two euro coin to give  a bit of size reference. Although the bird on top looks quite blue to me...

It got some abuse too, in the twitchy hands of kids, so it got dropped often. So I guess it was to be expected that it would be short-lived toy. And eventually it did stop charging. Best guess, kid left it on and that killed the battery dead.

So what a curious engineer does when that happens? Yes, break out trusty tools to see what's inside...

Top cover off at this point, and I had already done some damage by not noticing four screws that  keep top and bottom covers together. D'oh. Nevertheless, the green board is the camera module, connected to main board only with only three wires. Interesting.

Camera module off, it wasn't even glued or taped down. Camera module also has place for MicroSD card it.
On the main board there are three main chips;

Invensense MPU-6050C - combined gyroscope/accelerometer module, apparently one that is very widely used. I've been considering using similar chip for one application I've been thinking about, but unfortunately I haven't found suitable gyroscope yet - for the application I'm thinking about I'd need around +/- 10000 degrees/sec operating range, but most seem to be around +/- 2000 degrees/sec range - this one included. Not even close to sufficient.

ST Micro STM32F031K4 processor.

XN297, a 2.4GHz transceiver chip.

The other side. In corners there are motor driver transistors, and in middle a clock crystal and few programming test points. All in all, quite simple thing.

I tried measuring the battery, and it read exactly zero. When trying to charge it, voltage rises to about 0,2v. It's dead, and I don't feel like trying to figure out why either (earlier speculation aside) Might as well get rid of it, except that fun-looking camera module ... I can think a few uses for it immediately.