[Codebeispiel] Projekt: IR-Transmitter

[Eugenius]

Ich mache gerade Gedanken darüber wie man einen IR-Sender bauen kann.

Was möchte ich damit steuern:

• mein Fernseher (Samsung LED UE46D8090)
• Lautsprecher (Logitech Z906) über Infrarot steuern möchte.
• evtl. weiter Geräte (FireTV, XBOX, PS...)

Beide nutzen NEC-Protokoll, was die Sache schon mal erleichtert, aber die Codes an sich sind 8-stellige Strings und die können wir (stand heute) nicht übertragen.
Deswegen kam folgende die Idee: da die Codes fest sind (außer man kauft sich ein neues Gerät), kann man die Codes direkt im Sketch einprogrammieren (per define z.B.).
Dann gibt folgende Möglichkeiten:

1. für jeden Code eine eigene GA definieren => man ist sehr flexibel: wenn "1" an eine von diesen GAs gesendet wird, sendet man ein IR-Code. So kann beliebiges KNX-Gerät verwendet werden, z.B ganz normaler Taster. Nachteil: Anzahl der Codes = Anazahl der GAs
2. jeder Code bekommt eine ID. So definiert man eine einzige GA die eine ID empfängt. Nachteil: So braucht man zwar nur eine GA, aber so kann man nicht alle KNX-Geräte ohne weiters nutzen (man könnte evtl. Szenen-Funktion dafür missbrauchen = max 64 Möglichkeiten)

Aktuell tendiere ich zu Möglichkeit 1.

Was ich mir noch wünsche:
Script Funktion, ähnlich wie bei Logitech Fernbediegungen. D.h. man definiert wieder eine GA oder ID (je nach gewählte Möglichkeit) und sendet mehrere Codes auf einmal/nach einander:

• Watch TV: Fernseher EIN, Lautsprecher EIN, Lautsprecher Eingang 3
• Playstation: PS EIN, Lautsprecher Eingang 4, Fernseher HDMI1
• usw...

Weitere Ideen?

---

UPDATE:
Das haben wir bis jetzt ausgearbeitet:

• 1x GA zum ansteuern
• Max. 50 Codes, die man frei vergeben kann (über die Suite)
• Max. 5 Scripts über die o.g. GA ansteuerbar sind, Delays zwischen den Sendebefehlen müssen beachtet werden
• Standard Protokolle auswählbar machen (bzw. werden automatisch von der Lernfunktion gesetzt)
• RAW wird (vor erst) nicht unbeschützt

oder die bessere Alternative:

• Lernfunktion (die Codes werden nicht manuell ausgelesen/eingegeben, sondern direkt von der Fernbediegung gelernt)
• 1x GA zum ansteuern
• 1x GA / ProgButton zur Aktivierung der Lernfunktion

Vorteile:

• man muss nicht die Codes Manuell auslesen/eingeben.
• die Protokolle werden direkt mitgespeichert
• RAW-Format wäre theoretisch auch möglich

[tuxedo]

Hey, statt einen weg drum herum zu finden, wäre es doch besser das Problem bei der Wurzel zu packen. Es dürfte nicht so das Problem sein Strings als Parameter in der Suite zu haben.

Die Codes im Sketch zu verankern per DEFINE ... Is nicht. Das "DEFINE" ist nur eine Compiler-Anweisung die da sagt: Überall wo im Code XYZ steht, ersetze mit ABC.

Das macht in diesem Fall keinen Sinn. Dann kannst du gleich alles in feste Variablen gießen, andernfalls wäre dein Sketch wieder anwendungsabhängig und du kannst dir das Programmieren über die Suite sparen. Auch ist der Platzbedarf für viele Strings nicht zu verachten.

Das Protokoll der Suite erlaubt Parameter bis 11 byte Länge. Sofern das für die Codes reicht, ziehe ich das als String-Parameter in der Suite nach.
Einziger Knackpunkt ist dann noch die Sache mit den KOs... Die kannst du nicht "dynamisch" anlegen. Du musst eine bestimmte Anzahl in der XML einfach definieren und im Sketch auch berücksichtigen. Du kannst dann in der Suite für jedes KO einen Parameter mit dem entsprechenden Code hinterlegen. Oder du gehst einen anderen Weg:

Du machst ID<->Code Parameter-Paare. D.h. pro Code zwei Parameter. Einen für den Code selbst, und einen eine zugeordnete ID. Dann brauchst du nur eine GA die du von AUßen mit einer ID befeuerst und der Sketch sucht den passenden Code und sendet ihn. Wäre wohl auch Platzsparender im Sketch (da nur ein KO und keine 50...). Allerdings musst du dich bei der Anzahl der Codes festlegen (geht auch nicht dynamisch) und die XML entsprechend groß dimensionieren (was den Parameter-Block betrifft).

--> Github Ticket: https://github.com/KONNEKTING/KonnektingSuite/issues/5

[Eugenius]

Ok, es müssen nicht defines sein, aber zumindest die Constanten oder Array mit IR-Codes.
11 byte String klingt natürlich als die beste/universele Lösung, aber, man muss auch noch andere Sachen mitübergeben. Je nach Protokoll variiert auch die Stringlänge.
Zusammengefasst: für einen Code braucht man: Protokoll, IR-String, Länge, GA. Bei 50 Codes sind es schon 200 Parameter, die auch noch im EEPROM abgelegt werden... es wird schon knapp.
Und in diesem Fall ist das Senden von RAW-Data gar nicht möglich (normalerweise braucht man auch nicht)

[junibart]

Hi,
sowas bau ich auch gerade- allerdings habe ich genau die RAW-Anwendung (man braucht sie also doch...). Meine Dunsthaube wird von einer IR-Fernbedienung gesteuert, die keine der üblichen Codierungen hat. Bin da gerade mit einem Logik-Analyzer dran...

Neben den oben erwähnten Möglichkeiten zum Codieren- Wie wäre es mit folgendem:

- einen TSOP xxxx und einen weiteren Taster anbauen und das erste IR-Signal nach Tastendruck aufzeichnen, dann mit irgendeiner Logik einer GA zuordnen. Damit erschlägt man auch das Problem, den IR-Code erstmal herauszufinden. Oder:

- die Bytes eines IR-Strings einzeln als Parameter übergeben und im Gerät zusammensetzen. geht nur bei sehr wenigen Befehlen...

Meine Vorzugsvariante wäre auch, ganze Strings zu übergeben, ggf. getrennt nach Typ (NEC, RC5,...) und IR-Befehl.
Und wenn man schon mal KNX und IR zusammenbringt, auch gleich einen Empfänger mit konzipieren, der bei Eintreffen von bestimmten IR-Befehlen eine 1 auf definierte GAs sendet.

Für den Transmitter sollte man einen ausreichend dimensionierten Elko in der Schaltung vorsehen. Es werden m.E. Impulsströme bis 100mA für eine ordentliche Reichweite nötig. ich hab meine IR-LED mittels Widerstand auf 40mA begrenzt und erstmal den Transistor eingespart... berauschend ist die Reichweite nicht.

Grüße,
Gunnar

[tuxedo]

Ok, es müssen nicht defines sein, aber zumindest die Constanten oder Array mit IR-Codes.

Kann man machen. Geht halt Speicherplatz drauf den man ggf. für den Sketch braucht. Und Codes per Suite nachrüsten ist dann nicht.

11 byte String klingt natürlich als die beste/universele Lösung, aber, man muss auch noch andere Sachen mitübergeben. Je nach Protokoll variiert auch die Stringlänge.

Kommt drauf an wie man es ablegt... EIn Beispiel meiner Dunstabzugshaube:

[COLOR=#A71D5D][FONT=Consolas][SIZE=12px]const[/SIZE][/FONT][/COLOR][COLOR=#333333][FONT=Consolas][SIZE=12px] [/SIZE][/FONT][/COLOR][COLOR=#A71D5D][FONT=Consolas][SIZE=12px]long[/SIZE][/FONT][/COLOR][COLOR=#333333][FONT=Consolas][SIZE=12px] IRCMD_VENT_1 = 0xE3C01BE2;[/SIZE][/FONT][/COLOR]

Wenn man "0x" wegoptimiert, verbleiben noch 8 Bytes für den String. Tatsächlich sind es aber nur 4 Bytes für den Code (je zwei Zeichen ergeben einen 1-byte Hexwert).

Mit 11 Byte die unser Protokoll ohne erweiterung zulässt, lässt sich das gut erschlagen. Sogar mit ausreichend Reserve. Es ist also nur eine Frage der repräsentation. Statt eines Strings kann ich auch eine Hexwert-Eingabe (in Stringform) machen und dann intern einfach die reduzierte Byte-Form übertragen.

Zusammengefasst: für einen Code braucht man: Protokoll, IR-String, Länge, GA.

Code-Protokoll: Okay, das lässt sich in einem Byte ausdrücken. Damit hast du dann 256 mögliche IR-Protokolle. Sollte reichen.
IR-String: Wie gesagt, können das auch in Form von Raw-Daten machen. Ich geh mal von einem Durchschnitt von 4 Byte pro Code aus.
Länge: Wozu? Das ergibt sich doch aus dem verwendeten IR-Protokoll, oder nicht?
GA: Kommt drauf an ob du für jedes Kommando eine eigene GA willst, oder ob du eine GA hast und der nur eine ID übermittelst.


Wenn man die Lösung über die ID geht hat man pro Code:

1 byte für den Typ
ca. 4 Byte für den Code.

Da man aber das ganze recht "offen" halten sollte (d.h. sich nicht auf 4 bytes im Suite-Protokoll beschränken), wird man volle 11 Byte abspeichern.

Bei 50 Codes sind das 50*11 Byte = 550 Bytes. Dazu kommt noch die Parameter-Länge die auch nochmal 1 byte pro Parameter frisst. Macht nochmal 50 Bytes. Sind wir also bei 600 Bytes für 50 Parameter.

Wir haben 1k EEPROM. Rund 10 byte sind für den den Stack an sich "reserviert". Verbleiben noch 414 Bytes.
Eine GA braucht bei uns mittlerweile 3 bytes (2 für die eigenltiche GA und ein Byte für deren Status). Macht bei 414 verbleibenden Bytes 138 Gruppenadressen die noch möglich wären. Ich denke das sollte reichen ....

Wenn ich alle meine Fernbedienungen (Beamer, SAT-Receiver, AV-Receiver, Bluray-Player, IR-Funksteckdosen-Adapter, ...) auf den Tisch lege und die Knöpfe durchzähle die ich alltäglich brauche, komm ich glaub nicht ganz auf 50 relevante Knöpfe. Denke mit 50 Codes sollte man gut auskommen.

[tuxedo]

Wenn ein tatsächlich proprietäres IR-Protokoll verwendet wird, dann würde ich das nicht über ein universelles Gerät abhandeln, denn der RAW-Fall kann deutlich komplexer werden und sich ggf. mit den bestehenden IR-Libraries gar nicht abdecken lassen. Hier würde ich ein dediziertes Gerät basteln.

[junibart]

Wenn ein tatsächlich proprietäres IR-Protokoll verwendet wird, dann würde ich das nicht über ein universelles Gerät abhandeln, denn der RAW-Fall kann deutlich komplexer werden und sich ggf. mit den bestehenden IR-Libraries gar nicht abdecken lassen. Hier würde ich ein dediziertes Gerät basteln.

Die Komplexität untersuche ich gerade. Immerhin ist die Trägerfrequenz normale 38khz, und das Protokoll sieht eher trivial aus- man sieht im analyzer auf den ersten Blick, welche der 6 tasten gedrückt wurde.

Bin bei diesem Teilprojekt auf jeden fall dabei.
Gunnar

[Eugenius]

Wir müssen zuerst festlegen was wir brauchen:

1. IR-Trans ähnliche Lösung? dann muss es möglichst allgemein sein => für alle nutzbar, aber sehr komplex
2. Nur für einen konkreten Fall (wie bei mir TV+Lautsprecher), dann kann man die Codes auch fest im Sketch hinterlegen und keine große Gedanken machen => wenn man neue Geräte anschafft, dann muss man neuen Sketch einspielen...

Für meine Bedürfnisse reicht die Lösung 2 aus. Dann kann man auch in Richtung allgemeine Lösung gehen.

[coliflower]

Hallo zusammen,

für mein Verständnis - geht es hier um ein Gerät á la irTrans zu bauen ?
DANKE vorab !

[tuxedo]

@Eugen:

Es gibt noch Option 3:

Man legt sich auf max. 50 Codes fest und nutzt eine gemeinsame GA zum ansteuern. Das ist sehr einfach und sehr flexibel und man muss nicht hart im Code hinterlegen. Es fällt lediglich der Use-Case mit proporietären IR Protokollen weg.

[junibart]

Wir müssen zuerst festlegen was wir brauchen:

1. IR-Trans ähnliche Lösung? dann muss es möglichst allgemein sein => für alle nutzbar, aber sehr komplex
2. Nur für einen konkreten Fall (wie bei mir TV+Lautsprecher), dann kann man die Codes auch fest im Sketch hinterlegen und keine große Gedanken machen => wenn man neue Geräte anschafft, dann muss man neuen Sketch einspielen...

Für meine Bedürfnisse reicht die Lösung 2 aus. Dann kann man auch in Richtung allgemeine Lösung gehen.

Für Lösung 2 braucht man dann aber Konnekting nicht mehr. Wenn man die IR-Codes in den Sketch schreibt, kann man die GAs und die phys. Adresse auch so ablegen.
Ich wäre für einen universellen Ansatz, für dessen Programmierung ich die Arduino-IDE nicht mehr bemühen muss.

Gunnar

[tuxedo]

Noch eine Randnotiz:

Man kann ja ein und dieselbe HW mit unterschiedlichen Sketches austatten: Einmal die Universal-Funktion und einmal für die Spezial-Version für ein proprietäres Protokoll.
Ist ja sowieso unwahrscheinlich dass ein IR-Gerät die DAH in der Küche und den TV im Wohnzimmer steuern soll.

[Eugenius]

Also gut, zusammengefasst:

• 1 GA zum ansteuern
• Max. 50 Codes, die man frei vergeben kann (über die Suite)
• Max. 5 Skripten über die selbe GA ansteuerbar
• Standard Protokolle auswählbar machen
• RAW wird (vor erst) nicht unbeschützt

Hab ich was vergessen? Die HW-Menschen müssen aber noch helfen bzgl. IR-LED Ansteuerung (Transistor, Elko, Stromaufnahme, Reichweite...)

[tuxedo]

• Max. 5 Skripten über die selbe GA ansteuerbar

?? Kannst du das ein wenig erläutern?

• Standard Protokolle auswählbar machen

Hab noch nicht geschaut, aber ich vermute mal dass es hierfür schon einige Arduino Libs gibt? Hab bisher nur den umgekehrten Weg implementiert, sprich, den IR Empfang...

[Eugenius]

Skript: Fernseher EIN, Lautsprecher EIN, Eingang 3
Max 5 Stück von solchen Skripten erlauben/anbieten. Jeder Skript hat hat eigene ID, die auch über die GA von Einzelcodes angesprochen wird.

Protokolle sind alle schon vorhanden. Da muss man nur noch richtige Funktion rufen (sendNEC(), sendSAMSUNG...)