Computing stuff tied to the physical world

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.

  1. Nice! So for KAKU the same +150, -200 adjustments would be appropriate (though not strictly necessary)?

  2. I have 2 KAKU receivers from the same package. Strangely, the one works just fine with but the other only switches about 10% of the times I send a command. Perhaps this timing adjustment might just improve this situation. I’ll try to modify the KAKU code in a similar fashion sometime to see if this works.

    • I’ve just made some changes to the KAKU code in RF12demo with similar timing adjustments. Could you try it out and let me know whether that works better?

  3. I tried it with the new RF12demo, but still the same effect. I investigated further to see wether it could be something different. The KAKU receiver is situated next to a home-easy receiver. After I removed the home-easy receiver, the problem also disappeared. I don’t quite understand how it interferes with the KAKU reception, but it somehow does. The KAKU always worked OK with the KAKU remote btw, but when now trying further away it seems that the remote works better with the isolated KAKU than the one next to the home-easy receiver. So there’s some suffering from this interference here too, but it is less sensitive to it.

    So it wasn’t the KAKU code timeing afterall, but thanks for your helpfullness !

Comments are closed.