OpenEnergyMonitor

Welcome to the Thursday Toolkit series, about tools for building Physical Computing projects.

(this is again a bit of a side excursion, about checking the quality of a measuring instrument)

I recently visited a friend who had to get his frequency meter’s calibration verified to a fairly high precision. Thinking of the Rubidium clock I got from eBay, he came up with the idea of using a transfer standard.

The thing with accuracy, is that you have to have an absolute reference to compare against. One option is to go to a “calibration lab” and have them test, adjust, and certify that your instrument has a certain accuracy. Awkward, expensive, and usually a bit over the top for “simple” hobby uses.

So the other way to do things, is to “transfer” the calibration in some way. Buy or build a device which can keep the desired property stable, calibrate it to some standard, move it to where the instrument needing calibration is located, and compare the two. Or vice versa: match to instrument, then compare with a standard.

The latter is exactly what we ended up doing. First we created a little Arduino daughter board with a “VC-TCXO” on it: that’s a “Temperature Compensated Xtal Oscillator” which can be fine-tuned through a voltage. Here’s the setup, created and built by Rohan Judd:

On the left, an SPI-controlled digital potmeter, on the right a VC-TCXO running at 10 MHz.

Via a sketch, the VC-TCXO was fine-tuned to produce exactly 10.000,000 MHz readout on the frequency counter we wanted to verify. This was done at about 18°C, but a quick test showed that this VC-TCXO was indeed accurately keeping its frequency, even when cooled down by more than 10°C.

I took this device back home with me, and set up my frequency generator to use the Rubidium clock as reference. So now I had two devices on my workbench at JeeLabs, both claiming to run at 10 MHz …

Evidently, they are bound to differ to some degree – the question was simply: by how much?

Remember Lissajous? By hooking up both signals to the oscilloscope, you can compare them in X-Y mode:

Channel 1 (yellow) is the VC-TCXO signal, some sort of odd square wave – I didn’t pay any attention to proper HF wiring. Channel 2 (blue) is the sine wave generated by the frequency generator.

The resulting image is a bit messy, but the key is that when both frequencies match up exactly, then that image will stay the same. If they differ, then it will appear to rotate in 3D. It’s very easy to observe.

The last trick needed to make this work is simply to adjust the frequency generator until the image does indeed stop rotating. This is extra-ordinarily sensitive – the hard part is actually first finding the approximate setting!

After a bit of searching and tweaking, and after having let everything warm up for over an hour, I got this:

IOW, the frequency I transferred back to JeeLabs with me was 9.999,999,963 MHz. We’re done!

To put it all into perspective: that highlighted digit is 0.1 ppb (billion!). So the frequency counter appears to be 3.7 ppb slow. Assuming that the transfer standard did not lose accuracy during the trip, and that my Rubidium clock is 100% accurate. Which it isn’t of course, but since its frequency is based on atomic resonance properties, I’m pretty confident that it’s indeed accurate to more than 0.1 ppb.

The real story here, though, is that such breath-taking accuracy is now within reach of any hobbyist!

I had some space left on the TinySensor v1.0 PCB, plus I left myself few days to think before ordering the first batch, so I decided to throw in a SD card port. I didn’t want it to be anything fancy like the impossible to solder SMT card slots, so I decided to go for a quite rough but easy solution based on Getto SD card slot idea, also used by Nathan Chantrell in his SD shield project:

Nathan has put up a simple schematic for the SD card pin layout:

So the idea is to use either straight or right angle pins on the PCB and solder the SD card adapter to the PCB, then insert an micro SD card in it.

Here is the modified PCB:

 

The SD card can be Chip Selected via PA2 or PA7 pin, select-able by a jumper.  Basically it is a SPI interface, so any 3.3V SPI device can be hooked, not just a SD card.

 

Some first results from trying to run a JeeNode off a 24 x 32 mm indoor solar cell…

In each of the cases described below, I’m using a JeeNode without regulator and with 100 µF cap hooked up, with fuses and settings as described in this post. The cap should have enough energy to cushion the dip from a small packet transmission. I’m using the latest radioBlip2 sketch, which now sends out the following 7-byte payload:

The benefit of this version, is that the sketch reports not just the battery level but also how far the battery level drops after sending out a packet once a minute. That value is sent out in the next packet, so it always lags.

To get started, I connect the JeeNode to a BUB, which charges the 100 µF cap to 5V (and runs the RFM12B slightly above spec). Then I disconnect and hook it up to the solar setup. This way I don’t have to deal with startup problems yet – which is an entirely different (and tricky) problem.

Yesterday’s elaborate setup didn’t get very far, unfortunately. Two different runs gave me just a few packets:

L 09:16:01.571 usb-A600dVPp OK 17 1 0 0 0 1 209 0 L 09:18:07.445 usb-A600dVPp OK 17 3 0 0 0 1 86 51 L 09:19:10.308 usb-A600dVPp OK 17 4 0 0 0 1 86 50 L 09:24:12.477 usb-A600dVPp OK 17 1 0 0 0 1 206 0 L 09:25:15.707 usb-A600dVPp OK 17 2 0 0 0 1 86 210

Values are 20 mV steps, offset by 1V – the actual battery voltage is: 1 + 0.02 * X (where X is the reported value).

In the above runs, the battery is 86 (2.72V) before sending, and 50 (2.00V) after. That’s pretty close to the edge, I’m not sure why the drop is so large.

Another test with a 0.47 Farad supercap, charged for about 3 days to get the charge “deep” into the supercap, seems to fare a little better:

L 09:43:06.943 usb-A600dVPp OK 17 19 0 0 0 1 210 52 L 09:44:10.771 usb-A600dVPp OK 17 20 0 0 0 1 175 210 L 09:45:14.549 usb-A600dVPp OK 17 21 0 0 0 1 175 146 L 09:46:18.339 usb-A600dVPp OK 17 22 0 0 0 1 175 147 L 09:47:22.100 usb-A600dVPp OK 17 23 0 0 0 1 175 147 ...

That’s 4.50V and 3.94V before and after transmission, respectively. But a 0.47F supercap has a lot less energy in it than that 3.4 mAh Lithium cell used in the first tests above, so it’ll probably run down a lot faster.

After one hour, voltages drop to 4.28V and 3.72V. Two hours: 4.14V and 3.60V. Five hours: 3.92V and 3.36V. I’m not sure this will work, unless the node sends less at night perhaps or always restarts reliably the next day.

To be continued…

I have one of the cheap DX digital thermometers laying around with the thermistor removed and used in another project. So I got an idea to try: use the LCD screen for visualizing data.

The unit is driven by a thermistor: a variable resistor that changes its resistance in relation to the temperature. So, I thought the easiest way to simulate variable resistor is by using a photocoupler. I have a Sharp PC817 that I could use for the purpose. The idea is simple: PWM the LED in the photocoupler to vary the resistance on the output side. here is my test setup:

I also added a yellow LED to visually see the PWM-ing. On the software side, I wrote a small program to PWM the PC817 and visualize the PWM value on the serial output. I’d then write down the PWM value and LCD readout to try to get some sense out of it.

 

/* Fade This example shows how to fade an LED on pin 9 using the analogWrite() function. This example code is in the public domain. */ int led = 9; // the pin that the LED is attached to int brightness = 0; // how bright the LED is int fadeAmount = 5; // how many points to fade the LED by // the setup routine runs once when you press reset: void setup() { // declare pin 9 to be an output: Serial.begin(9600); pinMode(led, OUTPUT); } // the loop routine runs over and over again forever: void loop() { // set the brightness of pin 9: analogWrite(led, brightness); // change the brightness for next time through the loop: brightness = brightness + fadeAmount; // reverse the direction of the fading at the ends of the fade: if (brightness == 0 || brightness == 255) { fadeAmount = -fadeAmount ; } // wait for 30 milliseconds to see the dimming effect delay(10000); Serial.println(brightness); }

 

So running the program I was the LCD change values from -42 to +28.5 (strange, it should go higer, but II think it is due to the 220ohm current limiting resistor I had on the Yellow LED)

I recorded the reading in Excel, so that I can then PWM the value to get certain LCD screen reading.

One way to use it, is to create a lookup table, and find the closest WM value for the desired LCD output. I also tried to find a function based on the output values using this neat tool for working out nonlinear regressions, the result was Y= 21.03584781* LN(X) – 90.53971398

I tested, but it is not so accurate, so I prefer the look up table option.

I also have a DS1803 digital potentiometer that I tested, it is a 0-100K dual channel variable resistor controlled over I2C and the readings were much more accurate, at the cost of more complicated hardware and software setup.

As a conclusion, it was an interesting test of little practical value other than displaying lets say temperature data for cheap.

I hope the idea helps someone  :)

 

I have been working this weekend on improved version of the ATTiny84 remote sensor, this time I will use a PCB fab house to make at least 15 pcs of the PCB. The improvements over the old hand-made PCB are:

• CR2032 coin cell battery slot
• One Jeelabs compatible port for compatibility with Jeelab plugs. I am most interested in attaching I2C devices to that port
• One Analog voltage divider for various analog measurement purposes connected to a 2.5mm audio jack. The voltage divider is entirely made with through-hole parts and may be configured as per the needs. The primary intention is to use it for current sensing, but any configuration is possible, including soldering wire jumpers if necessary
• One port intended for DS18B20 temperature bus
• The one-wire bus, the Jeelabs port and the analog input can be powered from PB0 digital port only when necessary. The analog port can be either powered from 3.3V all the time of only when setting PB0 to high; the setting is configurable through a jumper
• The PCB is designed to fit a small plastic box sized 37x57mm

 

Eagle schematic and board files for the Tiny_Sensor_v1

I will be ordering the PCBs the next few days, I always wait a bit after I think I am ready so that I can react to new ideas.

Comments are welcome.

 

Time for another experiment, this time combining my small solar panel with the 3.4 mAh Lithium battery which seems to work so well. The circuit I’m going to try is as follows:

Here’s the construction, cozily attached to the back of the solar cell:

Same solar cell, I think it can supply up to 4.5V @ 1 mA in full sunlight.

The tricky bit is that the rechargable lithium cell needs to be treated with care. For maximum life, it needs to be hooked up to a voltage source between 2.8V and 3.2V, and the charge current has to be limited.

Note that the 1 kΩ resistor is put in series with the battery not only to charge it, but also when taking charge out of it. Seems odd, but that’s the way the datasheet and examples show it. Then again, with a 10 µA current draw the voltage drop and losses are only about 10 mV. A diode bypass could be added later, if necessary.

The diode after the regulator has the nice effect of dropping the 3.3V output to an appropriate value, as well as blocking all reverse current flow. There is no further circuitry for the regulator, since I don’t really care what it does when there is too much or too little power coming from the solar cell. Let’s assume it’s stable without caps.

It all looks a bit wasteful, i.e. linearly regulating the incoming voltage straight down to 3.3V regardless of PV output levels and discarding the excess. But given that this little 3V @ 3.4 mAH battery has already supported a few days of running time when fully charged, maybe it’s still ok.

I’ll let this charge for a day or two.

With all this tinkering with solar panels, little batteries, supercaps, etc, you often need to prevent current from leaking away. The usual approach is to insert a diode into the circuit.

Diodes conduct current in one direction and block the current in the opposite direction.

Well, that’s the theory anaway. In real life, diodes only conduct current once the voltage is above a certain level, and they tend to leak minute amounts of current when blocking the reverse voltage.

For ultra-low power use and the low voltage levels involved, you need to be careful about the type of diode used. A regular 1N4148 silicon diode has a forward drop of about 0.65V, quite a bit when supplies are 2..3V!

The Schottky diode has a much lower voltage drop. It’s usually specified as 0.3..0.4V, but it really depends on the amount of current passed through it.

To see the properties of the BAT43 Schottky diode I’ve been using, I created this simple test setup:

A 10 Hz “sawtooth” voltage is used to create a signal rising from -3V to +3V in a linear fashion, 10 times a second. This means that the current through the 100 kΩ resistor will go from -30 µA to +30 µA. We can then watch the voltage over the diode, and how it goes from a blocking to a conducting state:

The yellow trace is the sawtooth signal applied to the circuit. The blue trace is the voltage over the diode. Note the difference in vertical scale.

You can see that with negative voltages, the diode just blocks. As it should. With positive voltages up to 1.2V, i.e. a current up to 12 µA, the voltage drop over the diode is under 0.15V, rising slowly to about 0.175V at 30 µA.

Changing the resistor to 10 kΩ to increase the current by a factor of 10, we get this:

Same picture, different scale. At 300 µA, the voltage drop is now about 0.23V, and it’s fairly flat at that point.

For comparison, here’s a run-off-the-mill 1N4148 “standard” silicon diode:

Again: different vertical scale. About 0.53V at 300 µA. More importantly, it’s already 0.4V at 60 µA.

So when losses matter at low voltages and low currents, it’s better to use Schottky diodes.

With the SD card bootloader ready, I thought I need a mechanism to be able to download firmware from the Internet and save it to the SD card, so that upon the next reset, the Arduino is re-flashed with the newly downloaded sketch. So, I created a basic sketch that does that, it looks up a file called “app.bin” from my site (DNS resolved) and downloads it to the SD card. It is a compiled Arduino sketch that is converted to .bin format with a command like that:

avr-objcopy -I elf32-avr -O binary ledfade9.cpp.elf app.bin

As a to-do remains that I figure a neat way to reset the Arduino after the sketch is downloaded so that the flashing takes place immediately. I lean toward using the hardware watchdog reset, but I need to check the implications on the bootloader as well. Until then, a “dirty” hack maybe used to jump directly to the bootloader address, but this is not elegant solution:

cli(); asm volatile("jmp 0x7000");

Note that it is a 4KB bootloader, so hence the 0×7000 address

So the possible use of this sketch is to include it in the “setup” section of the code, so that it check for new firmware over the Internet and re-flashes itself. Combined with the SD bootloader’s capability to use file name of your choice via EEPROM string, it makes a nice add-on.

My code is available on github

The tri-colour LED's on the emonGLCD V1.3 are connected the the hardware digital PWM lines on the Atmega328. This allows the brightness to be smoothly controlled in 0-255 steps.

Up-until now we have not made use of this feature.

The video below shows a demo of Solar PV generation and power consumption ramping up and down. The tri-colour LEDs smoothly increase in intensity green or red depending on the amount of power being imported or exported.

This should serve as a nice at-a-glance visual indicator to how much power is being imported or exported at any given time. At the moment the example has been configured so that the LED's are at their brightest when 4kW's are being exported or imported. In the future it would be great if the display learnt what size PV system (kWp) is installed.




It would be possible to implement a similar feature on the Home Energy Monitor display to indicate the level of power being consumed, but this will have to be done carefully not to annoy the user! The problem with this is what constitutes a high level of consumption? To be useful the display needs to 'learn' what's high and what normal level of consumption.

Thanks to Rob Walker and the discussion on this thread for help in implementing this. Rob has also implemented proportional control of the white LED backlight level based on the light level in the room measured by the on-board LDR..nice!

All these changes and some other minor improvements have been committed to the emonGLCD github repository: https://github.com/openenergymonitor/EmonGLCD. Please test and report feedback on the forums.

Thanks for your thoughts John. It's a very good point regarding the density, I didn't consider that. Your guess at the density difference was very good, after a quick google it seems Al is 2.6 times denser than ABS. I will add a note to the post that the figures are for KWh/Kg. This would skew things in favour of plastic. Although a quick search on Farnell for two similar cases one in ABS and the other in Al shows that the Al case is only 10g more than the ABS one. This weight is only the weight Farnell indicate for their shipping, maybe it's not very accurate:
Al 130g: http://uk.farnell.com/camden-boss/31150001/box-aluminium-130x82x27mm/dp/1620909
ABS 120g : http://uk.farnell.com/boss-enclosures/33133001/box-abs-grey-145x95x25mm/dp/1620902

We had in mind extruded aluminium box shape with custom laser cut plastic/ply end plates such as: http://www.lincolnbinns.com/images/e-case-a.jpg. This PCB would be inserted by sliding in on the rails, no electronic contact would be made with the Al. The laser cut end plates will allow us to easily customise the port cut-outs. This sort of enclosure is commonly used for electronic devices: http://www.lincolnbinns.com/gallery.htm

Your right, it would ultimately be good to compare the embodied energy in the whole device to the potential savings, although this would be very hard to do in practice!

Now that there’s low-power vccRead() code to measure the current power supply voltage, we can finally get a bit more valuable info from the radioBlip sketch, which sends out one packet per minute.

So here’s a new radioBlip2 sketch which combines both functions. To support more test nodes, I’m adding a byte to the payload for a unique node ID, as well as a byte with the measured voltage level:

As a quick test I used a JeeNode without regulator, running off an electrolytic 1000 µF cap, charged to 5V via a USB BUB, and then disconnected (this is running the RFM12B module beyond its 3.8V max specs, BTW):

Here’s a dump of the received packets:

L 16:56:32.032 usb-A600dVPp OK 17 1 0 0 0 1 209 L 16:57:35.859 usb-A600dVPp OK 17 2 0 0 0 1 181 L 16:58:39.543 usb-A600dVPp OK 17 3 0 0 0 1 155 L 16:59:43.029 usb-A600dVPp OK 17 4 0 0 0 1 134 L 17:00:46.323 usb-A600dVPp OK 17 5 0 0 0 1 115 L 17:01:49.431 usb-A600dVPp OK 17 6 0 0 0 1 98 L 17:02:52.314 usb-A600dVPp OK 17 7 0 0 0 1 82 L 17:03:55.016 usb-A600dVPp OK 17 8 0 0 0 1 66 L 17:04:57.526 usb-A600dVPp OK 17 9 0 0 0 1 50

Or, more graphically, as voltage – showing 8 minutes before the sketch runs out of juice:

This consumes only marginally more power than without the VCC measurements: the original radioBlip sketch lasted 1 minute longer under similar conditions, i.e. one extra packet transmission.

Its always hard to get realistic figures but important to try to get to the bottom of it. Nice to try to go in the right direction.
A few thoughts:
I guess (but dont know) that sheet aluminium is far better than individual die-cast boxed.
Did you compare volume-volume? I guess density of Al is 3x that of plastic? Al could be considerably thinner.
Very few items are boxed in Aluminium.
Is extra material required to ensure electrical insulation?
What is the embodied energy as percetage of any possible savings due to monitoring?
I guess that screening (advantage or disadvantage) is a major factor?

Just some rambling thoughts.

A local forum guy asked me to help him setup a system that logs his solar hot water tank and few other temperatures. The thing is he wasn’t sure how many temperature sensors he’d use and wanted to expand as he needs to, but he isn’t familiar with Arduino programming. So, I decided to put up a small sketch that would utilize the Sensing Shield ontop an Arduino Ethernet, and the end product should be pretty much plug-and-play. If more sensors (DS18B20) were attached to the one-wire bus, they would be discovered and their readings sent to Pachube (now known as cosm.com).

So here is the result, a test sensor is connected to the OneWire port:

His particular need is to track temperatures only, so no other components were soldered.

Another requirement was to use Pachube.com for logging, since it is free and reliable. However, the in-built graphs didn’t offer overlaying the temperatures (the new version http://cosm.com seems to have better approach) and I googled a solution for overlaying three temperature readings on a chart:

The code for the chart is quite simple:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title>Pachube Viz - Preview</title> </head> <body style="font-family: Arial;border: 0 none;"> <b>This is a preview of your embedded code:</b><br /><br /> <script type="text/javascript" src="http://www.google.com/jsapi"></script> <script language="JavaScript" src="http://apps.pachube.com/google_viz/viz_multi.js"></script> <script language="JavaScript">createViz([57665,57665,57665],[1,3,4],800,400,["ff0000","0000ff","00ff00"]);</script> </body> </html>

The Arduino sketch is available on github

As shown in this post, it is possible to read out the approximate level of VCC by comparing the internal 1.1 V bandgap with the current VCC level.

But since this is about tracking battery voltage on an ultra-low power node, I wanted to tinker with it a bit further, to use as little energy as possible when making that actual supply voltage measurement. Here’s an improved bandgap sketch which adds a couple of low-power techniques:

First thing to note is that the ADC is now run in noise-canceling-reducing mode, i.e. a special sleep mode which turns off part of the chip to let the ADC work more accurately. With as nice side-effect that it also saves power.

The other change was to drop the 250 µs busy waiting, and use 4 ADC measurements to get a stable result.

The main delay was replaced by a call to loseSomeTime() of course – the JeeLib way of powering down.

Lastly, I changed the sketch to send out the measurement results over wireless, to get rid of the serial port activity which would skew the power consumption measurements.

Speaking of which, here is the power consumption during the call to vccRead() – my favorite graph :)

As usual, the red line is the integral of the current, i.e. the cumulative energy consumption (about 2300 nC).

And as you can see, it takes about 550 µs @ 3.5 mA current draw to perform this battery level measurement. The first ADC measurement takes a bit longer (25 cycles i.s.o. 13), just like the ATmega datasheet says.

The total of 2300 nC corresponds to a mere 2.3 µA average current draw when performed once a second, so it looks like calling vccRead() could easily be done once a minute without draining the power source very much.

The final result is pretty accurate: 201 for 5V and 147 for a 4V battery. I’ve tried a few units, and they all are within a few counts of the expected value – the 4-fold ADC readout w/ noise reduction appears to be effective!

Update – The latest version of the bandgap sketch adds support for an adjustable number of ADC readouts.

This is a conversation we had often in university when I studied environmental and resource management, and at work (wagner und co solar) because they make their PV mounting systems from aluminum.

Very tricky by the choice of material is tricky and it depends on the mechanical stress. A mounting system of PV module will have to stand a lot of stress: wind storms, snow loads etc etc, so does a macbook or an ipad, so the use of alu is justified. But for a static unit that sits indoors and does not have to stand a lot of mechanical stress this would be like wasting alu.

Bauxite mining is also made in open cats mines which are very destructive to ecosystems and landscapes.

I think the best from an ecological footprint point of view is wood, but not sure how that will stand humidity. Maybe waxed wood ? Or some 100% recycled plastic? Metals are too scarce and precious to waste on such an application.

But that's my point of view.

Let’s face it – some parts of the JeeNode / JeePlug documentation isn’t that great. Some of it is incomplete, too hard, missing, obsolete, or in some cases even just plain wrong.

I think that the fact that things are nevertheless workable is mostly because the “plug and play” side of things still tends to work – for most people and in most cases, anyway. You assemble the kits, solder the header, hook things up, plug it into USB, get the latest code, upload an example sketch, and yippie… success!

But many things can and do go wrong – electrically (soldering / breadboarding mistakes), mechanically (bad connections), and especially on the software side of things. Software on the host, but most often the problems are about the software “sketch” running on the JeeNode. You upload and nothing happens, or weird results come out.

Ok, so it doesn’t work. Now what?

There’s a chasm, and sooner or later everyone will have to cross it. That’s when you switch from following steps described on some web page or in some PDF document, to taking charge and making things do what you want, as opposed to replicating a pre-existing system.

To be honest, following instructions is boring – unless they describe steps which are new to you. Soldering for the first time, heck even just connecting something for the first time can be an exhilarating experience. Because it lets you explore new grounds. And because it lets you grow!

As far as I’m concerned, JeeLabs is all about personal growth. Yours, mine, anyone’s, anywhere. Within a very specific domain (Physical Computing), but still as a very broad goal. The somewhat worn-out phrase applies more than ever here: it’s better to teach someone how to fish (which can feed them for a lifetime) than to give them a fish (which only feeds them for a day).

IMO, this should also drive how documentation is set up: to get you going (quick start instructions) and to keep you going, hopefully forever (reference material and pointers to other relevant information). A small part of the documentation has to be about getting a first success experience (“don’t ask why, just do it!”), but the main focus should be on opening up the doors to infinitely many options and adventures. Concise and precise knowledge. Easy to find, to the point, and up to date.

Unfortunately, that’s where things start to become complicated.

I’m a fast reader. I tend to devour books (well, “skimming” is probably a more accurate description). But I don’t really think that thick books are what we need. Sure, they are convenient to cover a large field from A to Z. But they are reducing our options, and discourage creative patterns – What if I try X? What if I combine Y and Z? What if I don’t want to go a certain way, or don’t have exactly the right parts for that?

This weblog on the other hand, is mostly a stream-of-conscience – describing my adventures as I hop from one topic to the next, occasionally sticking to it for a while, and at times diving in to really try and push the envelope. But while it may be entertaining to follow along, that approach has led to over 1000 articles which are quite awkward as documentation – neither “getting started” nor “finding reference details” is very convenient. Worse still, older weblog posts are bound to be obsolete or even plain wrong by now – since a weblog is not (and should not be) about going back and changing them after publication.

I’ve been pondering for some time now about how to improve the documentation side of things. There is so much information out there, and there is so much JeeLabs-specific stuff to write about.

Write a book? Nah, too static, as I’ve tried to explain above.

Write an eBook? How would you track changes if it gets updated regularly? Re-read it all?

A website? That’s what I’ve been doing with the Café, which is really a wiki. While it has sections about software and hardware, I still find it quite tedious (and sluggish) for frequent use.

I’ve been wanting to invest a serious amount of time into a good approach, but unfortunately, that means deciding on such an approach first, and then putting in the blood, sweat, and tears.

My hunch is that a proper solution is not so far away. The weblog can remain the avant garde of what’s going on at JeeLabs, including announcing new stuff happening on the documentation side of things. Some form of web-based system may well be suited for all documentation and reference material. And the forum is excellent in its present role of asking around and being pointed to various resources.

Note that “reference material” is not just about text and images. There is so much information out there that pointers to other web pages are at least as important. Especially if the links are combined with a bit of info so you can decide whether to follow a link before being forced to surf around like a madman.

The trick is to decide on the right system for a live and growing knowledge base. The web is perfect for up-to-date info, and if there’s a way to generate decent PDFs from (parts of) it, then you can still take it off-line and read it all from A to Z on the couch. All I want, is a system which is effective – over a period of several years, preferably. I’m willing to invest quite a bit of energy in this. I love writing, after all.

Suggestions would be welcome – especially with examples of how other sites are doing this successfully.

For us the underlying aim of energy monitoring is energy reduction. It's therefore important that over its useful life an energy monitoring system contributes to the saving of more energy than it involved in the embodied energy of it's production.

Recently we have been having the discussion as to which material is environmentally better to use for electronic enclosures.

So I did some research:

Caution: The figures below were obtained from reputable sources but should not be taken on face value.

•  Extruded Aluminium takes approximately 40-80% more energy (KWh/Kg) to produce than ABS plastic [1][2] *

• Aluminium is widely and easily recycled (even if its been anodised [2]) and the recycled product is of just as high a quality as the original. ABS plastic can be recycled in some locations but the recycled product is of much lower quality than the original, 'downcycling' would be a better term! 

• Recycled aluminium takes about 30% less energy (KWh/Kg)  to produce than ABS plastic [3].

• Plastic is made from oil which is a non-renewable fossil fuel.

• Aluminium is the most abundant metal in the Earth's crust, extracting it requires lots of electricity which could be generated from renewable sources. 

With current processing and recycling methods we think aluminium could be the best material to use, it does take more energy to produce in the first place but once produced it can be recycled again and again to make new things with little extra energy.

What do you think?

References:
[1] http://www.inference.phy.cam.ac.uk/withouthotair/c15/page_88.shtml
[2] www.victoria.ac.nz/cbpr/documents/pdfs/ee-coefficients.pdf
[3] http://www.worldchanging.com/archives/005656.html

*Aluminium is about 2.6 times denser than plastic therefore a similar case made from plastic could be lighter. Further research is required before drawing a conclusion. 

Welcome to the Thursday Toolkit series, about tools for building Physical Computing projects.

(this is a bit of a side excursion, about checking the quality of a measuring instrument)

“Ah, but is it any good?” – that’s the inevitable question to ask when getting a precise instrument, right?

I’m referring to the 6.5 digit 34401A HP (now Agilent) multimeter I got my hands on, recently. This translates to: better than 1 ppm (part per million), i.e. 10,000 times more accurate than one percent!

This is the sort of thing the members of the volt-nuts mailing list ponder about, I would imagine.

In my case, with now over half a dozen ways to measure voltage here (numerous hand-held multimeters, mostly), I just wanted to know which one to trust most and to what extent.

The solution comes in the form of a transfer voltage standard – an item you can order, gets shipped to you, and which then gives a certain level of confidence that it will provide a fixed voltage reference. As it turns out, Geller Labs offer just such a thing at low cost – it’s called the SVR 2.0:

Put 15V on its input (left), wait 30 min, and the output pins (right) will produce exactly 10.00000 Volt – magic!

Each board is “burned in” (kept turned on) for 200 hours and calibrated at the temperature you specify (I asked for 21°C). You even get the measured temperature coefficient at that spot (mine is 1.7 ppm/°C), so you can in fact predict the voltage it will generate at a slightly different temperature. Now that’s serious calibration!

My bench-top multimeter will indeed go down to 1 ppm in 6-digit mode, i.e. steps of 10 µV when measuring 10 V:

And guess what – after a 30-minute warm-up (both the 34401A and the SVR), it’s spot on.

No last-digit jitter, nothing. A constant 10.000,00 readout. The current room temperature is 21.1°C, heh.

Think about it for a second: as hobbyist, you can order a precision second-hand instrument from eBay, Google around a bit to find a little voltage standard, have ‘em shipped from different parts of the planet, get them here within two weeks, hook up some wires, wait 30 minutes, and they match to 0.000,1 % precision.

Given that this instrument is from the 90′s, I’m massively impressed. This 34401A HP thing rocks!

Voltage? Current? Resistance? Game over – for me, this is more than enough precision for serious use.

With webcam surveillance, you can login from any computer, from any corner of the world and watch what is going on in your house. Whether you're on vacation, or away at work, your home is just a click away. What's more, most webcam software providers like GotoCamera www.gotocamera.com even allow you to login from your mobile phone and watch videos of your home.

After a long wait the Raspberry Pi I ordered from Farnell on 29th February finally arrived yesterday.

I expect that most people reading this blog knows all about the Raspberry Pi and the charity behind it by now, designed with the aim to bring programming back into the school curriculum and spawn a new generation of coders, it’s had some fantastic news coverage and even people with no idea about computers have mentioned it to me over the last few months. It has been a rocky road, originally it was expected to have been released in late 2011 but finally the much anticipated single board computer has started to be delivered into the eager hands of geeks around the world. Initially only a caseless version of the “Model B” is available, intended for early adopters and developers with a fully cased version being launched for education later in the year. The idea being that by the time it reaches the hands of school children there will already be a healthy eco system built up around it and those preparing educational material will have been able to do so.

At the moment I am just familiarising myself with it and getting a grasp of what it is capable of. I’m running Debian Squeeze on it as that’s my distro of choice for servers and the like anyway and is also what the Raspberry Pi team are currently recommending. As a desktop it’s usable but pretty sluggish, perhaps not as much as expected but it’s potential for me lies more in the home automation and IoT field, £30 for a tiny networked Linux box is unbeatable and with up to 17 GPIO pins, built in UART and support for I2C and SPI it also opens up a lot of possibilities for interfacing to other hardware, a number of expansion boards are already available or in the pipeline. Here is a good primer on Getting Started with Raspberry Pi GPIO and Python.