Computing stuff tied to the physical world

Search for “KAKU”

TD – KAKU remote switch

In Hardware on Mar 13, 2012 at 00:01

Welcome to the Tuesday Teardown series, about looking inside the technology around us.

Today’s episode is about the “KlikAanKlikUit” remotely controlled AC mains switches, a.k.a. KAKU.

I’m going to look at two different units, the older/smaller/cheaper PAR-1000 supporting 16 different addresses, and the newer YC-3500 supporting up to 256 different addresses and switching up to 3500W:

DSC 2956   DSC 2955

Here’s the PAR-1000, once opened (you need a TX9 torque screwdriver for both units):

DSC 2957

There’s a .22 µF X2 cap as transformer-less power supply, in series with a 100 Ω resistor (hidden in black heat shrink tubing, bottom right, next to it). According to this calculator, you can get up to 12.2 mA out of that, when using a bridge rectifier (which is under the cap, using discrete 1N4007 diodes).

The measured power consumption is 0.58 W. Note that due to the way these transformer-less power supplies work, this power is always consumed, whether the relay is turned on or not.

There’s an interesting post-production “mod” in this unit, on the relay, i.e. top middle in the above image. After removing the tiewrap and glue, this interesting part emerges – in series with AC mains:

DSC 2960

I’m guessing some sort of overheating protection for the relay, a PTC resistor?

Here’s the copper-side of the PAR-1000’s PCB, with what looks like lots of solder flux residue:

DSC 2959

And here’s the YC-3500, in a slightly larger enclosure and using a relay which can switch up to 16A:

DSC 2958

Same 100 Ω resistor but beefier 0.33 µF X2 cap, bringing the maximum current to 18.2 mA. Measured power consumption is 0.81 W – what a waste for an always-on device which is merely switching another device!

Here’s the underside of the YC-3500’s PCB:

DSC 2961

Both single-sided non-epoxy PCB’s have SMD’s on one side and through-hole parts on the other, but the amount of solder on the SMD side suggests to me that everything has either been soldered on by hand or glued on and wave-soldered. The extra solder on the left increases the PCB’s current carrying capacity, BTW.

These 433 MHz units respond to simple packets using the On-Off-Keying (OOK) protocol. There’s no way to control them directly, other than via RF – and even if there were, there would be no way for a home automation system to know their state since these units are receive-only. The relay is off after power loss. There’s an LED to indicate the actual on/off state. The choice of 24V relays is wise – needs much less current than 5V and 12V ones.

Note the 433 MHz antenna – a single loop of copper wire in one case, and a loop plus coil in the other!

Decoding 433 MHz KAKU signals

In AVR, Software on Mar 10, 2009 at 00:01

Here is a simple OOK receiver, hooked up to AIO port 3:

Decoding 433 MHz KAKU signals

The following interrupt-driven code will pick up signals from a “KlikAanKlikUit” remote control:

Picture 1.png

It should be relatively easy to adapt this to other units. Signals in different protocols can be decoded at the same time, since all decoding state is maintained in a separate state machine.

Sample output:

Picture 2.png

The KAKU units use a very crude signalling protocol, with no error checking other than sending a distinct bit pattern for 0’s and 1’s. The sample output has errors, in fact: the B7 after the B6 should have been a B6. It is probably best to only accept commands when they come in more than once in quick succession.

There can be quite a bit of noise from the receiver, in the form of random pulses. These will be ignored, but it may use up some CPU power to service all the corresponding interrupts.

The key-value straightjacket

In Musings, Software on Jan 5, 2013 at 00:01

It’s probably me, but I’m having a hard time dealing with data as arrays and hashes…

Here’s what you get in just about every programming language nowadays:

  • variables (which is simply keyed access by name)
  • simple scalars, such as ints, floats, and strings
  • indexed aggregation, i.e. arrays: blah[index]
  • tagged aggregation, i.e. structs: blah.property
  • arbitrarily nested combinations of the above

JavaScript structs are called objects and tag access can be blah.tag or blah['tag'].

It would seem that these are all one would need, but I find it quite limiting.

Simple example: I have a set of “drivers” (JavaScript modules), implementing all sorts of functionality. Some of these need only be set up once, so the basic module mechanism works just fine: require "blah" can give me access to the driver as an object.

But others really act like classes (prototypal or otherwise), i.e. there’s a driver to open a serial port and manage incoming and outgoing packets from say a JeeLink running the RF12demo sketch. There can be more than one of these at the same time, which is also indicated by the fact that the driver needs a “serial port” argument to be used.

Each of these serial port interfaces has a certain amount of configuration (the RF12 band/group settings, for example), so it really is a good idea to implement this as objects with some state in them. Each serial port ends up as a derived instance of EventEmitter, with raw packets flowing through it, in both directions: incoming and outgoing.

Then there are packet decoders, to make sense of the bytes coming from room nodes, the OOK relay, and so on. Again, these are modules, but it’s not so clear whether a single decoder object should decode all packets on any attached JeeLink or whether there should be one “decoder object” per serial interface object. Separate objects allow more smarts, because decoders can then keep per-sensor state.

The OOK relay in turn, receives (‘multiplexes”) data from different nodes (and different types of nodes), so this again leads to a bunch of decoders, each for a specific type of OOK transmitter (KAKU, FS20, weather, etc).

As you can see, there’s sort of a tree involved – taking incoming packet data and dissecting / passing it on to more specific decoders. In itself, this is no problem at all – it can all be represented as nested driver objects.

As final step, the different decoders can all publish their readings to a common EventEmitter, which will act as a simple bus. Same as an MQTT broker with channels, with the same “nested key” strings to identify each reading.

So far so good. But that’s such a tiny piece of the puzzle, really.

Complexity sets in once you start to think about setup and teardown of this whole setup at run time (i.e. configuration in the browser).

Each driver object may need some configuration settings (the serial port name for the RF12demo driver was one example). To create a user interface and expose it all in the browser, I need some way of treating drivers as a generic collection, independent of their nesting during the decoding process.

Let’s call the driver modules “interfaces” for now, i.e. in essence the classes from which driver instances can be created. Then the “drivers” become instantiations of these classes, i.e. the objects which actually do the work of connecting, reading, writing, decoding, etc.

One essential difference is that the list of interfaces is flat, whereas a configured system with lots of drivers running is often a tree, to cope with the gradual decoding task described a bit above.

How do I find all the active drivers of a specific interface? Walk the driver tree? Yuck.

Given an driver object, how do I find out where it sits in the tree? Store path lists? Yuck.

Again, it may well be me, but I’m used to dealing with data structures in a non-redundant way. The more you link and cross-link stuff (let alone make copies), the more hassles you run into when adding, removing, or altering things. I’m trying to avoid “administrative code” which only keeps some redundant invariants intact – as much as possible, anyway.

Aren’t data structures supposed to be about keeping each fact in exactly one place?

PS. My terminology is still a mess in flux: interfaces, drivers, devices, etc…

Update – I should probably add that my troubles all seem to come from trying to maintain accurate object identities between clients and server.

Reporting serial packets

In Software on Oct 16, 2012 at 00:01

The RF12demo sketch was originally intended to be just that: a demo, pre-flashed on all JeeNodes to provide an easy way to try out wireless communication. That’s how it all started out over 3 years ago.

But that’s not where things ended. I’ve been using RF12demo as main sketch for all “central receive nodes” I’ve been working with here. It has a simple command-line parser to configure the RF12 driver, there’s a way to send out packets, and it reports all incoming packets – so basically it does everything needed:

  [RF12demo.8] A i1* g5 @ 868 MHz 
  DF I 577 10

  Available commands:
    <nn> i     - set node ID (standard node ids are 1..26)
                 (or enter an uppercase 'A'..'Z' to set id)
    <n> b      - set MHz band (4 = 433, 8 = 868, 9 = 915)
    <nnn> g    - set network group (RFM12 only allows 212, 0 = any)
    <n> c      - set collect mode (advanced, normally 0)
    t          - broadcast max-size test packet, with ack
    ...,<nn> a - send data packet to node <nn>, with ack
    ...,<nn> s - send data packet to node <nn>, no ack
    <n> l      - turn activity LED on PB1 on or off
    <n> q      - set quiet mode (1 = don't report bad packets)
  Remote control commands:
    <hchi>,<hclo>,<addr>,<cmd> f     - FS20 command (868 MHz)
    <addr>,<dev>,<on> k              - KAKU command (433 MHz)
  Flash storage (JeeLink only):
    d                                - dump all log markers
    <sh>,<sl>,<t3>,<t2>,<t1>,<t0> r  - replay from specified marker
    123,<bhi>,<blo> e                - erase 4K block
    12,34 w                          - wipe entire flash memory
  Current configuration:
   A i1* g5 @ 868 MHz

This works fine, but now I’d like to explore a real “over-the-wire” protocol, using the new EmBencode library. The idea is to send “messages” over the serial line in both directions, with named “commands” and “events” going to and from the attached JeeNode or JeeLink. It won’t be convenient for manual use, but should simplify things when the host side is a computer running some software “driver” for this setup.

Here’s the first version of a new rf12cmd sketch, which reports all incoming packets:

Screen Shot 2012 10 14 at 15 31 51

Couple of observations about this sketch:

  • we can no longer send a plain text “[rf12cmd]” greeting, that too is now sent as packet
  • the greeting includes the sketch name and version, but also the decoder’s packet buffer size, so that the other side knows the maximum packet size it may use
  • invalid packets are discarded, we’re using a fixed frequency band and group for now
  • command/event names are short – let’s not waste bandwidth or string memory here
  • I’ve bumped the serial line speed to 115200 baud to speed up data transfers a bit
  • there’s no provision (yet) for detecting serial buffer overruns or other serial link errors
  • incoming data is sent as a binary string, no more tedious hex/byte conversions
  • each packet includes the frequency band and netgroup, so the exchange is state-less

The real change is that all communication is now intended for computers instead of us biological life-forms and as a consequence some of the design choices have changed to better match this context.

Tomorrow, I’ll describe a little Lua script to pick up these “serial packets”.

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: 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!

Playing with indentation

In Software on Sep 9, 2011 at 00:01

Bear with me – this isn’t directly related to Physical Computing, but I’ve been having fun with some code.

If you’ve ever written any web apps or designed a web site, chances are that you’ve also written some HTML, or at least HTML templates. Stuff like this, perhaps:

    <!DOCTYPE html>
    <html>
      <head>
        <meta charset='utf-8' />
        <title>Flot graph demo</title>
        <script type='text/javascript' src='.../jquery.flot.js'></script>
        <script type='text/javascript'>
          $(function(){ ... });
        </script>
        <style type='text/css'>
          #placeholder { width: 600px; height: 300px; }
        </style>
      </head>
      <body>
        <div id='placeholder'></div>
      </body>
    </html>

Well, I’m getting a bit tired of all this nesting. The essence of it is buried far too deeply inside what I consider line noise. There are currently a number of developments related to HTML, CSS, and JavaScript which might change this sort of development considerably. Much of it seems to be driven by the Ruby and Rails community, BTW.

Some examples: for HTML, there is Haml. For CSS, there is Sass. And for JavaScript there is CoffeeScript.

All of these have in common (along with Python and YAML) that they treat indentation as a significant part of the notation. Before you raise an eyebrow: I know that the opinions on this are all over the map. So be it.

I wanted to try this with JeeMon, so after a bit of coding, I ended up with a “Significant Indentation Formatter” and then applied that to HTML. Here’s the above, re-written in a HAML-like notation:

    !html
      head
        meta/charset=utf-8
        title: Flot graph demo
        script/type=text/javascript/src=.../jquery.flot.js
        script/type=text/javascript
          $(function(){ ... });
        style/type=text/css
          #placeholder { width: 600px; height: 300px; }
      body>#placeholder

It generates the same HTML as above, but there’s less to write. Even less in fact, because I’ve also integrated it with JeeMon’s templating system:

    !html
      head
        meta/charset=utf-8
        title: Flot graph demo
        [JScript includes flot]
        [JScript wrap $js]
        [JScript style { #placeholder { width: 600px; height: 300px; } }]
      body>#placeholder

Here’s a slightly more elaborate KAKU send example which illustrates basic template looping:

    !html
      head
        meta/charset=utf-8
        title: KAKU send
        [JScript includes ui]
        [JScript wrap $js]
      body
        % foreach x {1 2 3 4}
          p.toggles
            button#on$x: On $x
            button#off$x: Off $x
        p#group
          label: Group:
          % foreach x {I II III IV}
            input#g$x/type=radio/name=g/value=$x
            label/for=g$x: $x
        p
          label: House Code:
          select
          % foreach x {A B C D E F G H I J K L M N O P}
            option/value=$x: $x

So far, this system doesn’t use standard conventions, is undocumented, hasn’t been used in anger or proven itself to handle more complex layouts, has almost no error handling, and has only been used by yours truly for a few hours. Still, I’ve adjusted all the examples in JeeRev to gain a bit more experience with this approach.

I like it. The above is pretty close to how I want to design the structures and sections of a web page.

IR pulse pickup

In Hardware, Software on Oct 11, 2010 at 00:01

With the sending of IR pulses out of the way, the next step is picking them up. That’s a lot simpler since there are various sensors which do this.

But unfortunately I only have a QSC113 IR photo transistor at hand right now. It doesn’t have any sort of 38 kHz filtering, it just senses IR light. Then again, it still seems to work – I don’t understand why, to be honest:

Dsc 2123

Anyway, this seemed like a good test case to throw at the OOK Scope. The name is a bit confusing actually – it was used to analyze OOK-encoded radio signals a couple of months ago, but it’s really more general than that. What the OOK Scope does, is create a histogram of incoming pulse widths (20 .. 4604 µs with the current code).

As a refresher, here’s some OOK Scope output with a 433 MHz radio attached, after pressing buttons on my KAKU remote control:

Screen Shot 2010 10 10 at 22.06.54

The histogram runs sideways: at the top are the short pulses, at the bottom the long pulses. The longer the bar, the more pulses of that length have been picked up.

Now the fun part is that this same setup can also be used for IR pulses:

Dsc 2122

I simply replaced the OOK radio in port 2 by my IR photo transistor, with the short lead to GND and the long lead to AIO2. Here’s what comes out when using the Apple remote:

Screen Shot 2010 10 10 at 22.47.36

The pulses are a lot sharper, which is not surprising since it’s picking up direct light pulses now, not radiomagnetic waves of a much lower frequency and intensity that has to be detected and converted into an electrical signal by the radio.

Reading these values is a bit more work, because the ookScope.pde does some trickery to increase the range of pulse widths it can report in a single byte:

if (width >= 128) {
    width = (width >> 1) + 64;
    if (width >= 192) {
        width = (width >> 1) + 96;
        if (width >= 224) {
            width = (width >> 1) + 112;
            if (width >= 240) {
                width = (width >> 1) + 120;
                if (width >= 248) {
                    width = (width >> 1) + 124;
                    if (width >= 252) {
                        width = (width >> 1) + 126;
                        if (width > 255)
                            width = 255;
                    }
                }
            }
        }
    }
}

See the OOK Scope post for details on how this works.

Back to the readings. The values reported are two strong bands centered around ≈ 105 and 158, respectively, with another set of pulses at 224. The pulse widths corresponding to these are ≈ 420 µs, 652 µs, and 1536 µs if I got my calculations right. That last one might be the time between retransmissions.

I’ll have to revisit this with a real 38 kHz filtering IR sensor when I get them in – but that sort of looks right to me. Another remote sending out RC5 codes ended up with very similar pulse widths, but with more variation.

Tomorrow, I’ll describe the OOK Scope setup in more detail, since it doesn’t seem to be working for everyone…

Update – I just figured out the pinout of a 5V sensor with IR filtering (TSOP1138) – here’s what comes out:

Screen Shot 2010 10 10 at 23.32.07

Hm, more variation now. Then again, also a lot more sensitive, it seems. And it looks like it should still be possible to discriminate between the two pulse widths at position 135, i.e. around 568 µs.

The pulse trains are now more consistent on the scope:

Dsc 2124

Note that I’m driving the JeeNode I/O pin to nearly 5V, which isn’t really such a good idea…

PS. That’ a DSO Nano scope, in case you’re wondering…

(Not so) Home Easy

In Software on Apr 23, 2010 at 00:01

Here’s the Elro / Home Easy AB440R remote control:

Dsc 1351

On the surface, it looks like a very clean 433 MHz protocol:

Screen Shot 2010 04 17 at 12.16.22

Here are some bit patterns, as I see them coming in:

Screen Shot 2010 04 17 at 12.15.26

All the pulse widths are in the expected range (first two are timestamp and pulse count):

Screen Shot 2010 04 17 at 12.38.38

This is completely in line with the protocol description I found. Given that it uses a special 0-0 pattern for extended group codes, I decided to pass all the transitions back, leaving the interpretation to higher-level code:

Screen Shot 2010 04 17 at 12.31.28

Here’s what comes out:

Screen Shot 2010 04 17 at 12.30.50

Several very odd problems with this:

  • the incoming bit patterns are less than 50 bits
  • the KAKU decoder also matches these patterns
  • I’m getting spurious empty lines reported

The KAKU decoder match is very surprising, since it only fires when receiving exactly 12 bits! As it turns out, the other way leads to false positives as well: the KAKU transmitter currently triggers the HEZ decoder – but that’s more logical, since the HEZ decoder isn’t checking exact packet sizes yet.

Something very fishy is going on, but I can’t see where :( – despite this, I’ve updated the code.

Oh well, can’t win ‘em all…

Oregon sensors

In Software on Apr 15, 2010 at 00:01

Let’s try to decode the OOK data coming from an Oregon Scientific THGR810 sensor:

Dsc 1340

It sends at 433 MHz (the above picture was accidentally set to Fahrenheit). I used the OOK scope to figure out which pulse widths to use in the decoder. Ended up splitting pulses shorter and longer than 700 µs.

Anyway, now I can write a bit-decoder for it, using the same finite state machine approach I’ve used before for KAKU and FS20. But there’s one difference: these bits are Manchester encoded, i.e. 0 has two short pulses, while 1 is one long pulse. The Manchester encoding can be deduced from the fact that when you replace two short pulses my one marker, you get more or less consistent packet lengths. Since successive 1’s must flip the interpretation of the signal, there’s one extra bit of state to carry around in the decoder.

Most of these things can be determined by trial and error. Same for the synchronization pattern, the exact bit offset to start the data, and the bit / nibble / byte order of the data.

It helps tremendously that the sensor has an LCD display, showing what values it is transmitting, of course.

My basic approach is to collect lots and lots of pulses, and save them to file as Tcl scripts. Then I weed out impossible runs of bits, keeping only what looks like potential 0/1 sequences of a decent length. Then just keep collecting, until some “packets” end up being received more than once.

Once I have a dozen or more packets which keep showing up, it’s time to look at the preamble, to try and figure out what the common prefix could be. It’s usually pretty obvious by then. The only uncertainty being at which bit the preamble stops and the actual data starts.

Anyway, for the THGR810, this is some of the data I ended up receiving:

Screen Shot 2010 04 12 at 17.43.19

If you look closely, you can already see the reported values in reverse hex in the data.

That’s it!

Here’s the main part of the decoding logic for this sensor:

Screen Shot 2010 04 13 at 16.11.39

And here’s the received data:

Screen Shot 2010 04 12 at 12.18.44

The last value is the seconds timer, showing that this sensor is reporting values roughly every 70..90 seconds. I did some resets and fiddled with the channel switches, to be able to later determine which bits they correlate to.

Another run, showing the temperature dropping from 21.1° ro 20.1°:

Screen Shot 2010 04 13 at 00.37.49

Will do the checksums and separation into readings in JeeMon … another time!

Secure transmissions

In Software on Feb 23, 2010 at 00:01

For some time, I’ve been thinking about adding optional encryption to the RF12 wireless driver. I’ll leave it to the cryptography experts to give hard guarantees about the resulting security of such a system…

The basic goal is to provide a mechanism which lets me get messages across with a high level of confidence that an outsider cannot successfully do the same.

The main weakness which most home automation systems such as FS20 and KAKU completely fail to address is message replay. The “house code” used by FS20 has 16 bits and the address has 8 bits, with the naive conclusion being that it takes millions of attempts to send out messages to which my devices respond. Unfortunately, that’s a huge fallacy: all you have to do is sit outside the house for a while, eaves-dropping on the radio packets, and once you’ve got them, you’ve figured out the house code(s) and adresses in use…

I don’t care too much about people picking up signals which turn the lights on or close the curtains. You don’t need technology to see those events from outside the house anyway. I do care about controlling more important things, such as a server or a door opener.

Here are my design choices for optional encryption in the RF12 driver:

  • The cipher used is David Wheeler’s XXTEA, which takes under 2 Kb of code.
  • The keys are 128 bits, they have to be stored in EEPROM on all nodes involved.
  • All nodes in the same net group will use either no encryption or a shared encryption key.
  • A sequence number of 6, 14, 22, or 30 bits is added to each packet.

To start with the latter: XXTEA requires padding of packets to a multiple of 4 bytes. What I’ve done is add the sequence number at the end, using as many bytes as needed to pad to the proper length, with 2 bits to indicate the sequence number size. Encrypted packets must be 4..62 bytes long. It’s up to the sender to decide what size packets to send out, and implicitly how many bits of the sequence number to include. Each new transmission bumps the sequence number.

To enable encryption, call the new rf12_encrypt() function with a pointer to the 16-byte key (in EEPROM):

Screen shot 2010-02-21 at 18.37.36.png

Encryption will then be transparently applied to both sending and receiving sides. This mechanism also works in combination with the easy transmission functions. To disable encryption, pass a null pointer instead.

The received sequence number is available as a new “rf12_seq” global variable. It is up to the receiver (or in the case of acks: the originator) to ascertain that the sequence number is in the proper range. Bogus transmissions will decrypt to an inappropriate sequence number. To make absolutely certain that the packet is from a trusted source, include some known / fixed bytes – these will only be correct if the proper encryption key was used.

This new functionality has been implemented in such a way that the extra code is only included in your sketch if you actually have a call to rf12_encrypt(). Without it, the RF12 driver still adds less than 3 Kb overhead.

I’ve added two sample sketches called “crypSend” and “crypRecv” to the RF12 library. The test code sends packets with 4..14 bytes of data, containing “ABC 0123456789″ (truncated to the proper length). The receiving end alternates between receiving in encrypted mode for 10 packets, then plaintext for another 10, etc:

Screen shot 2010-02-21 at 22.42.27.png

As expected, the encrypted packets look like gibberish and are always padded to multiples of 4 bytes. Note also that the received sequence number is only 6 bits on every 4th packet, when the packet size allows for only one byte padding. The strongest protection against replay attacks will be obtained by sending packets which are precisely a multiple of 4 bytes (with a 30-bit sequence number included in the 4 bytes added for padding).

So this should provide a fair amount of protection for scenarios that need it. Onwards!

OOK reception with RFM12B ?

In AVR, Software on Dec 25, 2009 at 00:01

Yesterday’s post described a setup to see the RSSI and DQD status bit reported by the RF12 driver in real time.

One of the interesting results is that I can see the RSSI light come on when pressing a button on the FS20 remote transmitter – even though that’s an OOK signal, not FSK!

When adjusted to run at 433 MHz, the RSSI indicator also lights up with the KAKU remote.

In both cases, the DQD signal appears useless – it just shimmers all the time.

The RSSI signal is encouraging, though. It turns out that getting it to blink reliably did depend on setting the threshold right. At -103 and -97 dBm, it was on all the time – only the -91 dBm value produced a usable signal. I hope that’s the case with all units.

Could this be used to receive FS20 or KAKU?

Well, I just had to try. My idea was to continuously poll the RSSI status bit and then “mirror” its value to a DIO output pin. Then use a second JeeNode to treat this as a normal OOK pulse train.

Here’s the “rssiMirror” sketch I used:

Screen shot 2009-12-20 at 17.07.34.png

Does it work? Unfortunately … no :(

Time to hook up the Logic Analyzer to see what’s going on. I connected the above digital output to the first channel, and a real OOK receiver on the second channel:

uuu.png

Guess what… the RSSI signal is indeed detecting the presence of a transmitted signal, but it’s way too slow!

Here’s the same sample, zoomed in on the real OOK pulse train:

ooo.png

As you can see, there’s a pretty good sequence of transitions, 400 µs and 600 µs apart. Oh well, so much for the RSSI status bit – it’s nice to detect the presence of a carrier, but not more than that.

Next thing I tried was the DQD signal. After tweaking the DQD threshold to 3, this is what came out:

eee.png

Yeah, sure, it seems to track the signal, but not reliably, and with a huge number of extra transitions. Note how the top timings are all multiples of 25 µs apart – that’s because it takes 25 µs to read out the DQD status bit. Coarse, but fine enough in principle to track 400 / 600 µs pulses from an FS20 remote.

So, again: nice, but no dice. Neither the RSSI nor the DQD status bits are fast and accurate enough to decode a slow OOK pulse train with.

Next attempt was to try and pick up the ARSSI signal, direct off the RFM12B module – as mentioned in this forum discussion. There’s a German forum which describes where to pick up that signal:

rfm01.JPG.jpeg

And sure enough, here’s a scope capture of an FS20 transmission:

www.png

Yeah, it’s there alright. But the signal is a bit weak. I’d rather not dedicate the analog comparator or ADC to it, and besides – that still leaves the need to compare against the average level – there’s a nasty 0.4V bias in that signal.

Here’s the same signal, AC coupled:

qqq.png

And here’s a zoomed-in area, showing what looks like pretty decent 400 µs and 600 µs pulses:

hhh.png

So yes, a small self-adjusting comparator can proabably turn this into a nice digital pulse train – but it’ll require some extra components, and I’m a bit out of my league on designing such a circuit.

Oh well – perhaps this information will help someone else further along. It’s been a good learning experience for me, even if the result is not quite what I had hoped…

Tomorrow, I’ll describe another – successful! – outcome from this RSSI / DQD exploration.

Better FS20 transmissions

In Software on Dec 14, 2009 at 00:01

The RFM12B can be tricked into sending OOK (on-off-keying) signals – which is also called ASK (amplitude shift keying), by doing exactly what the term stands for: turning the transmitter on and off.

This has been used in several examples to control FS20 and KAKU remote power switches – just search for these terms on this weblog in the box at the bottom right of this page and you’ll get all the related posts.

The code I’ve been using for FS20 so far is:

Screen shot 2009-12-13 at 16.29.17.png

As it turns out, the timing is not quite up to scratch. JGJ Veken drew my attention to this in the forum and by sending in a couple of pictures, including this one:

03 jee-node transmitter 0 en 1 not ok.JPG

(Wow – great instrument, a 100 MHz Tektronix 2232 storage scope!)

A 0 bit comes out as 250/468 µS, and a 1 bit as 428/722 µS – pretty far off the 400/400 + 600/600 µS specs.

Here’s what we came up with after a few trials:

Screen shot 2009-12-13 at 17.20.28.png

The end result is within a few percent of the target, well within spec – yippie!

Jeenode Transmitter FS20 bitstream.JPG

I’ve updated the code in the RF12 examples (including RF12demo) in the code repository and the ZIP file.

A similar tweak could probably be used for the KAKU signals, but these use a lower rate of bit signaling, so the jitter is probably somewhat less important.

Update – the KAKU tweak has also been checked in, and the code has been simplified a bit further.

Updated RF12demo

In AVR, Software on Oct 29, 2009 at 00:01

The RF12demo software which comes pre-loaded on all JeeNodes and JeeLinks has been extended a bit:

Picture 1.png

The new commands are:

  • l – to turn the activity LED on or off, if present
  • f – send a FS20 command on the 868 MHz band
  • k – send a KAKU command on the 434 MHz band

The new FS20 and KAKU commands were added so that a JeeLink can be used out-of-the-box to control the commercially available remote switches of these types. The updated demo is included with all new JeeNodes and JeeLinks from now on.

For example, to turn on channel 1 of a FS20 unit with housecode 0x1234, you can type in “18,52,1,17f” – i.e. the house code in bytes, the channel, and 17, which is the “on” command. Likewise, to turn on channel 1 of group B on KAKU, type “2,1,1k”.

The KAKU transmission range is not very high because the RFM12B radio used is tuned for the 868 MHz band, but even more so because the attached wire antenna is completely wrong for use at 434 MHz. If you want to use this for controlling KAKU devices and don’t get enough range, try extending the antenna wire to around 17 cm, i.e. double its current length. You can just attach an extra piece of wire to the end.

Which – unfortunately – is going to substantially reduce the range at 868 Mhz… so if you really want to use both frequency bands, you’ll have to use two JeeNodes or JeeLinks, each with their own properly sized wire antennas.

For more info about FS20, see these posts on the weblog. For KAKU, see these.

OOK relay, revisited

In AVR, Software on Oct 21, 2009 at 00:01

The OOK relay to pass on 433 and 868 MHz signals from other devices has been extended:

DSC_0665.jpg

Spaghetti!

The following functions are now included:

  • 433 MHz signals from KAKU transmitters
  • 868 MHz signals from FS20 and WS300 devices
  • the time signal from the DCF77 atomic clock
  • pressure + temperature from a BMP085 sensor

Each of these functions is optional – if the hardware is not attached, it simply won’t be reported.

The BMP085 sensor in the top of the breadboard could have been plugged directly into port 3, but it’s mounted on a tiny board with the old JeeNode v2 pinout so I had to re-wire those pins.

Sample output:

Picture 1.png

There are still a few unused I/O lines, and additional I2C devices can be connected to port 3. Room to expand.

The source code for this setup is available here. It compiles to 10706 bytes, so there is plenty of room for adding more functionality.

This code includes logic for sending out the collected data to another JeeNode or JeeLink with acknowledgements, but I’m working on a refinement so it gracefully stops retransmitting if no receiver is sending back any acks.

As it is, this code will forever resend its data every 3 seconds until an ack is received, but this doesn’t scale well: all the “rooms” nodes do the same, so when the central receiver is unreachable every node will keep pumping out packets while trying to get an ack. It would be better for nodes to only re-send up to 8 times – and if no ack ever comes in, to disable retransmission so that only the initial sends remain.

I’m also still looking for a way to properly mount all this into an enclosure. There is some interference between the different radio’s, maybe all in one very long thin strip to maximize the distances between them?

Of JeeNodes and JeeLinks

In Hardware on Oct 18, 2009 at 00:01

There’s a new JeeLink coming…

DSC_0543.jpg

No external connections, just a little antenna wire sticking out. Uses a 10 ppm crystal to accurately keep track of time and has 1 Mbyte of flash memory on-board so it can collect data in unattended mode. This new JeeLink’s only purpose is to attach to a computer for communicating with JeeNodes and several commercially available RF controlled devices (KAKU, FS20, etc). It has three LEDs: RX, TX, and ACTIVITY.

The above will be called the JeeLink (v2) – I’ve just sent off my second prototype to the pcb shop. Quite a few tweaks and tricks were needed to fit everything into such a tight enclosure:

Picture 1.png

The current JeeLink (v1) is also going to change. First of all, it’s going to be called the JeeNode USB (v2) in the next revision since it really is a JeeNode, but with the FTDI-USB adapter added-on. Other changes will be mostly to make the standard JeeNode and this new JeeNode USB even more compatible with each other.

Ancient technology

In Hardware on Jun 12, 2009 at 00:01

This is fun. For one of my numerous projects, I wanted to resurrect a 15 year old LaserPrinter which has been gathering dust for a while:

Ancient technology

A “state of the art” 600 DPI PostScript laser printer for the Mac. With a whopping 6 MB RAM and LocalTalk / RS-232 / Parallel interfaces. Those were the days.

Plugging it in and running a self-test from the menu was all it took:

Ancient technology

As you can perhaps guess from the Dutch report in the bottom left, it has printed a mere 8050 pages in its lifetime so far.

Yeah. Back then, they knew how to make things. You just turn it on and it works. That toner cartridge must be at least 10-years old, btw!

Got some ideas about hooking up a JeeNode to this thing, probably via the serial port. The printer draws a lot of power and does not really have a standby mode, so the RFM12B could be used to control a remote KAKU power switch, for example. We’ll see…

Bubba JeeMon back up

In Hardware, Software on May 12, 2009 at 00:01

The title of this post can be interpreted in two ways, both accurate: 1) the Bubba Two NAS from Excito was my back-up server for the MMnet1001 module, and 2) that Bubba box is now my main JeeMon server and back in the air with all the electricity / gas / weather monitoring working again, as well as the Pachube and Bwired feeds.

I will probably stick to the Bubba from now on. It’s running Debian Etch Linux, and there’s a JeeMon runtime for it so the switch-over was trivial.

bubba-two.jpg.jpeg

This NAS box consumes about 4 watt, which is less than the specs because it has been modded to use a 2.5″ SATA disk instead of the standard 3.5″ ones they normally ship. It’s also a 300+ Gb file server which has been running various periodic tasks for almost a year now. There’s in fact much more disk storage in the form of 3 additional USB disks, but these are normally powered down (via a KAKU switch).

JeeHub Lite

In AVR, Hardware on May 4, 2009 at 00:01

The current JeeHub includes a MMnet1001 Linux module, which is great for running JeeMon. But for an even more basic always-on system, it’s possible to forego the Linux part – here’s the idea:

Picture 1.png

The whole thing is powered from USB, which must remain on permanently. There is no need for the attached computer to be on all the time, because incoming data can be saved into the on-board DataFlash memory. Depending on data volume and memory size, it ought to be possible to have a few days of autonomy.

The 433 and 868 MHz OOK receivers make this thing suitable for receiving weather data from off-the-shelf components, as well as responding to KAKU and FS20 remotes (and others like them). And since the RFM12B is so versatile, it can also send out 433 and 868 MHz OOK commands to those systems.

One thing I forgot to add in the above diagram, is a DCF77 receiver – or perhaps using a crystal or RTC. As has been mentioned a few times, the JeeHub needs to have a fairly accurate sense of time to do its main job of collecting real-time readings.

Only a minimal number of signals/ports are needed for the main tasks, there are several pins left to connect a few extra sensors.

The main bottleneck will probably be the amount of code needed to make such a JeeHub Lite perform basic home automation tasks. An Atmega328 might help a bit.

The normal monitoring and reporting work is still done with JeeMon, but now running on the attached PC (which can be Windows, Mac OS X, Linux, whatever). In such a configuration JeeMon must catch-up and extract saved data from the DataFlash in the JeeNode whenever it is launched.

RFM12 vs RFM12B

In AVR, Hardware on Apr 29, 2009 at 00:01

Here’s an RFM12 433 MHz module from Pollin, hooked up to an Arduino Duemilanove:

RFM12 (not RFM12B) @ 5V

One major difference between the RFM12 and the RFM12B is that the RFM12 can run at 5V, whereas the maximum operating voltage for the RFM12B is 3.8V (it can withstand up to 6V, which is good to know).

Alas, there seems to be some other difference which eludes me, because the RFM12 hooked up in the above picture only seems to be able to send. The RF12 demo code, which works fine for send and receive on RFM12B’s seems to do something wrong. Same behavior with another RFM12 module – so it looks like this is not due to a broken module. Send works, but nothing is coming in other than occasional garbage data.

The transmit part works fine when sending to an RFM12B, also in OOK mode: the RFM12 successfully controls both 433 and 868 MHz units (KAKU and FS20, respectively). But as packet receiver for other RFM12 or RFM12B modules … no joy so far.

Weird. Tips, anyone? Please let me know.

Update – Thanks to R. Max’s comment below, the problem has been solved: the RFM12 does not support arbitrary 2-byte sync patterns, it has to be 0x2D + 0xD4 – then it works fine!

Update 2 - See also the RFM12 vs RFM12B revisited page for a list of differences.

RF woes – solved!

In Software on Apr 28, 2009 at 00:01

Turns out my troubles with using the 868 MHz OOK radio next to the RFM12B module were caused by a silly software mistake (I mixed up the port assignments). No hardware or RF issues after all.

Latest sample output:

Picture 2.png

(the VOLT and BARO readings are bogus because the hardware is not connected)

As you can see, it’s receiving both packet types now. Still some trickiness with allocating the port signals properly, since some lines do require specific pins: the OOK receiver uses the analog comparator, but the ADC gets used as well, so I’ll need to adjust things a bit to use a pin change interrupt instead (used a crude workaround for now).

So now the basics are there to receive all types of signals with a single JeeHub: packets from other JeeNodes using the RFM12B, an 868 MHz OOK receiver for weather data and the FS20 remotes, and a 433 MHz OOK receiver for picking up KAKU remote commands (and possibly some other cheap weather sensors later).

Switching AC

In Hardware on Apr 16, 2009 at 00:01

Got myself a couple of these relays from Pollin, for less than the coin next to it:

Bi-stable relay

They can switch 220V @ 16A, and work at 3V. The specialty is that this relay is bi-stable, IOW there are two 15 Ω coils and you send a short pulse through either of them to switch to the corresponding position. So it takes some power to switch, but after that the relay keeps its last position without power. Like a mechanical switch.

It does take some 200 mA – briefly – to switch, so the power supply has to be up to that.

My plan is to connect this to a JeeNode as follows:

Picture 3.png

Probably using a pair of BC547 transistors and 1N4148 diodes (or maybe a ULN2803, to control up to 4 relays). That way, each port would be able to drive one relay. A pretty cheap solution to control any 220 V appliance.

Haven’t decided yet how far to go into actual AC control, since the other option is to use off-the-shelf RF-controlled switches, such as the Conrad/ELV FS20 868 MHz series or the cheap KAKU 433 MHz switches. But relays can be more secure, if some encryption is added to the RF12 driver.

Fun note: I spent a lot of time as a teenager thinking about building a (feeble) computer with relays. After all, this is essentially a 1-bit memory. I’ve moved on since then … slightly :)

JeeHub modularity

In Hardware on Apr 13, 2009 at 00:01

The current JeeHub setup is a bit of a mish-mash:

Picture 1.png

It includes the RFM12B radio of course, to receive data from all JeeNodes. But it also includes a 433 MHz OOK receiver, a BMP085 pressure / temperature sensor, and a DCF77 clock signal receiver.

Trouble is, these things interfere with each other …

The 433 MHz OOK receiver seems to severely degrade RFM12B reception – so I yanked it out. Didn’t have an immediate need to decode KAKU signals anyway.

But worse, the DCF77 receiver also fails to work inside the current JeeHub enclosure. I suspect that either radiated RF power or some messy interference on the power supply levels is preventing it from detecting the 77 kHz signal. I really want DCF77 as reference clock, but I haven’t been able to make any use of it so far.

It looks like there’s too much going on in the current JeeHub prototype, electrically or electro-magnetically.

This is silly – and there’s a very simple way out: move some data sources / sensors to a separate JeeNode. After all, the JeeHub has been doing one thing really well for some time now, i.e. collecting data from remote JeeNodes via the RFM12B:

Picture 2.png

All I need to do is add support for OOK receivers plus BMP085 to the pulse software, and then attach them to one of the remote JeeNodes. Would also make it possible to connect both 433 and 868 MHz OOK receivers.

Haven’t made up my mind about the DCF77 receiver though. Having it tightly integrated with the JeeHub still makes sense – it’s where all the data comes through and gets time-stamped. Maybe the DCF radio will start to work once I disconnect all the other cruft. If not, I’ll either move it physically away from the rest of the JeeHub or reassign it to a remote JeeNode as well.

Surprising, how physical / electrical aspects are starting to impose themselves…

Switching stuff

In Hardware on Dec 16, 2008 at 15:51

Today, some simple “KAKU” remote switches came in. These are both by KlikOn-KlikOff – the first one is an older setup I was already using, with up to 12 different codes:

5178D8B8-5919-4468-89B0-B194DC94A909.jpg

The second is a newer model with up to 256 different codes – it’s heavily discounted (€14 for 2 units plus transmitter), probably because this type is being replaced by a newer model which uses unique unit codes:

47189E65-1B9A-4213-A21A-AE5585C20CFF.jpg

The drawback with both of these, as compared to the FS20 models by Conrad, is that you can’t control them at the plug – you have to locate the remote and press buttons on it. But then again, at these low prices per unit … you get what you pay for.

These units use 433 MHz signalling, there’s code for Arduinos which understands the KAKU protocol.