Some links:
* capturing radio signals
http://www.stevenhale.co.uk/main/2013/08/home-automation-reverse-engineering-a-worcester-bosch-dt10rf-wireless-thermostat/
https://damn.technology/controlling-british-gas-wr1-receiver-arduino
http://rossharper.net/2015/11/decoding-a-siemens-rcr10433-thermostat-signal-to-control-a-boiler-from-a-raspberry-pi/
IMPORTANT: the transmitter prefers 3.3V, it stops working after a
while on 5V.
Reveng
======
Sampled at 192k samples/second, found that the transmissions had 3
types of (presumably square) pulses:
======== ======= ========
name samples duration
======== ======= ========
narrow 200 ~ 1ms
middle 300 ~ 1.5ms
wide 400 ~ 2ms
======== ======= ========
The two sequences are:
* ``nnnnnnWnWnnMnnMnnnnnWnnnnMnMWn``
* ``nnnnnnWnWnnMnnMnnnnnnnnnnWMMWn``
Actually no, the pulses are not ½ high and ½ low, they're shaped
weird. The source code has the correct widths.
Without Arduino
===============
The GPIO / XIO pins on NextThing's CHIP, even when driven via the `slow
sysfs interface`_, seem to be fast enough for our purposes.
See the ``sender-chip.pl`` test program.
The timing via the sysfs interface is awful.
It looks like we can drive the pins (not the XIO ones) via
memory-mapped registers: the sunxi-tools ``pio.c`` has most of the
code needed.
We could write a C program to just send the signal train. Look at
``clock.c`` for a way to handle fast / real-time scheduling and
delays.