CFL lifetime

When the ban of incandescent light bulbs came into effect, common argument against that was the lifetime if CFLs (and later, LEDs) that were to replace them were as short as incandescents, or even shorter.

It took a while (a long while), but now I got some anecdotal evidence on that argument.

We've lived in this house for over 10 years now, and we have never changed the outside lights (four of them in total). Until now. One of them had gone bad. A 11-watt CFL. The glass tube seems that have neatly broken at one point and let magic smoke out, or something to that effect. Other three identical CFLs are still going strong.

So these things have been out there for at least 10 years, in varying weather from -40 degrees C to +30 degrees C. Possibly over 20 years, even. During that time we've had some half dozen other CFLs in the house that, granted, have been used more, but so far none of them has broken.

Going back even more, I got my first larger apartment around 2003 or so. At that time I bought a light fixture to kitchen that I still have (some plastic parts have gone bad since, though). For that fixture I bought a CFL bulb that is still in use. So that would be 15 years, and that one has been used a lot during that time, considering that is has been in the kitchen, and lately, in my office kitchen/break room where it gets easily 6+ hours of use a day in winter (much less in summer, of course). I'd say that I've gotten far more "bang for a buck" out of CFLs, all in all, than ever from incandescents.

Now, that being said, CFLs have other issues, like some brightening very slowly, but lifetime certainly isn't one of their weak aspects.

Now, LEDs, so far, seem to be be falling in middle. At the moment we have maybe 10 LED bulbs around here, with maybe half being dimmable and oldest being somewhere between 5 and 8 years old (no firm anchor point on time for those like for CFL examples above, you see). So far one has failed (and I did open it and post here too, and once again semi-clever topic names bite me in the back as I can't find the post right now). Still, quite many hours of use we've gotten out of those, too.

I, for one, won't be missing incandescent lights, except maybe in color rendering purposes for photography. For that I'll keep some in spare. But I wouldn't be surprised even if that situation were to change in near future too.

Cyberpunk eyes

Everything cyberpunk has taught us is that it will make us better through implants - or augmentations, or whatever term you prefer. There is cost of course - monetary at least, and very likely social too (see: deus ex games). However..

Our visual cortex and eyes have been honed by millions of years of evolution, and even still it isn't even good, nevermind perfect - I do have to wear glasses after all. That being said, I don't really expect much more of it; after all, evolution is always looking for better overall result and not for singular results.

That makes me think.

Let's say we could replace my eyes with a perfect camera (not an option I'd pick first from a list of possible improvements, but for argument's sake) .. would my brain - or specifically, my visual cortex - keep up with it?

I think that overtime, our eyes and brain have evolved together, to offer just enough data at our focus to give sufficient resolution, but also process incoming data in most effective matter. This is the reason so many of the visual tricks work. "Focus on the jugglers .. now, did you notice the gorilla walking past?" just to name one example.

Our senses - eyes in this case - feed our brain massive amount of information, so before anything else happens, this wealth of data must be processed and filtered. Almost from birth our brain can detect movement very efficiently, as well as shapes - human faces specifically seem to take a lot of processing for identification - and some other very specific but very important things that helped our survival in the past.

If I were to feed my brain with that camera footage instead of what my natural eyes feed them, could my brain make any sense of it? I guess the answer for that would be yes - but only after long period of my brain getting used to it. That might take a long time, months or years even.

But the better question is, would that actually make me perform better? Replacing just the eyes that is. I do have a feeling that answer to this is no. The same processing would need to be applied to incoming data. I just changed the source, but processing did not change. For optimal results the brain needs an upgrade there too.

For example, some predatory birds the live in forests have essentially two visual processors. One keeps track of surroundings - essentially making sure they don't hit a trees or other such things. Other tracks their prey as they flee, to keep it from escaping. We don't have that capacity to focus on two very different (visual) things at once, although some people appear to thing they do, especially when driving.

Some frogs apparently have processing in their brain that only fires then small, round-ish item (like a bug) is moving on their vision (disclaimer: or so I've recently read from somewhere). What a perfect way to conserve energy by idling when there's nothing to do... (I think I wrote a post where I talked about this "do nothing/sleep until you need to do something" in context of MCUs but can't find it right now so no link, sorry).

So in the end, without some brain processing upgrades, upgraded eyes might not actually be that great. Granted, you could put processing in the the new eyes too, to provide a HUD or something like that to make them more useful, but even then, there is that "one focus thing only" limitation. Context switching is expensive in processors, and in our our brain, even more so (say, switch between focus points in vision.)

That eye upgrade - or at least versions 1 through 5 of them - might be quite disappointing. But even then, for someone with no (properly) functioning eyes, they still might be almost a miracle and absolutely worth the cost. I'll just wait upgraded version of eyes - and other things too -  for a bit longer, thank you.

Life of an NPC

Lately I've been way too busy to write (or even think up, really) new posts, nevermind ones that would be even close of being on-topic. So unfortunately you may need to just accept wildly off-topic posts like this.


In computer games, NPC refers to roughly "non-player character". Essentially, a character controlled by computer.

I've been playing WoW (that is, World of Warcraft) on and off for .. well, long time. After new expansion came out, I picked up again, for some time at least. And running around in Boralus harbor I saw some guards standing there in attention, and suddenly my imagination formed idea on what's going on "in their mind"...

"..So, my job is to stand here, in attention, for the length of this expansion? ..Well, could be worse, I could have been put to next hamlet over, to be eaten alive by huge monster whenever here comes to town, so once every hour or so I reckon..."


So, at this point you may be asking, I'm too busy to write not still have time for games? Well, like I said before, you need to relax in order to retain your productivity, and do know that unless I take a proper time out at some time, my productivity just plummets. So, at the moment, this is one of the ways I relax a bit when off from work.

Compiler bugs?

I've been writing code, in one form or other, for some 30 years now. And over all that time, I've found exactly two compiler bugs, and one of those is kinda grey area anyway.

First one was a C compiler for C51 processors. The bug was that when a did something like this;

int var;

void func()

{ var = var*2; }

...

var = 3;

func();

printf("var=%i\n", var);

It would print out 3. Whether this actually counts as bug (variable wasn't volatile, after all) is another issue, but this did take a few moments of head scratching to figure out.

Another one was with Microsoft Visual Studio 6 (or might been few versions newer MSVC too) or so. I don't remember the exact details here, but somehow, when #including things is a very specific order, compiler (well, pre-processor) decided to completely drop one of the included files from compilation, resulting a very, very strange error complaining about undeclared classes/namespaces/whatever (again, exact details escape me).

This one took again few hours to figure out (I had to actually make compiler to print out pre-processed intermediate output to find out what exactly happened), and just switching include order of two files (one that was dropped and another) fixed the issue.

Unfortunately, this was part of very complex project, so making simplified case of this to report the issue wasn't possibly, so I never submitted a bug report.

What am I trying to say here?

Do you suspect that error is a compiler bug? I am willing to bet that it isn't - it's your bug.

Yet, even then, I am a bit... shall we say, reluctant, to upgrade the compiler I'm using for my ARM builds. Although the possibility of finding an actual compiler bug is nearly zero, possibility of triggering some obscure bug in some part of (my!) old code because some detail somewhere changed doesn't make a fun possibility...

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.

Electric cars with space

So far all the fully electric cars have had ... well, anemic interior space. With family and two large dogs, small hatchback just doesn't cut it.

Now I found out that there is Audi e-tron coming, and judging from exterior shots, this one might actually work for me, although promised 400km range, while sufficient, isn't great - I had hoped for 600km range at this point since charging stations at the moment are unfortunately rare around here, limiting the route selection possibilities severely.

Now, will I be reserving one? Well, that's almost certain "no" at this point.

Like Tesla, this appears to be targeted towards luxury/high-end market, with gadgets, features and  power to match.

This will, very likely, make it Very Expensive Car to purchase - they are not telling the price, but I will be very surprised if it's below 80k€ around here (granted, Finland has pretty high tax for cars) for base model (whatever that means in this context).

That price is simply way too much for me. If it were, say, 50k, I could consider it. No, wait, that's almost certainly wrong, I'd almost surely buy it at that price point! That figure is, by the way, what the hybrid Outlander cost me. But anything above that I just can't really stomach. Even when the car I am looking to replace - gas-guzzling Santa Fe '03 - is starting to show its age, and not in a good way.

So guess I'm back to waiting for the tech to come down a price group or two...