Computing stuff tied to the physical world

Archive for October 2011

Permanent LCD display

In Hardware on Oct 31, 2011 at 00:01

Remember the re-using an LCD screen post?

Well, I’ve now built it into my lab corner at JeeLabs:

DSC 2698

The panel is hinged and swings to the left for access to other stuff, and everything has simply been screwed on. You can see the Acer Aspire One netbook mid-center, which is driving this display in mirroring mode right now.

Here’s the back, with 12V power, VGA, and DPMI connectors:

DSC 2700

You can see the (ugly) drilled cutout, with the backlight of the display shining through.

This display is going to be used mainly to experiment with basic in-house display of the data I’ve been collecting for so long, but it will also be available for a new oscilloscope I ordered recently, as well as other experiments which produce a VGA or DPMI signal, such as embedded Linux boards. A Raspberry Pi, perhaps?

A new life for an old discarded laptop display!

Driven by passion

In Musings on Oct 30, 2011 at 00:01

After three years, I thought that it might be interesting to “show you around” here at JeeLabs:

DSC 2638

To the right – not visible here – is the main electronics corner, which will be shown in tomorrow’s weblog post because of another little project I’ve been working on. Let me explain the various bits ‘n bobs you see here:

JeeLabs tagged

It might seems odd, but this is all there is to the JeeLabs, ahem, “empire”.

The Vancouver view always brings back lots of good memories from a year-long stay there, a couple of years ago. An amazing place, in terms of cultural diversity and with its breathtaking nature wherever you go.

I also wanted to show you this to illustrate how little is needed to sustain a small shop. It wouldn’t be sufficient if you’re chasing riches and fame, but if all you want is to have fun and keep going, then hey, it’ll do fine.

JeeLabs would have been totally unthinkable on this scale two decades ago.


CC-RT: Pin assignments

In AVR, Hardware on Oct 29, 2011 at 00:01

Part 4 of the Crafted Circuits – Reflow Timer series.

Now that all the pieces of the circuit are known, more or less (I’ll assume that the MAX31855 can be used), it’s time to figure out whether everything will fit together. One issue I’d like to get out of the way early on, is pin assignments on the ATmega. There are 20 I/O pins: 14 digital, of which 6 PWM, and 6 digital-or-analog.

The best thing would be to make this as compatible with existing products as possible, because that simplifies the re-use of libraries. For this reason, I’ll hook up the RFM12B wireless module in the same way as on a JeeNode:

  • D.2 = INT0 = RFM12B INT
  • D.10 = SS = RFM12B CS
  • D.11 = MOSI = RFM12B SI
  • D.12 = MISO = RFM12B SO
  • D.13 = SCK = RFM12B SCK

5 I/O pins used up – let’s see how many the rest needs:

  • 2 LED’s = 2 pins
  • 2 buttons = 2 pins
  • buzzer = 1 pin
  • LCD + backlight = 7 pins
  • thermocouple = 3 pins
  • SSR output = 1 pin

Total 5 + 16 = 21 pins. Whoa, we’re running out of pins!

Unfortunately, we’re not there yet: the thermocouple chip consumes about 1 mA, so we need a way to power it down if we want a serious auto power-off option. That’s one extra pin.

Also, it would be very nice if this thing can be programmed like a regular Arduino or JeeNode, i.e. using D0 and D1 as serial I/O. That also would help a lot during debugging and in case we decide to use the serial port for configuration. Hm, another 2 pins.

And lastly, I’d like to be able to measure the current battery voltage. Drat, yet another (analog) pin.

All in all we seem to need 5 more pins than are available on an ATmega168/328 28-DIP chip!

The good news is that there are usually a few ways to play tricks and share pins for multiple purposes. One easy way out would be to just use an I/O expander (like the LCD-plug) and gain 5 I/O pins right away. But that’s cheating by throwing more hardware at the problem. Let’s look at some other options:

  • the SSR output can be combined with one of the LEDs, since a red LED will probably be used to indicate “heater on” anyway
  • the thermocouple chip is a (read-only) SPI chip, which means that its SCK and SO pins can be shared with those of the RFM12B
  • one way to free the button pins is to put the buttons on data lines used by the LCD – with extra resistors to let the LCD output work even while pressed
  • the buttons and LEDs could be combined, as on the Blink Plug (this is mildly confusing, since pressing a button always lights its LED as well), but this would prevent sharing the SSR output with the red LED
  • multiple buttons could be tied to a single analog input pin by adding some extra resistors, but this rules out the use of pin-change interrupts
  • yet another trick is to combine a high-impedance analog input (for measuring battery voltage) with a pin which is usually used as output, such as one of the LCD data pins

I’m inclined to adopt the first three tricks. That frees five pins – one can be used to power the thermocouple chip and two would be D0 and D1 to support standard serial I/O. We could have up to 5 push buttons this way.

So all in all, the 28-pin ATmega seems to be just right for the Reflow Timer. Depending on the complexity of the sketch, either an ATmega168 or an ATmega328 could be used. My current reflow sketch fits in either one.

With luck, the Reflow Timer can remain compatible with Arduino, RBBB, JeeNode, etc. and it will support sketch uploads in exactly the same way as with JeeNodes and RBBB’s, i.e. through an FTDI 6-pin header with a USB-to-FTDI interface such as the USB-BUB.

Let’s try and come up with a tentative pin allocation:

  • D.0 and D.1 = serial I/O via FTDI pins
  • D.2 and D.10 .. D.13 = RFM12B, as above
  • D.3 = LCD backlight (supports hardware PWM)
  • D.4 = buzzer
  • D.5 and D.6 = LED outputs (both support PWM)
  • D.8 and D.9 = thermocouple power and chip select
  • A.0 = battery voltage readout
  • A.1 .. A.5 and D7 = LCD (4 data + 2 control)
  • A.1 .. A.5 = shared with up to 5 push buttons

Several pins could be changed if this will simplify the board layout later – but hey, ya gotta start somewhere!

Note that I’m using D.X as shorthand for digital pins, and A.Y for analog pins, matching Arduino terminology (where A.Y can also be used as digital pin => D.(Y+14)).

The next step will be to work out more electrical details, i.e. figure out how to add some new features.


The AC current sensor node lives!

In Hardware, Software on Oct 28, 2011 at 00:01

At last, everything is falling into place and working more or less as intended:

    OK 17 172 31 173 31   <- 25 W incandescent
    OK 17 169 31 177 31
    OK 17 40 0 41 0       <- open
    OK 17 245 95 40 0     <- 75 W incandescent
    OK 17 140 95 245 95
    OK 17 43 0 140 95     <- open
    OK 17 39 0 43 0
    OK 17 118 2 42 0      <- 2W LED-light
    OK 17 211 2 97 2
    OK 17 219 2 102 2
    OK 17 107 2 219 2
    OK 17 89 2 107 2
    OK 17 40 0 82 2       <- open
    OK 17 39 0 40 0
    OK 17 38 0 39 0
    OK 17 219 53 38 0     <- 40 W incandescent
    OK 17 234 53 219 53
    OK 17 43 0 234 53     <- open
    OK 17 149 75 43 0     <- 60 W incandescent
    OK 17 23 0 149 75     <- open
    OK 17 42 0 23 0

That’s the log of packets coming in from the AC current node, as I inserted and removed various light bulbs. Still through the isolation transformer for now.

As you can see, every change is very clearly detected, down to a 2W LED light. These are all the bulbs with an E27 fitting I happened to have lying around, since the test setup was fitted with one of those. Some other time I’ll try out light inductive loads, chargers, and eventually also a 700 W heater as load.

I’m not interested that much in the actual readings, although there is a fairly direct relationship between these wattages and the 2-byte little-endian int readouts. The fluctuations across readings with unchanged load are small, and the no-load readout is lower than in my previous tests, perhaps the shorter and more direct wiring of this setup is helping avoid a bit of noise.

One problem I see is that some packets are lost. Maybe the way the wire antenna is laid out (quite close to the PCB’s ground plane) prevents it from working optimally.

The other problem seems to be that this node stops transmitting after a while. I suspect that the current draw is still too large, either on the ADC side (500+ samples, back to back) or due to the RFM12B packet sends (unlikely, IMO, after the previous test results). At some point the voltage over the supercap was 3.1V – I’m not sure what’s going on, since after a new power-up the unit started transmitting again.

Hm… or perhaps it’s that plus an antenna problem: when I rearranged it, things also started working again (I’m always cutting power before messing with the test circuit, of course).

But all in all I’m delighted, because this unit has a really low component count!


AC current node prototype

In AVR, Hardware on Oct 27, 2011 at 00:01

Time for some pictures. Here’s the “AC current node” prototype I’ve been working on:

DSC 2680

And in case you’re wondering: that’s a simple plastic enclosure I found a while back, which looks pretty much like (and probably was intended as) … a game catridge!

Here’s the completed unit with a test hookup:

DSC 2690

You can see the transformer-less power supply, and an ATtiny84-with-RFM12B board, which I’m tentatively calling the “JeeNode Micro” (“JNµ”) – 16 x 48 x 4 mm:

Screen Shot 2011 10 17 at 21 18 07

Please note that I’m using this for internal projects for now. I haven’t figured out whether it’s suitable for the shop, since the JNµ is different from a JeeNode in several ways, not in the least in that it requires quite a bit more hand-holding to develop “sketches” for and to load them into the unit. This isn’t even the first JNµ board – I’ve tried several different layouts in the past.

For this particular project though, it’s quite a good fit, both in size and due to the ATtiny’s differential ADC plus 20 x gain stage. I’ve yet to hook up the analog input to the sense resistor, BTW. It’s all work-in-progress…


Running on charge

In AVR, Hardware, Software on Oct 26, 2011 at 00:01

Now that the supercap charger works, and now that I’ve switched to the ATtiny84 as processor, everything is ready to create a self-contained AC current sensing node.

The one missing piece is the software for it all. It’s going to take a while to get it tweaked, tuned, and optimized, but a basic check is actually quite easy to do.

Here is the main loop if my first test, reusing most of the code already in the tiny50hz sketch:

Screen Shot 2011 10 17 at 20 03 56

My main goal was to quickly get power consumption down, so that the ATtiny would use less than what’s available through the low-power supply, i.e. roughly 1 mA. Without extra steps, it’ll draw over 4 mA @ 8 MHz.

What I did was to reduce the clock rate to 1 MHz (except while processing RF12 packets), and to turn off subsystems while not needed (timer 1 is never used, and the ADC and USI h/w is now enabled only while used).

These two lines at the top of loop() are special:

  set_sleep_mode(SLEEP_MODE_IDLE);
  sleep_mode();

They will reduce power consumption by halting the processor until the next interrupt. Since time is being tracked via the millis() call, and since that operates through a timer interrupt, there is no reason to check for a new millisecond transition until the next interrupt. This is a quick way to cut power consumption in half.

But keep in mind that the processor is still running most of the time, and running at 1 MHz. That explains why the current consumption remains at a relatively high 440 µA in the above code (with a brief “power blip” every 16 s). For comparison: in power-down mode, current draw could be cut to 4 µA (with the watchdog timer running).

Still, this should be enough for a first test. Sure enough, it works fine – powered by the ISP programmer:

    OK 17 84 2 0 0
    OK 17 67 2 84 2
    OK 17 103 2 67 2

Every ≈ 16 seconds, a 4-byte packet comes in with the latest reading and the previous reading (as 2-byte ints).

The interesting bit is what happens when the ISP programmer gets disconnected. While connected, it charged the supercap to about 4.9V – so with a bit of luck, this node should keep running for a while, right?

Guess what… it does. My test node just sent out 197 packets before running out of steam!

This includes the ≈ 500 x ADC samples and 16-second waits in each cycle. IOW, a 0.47 F capacitor charged to 4.9V clearly has more than enough energy for this application. In fact, it makes me wonder whether even a normal electrolytic capacitor might be sufficient. The benefit of a smaller capacitor would be that the node can be up and running much faster than the 1 hour or so needed to charge up a supercap.

Here’s my very very sketchy estimate:

  • let’s assume the unit operates down to 2.5 V
  • with 4.9 V charge, it can run for about 200 cycles
  • so with 3.7 V charge (on AC mains), it ought to run for 100 cycles
  • using a capacitor 1/100th the size, we ought to have enough charge for one cycle
  • with more power-saving logic, energy use can no doubt be lowered further

Given that the node is permanently powered, a 4,700 µF cap ought to be sufficient. I’ve ordered a 6,800 µF @ 6.3V electrolytic cap – with a bit of luck, that should also work. And if it does indeed, startup times will go down drastically, to hopefully just a few seconds.

Progress!

Picking an ATtiny

In AVR, Hardware on Oct 25, 2011 at 00:01

The reason I’m using an ATtiny for the AC current measurement setup, is their differential ADC + gain, and because it is fairly easy to develop for them using the same Arduino IDE as used by, eh, well, Arduino’s and JeeNodes. There are good installers for Windows, Mac OSX, and Linux.

There are several very interesting alternatives other than ATmega and ATtiny, such as the Microchip Technologies PIC and the Texas Instruments MSP430 series. But while they each are attractive for a number of reasons, they either have only a development environment for Windows, or they don’t support standard gcc, or they just don’t offer enough of an advantage over the Atmel AVR series to justify switching. So for something like the AC current node, which doesn’t even need to run off a battery, I’d rather stick to the Arduino IDE and carry over much of what is already available for it. In terms of cost, the differences are minimal.

The trouble with the ATtiny85 I’ve been using for the AC current sensor is that it only has at most 6 I/O pins, while the RFM12B needs 5 to operate (with polling instead of interrupts, this could be reduced to 4).

I’ve tried hard to find tricks to re-use pins, so that the differential ADC pins can be used during measurements while still supporting the RFM12B somehow. I even considered using a 1-pin OOK transmitter instead of the RFM12B. But in the end I gave up – the hassle of finding a solution, figuring out how to support this in software, and still have a decent way of debugging this (read: ISP) … it didn’t add up.

It’s much easier to pick a chip which is slightly less I/O-pin limited, such as the 14-pin ATtiny84:

Screen Shot 2011 10 17 at 14 10 11

One drawback w.r.t. to the ATtiny85, is that it has no 2.56V bandgap reference, only 1.1V – but it does have differential ADC inputs with optional 20x gain stage, which is what made AC current measurements possible.

It turns out that the ATtiny84 has enough I/O pins (a whopping 11!) to support an SPI interface to the RFM12B as well as 2 complete JeeNode-like ports. There is in fact enough I/O capability here to hook up a Room Board.

The 8 Kb flash rom size is sufficient for the RF12 driver plus a bit of application-specific functionality. The 512-byte RAM is not huge, but should also be sufficient for many purposes (two full RF12 buffers will use up less than a third of what’s available). And lastly, there are 512 bytes of EEPROM – more than enough.

To be honest, I’ve been fooling around with this chip for some time, since it could be used to create even smaller PCB’s than the JeeNode. But it has taken me quite a while to get the SPI working (both hardware- and software-based), which was essential to support the RFM12B wireless module. The good news is that it now does, so this is what I’m going to use for the rest of the AC current sensor experiments – wireless is on the way!

Stay tuned …

No, wait. One more factoid: this weblog was started exactly 3 years ago. Celebration time – cheers!


Charging a supercap

In Hardware on Oct 24, 2011 at 00:01

This is a quick experiment to see how this very low-power direct AC mains supply behaves:

JC s Doodles page 20

Note that I’ve built the 200 kΩ value from two resistors in series. This reduces the voltage over each one, and offers a slight security if one of them shorts out. The max 1 mA or so of current these resistors will let through is not considered lethal – but keep in mind that the other side is a direct connection, so if that happens to be the live wire then it’s still extremely dangerous to touch it!

One idea would be to add a “fusible” 100 Ω @ 0.5 W resistor in series with the 200 kΩ. These are metal-film resistors which will disconnect if they overheat, without releasing gases or causing flames. I can’t insert it in the other wire due to the voltage issue, so I’m not really sure it actually would make things any safer.

Here’s my first test setup of this circuit, built into a full-plastic enclosure:

DSC 2687

It took 20 minutes to reach 1.8V, the absolute minimum for operating an ATtiny. This is not a practical operating voltage, because whenever the circuit draws 1 mA or more, that voltage will drop below the minimum again.

The RFM12B wireless module will need over 2.2V to operate, and draw another 25 mA in transmit mode. The only way to make this work will be to keep the transmit times limited to the absolute minimum.

Still, I’m hoping this crude power supply will be sufficient. The idea is to run on the internal 8 MHz RC oscillator with a startup divider of 8, i.e. @ 1 MHz. The brown-out detector will be set to 1.8V, and the main task right after startup will be to monitor the battery voltage until it is considered high enough to do more meaningful work.

With 3.5V power, an ATtiny draws ≈ 600 µA @ 1 MHz in active mode and 175 µA in idle mode, so in principle it can continue running at this rate indefinitely on this power supply. But for “fast” (heh) startup, it’ll be better to use sleep mode, or at least take the system clock down well below 1 MHz.

This might be a nightmare to debug, I don’t know. Then again, I don’t have to use the AC mains coupled supply to test this. A normal low-voltage DC source plus supercap would be fine with appropriately adjusted resistors.

After 35 minutes, the voltage has risen to 2.7V – sure, take your time, hey, don’t rush because of me!

Another 5 minutes pass – we’re at a whopping 3.0V now!

Time for a cup of coffee…

After 45 minutes the charge on the 0.47F supercap has reached 3.3V – yeay! I suspect that this will be enough to operate the unit as current sensor and send out one short packet. We’ll see – it’ll all depend on the code.

After 1 hour: 3.75V, which is about as high as it will go, given the 5.1V zener and the 2x 0.6V voltage drop over the 1N4148 diodes. Update: my test setup tops out at 3.93V – good, that means it won’t need a voltage regulator.

Apparently, supercaps can have a fairly high leakage current (over 100 µA), but this decreases substantially when the supercap is kept charged. In an earlier test, I was indeed able to measure over 2.7V on a supercap after 24 hours, once it had been left charged for a day or so. In this current design the supply will be on all the time, so hopefully the supercap will work optimally here.

Not that it matters for power consumption: a transformerless supply such as this draws a fixed amount of current, regardless of the load. Here’s the final test, hooked up to live mains without the isolation transformer:

DSC 2688

Of this energy, over 95% is dissipated and wasted by the resistors. The rest goes into either the load or the zener.

Funny Eneloop battery

In Hardware on Oct 23, 2011 at 00:01

I don’t know what happened…

DSC 2685

Weird wrinkled plastic wrapper. No leakage or bulge. The other side:

DSC 2686

Maybe this thing got short-circuited and became very hot? Maybe the wrapping has some heat-shrinking properties on purpose, to report this condition even if you look well after things have cooled down again?

I’ve been switching to Eneloop AA batteries everywhere since over a year now, due to the three nice chargers I’ve got. The advantage over NiCad and NiMh is that these really retain their charge for more than a year – perfect for wireless sensor nodes. When fully charged, each cell supplies 1.3V @ 1900 mAh. I’m also re-using these batteries over and over again in the wireless keyboards and mice we have (my mouse runs out once a month).

But that’s the end of the line for this one!

ELRO energy monitor decoding #2

In Hardware on Oct 22, 2011 at 00:01

Yesterday’s post showed how to try and figure out the data sent out by the ELRO wireless units. There’s a lot of guesswork in there, but the results did look promising.

The last guess was about how the data bytes are organized in the packet – which is usually the hardest part. Ok, so now if I treat these as low-to-high 8-bit bytes, then the two packets give me:

    12 1 231 4 16 0 0 213 81 17    hex: 0C 01 E7 04 10 00 00 D5 51 11
    12 1 232 4 16 0 0 214 81 17    hex: 0C 01 E8 04 10 00 00 D6 51 11

There’s not much more one can do with this, because all the packets contain the same information. Now it’s time to add a load to the monitor, so that it will report some more interesting values. I used a 75 W light bulb, so the instantaneous consumption reported should be around that value, and there will probably be a slowly-increasing cumulative power consumption reported as well.

Here are a bunch of packets, using the most recent decoding choices:

Screen Shot 2011 10 16 at 16 10 13

Great – the first four repetitions have again mostly zero’s, with a minor fluctuation in what is presumably the line voltage again. Looks like each reading gets sent out 15 (!) times or so. Or maybe a few more which aren’t recognized – the pulse width thresholds might still be off slightly.

And then values start coming in. Let’s see what this gives when decoded as bytes:

    200 8 1 231 0 32 0 0 216 81 33
    200 8 1 230 0 32 0 0 215 81 33
    200 8 1 230 0 32 0 0 215 81 33
    200 8 1 229 0 32 0 0 214 81 33
    200 8 1 230 32 32 243 2 236 82 33
    200 8 1 230 32 32 242 2 235 82 33
    200 8 1 229 32 32 240 2 232 82 33
    200 8 1 229 32 32 239 2 231 82 33
    200 8 1 229 32 32 239 2 231 82 33
    200 8 1 229 32 32 240 2 232 82 33
    200 8 1 230 32 32 240 2 233 82 33
    200 8 1 229 32 32 239 2 231 82 33
    200 8 1 229 32 32 238 2 230 82 33

Hm. That fourth byte could indeed be the line voltage, but the rest?

Let’s try the 25 W lamp:

    200 8 1 229 10 32 246 0 214 82 33
    200 8 1 229 10 32 246 0 214 82 33
    200 8 1 228 10 32 246 0 213 82 33

Aha – 10 is ≈ 1/3rd of 32. And 246 is ≈ 1/3rd of 2*256+238. Maybe these are amps and watts, not cumulative values after all. No wonder it’s transmitting so often – a lost transmission will cause an inaccurate reading.

Here’s a 700 W load (my reflow grill):

    200 8 1 230 44 33 255 26 29 83 33
    200 8 1 230 44 33 246 26 20 83 33
    200 8 1 230 43 33 221 26 250 82 33

Checking the load with another meter tells me it’s more like 680 W and 2.89 A @ 231 V.

Well, well: the bytes 221 and 26, when interpreted as little-endian int are 6887, i.e. the wattage in 0.1 W steps!

Let’s try amps the same way. With no load, there were values 16 and 32, so probably bits 4..7 of that second byte are used for something else. Let’s try 43 and 33-32, little-endian: could it be 2.99 A?

If all these guesses are correct, then the 75 W lamp readings are: 0.32 A and 75.0 W, and the 25 W lamp readings are: 0.10 A and 24.6 W – hey, these are indeed all pretty much spot on, yippie!

Here’s the other unit with no load plugged in:

    102 12 1 232 0 16 0 0 210 81 17
    102 12 1 232 0 16 0 0 210 81 17

The first two bytes differ. Perhaps a unit ID with its own header checksum?

It looks like the 6-byte is either 16 or 32, perhaps indicating an auto-scale amps range. Also, note how the next to last byte changes from 81 to 82 to 83 on these readings. I suspect that the packet checksum is actually 16 bits.

Great, I think I can implement a decoder for them now. It would be nice to get the checksum validation right, but even without this it will be useful.

These two units are going to be used for some varying loads here at JeeLabs: probably the dish washer and the washing machine. Since they send out readings once every 10 seconds, that should give me sufficient info to correlate with the house meter downstairs.

The readout unit is of no use to me anymore, so I’ve taken it apart:

DSC 2683

Simple OOK receiver, and single-sided board. Not many surprises, really:

DSC 2684

There are low-cost temperature (an NTC ???) and humidity sensors in there, as well as a buzzer (you can set an alarm when a certain power level is exceeded).

The only interesting bit is that the power for the receiver is switched via a transistor, so presumably it synchronizes its reception timing to when the units transmit (the display supports up to 3 units).

One nasty habit of these ELRO units is that they send out a lot of packets: each one sends about 15 per every 10 seconds, and it looks like this takes well over one second per transmission. I’m glad they use the 433 MHz band, otherwise they’d cause quite a few collisions with all the wireless RF12 stuff going on at JeeLabs.

Onwards!

ELRO energy monitor decoding

In Hardware on Oct 21, 2011 at 00:01

I recently found this set at reichelt.de:

ELROEC11

The battery-powered receiver is a bit large and ugly (10×13 cm), but what I was after were the measurement units, which transmit wirelessly on the 433 MHz band, using OOK.

That was a good reason to dust off the ookScope project and adjust them to work with the latest Arduino IDE (sketch) and JeeMon (script).

Here is the result after over 1,000,000 pulses:

Screen

This is a histogram with counts on the horizontal axis and pulse widths on the vertical axis. Both are scaled in a somewhat peculiar logarithmic’ish way, but the main info is on the bottom status line: the packets contain 360 pulses (i.e. bit transitions) with maximum counts at pulse widths of 184, 360, and 460 µs.

I used very specific settings and thresholds to single out these packets:

Screen Shot 2011 10 16 at 14 28 48

So it only picks up packets with 360..362 bit transitions, and ignores all pulses under 40 µs (10 x 4 µs).

The two longer pulse widths might be the same “long” pulse, depending on whether that pulse comes after a short or a long pulse. Here are the first few pulse widths of a quick burst of packets (ignore the P and first int):

Screen Shot 2011 10 16 at 14 28 14

There’s clearly a pattern. If I apply the following translation:

  • pulse < 260 -> display as “-“
  • pulse 260..411 -> display as “.”
  • pulse > 411 -> display as “|”

… then this comes out (this is one long line, wrapped every 80 characters):

Screen Shot 2011 10 16 at 14 43 55

So it looks like there are short (< 260 µs) and long (> 411 µs) pulses, with always a pulse in the range 260..411 µs in between them. And if those dots contain no extra information anyway, then we might just as well omit them:

Screen Shot 2011 10 16 at 14 48 16

That leaves 181 bits of “data”, presumably. If I drop all packets which don’t end up with exactly 181 dashes and pipe symbols, then it turns out I get just a few patterns – here’s a group which changes halfway down, if you can spot the difference:

Screen Shot 2011 10 16 at 14 58 25

But there’s still too much regularity here, IMO. Note that there’s not a single run of three _’s or |’s in there (other than at the start of the line). In fact, all these are either _|’s or |_’s, back to back. So it looks like there are not 2 transitions per data bit, but 4. Let’s reduce the output further. I’ve replaced _| by “0” and |_ by “1” (assuming there are more 0’s than 1’s). I’ve also removed all duplicate lines, and inserted a count of them at the front:

Screen Shot 2011 10 16 at 15 16 03

Note the alternation of 1110 and 0001 in these lines. My hunch is that it’s a slowly varying measurement value, overflowing from 7 (binary 0111) to 8 (binary 1000). This would indicate that the bit order is low-to-high.

Note also that further down the packet, the bit pattern flips from 10 to 01, which is a difference of 1 in binary terms. That’s probably a checksum, and it’s not using exclusive or (since 4 bits have changed) but simple byte-summing. Furthermore, the checksum is 40 bits to the left of the changed value, so there are either 5 bytes from value to checksum, or 8 nibbles-plus-guard-bit units. Let’s try grouping them both ways:

Screen Shot 2011 10 16 at 15 32 18

There is no load right now. The 8-bit grouping is interesting, because then the value alternates between 231 (0b11100111) and 232 (0b11100100) … could this be the line voltage?

Tomorrow, I’ll continue this exploration – let’s see if the data can be extracted!


CC-RT: Choices and trade-offs

In Hardware on Oct 20, 2011 at 00:01

This is part 2 3 of the Crafted Circuits – Reflow Timer series.

There are many design choices in the Reflow Timer. The goal is to keep it as simple and cheap as possible, while still being usable and practical, and hopefully also convenient in day-to-day use.

Display and controls – there are several low-cost options: separate LEDs, 7-segment displays, a character LCD, or a graphics LCD. The LEDs would not allow displaying the current temperature, which seems like a very useful bit of info. To display a few numbers, a small character-based LCD is cheaper and more flexible than 7-segment displays (which need a lot of I/O lines). The only real choice IMO, is between a character-based and the graphics LCD. I’ve decided to go for a 2×16 display because A) fancy graphics can be done on a PC using the built-in wireless connection, and B) a character LCD is cheaper and sufficient to display a few values, status items, and menu choices. And if I really want a GLCD option, I could also use wireless in combination with the JeePU sketch.

For the controls, there’s really only one button which matters: START / STOP. The power switch might be avoided if a good auto-power implementation can be created in software. For configuration, at least one more button will be needed – with short and long button presses, it should be possible (although perhaps tedious) to go through a simple setup process. A third button might make it simpler, but could also slightly complicate day-to-day operation. So two or three buttons it is.

Temperature sensor – this is the heart of the system. There are essentially two ways to go: using an NTC resistor or using a thermocouple. The NTC option is considerably cheaper and can be read out directly with an analog input pin, but it has as drawback that it’s less accurate. In the worst case, accuracy might be so low that a calibration step will be needed.

Thermocouples don’t suffer from the accuracy issue. A K-type thermocouple has a known voltage differential per degree Celsius. The drawback is that these sensors work with extremely low voltages which require either a special-purpose chip or a very sensitive ADC converter. Since thermocouple voltages are based on temperature differences, you also need some form of tracking against the “cold junction” side of the thermocouple. Thermocouple-based sensing is quite tricky.

But the main reason to use them anyway, is mechanical: although there are glass-bead NTC’s which can withstand 300°C and more, these sensors come with short wires of only a few centimeters. So you need to somehow extend those wires to run from the heater to the Reflow Timer. And that’s where it gets tricky: how do you attach wires to that sensor, in an environment which will heat up well beyond the melting point of solder? And what sort of wire insulation do you use? Well… as it turns out, all the solutions I found are either very clumsy or fairly expensive. There’s basically no easy way to get a glass-bead NTC hooked up to the reflow timer in a robust manner (those wires out of the glass bead are also very thin and brittle). So thermocouple it is.

Thermocouple chip – for thermocouples, we’ll need some sort of chip. There seem to be three types:

  • dedicated analog, i.e. the AD597
  • dedicated digital, i.e. the MAX6675 or MAX31855
  • do-it-yourself, i.e. a sensitive ADC plus cold-junction compensator

The AD597 is used the the Thermo Plug and in my current reflow controller setup. It works well, with a voltage of 10 mV/°C coming out as analog signal. So with 250°C, we get 2.50V – this is a perfect match for an ATmega running at 3.3V. The only small downside, is that it needs an operating voltage which is at least 2V higher than the highest expected reading. If we need to go up to say 275°C (above what most ovens can do), then we’ll need a 4.75 V supply voltage for the AD597.

The MAX6675 doesn’t have this problem because the readout is digital, and works fine with supply voltages between 3.0 and 5.5V. But it’s a very pricey chip (over €14 incl VAT). Keeping these in stock will be expensive!

The MAX31855 is also a digital chip, and about half the price of the MAX6675. The main difference seems to be that it can only operate with a supply from 3.0 to 3.6V, which in our case is no problem at all (we need to run at 3.3V anyway for the RFM12B). I’ve no experience with it, but this looks like a great option for the Reflow Timer.

There is a slight issue with each of these chips, in that they do not exist in through-hole versions but only in a “surface mounted device” (SMD) style. The package is “8-SOIC”, i.e. a smaller-than-DIP 8-pin plastic chip:

8 SOIC sml

For people who don’t feel confident with soldering it might pose a challenge. There are no sockets for SMD, you really have to solder the chip itself. Then again, if you’re going to create a reflow setup for building SMD-based boards anyway, you might as well get used to soldering these size chips. Trust me, SOIC is actually quite easy.

(note: there is an all-DIP solution with the LT1025, but it needs an extra op-amp, so I’ve not checked further)

Battery

If we can use the MAX31855, then everything can be powered with 3.3V. This means that either 3x AA or 1x LiPo will work fine, in combination with a 3.3V regulator. I’ll stick with the MCP1702 regulator, even though it’s not the most common type, because of its low standby current – this will help reduce power in auto power-down mode.

But how much current do we need? To put it differently: how long will these batteries last? Let’s find out.

The prototype I have appears to use about 35 mA while in operation. Let’s take a safety margin and make that 50 mA in case we also need to drive an opto-coupler for the SSR option. And let’s say we use 2000 mAh AA cells, then we’ll get 40 hours of operation out of one set of batteries. Let’s assume that one reflow cycle takes 10 minutes, plus another 5 minutes for auto power-off, then we can use one set of batteries for 160 reflow cycles. Plenty!

We could even power the Reflow Timer with an AA Power Board, and still get about 50 cycles – but that would increase the cost and require some very small SMD components.

Let’s just go for the 3x AA setup, with either a DC or USB jack as possible alternative.

AC mains switching

For switching the heater, there are several options. The one I’m using now is a remote-controlled FS20 switch from Conrad (or ELV). It can be controlled directly by the RFM12B wireless module. An alternative would be the KAKU (a.k.a. Klik Aan Klik Uit or Home Easy) remote switch, which operates at 433 MHz and kan also be controlled directly from the RFM12B. The advantage of this setup is that you never need to get involved with AC mains – just place the remote switch between mains socket and heater (grill, oven, etc) and you’re done.

Another option is to use a Solid State Relay (SSR), which needs 5..10 mA of current through its built-in opto-coupler. I built this unit a while back to let me experiment with that. The benefit of such a configuration is that all the high-voltage AC mains stuff is tucked away and out of reach, and that the control signal is opto-isolated and can be attached to the Reflow Timer without any risk. Note that with SSR, the RFM12B module becomes optional.

Yet another option would be to use a mechanical relay, but I’d advise against that. Some heaters draw quite a bit of current (up to 10A) and will require a hefty relay, which in turn will require a hefty driver. Also, very few power relays can operate at 5V, let alone 3.3V – which means that a 3x AA powered approach would not work.

So, RF-controlled switch it is, with an extra header or connector to drive the LED in an SSR as option.

That’s about it for the main Reflow Timer circuit design choices, methinks.


CC-RT: Prototyping

In Hardware on Oct 19, 2011 at 00:01

This is part 2 of the Crafted Circuits – Reflow Timer series.

Now that the initial requirements of the Reflow Timer have been laid out, it’s time to design and build a first prototype of the whole setup. Normally, I’d do this with either a solder-less breadboard (shown on the left) or a soldered protoyping PCB (bottom view of an example shown on the right):

DSC 2691

But in this case, I’ll skip those since I already built up a system using a JeeNode, some plugs, and my favorite circuit hacking setup, which I call Projects On Foam:

DSC 2189

That’s a JeeNode mounted upside-down, with a few plugs: a Thermo Plug, a Blink Plug, and an LCD Plug with a 2×16 character LCD on top. In the bottom right is a 4x AA battery pack, stuck to the board with double-sided tape.

I’ve been using this setup for about a year now. There are some “features” listed which don’t actually exist, such as the calibration mode: the current sketch has fixed values, tweaked by trial and error for my specific grill. But apart from that, it works well: prepare grill, turn on, press start, wait for beep, open grill, turn off, done.

The reason to skim over this step in this series of posts, is that your setup will differ anyway, unless you intend to build exactly the same thing. But it’s still a crucial step to go through. This is where you get to test that your idea actually works, and where you create the setup needed to develop and test the software, i.e. sketch.

Having constructed this setup, I know it works. I also gained valuable experience with it – and I’m still not 100% satisfied (besides being a mish-mash of plugs stuck together on a foam board). The main issues are:

  • this is using an AD597 thermocouple chip, which needs at least 5V – hence the 4x AA
  • there is no provision for a mechanical or solid-state relay to switch the heater
  • I’d like to have more control over the backlight, i.e. dimming through PWM
  • it’d be nice to support an auto-power-down mode which draws virtually no current
  • the LCD plug could be omitted if we have enough I/O pins to drive the LCD directly
  • maybe the transistor driving the beeper can be omitted as well

Those last two items are all about reducing the number of components. Less components = lower cost = simpler build instructions = better chances of success = everybody happy :)

Tomorrow, I’ll go through the main choices / trade-offs.

Coming back for more

In News on Oct 18, 2011 at 00:01

The JeeLabs shop has always been based on the Shopify service (which I won’t recommend for European shops, because they haven’t got a clue about VAT). It looks nice, and I guess I fell for it before understanding all the implications. So Shopify it is, as far as JeeLabs is concerned. I’ve worked my way around VAT by simply refunding and issuing a VAT-exempt invoice where needed.

Anyway, it turns out that there is now a “customer login” option, which I activated a few days ago. What that means is that whenever you shop at JeeLabs, you now get a choice when checking out your order:

Screen Shot 2011 10 11 at 17 59 07

What that really means, is that you won’t have to re-enter your shipping details over and over again if you decide to come back for more. And judging from the info in Shopify, that’s about a third of all JeeLabs customers. I am very proud of that fact BTW, because in my view a return customer is someone who is genuinely satisfied with what he/she got the first time around. It feels good to be able to follow up.

If you don’t want to leave this sort of info on the Shopify servers, please keep in mind that the only difference is that you get to pick a password for re-using what you’ll need to enter anyway.

In case you’re worried that this information is going to be used (by me or anyone else), for anything but order fulfillment: don’t be. I’m probably far more extreme in my position than you on privacy. I do not track personal details. The internet is a nightmare in that respect as it is. I Really Do Not Track, nor keep logs, nor “forget” to remove logs. I don’t do Google Analytics. I don’t have the Shopify “stats” option. I don’t “visualize” web accesses. All I keep are recent activity logs of my own servers, to be able to figure out problems when needed.

Life’s too short for lots of things – and that includes feeding ego’s and spying on people, IMO :)

But that doesn’t mean you have to suffer and re-enter the same info over and over in the JeeLabs shop, eh?


Voltage levels

In AVR, Hardware on Oct 17, 2011 at 00:01

In yesterday’s post, I described the idea of powering the AC current detector via a transformer-less power supply, using a very large capacitor or a supercap.

That means the whole circuit ends up being connected to 220V AC mains. You might think that nothing changed, since the circuit was already connected to mains via the 0.1 Ω shunt, but there’s more to it – as always!

If the power supply is tied to AC mains, then that means the circuit’s GND and VCC are also tied to these wires. The problem is that these two things interfere with each other:

JC s Doodles page 19

Because now we have a signal coming from the voltage drop generated by the shunt which is referenced to the same voltage level as the GND of the circuit. In other words, that signal we’re trying to measure now swings around zero! And while the ATtiny has a differential input, which in principle only cares about the voltage differential between two pins, it’s not designed to deal with negative voltages.

Uh, oh – we’re in trouble!

I could use a capacitor to “AC-couple” the 50 Hz frequency into a voltage divider, but that effectively creates a high-pass filter which attenuates the 50 Hz and lets more of the noise through. Not a very nice outlook, and it’s also going to require a few additional passive components. I’m still aiming for a truly minimal component count.

But we’re in luck this time. The differential ADC appears to be perfectly happy with tying one side to ground. It might not be able to measure the negative swings, but it does the positive ones just fine. When I tried it on my existing setup, I still got more or less the same readings.

Still, we do have to be careful. A negative voltage on any input pin is going to seek its way through the ESD protection diodes present on each ATtiny I/O pin. Keep in mind that we’re dealing with a very low-impedance shunt, and large currents. So it’s important to limit the effect of negative swings to avoid damage to the chip. The easiest way to do so is to include a 1 kΩ resistor in series, i.e. between signal and ADC input pin. That way, even a 1 V negative voltage excursion will drive less than 1 mA current through the ESR diode, a value which is still well within specs. Even better, that 1 kΩ resistor can be combined with a 0.1 µF cap to ground, as low-pass for the ADC.

Good, so if that weak-supply-feeding-a-big-cap idea works, then the rest of the circuit ought to continue working as intended, even though we’re operating at the limit of the ATtiny’s ADC voltage range.

All that’s left to do then, is get that power supply right. Oh, wait: and figure out a way to get a wireless setup going. Oh, and also figure out a good enclosure to keep this dangerous hookup safely tucked away and isolated.

Oh well. Not there yet, but progress nonetheless!


Finding a power source

In Hardware on Oct 16, 2011 at 00:01

Assuming I can figure out a way to transmit wireless information from the ATtiny, I’d like to make that recent AC current change detector a self-contained and self-powered unit. At minimal cost, i.e. with as few parts as possible.

That’s a bit of a problem. Adding a transformer-based power supply, however feeble, or a ready-made AC/DC converter would probably triple the cost of the setup so far. Not good.

I really only need a teeny bit of power. The techniques to a get a JeeNode into low-power sensing have been well-researched and documented by now. It shouldn’t be too hard to make an ATtiny equally low-power.

First of all, this “power sensing node” really doesn’t have to be on all the time. Measuring power once every few seconds would be fine, and reporting over wireless only when there is a significant change in detected current. So for the sake of argument, let’s say we measure once a second, track the average of three to weed out intermittent spikes, and report only when that average changes 20% or more since the last value. For continuity, let’s also report once every 3 minutes, just to let the system know the node is alive. So that’s one packet with a 2-byte payload every 3 minutes most of the time, and one current measurement every second (with the same ADC sampling and filtering as before).

What this comes down to is that we need perhaps 3.3V @ 10 µA all the time, with a 30 mA peak current draw every couple of minutes.

A battery would do fine. Perhaps 2x AA or a CR123 1/2 AA. But it feels silly… this thing is tied to a power line!

Why not use a transformer-less power supply, as described in this well-known application note from MicroChip?

Well, there’s a problem. These types of supplies draw a constant amount of current, regardless of the load. Whatever the circuit doesn’t use is consumed by the zener diode. So to be able to drive a 30 mA peak, we’d need a power supply which constantly draws 30 mA, i.e. 6.6 watts of power. Whoa, no thanks!

Here’s a basic resistive transformer-less supply (capacitive would also be an option):

JC s Doodles page 19 copy

There is a way to reduce the current consumption, since we only need that 30 mA surge very briefly, and not very often: use a big fat capacitor on the end, which stores enough energy to provide the surge without the voltage collapsing too far. This might be a good candidate for a trickle-charged small NiMh cell or even a supercap!

Hm, let’s see. If the supply is dimensioned to only supply a very small amount of current, say 1 mA, then it would be more than enough to charge that capacitor and supply the current for the ATtiny while in power-down mode. A 0.47 F supercap (which I happen to have lying around) ought to be plenty. This power supply would draw 0.22 W – continuously. Still not stellar, but not worse than several other power bricks around here.

Alas, such a design comes with a major drawback: with such a small current feeding such a large cap, it will take ages for the initial voltage to build up. I did a quick test, and ended up waiting half an hour for the output to be useful for powering up an ATtiny + RFM12B. That’s a lot a waiting for when you plug in such a system for the first time, eager to see whether it works. It also means that the firmware in the ATTiny has to very careful at all times with the limited energy available to it.

Still, I’m tempted to try this. What’s half an hour in the grand scheme of things anyway?

Digital filter design

In Software on Oct 15, 2011 at 00:01

In the moving averages post a few days ago, I just picked whatever seemed reasonable for filtering – i.e. running a moving average of order 31 over 531 samples, sampling at roughly 7,000 samples/second (which is what the free-running ADC does with my clock choice). And indeed, it looks like it will work quite well.

The nice thing about moving averages done this way, is that the calculations are trivial: just add the new value in and omit the oldest one. All it takes is an N-stage sample memory, i.e. 31-int array in this case.

But diving a bit deeper into FIR filters, which includes such a moving average as simplest case, it’s clear that I was sampling more than needed. I really don’t need 531 samples to measure the peak-to-peak level of the underlying 50 Hz signal, I just need to measure for the duration of a few 50 Hz cycles (about 3 in the above case).

As it turns out, once you dive in there are many ways to improve things, and lots of online guides and tools.

There’s a lot more to FIR filter design, and there’s an amazing design technique by Parks and McClellan which lets you basically specify what cutoff frequency you want, and what attenuation you you want above a second (higher) frequency. Then I found this site with an easy to use on-line tool for visualizing it and doing all the calculations:

Screen Shot 2011 10 10 at 0 52 23

That’s attenuation on the Y axis vs frequency on the X axis. The gray lines are what I specified as requirement:

Screen Shot 2011 10 10 at 1 08 23

And this is the C code it generated for me:

    /*
    FIR filter designed with http://t-filter.appspot.com

    sampling frequency: 1000 Hz
    fixed point precision: 16 bits

    * 0 Hz - 50 Hz
      gain = 1
      desired ripple = 5 dB
      actual ripple = n/a
    * 100 Hz - 500 Hz
      gain = 0
      desired attenuation = -50 dB
      actual attenuation = n/a
    */

    #define FILTER_LENGTH 31

    int filter[FILTER_LENGTH] = {
      -226,
      -328,
      -486,
      -608,
      -628,
      -474,
      -81,
      595,
      1565,
      2793,
      4194,
      5646,
      7000,
      8103,
      8825,
      9076,
      8825,
      8103,
      7000,
      5646,
      4194,
      2793,
      1565,
      595,
      -81,
      -474,
      -628,
      -608,
      -486,
      -328,
      -226
    };

There’s a drawback in that this is no longer a moving average. Now each output of the filter is defined by applying these integer coefficients to each of the past 31 samples. So there’s more computation involved – a quick test tells me that each sample would take 100..200 µs extra (on an ATmega @ 16 MHz).

But the nice part of this is that it might support a lower-power implementation. Instead of running the ADC 531 times @ 7 KHz (with an unknown filter response), I could run the ADC 100 times, clocked on the 1 ms timer interrupt (and sleeping in between), and apply this modified FIR filter to extract a similar peak-to-peak results.

Why low power? Well, running this on batteries is probably not practical, but I might consider running this setup off a very low-power transformer-less supply. After all, the goal of these experiments is to create a simple low-cost sensor, which can then be used for all the major energy consumers in the house. I’m trying to reduce power consumption, not add yet more to it from all these extra AC current sensors!

Note that maybe none of this will be needed – a simple RC filter before the ADC pin, plus an order 7..31 moving average may well be more than sufficient after all.

But it’s good to know that this option is available if needed. And it’s pretty amazing to see how easily such DSP tasks can be solved, even for someone who has never done any digital signal processing before!


CC-RT: Initial requirements

In AVR, Hardware, Software on Oct 14, 2011 at 00:01

Let’s get going with the CC-RT series and try to define the Reflow Timer in a bit more detail. In fact, let me collect a wish list of things I’d like to see in there:

The Reflow Timer should…

  • support a wide range of ovens, grills, toasters, and skillets
  • be self-contained and safe to build and operate
  • include some buttons and some sort of indicator or display
  • be created with through-hole parts as much as possible
  • (re-) use the same technologies as other JeeLabs products
  • be built on a custom-designed printed circuit board
  • use a convenient and robust mechanical construction
  • be very low-cost and simple to build

To start with that last point: the aim is to stay under € 100 as end-user price, including a simple toaster and whatever else is needed to control it. That’s a fairly limiting goal, BTW.

I’m sticking to “the same technologies” to make my life easy, both in terms of design and to simplify inventory issues later, once the Reflow Timer is in the shop. That translates to: an Arduino-like design with an ATmega328, and (for reasons to be explained next) an RFM12B wireless module.

Safety is a major concern, since controlling a heater tied to 220 V definitely has its risks. My solution to controlling an oven of up to 2000 W is the same as what I’ve been doing so far: use a commercially available and tested power switch, controlled via an RF signal. KAKU or FS20 come to mind, since there is already code to send out the proper signals through an RFM12B module. Range will not be an issue, since presumably everything will be within a meter or so from each other.

With wireless control, we avoid all contact with the mains power line. I’ll take it one step further and make the unit battery-operated as well. There are two reasons for this: if we’re going to uses a thermocouple, then leakage currents and transients can play nasty games with sensors. These issues are gone if there is no galvanic connection to anything else. The second reason is that having the AC mains cable of a power supply running near a very hot object is not a great idea. Besides, I don’t like clutter.

Having said this, I do not want to rule out a couple of alternatives, just in case someone prefers those: controlling the heater via a relay (mechanical or solid-state), and powering the unit from a DC wall wart. So these should be included as options if it’s not too much trouble.

To guard against heat & fire problems, a standard heater will be used with a built-in thermostat. The idea being that you set the built-in thermostat to its maximum value, and then switch the entire unit on and off via the remote switch. Even in the worst scenario where the switch fails to turn off, the thermostat will prevent the heater from exceeding its tested and guaranteed power & heat levels. One consequence of this is that the entire reflow process needs to unfold quickly enough, so that the thermostat doesn’t kick in during normal use. But this is an issue anyway, since reflow profiles need to be quick to avoid damaging sensitive components on the target board.

On the software side, we’ll need some sort of configuration setup, to adjust temperature profiles to leaded / unleaded solder for example, but also to calibrate the unit for a specific heater, since there are big differences.

I don’t think a few LEDs will be enough to handle all these cases, so some sort of display will be required. Since we’ve got the RFM12B on board anyway, one option would be to use a remote setup, but that violates the self-contained requirement (besides, it’d be a lot less convenient). So what remains is a small LCD unit, either character-based or graphics-based. A graphic LCD would be nice because it could display a temperature graph – but I’m not sure it’ll fit in the budget, and to be honest, I think the novelty of it will wear off quickly.

On the input side, 2 or 3 push buttons are probably enough to adjust everything. In day-to-day operation, all you really need is start/stop.

So this is the basic idea for the Reflow Timer so far:

JC s Doodles page 18

Ok, what else. Ah, yes, an enclosure – the eternal Achilles’ heel of every electronics project. I don’t want anything fancy, just something that is robust, making it easy to pick up and operate the unit. I’ve also got a somewhat unusual requirement, which applies to everything in the JeeLabs shop: it has to fit inside a padded envelope.

Enclosures are not something you get to slap on at the end of a project. Well, you could, but then you lose the opportunity of fitting its PCB nicely and getting all the mounting holes in the best position. So let’s try and get that resolved as quickly as possible, right?

Unfortunately, it’s not that easy. We can’t decide on mechanical factors before figuring out exactly what has to be in the box. Every decision is inter-dependent with everything else.

Welcome to the world of agonizing trade-offs, eh, I mean… product design!


New series: Crafted Circuits

In Hardware on Oct 13, 2011 at 00:01

I’m thrilled to announce a new series of posts for this weblog about how to craft, i.e. design and create, an electronic circuit based on all the neat Physical Computing stuff which has been flying across this weblog for several years now.

The purpose of these posts is to present and explain the complete process of producing a working product. It’ll be geared towards people who want to do this themselves, implementing designs of their own invention. Whether as a hobby for personal use, for teaching these skills to others, or to get rich and famous… whatever makes you tick!

Creating a complete product from start to finish is a major undertaking. But it’s also something I’m passionate about, so that’ll help stay on the path to completion. With as reward for me: a new product in the JeeLabs shop.

Cc

What

The product to be created will be a Reflow Timer kit – this is a circuit to control a heater in such a way that it can be used for reflow soldering. Hardware, software, PCB, assembly, enclosure – everything will be addressed.

It’s nothing new or earth-shattering, but it’s an excellent project for this series, because creating your own tools is a great way to extend your own capabilities. I’m all for empowerment. Given that reflow soldering is now within reach of any electronics hobbyist, and since I’ve already written many posts about this topic on the JeeLabs weblog, I feel confident that all the hurdles can be overcome.

And hurdles there will be, I assure you. Because creating a product is quite different from building a working one-off setup. Things like making it work under all sorts of real-world conditions, ease of assembly, repeatability, the availability and suitability of components for hobby use (since this will be a kit). Not to mention the 2,718,281 decisions which need to be taken.

Why

I’m doing this to share what I know and what I’ve learned so far, but also to learn new tools and try out new ideas. So while I’ll stick to several technologies which are already familiar (like the ATmega and RFM12B), you’ll also get to see me start with a new tool and struggle as I learn how to put it to use.

My second reason is to end up with a nice Reflow Timer. I love my prototype, but now I want a real product!

So my motivation is in fact two-fold: to expose the entire process and to end up with a neat new product.

How

While writing down a first outline for this series, it dawned on me just how huge the task might become, so I’m going to try hard and keep things manageable and moving forward. An unfinished product is not a product.

The plan is to create a series of posts (two dozen?) which document different aspects of this process, in the same order in which things get tackled. If you’re interested in reflow control, great – if not, please keep in mind that a lot of this should carry over to whatever electronics project you decide to work on yourself.

Ok, so much for raising expectations. Now let me lower them again to get our feet back on the ground:

I don’t know yet how often I’ll be able to come up with a new post for this series. It will to some degree depend on what sort of issues come up – there’s little point in writing a new post for the sake of continuity, when there’s not enough progress to stay ahead of the game and come up with tangible results.

I’m no “star” EE designer. I haven’t created lots of complex electronic products, and I don’t have sophisticated equipment to analyze tricky problems (neither hardware nor software). What I’ll be describing is what works for me, and what I think any enthusiastic hobbyist with a technical interest can accomplish with limited means.

Knowledge is not a pre-requisite, but something you can pick up along the way. As you’ll see, there’s an amazing amount of stuff you can accomplish nowadays, if you’ve got the interest to dive in and the time to push through.

As always, I welcome all tips, suggestions, and of course corrections. Let’s make this series as good as we can.

And lastly: the entire series will be listed on the Café website. I’ll abbreviate it as “CC-RT” from now on.


AC measurement status

In AVR, Software on Oct 12, 2011 at 00:01

Before messing further with this AC current measurement stuff, let me summarize what my current setup is:

JC s Doodles page 17

Oh, and a debug LED and 3x AA battery pack, which provides 3.3 .. 3.9 V with rechargeable EneLoop batteries.

I don’t expect this to be the definitive circuit, but at least it’s now documented. The code I used on the ATtiny85 is now included as tiny50hz example sketch in the Ports library, eh, I mean JeeLib. Here are the main pieces:

Screen Shot 2011 10 07 at 00 32 58

Nothing fancy, though it took a fair bit of datasheet reading to get all the ADC details set up. This sketch compiles to 3158 bytes of code – lots of room left.

This project isn’t anywhere near finished:

  • I need to add a simple RC low-pass filter for the analog signal
  • readout on an LCD is nice, but a wireless link would be much more useful
  • haven’t thought about how to power this unit (nor added any power-saving code)
  • the ever-recurring question: what (safe!) enclosure to use for such a setup
  • and most important of all: do I really want a direct connection to AC mains?

To follow up on that last note: I think the exact same setup could be used with a current transformer w/ burden resistor. I ought to try that, to compare signal levels and to see how well it handles low-power sensing. The ATtiny’s differential inputs, the 20x programmable gain, and the different AREF options clearly add a lot of flexibility.

Onwards!

Elektro:Camp

In News on Oct 11, 2011 at 00:01

Looks like I’ll be participating in this year’s Elektro:Camp (updated link) coming November 4th and 5th. Not sure what it’s all about and how it’s set up – I’ve never been to a “barcamp-style” meeting – but it seems like a good place to be for anyone in the area and interested in hacking on their energy consumption and automation systems at home:

Elektro camp 2011 10 final

If you’re into this sort of thing, consider joining. It’s bound to be fun, and it’ll be great to meet up in person :)

(Groningen brings up lots of memories, I grew up there – most of my primary school time anyway)

Soooo… see you there?


AC current detection works!

In AVR, Software on Oct 10, 2011 at 00:01

As promised, the results for the ATtiny85 as AC current detector, i.e. measuring current over a 0.1 Ω shunt.

Yesterday’s setup showed the following values in the display:

    30 71-101 68.

From right to left, that translates to:

  • it took 68 ms to capture 500 samples, i.e. about 7 KHz
  • the measured values were in the range 71 .. 101
  • the spread was therefore 30

With a 75 W lamp connected, drawing about 100 mA, I get this:

DSC 2677

With the 25 W lamp, the readout becomes:

DSC 2673

And finally, with a 1 kΩ resistor drawing 20 mA, this is the result:

DSC 2679

As soon as the load is removed, readings drop back to the first values listed above.

Now it seems to me that these readings will be fine for detection. Even a low 20 mA (i.e. 4.4 W @ 220V) load produces a reading with is 30 times higher than zero-load (with about 10% variation over time).

I’m measuring with 2.56V as reference voltage to remain independent of VCC (which is 3.8V on batteries). So each step is 2.5 mV with the built-in 10-bit ADC. With the 20x amplification, that becomes 0.125 mV per ADC step. Now let’s see… a 20 mA DC current across a 0.1 Ω shunt would generate a 2 mV differential. I’m using an order 31 moving average, but I didn’t divide the final result by 31, so that 1099 result is actually 35 on the ADC. Given that one ADC step is 0.125 mV, that’s about 4.4 mV peak-to-peak. Hey, that looks more or less right!

There is still a problem, though. Because half of the time I get this:

DSC 2675

Total breakdown, completely ridiculous values. The other thing that doesn’t look right, is that none of the readings are negative. With a differential amplifier fed with AC, one expects the values and signs to constantly alternate. Maybe I damaged the ATtiny – I’ll get another one for comparison. And maybe I didn’t get the sign-extensions right for the ADC’s “bipolar differential” mode. There’s a lot of bit-fiddling to set all the right register bits.

But still… this looks promising!

Update – Problem solved: it was a signed / unsigned issue. The values are now completely stable with under 1 % variation between measurements. I’m not even filtering out high frequencies, although I know I should.


More sensitivity

In Hardware on Oct 9, 2011 at 00:01

Yesterday’s post was nice, but it stepped over one teeny weeny little detail: the ATmega’s ADC isn’t sensitive enough to measure AC signals in the millivolts range. With a 3.3V reference, each step is ≈ 3.3 mV, while the signals at low power levels are close to a single ADC step. I could bump the sensitivity slightly by using the 1.1V bandgap as ADC reference voltage, but that still only gets me to 1.1 mV steps. Hardly enough to apply filtering to and set thresholds.

Ah, but there’s a way out… (there always is!)

The ATtiny85 is the smaller brother of the ATmega with a frighteningly low pin count of 8. The key is that it has a differential ADC option, i.e. it’s able to measure the voltage between two points (within 0..VCC) and that it has an optional 20 x analog signal amplifier built-in, when used in differential mode. As reference voltage, there is 1.1V, 2.56V, and VCC – providing a couple of ways to tweak the actual range and sensitivity.

Since I had the right ATtiny85 lying around, as well as TinkerLog’s prototyping board, I thought I’d give it a go:

DSC 2678

The problem with an 8-pin chip, of course, is that it only has 5 I/O pins (6 if you’re willing to use the RESET line and lose the ISP programming mode – which I wasn’t). That’s not much to interface with. The ATtiny85 I used has 8 Kb flash and 512 bytes of RAM, so that in itself should be sufficient for all the code I need.

There’s no boot loader. There’s no ready-to-use serial port. And it’s not an Arduino-compatible system, so you can’t just write sketches for it, right?

Not so fast. First of all, there’s the LCD Plug which needs only 2 I/O lines. That leaves me 3 pins: 2 for the differential analog input, and 1 for a debug LED. Plenty!

The LCD needs the Ports library. Which needs the Arduino IDE and runtime. Ah, but there’s more good news: there’s an arduino-tiny project which defines some boards and a set of “core” runtime source files which are intended to run on ATtiny85’s and other non-mega AVR chips. That’s quite a feat, btw, once you consider just how limited an ATtiny85 is (ASCII art by the arduino-tiny project):

                             +-\/-+
    Ain0       (D  5)  PB5  1|    |8   VCC
    Ain3       (D  3)  PB3  2|    |7   PB2  (D  2)  INT0  Ain1
    Ain2       (D  4)  PB4  3|    |6   PB1  (D  1)        pwm1
                       GND  4|    |5   PB0  (D  0)        pwm0
                             +----+

Still, they managed to support a couple of digital and analog I/O pins, with support for the millis() timer, analog in and out, and more. With this installed, I can write sketches and upload them via the AVR-ISP. Pretty amazing!

Sooo… just had to make a few small and obvious tweaks, and the Ports library works. There’s exactly one port (AIO1 = PB2, DIO1 = PB0, IRQ = PB1). Note that I’m using the new Arduino IDE 1.0 (beta).

That leaves me a whopping two pins for the differential analog input, which is what this is all about, after all.

Here’s my setup (hooked up to the safe 20 VAC brick):

DSC 2672

I was too excited to tidy up once the LCD hookup worked. It would all have fitted on a single (mini) breadboard.

Tomorrow, I’ll show you how this crazy little setup measures up…


Moving averages

In Software on Oct 8, 2011 at 00:01

In the comments, Paul H pointed me to a great resource on digital filtering – i.e. this online book: The Scientist & Engineer’s Guide to Digital Signal Processing (1999), by Steven W. Smith. I’ve been reading in it for hours on end, it’s a fantastic source of information for an analog-signal newbie like me.

From chapter 21, it looks like the simplest filtering of all will work just fine: a moving average, i.e. take the average of the N previous data point, and repeat for each point in time.

Time for some simple programming and plotting. Here is the raw data I obtained before in gray, with a moving average of order 349 superimposed as black line (and time-shifted for proper comparison):

O349s1

Note that the data points I’m using were sampled roughly 50,000 times per second, i.e. 1,000 samples for each 50 Hz sine wave. So averaging over 349 data points is bound to dampen the 50 Hz signal a bit as well.

As you can see, all the noise is gone. Perfect!

Why order 349? Because a 349-point average is like a 7-point average every 50 samples. Let me explain… I wanted to see what sort of results I would get when measuring only once every millisecond, i.e. 20 times per sine wave. That’s 50x less than the dataset I’m trying this with, so the 1 ms sampling can easily be simulated by only using every 50th datapoint. To get decent results, I found that an order 7 moving average still sort of works:

O7s50

There’s some aliasing going on here, because the dataset samples aren’t synchronized to the 50 Hz mains frequency. So this is the signal I’d get when measuring every 1 ms, and averaging over the past 7 samples.

For comparison, here’s an order 31 filter sampled at 10 KHz, i.e. one ADC measurement every 100 µs:

O31s5

(order 31 is nice, because 31 x 1023 fits in a 16-bit int without overflow – 1023 being the max ADC readout)

The amplitude is a bit more stable now, i.e. there are less aliasing effects.

Using this last setting as starting point, one idea is to take 500 samples (one every 100 µs), which captures at least two highs and two lows, and to use the difference between the maximum and minimum value as indication of the amount of current flowing. Such a process would take about 50 ms, to be repeated every 5 seconds or so.

A completely different path is to use a digital Chebyshev filter. There’s a nice online calculator for this over here (thx Matthieu W). I specified a 4th order, -3 dB ripple, 50 Hz low-pass setup with 1 KHz sampling, and got this:

Cheb

Very smooth, though I didn’t get the startup right. Very similar amplitude variations, but it needs floating point.

Let me reiterate that my goal is to detect whether an appliance is on or off, not to measure its actual power draw. If this can be implemented, then all that remains to be done is to decide on a proper threshold value for signaling.

My conclusion at this point is: a simple moving average should be fine to extract the 50 Hz “sine-ish” wave.

Update – if you’re serious about diving into DSP techniques, then I suggest first reading The Scientist & Engineer’s Guide to Digital Signal Processing (1999), by Steven W. Smith, and then Understanding Digital Signal Processing (2010) by Richard G Lyons. This combination worked extremely well for me – the first puts everything in context, while the second provides a solid foundation to back it all up.


iPad oscilloscope

In Hardware on Oct 7, 2011 at 00:01

While exploring the different ways to get to grips with the 50 Hz AC signal, I stumbled on video about oScope, an app for iPad and iPhone. It’s just €3.99, and samples with 16 bit @ 48 KHz.

It works via the audio input, which is a decent A/D converter for signals in the audio range. The neat bit is that it can also get its input via a USB audio adapter hooked up using the iPad’s camera adapter kit. And I happened to have all the required bits lying around:

DSC 2671

Woohoo – instant scope!

The horizontal and vertical are set with pinch-and-zoom, and the scale displays in the top left corner. Likewise, setting the trigger you just drag the red trigger line up or down.

Here’s a screen shot:

IMG 0045

(it doesn’t quite come out at reduced size, but on-screen it’s gorgeous)

There’s also what appears to be an FFT power spectrum:

IMG 0044

There’s also a (more expensive) app from ONYX Apps which can sample both audio channels and has a convenient auto-set mode (but no FFT):

IMG 0046

The problem I have with all this is that the noise in my signal is gone. These samples were taken from the same 0.1 Ω shunt setup as in the previous days, so I’m not quite sure why the amplitude is different and why the signal is so noise-free. Perhaps there is some signal processing going in in the iPad.

But a real scope based on touch screen controls and such a large display sure would be phenomenal!

Captured samples

In Software on Oct 6, 2011 at 00:01

With the USB scope hookup from yesterday’s post it’s also quite easy to capture data for further experiments. It helps to have a fixed data set while comparing algorithms, so I used the DSO-2090 software again to capture over a million 8-bit samples.

The dump is binary data, but decoding the format is trivial. Some header bytes and then each value as 2-byte int. Just to show that JeeMon is also up to tasks like this, here’s the “rec2text.tcl” script I created for it:

Screen Shot 2011 10 04 at 17 13 47

And this is how it was used to generate a text file for the plots below:

Screen Shot 2011 10 04 at 16 43 09

(silly me – I’m still impressed when I see a script process over a million items in the blink of an eye…)

That’s a bit too much data for quick tests, but here are the first 10,000 values from the 75W-bulb-on-20-VAC:

Screen Shot 2011 10 04 at 15 28 12

There’s quite a bit of noise in there if you look more closely:

Screen Shot 2011 10 04 at 15 33 20

The measurements are all over the map, with values over almost the entire 0..255 range of the scope’s 8-bit ADC. The actual spikes are probably even larger, occasionally.

I hope that this is a decent dataset to test out filtering and DSP techniques. It’ll be much quicker to try things out on my Mac than on a lowly ATmega 8-bit MPU, and since both can run the same C & C++ code, it should be easy to bring things back over to the ATmega once it it does the right thing.

Hmmm… now where do I find suitable DSP filtering algorithms and coefficients?

Update – Found a great resource, thx Paul & Andreas. Stay tuned…

Back to basics

In Hardware on Oct 5, 2011 at 00:01

After all this messing around with 220V, and none of it working out so well, it’s time to simplify. I had a 17 VAC transformer lying around, so I decided to first get rid of all that risk. The goal remains the same: trying to reliably determine whether a low-wattage appliance is on or off. Here’s what I’m going to use:

DSC 2664

That’s a 75W lightbulb, hooked up to that AC power supply. It’s drawing 100 mA, as you can see. Unloaded, the voltage is a bit higher (as usual with transformers) – bit still harmless to experiment with:

DSC 2667

So now I can go back to a more convenient setup, and measure directly:

DSC 2668

Note that the light bulb is not on, but it does get hot to the touch. It’s still generating 20 V x 0.1 A = 2 Watts of heat, after all. Except that in this case the heat only rises, so it’s just the top of the light bulb which heats up.

It’s pretty odd that this draws only 3x as much current at 220V as at 20V. The reason for that is that the resistance of a lightbulb filament increases considerably when glowing. When a light bulb is turned on, it creates a “cold surge” which heats it up – at which point it’ll start drawing less current – a light bulb is a NTC PTC resistor!

Good, now we’re cookin’ again. I can hook up the USB scope at last:

Screen Shot 2011 10 04 at 14 19 58

Oooh… if that’s similar to the signal I’ve been measuring so far, then no wonder my amplitude algorithm was bad. Yikes… this thing is full of noise and spikes!

There are some nice features in the DSO-2090 software. Here’s the same waveform averaged over 128 scans:

Screen Shot 2011 10 04 at 14 43 22

Which shows that the signal indeed has non-repetitive noise superimposed on it.

Here’s something interesting. The purple line is an FFT spectrum analysis (the input signal was resized/moved):

Screen Shot 2011 10 04 at 14 26 40

There’s one spike in that spectrum. No idea what it is, but I bet that’s what’s messing up the sine wave.

Good. At least these different readings are consistent.

Capturing (no go) – part 2

In Software on Oct 4, 2011 at 00:01

On to the next step in capturing samples from the direct 220V connection.

First, let me clarify why I called the first sketch “fatally flawed” – because it is, literally! The sketch required a button press to get started, a big no-no while hooked up to AC mains (isolated or not, I won’t touch it!).

The other problem I didn’t like after all, is that the sampling was taking place in burst, saving to the Memory Plug in between – which takes several milliseconds each time. That doesn’t produce a nice stream of equally-spaced ADC measurements.

So instead, I decided to redo the whole sketch and split it into two separate sketches in fact. One fills the EEPROM on the Memory plug, the other dumps it to the serial port. No more buttons or LEDs. Just a JeeNode with a Memory Plug. To make things work, a fairly peculiar series of steps has to be taken:

  • upload the “saveToMem” sketch and plug in the Memory Plug
  • disconnect, and hook up to the 0.1 Ω shunt etc (with power disconnected)
  • insert AA battery to power the whole thing, it starts collecting
  • turn on AC power
  • let it run for a few seconds
  • turn off AC power
  • disconnect, remove the battery and Memory Plug, and reattach to USB
  • upload the “saveFromMem” sketch
  • open serial monitor and capture the dump to file (with copy & paste)

The key is to remove the Memory Plug as soon as it has been filled, so that the next power-up doesn’t start filling it all over again. There’s logic in the sketches to do nothing without Memory Plug.

Note that the internal ATmega EEPROM is also used to record how far the save has progressed (in units of 128 samples, i.e. 256 bytes).

It turns out that the writes to EEPROM via I2C take quite a bit of time. I settled on a 1 KHz sampling rate to avoid running into any timing issues. That’s 20 samples per 50 Hz cycle, which should be plenty to reliably identify that frequency even if its not a pure sine wave. The samples will tell.

Ok, first test run, nothing powered up. Result is mostly 511’s and a few 510’s, which is as expected – halfway the 0..1023 range:

    $ grep -n 510 unplugged.txt |wc
         115     115    1062
    $ grep -n 511 unplugged.txt |wc
       14605   14605  135044
    $

Next run is with the 60 W light bulb turned on a few seconds after sampling starts.

Whoops, not so good – I’m only getting 510, 511, and 512 readings, almost nothing else!

    $ grep -n 509 powered.txt |wc
           0       0       0
    $ grep -n 510 powered.txt |wc
         110     110    1012
    $ grep -n 511 powered.txt |wc
       13750   13750  126668
    $ grep -n 512 powered.txt |wc
         220     220    2026
    $ grep -n 513 powered.txt |wc
           0       0       0
    $ wc powered.txt 
       14084   14086   56366 powered.txt
    $

My conclusion so far is: can’t detect these small AC signals without additional amplification, it’s simply too weak.

It’s not really a setback, since I wasn’t planning on creating a directly-connected JeeNode setup as official solution, but it would have been nice to get a basic detection working with just a few resistors.

Maybe there’s an error in these sketches, but I’ve verified that the input senses ground as 0 and VCC as 1023, so that part at least is working as expected. I’ve placed the two sketches as a “gist” on GitHub, for reference (sampleToMem and sampleFromMem).

Back to the drawing board!

Dabbling in HTML5 + CSS3

In Software on Oct 3, 2011 at 00:01

(Small change of plans, the continuation of yesterday’s post has been postponed to tomorrow)

I’ve been tipping my toes a bit in the waters of HTML5 + CSS3. Nothing spectacular, but here’s what came out:

Screen Shot 2011 10 02 at 22 59 24

Small “widgets” to display home readings on a web page (it’s in Dutch… but you can probably guess most of it).

There are no colors in here yet, but hey… just visit a site such as the Color Scheme Designer to fix that.

Here are the CSS styles I used:

Screen Shot 2011 10 02 at 22 20 27

And here is the funky code I used to generate the HTML for this in JeeMon:

Screen Shot 2011 10 02 at 22 20 59

It’s still a bit awkward to generate elements which need to be combined inline, i.e. <span> elements.

To see the actual generated HTML, use your browser to check the page source of the new Widgets page at http://jeelabs.org/tools/. To examine the entire file needed to generate this from JeeMon, click on this link.

For actual use, all I’ll need to change is: 1) generate the HTML with $blah Tcl variables, or 2) use JavaScript on the browser to fill in the values (driven by Server Sent Events, for example). The latter avoids page refreshes.

The separation of content, structure, and style has come a long way since the early days of HTML. It just feels right, the way this works out. Applications can be written with nearly complete independence between, eh… “looks” and “guts”. Even complete page make-overs which are well beyond the positioning capabilities of CSS can be taken care of with basic templating on the server side. It’s interesting that the elaborate and efficient templating “engines” which used to drive dynamic websites and which are still used in many frameworks are becoming irrelevant. With a bit of JavaScript smarts on the client side, the server now only needs to serve static files plus JSON data for REST-style Ajax calls. The good news for embedded home automation systems, is that very low-end servers may well turn out to be sufficient, even for sophisticated web presentations.

As I said, nothing spectacular, but I’m delighted to see how simple and cleanly-structured all this has become.


Capturing some test data

In Software on Oct 2, 2011 at 00:01

(Whoops, looks like I messed up the correct scheduling of this post!)

Coming soon: a bit of filtering to get better AC current readouts.

There are many ways to do this, but I wanted to capture some test measurements from the AC shunt first, to follow up on the 220V scope test the other day. That way I don’t have to constantly get involved with AC mains, and I’ll have a repeatable dataset to test different algorithms on. Trouble is, I want to sample faster and more data than I can get out over wireless. And a direct connection to AC mains is out of the question, as before.

Time to put some JeePlugs from my large pile to use:

DSC_2661.jpg

That’s a 128 Kbyte Memory Plug and a Blink Plug. The idea is to start sampling at high speed and store it in the EEPROM of the Memory Plug, then power off the whole thing, connect it to a BUB and press a button to dump the saved data over the serial USB link.

Here’s the sketch I have in mind:

Screen Shot 2011-10-02 at 01.31.52.png

Note that saving to I2C EEPROM takes time as well, so there will be gaps in the measurement cycle with this setup. Which is why I’m sampling in bursts of 512. If that doesn’t give me good enough readings, I’ll switch to an interrupt driven mechanism to do the sampling.

Hm… there’s a fatal flaw in there. I’ll fix that and report the results tomorrow.

Time for a new mousetrap

In Hardware on Oct 1, 2011 at 00:01

It’s been a while. In December 2008, I posted about my setup for detecting the rotation of my electricity and gas meters. This was before the JeeNode even existed. It was built with an RBBB plus RFM12B with voltage dividers.

That setup has been running ever since, probably sending over a million packets around the airwaves here at JeeLabs. But it’s getting a bit old – and it’s still that dangling mess of wires. Besides, I’d really like to get a more up-to-date setup going: the current unit is still using the old v1 RF12 protocol, so it needs a specially-built receiver to pick up the packets. Then again, I don’t want to replace it before there is a sufficiently stable alternative.

First thing I did quite a while back was to get an extra electricity meter, if only to avoid the constant runs up and down the stairs. That way I can hook up a scope, and try things at my leisure:

DSC 2659

I also wanted to experiment with different sensors, so I tried the GP2S700HCP, which is a tiny SMD device:

DSC 2660

Unfortunately, the range is a bit low -it’s specified as 0.5 .. 5.5 mm. That translates to a fairly weak signal:

Screen shot 2011 06 29 at 02 16 43

About 150 mV swing on a 1.8 V signal, it seems. Hm… I might go for the venerable CNY70 after all. That’s the sensor most people seem to be using. I was hoping to find something smaller, because it would be easier to create a mounting solution for it.

Even better would be to try and detect the irregularities around the entire Ferraris wheel, and perhaps also to detect variations on the digits of the gas meter.

More tinkering needed…