Image deblur experiments

Quite some time ago a friend of mine took a photo, which turned out heavily motion blurred. I had just been talking about image deblurring so he sent the photo to me to see what I could do with it. I spent some time working on the photo and computed a reconstruction, which was quite good.

Figure 1. The original photo as I received it.

Figure 2. My original reconstruction from some years ago.

The original photo is shown in Figure 1, while my original reconstruction is shown in Figure 2. In Figure 1 one can see that the object appears to be an airplane. Figure 2 however reveals that the object in question is in fact an airplane toy, which is apparent from the propeller in the rear. I was genuinely surprised when I saw this in the reconstruction as I believed the photo was of a real plane and the reconstruction had actually provided new information.

My original reconstruction relied on the fact that the convolution kernel is essentially one dimensional, and it was in grayscale due to computational limitations. This time I wanted to try to reconstruct the image using a more generic approach and in color.

In the original reconstruction I used a total variation regularized deconvolution applied to each horizontal line of the image separately. This could be done because the blur happens almost exactly in the horizontal direction (in fact I rotated the photo slightly to make this even more the case). The convolution kernel was selected by analyzing the photo by eye and computing several simple Tikhonov regularized reconstructions with different kernels and choosing the one which looked the best.

This time around I wanted to use a 2D total variation regularized deconvolution using the trick of writing the problem as a constrained quadratic programming problem. Some poorly formatted maths follow:

The problem itself is

min_X 1/2 || conv(K,X) - B ||^2 + alpha sum {|X_(i+1,j)-X_(i,j)|+|X_(i,j+1)-X_(i,j)|},

where conv(K,X) is the convolution of image X with kernel K, || || denotes the 2-norm while | | denotes the absolute value. The values |X_(i+1,j)-X(i,j)| and |X(i,j+1)-X(i,j)| are the variations in the image and summing up all of them over the image is the total variation, hence the name total variation regularization. The target function is not differentiable and thus this is quite a difficult optimization problem. The trick however is to notice that this can be re-written as

min_X 1/2 || conv(K,X) - B ||^2 + alpha sum { U_k + V_k },

with the constraints that LX = U-V and U,V>=0, where L is an operator which gives the (signed) variations X_(i+1,j)-X_(i,j) and X_(i,j+1)-X_(i,j) for all i,j. U then represents the positive part of the variations of X while V represents the negative part. The total variation is then just the sum of the components of U and V.

There are multiple ways to actually find the minimizer of the latter formulation, of which I've implemented the projected Barzilai-Borwein method due to its simplicity. I enforce the equality constraint with a penalty term to keep the system positive-definite (although I'm currently working on doing this with some sort of stabilized Uzawa iteration to solve the saddle point problem one arrives at when enforcing the constraint using a Lagrange multiplier). The Hessian of the system is not only large (but not huge: about 5 million unknowns), but also dense (around 10 billion nonzeros), which makes iterative methods the only possible option. Fast Fourier transforms save the day.

As was the case with the earlier reconstruction, I again started with analyzing the photo by eye, choosing a suitable type of convolution kernel and narrowing the parameters of the kernel down. This was again done by computing several Tikhonov regularized reconstructions and choosing the one which looked the best.

Figure 3. Tikhonov regularized deconvolution with alpha = 0.001 and with the most eye-pleasing convolution kernel.

Obviously I chose the kernel type as a moving average over a straight line with the parameters being the length of the line and its angle from horizontal. The values of the parameters found to give best looking results were length = 110 pixels and angle = 0.03 radians. Figure 3 shows the result when using a standard Tikhonov regularization with regularization parameter alpha = 0.001. This computation takes 5 seconds on my 9 year old laptop.

Figure 4. Total variation regularized deconvolution with alpha = 0.0005.

The result of the total variation regularized deconvolution with regularization parameter alpha = 0.0005 is shown in Figure 4. This computation takes several hours on my laptop, but I'm expecting this to reduce by quite a lot by using more elaborate algorithms.

Figure 5. Total variation regularized deconvolution (alpha = 0.0005) using a kernel estimated from the reconstruction in Figure 4.

As the total variation regularization reduces the ghosting artifacts (which I'm guessing are due to the kernel not being quite right), I was wondering if I could use the reconstruction to give a better estimate of the convolution kernel. As the kernel is just the deconvolution of the blurred image using the sharp image, I could quickly compute the kernel using a Tikhonov regularized deconvolution. When I then re-ran the deconvolution (again alpha = 0.0005) using this new kernel estimate, I got what is shown in Figure 5, which to my eye looks like the best one yet.

Home heat pump efficacy

Our house is electrically heated, which is a bad idea in the long run. Trying to save on electricity, we got a heat pump installed in September 2014. Now that it's been running for a year, I decided to take a look at some numbers.

Our electric utility company (Helen) provides a service from which I can download my usage data for each hour. I downloaded all the data that was available and started playing around with it in Octave.

Figure 1. Electricity usage over the observed period.

Figure 2. Correlation between outside temperature and electricity usage.

My plan was to first create a model of our electricity usage pre heat pump, using the outside temperature as the explaining variable. I would then look at how large the discrepancy between our recent electricity usage is compared to that model.

Looking at the correlation between outside temperature and electricity usage in Figure 2, it seems that there is a reasonably linear relationship whenever the temperature is below 10 degrees Celsius. As I am only really interested in using the heat pump as a heating device during the winter, I will hence fit the model to cold weather data only.

Figure 3. Our electricity usage averaged over days.

Our average daily electricity usage is shown in Figure 3. Our usage increases near midnight, but there is no sudden increase even though the water heater turns on every night. This is because the heater turns on at different times on different days of the week, as controlled by the utility company. Also, since our daily routines follow a weekly pattern, it perhaps makes more sense to look at average weekly usage.

Figure 4. Our electricity usage averaged over weeks.

In Figure 4, the spikes of the water heater turning on are clearly visible. It seems that the heater turns on at around 23:00 most days, but on Wednesday and Saturday at 21:00. Also our daytime electricity usage seems to be a bit higher on weekends than weekdays. Night time usage is about the same. Makes sense.

Figure 5. A second look at the electricity usage versus temperature. This is the electricity usage in the training data smoothed using the weekly average profile.

When the weekly variation is removed from the data, we get a smoothed version of electricity usage. Figure 5 shows the smoothed electricity usage versus temperature in the training data, i.e. the cold weather data from before the heat pump was installed. It seems to have a much reduced variance compared to the original data in Figure 2 and thus seems to allow a better first order polynomial approximation.

Figure 6. Electricity usage, model fit and model prediction. Model fit is how the model reproduces the training data, while prediction is what the model predicts the usage would be.

Figure 7. Model fit error and model prediction error in kW.

Figures 6 and 7 show the first order polynomial model fit and its prediction. Figure 7 in particular shows the difference between the model output and actual data (i.e. positive values means the model estimates greater electricity usage). The model prediction error in magenta seems to be ever so slightly positive, which would translate to us using just a bit less power than before (about 6% less). I was expecting a huge difference, so this comes as quite a disappointment.

There are, however, some caveats. The weather was quite warm last winter, so there wasn't that much need for heating. Also, a big thing is that we have gone from a 2 person household to a 4 person household within the data period. This probably means increased water consumption, which in turn increases electricity use.

Lets approach the problem from a different direction. Instead of looking at how much less electricity we use now compared to a model of pre heat pump usage, we can model both cases and compare these models.

Figure 8. Pre heat pump installation and post heat pump installation electricity usage (smoothed with weekly average profile).

Figure 8 shows the smoothed electricity usage versus the outside temperature. The blue data is the same that is shown in Figure 5, but the red data is measurements from post heat pump installation. It's not very clearly visible as last winter wasn't very cold, but it seems that the post heat pump installation data has a slightly shallower slope, which would indicate that heating the house uses less power than before.

Figure 9. Model fit to pre and post heat pump installation data.

Figure 9 shows the result of fitting first order polynomials in the data. The models are

•  Pre heat pump installation
• P = 2.94 kW - 0.121 kW/C * T
• Post heat pump installation
• P = 2.70 kW - 0.092 kW/C * T,

where P is the used electric power in kW and T is the outside temperature in Celsius. That is, the electric power required for heating per degree Celsius has reduced by about 24%. This makes me feel slightly less disappointed, but it's still nowhere near what I was expecting. However, the post heat pump installation data isn't very reliable as there is still so little of it available. Hopefully I'll have better data by spring time.

Multi-turn potentiometer modification for cheap power supplies

As covered in an earlier post, I have four MC Power/MC Voice NG1620-BL power supplies. These serve me quite well, although adjusting the current limit at the low end of the scale is quite fiddly. Some time ago (a year or so) I replaced the potentiometers on one unit with multi-turn wire wound potentiometers. This simple modification completely fixed all problems with setting the output. The first time around I only ordered two potentiometers as they are quite expensive. Now I have replacement pots also for the rest of them.

Figure 1. Chinese multi-turn wire wound potentiometers.

I ordered the potentiometers off eBay. They are nominally 6.8k wire wound 10 turn potentiometers (WXD3-13-2W). Made in China, perhaps of brand Xinghuo. Based on how they look, I suspect they are recycled from old hardware. Anyway, these are the same ones I used for the first unit and I have been happy with them.

Figure 2. De-solder these.

Figure 3. Pots came off easily.

Figure 4. Close up on the old pots.

The first thing of course was to remove the original pots. The knobs just pull off, and the pots themselves are secured to the case with hex nuts. I don't have a long enough socket, so I just used pliers to loosen the nuts. An important thing to check is which way the pots are wired. Both pots in this power supply are connected in the way, in which the counter-clockwise end gives the minimal resistance. For the new pots this means that I need to connect to the terminal closest to the shaft in addition to the wiper, which is the terminal furthest away from the shaft.

Figure 5. The new pots are slightly too long to fit between the board and the front panel.

Figure 6. Board mounts unscrewed to make space to solder new pots in.

Figure 7. New holes drilled to mount the board slightly further back. New pots fit nicely.

The new pots use the same thread, so I just re-used the washers and hex nuts from the original ones. However, the new pots are slightly too long to fit nicely between the front panel and the main board. However, there is more than enough space in the enclose, so I just drilled new mounting holes for the board and moved it slightly back.

Figure 8. 0.8mm welding wire bent into U-shapes.

Figure 9. This is how the U-shaped wires attach to the pot. The knob goes over this with a drop of hot glue.

After closing everything up I still needed to put the knobs on. The shafts are different, so the old ones don't go straight on. I cut short lengths of 0.8 mm welding wire and bent them into U-shapes. This grabs the slot on the end of the shaft and slides in the knob quite tightly. A small drop of hot glue secures them in place. This sounds like a kludge, but it has held up perfectly in the one unit I modified earlier.

Figure 10. Voltage is now easy to adjust within 10 millivolts. Current is easy to adjust within 1 milliampere.

Figure 11. I have four of these power supplies. Two on the left are still unmodified, while the two on the right now have this modification.

Weather display update

My wall mounted Ferrograph Aurora 63 is now displaying weather data.

Figure 1. The sign displaying weather icons.

Figure 2. The sign displaying temperatures.

The weather data is obtained through the Finnish Meteorological Institute's open data service. The format is a bit on the convoluted side, when compared with for instance what is provided by openweathermap.org. However, openweathermap.org data seemed quite a bit off for my area, so FMI data is much more reliable.

Currently only temperature and a general weather symbol is shown (current symbols are clear, partly cloudy, overcast, light rain, moderate rain and heavy rain). These displays alternate every couple of seconds. I'll probably add precipitation intensity and wind data as well. Also I'll need to draw more weather symbols.

See the display in action on YouTube.

FPV with Hubsan H107L - fail!

I got a Hubsan H107L quadcopter (or a clone thereof) from a friend. I've been flying it quite extensively lately, and thought it would be cool to try some FPV on the thing.

I tested the carrying capability of the thing by attaching some self adhesive wheel balance weights on its bottom. Turns out it can only lift about 15 grams, so any video gear needs to be really light.

I ordered the smallest cheapest camera I could find on eBay as well as the smallest video transmitter. Although the copter is controlled over 2.4GHz and the small video transmitters are also 2.4GHz I decided to give it a try anyway.

Figure 1. The small camera straight off from eBay.

According to the data sheet, the video transmitter board operates from 3.3V to 5V, so operation from the single LiPo cell of the quadcopter is possible. The camera however was specified for operation from 9 to 12 V. Opening the camera revealed a single low dropout linear regulator providing 3.3V to everything important (only the bias voltage for the small electret microphone was fed from the supply voltage). The dropout voltage of the regulator was around 0.5V, so power could still be supplied from a single cell as long as it wasn't too empty (also the camera remained operational long after the regulator dropped out of regulation). As a side note, the specified 9V is probably too high for the camera. As it draws about 200mA of current, the regulator needs to dissipate about 1 watt of power. That is quite a lot for a SOT-23-6 package.

By coincidence the video transmitter is exactly the same size and shape as the camera board, so both of them fit inside the camera housing. It was then just a matter of connecting the boards to each other and wiring the power. The whole set-up weighs just 10 grams.

Figure 2. Camera and transmitter boards connected. Yellow loose wire is the antenna, while red and black are the power leads.

Figure 3. Camera and transmitter boards fitted in the camera housing. A small hole was drilled for the antenna wire.

Unfortunately, with the high power video transmitter so close to the quadcopter receiver, the control range is reduced to just 2 meters. Switching the video transmitter channel doesn't affect the range, so the high power is probably just saturating the receiver. Complete failure in that respect. You can't win them all. Perhaps I'll find some use for this neat little camera later.

Ferrograph Aurora 63 LED sign wall mount

So my wife OK'd the wall installation of my Ferrograph Aurora 63. The idea was to have it over the entryway door showing the weather forecast. This makes it easier to choose appropriate clothes when dressing the kids. The Bluetooth modification of my Ferrograph Aurora 63, covered earlier in this blog, was the first step in this project.

Figure 1. The display showing a message on my work bench.

The wall mount I built is just a 1100x200 mm wooden shelf attached to the wall with three brackets. The display hangs from the shelf with 4 M3 screws. The heads of the screws are captive in the mounting slot on the top of the display. I first attached the shelf to the wall and then slid the display onto the hanging M3 screws. After everything was fixed, I drilled a hole through the wall for the power cable.

Figure 2. The screws can move in the mounting slot of the display so that the display can be slid from side to side.

Of course not everything went quite to plan. The screw holes for two of the brackets originally hit some concrete inside the wall, and while I could have drilled the holes with my hammer drill, I opted to move the brackets instead. This of course left some slightly ugly extra holes in both the shelf as well as the wall. I'll probably fix these later, as I still have to take the display down to paint it white. Also the shelf is a quarter of a degree crooked, which is visible as it is so close to the ceiling.

Figure 3. Close up on the power cable junction (I'll install a junction box for this) and the extra holes in the shelf and the wall.

Figure 4. This is how it looks like.

Anyway, I declare this a success. Now to write some code to have it display useful stuff.

RC car build and trouble with motor driving

Sometime in the early 90s I bought a Taiyo Fast Traxx Pick-up RC car. The special thing about it was, that instead of wheels it had two rubber tracks. It served me well, until one day about 20 years ago the electronics crapped out. I never threw it out in hopes of repairing the electronics some day.
Turns out the electronics were basically all custom parts, or at least with custom markings. I didn't want to start figuring all that out, so I decided to build new electronics from scratch. Basically I just needed two H-bridge motor controllers and a radio receiver.

The motors were running quite poorly after all the years in storage, so I cleaned them by running them in a bath of CRC 5-56. It turned out that the motor had quite low armature resistance (around 0.5 ohms), i.e. they would pull huge currents if stalled (in the order of 20 amperes from the original 9.6V supply). This was surprising as the original controller was just on-off and to handle the stall current the switching device would have needed to have a very low on state resistance.

As the only H-bridge drivers I had in my junk box were L298s, I decided to use one of those. I planned to limit the current to acceptable levels just by limiting the pulse width of the enable signal. Also, the L298 has high saturation voltage in the switching transistors, which also helps to limit the current.

For the receiver, I wanted to use one of my "receiver v3" boards. Those were designed to drive standard servo motors at 50Hz frequency and between 1 and 2 milliseconds pulse widths. This application would need much higher frequency and also higher duty cycles. Due to the way the receiver board was designed, the duty cycle would always be limited to at most 50% when driving two channels, but that was enough for this application and wasn't a problem. The frequency could also be increased easily to 1kHz.

After building everything on a proto board I did the first test. The motors didn't turn. The L298 just couldn't drive the motors. The IC just got really hot even with a large piece of aluminum acting as a heat sink. So back to the drawing board it was...

Figure 1. L298 based dual H-bridge driver, which was a complete failure. Receiver is not in the picture, but it would mount upside down in the black female pin headers.

I decided to go simple with the build. Just a single N channel MOSFET switching the current and perhaps to do the reverse later using a relay. I had some FDD16AN08A0 FETs laying around in my parts bin and wanted to use those, but 3.3V gate-source voltage isn't enough for those. The highest current capability FETs I had that could be driven with 3.3V were CEG8205. They are TSSOP-8 packaged, which makes them really awkward to use on a proto board, so I didn't go with that and instead used two Si2302s in parallel.

First test with the motors goes well, when powered from my lab supply. The motors turn, but not very fast as the lab supply doesn't provide much current. Happy with the way everything is working, I test it out with a battery. Now the motors are running much faster and the whole thing seems like a winner. Then, all of a sudden, flames and smoke. I quickly disconnect the battery. The transistors have gone up in smoke (this incident also took out the processor, the radio module and the 3.3V regulator on the receiver board). I find this odd, as the two Si2302s in parallel were supposed to be able to handle 5A of current.

Figure 2. Burn marks on the phenolic board after the transistors caught fire.

I went back to the CEG8205s, so I bodged them on some SO-8 to DIP breakout boards I had, and soldered those on the proto board. With both channels in parallel they should be good to 9A. Testing on the lab supply again, I slowly turn up the power on the controller and the motors start slowly turning. Then suddenly one of the FETs starts to smoke. It took some time for me to understand how a 2A limited power supply was able to destroy a 9A rated MOSFET, but I think what happened was that when the current limit of the power supply kicked in, the output voltage dropped suddenly. This in turn reduced the gate-source drive voltage of the FET, which then wasn't enough to achieve a low channel resistance. The 2A current through the channel was then enough to destroy it. After this incident, I increased the brownout threshold of the processor to 2.7V, which should still be high enough for an acceptable channel resistance.

After all this and more (for instance playing around with the drive frequency and measuring waveforms), I still couldn't get the thing to work. It would work for a while and then a FET would die. I then got fed up and added a 74HC04 to level shift the drive waveform to 5V and switched to the much larger FDD16AN08A0 FETs. Even still, the FETs would get so hot that the solder would start to melt! I couldn't believe it. This is when I realized that although the average current through the channel was limited to 2A by the power supply, the maximum current could be much higher. This could result in a much higher average power dissipated in the device than what would be inferred from the average current. I was working under the assumption that the motor had significant inductance, and due to it the current would remain approximately constant (or at least not shoot to insane values) during the switching period. I had experimented with rising the switching frequency up to 8kHz, but didn't have any luck with that, so the inductance had to be really small (in fact my poor man's LCR meter measured it at less than 10uH).

I found some high current 100uH inductors in my parts bin and put those in series with the motors and everything just started to work! Motors run faster, FETs run cool. I even tested with the L298 driver board I first made and it is now capable of getting the motors running (however they give too little torque and don't run very fast, so I still can't use that).

Figure 3. The RC car assembly with FPV gear.

Figure 4. Close up on the quality of workmanship. I didn't bother redoing the board after replacing the CEG8205s with the FDD16AN08A0s. I just bodged them onto the breakout boards.

Figure 5. Close up on the 100uH load inductors. Secured down with hot glue.

Bluetooth modification for Ferrograph Aurora 63

Some time ago I got a Ferrograph Aurora 63 LED display. Its a 16x135 matrix of dual color (red/green) LEDs. It has the custom XDF firmware installed, which allows it to be controlled using the well documented Alpha Sign protocol. The commands are given to the display through either RS422 or RS232.

Figure 1. The panel displaying a message on my work bench.

As RS232 serial ports are quite rare today, I decided to modify the display to use Bluetooth instead. The display uses a MAX232 level shifter for the RS232 communication. That is, to shift the levels between the higher voltage RS232 levels and the TTL compatible logic levels which the processor of the display (Z180) uses. My idea was to make a Bluetooth module, which would act as a drop-in replacement for the MAX232 chip.

I have some HC-05 Bluetooth serial adapters on breakout boards (ZS-040) from eBay, which I planned to use for this project. These modules use 3.3V CMOS logic levels. The output from one of these can be directly fed into the TTL compatible input of the Z180 and it will function properly. However, the input pin on the Bluetooth adapter is not 5V tolerant, and the output from the Z180 would damage it. I used a simple resistor divider (12kohm:22kohm) to bring the voltage down from 5V to 3.3V.

Figure 2. The resulting module. I used horrible phenolic paper prototype board.

Figure 3. Module installed in place of the MAX232 chip. It is difficult to open the thing up for a better photo, sorry.

I was worried that the aluminum chassis of the display would block the radio signals, but this thing works all the way from the other side of the house. Now to just mount it on the wall and write some software to display useful information on it :-).

Update 2020/05/17

Some people have asked for the schematic for my MAX232 replacing module. I didn't publish it here originally, as I didn't have one. The thing was just improvised at the time. I've since drawn the schematic, so here it is.

Lab power supply repair

I have four Mc voice/Mc power NG1620-BL power supply units. These are the absolute cheapest lab supplies I've found with adjustable voltage and current (I bought mine from thiecom.de). They are not very high power with their 0-15 V and 0-2 A range, but they fit most of my needs. Also, as they are floating supplies I connect them up in series and parallel when needed.

Left running for several days, one morning I noticed one of them showed 9V on the meter when it should have been around 5V. First I suspected a meter fault, but I confirmed that the output voltage was indeed 9V. Good thing the device it was powering had its own regulator, so the supply didn't take anything with it. I've had the main filter capacitor fail in one of the other units, so I suspected it had gone bad in this one too. I replaced it, but the problem persisted.

The unit supplies 9V even when the voltage is adjusted all the way down. If the current limit is increased, the voltage increases also, independent of the voltage pot. Voltage rises to over 20V if the current limit is adjusted all the way up. There doesn't seem to be any obvious sign of damage anywhere, so I need to check things more carefully.

I couldn't find a schematic online so I decided to trace it out myself. I might not really need one for this fix, but I've wanted to have the schematic even before anything got broken. I first took photos of the top and bottom side of the PCB and then planned to superimpose them into the same image to see both the components and their connections. Luckily the PCB is one sided, as this helps a lot while tracing the circuit.

Figure 1. Top side of the PCB.

Figure 2. Bottom side of the PCB.

Figure 3. Top side image overlaid on the bottom side image.

The overlay turned out quite good. I didn't go out of my way to align everything. I just corrected for the perspective of the board in the photos and scaled the resulting images to the same size, and placed them on top of each other (of course mirroring the bottom side image). This was done using GIMP.

The board isn't the best construction quality, though it could be much worse. The soldering quality is quite good apart from some of the components having quite long leads (the burnt flux residue is from replacing the filter cap as I didn't clean the board before I took the photos). My main problem with the unit is however the dubious mains insulation. They have shrink wrap tube around the connections, but it has been applied sloppily and the connections are exposed in many places. The main chassis is properly earth grounded, but I'm not confident that the cover shell makes good contact as the parts are painted. Furthermore, the chassis has ventilation holes, which could easily pass a loose wire end inside in a messy workbench environment... I'll need to do something about this.

Figure 4. Raw traced schematic.

Figure 4 shows the schematic I traced out. I might still arrange it in a better way and re-draw this in Eagle. An important notice is that GND and the positive output terminal T+ are connected. The main electronics power supply thus always follows the output voltage and produces +12 and V- around that rail. The negative output terminal is basically what gets controlled.

The main voltage loop seems to be run by the LM741 (N1) and current limit is done using a single channel from the LM324 (N2). One extra channel from the LM324 is used to switch the secondary winding for the main power stage. Two channels of the LM324 (N2) are unconnected. There is something weird connected to the offset compensation pins of the LM741 (N1). Perhaps that motivates the use of an additional opamp instead of just using one extra channel from the LM324 (N2).

Before any probing around, I insulated all exposed mains wiring with hot glue. After that I started by checking the reference voltage, which was spot on. Then I checked the +12V rail, which again was spot on. Checking the V- rail I saw 25Vpp oscillation at mains frequency. This rail drives two shunt regulators to provide the negative voltages to the opamps, and is thus quite heavily loaded (not because of the opamps that is, but because of shunt regulation). My first guess was that the filter capacitor of that line (C2) might have gone bad. After removing the capacitor, a quick check with my multimeter revealed a significant loss of capacitance. I replaced the capacitor with a similar spec one, though with slightly larger physical size. Power on, and the device had come back to life.

Checking the failed capacitor with my ESR meter I got 6000 nF of capacitance and 18 ohms series resistance. That is significant. I also replaced the two other identical capacitors in the circuit (C1 and C3), although they both read fine on the meter (oddly enough, they were even better than the ones I used to replace them).

I probably wouldn't have needed the schematic for this, but having it at hand really allowed me to search for problems systematically and by publishing it here there is the remote possibility that others might find it useful as well.

Bootloading over radio

I currently have 9 wireless temperature and humidity sensors around the house for testing purposes. If I need to update their software, I collect them and do the update with an ISP programmer and then put each back to their proper place. This is annoying, but still quite doable. However, I'll soon have around 20 sensors around the house, and some in the crawlspace and other hard to reach places. I thus started to think more about the logistics of deploying a software update.

Over the air software updates are the proper solution to the problem. The microcontroller I'm using has a dedicated bootloader section at the end of flash, to which the reset vector can be pointed at, as well as a facility to move the interrupt vectors there also. The plan is to have the bootloader send a packet to the receiver notifying it of the type of reset that has occurred, as well as battery voltage, application program version number and whether the CRC of the application area is valid. This is the command mode. The receiver will then respond by commanding the execution of the application program, by commanding the reprogramming of the application memory or by some other commands such as device address programming.

If the execution of the application program is requested, the bootloader restores the microcontroller to a state similar to that after a reset condition, and jumps to the original reset vector of 0.

Reprogramming the application memory is done page by page, where each page is 128 bytes. The bootloader requests a chunk of data indexed by the page and chunk indexes. When all chunks of a page have been received, the page is erased and programmed. When the entire application program area has been programmed, the bootloader returns back to the command mode.

I'm still somewhat unsure what to do with the possible changes in radio configuration (frequency, bitrate, bandwidth, modulation and so on). One possible solution is to store the radio configuration in EEPROM so that both the application program and bootloader can use the same settings. However, the bootloader needs to store a separate failsafe configuration if the configuration in EEPROM is incorrect.

There also needs to be a facility in the application program to get execution back to the bootloader. Here lies the biggest pitfall. If the application program misbehaves, it might be impossible to return to the bootloader without physically accessing the device. Proper testing should thus be done before submitting an update to devices in hard to reach places.

Wireless temperature and humidity sensors

Our house has a crawlspace which has had some humidity problems in the past. Instead of crawling in there to check every spring and fall, I wanted to place instruments there which would do the monitoring year round. Looking online, all the available devices were either much too expensive or do not really meet my requirements (they had dubious calibration, poor battery life and so on). Partly due to this reason I started developing my own sensors. I had played around with the idea of home automation before, so this seemed like as good a starting point as any other function. Some part of me also thought that I might make a few bucks in the process, but this is yet to happen.

I wanted the devices to be small, cheap and have a long battery life. So that one could just scatter them around the house and basically forget about them. I had played around with low power electronics as well as radio communication before, so I kinda knew what I was doing. I decided on using an Atmel Atmega328P for the CPU and a Silicon Labs Si4432 as the radio IC as I had previous experience with both and knew that both of them are very low power devices with broad voltage ranges (1.8V - 3.6V for the Si4432). Also, instead of playing with all the passives required for the operation of Si4432 on the 433MHz band, I used a complete module called the XL4432 available on both eBay and AliExpress from several vendors. The big question, however, was what to use as sensors.

Figure 1. AM2302 (DHT22) on the left and DHT11 on the right.

Initially I had thought of using either Aosong AM2302 or DHT11 digital temperature and humidity sensors. As these require greater than 3 volt power supplies, and I needed to be able to run down to 2 volts, I needed to power them through a charge pump voltage doubler, which proved successful. While prototyping however it became obvious that these sensors could not be used, as they drew a lot of current at power-on. They could not be left constantly on either, as although the quiescent current was much lower that startup current, it was still far too great for a battery powered device with any significant battery life (say greater than 5 years).

Figure 2. First revision of wireless sensor boards. These use the Aosong HR202L (white box seen in the leftmost and rightmost images) humidity sensor as well as an NTC thermistor (reddish glass bead seen in the middle image).

The second idea was to use an Aosong HR202L passive resistive humidity sensor and a precision NTC thermistor. The resistances of the sensors were measured against reference resistors using the on chip ADC of the microcontroller. This idea proved successful in prototyping and I ordered a batch of PCBs from dirtypcbs.com. The total parts cost ended up around 6 euros per board, which wasn't too bad. I built 9 boards, which have now been measuring around the house for more than half a year. I wasn't completely satisfied with the calibration of the sensors though. They are still reasonably correct, with an error of around 1 degree Celsius in temperature and maybe slightly worse than 5 percent points in relative humidity. Of course they could be further calibrated manually, but that is a hassle I don't want to go through.

Figure 3. Second revision of the wireless sensor boards at different levels of assembly. These use the Sensirion SHT20 (marked as U2 on the lower right board) as the temperature and humidity sensor.

The third iteration uses a Sensirion SHT20 digital sensor, which has a respectable typical sleep mode current of 150 nA. This model is the low accuracy model in the line, but it is still accurate enough for me with a typical temperature error of less than 0.5 Celsius and typical relative humidity error of less than 3 percentage points. I ordered once again a batch of boards and have so far built 4 of them, which are still undergoing development and testing. So far I'm very happy with this change. SHT20 is slightly more expensive than the old solution, but the total parts cost is still only around 7 euros. I'll have my batch of 10 wireless sensors soon assembled.