How (not) to run online business

Communication, communication, communication. This is one of the most important lessons every business, especially web business should learn and understand early.

If you get a query about your product, answer it immediately. Even sending immediately "No idea, but I'll find out" is far better than just answering with information week or two later. And no response at all is worst possible option. If the customer doesn't hear from you in a day or two, he'll move on - to your competitor. You've lost him for good.

If you get an order, send order confirmation immediately. It doesn't matter if the product is in stock and you can deliver it immediately, send the damn confirmation about it. Even if you receive order on phone, although on phone confirmation is often explicit anyway, and implicit. I've taken up habit of ending the conversation always with quick listing of what was ordered and note that I'll be shipping the goods immediately or early next week or whatever the schedule happens to be.

Customer wants to know that they will be receiving what they ordered, and when. Preferably you'll want to use delivery method with tracking information so both customer and you can see what is happening, but for small deliveries this may be too expensive.

If the item ordered isn't in stock, send order confirmation anyway - with estimated delivery date included. "Estimated to ship in two weeks", then new notification  when items are shipped (and possibly in between too, "we didn't forget your order, it's due next week." You may want to use different wording there though.)

And if you can't deliver as earlier predicted, send a note about it anyway with new schedule. Yes, you may be trying customer's patience with delays, but at least you are telling them what's happening. Offering alternative products at that point is fine also, but consistently offering just more expensive items for immediate shipping may feel like you are trying to rip off customer.

This isn't rocket science, people. Just learn to communicate, or people will take their business elsewhere!

And here I am, writing this while wondering if I ever get any response from a few shops I requested information about some (less common) screws about a week ago...

On pulse forgery

It's been a while and I've been playing with pulse forgery problem (think of cabs with meters that seem to measure a bit too much cost) lately. Or more correctly, with the detection of forgery.

I wrote about this a bit, way back when I first started posting my random thoughts here, but since then some ideas have been clarified.

The easiest way of course was to cross-reference the pulse data with external source, like GPS. This of course requires GPS to practically be built-in, so it's a bit expensive, and in some regions might be a bit of a problem due to frequent loss of GPS signal (high buildings, tunnels, underground garages and whatnot)

But let's say you only have the pulse to work with. Most of the methods available work with the statistical parameters of the pulse; mainly duty cycle and period and changes in those. It's winter now, and while now it's not exceptionally slippery (at time of writing this it's -30C outside, and when it gets past (below) -5C or so slipperiness isn't as bad as close to zero) still in some cases wheels might lose their grip and spin momentarily wildly, like when trying to get moving from stop uphill, or trying to accelerate at on-ramp of highway. It wouldn't be nice if meter detected such events as tampering.

But ignoring that for a while, period (or frequency) change is simple one. In typical driving it shouldn't change too fast, and at least not constantly. So sudden large change there is pretty much a red flag. Measuring that is also a bit tricky. Some cars generate about 27000 pulses per kilometre, or 27 pulses per metre. At speed of mere 100km/h that translates already to 750 pulses per second - you'll need a fairly high precision timer if you want to measure those periods in detail! (and then there is software latency too, if you can't use hardware for this for some reason)

Duty cycle is also fun one - large change in duty cycle is another red flag. But unfortunately that is even greater problem as now your timing precision must be several orders of magnitude larger than with period alone. In some cars duty cycle can also vary based on speed so it can also cause false positives if that isn't considered.

At the moment I'm considering pulse period monitoring (most likely both overall frequency monitoring as well as monitoring pulse period discrepancies between sequential pulses) as more likely candidate. We'll see what happens when I get the test software I've been playing with on my desk to my car for more practical testing.

Thermal camera hack

Some time ago I got Flir E4 camera. I was aware of the hack that could upgrade its resolution (link/discussion on eevblog here, a bit more detailed instructions here) but for some time I didn't bother. Until now.

Apparently the upgrade needs 32-bit operating system, XP or Windows 7. This was a bit of a problem as none of my main machines have 32-bit systems anymore. Fortunately I still have one 15-year old test machine running XP (yes, it's unconnected and reallly slow but does its job for now) so I could try this out.

Also, newer cameras apparently come with newer (2.8.0) firmware on which the hack does not work. Mine fortunately still had older 2.3.0 version.

Just installing the tools needed for the hack to this ancient machine took several hours, but eventually I got everything done. And the change is astonishing.

Low-resolution dog.

High-resolution dog.

It might be difficult to see but dog got five years younger too! ...Jokes aside, photos were taken year apart in different places and the dog isn't the same - the other dog wasn't very photogenic at the moment, sleeping with legs up, so I chose other one to pose on high-res pic. And I used different color spectrum too, d'oh.

So how about some PCB shots?

Hot, failing PCB, low res.

STM32 Discovery board, high res.

Again, pictures taken almost a year apart and of different board, but change should be fairly clear nevertheless. I really should've upgraded sooner...

I also really like the multispectral system this camera uses; it takes heat picture and adds emboss-like details from normal camera on top of that to allow details to be seem better. Taking picture too close adds some offset on that, though, and you can see the effect on both pictures.

Hyundai key fob

When I bought my old(ish) Hyundai the remote lock was completely non-functional. I expected it to be nothing but synchronization issue (car and the fob can lose synchronization and thus become non-functional; if this is possible, your car's manual should describe how you can to synchronize them again) so I kept my mouth shut at that point and accepted marginally lower buying price.

Sometimes you win, and then you lose. Assholes at the shop had used pressure washer to clean the engine - something that in my opinion should never, ever be done, for any reason. Unfortunately they did and water (unsurprisingly) got in a place where it shouldn't be - block heater connector.

For those unfamiliar with these devices, a block heater is simple electric heater that is used to warm up engine (typically its cooling water, although newer aluminium engine blocks require less efficient methods) which is used at high latitudes to, well, warm the engine slightly before turning it on. When it's -30 degrees outside this will definitely make the engine wear less and start easier. So when it got cold (few months after I bought the car) I plugged it in - and shortly saw smoke coming out from the engine compartment. Connector of the heater had melted and shorted itself. D'oh. And of course dealership refused to accept any responsibility. Nothing I could do, can't prove they were guilty of reckless washing. So that cost me about 150€ to fix.

But once again I got carried away on marginally related topic, back to the key.

Like I expected, synchronization fixed the remote locking, but the range was pretty bad - few meters. That was fixed with a new key fob battery and all was good for some time again.

Until now, when it started working only occasionally. I had to press buttons multiple times to unlock (or lock) the car, and eventually lock button stopped working completely (indicated by LED no longer flashing at all when pressing it)

So, open the key fob again to see if I could find out what's wrong. Inside was this PCB (minus leads you can see at bottom.) To me it seems that the fob (and very likely its counterpart in the car) are both manufactured by Omron and Hyundai just bought them as-is, with maybe some tweaking at the car end. Not really unexpected.

On the other side are just the battery connectors. Chip was marked with Omron, and I didn't bother with the code - I expect it to be a custom chip for remote entry application, so finding any useful documentation is very unlikely anyway.

I am not exactly sure what the green gunk on the buttons is. The board was not conformally coated (which is a bit curious, now that I think of it) so that shouldn't be it. The plastic enclosure had seen some abuse so it might just be some crap that got in, but the color is off in that case.

First I tested the buttons with multimeter, no problem there. Nothing obviously wrong in the solder joints either (buttons or elsewhere), although some joints did look a bit suspicious (buttons especially; compare joints on them to, say, other components around them). It is possible that someone else had attempted repairs earlier and button joints are result of that.

Further testing was somewhat difficult without somehow powering this up, so I soldered wires to suitable places on board and started probing it oscilloscope. And what do you know, there was actual solder joint issue there - buttons worked (LED flashed) when I was probing the chip leads and pressed button.

So, at least in this case the solution was simple enough. Resolder all pin legs and fob works again. On a quick glance I couldn't see any issues at other components so I chose not to re-do all the joints. One fixed key fob - at least for now.

Not a fan of wind power

Let's get one thing clear at the start: I'm absolutely certain that global CO2 emissions absolutely must be reduced dramatically.

Many people who agree with that seem to unconditionally love renewables - especially solar and wind. I don't. Here is the reason:

This graph is directly from fingrid (company that runs national energy grid) page, accessible to anyone here. To be more specific, this lists wind power generation over last four months in Finland. Note I didn't say estimated there - these are mostly based on real figures delivered to them by producers. There is some error there (not all production apparently is reported properly) but in general the numbers are close enough to be trusted.

Let's compare it to power consumption and generation numbers, as seen below.

Red graph is consumption, black is national production. There is lot of short-time variance; this is because consumption on days is always about 1GW more than on night. Steady rise is because of transition from summer to winter - heating houses consumes a lot of power.

Then note that there is constant 2 GW difference; there just isn't enough domestic electricity production to meet demand. So we must constantly import energy from neighboring countries (mostly from Sweden, but some from Norway and Russia too). To make things worse, wind power is also disrupting reserve power plants - they're being completely shut down due to insanely high guaranteed price given to wind power producers. 

Also note how the difference dramatically grows towards end. Let's take a closer look there.

Upper graph; red is consumption, black production. Lower graph yellow is wind power generation.

I'm writing this on noon of january 7th and it's -30C outside, just like it was yesterday. People often claim that wind power works also when it's freezing outside. Well, doesn't look like it to me, consumption is way up from last week and there's practically no wind power generation. (now, before someone complains: the claim might be true somewhere and/or sometime, but every single cold period here (granted, not that many so far) I've looked up has looked similar to this)

Or in numbers: From the new year's eve, 31.12., the production has dropped to about one fifth (from about 580MW (my estimation) to about 100MW). At the same time (peak) consumption as gone up by almost 2000MW. Yeah, I'll take just about anything before I'd rely on wind power as main form of energy production. For each windmill you'd need another equally powerful plant as backup! Talk about insane ways to generate power...

Due to high latitude solar here is equally insane option. Sure, it generates a lot in summers, when the consumption at its minimum, but in winter there's practically no production as sun just barely rises over the horizon (or doesn't at all, like up north).

Hydro in Finland is pretty much at max already, every river where there is potential is already used, so there isn't any way to increase that either.

There's a lot of talk about energy storage as buffer to help with the fluctuations of generation, but until you can show me cheap, reliable and safe (you have seen pictures of phone batteries bursting? Now imagine same, only with a battery thousand times of the capacity and so heavy you can't just toss it outside to burn...) storage method, I'll take a few more nuclear plants, thank you.

WiFi modules and control software

I've been playing with BlueGiga WF121 WLAN module lately. Not the cheapest module you could get, but then again, it has TCP/IP stack built-in (so you don't have to have an OS or write that yourself) and more importantly all necessary legal certifications and approvals so using it is way safer (in legal sense) than some random cheap module - unless you want to spend some serious money on having your device tested and approved yourself.

The serial interface of the module is pretty nice, but unfortunately not completely asynchronous. Some operations (like TCP/IP connect) pretty much require that you wait for response before doing anything else which pretty much ruins entire idea of having non-blocking, asynchronous system - something I've worked pretty hard to accomplish (on simple MCU without operating system so no threads or tasks to make things easier)

Note that above I said response. The command interface of this module is written so that module sends response almost immediately - most of the time just in tens of milliseconds or so, and later (possibly much, much later) comes an event - connected successfully or failed. I'm not writing a hard real-time system here so I could block - that is, wait for the response - which in turn contains necessary information (in this case id to newly created connection) to handle the event later, but still, I've worked pretty damn hard to write new system to be as non-blocking as possible so I don't like that idea (slippery slope and all - I waited there a bit so might as well wait here too...). Especially I hate the case where response is corrupt or doesn't arrive, which might cause a long (too long) blocking period.

Other way to handle this would be to create another abstraction layer in the application that would take care of this, but I don't like the idea either. A lot of code to do so very little, especially since I typically have only "background" and "foreground" operations going on. Foreground being ones that user sees, and background operations are allowed to have high latency so they can typically wait.

So I decided to build system so that these few operations that are dangerous cause other similar commands to fail while they are being processed. If failed operation was background operation, that's fine - system will retry the operation later. If it was foreground operation the system can retry a few times (transparently to user, aside just a bit longer wait), then notify about it if problem persists (retry / cancel?). Problem averted.

I hope. All this is mostly theoretical at this point, as I haven't tested anything on actual board yet (only on evaluation kit connected to PC - I've written the connection layer so that exactly same code is used both PC and embedded), but most of the above (especially failures and how they could be/should be handled) can be said to be well-informed guesses, based on what I've learned in past on building similar systems.

Once again, practical experience takes all the fun out from writing code as you have to think issues like these - or more to the point, can't avoid thinking issues like these before you even have anything built.