Looking for help at the net

Gotta love Analog Devices. They make absolutely great chips, such as nice ADuM4160 USB isolator. This chip offers full isolation for USB bus, completely separating electronics on your PCB from PC controlling it and preventing that magic smoke from escaping due to serious voltage differences between the two devices, and this without having to use secondary power source on PCB (granted, in case of USB this is of a lesser deal, but for buses like RS485, not having to build isolated power supply for is a big deal - and there's chip for that too.)  But the thing is, this chip - and many others AD makes - aren't cheap. This one was around 10€ a piece in low quantities, if my memory serves. But then again, if your industrial PCB costs something hundreds of euros, taking precautions against stupid users might be worth it. That's who the main customers for this chip - and others like it - are.

That being said, I was testing this chip in case I need it one day, and found out that when using it, USB wasn't working properly. It tried to, but failed to establish connection. Hmm. Curious, as I thought I had followed documents to the letter when designing test board. And since AD hadn't bothered to even include an example schematic in their datasheets (why?!?), I fired up google image search with "ADum4160 schematic".

And oh boy, I don't envy anyone trying to get their circuit working based on those schematics. There are functional ones there, sure, but some work only in specific cases, some of them are completely wrong, and quite a few subtly wrong so that it may work - or not. Like this add-on board (that I shall not name here) that doesn't have any bypass caps for ADuM anywhere on the board. If that one works with any reliability, it'll be due to pure miracle.

Anyway, I managed to get my ADuM working eventually - small issue with supply rails that I didn't notice when initially reading datasheet, going to "specific case" mentioned above, found out by examining some schematics and then doing some very careful reading of datasheet - but damn if I had to rely on internet with things like this more often, I'd be in a real trouble.

So, go on and search the net for information. But be wary of any information supplied - it might be wrong. And yes, that includes stuff I write here, too.

Shortest camera life yet

Our old Canon point-and-click camera that we got maybe 6 years ago finally got damaged enough not to work anymore. So wife went and bought just about cheapest possible camera - specifically Nikon Coolpix A10. Price wasn't that bad either, some 85€, taxes included.

And kid dropped it on the lens which broke on the very same day. Specifically the objective/lens mechanism that moves it to storage position got stuck, most likely by breaking or jumping off the thread (rail?) or whatever.

So what are our options? Home insurance? With deductible of ~120€, that's a no go.
Return it for refund? I'm too honest for that kind of fraud.

That leaves me with option three; open it and see what could be done. But I wasn't too hopeful to begin with. Those mechanisms tend to be damn complex and in general difficult to work with, and this being plastic didn't exactly fill me with any confidence.

I can almost hear someone out there screaming about opportunity cost, but a) I just happen to be curious enough to want to see how they're build, and b) unless you actually do get paid in full for the time spent, opportunity cost is generally nothing but an excuse to avoid things you don't really want to do. Like actually saving money by cooking yourself. But I digress here once again...

Opening the camera wasn't that difficult. Some six screws and small amount of force popped front and back covers off. After looking for way to get logic board off, I peeled some tape off the boards. And next thing I found out - painfully - that camera apparently keeps the flash capacitor (330v 100uF) charged all the time. Ouch. If you open this up, be careful with it, 10k resistor is handy for discharging it. Just don't hold the resistor leads with both hands! (doubly ouch, and might do more than just hurt). Preferably hold it with no hands, like with well-insulated pliers.

After that display and it's holder came off with few screws.

The system integration is damn impressive on these things. There is a small PCB on front of camera, just for LED, and on top there is another for for buttons and flash circuits. Those are connected to each other and main logic board with solder joints, as well as the battery contacts from holder come through the main board and were soldered on. It took a while to figure this out and to pry main board off. Lead-free solder joints are damn annoying to get off sometimes, especially if there are large ground planes involved.

After getting logic board off, the lens mechanism came off as module, pretty much as I expected. 

 

There are two flexes going to the module; one for image sensor and one for motors and whatnot. No need to get sensor off, really.

This package itself was hold closed by I think five plastic clips. Four of them are easy to get to, but fifth is under the motors flex and damn small. Small, sharp and sturdy pin with small screwdriver is the best method to get it open.

Left is the cover with CCD, right is the mechanism.

And this is pretty much where I gave up. The motor (large-ish and metallic colored, on left of mechanism) seems to drive the opening mechanism, but the large wheel down there was seriously stuck. I could not find out any way to open this non-destructively so that was it.

I put it together (making sure to salvage that nice flash capacitor first), leaving everything (including battery holder) unconnected. This is kept as reminder and practice piece for the kid - no more cameras for him until he can handle them without dropping them constantly. Sure, it won't be fun to  play with as it doesn't do anything, but that's all he's going to get for now...

If I could salvage another A10 somewhere, with, say, broken screen, I might be able to build one functional camera out of them (again, more for curiosity and practice than saving money), but even that is only worth the trouble if I get the other camera for essentially free. 

Whether one should have hobby projects

Long time ago, when I was just studying and not being working, I enjoyed having my own projects to work with. Being primarily software guy, this of course was projects I could think of. Utilities, games, tools, anything like that. Lots of them, in fact. Some gained some interest, but nothing spectacular. I had plenty of time and energy for that.

Then I got work as software developer. Part-time at that point, but still. So now I am programming some four hours a day for work (plus studying, this being while I was still in university), and much of that (work) was actually learning about things around the main job as well - things like physical environments and how they affect signals, math around stuff, programming tools and concepts I hadn't encountered before and so on. Fun stuff, really. I always love to learn new stuff that interests me, and money is kinda big motivator for learning.

Then I graduated and previous part-time gig became a full-time job. And suddenly I didn't really have any energy left for my own projects any more. Will, sure, but energy, not really.

Over the years I've figured this out in more detail. Part by reading, part by experience.

It's said that programming is creative work. I absolutely agree with this, even if you are dealing with what could be called boiler plate code. There is just so much of creative effort you can squeeze out before it gets depleted. While I may not be painting Mona Lisa, or sculpting David, there still is is structure of program I'm writing that I have to keep in my head while working. Small problems are almost nothing, but big frameworks, bug structures, still existing only in my head, are fragile things. Keeping them in my mind is an effort, and a very taxing effort at that. And badly timed interruption can smash entire thing to splinters. There is a limit on how much you can keep such thing in your mind.

My personal hard limit seems to be at around five to six hours. After that there is a wall I run onto, and no matter what I do, I will not be productive software developer again until after proper rest - that is, a good night's sleep.

I can do other things though - say, assembly line type work, or anything completely different that software stuff - but then again, at my current position I am kinda lucky I have that escape route. If I were working in usual 8 to 4 office setting, there might not be anything else to do but sit there feeling useless.

Documentation, testing, all that - it's essentially same work, in different format, with different difficulty applied. I can try to do it, but in the end the quality will be sub-par. It's better I don't even try. So, five to six hours of serious work. And I am not even surprised that I don't have energy for hobby projects any more after that, not any more.

I'm not the only one, mind you. The consensus on the field seems to be that six hours per day is already pushing it.

Now, common theme in industry seems to be that one should have those hobby projects. Employers seek to people with those interests.

Now, wait a moment here - as an employer, you want that your people have energy left after work day to seek out extracurricular activities? Really, do you really want that your people you employ just waste their time - time you pay for - doing whatever, only to have enough energy for those hobby projects too?

Really?

Battery backups

Here's a pretty common scenario: You've got a low powered device with a RTC (real time clock) - be it internal to the processor or external chip. When your device is powered the clock uses external power - like mains or larger battery - and when not, either small lithium battery (coin cell type) or a super capacitor.

Typically this is achieved by having two separate VCC supply lines; one for external power which is used when available, and one for battery backup when main power is not available. 

Lithium batteries (CR1232 or something like that) are nice - lots of "slow" capacity in small package. Enough to run your clock about two to five years (depending on battery size and power consumption of your RTC). However, when it runs out it runs out, everything that was on chip (and I'm assuming that storage is RAM like it usually is) is gone, for good. If there were critical data on the RAM, it's gone. But then again, if your device has been unpowered for years, that data might not be relevant anymore. Or then again, you might have wanted to keep the data anyway.

Supercaps on the other hand have capacity for maybe a week or two, but at least they can be charged again and again. This is nice if your device is externally powered most of the time (like mains power), but if power does run out, same limitations as mentioned above apply. The time will be much shorter though - week or two, tops, with common supercap sizes.

But wait, what if you wanted to use simple, cheap capacitor? Something like 330u electrolytic caps are cheap these days. Well, sure, if your device is almost always externally powered, like, say, an alarm clock. It would be able to keep charge for maybe few hours, max, but at least it would tolerate short power outages. Unlike my current one, which isn't even cheapest one available but still loses all the settings even if power goes out for few minutes.

But dissing Sony designs aside, how do you choose your back up solution? That, of course, depends.

How long you want the data to be retained?
What happens when power eventually runs out?

There is no single answer, it's something that you'll need to weigh case by case.

Older Nintendo Pokemon games are an example of this. The save game data in the cartridge was stored in low-power RAM, backed up with large coin cell battery. Those batteries are now dying, and your precious Pokemon collection is about to vanish - unless you replace the battery (not an easy task, as cartridge must have that backup power supply enabled during entire operation!)

Personally I prefer actual nonvolatile storages, like EEPROM (or MRAM/FRAM these days). On paper they have limited life - quoted as 20 years or so - but in practice it is much longer. And they keep their data without being externally powered. Internal clock may stop after its power runs out but it is easy to set again - other data however may be worth a lot more. Like those Pokemons.
But apparently few pennies more for actual nonvolatile memory was too much for them...

I could have used SD card?!?

I have stayed away from SD cards (in my projects) because of two assumptions;
1) They require difficult and fast SD control hardware and software, and
2) They're unreliable pieces of s***.
2B) It is possible that I have heard at one point about licensing required and thus (subconsciously) didn't even bother. But I'm not sure so this doesn't really count.

Only now I found out, almost by accident, that SD cards have SPI mode. I love SPI. It's dead easy to implement even in software, allows many devices to share a bus (kinda-sorta) and is very reliable. So if I, all this time, could have just put a SD socket on board and instantly gained huge amount of nonvolatile memory... Daaaaamn.

But point 1) still kinda-sorta stands. If I would need to implement FAT filesystem (instead of treating it as raw bulk storage), that would still take some software to do. At the moment I'm kinda struggling with current product line as I'm almost out of program flash, and there is still years of development to do. Even few kilobytes more would make my life very difficult.

But if could treat it as a raw storage. Instead of "small" SO8 flash chip (of just 16 or 64Mbit or so), SD card could be put there with more space than I could ever use. For my current purposes even 2 GB card would be nearly unlimited.

Did I mention I still like to program small? I just checked - Google home page is over 200kB, excluding any pictures (like the logo). That's just a bit less than program area of the current MCU I use, and it is packed full of functionality (the MCU, that is). Data structures I transmit over web (between devices) are few hundred bytes each. HTTP headers are often larger than that! So, comparatively, essentially unlimited storage.

But then we get back to point 2). Failure mode of flash memories is notoriously bad. At least early SSDs had habit of suddenly going completely inaccessible. One moment it would work fine, no issues, the next -- nothing. You couldn't get anything out of it. 
SD cards have similar track record, although being commonly removable, exact failure is harder to track, and might often be related to less than careful handling of cards.

I've dealt with those already mentioned SO8 flash chips. They may have "just" 64Mbit of storage or so, but they often promise something like 10000 erase cycles. That number is actually something I could trust - or at least believe.

SD cards, on the other hand, often seem to like to hide that number. There is this load balancer circuit that tries to hide that stuff from view, replacing it with meaningless "real world use" numbers for marketing purposes. 

But still. Take 2 GB memory card. Write, say, 512 bytes to it, every second. Let's assume that this specific card can tolerate only 100 erase cycles. This number, by the way, is highly conservative - even cheapest of the cheap flash chips these days offer at least 1000 erase cycles.

Even then this would mean more than 10 years of usable life for the product. Assuming, of course, that the balancer doesn't lose it mind in between and destroy everything. 

It's still very, very tempting...

"Are you sure?"

Kid, now 6, loves to play Lego Batman 2 on my laptop. I even got him XBox controller to play it with. At first he needed help with some parts (some tricky jumps mostly) but it seems he has gained some skill there as he managed to completely finish the story with just small help here and there.

Then he found out that after finishing the game that you can play with any (unlocked) characters you want, anytime. Talk about excitement! I'm guessing the save he was using was nearing 70% completion or so.

Now, I deal with the problems of my clients often. Many people seem to learn technology with a method of "press this, then three times this, then this". They do not read what is on the screen, they just press the memorized-by-rote combination. And if anything they didn't expect shows up (like an error message), they way too often don't even bother reading it and instead start wildly pressing anything and everything to make the error go away.

After that they typically call me.

Take a deep breath. Count to ... well, three, as it is a phone call and I can't really delay much longer. And calmly explain them how to salvage whatever's salvageable at that point. Really, that's all I can do. And quite often, that's all that needs to be done. Next time they (hopefully) are wiser.

I'm pretty sure kid isn't like that. He seems to be - in general - remarkably resourceful when figuring out how to get whatever he wants. At the moment he doesn't read because he can't - yet at least. And I'm guessing that's why he chose "new game" and then his (70-ish percent complete) save slot.. and then even confirmed the erase of the old save...

...And proceeded to ask why there was the (unskippable) intro movie playing, again.

After I figured out and explained to him what had happened he took it relatively calmly. But he hasn't asked to play that game again afterwards either... But then again, I wouldn't be too happy to start everything over again either.

Lesson learned. Maybe. Hopefully.


 

Transmit errors

When you dig down deep enough, everything is analog. And this means certain degree of uncertainty.

I've mentioned WiFi module I'm using previously, and deep down the communication with it - via serial link - is again nothing more than stream of bytes. It's up to application to assign meaning to that with software.

And boy, is that fun. The protocol the module uses assumes that serial link is mostly immune to transmission errors - that is, that absolutely no bytes are corrupt or lost during transmission from the main processor to the module or the other way around. If a singly byte is lost, synchronization is lost and data received becomes incomprehensible. And since frame format has no checksum, single corrupt byte may render entire transmission (either single frame, or your gigabyte data within) irrelevant or at least broken until repaired.

So, while the underlying TCP/IP link (assuming that one is open at the moment) itself may be resistant to errors, suddenly the data link from the module to processor might not be (and in case of my application, it definitely isn't due to module being placed on an external module connected with cable). And this will easily lead to corrupt data being transmitted.

Fortunately I have a personal, deep distrust on data integrity of any such transmission link - be it point-to-point one inch serial link contained within a board, or wireless link over thousands of kilometres, so I have tendency to design my applications' data transfer protocols to contain rudimentary integrity checks too, in order to avoid just this kind of situation. If data is lost (to either way), connection (read: entire module, if error is persistent) is reset and application will try again.

Whether this is efficient depends on your point of view. Is it fastest way to transmit data? Absolutely not, as constant data transmits and respective acknowledgements take a lot of time, especially over slower links (protocols designed for fast but high-latency links are nice, but I don't have any at my disposal at the moment.)  But then again, I'm not transmitting blockbuster movies at 4k resolution here, but infrequent, small(ish) data packets that I want to be processed by receiver exactly once. It's up to receiver to make sure received package is handled only once.

If you happen to be modern (web) programmer, working exclusively with high-level languages, this may seem a bit excessive to you. But when you're working on lower level, with no operating system or high-level language libraries to hide all the nasty details of unreliable links beneath, these things need to be done.

And guess what? I still like it, just the way it is. It might be unreliable, but still is fun to work with.