From bbbda74130be3af613b0c3a6a5527d53bdee625a Mon Sep 17 00:00:00 2001
From: rudolfkoenig <>
Date: Sun, 29 Oct 2017 14:24:51 +0000
Subject: [PATCH] 16_CUL_RFR.pm: clarifications in the doc (Forum #78574)

git-svn-id: https://svn.fhem.de/fhem/trunk@15341 2b470e98-0d58-463d-a4d8-8e2adae1ed80
---
 fhem/FHEM/16_CUL_RFR.pm | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/fhem/FHEM/16_CUL_RFR.pm b/fhem/FHEM/16_CUL_RFR.pm
index e6047b240..7870f655a 100644
--- a/fhem/FHEM/16_CUL_RFR.pm
+++ b/fhem/FHEM/16_CUL_RFR.pm
@@ -161,10 +161,22 @@ CUL_RFR_AddPrefix($$)
   The CUL_RFR  module is used to "attach" a second CUL to your base CUL, and
   use it as a repeater / range extender. RFR is shorthand for RF_ROUTER.
   Transmission of the data uses the CC1101 packet capabilities with GFSK
-  modulation at 250kBaud after pinging the base CUL at the usual 1kBaud. When
+  modulation at 250kBaud after pinging the base CUL at the usual 1kBaud.  After
   configured, the RFR device can be used like another CUL connected directly to
-  fhem.
+  FHEM.<br>
 
+  In theory every SlowRF protocol should work, as the hook is implemented in
+  the culfw output routine: instead of sending the data to the USB-Interface it
+  is transmitted via radio to the base CUL. There are still some restrictions:
+  <ul>
+  <li>due to the ping both CULs have to be in SlowRF mode, and use the same
+    parameters (freq, bwidth, etc).</li>
+  <li>the logical module handling the protocol is not allowed to access the
+    routines of the IODev (i.e. CUL) directly.</li>
+  </ul>
+  Tested protocols are FHT, FS20, EM, HMS, S300.<br>
+  Since there is no ack or a resend mechanism, it should be primarily used to
+  forward "unimportant" data, it was developed for forwading KS300 packets.
 
   <br><br>
   Before you can use this feature in fhem, you have to enable/configure RF