summaryrefslogtreecommitdiff
path: root/trasmitter/README.rst.txt
blob: d2fd957cfaf1f883f99112f0a57bd47b06ab2771 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
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.