Bad air

At some point I noticed that my office air was getting bad, especially in late afternoon. As this building is somewhat old, and doesn't have good air exchange now that old fireplace isn't used anymore this wasn't very surprising. How bad it was though was a bit more unknown.

I managed to get my hands on a carbon dioxide sensor for some time and was surprised to see co2 levels reaching nearly 2000 ppm during afternoons. No wonder I was getting really tired towards end of days. So I got some improvements made (added intake vents, and wind-powered vacuum at top of old chimney) to improve situation. After this I did notice improvement, but at that time didn't have tools to find out how much the situation really improved.

This was close to a year ago. Out of curiosity I now got a few sensors that should be able to determine this. Specifically, Sensiron SCD30 carbon dioxide sensor and SGX Sensortech MiCS-VZ-89TE air quality sensor.

MiCS measures VOC levels (Volatile Organic Compounds, measured in ppb or parts per billion) by using semiconductor sensor. Datasheet doesn't exactly tell how that is done, but in many similar sensors (as far as I know) this involves hot plate (very tiny one, but nevertheless) on which chemicals and compounds react and change the resistance of this plate which in turn can be measured. This technology isn't very specific, but to put it bluntly, is is still useful to detect many kinds of, well, volatile compounds (most, if not all of which can be considered to be less than healthy to breath in.)  Although datasheet mentions co2, it doesn't really directly measure it and instead gives "co2 equivalent" reading mostly based on VOC reading. Many times these correlate, but not always. But even then, the good side is that these sensors give out a relative reading of air quality and are relatively cheap to be embedded in many consumer-level goods. Think of your phone signalling you that "yeah, you might want to get out of here" when you enter area with less than great air. That at least is target for many of these sensors.

SCD30 on the other hand uses nondispersive infrared sensor (NDIR) to measure actual carbon dioxide level in air, and pretty much nothing else (although I guess some gases/chemicals with similar absorption characteristics as co2 might somewhat affect the reading.)  So this doesn't detect nasty solvents, cigarette smoke or other such things that might be in air. These sensors tend to be a bit more expensive too so they're not that often seen in consumer equipment.

I left these sensors running for some time, below being graph from one day period (noon-ish to noon-ish next day). Sensors actually had been running much longer at this point but I managed to screw up logging (several times, actually) so previous data was lost. Ah well.

Here the co2 level measured by SCD30  is on blue. The level drops when I leave office, eventually falling to current outside air levels (400ppm), and on next day starts to rise immediately when I come in, despite improved air circulation. At least it no longer gets anywhere close to previous 2000ppm levels, instead maxing out at 1200ppm. Not great, but much better than previously.

Red graph shows "equivalent co2" as measured by MiCS. At start of graph it follows SCD30 results relatively closely (not bad!), but veers wildly off at start of next day for some reason. Huge spike you can see in that and VOC reading are because I put small amount of denatured alcohol on tissue and left it near the sensor, to which it reacted immediately. Note that actual (blue) co2 levels weren't changed; only now there was volatile compounds in air that this sensor detected, resulting severe degradation in reported air quality.

I now hope I didn't damage the sensor by leaving alcohol too close to it. Hot plate sensors shouldn't be that sensitive (we're talking about table spoon's worth of alcohol total here) but who knows how this one reacts. Its behavior at end of graph doesn't look too good though. I need to follow its behavior some more to see how it behaves now.

A part of Finnish history

Recently a map where cities of more than 500 people were placed on world map. Terminology aside, I was of course first checking out how Finland looks on this map.

Entire map here

And here is cropped Finland where I very very quickly copy pasted rough current country borders on top of it. Borders are skewed, badly placed and very likely of incorrect size but they are close enough to illustrate my point:

I noticed that for some reason, there is interesting clear divide inside the country, southwestern part of having cities (towns, whatever term you prefer) quite densely, and northeastern part of being very sparse. Hmm. Curious, wonder if there is an historical reason..

Although I was almost certain already, I did quick googling found this article, listing historical borders of Finland. Historically (granted, part of following is my opinion) Finland has been either wild frontier, part of Sweden on west or Novgorod (later Russia) on east, often having been divided up by these two powers. Frontier part being areas, inside or outside these countries allocated borders where their respective governments couldn't or wouldn't reach. Although due to climate, this frontier never was anything like later western frontier of USA, more like wilderness where people could just vanish to live their own life without having to bother with tax collectors, army recruiters and other nuisances of foreign government.

But I digress here. As I remembered, the density border I imagined in above picture matches very closely border agreed by Sweden and Novgorod in 1323, 'Pähkinäsaaren rauha' (as it is known in Finland, Treaty of Nöteborg more internationally). This border stayed in place for next centuries, and changed next time only in 1595 and then 1617.

While I am not familiar on how Sweden and Russia treated this land over this time, I can, based on above map make a guess where Sweden encouraged people moving out and forming communities, while Novgorod .. didn't, and as a result of this one historical border, the entire northeastern part of Finland still remains mostly empty land.

Maybe pointless, but I found this interesting nevertheless.

Car charger (bigger one)

If you are planning on owning an PHEV (plug-in hybrid electric vehicle) or full EV (electric vehicle), you would be absolutely insane to even think of using public charger network, as they're very expensive compared to electricity price you're normally paying. This with some notable exceptions,like Teslas with free supercharger usage.

This is with mainly Finnish focus, but might apply elsewhere too. The electric grid is primarily 3-phase, nominal 230v. Typically normal single-family home receives all three phases, each phase with single "top-level" fuse, typically 25 amps, and within the home all three phases are distributed in a way that this current is not exceeded in any single phase. So for example washing machine and drier, each that can use 16 amps, are placed in different phases.

At home you wouldn't likely be using high-power charger, but instead 2.2 (10-amp) or 3.6kW (16-amp) charger. But there's a problem there: you don't want to overload the main fuses with new high load, so careful planning will be needed.

You can of course switch to larger main fuses (like 3x32A or even higher), but that will increase the electric bill even if you don't use the increased capacity so you don't typically want to go there.

In my case I wanted to install 3.6kW charger, so I had to calculate very carefully how the current wiring in the house goes and what is the expected maximum load of each phase. Fortunately fuse box is very well marked, so it was easy to calculate loads involved in each phase.

As it turned out, stove, sauna and washing/drying machines were the main loads. Phases 2 and 3 were essentially topped out (couldn't use drier when charging the car - not great), but with some care phase 1 could be utilized without too much worry of an overload - especially if charging is timed to happen mostly at nights when other usage is low, so when we got charger installed, I timed car to charge only between 22-07 hours.

Figuring these things out is a bit of an headache, but needs to be done to get things working. And at this point I'm just too fond of electric driving, I wouldn't want to go back to archaic combustion engines.

Car charger

Some companies have been distributing these simple car power adapters - takes 12v in from car cigarette lighter and puts out 5v at whatever current. As they're often freely available at trade fairs, I've ended up with few.

Currently I have a specific one at hand, which appears to be distributed by a norwegian company, and promises 5v @ 700mA. And of course it, after some time of use, doesn't work anymore. Not too surprising, really, I expect these things to be really cheaply made.

After opening it up, I found pretty much what I expected. Simple buck converter, using a chip labeled AD85063. Well, at least this one is kinda honest - this chip is rated max 700mA. There appears to be quite a few of similar adapters that promise something like 2 amps, using this same chip.

The bad part; there appears to be no real protection on the chip, and no real current limit anywhere on the circuit. USB data pins are shorted, so devices can pull high currents, damaging the chip in process. And, apparently, based on few posts I've found, the failure mode of this chip isn't very pretty - it'll short the input to the output after which there's plenty of +12v coming in the USB. This can happen with buck converter if chopper transistor shorts out, which seems to be all too common failure mode. Hope the protections in phone are up to their job.

Now, I have few of similar converters around here, looking almost same but this one is with 2 ports and higher output current rating (total over 3 amps). Now I'm kinda curious to open it and see what's inside...

Certificate of Authentic Windows

Some time, around mid '00s I was assigned to handle licensing of Windows operating system for embedded devices manufactured by a company, as the person who previously handled this had left the company. The paperwork wasn't too bad (which was kinda surprising) and licensing conditions weren't too bad to read either - maybe around 10-16 pages (I don't remember exactly), and not written in too bad legalese. In other words, much easier read than common EULAs (End User License Agreement) even then - and I'd guess EULAs have gotten worse over time.

Obviously I read it through like the proverbial devil reads equally proverbial bible. There were few things that needed a bit more attention and clarifications but in general it was all well. All conditions were met so we could just install the OS, attach Certificate of Authenticity (CoA) to device and it's done. It was also very explicitly said in that agreement that 'CoA' means the license number sticker. Essentially same small holographic sticker with 25-character license code just about every windows computer has.
  
CoA is supposed to be the final authority on whether computer has valid windows license or not. As a home user one might not care too much, but I've heard stories where BSA (Business Software Alliance, who are essentially hired goons of major software publishers. Legal goons, although I am tempted to say that they are just barely on that side of the line.) has refused to accept these stickers as proof that business' Windows installation is legal - that is, Authentic. Despite Microsoft's own licensing terms saying exactly opposite here.

Granted, I have only dealt with embedded licensing, and only relatively briefly, so things might have changed before I took that job and likely also after I left. License types might be different too. But situation where license provided says that CoA is just that - Certificate of Authenticity - and hired goons can just say that it's not - well, I can't but feel a bit uncomfortable here. Although my neck is at the moment quite safely out from that noose.

PHEV vs EV

 
As previously mentioned, I got PHEV Mitsubishi Outlander last year. It has 12kWh battery and best I've gotten out of it is around 40 km, 35 being more typical, even in optimal weather. So let's say 40km to be optimistic, which puts its consumption to around 0.3 kWh/km range. And this is in summer - in winter the figure is much worse, down to 20km (0.6 kWh/km!) with heating on, or even full zero km when it's cold enough (around -25 degrees C, if I remember correctly - at that point it just doesn't use the battery any more.)  Effectively, to get anywhere with electric power, it has to be charged every night.

Not great figures, those. Not at all. So I was somewhat doubtful with full EVs. As it turns out, if you do things right, the figures are completely different.

I got Hyundai Kona Electric just few weeks ago now, and so far I've put around 800km to it (including one 300km one-day business trip, with no charging on the way). At the moment it's still early spring, so temperature hovers around 0 degrees C now, so best figure I've gotten out of this car is about 380km. The car has 64kWh battery, so this works out to about 0.16 kWh/km figure. Almost half of the Outlander's figure! And this is with heating and everything running.

And just to clarify this, right now (temperature being around 0 C) the reported range of each car, with full battery, is as follows:

	Range	Consumption
Outlander, heating on	25 km	0.480 kWh/km
Outlander, heating off	38 km	0.315 kWh/km
Kona, heating on	380 km	0.168 kWh/km
Kona, heating off	400 km	0.160 kWh/km

Aerodynamics certainly has some effect on these figures, although I can't say how big the effect is. Weigh shouldn't make that much difference, as they're near enough (around 1700kg for Kona vs 1800kg, if I remember right - battery in Kona is heavy.)  4-wheel drive of Outlander might have some effect too.

I guess the most surprising part with Kona is that the heating has so little effect to range. It apparently has system (heat pump?) that can use the waste heat from power electronics to heat the cabin, which is pretty nice in cold climates. How well it works when it's really cold is a question that has to wait until next winter though.

The primary difference, as far as I can see, is that Outlander is designed as gasoline-powered car first, and PHEV part is almost an afterthought, and thus there are too many compromises in design, each nibbling a bit away from the efficiency of the whole system, and end result is disappointingly mediocre. It's not horribly bad, but when comparing these two, the inefficiency is obvious. I can't help but wonder how the system would work if it were designed as electric first, but just with small battery and small gasoline engine put in some corner to function purely as a generator when needed.
Not to say that Kona is designed as electric first (as there are gasoline powered Konas available), but I am certain that requirements of EV have played significant role in design.

There's also battery life I'm kinda concerned about. With my current driving, I charge Kona once a week, or once in two weeks. Hyundai gives pretty amazing battery warranty of 8 years (or 200 000 km), and unless something goes horribly wrong, so I don't see issues there. Except possibly long wait for battery replacement, if things are as I fear they are.
Outlander, however, needs to be charged daily. As battery life typically is primarily set by charge cycles, this daily charging requirements is kinda bothering me. And of course Mitsubishi doesn't have as generous warranty as Hyundai either.

Now, a question many might ask: How does the Kona EV work as a car?

In short, I like it. Long range makes it perfectly fine for normal weekday driving, and since I find that I only need to charge it on weekends, longer charging period isn't really an issue either. My main gripe is that it's small. There's no way we could go for a weekend trip as whole family, dogs and all, without having some serious space issues (roof rack excluded; I don't like them, but I might have to reconsider). But if I go to business trip alone, or with just one or two persons with me, it would easily carry me, although longer recharge times between 300-400km of driving will change pacing of such trips in future.

So for now, when packing heavy, Outlander is the car of choice, simply due to its size. But I will be seriously considering switching immediately when similarly-sized all-electric vehicles become available - at reasonable price, of course.

Updating device remotely

Let's say you have a small-ish embedded device that communicates with remote server via network connection. It would be nice to update its software remotely, but since it is, well, remote, you generally want that the such updates are as fool-proof as possible. As in, no change (or very marginal one) of bricking the device.

This obviously means that the updates can't be done over active connection. Any issue with said connection might cause your update to be interrupted, causing it to fail and leaving system in unpredictable and likely corrupt state.
Solution for this is to load the software fully to local storage and to verify it against known checksums before starting the update, to make sure that everything is received properly.

Also, you generally do not want to software to perform full self-updates. If software is one monolithic block, any failure during update will easily leave it in corrupt state.
For this, the software must actually be in two parts; first is the bootloader, which in perfect world is immutable and never touched outside device production. And the second part is the main application software that can do everything but to actually perform the update (including downloading and initial verification of it).

The update process, then, is something like this:

• Main application contacts server and receives a notification of update
• Main application downloads update to local, nonvolatile storage reserved specifically for updates.
• Main application verifies that the update is valid, uncorrupt and optionally properly authenticated
• Main application sets nonvolatile system state to "perform update" mode, and starts system again
• Bootloader, on startup, checks system state and notices that update should be done, causing it to branch to update, instead of starting main application as would be normal operation
• Optionally bootloader verifies the update data again, to make sure everything is proper
• Bootloader then loads update data from nonvolatile memory and replaces main application data with the updated version. 
• If this process is interrupted (power loss for example), system is still in update mode and can resume update.
• After update is done, bootloader verifies it once again, and when satisfied that everything is correct, updates system state to normal operating mode and starts main application.

Depending on how far you want to go to make sure everything keeps rolling no matter what, there may also be two copies of software, so you can go back to old version in case new version somehow doesn't work. There is also possibility of encrypting the software when it is in transit, so that only the bootloader can decrypt it during update, to retain secrecy of your code.

Now, if you ever wanted to update the bootloader... Well, it can be done with this setup, too, but generally you don't want to do that, as failure there may be unrecoverable, or at best, difficult to recover from. Generally speaking, though, you want to avoid this as much as possible.

You may notice that I haven't written a word on how to actually implement this stuff. That's right. Every single system is slightly different here, so there isn't single solution for this, and without knowing your exact setup I can't really give any ideas. Other than ones provided above.