FS20 S3-Ersatz

Im Laufe der letzten Jahre sind mehrere meiner FS20 S3 Sender von ELV, die ich in Verbindung mit einer Funksteckdose FS20 ST-3 im Timermode zur Steuerung unseres Garagentores verwende, in die nächste Existenzebene übergewechselt.

Ersatzsender lassen sich nur noch spärlich auftreiben und deren Preise sind inzwischen in astronomische Höhen geklettert, brav den marktwirtschaftlichen Gegebenheiten folgend.

Gerade habe ich noch zwei als „neu“ gekennzeichnete Exemplare ergattert, die sich bei näherer Betrachtung als bereits gebraucht, bei einem der Teile sogar durch erhebliche Abnutzung am Taster 1 erkennbar als sehr stark im Einsatz gewesen, erwiesen haben. Darüber hinaus sind bei beiden Geräten die Batterien mindestens einmal ausgelaufen, die Batteriekontakte waren entsprechend verranzt, wie man so schön sagt.

In der Bucht findet man gerade haufenweise „Lernfähige Handsender“ die auch den beim FS20-System verwendeten Frequenzbereich von 868 MHz abdecken. Hier muss man aufpassen, dass man den richtigen Typ auswählt, denn die Geräte werden teilweise als „lernfähig“ bezeichnet, weil sie an einem entsprechenden Funkempfänger eingelernt werden können. Der Sender selbst ist in diesem Fall aber in keiner Weise lernfähig und somit auch nicht in der Lage, eine vorhandene Fernbedienung zu clonen.

Die nicht cloning-fähigen Typen heißen YET2128 (Bezeichnung auf der Platine) und werden mit einer 12 V Alkalinebatterie befeuert. Der „richtige Typ“, also echt lernfähig im Sinne von Clonen, hat irgendwo in der Beschreibung die Bezeichnung YET2130 und die Versorgungsspannung kommt von einer 3 V Knopfzelle.

Beide kommen im identischen Gehäuse daher, sind also optisch nicht unterscheidbar.

Erst geöffnet sind die beiden Typen leicht zu unterscheiden.

          (Click auf die Platinen öffnet Detailaufnahmen)

In den Bildern oben ist die rote/linke Fernbedienung der “richtige Typ”.

Leider tritt auch bei dieser neuen Generation von lernfähigen Fernbedienungen das klassische Problem beim Erkennen des zu lernenden Codes auf: Um den Code analysieren zu können, muss dieser über einen längeren Zeitraum und gegebenenfalls periodisch wiederholend gesendet werden.
Das klappt auch, aber beim FS20-System wird nach einem Tastendruck länger als 0,4 s eine andere Funktion ausgelöst.

Im gegebenen Fall, mit der Steckdose FS20 ST-3, wird mit dem erlernten Code die Timerfunktion ausgeschaltet, die Steckdose wird also permanent eingeschaltet. Außerdem scheint das Timing des erzeugten Signals nicht konstant zu sein, denn die Funktion wird nicht immer zuverlässig ausgelöst.

Kurz und bündig: Diese lernfähigen Ersatzsender sind für den gedachten Einsatzfall ungeeignet.

Nachtrag
Nachdem ich den Ersatzsender mit AtTiny85 soweit am Laufen hatte, habe ich mir überlegt, basierend auf der Arduino Firmware V1.1 eine Version V1.2 zu implementieren, die bei kontinuierlichem Tastendruck laufend die Code-Pakete sendet die den normalen EIN-Befehl repräsentieren.

Das FS20-Protokoll definiert den normalen EIN-Befehl so:
DATA  -  PAUSE 10 ms  -  DATA  -  PAUSE 10 ms  -  DATA  -  PAUSE >110 ms

Ich habe die Pause nach dem dritten DATA auf 500 ms festgelegt und dann die Wiederholung in einer Schleife gestartet.

Auf diese Weise sollte der lernfähige Ersatzsender in der Lage sein, das Signal korrekt zu analysieren und anschließend diese normalen EIN-Signale zu reproduzieren.

Diese Annahme hat sich bestätigt, die lernfähige Fernbedienung (die “Rote”) kann jetzt ebenfalls unser Garagentor steuern. Allerdings ist die Reichweite des Senders deutlich geringer als bei den Original ELV Sendern oder auch bei meiner Ersatzlösung mit dem AtTiny (was erklärlich ist, denn der verwendet ja den unveränderten HF-Teil des Originals).

---

An dieser Stelle angelangt habe ich mir überlegt, das Dilemma durch einen selbst programmierten AtTiny µC aufzulösen, der in das vorhandene FS20 S3 Gehäuse implantiert wird. Eine Platine im passenden Format wird entworfen, die die Original-Platine im Sender ersetzt.

Dazu muss man wissen, dass Digital- und HF-Teil des Senders auf getrennten Platinen realisiert sind, die in Sandwich-Bauweise aufeinander gelötet sind.

Zwischen der Digital-Platine und dem HF-Teil liegt eine weitere Glasfaserplatte ohne Kupferbelag. Diese dient als Abstandshalter und hat passende Ausschnitte, damit die Enden der Knackfrosch-Taster ausreichend Spiel in den Befestigungslöchern haben. Auch die bedrahtete LED - auf neudeutsch ein Through Hole-Bauteil, abgekürzt TH - benötigt auf der Unterseite Platz für die Lötverbindung.

---

Der Warmduscher-Ansatz bei der Implementierung der Funktion ist, die Impulsfolge an der Schnittstelle zwischen Digital- und HF-Teil mit dem Oszi auszumessen und einfach als feste Folge mit dem µC zu erzeugen.

Der Königsweg ist natürlich die Implementierung des FS20 Protokolls und der Möglichkeit, die notwendigen Haus- und Gerätecodes per Tastenkombination erlernbar zu machen und somit die volle Funktionalität der Original-Komponenten zu simulieren. Da die AtTinys ein EEPROM an Bord haben, ist zusätzlich das lästige Vergessen der Codes beim Batteriewechsel und bei stärkeren Erschütterungen Geschichte.

Im selbst gebauten FS20-Ersatz kann auch das im gegebenen Einsatzfall unerwünschte Dauer-EIN der Steckdose unterbunden werden, bei längerem Tastendruck wird ebenfalls nur der normale EIN-Befehl gesendet. Es ist trotzdem eine gute Idee, den AUS-Befehl zu implementieren, damit eine mit einem Original-Sender versehentlich auf Dauer-EIN geschaltete Steckdose wieder in den Timer-Mode zurück geschaltet werden kann.

Nachtrag
Der Dauer-EIN-Zustand der Steckdose wird auch durch senden eines normalen EIN -Befehls aufgehoben, die Implementierung des AUS-Befehls ist also nicht unbedingt notwendig.

Unterstützend bei der Umsetzung beider Lösungsansätze kann auf die Vorarbeiten von Dirk Tostmann zurückgegriffen werden, der im Zusammenhang mit der PC Zentrale „FHZ1000 PC“ das FS20 Protokoll analysiert hat. Vielen Dank an dieser Stelle an Dirk!

Auch in Burkhard Kainkas Weblog gibt es einen Beitrag zum FS20 System, in dem der Autor die Ansteuerung eines FS20 HF-Teils mit einem AtTiny13 beschreibt, der von einem PC-Programm gesteuert wird.

---

Der erste Ansatz, nur das Bitmuster eines eingelernten, funktionierenden Senders aufzuzeichnen und dann mit dem neuen Microcontroller zu wiederholen, ohne die gespeicherten Codes zu kennen, erfordert zuerst einmal eine Möglichkeit, das Bitmuster zu erfassen.

Am einfachsten erschien mir, dazu einen Arduino zu verwenden, mit dem ich das Ausgangssignal des Digitalteils eines FS20 S4M, den ich mit dem Code der Steckdose programmiert hatte, abtaste.

Das dazu notwendige Programm stelle ich als Arduino Source zur Verfügung.

Hinweis
Das zur Verfügung gestellte Programm liefert keine Tasten-Codes, es ist keine Dekodier-Funktion implementiert. Angezeigt wird die reine Bitfolge, die der HF-Teil zum Empfänger sendet, inklusive der Präambel zur Synchronisierung, den verschiedenen Codes, dem Befehl an den Empfänger, einer Quersumme und Parity-Bits zur Fehlererkennung bei der Übertragung.

Das digitale Ausgangssignal des Senders liegt auf dem rechten Pin des dreipoligen Steckers und wird über Pin D2 in den Arduino eingespeist (gelbe Leitung im Bild oben). Das HF-Modul ist für diesen Vorgang nicht aufgesteckt. Masse von Sender und Arduino müssen, gegenüber der Darstellung auf dem Bild, ebenfalls verbunden sein.

Der FS20 S4M wird hier über ein Labornetzteil mit 12 V versorgt, ein 3 V Spannungsregler ist auf dem Board vorhanden. Das Ausgangssignal des FS20 S4M reicht mit ca. 3 V gerade so aus, den mit 5 V betriebenen Arduino anzusteuern, eine Pegelanpassung war also nicht nötig.

Der eingelesene Code, eine 59 Zeichen lange Bitwurst aus „0“ und „1“ wird über die serielle Schnittstelle (USB am Arduino) zum PC übertragen und kann im Terminal-Fenster kopiert und in das Sender-Programm eingefügt werden.

---

Der Sender ist komplizierter.

Hier ist in erster Linie darauf zu achten, dass der Microcontroller im Deep Sleep Modus verharrt, solange keine Taste gedrückt ist.

Für den AtTiny85 sind folgende Ressourcen im Chip stillzulegen:

• Brownout detection (am besten gleich mit der passenden Fuse abschalten)
• Analog comparator
• AD Wandler
• Interne Spannungsreferenz
• Watchdog

Weiterhin ist darauf zu achten, dass keine Eingänge offen bleiben, alle Eingänge sind also mit einem hochohmigen PullUp zu versehen. Der AtTiny hat 6 IOs, einer wird zum Ausgang für das Code-Signal, einer steuert die LED an, die anderen vier IOs erhalten einen PullUp von 1 MΩ. Der intern zur Verfügung stehende PullUp ist niederohmiger, weshalb ich zugunsten eines geringeren Stromverbrauchs darauf verzichten möchte. Laut Datenblatt haben die internen PullUps einen Wert zwischen 20..50 kΩ (am Reset Pin 30..60 kΩ). Im ungünstigsten Fall fließen also pro Pin bei 3V Versorgungsspannung 150 µA. Bei 1 MΩ externem PullUp verringert sich dieser Wert auf 3 µA.

Diese Werte sind natürlich nur bei aktiviertem Eingang (Taste gedrückt) gültig. In diesem Fall wird aber sowieso das Sendesignal erzeugt und die LED kurz eingeschaltet. Im Zweifelsfall trägt also der Strom durch den (die) PullUp(s) nur zu einem vernachlässigbaren Teil zum Gesamtverbrauch bei und die externen PullUps können zugunsten einer vereinfachten Schaltung entfallen.

Auf der Platine ist ein ISP-Programmieranschluss vorgesehen um den Code ggf. neu aufspielen zu können, die „Knackfrosch“-Tasten des Originals werden durch echte SMD-Taster ersetzt.

Die Platine muss in das Gehäuse des FS20 S3 passen, die Lage der Taster und der LED sind dadurch festgelegt.

Soweit die zu erfüllenden Randbedingungen für die Hardware.

Wie eingangs erwähnt war beabsichtigt, eine eigene Platine zu entwerfen, die in das Gehäuse des ELV Senders passt. Eine andere, nachgerade grandios anmutende Idee ist, die vorhandene Digital-Platine einfach weiter zu verwenden. Das hat den Charme, dass LED und Taster bereits passend positioniert sind. Desweiteren sitzt auf der Platine noch ein LowPower Reset Controller der Firma Torex aus der XC61xx-Serie, der dafür sorgt, dass der µC immer korrekt seinen Reset erhält, sollte die Versorgungsspannung mal auf der Kippe stehen (fast leere Batterien). Ein paar notwendige Blockkondensatoren und der Serienwiderstand für die LED sind auch schon vorhanden.

Der original µC - auf dem FS20 S4M Modul übrigens ein Samsung S3P72N4, ein 4bit OTP Prozessor - sitzt unter einem schwarzen Blob und muss für die Transplantation ggf. weggeflext werden, aber spätestens dann sollten sich die 8 Hufe des AtTiny relativ einfach mit dünnen Drähten passend an die vorhandenen Leiterbahnen anschließen lassen.

Eine visuelle Kurz-Schaltungsanalyse ergibt: Die Anschlüsse der drei Tasten sind leicht zu erreichen, ebenso der Reset-Ausgang des Torex Controllers (dessen Leitung verläuft auf der Unterseite, kommt aber über ein Via wieder nach oben), der Anschluss für die LED sowie der Datenausgang Richtung HF-Modul. Bleiben VCC und GND, die ebenfalls auf der Oberseite der Platine zugänglich sind.

Bei Realisierung dieser Option muss das Programm im AtTiny aber schon komplett ausgereift sein, denn bei einer fliegenden Verdrahtung des Mikrocontrollers kann man nur schlecht einen Programmieranschluss vorsehen.

Auf der Unterseite der Platine sind zwar Pads eines Programmieranschlusses vorhanden, es wäre aber reiner Zufall, wenn die Zuordnung dieser Pads zu den benötigten Signalen am AtTiny passen würde oder zumindest möglich wäre. Das ist zu prüfen.

Schlimmer im Sinne der Nutzbarkeit dieser Möglichkeit ist aber, dass die Unterseite dieser Digital-Platine nach dem Zusammenbau von Digital- und HF-Teil nicht mehr zugänglich ist. Der HF-Teil wird mit den drei Lötflächen links neben der Aufschrift “HFS1” und dem am rechten Platinenrand sichtbaren Draht flach auf die Digital-Platine aufgelötet und deckt die Programmier-Pads fast vollflächig ab.

Hier sieht man übrigens schön die Macken (rote Kreise im Bild), die sich im Laufe der Zeit durch die Betätigung der Knackfrosch-Taster ergeben und die dann letztlich zum Ausfall der Schalter führen.

---

Softwaretechnisch habe ich zwar zuerst tatsächlich das Ausgangssignal des FS20 S4M Senders analysiert und mal ein kleines Programm auf einem Arduino geschrieben, das diesen aufgezeichneten Impulsstrom einfach kopiert. Nachdem ich aber auf diesem Weg nur das EIN-Signal clonen konnte, das geclonte AUS-Signal sich hingegen standhaft geweigert hat, ebenfalls zu funktionieren, habe ich dann einen Kompromiss zwischen den beiden oben erwähnten Möglichkeiten implementiert.

Der Hauscode und die Adresse werden jetzt im Programm als Tastencodes hinterlegt, die erforderlichen Bitmuster für den Impulsstrom werden im Programm daraus errechnet. Auf diese Weise klappt auch die Erzeugung des AUS-Signals :-)

Hier der entsprechende Code-Ausschnitt:

static String Synchron = "0000000000001"; // Synchronisierung, festgelegt, nicht aendern!
// --------------- --------------- -------------- -------------- --------------
// hier die eigenen Codes eintragen (HC1/HC2 sind der Hauscode, Einzelheiten siehe
   Bedienungsanleitung des FS20 S3 Senders)
static String HC1 = "1111";     // Tastencodes (Taste1, Taste2, Taste4 am FS20 S3 moeglich)
static String HC2 = "2222";
static String Adresse = "3333";
// --------------- --------------- -------------- -------------- --------------
static String EOT = "0";     // kein Tastencode, nur eine Null, festgelegt, nicht aendern!

Die Hauscode-Teile HC1 und HC2 sowie die Adresse müssen mit den eigenen Codes (vierstellige Zahlen mit den Ziffern 1..4, entsprechend der Wertigkeit der drei Tasten des FS20 S3) ersetzt werden, im Handbuch des Senders FS20 S3 ist genau beschrieben, wie die Codes aufgebaut sein müssen.

Auch diese erste Version des Sender-Programms stelle ich zur Verfügung.

Hier ist allerdings zu beachten, dass dieses Programm lediglich der Verifizierung der Idee dient und auf einem Arduino Nano mit 16 MHz und ohne jegliche Maßnahmen zur Energieeinsparung läuft.

Weiterhin habe ich in dieser Programmversion die Impulsströme für EIN und AUS jeweils  in einem String abgelegt um mir im ersten Ansatz das Gefummel mit doppelten Indizes beim Zugriff auf Byte-Arrays zu ersparen (wir erinnern uns, jeder Befehl hat 59 Bit). Letztlich werde ich das aber wohl doch noch umstellen, denn die notwendigen mehrfachen Umformungen von Strings in berechenbare Ausdrücke und zurück machen auch nicht wirklich Spaß... Also mir, beim Programmieren. Dem Arduino ist das egal ;-)

---

Inzwischen habe ich eine Version V1.1 des Arduino Programms erstellt. Hier verwende ich keine Strings mehr sondern verpacke die zu sendende Bitwurst in eine unsigned long long Variable. Leider unterstützen bitRead() und bitWrite() keine ULL Variablen, aber Nick Gammon hat sich schon mal um dieses Problem gekümmert und eine Lösung in Form zweier Template-Definitionen bereit gestellt.

Auch diese Version für den Arduino enthält noch keine Energiesparmaßnahmen und dient nur als Vorarbeit für den eigentlichen Einsatz auf einem AtTiny85.