livebox:universalrfrx [DBZoo]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Universal RF Rx ======

The idea behind the URF-Rx service is to enable you to use ANY RF remote as a controller for ANY xAP service.

{{:livebox:urfrx-block-diagram.png}}

With the virtual serial port mode this makes it possible to combine the HAHCentral sketch with the RFRX receiver code module.  One piece of hardware can be used to communicate with the [[hah_hahnode|HAHNodes]] and with the 433MHz RF receiver hardware.

It would also allow you to combine say the RFGateway sketch using the Nanode hardware with the RF hardware and have the xap-serial message being dumped directly onto the Ethernet.  Many options available with these architecture choices.
===== The receiver =====

The hardware to slurp and detect what looks like a valid RF signal from all the background noise.  With this hardware we don't pre-code what RF signals we are going to look for, which is what most purpose built RF receivers do.

The source: http://livebox-hah.googlecode.com/svn/trunk/userapps/arduino/ You will also need the RFRX Library .

<note>The RFRX library is part of the HAHCentral sketch so by attaching a RF receiver to this existing hardware you can get this functionality for very little extra cost.  Just the cost of a RF Rx unit, which is about 3-4 quid.</note>

The beautiful part of this design is the separation of the signal gatherer from the decoder.  We look for a signal that has a lead-in >10ms and repeats more than once.   If this condition is met we emit the pulse stream for a repeating block out to the serial port for the decoder to deal with.

Here is a pulse train that meets this condition.

{{:livebox:pulse_train.png?640|Sample Pulse train}}

The first block would be stored and when the 2nd block is encountered it's compared to the 1st, as they match it would then be emitted as a sequence of pulse durations, -ve for LO and +ve for HI, down the serial port to a decoder.
  
Sample output.
<code>
-11248,384,-1072,1120,-352,384,-1072,384,-1072,384,-1072,384,-1072,384,-1072,384,
-1072,384,-1072,384,-1072,400,-1056,1120,-352,384,-1072,384,-1072,384,-1072,384,
-1088,368,-1088,368,-1088,368,-1088,1120,-352,384,-1088,1120,-352,384,-1072,384,
-1072,384,-10016
</code>

This pulse sequence can be visualized using a helper:
  * http://www.dbzoo.com/public/rf-plot.html
and if all has gone well it should look like the picture we captured using our Logic Analyzer directly attached to the RF receiver pin.

{{:livebox:pulse_train-plot.png}}

We then take this pulse sequence and use some magic to convert it into a URF string using this web page
  * http://www.dbzoo.com/public/pulseTrainToURF.html

If you are going to use this to transmit you'll need to adjust the **burstcount** which using the HTML form above will always default to 1.  The signal analyzer won't detect how many times this pattern repeats.

This gives us the following packed URF hex string:
<code>
0101017E0434046001600A01271018401014
</code>

This is used by the Decoder explained in the next section.  It may also be used by the RF Tx unit to generate the same pulse sequence for control too.

===== The decoder =====

The signal processor to match a signal against a list of pre-configured patterns.

Using the web page we enter the ON and OFF signal we want to watch for.   If there is only a single RF pattern, i.e. it's a toggle for ON followed by OFF, only supply a single RF pattern, don't repeat it in the ON and OFF fields. Just ON will do.

{{:livebox:urfrx-screen.png|}}

The /etc/xap-livebox.ini file may also be edited by hand to input this information.

<code>
[urfrx]
devices=1
rf1.label=RF 1
rf1.off=0101017E0434046001600A01271018401014
rf1.on=010201820436046A015601700436045001700101271018100001820339
enable=1
serialport=/dev/ttyUSB0
vserial=1
</code>

  * vserial - Virtual Serial port (1) or Directly connected hardware (0)
  * enable - Start this service automatically 

Each RF<number>.STATE pattern is created as a BSC endpoint.  When a signal comes in that matches our definition the endpoint will have its state changed accordingly and an xAPBSC.event will be generated.

A sample event when a signal comes in that matches the rf1.on pattern.
<code>
xap-header
{
v=12
hop=1
uid=FF00EE02
class=xAPBSC.event
source=dbzoo.livebox.urfrx:rf.1
}
input.state
{
state=on
}
</code>