Frank M. schrieb:> Wilhelm M. schrieb:>> a) Auslagerung der Deklaration der Funktionsprototypen irmp_int(),>> irmp_get_data() und irmp_ISR() zusammen mit dem typedef für IRMP_DATA in>> eine eigene Header-Datei.>> Ganz habe ich das nicht verstanden. Die externen Deklarationen stehen> doch bereits in irmp.h? Kannst Du mal schematisch andeuten, wie Du irmp> nutzt?
Wenn ich irmp.h inkludiere, dann bekomme ich tonnenweise #define's, die
ich nicht haben will. Die sind ja ohne scope ... deswegen möchte ich die
in meinem C++-Code nicht haben (ich verwende keine Cpp-Makros mehr).
Ich hätte also nur gerne die Prototypen und die typedefs. Dann kann ich
in einer eigenen Header-Datei statt dem folgenden
1
namespaceIrmp{
2
extern"C"{
3
structIrmpData{
4
uint8_tprotocol;// protocol, e.g. NEC_PROTOCOL
5
uint16_taddress;// address
6
uint16_tcommand;// command
7
uint8_tflags;// flags, e.g. repetition
8
}__attribute__((__packed__));
9
10
typedefstructIrmpDataIRMP_DATA;
11
12
externvoidirmp_init(void);
13
externuint_fast8_tirmp_get_data(IRMP_DATA*);
14
externuint_fast8_tirmp_ISR(void);
15
16
}
17
constexpruint8_tRepetition=0x01;
18
19
}
einfach innerhalb des namespaces die (neue) Headerdatei inkludieren (mit
Ausnahme des constexpr ...).
Ganz am Ende(!) meiner (einzigen) Implmentierungsddatei kommt dann:
static_assert(finterrupts>=10000,"IR Interrupts frequeny too low");
4
static_assert(finterrupts<=20000,"IR Interrupts frequeny too high");
5
6
#define F_INTERRUPTS finterrupts
7
8
#define input(x) iRPin::read()
9
10
namespaceIrmp{
11
#include"irmp/irmp.c"
12
}
>> "header-only Libs" hört sich danach an, dass Du den IRMP-Source> includest statt dazuzubinden mittels IRMP_USE_AS_LIB. Ist es das?
Ja: s.o.
>>> b) das Cpp-Macro input(x) mit einem #ifndef versehen.>> #ifndef WAS-Denn?
Ja, das Macro eben, damit ich das obige benutzen kann ;-)
Also etwa:
Frank M. schrieb:> Marcel schrieb:>> kannst Du noch bitte das SAMSUNGAH Protokoll in IRSND übernehmen?>> Gern. Läuft es denn im IRMP? Laut Deinem letzten Beitrag wolltest Du es> testen und Dich dann nochmal melden...
Entschuldige. Ja wir haben es getestet und es sieht gut aus.
Die Werte sind, bis auf die wechselnden Tasten, immer identisch.
Man kann also sehr gut damit arbeiten =). Danke hierfür!
Jörg R. schrieb:> In 3.0.7 ist SAMSUNGAH defaultmäßig an.> Damit gehen verschiedene andere Protokolle nicht mehr.> Das sollte auf defaultmäßig aus.
Upps, da habe ich vergessen, es nach dem Test wieder abzuschalten.
Sorry, ich deaktivier das wieder. Danke für den Hinweis.
Marcel schrieb:> ich wollte mal fragen was der Stand ist bzgl. dem SamsungAh Protokoll> und IRSND?
Sorry, ich bin noch nicht dazu gekommen. Aber ich denke, dass ich das am
kommenden Wochenende fertigstellen werde.
Hallo,
würde das Interesse bestehen das Protokoll von MCE Funkfernbedienungen
für PCs wie es sie z.B. von Medion, Toshiba oder Pearl gibt/gab zu
integrieren?
Stefan B. schrieb:> würde das Interesse bestehen das Protokoll von MCE Funkfernbedienungen> für PCs wie es sie z.B. von Medion, Toshiba oder Pearl gibt/gab zu> integrieren?
Ja, auf jeden Fall.
Frank M. schrieb:> Ja, auf jeden Fall.
Prima, dann wurdest du mir nicht umsonst im VDR-Portal empfohlen. ;-)
Ich bin leider kein top Programmierer und habe quasi null Erfahrung mit
Protokollanalyse, trotzdem habe ich mich mal mit dem kleinen Saleae
Logic Analyzer versucht.
Ich kann gerne mal jeden Tastendruck aufnehmen und hier die Logic oder
die CSV Datei(en) anhängen.
Zum Datenabgreifen habe ich einen Empfänger geöffnet, einen IC
vorgefunden für den man ein Datenblatt findet und der Datenausgang auf
eine Lötöse geführt wird.
Sagt mir was ihr ihr braucht und ich stelle euch die Daten zur
Verfügung. :-)
Heute, bzw. gestern habe ich IRMP auf einem China STM32F103C8T6 Mini
Development Board mit libopencm3 [1] zum Laufen gebracht. Es waren nur
geringe Änderungen/Ergänzungen nötig (Diff im Anhang). Wenn Interesse
besteht, die Änderungen in die Codebasis zu übernehmen, würde ich das
ganze noch etwas aufhübschen und ein lauffähiges Beispielprogramm
nachreichen.
Und vielen Dank für den super Decoder. Hat auf Anhieb funktionert. Um
meinen vor Jahren mal geschriebenen RC5-Decoder anzupassen, hätte ich
wahrscheinlich länger gebraucht.
[1] https://github.com/libopencm3/libopencm3
Leo C. schrieb:> Wenn Interesse besteht, die Änderungen in die Codebasis zu übernehmen,> würde ich das ganze noch etwas aufhübschen und ein lauffähiges> Beispielprogramm nachreichen.
Sehr gern kann ich Deine Änderungen in die Codebasis übernehmen.
Frank M. schrieb:> Marcel schrieb:> ich wollte mal fragen was der Stand ist bzgl. dem SamsungAh Protokoll> und IRSND?>> Sorry, ich bin noch nicht dazu gekommen. Aber ich denke, dass ich das am> kommenden Wochenende fertigstellen werde.
Hi,
wollte mal fragem was der aktuelle Stand ist.
Gruß Marcel
Meine libopencm3 Anpassungen dürften inzwischen einigermaßen vollständig
sein. IRSND läuft jetzt auch, und zuletzt habe ich das IRMP-Logging über
einen USART eingebaut.
Wens interessiert: Die Demoprogramme können unter [2] und das angepasste
irmp unter [1] heruntergeladen werden.
Am schnellsten gehts mit
@Leo:
>Am schnellsten gehts mit git clone --recursive http://cloudbase.mooo.com/> git/irmp-demo
Nein, damit geht's gar nicht:
ssh: Could not resolve hostname cu.loc: Name or service not known
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
fatal: clone of 'cu.loc:git/irmp' into submodule path
'/tmp/irmp-demo/2/irmp-demo/irmp' failed
Failed to clone 'irmp'. Retry scheduled
Wo kommt dieses cu.loc her?
Wenn ich dann in irmp-demo/.git/config
[submodule "irmp"]
url = cu.loc:git/irmp
durch
[submodule "irmp"]
url = http://cloudbase.mooo.com/git/irmp
ersetze, kann ich per git submodule init/update
das Repo aktualisieren.
Aber dann:
$ make
libopencm3.rules.mk:93: libopencm3/mk/genlink-config.mk: No such file or
directory
libopencm3.rules.mk:167: libopencm3/mk/genlink-rules.mk: No such file or
directory
???
Erstmal danke fürs Testen.
> Wo kommt dieses cu.loc her?
Schlamperei, mein lokaler Nameserver kennt den Host aber.
> Wenn ich dann in irmp-demo/.git/config>> [submodule "irmp"]> url = cu.loc:git/irmp> durch>> [submodule "irmp"]> url = http://cloudbase.mooo.com/git/irmp
Das habe jetzt so auf dem Server korrigiert.
> ersetze, kann ich per git submodule init/update> das Repo aktualisieren.> Aber dann:>> $ make> libopencm3.rules.mk:93: libopencm3/mk/genlink-config.mk: No such file or> directory> libopencm3.rules.mk:167: libopencm3/mk/genlink-rules.mk: No such file or> directory
Bei mir wurde wg. obigem Fehler das Submodul libopencm3 nicht richtig
geladen (Alle Dateien waren gelöscht). Ein 'git reset HEAD' im
Verzeichnis libopencm3 hats gerichtet.
Die Alternative wäre in einem neuen Verzeichnis nochmal ganz vorne mit
'git clone --recursive ...' anzufangen.
Wenn man libopencm3 schon irgendwo installiert hat, kann man auch im
irmp-demo Makefile den Pfad (OPENCM3_DIR) dorthin zeigen lassen.
git clone jetzt ok.
Aber immer noch:
$ (cd libopencm3; git reset HEAD)
$ make
libopencm3/mk/genlink-config.mk:63: libopencm3/lib/libopencm3_stm32f1.a
library variant for the selected device does not exist.
make: Nothing to be done for 'all'.
Das:
>Wenn man libopencm3 schon irgendwo installiert hat, kann man auch im>irmp-demo Makefile den Pfad (OPENCM3_DIR) dorthin zeigen lassen.
geht allerdings.
>Hätte man das wissen müssen?
Ja, wenn man
>libopencm3/mk/genlink-config.mk:63: libopencm3/lib/libopencm3_stm32f1.a>library variant for the selected device does not exist.
richtig interpretiert hätte...
Hallo liebe Leute.
Gibt es beim ATmega 328P irgend welche Besonderheiten die ich beachten
muss, um die IRMP zum laufen zu bekommen. In Anderen Schaltkreisen
ATtiny26_16UP und ATtiny 85 klappe das sofort.
Der ATmega 328P soll andere Pinbezeichnungen haben PORTB6 anstand PB6,
oder müssen andere FUSE Bits gesetzt werden, der Defaultwerte ist 8Mhz
Werksseitig ? Selbst mit der irmp-main-avr.c um eine LED zu Starten
if (irmp_get_data (&irmp_data)) {PORTD = (1<<PORTD7);} Die IDE ist, AVR
Studio 7, und im C Compiler - Symbols ist bei (-D) F_CPU=8000000UL
eigetragen bei Optimization ist (-Os) gesetzt.
Passiert nix.
Liebe Grüße an alle
Ich hab es gefunden, und läuft, Liebe Grüße an Frank.M, ich hatte
vergessen in den Low Fuse das Häckcen für die interne Teilung durch 8
rauszunehmen.
Liebe Grüße Andres
Dieses Projekt is eine super Sache!
Vor vielen Jahren hatte ich mal mit RC5 rumgespielt...
Jetzt soll was mit einer FB vom Schrott angesteuert werden. Die kleinen
Stolpersteine ließen sich durch lesen der Dokumentation vollständig
beseitigen.
Danach geguckt, welches Protokoll verwendet wird, alle anderen
Protokolle wieder ausgeknipst und man kann sich auf die eigentliche
Applikation konzentrieren.
Vielen herzlichen Dank an alle Beteiligten!
Ulf
Hallo,
ich bin neu auf dem Gebiet der AVRs. Ziel meines ersten Projektes soll
es sein, u. a. Relais auf einer Netzteilplatine mittels einer
Fernbedienung zu schalten. Nicht die schwerste Angelegenheit, aber an
einer Stelle hänge ich nun. Mein Code sieht folgendermaßen aus:
//wenn Taste auf Fernbedienung gedrückt
if (irmp_get_data (&irmp_data))
{
//wenn Apple Protokoll
if (irmp_data.protocol == IRMP_APPLE_PROTOCOL)
{
//wenn Play-Taste grdrückt
if (irmp_data.command == 0x05)
{
//wenn Taste nicht lang gehalten (aber entprellt)
if (!(irmp_data.flags & IRMP_FLAG_REPETITION))
{
//wenn ausgeschalteter Zustand
if(prev==0)
{
// toggle Relais
PORTD ^= ((1<<PD6) | (1<<PD4));
// toggle LEDs
PORTB ^= ((1<<PB1) | (1<<PB2));
prev=1;
}
}
//wenn Taste lang gehalten
if (irmp_data.flags & IRMP_FLAG_REPETITION)
{
//wenn eingeschalteter Zustand
if(prev==1)
{
// toggle Relais
PORTD ^= ((1<<PD6) | (1<<PD4));
// toggle LEDs
PORTB ^= ((1<<PB1) | (1<<PB2));
prev=0;
}
}
}
}
}
Natürlich kann man das kürzer schreiben, aber zum Probieren und
Auskommentieren vorteilhaft.
Ich verwende eine Apple Remote. Durch kurzes Drücken der
Play/Pause-Taste sollen die Relais anziehen und durch langes Drücken
wieder abfallen. Das funktioniert auch soweit, allerdings könnte die
Zeitspanne, bis eine langes Drücken erkannt wird länger sein. Kann man
das nachjustieren oder muss ich das in meinem Code berücksichtigen?
Des Weiteren ist es bei der Apple Remote der Fall, dass die
Play/Pause-Taste zwei verschiedene Befehle direkt nacheinander sendet.
Diese sind 0x5f gefolgt von 0x05. Ich habe festgestellt, dass das lange
Drücken in Verbindung mit dem Befehl 0x5f nicht erkannt wird, mit dem
Befehl 0x05 allerdings schon. Wie ist das zu erklären?
Verwende ich nun eine andere Taste, die lediglich einen einzigen Befehl
sendet, habe ich festgestellt, dass mit meinem obigen Code das
vermeintlich kurze Drücken dieser Taste zum Ein- und wieder zum
sofortigen Ausschalten der Relais führt. Der kurze Tastendruck wird also
vereinzelt bereits als langer Tastendruck erkannt? Auch hier stelle ich
wieder die gleiche Frage. Kann die Zeitspanne, nach deren Ablauf ein
langer Tastendruck erkannt wird, vergrößert werden?
Und warum tritt das Verhalten bei der Play/Pause-Taste mit zwei
gesendeten Befehlen nicht auf?
Viele Grüße
Oliver
Oliver schrieb:> Das funktioniert auch soweit, allerdings könnte die Zeitspanne, bis eine> langes Drücken erkannt wird länger sein. Kann man das nachjustieren oder> muss ich das in meinem Code berücksichtigen?
Du hast eventuell die Bedeutung des Flags etwas missverstanden. Flag = 1
heisst nicht unbedingt, dass der Anwender die Taste wesentlich länger
gedrückt hat. Es heisst eher, dass die FB einen Frame wiederholt
ausgesandt hat - meist aufgrund eines längeren Tastendrucks. Das können
auch schon mal 10 Frames (und damit auch 10x IRMP-Daten mit gesetztem
Flag) lang sein, obwohl Du gefühlt erst eine halbe Sekunde gedrückt
hast. Die FB feuert dann halt so schnell sie kann.
> Kann man das nachjustieren oder> muss ich das in meinem Code berücksichtigen?
Jörg hat es mit seiner Antwort schon angerissen.
Hier nochmal mit anderen Worten:
Du musst das selber machen: Zähle einfach, wie oft Du Du einen
Wiederholungsframe erhältst, also wie oft das Flag = 1 hintereinander
gesetzt ist. Teste erstmal den Zähler auf 10, wenn dir das zu lang
vorkommt, dann reduziere den Testwert.
Oliver schrieb:> Ich danke Euch für die Hilfe! Fünf kleine Zeilen ergänzt und es> funktioniert wie gewünscht.
Schön das du uns an der Lösung teil haben läßt, so das Leute mit
ähnlichen Problemen hier gleich die Lösung finden können.
Moin,
da ich irgendwie vergessen worden bin was das Samsung AH Protokoll in
der IRSND Lib angeht, hab ich mich mal selbst versucht da das Projekt
sonst umsonst war!
Reicht es folgenden Block in die irsnd.c aufzunehmen mit entsprechenden
Konstanten in irsndconfig.h?
Leider verstehe ich die Kommentare nich bei den Bitoperationen wie
AAAAAAAAA oder CCCCCCCC. Evtl. kann mir das jmd. erklären.
#if IRSND_SUPPORT_SAMSUNGAH_PROTOCOL == 1
case IRMP_SAMSUNGAH_PROTOCOL:
{
address = bitsrevervse (irmp_data_p->address,
SAMSUNGAH_ADDRESS_LEN);
command = bitsrevervse (irmp_data_p->command,
SAMSUNGAH_COMMAND_LEN);
irsnd_buffer[0] = (address & 0xFF00) >> 8;
// AAAAAAAA
irsnd_buffer[1] = (address & 0x00FF);
// AAAAAAAA
irsnd_buffer[2] = (command & 0xFF00) >> 8;
// CCCCCCCC
irsnd_buffer[3] = (command & 0x00FF);
// CCCCCCCC
irsnd_busy = TRUE;
break;
}
#endif
Hallo,
ich habe mal einen Versuch gestartet irmp in nodemcu unterzubringen und
folglich mittels Lua zugänglich zu machen. Das war letztlich garnicht so
schwer und funktioniert gut. Es reichen dann folgende Aufrufe in Lua:
irmp.init()
irmp.startrecv(
function(pn, n, a, c, f)
print(pn..": addr="..a..", cmd="..c..", flag="..f)
end
)
Mit jedem empfangenen Code wird die Callback-Funktion aufgerufen, die in
diesem Fall das Protokoll, die Adresse, das Kommando und die Flags
ausgibt.
z.B.
NEC: addr=47685, cmd=5, flag=1
Wenn daran Interesse besteht, kann ich das mal zusammen packen und z.B.
hier posten.
Uwe
Hallo Frank
ich benutze das IR-LCD von Klaus Leidinger. Weshalb wird bei einem
normalen NEC-Code (8bit-Adresse, 8bit Befehl) der Code immer 4-stellig
als Hex ausgegeben.
Als Beispiel: Yamaha Fernbedienung RAX9, Power-Taste.
Angezeigt wird: Adresse: 857A , Command: 1F
Ich habe den Schaltplan zum Yamaha Gerät und da stehen auch
die Hex-Codes für die Fernbedienung drin. Power-Taste = Adresse: 7A ,
Command: 1F
Wenn ich jetzt den Code einer Fernbedienung nicht kenne , diesen mit
IRMP auslese und dann in meinem Programm verwende, würde dies ja nicht
funktionieren da die FB ja nur die Hex-Adresse 7A sendet u. nicht 857A.
Wie müßte ich denn IRMP abändern wenn ich die Ausgabe auf dem LCD
nicht im Hex- sondern im Dezimal-Format haben möchte.
Ich bin ein kpl. Anfänger was C betrifft.
Im Vorraus besten Dank
Helmut
Helmut K. schrieb:> Weshalb wird bei einem normalen NEC-Code (8bit-Adresse, 8bit Befehl) der> Code immer 4-stellig als Hex ausgegeben.
Das liegt daran, dass der NEC-IR-Code irgendwann später aufgebohrt
wurde, um mehr verschiedene Geräteadressen zu ermöglichen. Schau Dir das
aus dem IRMP-Artikel an:
https://www.mikrocontroller.net/articles/IRMP#NEC_.2B_extended_NEC
Aus dem NEC-Frame:
Das heisst: die 8 invertierten Adress-Bits gibt es nicht mehr zwingend,
sondern sind nun frei wählbar. Dadurch erhöht sich die Anzahl der
maximalen Geräeteadressen von 265 auf 65536.
Aus diesem Grund verwendet IRMP die kompletten 16 Bit zur Angabe der
Adresse und ist damit abwärtskompatibel zum alten Standard-NEC-Format.
Möchtest Du einen NEC-Code per IRSND auch wieder senden, dann musst
Du für die Adresse deshalb den kompletten 16-Bit-Code für die
Geräteadresse angeben.
> Ich habe den Schaltplan zum Yamaha Gerät und da stehen auch> die Hex-Codes für die Fernbedienung drin. Power-Taste = Adresse: 7A
Der invertierte Wert von 7A (alle Bits kippen) ist 85. Das passt also
perfekt zu 857A, was IRMP ausgibt. Im Yamaha-Handbuch steht halt die
alte Schreibweise drin, als es noch kein Extended NEC-Format gab.
> Wie müßte ich denn IRMP abändern wenn ich die Ausgabe auf dem LCD> nicht im Hex- sondern im Dezimal-Format haben möchte.
In IRMP: Gar nicht. IRMP ist lediglich eine Bibliothek, die keine
Benutzerinteraktion hat und sich schon gar nicht um
Ausgabe-Zahlenformate kümmert.
Die Ausgabe auf dem LCD hat Klaus dazuprogrammiert, wahrscheinlich zu
finden in seinem main.c.
Ich halte von der dezimalen Ausgabe in diesem Fall jedoch wenig bis gar
nichts. Die meisten IR-Fernbedienungen benutzen eine Tastatur-Matrix,
deren Kommandos hexadezimal codiert sind. Da findest Du dann z.B.
1
Taste "1" = 0x11 erste Reihe, erste Spalte
2
Taste "2" = 0x12 erste Reihe, zweite Spalte
3
Taste "3" = 0x12 erste Reihe, dritte Spalte
4
Taste "4" = 0x21 zweite Reihe, erste Spalte
5
Taste "5" = 0x22 zweite Reihe, zweite Spalte
6
Taste "6" = 0x23 zweite Reihe, dritte Spalte
7
Taste "7" = 0x31 dritte Reihe, erste Spalte
8
Taste "8" = 0x32 dritte Reihe, zweite Spalte
9
Taste "9" = 0x33 dritte Reihe, dritte Spalte
Oder auch:
1
Taste "1" = 0x31
2
Taste "2" = 0x32
3
...
4
Taste "9" = 0x39
In dezimaler Schreibweise würde man so eine Systematik schwerlich
erkennen.
> Ich bin ein kpl. Anfänger was C betrifft.
Ich empfehle, Dir zumindest Grundkenntnisse über das Hexadezimal-System
anzueignen. Gerade bei der Programmierung von µCs hilft es ungemein,
Werte hexadezimal lesen zu können - zumindest bis 0xFF. Dafür muss man
nicht konkret wissen, was z.B. 0xE5 in dezimal ist. Es geht lediglich
um das Verständnis.
Dass das Yamaha-Handbuch die Adresse ebenso in Hex (7A) ausgibt, hat
schon einen Grund...
Hallo Frank
danke für deine Antwort.
> Frank M. schrieb>Aus dem NEC-Frame: 8 Adress-Bits + 8 invertierte Adress-Bits> + 8 Kommando-Bits + 8 invertierte Kommando-Bits> wurde irgendwann im Extended NEC-Format:> 16 Adress-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits
Ich hatte mir so etwas schon gedacht.
Danke
Hallo
ich habe die IRMP und IRSND Library erweitert.
Nun werden STM32 Controller mit der HAL-Library unterstützt.
Es ist somit möglich ein Projekt mittels STM32CubeMX zu erstellen und
die Library einzubinden.
Momentan ist die Library so eingestellt, dass wenn man im Cube die 2
benötigten Pins "IRMP_Receive" und "IRSND_Transmit" bennent, diese
direkt von der Library übernommen werden.
In diesem Fall muss man nur noch den Timer in irsndconfig.h anpassen
Verwendet habe ich hierfür das Board "NUCLEO F103RB" mit dem Controller
STM32f103RB.
Da die HAL-Library für alle STM32 Controller gleich ist sollten alle
anderen Controller auch kein Problem sein.
Getestet habe ich es allerdings nur mit dem STM32f103RB.
Matthias F. schrieb:> Nun werden STM32 Controller mit der HAL-Library unterstützt.
Vielen Dank, werde ich mir anschauen und ins nächste Release mit
einbauen :-)
Hallo zusammen,
hat schon mal jmd von euch IRMP Sender & Empfängerroutine als eine
lernbare FB laufen lassen und dazu vll ein fertiges Projekt? Ich suche
eine Möglichkeit 10 Tasten mit B&O Codes zu belegen (eine normale
lernbare FB kann das wg den 455kHz nicht).
Danke!
Ja ist mir klar...wird kein Problem sein, deine Doku ist ja gut. 2xAAA
natürlich nur mit lowvolt AVR...aber dann gehts, oder? Wie groß wird der
Code, reichen 4k (Atiny44 hätte ich noch genug da)?
Klaus
Klaus R. schrieb:> wenn ich NICHT lerne müssten ja auch 2xAAA reichen, oder?
Neuere TSOPs arbeiten auch schon ab 2,5V. Der TSOP wird in dem oben
genannten Projekt vom ATmega selbst versorgt und wird abgeschaltet,
solange man nicht anlernt. Er verbraucht also im Normalbetrieb keinen
Strom.
Bei 2xAAA solltest Du den Basiswiderstand vor dem Transistor anpassen,
nämlich z.B. 820 Ohm wählen.
Anpassungen auf 3V waren klar, die TSOP 2,5V Info kannte ich nicht - ich
prüfe ob TSOP7000 das auch kann, Danke! Code wird um die 7k, mal sehen
ob er unter 4k geht, wenn ich nur B&O nutze.
Werden die Befhele im E² abgelegt, falls mal die Batterie leer ist? Dazu
fand ich keine Infos (würde das dann mit einer 150er LiPo aufbauen).
Tolles Teil und schon fast ein Youngtimer! :) Danke, Frank!
Klaus R. schrieb:> Wie groß wird der Code, reichen 4k (Atiny44 hätte ich noch genug da)?
Wenn Du nur B&O als Protokoll freischaltest, könnten 4k (knapp) reichen,
musst Du ausprobieren. Ich hatte den ATmega gewählt, weil der ein
relativ großes EEPROM zum Speichern der Codes hat. Aber Du kannst
natürlich die Makro-Fähigkeit rauswerfen, schließlich gibts für jede
Taste 3 Ebenen und pro Ebene und Tasten 5 Codes, also 15 pro Taste. 5 x
15 = 75 Codes. Du brauchst aber nur 10.
Sollten IRMP und IRSND zusammen mit dem nötigen Anwendungscode nicht in
die 4K Flash passen könntest Du folgendes machen:
Die 10 Tasten einmal per IRMP (ohne IRSND) anlernen und dann im EEPROM
speichern, anschließend die abgespeckte Anwendung mit IRSND (ohne IRMP)
flashen.
Da bei Dir das Anlernen der 10 Tasten wahrscheinlich ein einmaliger
Vorgang ist, wäre das ein gangbarer Weg für Dich.
...daran dachte ich auch schon - und ob ich die Tasten über den ADC
eines Tiny45 einlesen werde...hmmm :) Das mit der LED als Receiver hat
sich vermtl nie umsetzen lassen, oder (ist ja auch egal, aber sehr
interessant)?
Klaus.
Klaus R. schrieb:> - ich prüfe ob TSOP7000 das auch kann, Danke!
TSOP7000 geht ab 2,7V, sollte also passen.
> Code wird um die 7k, mal> sehen ob er unter 4k geht, wenn ich nur B&O nutze.
Wie gesagt: Du könntest daraus auch 2 Programme machen, eins zum
Anlernen und eins zum Abspielen. Dann sollte es auf jeden Fall passen.
> Werden die Befhele im E² abgelegt, falls mal die Batterie leer ist?
Ja, die werden im EEPROM gespeichert. Beim ATTiny ist natürlich nicht so
viel Platz, da musst Du abspecken, siehe Tipps oben. 10 Codes gehen auf
jeden Fall :-)
Klaus R. schrieb:> Das mit der LED als Receiver hat sich vermtl nie umsetzen lassenLED als Receiver? Das wird wohl nur gehen, wenn Du sämtliche Störungen
aus der Umgebung ausschließen kannst. Nimm lieber einen TSOP, damit geht
das wesentlich entspannter.
...habe IRMP schonmal verwendet um ein altes Radio aus den 70iger FBbar
zu machen, da passten in den Attiny auch alles rein für 10 Tasten plus
das andere Zeug für Releais & Quellenstrg, Anzeige, I2C Poti und so -
ich versuchs mal am Wochenende, bin schon sehr gespannt :)
Danke & schönen Feierabend!
Klaus R. schrieb:> und ob ich die Tasten über den ADC eines Tiny45 einlesen werde..
Ich weiß nicht, ob Du damit den Tiny aufwecken kannst. Normalerweise ist
der verwendete ATmega im Sleep-Mode und verbrät nur wenige µA, um die
Batterie zu schonen.
Klaus R. schrieb:> ...habe IRMP schonmal verwendet um ein altes Radio aus den 70iger FBbar> zu machen, da passten in den Attiny auch alles rein für 10 Tasten plus> das andere Zeug für Releais & Quellenstrg, Anzeige, I2C Poti und so -> ich versuchs mal am Wochenende, bin schon sehr gespannt :)
Na dann viel Spaß!
Wenns läuft, kannst Du Dein Projekt ja gerne vorstellen :-)
...dann muss ich wieder Prügel für den dirty-Code enstecken :) Daher
gibts dann nur Bilder und die B&O Codes (aus dem EEPROM). Aber du weißt
ja, wie das mit so Vorhaben am WE ist - es kommt immer was dazwischen!
:)
Gruß, Klaus.
Klaus R. schrieb:> ...dann muss ich wieder Prügel für den dirty-Code enstecken :)
Wieso "wieder"? ;-)
Ich biete mich gern an, den Code zu überarbeiten, wenn er dann nächstes
... ähem ... übernächstes Wochenende fertig wird ;-)
...so, was ich hier an Geräten nicht habe, habe ich entfernt (zudem UART
+ BOOTLOADER) - bin bei knapp 5k, aber dem Attiny85 ja egal. Afaik läuft
das auch mit internem RC ausreichend sauber, oder (auch beim 455kHz
Protokoll)?
Nun muss ich noch kapieren, wie die Tastenroutine genau funktioniert und
durch den ADC die Tasten auswerten (am besten einfach der existierenden
Routine "vorgaukeln") - da die üblichen Mikrotaster ja immer
Doppelkontakte haben, werde ich damit den ADC und einen PCINT0 bedienen
- dann weckt jeder Tastendruck den uC UND kann per ADC ausgewertet
werden - oder?
Ich würde nur eine LED verwenden und diese je nach gewählter "Bank"
n-Mal blinken lassen. Vll auch beim Senden, damit man immer mal wieder
sieht, "wo" man ist.
EDIT: Aber vll flansche ich das erstmal auf ein BB und teste, ob das B&O
"Master Control Panel 5500" überhaupt damit läuft - sonst kann ich mir
das gleich schenken.
Klaus.
Klaus R. schrieb:> da die üblichen Mikrotaster ja immer Doppelkontakte haben,
Wäre mir neu, wenn sie Doppelkontakte haben. Ich kenne das nur so, dass
jeweils zwei der vier Pins immer paarweise miteinander verbunden sind.
Aber ich lasse mich gern eines besseren belehren :)
> werde ich> damit den ADC und einen PCINT0 bedienen - dann weckt jeder Tastendruck> den uC UND kann per ADC ausgewertet werden - oder?
Hm, wenn die Taster wirklich Doppelkontakte haben, ja. Sonst: nein.
> EDIT: Aber vll flansche ich das erstmal auf ein BB und teste, ob das B&O> "Master Control Panel 5500" überhaupt damit läuft - sonst kann ich mir> das gleich schenken.
Ja. Alles Step by Step.
...da ich den TSOP ja eh sockeln muss (wg 38 vs 455 kHz) überlegte ich,
ob man den OUTPUT Pin (vom uC) der IR Diode nicht als INPUT Pin für den
TSOP nutzen kann (ggf mit Steckbrücke im TSOP Sockel) - beides
gleichzeitig braucht man ja eh nicht und es wäre eine weitere
Optimierung. Geschaltete Stromversorgung für den TSOP entfällt dann eh.
Nun ist mal alles aufs Breadboard gesteckt und ich muss die Register
noch auf Tiny85 ändern, dann erfolgt ein erster Versuch mit einem
"normalen" 38kHz Gerät...
Klaus.
...sooo, nachdem ich kapiert habe, dass IRSND in dem Projekt einfach zu
alt war (Definitionen für die Tinys fehlten), habe ich die neue Version
eingebunden und kann nun über 2 Tasten (Select & PWR) immerhin einen
Befehl aus den 3 Bänken mit dem Tiny schicken. HW und SW sind also
soweit iO, die Glotze geht an/aus. Nun muss die Abfrage der am ADC
angeschlossenen Tasten implementiert werden, (für mich) die eigentliche
Herausforderung an der Sache.
Klaus.
Frank L. schrieb:> Warum die Tasten mit ADC auswerten, wieviele Tasten willst Du abfragen> und wieviele Pins hast Du frei?
Klaus schrieb oben etwas vom ATTiny85. Damit hat man nicht viel
Spielraum ;)
...so, auch das mit dem ADC läuft - ABER aus einem mir noch unbekannten
Grund blockiert der ADC_read(); den IR Empfang / Lernprozess. Das kapier
ich aber heute wohl nicht mehr...alles was sonst so geplant war, läuft.
Fast fertig.
ADCSRA|=(1<<ADSC);// eine Wandlung "single conversion"
29
30
while(ADCSRA&(1<<ADSC)){}// auf Abschluss der Konvertierung warten
31
32
ADC_value=ADCL;// mit uint16_t x
33
ADC_value+=(ADCH<<8);// in zwei Zeilen (LSB/MSB-Reihenfolge und
34
// C-Operatorpriorität sichergestellt)
35
36
returnADC_value;// ADC auslesen und zurückgeben
37
38
}
Den ADC habe ich nun über ein mode-flag während RX bzw TX abgeschaltet,
weil das sonst nicht geht - aber wieso? Iwas bremst der aus...ist das
sampling eine ISR?
@Frank L.: Mein Ziel ist es das ganze zu minimalisieren - ich hatte iwie
keinen Lust auf einen AT168 (und auch keinen da) und Tasten über ADC
auswerten find ich iwie grdstzl pfiffig.
EDIT: cnt = irmp_data[k].flags+1; // get number of frames to send
-> Die "+1" sorgt bei mir dafür, dass der Fernseher (Toshiba!) stehts
an->aus->an geht, vermtl in Verbindung mit der neuen irsnd iwie fehl am
Platze? Gelöscht, geht.
Klaus.
key_poll(); wird in der ISR aufgerufen und triggert dann den
ADC_read();, der mit while alles blockiert - das muss geändert werden,
keine Frage.
@ukw: Wieso aber die Befehle immer 2x gesendet werden (ich schalte in
send_key(); die LED pro Frame einmal an/aus) und der Toshiba dann
ein->aus->ein geht, ist mir noch nicht klar, da bist du aber eher der
Profi? Fehlt dann da das Wiederholungs-Flag? Oder hat sich beim Toshiba
Protokoll etwas geändert? Ich versuche es mal mit anderen IR Geräten...
Klaus.
ADC wird nun alle x-ms aufgerufen, die Diodenveroderung mit PCINT1
funktioniert auch, alles läuft. sleep_cpu() musste ersetzt werden, bin
nun im tiefschlaf im AT85. Fast fertig, dann muss ich noch eine HW (die
den Namen verdient) mit etwas WAF fertigen...und der TSOP7000 muss mich
endlich erreichen (oder ich zapfe den Beomaster direkt an).
EDIT: Letztes Problem ist, das durch Umbau auf ADC Tasten der Prog-Modus
immer einen "Abbruch" erkennt, bin aber noch nicht ganz dahinter
gekommen, wo & warum...
Klaus.
...mit einer JVC FB geht es, es wird nur 1x gesendet (bzw das
entsprechende "Toggle Bit" gesetzt), der Receiver regiert nur mit "an"
oder "aus". Vermutung ist also, das im IRMP beim Toshiba Protokoll etwas
nicht ganz stimmt...falls du Infos brauchst (ein eep Dump zB), gerne.
EDIT: Der Abbruch wurde ausgelöst, weil der ADC dtl seltender die Tasten
abfragt und daher noch der "alte" Wert drnsteht, was zu einem Abbruch
führt:
else if (key == KEY_PROG_VALUE)
{
cancelled = TRUE;
break;
}
Klaus.
...so, wenn ich das Ganze auf der Ziel-HW habe, dann ist wieder das
Problem, dass die ADC Werte der Tasten etwas unterschiedlich zum
Breadboard sind - hier wäre nun noch eine Anlern-Routine sinnvoll:
Drücke 3x Taste n bis LED kurz an geht, dann Taste n+1...usw, die
Mittelwerte dann inkl. im EEPROM sichern und mit einer erlaubten
Abweichung zur Auswertung nutzen. Mal sehn...
Klaus.
Klaus R. schrieb:> Wieso aber die Befehle immer 2x gesendet werden (ich schalte in> send_key(); die LED pro Frame einmal an/aus) und der Toshiba dann> ein->aus->ein geht, ist mir noch nicht klar,
Ich hatte Dir ja schon geantwortet per Mail, eben gerade nochmal.
Du solltest beim Anlernen grundsätzlich Wiederholungsframes ignorieren,
also nur die Frames speichern, wo das Repetition-Flag NICHT gesetzt ist.
Pseudocode:
...ich hatte dir auch schon geantwortet :) und bin davon ausgegangen,
das irmp & irsnd das in Verbindung mit remotecontrol.c
(DIY_Lernfähige_Fernbedienung_mit_IRMP) selber regeln - das war aber
dann wohl falsch. Also muss ich morgen "mal gucken".
EDIT: Vll liegt hier der Hase im Pfeffer...:
1
while(ms_cnt<250)
2
{
3
// some devices need a repeated frame to accept the command, e.g. POWER command on Toshiba TV to switch off
4
if(!cancelled&&irmp_data[k].protocol!=0xFF)// after 250 ms....
5
{
6
IRMP_DATAid;
7
8
if(irmp_get_data(&id))// ... receive IR signal again
9
{
10
if(id.flags==1)// it's a repeated frame, store it!
Klaus R. schrieb:> Vll liegt hier der Hase im Pfeffer...:
Ja, glaube ich auch.
> // some devices need a repeated frame to accept> the command, e.g. POWER command on Toshiba TV to switch off
Mittlerweile kann ich mich daran wieder erinnern. Ich hatte damals auch
einen Tobshiba-Fernseher. Der wollte immer 2 Frames beim
Ein-/ausschalten, sonst hat der Fernseher nicht reagiert. Die
Original-FB hat das auch immer brav bei der Power-Taste so gemacht, egal
wie kurz man die Power-Taste gedrückt hat.
Aus diesem Grund habe ich auch die Anzahl der Wiederholungen im EEPROM
gespeichert.
Das war aber wohl ein spezielles Feature meines Fernsehmodells. Ich
empfehle Dir daher, den Code folgendermaßen zu ändern:
Die letzte Zeile aus Deinem Code-Auszug:
1
irmp_data[k].flags=framecnt;
folgendermaßen ändern:
1
irmp_data[k].flags=0;
Bei Deiner FB sollte es aber eigentlich nur passieren, wenn Du beim
Anlernen die Taste zu lange drückst. Mit obiger Änderung sollte es dann
kein Problem mehr sein.
Klaus R. schrieb:> GENAU das hatte ich QnD morgen vor!
Gut.
> Toshiba hat das übrigens geändert ;)
Das glaube ich. Ist auch schon 7 Jahre her, wo mir das aufgefallen ist.
Übrigens steht im Artikel der DIY-FB:
"Die Tasten auf der Originalfernbedienung sollten sehr kurz gedrückt
werden, da die Wiederholbefehle mitgespeichert werden"
Das ist dann mit obiger Änderung dann auch hinfällig.
...hatte heute morgen noch ne Std Zeit - funktioniert nun. Ich glaube,
das lag aber letztendlich daran, dass der ADC die Tasten zu langsam
sampelt und daher der Befehl "Taste x gedrückt" 2 Sendezyklen auslöste.
Habe den Code auch kommentiert und vertikutiert - wenn das auf der
finalen HW läuft, dann poste ich den auch hier, weil das Ganze schon
sehr adrett & minimalistisch geworden ist.
Klaus.
Klaus R. schrieb:> Ich glaube, das lag aber letztendlich daran, dass der ADC die Tasten zu> langsam sampelt und daher der Befehl "Taste x gedrückt" 2 Sendezyklen> auslöste.
Ja, das klingt plausibel. Hast Du auch schon den Sleep-Modus umgesetzt?
Wenn ja, wie hoch ist dann noch der Stromverbrauch?
...nicht für mich messbar, ich bin im kompletten deepsleep Nirvana. Iwo
im x uA Bereich, damit unerheblich da ich ja ne LiPo nutze (siehe Foto
oben).
Klaus.
...so, nachdem ich - mangels debug Möglichkeit aus dem "inneren des
Attiny" - ewig nach den letzten Fehlern auf der Ziel-HW gesucht habe,
funktioniert nun auch die Lernroutine der Tasten. Man baut die FB auf,
wählt schön gleichverteilte Widerstände und beim Einsetzen der Batterien
drückt man kurz alle Tasten in einer festgelegten Reihenfolge - die ADC
Werte werden dann im E² abgelegt. Damit sind Toleranzen etc egal...hoffe
ich ;)
Die Todo & Ideen-Liste wird immer kürzer, einzig eine Doppelbelegung der
5 Funktionstasten (exkl. SELECT) mit Longpress-Funktion wäre noch
interessant (z.B. MUTE auf VOL- bei Longpress). Das wären dann 10 Fkt
pro Bank bei 5 Tasten.
Aber so langsam frage ich mich auch, wieso ich mir nicht einfach eine
2te Harmony 300 gekauft habe ;)
Klaus.
...so, das war jetzt - auf dem letzten Meter ist dann noch der
ungesockelte AT85 auf der Ziel HW hopps gegeangen...war ja klar :)
Anbei Bilder & Code als Inspiration...
Klaus.
5 Tasten sind im praktischen Betrieb zu wenig, mir fehlen zB Mute und
Prg1...also muss ich doch noch auf longpress erweitern, vll gleich mit
Peter Ds Taster-Lib, die aber erst ADC fähig werden müsste...puh O.o
Klaus.
...an bestimmten Stellen wird auf "gültiges Protokoll" geprüft oder dies
auf "ungültig" gesetzt (0xFF) wenn ein Lernvorgang beendet wurde - das
initiale .eep enthält aber 0-en, so dass erstmal alle Code gültig sind.
Ich habe hierzu #defines eingeführt mit VALID 23 / INVALID 0 und setze
diese. Zudem leuchtet die Sende-LED nur sehr kurz, wenn erfolgreich
gesendet wurde, bleibt aber dtl länger an, wenn man einen "leeren" Platz
erwischt hat.
Das mit der Doppelbelegung durch longpress ist noch etwas aufwendiger,
aber die letzte Hürde. Anbei der Code in v2.0
Klaus.
Hallo Frank,
ich habe nun einen TSOP7000 erhalten (von Sascha, Danke!) und es ist wie
es hat sein müssen - IRMP erkennt den Code nicht. Hast du eine Idee, ob
es mehrere Code bei B&O (Mein Receiver ist BJ85 mit Bedienteil "Master
Control Panel 5500") gibt? Verwundert es dich vll gar nicht? UART wird
bei mir eng, weil ich ja "minimalistisch" unterwegs bin, könnte ich aber
auf dem Breadboard iwie drankommen, denke ich.
Vll helfen ja die "screenshots" im Anhang (Überblick / die ersten 3
Startimpulse) bei einer ersten Idee? Wäre toll, wenn du mir helfen
könntest...hat aber keine Eile!
Gruß, Klaus.
EDIT: Das scheint es wohl nicht zu sein...ist das "dein" Protokoll`?
Frequency: 455 kHz
Coding: pulse distance (manchester biphase code)
Frame: 4 start bits + 16 data bits + 1 trailer bit + 1 stopbit
Data: 8 address bits + 8 command bits
Start-Bit 1: 200µs puls, 3125µs pause
Start-Bit 2: 200µs puls, 3125µs pause
Start-Bit 3: 200µs puls, 15625µs pause
Start-Bit 4: 200µs puls, 3125µs pause
0-Bit: 200µs puls, 3125µs pause
1-Bit: 200µs puls, 9375µs pause
R-Bit: 200µs puls, 6250µs pause, repetition of last bit
Trailer bit: 200µs puls, 12500µs pause
Stop bit: 200µs puls
Repetition: none
Pushbutton repetition: N-times repetition of original-frames within
100ms
Bit order: MSB first
Klaus R. schrieb:> ich habe nun einen TSOP7000 erhalten (von Sascha, Danke!) und es ist wie> es hat sein müssen - IRMP erkennt den Code nicht.
Schade, wahrscheinlich benutzt(e) B&O verschiedene Codierungen.
> Vll helfen ja die "screenshots" im Anhang (Überblick / die ersten 3> Startimpulse) bei einer ersten Idee? Wäre toll, wenn du mir helfen> könntest...hat aber keine Eile!
Am besten wären ein paar Scans (mit eingeschaltetem IRMP_LOGGING, siehe
Artikel). Leider hat der ATTiny keinen UART. Du müsstest es also
entweder über SW-UART erstellen oder doch einen AVR nehmen, der auch
einen HW-UART hat.
Anhand solcher Scans kann ich dann ziemlich flott ein neues Protokoll
einbauen.
> EDIT: Das scheint es wohl nicht zu sein...ist das "dein" Protokoll`?
Das habe ich auch aufgrund von Scans, die ich von einem User erhalten
habe, eingebaut. Er hat mir dann auch bestätigt, dass es so
funktioniert. Wenn ich es richtig in Erinnerung habe, habe ich damals
auch eine Dokumentation im Internet zu diesem Protokoll gefunden.
Also: Wenn Du mir Scan-Dateien zuschickst, baue ich es gerne ein.
Hallo Frank,
gut, dann sattel ich den ganzen Kram (bzw nur irmp.h) in der kommenden
Woche nochmal auf ATMEGA um und schicke dir entsprechende Scans - jetzt
aufgeben ist keine Option :)
Ich habe in deinem Artikel gelesen, wie man die analysiert, bin mir aber
unsicher ob deine irmp.exe nach Einlesen der scans direkt die für irmp.h
relevanten Daten rausspuckt...ich überlasse das daher gerne & dankbar
dem Profi!
Gruß, Klaus!
Klaus R. schrieb:> Ich habe in deinem Artikel gelesen, wie man die analysiert, bin mir aber> unsicher ob deine irmp.exe nach Einlesen der scans direkt die für irmp.h> relevanten Daten rausspuckt...ich überlasse das daher gerne & dankbar> dem Profi!
Spuckt die Exe schon aus, aber wahrscheinlich ist es besser, Du schickst
mir die Scans zu. Ich glaube, die Exe kann nur Scans mit 10kHz
auswerten. Außerdem hat sie schon ein paar Jahre auf dem Buckel.
Frank M. schrieb:
[...]
> Das habe ich auch aufgrund von Scans, die ich von einem User erhalten> habe, eingebaut. Er hat mir dann auch bestätigt, dass es so> funktioniert. Wenn ich es richtig in Erinnerung habe, habe ich damals> auch eine Dokumentation im Internet zu diesem Protokoll gefunden.
[...]
Wenn ich mich richtig erinnere war ich derjenige, der damals die Scans
gemacht hat.
Die Scans wurden mit einer B&O-Fernbedienung "Video Terminal
Bang&Olufsen", Baujahr ca. mitte '90 erstellt und die Funktion in IRMP
von mir auch mit modernen B&O-FB geprüft.
Wahrscheinlich hatte B&O in den 80'ern noch ein anderes Protokoll.
Gruß,
f
Hallo,
Ich habe schon seit viel Jahre auf Deutsch nicht gesprochen.
Ich habe einige IR-scan von Samsung, Akai and Gree.
Wer kann mir helfen in diesem Topik?
If possible in English :)
Danke schon!
Als leidenschaftlicher Nutzer von ChibiOS (http://www.chibios.org)
wollte ich IRMP auch in meinen ChibiOS-basierten Projekten verwenden und
habe daher eine Integration geschrieben. Da IRMP ja mittlerweile schon
für einige Plattformen verfügbar ist und daher entsprechende defines
vorsieht, war das auch gar nicht mal so schwer oder viel Code.
Patch ist angehängt und ich würde mich über eine Aufnahme ins offizielle
IRMP-Repo oder Kritik und Verbesserungsvorschläge freuen.
Nachdem ChibiOS als RTOS auch so nette Dinge wie Events mitbringt, auf
die z.B. Threads warten können, habe ich auch dafür eine Unterstützung
eingebaut. Wenn man das in der irpmconfig.h mit IRMP_USE_EVENT aktiviert
und einen passenden Threadpointer und Eventflag definiert, bekommt der
Thread einen Event gesendet sobald gültige IR-Daten empfangen wurden.
In der irmp-main-chibios.c wird gezeigt wie man das verwendet.
Ich habe den Code bei mir jetzt mit ChibiOS/NIL Version 18.2.1 auf einem
kleinen STM32F030F4 am Laufen und da ist neben IRMP noch genug Platz für
eine kleine serielle Shell und RGB-LED-Anzeige als Status-Feedback.
Gerd E. schrieb:> Patch ist angehängt und ich würde mich über eine Aufnahme ins offizielle> IRMP-Repo oder Kritik und Verbesserungsvorschläge freuen.
Kann ich gerne machen, danke dafür. Würdest Du dann im IRMP-Artikel
die Besonderheiten, die Du angesprochen hast, auch dort dokumentieren?
Frank M. schrieb:> Kann ich gerne machen, danke dafür.
Danke.
> Würdest Du dann im IRMP-Artikel> die Besonderheiten, die Du angesprochen hast, auch dort dokumentieren?
Deutscher und englischer Artikel sind angepasst.
Ich hoffe das passt so.
Du müsstest nur noch die Versionsnummer eintragen wenn Du den neuen
Release machst.
Gerd E. schrieb:> Deutscher und englischer Artikel sind angepasst.
Super, vielen Dank! :-)
> Du müsstest nur noch die Versionsnummer eintragen wenn Du den neuen> Release machst.
Ich habs gerade eben eingecheckt. Versionsnummer ist nun 3.1.0, passe
ich an.
Das ging ja fix. Wenn alle Opensource-Projekte so schnell beim
Integrieren von Änderungen wären ;)
Frank M. schrieb:> Ich habs gerade eben eingecheckt. Versionsnummer ist nun 3.1.0, passe> ich an.
Wenn ich die SVN-Diffs richtig interpretiere, ist noch das
GREE-Protokoll neu dazugekommen. Das fehlt noch im Changelog & in der
Dokumentation.
Gerd E. schrieb:> Das ging ja fix. Wenn alle Opensource-Projekte so schnell beim> Integrieren von Änderungen wären ;)
Du hast ja auch alles sehr gut vorbereitet. Einmal patch aufgerufen und
das war's. :)
> Wenn ich die SVN-Diffs richtig interpretiere, ist noch das> GREE-Protokoll neu dazugekommen. Das fehlt noch im Changelog & in der> Dokumentation.
Stimmt. Das hatte ich komplett vergessen, da ich es irgendwann
zwischendurch eingebaut habe. Werde ich mir bei Gelegenheit anschauen
und dann die Dokumentation entsprechend aktualisieren.
Vielen Dank nochmal und Kompliment auch an die exzellente Umsetzung und
auch an die perfekte Aktalisierung der Doku - auch der englischen!
Ich halte gerade bei OpenSource Software eine gute Dokumentation für
äußerst wichtig. Leider wird sie oft genug vernachlässigt. Ich war mal
vor 20 Jahren bei einem Vortrag von Richard Stallman zugegen, der an die
anwesenden Entwickler appellierte, sie mögen doch genauso viel Zeit in
die Doku stecken wie in die Entwicklung der Software. Zur Ermunterung
sagte er: "Documentation doesn't crash!". :)
Frank M. schrieb:> Vielen Dank nochmal und Kompliment auch an die exzellente Umsetzung und> auch an die perfekte Aktalisierung der Doku - auch der englischen!
Danke für die Blumen.
Mich hat jetzt aber noch der Ehrgeiz gepackt und ich wollte den
ständigen Aufruf des Timer-IRQs in der (Haupt-)Zeit ohne jegliche
IR-Daten loswerden so daß der µC dann in den Sleepmode gehen kann. Das
ChibiOS gibt sich extra große Mühe tickless zu arbeiten, und dann kommt
das IRMP und macht das alles kaputt ;)
Ich möchte dafür aus der irmp_ISR() eine irmp_idle()-Funktion aufrufen
die von meinem Hauptprogramm gestellt wird. Darin schalte ich dann den
Timer aus und einen Pinchange-IRQ an. Wenn der Pinchange kommt, wird der
Timer wieder gestartet und irmp_ISR() aufgerufen.
Funktioniert soweit schon ganz gut, der Stromverbrauch meines kleinen
Boards mit dem STM32F030F4 und dem IR-Empfänger ist von 15mA auf 9mA im
Idle runtergegangen.
Allerdings muss ich zugeben daß ich in der Statemachine der irmp_ISR
noch nicht so ganz durchsteige.
So sieht mein Code am Ende der irmp_ISR jetzt aus:
+ // check if there is no ongoing transmission or repetition
9
+ if (!irmp_start_bit_detected &&
10
+ !irmp_pulse_time &&
11
+ !irmp_pause_time &&
12
+ !wait_for_start_space &&
13
+ key_repetition_len > IRMP_KEY_REPETITION_LEN)
14
+// TODO: do we need to check irmp_tmp_address, irmp_tmp_command, irmp_bit ??
15
+// TODO: why is wait_for_space kept set after receiving ir data once and then idle?
16
+ {
17
+ // no ongoing transmission
18
+ // enough time passed since last decoded signal that a repetition won't affect our output
19
+
20
+ irmp_idle();
21
+ }
22
+#endif // IRMP_USE_IDLE_CALL
23
+
24
return (irmp_ir_detected);
25
}
Wie im Kommentar vermerkt ist mir aufgefallen, daß nach dem ich ein
IR-Telegramm empfangen habe, wait_for_space immer auf 1 stehen bleibt.
Das hatte ich am Anfang auch immer für die Idle-Bedingung mit abgefragt.
Hat das einen tieferen Sinn oder ist das an der Stelle einfach nicht
relevant und wird daher nicht zurückgesetzt?
Fange ich mit meiner jetzigen Abfrage wirklich alle Fälle von
Übertragung und sonstigen relevanten Pause-Zuständen ab? Oder muss ich
noch weitere Variablen wie z.B. irmp_tmp_address, irmp_tmp_command,
irmp_bit beachten?
Getestet habe ich nur mit NEC-Codes.
Wäre nett wenn Du da nochmal drüberschauen könntest.
Wenn es passt kann ich das als Patch mit Beispiel & Doku fertig machen.
Gerd E. schrieb:> Wie im Kommentar vermerkt ist mir aufgefallen, daß nach dem ich ein> IR-Telegramm empfangen habe, wait_for_space immer auf 1 stehen bleibt.
Merkwürdig. Eigentlich sieht es so aus:
1
if(!irmp_ir_detected)// ir code already detected?
2
{// no...
3
if(!irmp_start_bit_detected)// start bit detected?
4
{// no...
5
....
6
}
7
else
8
{
9
if(wait_for_start_space)// we have received start bit...
10
{// ...and are counting the time of darkness
11
if(irmp_input)// still dark?
12
{// yes
13
...
14
}
15
else
16
{// receiving first data pulse!
17
...
18
wait_for_start_space=0;
19
}
20
}
21
}
22
}
wait_for_start_space sollte also nach dem Empfang des ersten
Daten-Pulses wieder auf 0 zurückgesetzt werden.
> Fange ich mit meiner jetzigen Abfrage wirklich alle Fälle von> Übertragung und sonstigen relevanten Pause-Zuständen ab?
Warum nicht folgende einfache Bedingung?
1
if(!irmp_start_bit_detected&&
2
{
3
irmp_idle();
4
}
Dann sollte der µC außerhalb der Zeit, wenn ein Frame übertragen wird,
schlafen. Reicht das nicht?
Frank M. schrieb:> wait_for_start_space sollte also nach dem Empfang des ersten> Daten-Pulses wieder auf 0 zurückgesetzt werden.
wird es auch. Ich meinte wait_for_space.
> Warum nicht folgende einfache Bedingung?>
1
>if(!irmp_start_bit_detected&&
2
>{
3
>irmp_idle();
4
>}
5
>
>> Dann sollte der µC außerhalb der Zeit, wenn ein Frame übertragen wird,> schlafen. Reicht das nicht?
Naja, also zumindest irmp_pulse_time muss ich noch abfragen, da es ganz
am Anfang erhöht wird, bevor irmp_start_bit_detected überhaupt gesetzt
wird.
Außerdem wird im Idle dann natürlich auch key_repetition_len nicht mehr
erhöht, so daß die ganze Wiederholungserkennung kaputt wäre. Den Check
sollte ich also auch machen.
Die Frage ist halt ob es irgendwelche anderen Zustände geben kann, bei
denen eine Übertragung läuft oder irgendwie auf eine Wiederholung
reagiert wird die ich mit diesen Checks noch nicht abgedeckt hätte.
Weil die Funktionsweise für mich eben nicht ganz offensichtlich war,
habe ich die Kandidaten, die mir relevant aussahen, auch noch mit
geprüft. Aber es kann dennoch sein daß ich irgendeinen Fall übersehen
hab, vorallem welche in den protokollspezifischen Defines. Da gibt es ja
auch noch eigne Repetition-Logik wie z.B. denon_repetition_len.
Gerd E. schrieb:> wird es auch. Ich meinte wait_for_space.
Upps, da habe ich mich verlesen, sorry. Ich habe das gerade mal unter
Linux getestet: Tatsächlich bleibt das Flag nach dem Einlesen eines
kompletten Frames gesetzt. Scheint dann aber keine Rolle mehr zu
spielen, da dann andere Zustandsvariablen greifen. Muss ich mir nochmal
in Ruhe anschauen bzw. ich müsste mal alle Zustandsvariablen
dokumentieren.
> Naja, also zumindest irmp_pulse_time muss ich noch abfragen, da es ganz> am Anfang erhöht wird, bevor irmp_start_bit_detected überhaupt gesetzt> wird.
Stimmt, irmp_start_bit_detected wird natürlich erst nach dem Empfang des
Start-Bits gesetzt. Das war von mir zu kurz gedacht.
Ich habe eben mal unter Linux folgendes im Source testweise eingesetzt:
Alt:
schön beobachten, wie sich die Zustandsvariablen ändern. Eine von beiden
ist während des Empfangs eines IR-Frames immer gesetzt - auch bei den
Repetition-Frames.
Damit sollte diese Bedingung ausreichen:
Frank M. schrieb:> ich müsste mal alle Zustandsvariablen> dokumentieren.
Du warst der, der oben Stallman zum Thema Dokumentation zitierte ;)
> Damit sollte diese Bedingung ausreichen:>
1
>if(!irmp_start_bit_detected&&!irmp_pulse_time)
2
>{
3
>irmp_idle();
4
>}
5
>
Danke für den Testcode und die Analyse. Ich stimme Dir zu....
...bis auf die Prüfung von key_repetition_len.
Wenn ich diesen Code verwende:
1
if(!irmp_start_bit_detected&&!irmp_pulse_time
2
&&key_repetition_len>IRMP_KEY_REPETITION_LEN)
3
{
4
irmp_idle();
5
}
funktioniert alles wie gewünscht. Wenn ich 2x die selbe Taste kurz
hintereinander drücke, wird das IRMP_FLAG_REPETITION-Bit gesetzt. Mache
ich das mit längerem Zeitabstand, wird es nicht mehr gesetzt.
Ohne die Prüfung von key_repetition_len wird das
IRMP_FLAG_REPETITION-Bit immer gesetzt, egal was für ein Zeitabstand
zwischen den Tastendrücken liegt.
Ist auch klar wenn man sich den Code anschaut:
1
if(irmp_ir_detected)
2
{
3
if(last_irmp_command==irmp_tmp_command&&
4
last_irmp_address==irmp_tmp_address&&
5
key_repetition_len<IRMP_KEY_REPETITION_LEN)
6
{
7
irmp_flags|=IRMP_FLAG_REPETITION;
8
}
Wenn hier das key_repetition_len wegen des Sleepmode nicht mehr
hochgezählt wird, ist die Bedingung halt immer wahr.
Ich denke also die Prüfung auf key_repetition_len >
IRMP_KEY_REPETITION_LEN ist notwendig.
Gerd E. schrieb:> Wenn hier das key_repetition_len wegen des Sleepmode nicht mehr> hochgezählt wird, ist die Bedingung halt immer wahr.
Ja, das ist natürlich richtig. Diese Situation ist zur Zeit nicht
simulierbar, da der Simulator sich zwischen den Frames nicht schlafen
legt.
> Ich denke also die Prüfung auf key_repetition_len >> IRMP_KEY_REPETITION_LEN ist notwendig.
Korrekt.
Frank M. schrieb:> Passt und ist online als 3.1.1 :-)
Danke. Die Artikel sind jetzt auch angepasst.
(OT: falls Du das noch nicht kennst: die Übersetzung ins Englische hab
ich https://www.deepl.com machen lassen. Bis auf ein paar kleine
Anpassungen bei den Formulierungen kommt der Text direkt aus der
maschinellen Übersetzung. Ich finde das ist Welten besser als Google
Translator und Konsorten und schon echt brauchbar so.)
Mir ist aufgefallen das am Abend unter Neonlicht zum Teil falsche
Scans/gestörte Scans bei meinem IR Empfänger ankommen (ist jetzt nicht
IRMP) aber habt ihr auch schon solche Erfahrungen gemacht?
Das war jetzt in nem nicht so oft besetzten Labor so wo die Lampen noch
nicht durch LED ausgetauscht wurden.
Gerd E. schrieb:> Danke. Die Artikel sind jetzt auch angepasst.
Prima, danke.
> (OT: falls Du das noch nicht kennst: die Übersetzung ins Englische hab> ich https://www.deepl.com machen lassen.
Kannte ich noch nicht. Aber ein paar kurze Stichprobentests haben mich
überzeugt. Der ist schon verdammt gut... Lesezeichen gesetzt :-)
Markus schrieb:> Mir ist aufgefallen das am Abend unter Neonlicht zum Teil falsche> Scans/gestörte Scans bei meinem IR Empfänger ankommen (ist jetzt nicht> IRMP) aber habt ihr auch schon solche Erfahrungen gemacht?>> Das war jetzt in nem nicht so oft besetzten Labor so wo die Lampen noch> nicht durch LED ausgetauscht wurden.
Ähnliches hab ich früher schon gelesen.
Auf die Schnelle ("neonlicht stört ir fernbedienung") z.B. das hier
gefunden:
https://www.tt-board.de/forum/threads/leuchtstoffroehre-vs-infrarot.46583/
Markus schrieb:> Mir ist aufgefallen das am Abend unter Neonlicht zum Teil falsche> Scans/gestörte Scans bei meinem IR Empfänger ankommen (ist jetzt nicht> IRMP) aber habt ihr auch schon solche Erfahrungen gemacht?
Ja, das ist allgemein bekannt.
Bei IRMP können solche gestörten IR-Frames ziemlich gut aussortiert
werden, da hier die Pulse nicht nur stumpfsinnig aufgezeichnet werden,
sondern immer erst das Protokoll ermittelt und dann sämtliche
Pulse/Pausen auf Plausibilität geprüft werden.
Dabei werden on-the-fly bzw. abschließend folgende Regeln geprüft:
1. Sind die Puls-/Pause-Zeiten innerhalb der für das Protokoll
definierten Toleranzen?
Das gilt für jedes Protokoll.
2. Sind CRCs/Parity-Bits im Protokoll enthalten?
Wenn ja, stimmen diese mit den empfangenen Daten überein?
Beispiele:
Kaseikyo (Japan) Protokoll: 4 + 8 Parity Bits
LEGO: 4 Bits CRC
3. Sind Redundanzen im Frame enthalten?
Wenn ja, stimmen diese (nach eventueller Transformation) überein?
Beispiele NEC, SAMSUNG und BOSE:
Daten liegen sowohl als nicht-invertierte als auch als invertierte
Bits in demselben Frame vor.
4. Werden die IR-Frames mit n-facher Wiederholung gesandt?
Wenn ja, stimmen die Frames vom Inhalt auch überein?
Beispiele:
DENON: im 2. Frame ist das Kommando invertiert.
SAMSUNG48: der 1. Frame wird immer ein zweites Mal wiederholt.
KASEIKYO: der 1. Frame wird optional innerhalb 50ms wiederholt
SONY (SIRCS): der 1. Frame wird optional innerhalb 50ms wiederholt
Matthias F. schrieb:> Hal
Habe die STM32 HAL Implementierung soweit getestet. Frank hast kannst du
die Erweiterung von Matthias F. aus Beitrag #5328596 noch übernehmen?
Gruß
Stephan
technikus schrieb:
Habe die STM32 HAL Implementierung soweit getestet.
technikus eine Frage an Sie oder an jemanden, der es geschafft hat. Ich
habe versucht, ein Projekt STM32 mit HAL auszuführen, aber es
funktioniert nicht. Es ist möglich, dass ich etwas falsch mache. Obwohl
es keine Fehler gibt. Können Sie mir Ihre Projektumsetzung per E-Mail
schicken (jonkul001@utp.edu.pl)?
technikus schrieb:> Frank hast kannst du> die Erweiterung von Matthias F. aus Beitrag #5328596 noch übernehmen?
Die habe ich aus irgendwelchen Gründen übersehen/vergessen. Hole ich
nach.
technikus schrieb:> Frank hast kannst du die Erweiterung von Matthias F. aus Beitrag> #5328596 noch übernehmen?
Die Änderungen sind nun online, die Doku wurde angepasst.
Viel Spaß,
Frank
Jonas,
beschreib doch mal dein Problem.
Bekommst du Fehler beim Compilieren?
Im Grunde wird irmp ja nur initialisiert und in der Timer ISR
aufgerufen.
Die ISR Frequenz ist sehr wichtig. Bei STM32 ist die richtige Clock
Config wichtig.
Ich toggle immer erst eine LED in der ISR und prüfe mit dem Oszilloskop
die Frequenz...
Gruß
Stephan
Hallo Frank,
gerne möchte ich mir eine T+A Fernbedienung zulegen um mein DIY
Vorverstärker zu steuern. Deshalb habe den Hersteller angefragt welches
Protokoll implementiert ist.
Hier die Antwort:
RC2
Habe das Dokument vom Hersteller hier hochgeladen
https://filehorst.de/d/cFypmGgi
Ist es denkbar das Protokoll anhand dieser Daten in irmp zu
implementiern?
Dann würde ich mir das Teil bestellen.
Danke und Gruß
Stephan
technikus schrieb:> Ist es denkbar das Protokoll anhand dieser Daten in irmp zu> implementiern?
Ja. Das ist einfacher Manchester Code ("bi-phase"). Allerdings gibt es
als Besonderheit noch dieses Pre-Bit vor dem eigentlichen Start-Bit. Ich
würde es als Protokoll mit 2 unterschiedlichen Start-Bits
implementieren.
Reicht die Protokoll-Erkennung (IRMP) oder soll auch gesendet werden
(IRSND)?
Noch eines: Die 31,25 kHz Modulationsfrequenz sind etwas ungewöhnlich.
Ich würde dafür nicht unbedingt einen TSOP nehmen, der auf 38kHz
abgestimmt ist, sondern eher einen für 30kHz, wie den TSOP31230. Oder
den TSOP31233 für 33kHz.
technikus schrieb:> IRMP, also Empfang würde reichen.
Die Version 3.1.3 ist online.
Neuerung:
- Neues Protokoll: RC II (T+A)
Den IRMP-Artikel habe ich ebenso aktualisiert. Dank der sehr guten
Dokumentation zu diesem Protokoll konnte ich die Erkennung des
Protokolls zügig umsetzen. Zum Testen habe ich eine Scan-Datei
IR-Data/rcii-15kHz.txt mit dem Editor erstellt, welche alle Codes der FB
berücksichtigt. Es könnte noch sein, dass man noch etwas an den
Toleranzen schrauben muss. Das wird sich dann herausstellen, sobald die
Fernbedienung mit IRMP gestestet werden kann.
Viel Spaß,
Frank
Hallo,
ich versuche gerade IRMP so zu erweitern, dass er das Merlin-Protokoll
vollständig und Fehlerfrei unterstützt, im Moment wird nur ein Teil
fehlerhaft unterstützt.
Die Herausforderung ist, dass es eine variable Länge hat und Manchester
kodiert ist. Das Dunkel am Ende kann, muss aber nicht, Teil des letzten
Bits sein:
Beispiel für Taste loslassen:
Start-Bits: 10
Adresse: 00000001
Ergibt dann (1 Dunkel, ein Zeichen pro Symbol):
...1111|0110|1010101010101001|1111...
Beispiel für die Taste A:
Start-Bits: 10
Adresse: 00000001
Kommando: 00000100
End-Bit: 1
Ergibt dann (1 Dunkel, ein Zeichen pro Symbol):
...1111|0110|1010101010101001|1010101010011010|01|1111...
Beispiel für die Taste B:
Start-Bits: 10
Adresse: 00000001
Kommando: 00000101
End-Bit: 0
Ergibt dann (1 Dunkel, ein Zeichen pro Symbol):
...1111|0110|1010101010101001|1010101010011001|10|1111...
Wie man aus den Trennstrichen sieht, ist das letzte Bit z.T. im
Endbereich wo es nicht mehr hell wird.
Die Anzahl der Kommando-Bytes kann zwischen 0 und 4 liegen, wenn ein
Kommando-Byte kommt, dann kommt auch ein End-Bit am Schluss des Frames
welches immer das Inverse des Bits davor ist.
Ich habe schon etwas rumgebastelt, aber ich bekomme es nicht hin, das
alles geht, entweder 01 am Ende geht oder 10.
Die Kommando-Länge habe ich bereits auf 32 Bit geändert wenn Merlin
aktiviert ist, dazu kommt noch ein Feld was dann die Kommando-Länge
enthalten soll.
Ich verstehe auch noch nicht alles in dem Code, vielleicht kann mir
jemand helfen das einzubauen. Im Idealfall würde es auch das offizielle
IRMP übernommen, aber es erfordert halt eine Erweiterung der API.
Vielen Dank
Stefan
Stefan O. schrieb:> Ich verstehe auch noch nicht alles in dem Code, vielleicht kann mir> jemand helfen das einzubauen.
Kannst Du Scans mittels IRMP_LOGGING erstellen und diese dann hier zur
Verfügung stellen? Das wäre das einfachste für mich.
Erstaunlich, dass es immer noch Protokolle gibt, die nicht in IRMP
integriert sind :-)
Wäre es nicht auch mal möglich, IRMP in die "offizielle" Arduino Library
zu integrieren, so dass man es einfach über die IDE aktuelle halten und
auf allen µC nutzen kann? Ich frage für nen Freund… hust
Stefan Z. schrieb:> Erstaunlich, dass es immer noch Protokolle gibt, die nicht in IRMP> integriert sind :-)
Doch, das Merlin-Protokoll, um welches es geht, ist bereits integriert.
Aber offenbar ist die Integration unvollständig, ich kann halt nur das
umsetzen, was man mir als Stoff (in Form von Scans) liefert. Denn ich
kann nicht alle Fernbedienungen der Welt vorrätig haben. Außerdem weiß
ich aus Erfahrung, dass es zu vielen Protokollen etliche
herstellerspezifische "Erweiterungen" gibt. Wahrscheinlich ist dies hier
auch der Fall.
> Wäre es nicht auch mal möglich, IRMP in die "offizielle" Arduino Library> zu integrieren, so dass man es einfach über die IDE aktuelle halten und> auf allen µC nutzen kann? Ich frage für nen Freund… hust
Klar, mach. ;-)
Das Arduino-Problem ist wohl folgendes: IRMP braucht einen
Timer-Interrupt. Da kann man unter Arduino wohl nicht jeden x-beliebigen
Timer nehmen, weil das Arduino-Runtime-System bereits einen für sich
reserviert - jedenfalls bei AVR. Wie das bei anderen µC-Familien ist,
entzieht sich meiner Kenntnis.
Es gibt bereits Portierungen von IRMP für Arduino, einfach mal im
IRMP-Artikel nach Arduino suchen. Diese Ports wurden aber wohl immer
nur für einen speziellen µC durchgeführt und niemals so allgemein
formuliert, wie es der IRMP-Source generell ist. Zudem kann ich über die
Qualität der jeweiligen Portierung nichts sagen.
Stefan Z. schrieb:> Wäre es nicht auch mal möglich, IRMP in die "offizielle" Arduino Library> zu integrieren,
das habe ich mit einer älteren Version von IRMP schon geschafft (ist ja
"nur" C), einfach einen arduinofreien Timer wählen, ABER die letzten
IRMP waren so monster groß das die IDE überlastet wurde.
Frank M. schrieb:> Klar, mach. ;-)
Ich bin mir nicht sicher, ob das zielführend wäre.
Ich habe vor Jahren mal eine IRMP Version auf Arduino umgebastelt, die
nutze ich auch noch, aber sauber war das nicht zu 100%.
Arduino ist ja eh an so vielen Stellen total bekloppt.
Die seltsame Board-From die keinen Sinn ergibt.
Die Abstände der Pinleisten.
Die Platzierung der Bohrlöcher.
IRMP kann man aber schon auf andere Timer umbiegen, vor allem weil
Arduino doch nur T0 für Millis u.Ä. nutzt:
"The standard Arduino has 3 timers, timer0 is 8 bit and used for the
millis() and micros() functions. Timer1 is 16 bit and not used by
default, timer2 is another 8 bit timer like timer0 but not used by
default."
http://sphinx.mythic-beasts.com/~markt/ATmega-timers.html
Es hatte mich nur gewundert, weil IRMP ja schon sehr
"Scheckheftgepflegt" ist und super sauber implementiert.
Vielleicht sehe ich es mal als persönliches Lern-Projekt, aber das ist
schon einschüchternd viel was man wissen muss, um auf dem Level dann die
Integration in Arduino zu machen.
Stefan Z. schrieb:> Die seltsame Board-From die keinen Sinn ergibt.> Die Abstände der Pinleisten.
ergibt schon Sinn, bastelsicher verdrehsicher für Shields!
auch wenns uns nicht gefällt für Lochrasteraufbauten, ich hatte einfach
etwas Lochraster um 1,27mm verschoben eingesetzt.
Joachim B. schrieb:> Stefan Z. schrieb:>> Die seltsame Board-From die keinen Sinn ergibt.>> Die Abstände der Pinleisten.>> ergibt schon Sinn, bastelsicher verdrehsicher für Shields!
Gut, da hätte man auch einfach asymmetrisch arbeiten können (was de
fakto eh so ist, nur dass zusätzlich noch schief verschoben wird in alle
Dimensionen), oder einen Elko so platziert, dass es physisch unmöglich
wäre zu verpolen.
Ist halt ein Standard der leicht "bitter" schmeckt.
Von dem delay() im ersten Hallo Welt mal ganz abgesehen…
Hallo,
vielen Dank für die schnelle Reaktion.
Ich habe es jetzt geschafft es zu implementieren: Das Problem war, dass
sich die Toleranzgrenzen überlappen und ein kurzer auch als langer
erkannt wurde (aber nicht andersherum) und man daher zwingend erst auf
kurz prüfen müssen.
Da das Protokoll vorher nicht richtig implementiert war (Adresse wurde
falsch erkannt, war im Manchester-Code verschoben, Kommandos erhielten
ein zusätzliches Bit am Anfang), ist es nicht kompatibel mit der
vorherigen Implementierung, da sich Adresse als auch Kommandos
unterscheiden.
Es werden jetzt Kommandos bis 4 Byte erkannt (länger geht mit der
Tastatur nicht), erkannt und das Prüfbit wird überprüft.
Zur Implementierung:
-Wenn Merlin aktiviert ist, wird die Kommando-Länge auf 32 Bit gesetzt
und es gibt das Feld cmdlen in IRMP_DATA (leider sind die aktivierten
Protokolle nicht in der irmpsystem.h verfügbar, daher hab ich das da
nochmal definiert, sehr unschön).
-Wenn er Merlin erkannt hat und eine Pause kommt die länger ist als eine
lange Pause, setzt er die Frame-Länge auf die aktuelle Länge und setzt
"got_light".
-Wenn er in dann in dem if(got_light) ist und die aktuelle Länge den
Frame-Länge entspricht, baut er basierend auf der letzten
Pausen/Pulslänge und Zustand die letzten ein bis zwei Bits (da die Pause
dazugehören kann aber nicht muss ist das der schwierige Teil)
-In irmp_get_data prüft er dann die korrekte Länge (entweder 10 oder
11+n*8) und das letzte Bit und setzt die Länge des Kommandos in Byte (0
bis 4).
-Da nach der Adresse noch 33 Bit folgen können wegen dem Prüfbit, habe
ich die Adresse auf 9 Bit definiert, nachdem das letzte Bit überprüft
wurde wird in irmp_get_data das Bit von der Adresse ins Kommando
geschoben.
-Da die Erkennung ob Merlin in keinster Weise geändert wurde und auch in
keinem nicht-Merlin spezifischen Teil was geändert ist (außer das
Kommando jetzt 32 Bit), sollte kein anderes Protokoll irgendwie
beeinflusst werden.
-Die Menge an Programmspeicher, welcher benötigt wird wächst von ~300
Byte auf ~1200 Byte.
Ich würde mich freuen, wenn das in das offizielle IRMP übernommen werden
kann.
Das mit dem IR Logging klappt nicht richtig bei mir, die serielle
Schnittstelle hängt sich dabei irgendwie auf und es geht erst wieder
nach Reset. Falls noch Bedarf ist, kann ich es mit dem Logic-Analyzer
bei 20kHz aufnehmen, sollte dann doch das gleiche sein?
Vielen Dank
Stefan
Stefan O. schrieb:> Ich habe es jetzt geschafft es zu implementieren: Das Problem war, dass> sich die Toleranzgrenzen überlappen und ein kurzer auch als langer> erkannt wurde (aber nicht andersherum) und man daher zwingend erst auf> kurz prüfen müssen.
Die Reihenfolge der Prüfung sollte hier nicht maßgeblich sein, vielmehr
sollte man dafür sorgen, dass sich die Toleranzgrenzen nicht überlappen.
> Da das Protokoll vorher nicht richtig implementiert war
Bist Du Dir sicher, dass wir hier von demselben Protokoll sprechen?
MERLIN bezieht sich auf die Pollin-FB
https://www.pollin.de/p/infrarot-fernbedienung-merlin-620185 (Artikelnr.
620 185). Es gibt unter IR-Data eine Datei merlin-15kHz.txt, die über
die Test-Suite (siehe test-suite.sh) auf Reproduzierbarkeit getestet
wird.
> (Adresse wurde> falsch erkannt, war im Manchester-Code verschoben, Kommandos erhielten> ein zusätzliches Bit am Anfang),
Das hört sich nach einer ganz anderen FB an. Wenn dem so ist, dann
sollte dem Protokoll Deiner FB auch ein anderer Name gegeben werden. Um
was handelt es sich? Ich lese bei Dir "Tastatur", geht es hier um eine
IR-Tastatur für den PC?
> Es werden jetzt Kommandos bis 4 Byte erkannt (länger geht mit der> Tastatur nicht), erkannt und das Prüfbit wird überprüft.
Ja, die Tatsache, dass in IRMP sowohl Adresse als auch Kommando auf 16
Bit beschränkt sind, hat mich später schon gestört, weil es durchaus
auch Protokolle gibt, welche mehr Bits verwenden. Trotzdem konnte ich
meist Redundanzen (CRCs, Parity-Bits und Wiederholungen) erkennen,
welche dann besser lediglich geprüft, aber nicht in command oder
address mit abgespeichert wurden. Zur Reproduzierung des Original-Frames
werden dann in IRSND die notwendigen Bytes wieder neu berechnet und in
den zu sendenden Frame wieder eingeführt.
Bist Du Dir da sicher, dass mehr als 16 Bit an reiner Information
notwendig sind? Durch die Verwendung von mehr als 16 Bits wird IRMP zu
einer größeren Reihe an real existierenden Anwendungen inkompatibel -
siehe Abschnitt
https://www.mikrocontroller.net/articles/IRMP#Hardware_.2F_IRMP-Projekte
Hier wird meist die Struct über UART oder USB als feste Größe
verschickt. Durch Deine Änderungen
1. Erweiterung der Struct um Variable cmdlen
2. Erweiterung des Typs von command auf 32 Bit
laufen viele dieser Anwendungen ohne Anpassung nicht mehr.
Ich habe schon öfters überlegt, address und command auf 32 Bits zu
erweitern, um es mir bei manchen Protokollen leichter zu machen, aber
immer wieder diese Änderung verworfen, nämlich aus dem einfachen Grund,
dass die 8-Bit-AVRs bei 32Bit-Variablen-Operationen (wie z.B. Shifts
etc) grottenlangsam werden und so etwas in einer ISR tödlich ist.
Frage: Welchen µC setzt Du hier konkret ein? Hast Du es mit einem AVR-µC
getestet?
Ich kann mir durchaus vorstellen, ab Version 4.0 einen Schnitt zu machen
und address und command generell auf 32-Bit zu erweitern (bei
Verzicht(!) auf cmdlen). Vorher muss aber greprüft werden, ob die
8-Bit-AVRs da noch mithalten können und bei welcher Taktfrequenz.
> Zur Implementierung:> -Wenn Merlin aktiviert ist, wird die Kommando-Länge auf 32 Bit gesetzt> und es gibt das Feld cmdlen in IRMP_DATA (leider sind die aktivierten> Protokolle nicht in der irmpsystem.h verfügbar, daher hab ich das da> nochmal definiert, sehr unschön).
Das mit der Nochmal-Definition in irmpsystem.h ist ein NoGo, das müsste
anders gelöst werden, z.B. durch generelles Arbeiten mit 32-Bit, siehe
oben. Ich könnte mir auch vorstellen, lediglich bei den 32-Bit-µCs auf
32 Bit zu gehen. Dann bleiben die AVRs halt bei 16 Bit und unterstützen
Dein "Merlin-Protokoll" nicht.
> -Wenn er Merlin erkannt hat und eine Pause kommt die länger ist als eine> lange Pause, setzt er die Frame-Länge auf die aktuelle Länge und setzt> "got_light".
Hm, sehr speziell. Besser wäre eine Anpassung der Toleranzen, so dass
sich diese "in beiden Richtungen" nicht mehr überschneiden.
> -In irmp_get_data prüft er dann die korrekte Länge (entweder 10 oder> 11+n*8) und das letzte Bit und setzt die Länge des Kommandos in Byte (0> bis 4).
Bist Du Dir da sicher mit den variablen Bitlängen? Hast Du da irgendeine
Dokumentation zu Deiner Tastatur?
> -Da die Erkennung ob Merlin in keinster Weise geändert wurde und auch in> keinem nicht-Merlin spezifischen Teil was geändert ist (außer das> Kommando jetzt 32 Bit), sollte kein anderes Protokoll irgendwie> beeinflusst werden.
Mir scheint, dass IRMP bei Deiner FB fälschlicherweise wegen der
Start-Bits auf MERLIN springt, das Protokoll aber hier ein ganz anderes
ist. Wie gesagt, MERLIN steckt hier in der Test-Suite und ist daher
ziemlich gesichert, was die Erkennung betrifft.
> -Die Menge an Programmspeicher, welcher benötigt wird wächst von ~300> Byte auf ~1200 Byte.
Hui, das ist eine Menge Holz. Naja, kommt auf den Prozessor an. Außerdem
habe ich gesehen, dass Du F_INTERRUPTS auf 20000 gesetzt hast. Ist das
für Dein "Merlin" so notwendig?
> Ich würde mich freuen, wenn das in das offizielle IRMP übernommen werden> kann.
Sorry, in dieser Form bestimmt nicht, das fängt mit der inkompatiblen
Änderung von IRMP_DATA an und hört auch nicht mit mit dem festen #define
von IRMP_SUPPORT_MERLIN_PROTOCOL an der falschen Stelle auf. Als
allererstes wäre überhaupt zu klären, ob wir beide überhaupt dasselbe
"Merlin-Protokoll" meinen.
Hast Du mal nach Deinen Änderungen die Test-Suite aufgerufen, um zu
prüfen, ob noch alles so läuft wie vorher?
> Das mit dem IR Logging klappt nicht richtig bei mir, die serielle> Schnittstelle hängt sich dabei irgendwie auf und es geht erst wieder> nach Reset. Falls noch Bedarf ist, kann ich es mit dem Logic-Analyzer> bei 20kHz aufnehmen, sollte dann doch das gleiche sein?
Wenn Du den Logic-Analyzer-Output wieder ins IRMP-Loggin-Format
zurückübersetzt, damit man unter Linux mit "irmp -a" im Analyzer-Modus
das Protokoll näher analysieren kann, dann ja ;-)
Gruß,
Frank
Stefan O. schrieb:> Das mit dem IR Logging klappt nicht richtig bei mir, die serielle> Schnittstelle hängt sich dabei irgendwie auf und es geht erst wieder> nach Reset. Falls noch Bedarf ist, kann ich es mit dem Logic-Analyzer> bei 20kHz aufnehmen, sollte dann doch das gleiche sein?
20kHz ist aber zu wenig bei einem 36kHz Empfänger.
Aber Rohdaten vom TSOP abzugreifen sollte ja mit 10 Zeilen Code und
einem Arduino auch einfach sein, wobei die Logging Funktion von IRMP für
mich früher immer gut funktionierte…
> Die Reihenfolge der Prüfung sollte hier nicht maßgeblich sein, vielmehr> sollte man dafür sorgen, dass sich die Toleranzgrenzen nicht überlappen.
Ich habe die Toleranzen auf 10% reduziert, geht immer noch problemlos.
Es könnte sein, dass die Toleranzgrenzen so groß gewählt (30%) waren
damit der Fehler in der Implementierung ausgeglichen wird.
> Bist Du Dir sicher, dass wir hier von demselben Protokoll sprechen?
Sicher bin ich mir nicht, da ich die Fernbedienung dort nicht besitze,
sondern diese Tastatur:
https://www.mikrocontroller.net/articles/IR-Tastatur_Merlin_Ruwido
Das Protokoll SIEMENS_OR_RUWIDO erkennt gar nichts, MERLIN erkennt in
seinem derzeitigen Zustand einzelne Tastendrücke inkorrekt, aber
reproduzierbar.
> MERLIN bezieht sich auf die Pollin-FB> https://www.pollin.de/p/infrarot-fernbedienung-merlin-620185 (Artikelnr.> 620 185). Es gibt unter IR-Data eine Datei merlin-15kHz.txt, die über> die Test-Suite (siehe test-suite.sh) auf Reproduzierbarkeit getestet> wird.
Test-Suite läuft problemlos, auch merlin-15kHz.txt wird korrekt erkannt
(das ist genau das Protokoll das ich meine, meine Tastatur gibt exakt
solche Werte aus!), jedoch sind die Soll-Werte falsch:
Adresse muss 0x0001 sein und statt 0x0122 muss es 0x0022 sein etc. Das
meinte ich damit als ich schrieb, es ist inkompatibel zur vorherigen
fehlerhaften Implementierung. Argument warum vorher falsch und jetzt
richtig folgt im nächsten Absatz.
> Bist Du Dir da sicher, dass mehr als 16 Bit an reiner Information> notwendig sind? Durch die Verwendung von mehr als 16 Bits wird IRMP zu> einer größeren Reihe an real existierenden Anwendungen inkompatibel
Ja, definitiv: Es können mehrere Tasten gleichzeitig gedrückt werden
(bis zu 4) und die Tastatur überträgt dann genau die 4 8-Bit Codes der
Tasten direkt hintereinander (32 Bit). Dies ist absolut konsistent und
die Codes entsprechen für alle Standard-Tasten exakt den USB HID Codes.
Daher bin ich mir auch so sicher, dass die Erkennung vorher falsch war,
weil wie ich es jetzt habe ist es konsistent.
> Frage: Welchen µC setzt Du hier konkret ein? Hast Du es mit einem AVR-µC> getestet?
Ein ATmega644P mit 18,432 MHz. Es soll später auf einem ATmega32U2 bei
16MHz laufen (warte noch auf die Leiterplatte, wird wohl Ende November
bis ich das testen kann)
> Hm, sehr speziell. Besser wäre eine Anpassung der Toleranzen, so dass> sich diese "in beiden Richtungen" nicht mehr überschneiden.
Hier das Problem (ausgabe von irmp-15khz):
protocol = MERLIN, start bit timings: pulse: 2 - 4, pause: 5 - 8
pulse: 1 - 5 or 2 - 10
pause: 1 - 5 or 2 - 10
Problem scheint zu sein, dass die Werte einfach verdoppelt werden, was
exakt korrekt wäre, aber bei den auf- und abgerundeten Werten halt zu
sowas führt.
> Mir scheint, dass IRMP bei Deiner FB fälschlicherweise wegen der> Start-Bits auf MERLIN springt, das Protokoll aber hier ein ganz anderes> ist. Wie gesagt, MERLIN steckt hier in der Test-Suite und ist daher> ziemlich gesichert, was die Erkennung betrifft.
Nein, defintiv nicht. Mit der vorherigen Implementierung kann ich
einzelne Tastendrücke empfangen, die genau wie in der Testdatei
aussehen. Nur die Erkennung vorher war meiner Ansicht nach mit den oben
genannten Gründen falsch.
> Hui, das ist eine Menge Holz. Naja, kommt auf den Prozessor an. Außerdem> habe ich gesehen, dass Du F_INTERRUPTS auf 20000 gesetzt hast. Ist das> für Dein "Merlin" so notwendig?
Ja, für die letzten Bits ist es etwas speziell, daher wohl. 15kHz geht
auch, ist aber an der Grenze (kurzer Puls darf 1 lang sein).
> Das mit der Nochmal-Definition in irmpsystem.h ist ein NoGo, das müsste> anders gelöst werden, z.B. durch generelles Arbeiten mit 32-Bit, siehe> oben. Ich könnte mir auch vorstellen, lediglich bei den 32-Bit-µCs auf> 32 Bit zu gehen. Dann bleiben die AVRs halt bei 16 Bit und unterstützen> Dein "Merlin-Protokoll" nicht.
Ja, das mit der irmpsystem.h ist klar, war nur zum testen, wäre das so
übernommen worden hätte ich mich arg gewundert.
Mein Vorschlag:
Statt auf 32 Bit zu gehen wenn Merlin aktiviert ist, eine Option mit der
man 32 Bit einschaltet. Dann kann man beim Kompilieren selber
entscheiden unabhängig vom Protokoll. Für cmdlen genauso, wenn man es
nicht aktiviert bleibt es ABI-kompatibel zu vorherigen Version.
> 20kHz ist aber zu wenig bei einem 36kHz Empfänger.> Aber Rohdaten vom TSOP abzugreifen sollte ja mit 10 Zeilen Code und> einem Arduino auch einfach sein, wobei die Logging Funktion von IRMP für> mich früher immer gut funktionierte…
Der Empfänger ist sogar 56 KHz, aber das Protokoll reizt das zum Glück
nicht aus.
Ich werde sonst gleich mal eine Testdatei basteln mit Kommandos der
Tastatur.
Nochmal was ganz anderes:
Da mein Projekt auch IR Befehle wieder senden können soll (vom HTPC zu
Fernseher etc.) habe ich mal eben meine Fernbedienungen untersucht. Ich
habe einen alten Metz TV, da wird nichts erkannt. Es scheint ein
Pulse-Distance-Protokoll zu sein:
Start: 866µs Pulse / 2300µs Pause
Bit A: 433µs Pulse / 956µs Pause
Bit B: 433µs Pulse / 1648µs Pause
Irgendeine Idee was das ist?
Viele Grüße
Stefan
So, ich habe die zu erwartenden Werte in der merlin-15kHz-correct.txt
angepasst und eine weitere Test-Datei für die Tastatur angelegt, welche
Kommandos von 0, 1 und 2 Byte Länge überprüft (für 3 und 4 Byte müsste
das Testprogramm wohl angepasst werden).
Noch eine Bestätigung das ich das selbe Merlin-Protokoll meine: In der
Testdatei merlin-15kHz.txt sind die Kommandos für die Ziffern 1 bis 0
(10?), die sind genau wie bei meiner Tastatur. Vorher stand da 0x011e
bis 0x0127, USB HID codes für die Ziffern 1,2, ... bis 0 sind 0x1e bis
0x27, die werden jetzt auch erkannt.
Wenn man sich Merlin vorher anschaut machen schon die Werte im Header
für Adresse- und Kommandoposition bzw. -länge keinen Sinn (sie
überlappen sich), dazu kommt in dem Kommentar steht was anderes als im
define direkt davor.
Ich bin mir doch sehr sehr sicher das ich es richtig habe und es vorher
falsch implementiert war.
Natürlich bricht die neue Implementierung die Kompatibilität,
möglicherweise kann man das auch wieder mit defines Regeln, man muss
zusätzlich zu
IRMP_SUPPORT_MERLIN_PROTOCOL noch
IRMP_MERLIN_PROTOCOL_OLD_IMPLEMENTATION oder
IRMP_MERLIN_PROTOCOL_NEW_IMPLEMENTATION definieren (ich würde kein
default setzen, damit man sich beim Kompilieren überlegen muss was man
möchte).
> wobei die Logging Funktion von IRMP für> mich früher immer gut funktionierte…
Da ist jetzt vielleicht die Grenze vom AVR erreicht weil ich 32 Bit und
20 kHz aktiviert habe...
Nochwas: Ich verwende avr-gcc 8.2 als Kompiler (habe ich selber
kompiliert weil ich einen AVR dieser neuen tiny1-Serie verwendet habe
und die erst ab 8 unterstützt werden). Möglicherweise gab es mal
Optimierungen das 32-Bit jetzt schneller läuft, soweit ich weiß habe ich
da mal was gelesen, weiß aber gerade nicht bei welcher Version das war.
Viele Grüße
Stefan
Das Metz Protokoll einzubauen war eine Angelegenheit von Minuten, hab
keine Ahnung ob es noch woanders genutzt wird, die Aufteilung
Adresse/Kommando erfolgte nach dem Prinzip solange Bits von Adresse nach
Kommando geschoben bis Adresse für alle Tasten der Fernbedienung gleich.
Die Kommandos sind ziemlich willkürlich, es gibt ein paar die direkt
aufeinander folgen, der Großteil scheint ziemlich willkürlich über einen
großen Bereich verteilt zu sein:
irmpprotocols.h:
Ich habe das Toggle-Bit jetzt einfach weggeworfen, bei anderen
Protokollen passiert das manchmal erst bei irmp_get_data, wie sollte
damit umgegangen werden?
Viele Grüße
Stefan
Bezüglich des RCII-Protokolls ist IRMP zumindest mit meinem Equipment
nicht in der Lage, diesen zu erkennen. Getestet mit einer originalen
Fernbedienung von T+A, Programm wurde compiliert für einen ATmega168
@16MHz, Empfänger an PORTB 0.
Habe nur die RC5- und RCII-Protokolle aktiviert. Signal kommt auch an,
das Oszi-Bild steht für eine "0".
RC5 wird erkannt.
Habe ich etwas übersehen?
Ich weiß, mein Scope ist schon etwas "abgerockt".
Auszug aus der "irmpconfig.h"
Stefan O. schrieb:> Ich habe die Toleranzen auf 10% reduziert, geht immer noch problemlos.> Es könnte sein, dass die Toleranzgrenzen so groß gewählt (30%) waren> damit der Fehler in der Implementierung ausgeglichen wird.
Ich stelle die Toleranzen immer erstmal großzügig ein, weil ich aus
Erfahrung weiß, dass diverse Fernbedienungen teilweise erheblich von den
Sollwerten abweichen. Solange das nicht in Konflikt mit anderen
Protokollen steht, lasse ich das so. Sollte es einen Konflikt mit
anderen Protokollen geben, verkleinere ich anschließend die Toleranzen.
> Sicher bin ich mir nicht, da ich die Fernbedienung dort nicht besitze,> sondern diese Tastatur:> https://www.mikrocontroller.net/articles/IR-Tastatur_Merlin_Ruwido
Ah, okay.
> Test-Suite läuft problemlos, auch merlin-15kHz.txt wird korrekt erkannt> (das ist genau das Protokoll das ich meine, meine Tastatur gibt exakt> solche Werte aus!), jedoch sind die Soll-Werte falsch:> Adresse muss 0x0001 sein und statt 0x0122 muss es 0x0022 sein etc. Das> meinte ich damit als ich schrieb, es ist inkompatibel zur vorherigen> fehlerhaften Implementierung. Argument warum vorher falsch und jetzt> richtig folgt im nächsten Absatz.
Das überzeugt mich. Bei einigen Protokollen, bei denen mir lediglich ein
paar wenige Scans vorlag und keine Dokumentation dazu, musste ich bei
der Verteilung der Bits auf Adressen und Kommandos einfach raten. Es
musste halt so passen, dass die Adresse immer dieselbe ist. Ob damit die
Breite der Adresse korrekt ist, kann ich natürlich nicht immer
garantieren.
Fazit:
Ich versuche, Dein korrigiertes Merlin-Protokoll in den IRMP einzubauen
- unter optionaler Erweiterung der IRMP-Struct-Members auf 32 Bit. Wählt
man den Standard "16 Bit" in der Konfiguration, ist halt Merlin nicht
verfügbar. Das lässt sich aber durchaus verschmerzen, da es nicht sooo
verbreitet ist.
Vielen Dank für Deine Arbeit.
Stefan O. schrieb:> Das Metz Protokoll einzubauen war eine Angelegenheit von Minuten,> hab keine Ahnung ob es noch woanders genutzt wird, die Aufteilung> Adresse/Kommando erfolgte nach dem Prinzip solange Bits von Adresse nach> Kommando geschoben bis Adresse für alle Tasten der Fernbedienung gleich.
Ja, meist passt das dann - wenigstens ungefähr.
> Die Kommandos sind ziemlich willkürlich, es gibt ein paar die direkt> aufeinander folgen, der Großteil scheint ziemlich willkürlich über einen> großen Bereich verteilt zu sein:
Wenn dieser Effekt auftritt, kann es sein, dass die Bitreihenfolge auf
LSB statt MSB eingestellt werden muss. Wenn die Werte dann
"vernünftiger" erscheinen, kannst Du davon ausgehen, dass das Umdrehen
der Bits richtig war.
Von daher würde ich Dich bitten, mal
1
#define METZ_LSB 1
auszuprobieren.
> Ich habe das Toggle-Bit jetzt einfach weggeworfen, bei anderen> Protokollen passiert das manchmal erst bei irmp_get_data, wie sollte> damit umgegangen werden?
Ja, das kann man meist wegwerfen, weil IRMP die Abstände zwischen den
Frames misst, um festzustellen, ob es sich um eine lang gedrückte Taste
handelt oder nicht. Hast Du das getestet, ob flag korrekt gesetzt wird?
Zum Umgang: Meist ist es einfacher, es erst am Ende, also bei
irmp_get_data() wegzuwerfen. Dann bleibt der Eingriff in die
zeitkritische ISR "minimalinvasiv".
Ich werde das METZ-Protokoll gerne übernehmen. Interessant wäre jedoch
noch der Test auf LSB-Reihenfolge.
Was immer ganz wünschenswert ist, ist eine Scan-Datei zu einem neuen
Protokoll. Dann kann man sie in die Test-Suite mit aufnehmen und damit
auch gewährleisten, dass bei zukünftigen Änderungen der Decoder noch
vernünftig arbeitet. Vielleicht probierst Du nochmal, den UART zum
Laufen zu überreden. Alternativ kann man so eine Scan-Datei auch mit
einem Editor "künstlich anlegen", wenn man das Protokoll gut kennt. Ist
aber ein wenig Arbeit...
Lötlackl *. schrieb:> Bezüglich des RCII-Protokolls ist IRMP zumindest mit meinem Equipment> nicht in der Lage, diesen zu erkennen. Getestet mit einer originalen> Fernbedienung von T+A, Programm wurde compiliert für einen ATmega168> @16MHz, Empfänger an PORTB 0.
Es kann durchaus sein, dass TA hier ein anderes Protokoll als das
"hauseigene" Protokoll verwendet. Das kommt sogar ziemlich oft vor, z.B.
wenn das betreffende Gerät oder die Entwicklung lediglich eingekauft
oder einfach nur "umgelabelt" wurde. Um das zu entscheiden, solltest Du
ruhig ein paar mehr Protokolle aktivieren.
Alternativ machst Du mit IRMP ein paar Scans. Dann kann ich ziemlich
schnell herausfinden, ob IRMP das Protokoll kennt oder nicht. Wenn es
noch unbekannt ist, kann ich es einbauen. Falls Du es also nicht selbst
herausfindest, solltest Du Dich mit IRMP_LOGGING beschäftigen ;-)
> Habe nur die RC5- und RCII-Protokolle aktiviert. Signal kommt auch an,> das Oszi-Bild steht für eine "0".> RC5 wird erkannt.
RC5... gilt das jetzt für die TA-Fernbedienung oder für eine andere?
Wenn für die TA-FB, dann hast Du ja schon das verwendete Protokoll
gefunden.
> Ich weiß, mein Scope ist schon etwas "abgerockt".
Leider kann ich da nicht wirklich Zeiten ablesen, nur die Verhältnisse
von Puls/Pause zueinander. Bei einer 0, wo alle Pausen und Pulse gleich
lang ist, ist das aber wenig aussagekräftig. Ich kann daher nur
erkennen, dass da ein längeres Startbit ist, kann aber wegen der
gleichlangen Verhältnisse nicht sagen, ob danach Manchester-,
Pulse-Distance-, Pulse-Width- oder Pulse-Position-Code folgt.
Aussagekräftiger wären daher Frames, wo verschiedene
Pulse-/Pausen-Verhältnisse erkennbar sind - unter Angabe der Zeiten.
Einfacher wirds aber mit IRMP_LOGGING, siehe oben.
> # define F_INTERRUPTS 20000 // interrupts
Da würde ich nicht unbedingt mit so einem hohen Wert anfangen, sonder
erstmal moderat 15000 Interrupts/Sekunde wählen.
Wie gesagt: Wenn IRMP tatsächalich bei der TA-FB RC5 erkennt, dann ist
es auch RC5 (und nicht RCII) und der Drops ist gelutscht.
Frank M. schrieb:> Es kann durchaus sein, dass TA hier ein anderes Protokoll als das> "hauseigene" Protokoll verwendet. Das kommt sogar ziemlich oft vor, z.B.> wenn das betreffende Gerät oder die Entwicklung lediglich eingekauft> oder einfach nur "umgelabelt" wurde. Um das zu entscheiden, solltest Du> ruhig ein paar mehr Protokolle aktivieren.Frank M. schrieb:> Da würde ich nicht unbedingt mit so einem hohen Wert anfangen, sonder> erstmal moderat 15000 Interrupts/Sekunde wählen.
Das hatte ich anfangs sogar, und auch 15000 Interrupts/Sekunde benutzt.
Ich habe es zwecks Fehlereingrenzung nur auf die beiden Protokolle
zurechtgestutzt.
Frank M. schrieb:> RC5... gilt das jetzt für die TA-Fernbedienung oder für eine andere?> Wenn für die TA-FB, dann hast Du ja schon das verwendete Protokoll> gefunden.
RC5 gilt für eine andere Fernbedienung. Die habe ich nur beispielhaft
aufgeführt, um Zweifel über die Funktionsfähigkeit meines Aufbaus zu
zerstreuen. Viele andere Protokolle wurden schließlich richtig erkannt,
nur eben RCII nicht.
Frank M. schrieb:> Alternativ machst Du mit IRMP ein paar Scans. Dann kann ich ziemlich> schnell herausfinden, ob IRMP das Protokoll kennt oder nicht. Wenn es> noch unbekannt ist, kann ich es einbauen.
Es ist definitiv RCII, weil ich dieses Protokoll ohne Träger für meine
TV-Mimik (nur noch eine Fernbedienung für "alles") in einer anderen
Schaltung implementiert habe. Die Mimik empfängt dabei RC5-Befehle und
übersetzt sie bei Bedarf nach RCII. Die T+A-Dinger haben einen so
genannten "R-Link"-Eingang, dort gibt es nur +5V, GND und den
Signaleingang, ideal, um einen TSOP*** dranzuklöppeln. Und das
funktioniert sogar mit der originalen FB wie auch mit meiner Mimik.
Frank M. schrieb:> Falls Du es also nicht selbst> herausfindest, solltest Du Dich mit IRMP_LOGGING beschäftigen ;-)
So siehts wohl aus.
Anbei noch ein Bild besagter Mimik.
Trotzdem Danke und einen schönen Abend.
Lötlackl *. schrieb:> Frank M. schrieb:>> Falls Du es also nicht selbst>> herausfindest, solltest Du Dich mit IRMP_LOGGING beschäftigen ;-)>> So siehts wohl aus.
Wenn Du die Scans dann hier reinstellst, kann ich anschließend IRMP
daran anpassen.
Frank M. schrieb:> Stefan O. schrieb:>> Das Metz Protokoll einzubauen war eine Angelegenheit von Minuten,>> hab keine Ahnung ob es noch woanders genutzt wird, die Aufteilung>> Adresse/Kommando erfolgte nach dem Prinzip solange Bits von Adresse nach>> Kommando geschoben bis Adresse für alle Tasten der Fernbedienung gleich.>> Ja, meist passt das dann - wenigstens ungefähr.>>> Die Kommandos sind ziemlich willkürlich, es gibt ein paar die direkt>> aufeinander folgen, der Großteil scheint ziemlich willkürlich über einen>> großen Bereich verteilt zu sein:>> Wenn dieser Effekt auftritt, kann es sein, dass die Bitreihenfolge auf> LSB statt MSB eingestellt werden muss. Wenn die Werte dann> "vernünftiger" erscheinen, kannst Du davon ausgehen, dass das Umdrehen> der Bits richtig war.>> Von daher würde ich Dich bitten, mal>
1
>#defineMETZ_LSB1
2
>
>> auszuprobieren.
Hatte ich schon, war ebenfalls Murks, aber ich habe ein Muster erkannt
und mir das mal genauer angeschaut: Die Adresse/Kommando wird zweimal
hintereinander übertragen, davon beim zweiten mal mit invertierten Bits.
Stimmt für alle Tasten und die Ziffern 0-9 sind jetzt die Kommandos 0
bis 9, auch alle anderen Tastengruppen liegen sinnvoll hintereinander.
Hier wird das überprüft :
>>> Ich habe das Toggle-Bit jetzt einfach weggeworfen, bei anderen>> Protokollen passiert das manchmal erst bei irmp_get_data, wie sollte>> damit umgegangen werden?>> Ja, das kann man meist wegwerfen, weil IRMP die Abstände zwischen den> Frames misst, um festzustellen, ob es sich um eine lang gedrückte Taste> handelt oder nicht. Hast Du das getestet, ob flag korrekt gesetzt wird?>> Zum Umgang: Meist ist es einfacher, es erst am Ende, also bei> irmp_get_data() wegzuwerfen. Dann bleibt der Eingriff in die> zeitkritische ISR "minimalinvasiv".
Das Flag wurde richtig gesetzt für Wiederholung, in irmp_get_data geht
es genauso.
>> Ich werde das METZ-Protokoll gerne übernehmen. Interessant wäre jedoch> noch der Test auf LSB-Reihenfolge.>> Was immer ganz wünschenswert ist, ist eine Scan-Datei zu einem neuen> Protokoll. Dann kann man sie in die Test-Suite mit aufnehmen und damit> auch gewährleisten, dass bei zukünftigen Änderungen der Decoder noch> vernünftig arbeitet. Vielleicht probierst Du nochmal, den UART zum> Laufen zu überreden. Alternativ kann man so eine Scan-Datei auch mit> einem Editor "künstlich anlegen", wenn man das Protokoll gut kennt. Ist> aber ein wenig Arbeit...
Ich habe eine Testdatei angehängt, es gibt jedoch 2 Probleme:
-Erst wenn die Start-Pulse/Pause-Toleranz runter auf 5% ist, wird
Grundig/Nokia nicht mehr fälschlicherweise als Metz erkannt. Ich weiß
nicht ob das sinnvoll ist (mit meiner Fernbedienung OK, aber wie ist die
Streuung?) oder ob die Protokolle sich gegenseitig ausschließen sollten.
-Er erkennt zwar richtig, aber er irgendwo findet er noch ein start
pulse und hat dann ein timeout, weiß nicht genau warum.
Frank M. schrieb:> Ich versuche, Dein korrigiertes Merlin-Protokoll in den IRMP einzubauen> - unter optionaler Erweiterung der IRMP-Struct-Members auf 32 Bit. Wählt> man den Standard "16 Bit" in der Konfiguration, ist halt Merlin nicht> verfügbar. Das lässt sich aber durchaus verschmerzen, da es nicht sooo> verbreitet ist.
Vielen Dank! Das Drücken von nur einer oder zwei Tasten geht ja noch mit
16 Bit, weiß nicht wie das mit der Merlin-Fernbedienung die du verlinkt
hattest ist und ob der Aufwand lohnt mit einem Haufen ifdefs ein Teil
des Merlin-Protokolls mit 16 Bit zu unterstützen.
Was wichtig ist: Wenn man während die Tastatur einen Frame sendet eine
weitere Taste drückt, ist es nicht unwahrscheinlich, das Blödsinn
gesendet wird, es ist daher unbedingt erforderlich nur die korrekten
Längen zuzulassen und das letzte Bit zu prüfen wie das mein Code macht.
> Vielen Dank für Deine Arbeit.
Sehr gerne, ich möchte es ja nutzen :)
Viele Grüße
Stefan
Stefan O. schrieb:> Hatte ich schon, war ebenfalls Murks, aber ich habe ein Muster erkannt> und mir das mal genauer angeschaut: Die Adresse/Kommando wird zweimal> hintereinander übertragen, davon beim zweiten mal mit invertierten Bits.> Stimmt für alle Tasten und die Ziffern 0-9 sind jetzt die Kommandos 0> bis 9, auch alle anderen Tastengruppen liegen sinnvoll hintereinander.> Hier wird das überprüft :#if IRMP_SUPPORT_METZ_PROTOCOL == 1
Sehr gut!
> Das Flag wurde richtig gesetzt für Wiederholung, in irmp_get_data geht> es genauso.
Prima, das reicht.
> Ich habe eine Testdatei angehängt [...]
Danke.
> -Erst wenn die Start-Pulse/Pause-Toleranz runter auf 5% ist, wird> Grundig/Nokia nicht mehr fälschlicherweise als Metz erkannt.
5% für Start-Bits ist - aus eigener Erfahrung - akzeptabel. Eventuell
kann man die Toleranz auch noch für Grundig/Nokia etwas
herunterschrauben, dann hat man mehr Spielraum.
> -Er erkennt zwar richtig, aber er irgendwo findet er noch ein start> pulse und hat dann ein timeout, weiß nicht genau warum.
Das habe ich nicht verstanden.
Gruß,
Frank
Frank M. schrieb:> 5% für Start-Bits ist - aus eigener Erfahrung - akzeptabel. Eventuell> kann man die Toleranz auch noch für Grundig/Nokia etwas> herunterschrauben, dann hat man mehr Spielraum.
Ich hatte bei mir in der Erkennung Metz vor Grundig/Nokia und er hat die
Dateien Dbox.txt und die Grundig Dateien als Metz erkannt bis ich die
Toleranz runter auf 5% hatte. Vielleicht ist es andersherum besser.
Frank M. schrieb:> Das habe ich nicht verstanden.
Hier die Ausgabe von irmp beim Überprüfen der Testdatei, du wirst aus
der Meldung sicher mehr Rückschlüsse ziehen können:
Hallo Frank,
wenn man IRMP kennt und es daher sehr zu schätzen weiß, verzweifelt man
unter Linux mit LIRC geradezu. Man muss sehr krude Sachen machen um eine
FB anzulernen, alles ist sehr unkomfortabel und funktioniert dann doch
nicht.
Hast du eine Implementierung oder kennst etwas empfehlenswertes für
RasPi? IRMP wird wohl wg der fehlenden interruptfähigkeit nicht
portierbar sein?
Danke, Klaus.
Klaus R. schrieb:> wenn man IRMP kennt und es daher sehr zu schätzen weiß, verzweifelt man> unter Linux mit LIRC geradezu. Man muss sehr krude Sachen machen um eine> FB anzulernen, alles ist sehr unkomfortabel und funktioniert dann doch> nicht.
ja kenne ich
> Hast du eine Implementierung oder kennst etwas empfehlenswertes für> RasPi? IRMP wird wohl wg der fehlenden interruptfähigkeit nicht> portierbar sein?
könnte doch machbar sein, ich hatte mal gelesen das um 1µs (oder waren
das 100µs) machbar sind, damit sollte es eigentlich gehen können.
Nun, auf dem Rpi eine IRQ-Rate mit 15kHz hinzugekommen um IRMP zu
treiben ist schon sehr sportlich. Ich denke selbst mit Kernel-Treiber
wird das haarig.
...das befürchte ich auch. Man müsste die IRQ ja quasi nur auslagern und
die serialisierten Daten dann verarbeiten (was wohl mit der VUSB Lsg
passiert). Ziel ist, dass der RasPi unterscheidliche andere Geräte
steuert (433Mhz, RC5, 455kHz IR, ...) und quasi als Server dient und man
auch das Inet-Radio steuern kann. Ich hatte große Hoffnung auf LIRC,
aber iwie erscheint mir das extrem merkwürdig zu sein und eher ein
"netter Versuch".
Klaus.
Hallo Frank,
für den RPi habe ich gerade mal einen Test gemacht.
Es gibt dort die pigpio library mit GPIO Support.
Dort kann ein Portpin mit 200kHz (default, geht auch langsamer) gepollt
werden. Man kann einen Callback einrichten, der bei Pin change
aufgerufen wird. Dort bekommt man dann einen Tickcounter in usec
mitgeliefert. Man kann also die Zeitdifferenz zwischen den Pegelwechseln
errechnen.
Könnte man den Mechanismus in IRMP nutzen um damit das IR-Signal zu
dekodieren? Jetzt wird doch sicher nichts anderes gemacht, nur das IRMP
das Signal sampled und dann die Zeiten berechnet.
Ich stecke jetzt garnicht tiefer in IRMP drin. Aber evtl. lässt sich das
ja "leicht" nutzen.
Ich habe mal einen DCF77-Empfänger an einen Pin gehängt und in der
Callbackfunktion dann nur die Zeiten und den Pinzustand geloggt. Die
Zeiten sind in usec.
Man kann gut die 100/200ms Signale vom DCF erkennen.
1
GPIO 27 became 1 at 3839270678
2
GPIO 27 became 0 at 3839368284
3
GPIO 27 became 1 at 3840267646
4
GPIO 27 became 0 at 3840369131
5
GPIO 27 became 1 at 3841266373
6
GPIO 27 became 0 at 3841461904
7
GPIO 27 became 1 at 3842267956
8
GPIO 27 became 0 at 3842371996
9
GPIO 27 became 1 at 3843264478
10
GPIO 27 became 0 at 3843467599
11
GPIO 27 became 1 at 3844266506
12
GPIO 27 became 0 at 3844365561
13
GPIO 27 became 1 at 3845273349
14
GPIO 27 became 0 at 3845367674
15
GPIO 27 became 1 at 3846270121
16
GPIO 27 became 0 at 3846368736
17
GPIO 27 became 1 at 3847267424
18
GPIO 27 became 0 at 3847464939
19
GPIO 27 became 1 at 3848271741
20
GPIO 27 became 0 at 3848461172
Ein Timer mit 10-20kHz geht leider nicht in der Lib.
Es fällt mir wieder wie Schuppen von den Augen, es ist schon etwas
länger her, als ich das Sendeprotokoll implementierte. Das Oszi-Bild
zeigt lediglich das Startkommando, ein vollständiges Telegramm
beinhaltet aber noch etwas mehr.
Siehe auch:
https://www.ta-hifi.de/wp-content/uploads/tua_ir_commands.pdf
Ich zitiere:
"A telegram consists of a 10-bit start command
(Start), one or more 10-bit commands (CMD) and a 10-bit end command
(END)."
In dieser Beziehung ist das von technikus verlinkte PDF etwas ungenau.
Vielleicht ist das der Grund, weshalb IRMP mit RCII nichts anfangen
kann.
Gute N8
Habe die Leiterplatten am Samstag bekommen und IRMP läuft problemlos mit
32-Bit-Kommandos auf einem ATmega32u2 mit 16 MHz. Der macht bei mir
jetzt 2 USB-HID-Geräte: Eine HID-Tastatur, die Merlin-Tastatur
funktioniert damit wie eine normale Tastatur (auch
Tastenkombinationen/lange Drücken funktioniert ganz normal), nur bei
sehr schnellem Tippen fehlen z.T. Buchstaben (das liegt aber nicht am
Empfänger, die werden nicht vollständig gesendet wenn schon die nächste
Taste kommt). Das zweite ist ein universelles HID-Gerät welches
IR-Befehle mit IRSND senden kann.
Ich werde Schaltplan/Layout/Quellcode gerne veröffentlichen, warte aber
bis die nächste IRMP-Version draußen ist, jetzt geht es nur mit meiner
angepassten Version.
Viele Grüße
Stefan
Stefan O. schrieb:> Habe die Leiterplatten am Samstag bekommen und IRMP läuft problemlos mit> 32-Bit-Kommandos auf einem ATmega32u2 mit 16 MHz.
Freut mich zu hören.
> Ich werde Schaltplan/Layout/Quellcode gerne veröffentlichen, warte aber> bis die nächste IRMP-Version draußen ist, jetzt geht es nur mit meiner> angepassten Version.
Beim Einbau in den IRMP ist da noch eine Frage aufgetaucht: Ist cmdlen
als eigener Struct-Member von IRMP_DATA speziell für das
Merlin-Protokoll tatsächlich notwendig?
Ich schlage vor, diese Information besser als Zusatzinfo in "flags"
unterzubringen. Das wird für spezielle Genre-Flags im Kaseikyo-Protokoll
nämlich auch schon so gemacht, weil die bisherigen 16 Bit dort auch
nicht ausreichten.
Für solche protokollspezifischen Zusatzinformationen sind nämlich in
flags die oberen 4 Bit reserviert. Wenn ich es richtig verstanden habe,
reichen diese 4 Bits auch aus, um cmd_len zu speichern, da es nur die
Werte von 1 bis 4 annehmen kann.
ich plädiere daher dafür:
Alt:
1
#if IRMP_SUPPORT_MERLIN_PROTOCOL == 1
2
irmp_data_p->cmdlen=cmd_len;
3
#endif
Neu:
1
#if IRMP_SUPPORT_MERLIN_PROTOCOL == 1
2
irmp_data_p->flags|=cmd_len<<4;
3
#endif
Dann kann cmdlen in der neuen IRMP-Struct komplett entfallen. Wenn Du in
der Anwendung dann cmd_len wieder auswerten möchtest, schreibst Du:
1
cmd_len=(irmp_data.flags>>4)&0x0F;
Oder kürzer, da die Flags immer nur 8 Bit breit sind:
Stefan O. schrieb:> protocol = METZ, start bit timings: pulse: 16 - 19, pause: 43 - 49> [...]> 5.550ms error 1: pause after start bit pulse 8 too long: 311
Ich habe das Metz-Protokoll eingebaut. Die obige Fehlermeldung erscheint
typischerweise, wenn man ein Bit zuwenig einliest.
Ich habe das so korrigiert:
Hallo,
das mit cmdlen in den Flags ist eine sehr gute Idee! Die Werte können
zwischen einschließlich 0 und 4 liegen (Länge 0 bedeutet alle Tasten
wurden losgelassen, es wird nur Adresse übertragen), 3 Bit wären also
sogar schon ausreichend.
In der irsnd.c war noch keine Definition für den ATmega32U2, habe ich
ergänzt:
1
#elif defined (__AVR_ATmega8U2__) \
2
|| defined (__AVR_ATmega16U2__) \
3
|| defined (__AVR_ATmega32U2__) // ATmega(8|16|32)U2 uses OC0A = PB7 or OC0B = PD0
4
# if IRSND_OCx == IRSND_OC0A
5
# define IRSND_PORT_LETTER B
6
# define IRSND_BIT_NUMBER 7
7
# elif IRSND_OCx == IRSND_OC0B
8
# define IRSND_PORT_LETTER D
9
# define IRSND_BIT_NUMBER 0
10
# endif // IRSND_OCx
Ich weiß nicht ob du das Metz-Protokoll auch direkt in irsnd eingebaut
hast, sonst probiere ich das am Wochenende mal.
Viele Grüße
Stefan
Stefan O. schrieb:> das mit cmdlen in den Flags ist eine sehr gute Idee!
Ich habe hier mal die aktuelle Fassung von IRMP angehängt. Wenn das
alles so bei Dir funktioniert, dann mache ich daraus ein neues Release.
Wichtig ist, dass man hier im Projekt IRMP_32_BIT auf 1 setzt, also die
Compileroption
1
-DIRMP_32_BIT=1
verwendet. Ich wollte das eigentlich mit in irmpconfig.h aufnehmen,
überlege aber noch, wie ich das realisiere. irmpconfig.h wird nämlich
aus gutem grund nach irmpsystem.h includiert. Dafür ist es aber dann zu
spät.
> Ich weiß nicht ob du das Metz-Protokoll auch direkt in irsnd eingebaut> hast, sonst probiere ich das am Wochenende mal.
Das METZ-Protokoll ist zwar im IRMP-Source drin, aber nicht in IRSND. Da
kannst Du Dich gern austoben :-)
P.S.
IR-Data und damit die Test-Suite habe ich ebenso um Deine Scan-Dateien
erweitert.
https://www.mikrocontroller.net/articles/IRMP#Kodierungen
legt nahe das IRMP auch als 'HFMP' für ASK auf 433/868 MHz funktionieren
könnte.
Kommt er gut mit Bit-Rauschen klar wenn gerade kein Signal Übertragen
wird, oder braucht er eine Rauschsperre (Squelch)?
Bastler #7 schrieb:> https://www.mikrocontroller.net/articles/IRMP#Kodierungen> legt nahe das IRMP auch als 'HFMP' für ASK auf 433/868 MHz funktionieren> könnte.
Ja, ich habe da mal vor ein, zwei Jahren auch mit experimentiert, das
dann aber mangels Interesse nicht weiter verfolgt.
> Kommt er gut mit Bit-Rauschen klar wenn gerade kein Signal Übertragen> wird, oder braucht er eine Rauschsperre (Squelch)?
IRMP sollte ganz gut damit klarkommen. Wenn etwas empfangen wird, was
keinem Muster zugeordnet werden kann, wird die Statemachine
zurückgesetzt. Rauschen sollte also nichts weiter bewirken, als dass
IRMP sich jedesmal wieder neu in die Startlöcher hockt, bis was "echtes"
wie z.B. eine Präambel kommt.
Hallo,
komme gerade nicht weiter. Ich möchte einen RC5 weitersenden.
irrcv sagt mir:
// RC5 C0C
uint32_t address = 0x10;
uint32_t command = 0xC;
uint64_t data = 0xC0C;
Wie muss denn jetzt der irsend.sendRC5 aussehen, damit er genau den
Befehl sendet?
irsend.sendRC5(0x10CC0C,24) ???
Wie wird Data "zusammengebaut"?
Holger
ok, hab zu kompliziert gedacht. Einfach den Wert 0xC0C senden...passt
jetzt
Ich habe hier eine alte Fernbedienung eines Videorecorders von Grundig.
Es handelt sich um eine VIDEO PILOT 615. Ein TSOP für 38kHz kann das IR
Signal sauber erkennen. Das Ausgangssignal entspricht weitgehend dem in
https://www.mikrocontroller.net/attachment/77507/Grundig_10bit.pdf
beschriebenen Signal, allerdings mit dem Unterschied, das hier nur 7 Bit
(1 Startbit und 6 Datenbits) gesendendet werden. Sieht ganz so aus, als
fehlten die Gruppenbits. Die Daten selbst passen zu den Codes in der
Befehlsliste des obigen Dokuments.
Nun die Frage: Die Grundig/Nokia Fernbedienung in IRMP geht von 10 Bit
aus. Reicht es daraus 7 Bit zu machen, um diese alte Fernbedienung zu
erkennen?
Uwe
Uwe S. schrieb:> Die Grundig/Nokia Fernbedienung in IRMP geht von 10 Bit aus. Reicht es> daraus 7 Bit zu machen, um diese alte Fernbedienung zu erkennen?
Ja, kann gut sein, probiere es einfach aus. Du musst dafür nur
irmpprotocols.h anpassen.
Wenn es klappt, kann ich auch in den Source einen Timeout-Handler
einbauen, damit IRMP sowohl 10 Bit als auch 7 Bit erkennen kann.
Dafür wäre eine Scan-Datei (IRMP_LOGGING auf 1) sehr sinnvoll, damit ich
das testen kann.
Frank M. schrieb:> Uwe S. schrieb:>> Die Grundig/Nokia Fernbedienung in IRMP geht von 10 Bit aus. Reicht es>> daraus 7 Bit zu machen, um diese alte Fernbedienung zu erkennen?>> Ja, kann gut sein, probiere es einfach aus. Du musst dafür nur> irmpprotocols.h anpassen.
Das hat erstaunlich gut geklappt. Damit wird die Fernbedienung schon
erkannt.
> Wenn es klappt, kann ich auch in den Source einen Timeout-Handler> einbauen, damit IRMP sowohl 10 Bit als auch 7 Bit erkennen kann.>> Dafür wäre eine Scan-Datei (IRMP_LOGGING auf 1) sehr sinnvoll, damit ich> das testen kann.
Ich habe in der Schaltung leider keine serielle Ausgabe. Angehängt ist
daher eine modifizierte Ausgabe von Sigrok. 0 steht für hell und 1 für
dunkel, abgetastet mit 20 kHz. Im angehängten Screenshot sieht man das
Signal auch grafisch aufbereitet. Der erste Frame ist immer gleich. Im
zweiten Frame ist dann das eigentliche Kommando. Dieses wird so oft
wiederholt, wie die Taste gedrückt wird. Nach Loslassen der Taste kommt
nochmal der Frame vom Anfang (im Bild und dem Dump nicht vorhanden). Das
entspricht weitesgehend der 10Bit Grundig Fernbedienung. Die Daten
werden LSB gesendet. Die in der Beschreibung der 10Bit
Grundig-Fernbedienung gelisten Codes, stimmen bis auf das letzte
gesendete Bit überein. Für die Stop Taste wird "S001101" (S=Startbit)
gesendet. Laut Beschreibung sollte es aber "S001100" sein. Das ist auch
bei anderen Tasten so. Das letzte Bit könnte natürlich auch ein Stop bit
sein, denn bisher habe ich keine Taste gefunden, deren letztes Bit nicht
"1" war.
Noch eine Frage zu den Frames. Kümmert sich IRMP um die Frames und deren
Interpretation oder muss ich das selbst machen?
Uwe
Uwe S. schrieb:> Das hat erstaunlich gut geklappt. Damit wird die Fernbedienung schon> erkannt.
Prima.
> Ich habe in der Schaltung leider keine serielle Ausgabe.
Schade.
> Angehängt ist> daher eine modifizierte Ausgabe von Sigrok. 0 steht für hell und 1 für> dunkel, abgetastet mit 20 kHz.
Okay, danke. Die Aufzeichnung kann ich verarbeiten.
> Die in der Beschreibung der 10Bit> Grundig-Fernbedienung gelisten Codes, stimmen bis auf das letzte> gesendete Bit überein. Für die Stop Taste wird "S001101" (S=Startbit)> gesendet. Laut Beschreibung sollte es aber "S001100" sein.
Kann sein, dass Du die Anzahl der Bits in irmpprotcols.h um 1 zu hoch
eingestellt hast. Am besten zeigst Du auch alle Änderungen, die Du in
irmpprotocols.h vorgenommen hast.
> Noch eine Frage zu den Frames. Kümmert sich IRMP um die Frames und deren> Interpretation oder muss ich das selbst machen?
Da kümmert sich IRMP selbst drum. Ab einer längeren Ruhepause weiß die
Statemachine, dass der Frame zuende ist - egal ob vollständig oder
nicht. Die Statemachine wird dann automatisch zurückgesetzt.
Frank M. schrieb:> Uwe S. schrieb:
[...]
>> Die in der Beschreibung der 10Bit>> Grundig-Fernbedienung gelisten Codes, stimmen bis auf das letzte>> gesendete Bit überein. Für die Stop Taste wird "S001101" (S=Startbit)>> gesendet. Laut Beschreibung sollte es aber "S001100" sein.>> Kann sein, dass Du die Anzahl der Bits in irmpprotcols.h um 1 zu hoch> eingestellt hast. Am besten zeigst Du auch alle Änderungen, die Du in> irmpprotocols.h vorgenommen hast.
Nur diese beiden Zeilen
Hallo Frank,
mit der kleinen Korrektur der GRUNDIG_COMMAND_LEN von 9 auf 6 und
GRUNDIG_COMPLETE_DATA_LEN von 10 auf 7 habe ich mal alle Tasten der FB
aufgezeichnet. Das Scannen selbst habe ich mit sigrok und pulseview mit
einer Abtastrate von 20kHz gemacht und das Ergebnis in die Datei
IR-Data/Grundig_Video-Pilot-615-20kHz.txt der angehängten Zip-Datei
geschrieben.
In jeder Zeile steht die Abtastung einer Taste. Das dann durch
irmp-20kHz geschickt, ergibt die Ausgabe in
IR-Data/Grundig_Video-Pilot-615-20kHz.out
Sieht soweit alles recht ordentlich aus, aber wie erweitert man den
Quellcode von IRMP entsprechend, damit sowohl die 10-Bit als auch die
6-Bit FB von Grundig erkannt wird? Und was passiert mit den Start- und
End-Code, der bei jeder Taste gedrückt wird? Kümmert sich irmp darum
oder muss ich das in der Anwendung selbst machen.
Uwe
Hallo
habe gerade versucht, mit irsnd ein NEC - Datagramm zu erstellen - ging
nicht, die Modulationsfrequenz war viel zu hoch (~700kHz). Kann es sein,
dass in der Zeile (irsnd.c)
was nicht stimmt?
F_CPU=20000000,
F_INTERRUPTS=16000
Wenn ich IRSND_FREQ_36[38]_KHZ = 250 setze, ist alles gut.
p.s. falls ich richtig rechne, ergibt sich doch für F_CPU =20MHz und
F_INTERRUPTS=15k ein Wert, der größer als 8 bit ist. Ist das gewollt?
In void irsnd_init (void) steht für NEC: irsnd_set_freq
(IRSND_FREQ_36_KHZ),
in uint8_t irsnd_ISR (void): irsnd_set_freq (IRSND_FREQ_38_KHZ); ist das
so gewollt?
@Frank, kannst Du gelegentlich die Versionsnummern mit in die Quelltexte
aufnehmen?
Gruß, Bernd
[Mod: Macros in C-Tags gesetzt]
Bernd schrieb:> Kann es sein, dass in der Zeile (irsnd.c)> ...> was nicht stimmt?
Ich habe in Deinem Beitrag mal die Macros in C-Tags gepackt, damit die
Operator-Zeichen von der Forumssoftware nicht verschluckt werden.
> p.s. falls ich richtig rechne, ergibt sich doch für F_CPU =20MHz und> F_INTERRUPTS=15k ein Wert, der größer als 8 bit ist. Ist das gewollt?
Das sehe ich anders. Wegen
1
# if F_CPU >= 16000000L
2
# define AVR_PRESCALER 8
3
# else
4
# define AVR_PRESCALER 1
5
# endif
ist bei F_CPU = 20MHz dann AVR_PRESCALER = 8.
Damit kommt für
Der Wert 31 passt durchaus in ein uint8_t. Das hatte ich damals schon
berücksichtigt, dass bei größerem CPU-Takt hier ein Overflow auftreten
könnte.
AVR_PRESCALER wird dann später auch genutzt beim Setzen von TCCR2 bzw.
TCCR2B bzw. TCCR0 bzw. TCCR0B - je nach AVR-Typ.
> Wenn ich IRSND_FREQ_36[38]_KHZ = 250 setze, ist alles gut.
Das sieht jetzt aber so aus, als ob bei Dir AVR_PRESCALER auf 1 steht,
also das obige #if nicht funktioniert. Oder hast Du in den Source
eingegriffen?
Wo hast Du denn F_CPU gesetzt? Im Projekt selbst, also da, wo es
hingehört? Ändere den Wert mal in 20000000UL - wie im Artikel empfohlen.
Wenn ich es richtig in Erinnerung habe, konnten ältere avr-gcc solche
großen Werte ohne den Zusatz "UL" nicht richtig verarbeiten.
Es könnte auch sein, dass das Makro IRSND_FREQ_38_KHZ generell in
16-Bit-Integer gerechnet wird, solange da kein ausgezeichneter Long-Wert
im Ausdruck angegeben wird. Die Angabe von 20000000UL (mit UL) könnte es
also schon richten.
Welche avr-gcc-Version nutzt Du?
Welchen AVR-µC nutzt Du?
Du kannst leicht überprüfen, ob der avr-gcc den richtigen Wert für
AVR_PRESCALER wählt.
Schreibe einfach mal:
1
# if F_CPU >= 16000000L
2
# define AVR_PRESCALER 8
3
xxxxxxxx// produce syntax error
4
# else
5
# define AVR_PRESCALER 1
6
# endif
Wenn der avr-gcc den Syntax-Error findet, dann nimmt er den richtigen
Wert.
Bernd schrieb:> In void irsnd_init (void) steht für NEC: irsnd_set_freq> (IRSND_FREQ_36_KHZ),> in uint8_t irsnd_ISR (void): irsnd_set_freq (IRSND_FREQ_38_KHZ); ist das> so gewollt?
Ja, das ist gewollt. In irsnd_init() wird erstmal ein Standardwert
gesetzt, deshalb steht da auch im Kommentar "default frequency"
dahinter. Da steht auch nichts von NEC, das ist ganz allgemein zu sehen.
Später, wenn Du das gewollte Protokoll auswählst, wird dann die
protokollspezifische Frequenz genommen, also 38kHz für NEC, was auch
richtig ist.
> @Frank, kannst Du gelegentlich die Versionsnummern mit in die> Quelltexte aufnehmen?
Hm, hatte ich die nicht mal drin? Werde ich prüfen.
@Frank
F_CPU wird über eine h-Datei korrekt und als erstes in main.c
inkludiert. Trotzdem ist der Wert an der Definitionsstelle AVR_PRESCALER
F_CPU==1000000. Ursache dürfte bei mir delay.h sein. Da bringt der
Compiler manchmal eine Warnung und manchmal nicht.
Danke für die schnelle Hilfe, komme nun (hoffentlich) allein weiter.
Gruß
Bernd
Bernd schrieb:> Ursache dürfte bei mir delay.h sein. Da bringt der Compiler manchmal> eine Warnung und manchmal nicht.
Wenn delay.h meckert, hast Du eben nicht überall F_CPU definiert. Dann
wird übrigens F_CPU blöderweise auf 1MHz gesetzt, statt mit einem Fehler
auszusteigen.
IRMP und IRSND benutzen auch gar keine Delays.
F_CPU gehört als Option in Dein Projekt. Jede IDE für AVR bietet die
Möglichkeit, F_CPU in den Projekteinstellungen zu definieren, damit es
für alle C-Files einheitlich gilt. Wenn Du ohne IDE arbeitest, gehört es
halt ins Makefile: -DF_CPU=20000000UL
Hast Du das mal mit "UL" hinter 20000000 ausprobiert?
Hallo Frank,
ich wollte mal Irmp auf dem Arduiono laufen lassen um es mit 2 anderen
Arduino IR libraries zu vergleichen.
Leider ist es nicht direkt lauffähig.
Es sind aber nur einige Änderungen zu machen, wenn man sich auskennt.
Ich würde es auch gerne als Arduio library zusammenstellen, da muss man
nur eine library.properties und eine keywords.txt hinzufügen (hab ich
beides schon gemacht) und leider alle mains entfernen, aber das wars
auch schon.
Bestände da Interesse, es ist übrigens die beste der 3 Libraries und es
wäre doch schade, sie einer größeren Community vorzuenthalten.
Wie könnte man das organisatorisch mit den Updates und dem
zusammenstellen machen, Arduino verlangt ein Github Repo als Master.
Soll ich / kann ich da noch das svn2github.py anpassen? Gibt es schon
einen github account (für die Word Clock) den man benutzen kann?
Beste Grüße
Armin
Armin J. schrieb:> Es sind aber nur einige Änderungen zu machen, wenn man sich auskennt.
Ich kenne mich mit den Arduino-Spitzfindigkeiten so gut wie gar nicht
aus.
> Ich würde es auch gerne als Arduio library zusammenstellen, da muss man> nur eine library.properties und eine keywords.txt hinzufügen (hab ich> beides schon gemacht) und leider alle mains entfernen, aber das wars> auch schon.
Das klingt sehr gut. Kannst Du gern machen!
> Bestände da Interesse, es ist übrigens die beste der 3 Libraries und es> wäre doch schade, sie einer größeren Community vorzuenthalten.
Auf jeden Fall.
> Wie könnte man das organisatorisch mit den Updates und dem> zusammenstellen machen, Arduino verlangt ein Github Repo als Master.> Soll ich / kann ich da noch das svn2github.py anpassen? Gibt es schon> einen github account (für die Word Clock) den man benutzen kann?
Das svn2github stammt nicht von mir. Nein, es gibt noch keinen github
account. Soll ich einen anlegen?
Bin auch 100% für eine Arduino Version, hatte ich auch schon angeregt,
liegt aber klar außerhalb meines Skillsets.
Da IRMP ja multi-platform ist, könnte man als Fernziel auch noch eine
Integration in PlatformIO in Betracht ziehen, bzw. das von vornherein
berücksichtigen. Der Arduino Editor ist ja schon extrem schrecklich im
Vergleich zu jeder richtigen IDE…
Ehrlich, es ist nun gar kein großes Problem, dass so wie es ist für
Arduino zu verwenden.
Die Leute, die das nicht hinbekommen, die werden dann an anderer Stelle
scheitern wo etwas konfiguriert werden muss oder doch trotz richtiger
Konfiguration etwas nicht funktioniert.
Es ist so eine super gut funktionierende Library und ohne großen Aufwand
fast überall so einzubinden.
900ss D. schrieb:> Ehrlich, es ist nun gar kein großes Problem, dass so wie es ist für> Arduino zu verwenden.
Es ist aber auch nicht elegant, so wie es jetzt ist.
GIT in PlatformIO eintragen, Compiler saugt die aktuelle / gewünschte
Version.
Oder eben in der Arduino IDE direkt verfügbar.
Ich sehe den Nachteil nicht, das endlich mal offiziell und sauber zu
machen.
900ss D. schrieb:> Ehrlich, es ist nun gar kein großes Problem, dass so wie es ist für> Arduino zu verwenden.
die irmp.c,v 1.164 2014/09/15 läuft bei mir astrein im Arduino
eine neuere Version hat die Arduino IDE überfordert
900ss D. schrieb:> Es ist so eine super gut funktionierende Library und ohne großen Aufwand> fast überall so einzubinden.
ja, aber sie ist in der aktuellen Version ziemlich fett geworden, ich
hatte es ja versucht, aber die Arduino IDE hatte verweigert, die kam mit
denganzen Verschachtelungen nicht mehr zurecht.
Das klingt doch ermutigend.
Dann will ich mal.
Frank es ist wohl am besten, wenn du ein Github Repository Irmp anlegst
und mich https://github.com/ArminJo dafür auch gleich berechtigst.
Soll ich erst mal die Library dort zusammenbauen und später schauen wir
dann, wie wir die Synchronisation mit svn hinkriegen?
Und noch 2 Sachen:
1. Der Arduino Standardport in den Sourcen ist zurzeit B6, das
funktioniert garantiert auf keinem Arduino, da alle dort den Quarz
haben.
Kann man das ändern, z.B. auf D6 oder D4, oder muss das
rückwärtskompatibel bleiben?
2. Muss die irmp.c weiter eine C Source sein, oder kann ich auch ein cpp
draus machen? Dann funktioniert nämlich das Logging aus der Tüte mit der
Arduino Klasse Serial. Ist jetzt nicht sooo wichtig, wäre aber nett.
Vielleicht auch nur für die Arduino Version...
Und wie lasse ich Dir Änderungen für das svn zukommen? Vielleicht baue
ich erst mal die library und sage dann, welche Files ich wo geändert
hab.
@900ss D. Natürlich läuft es nach einer Stunde im Arduino, wenn man das
mit dem Port mal gerafft hat und die kapitalen Fehler in Arduino
Beispiel bei der Protokollnamensausgabe nicht stören....
Stefan Z. schrieb:> das endlich mal offiziell und sauber zu machen
Wenn alle Software so sauber wie diese Library wäre, dann würde einiges
besser funktionieren. ....kopfschüttel.....
Joachim B. schrieb:> ja, aber sie ist in der aktuellen Version ziemlich fett geworden, ich> hatte es ja versucht, aber die Arduino IDE hatte verweigert, die kam mit> denganzen Verschachtelungen nicht mehr zurecht.
Dann hast Du vermutlich etwas kaputtrepariert. Nenn doch bitte mal eine
Fehlermeldung.
Was meinst Du mit "Verschachtelungen"? Die ganzen #ifdefs? Die sind doch
überhaupt kein Problem für den Preprozessor, da kannst Du auch
irgendeinen uralten nehmen.
Frank M. schrieb:> Dann hast Du vermutlich etwas kaputtrepariert. Nenn doch bitte mal eine> Fehlermeldung.
ist schon wieder einige Jahre her, zwischen 2014 und jetzt sinds ja
wieder >4 Jahre.
Ich probiere das nun nicht mit jeder IDE oder gcc Version neu.
Die IDE hatte ich irgendwann von 1.0.5 über 1.6.x zu 1.8.5 bis 1.8.8
gewechselt.
Vielleicht war der Unterschied auch nur damals alles angekreuzt um einen
Universaltester zu bauen, klappte. Später alles angekreuzt und die IDE
schmierte ab.
> Was meinst Du mit "Verschachtelungen"? Die ganzen #ifdefs? Die sind doch> überhaupt kein Problem für den Preprozessor, da kannst Du auch> irgendeinen uralten nehmen.
mag ja sein, vielleicht ist meinem Rechner XP win32 mit 2GB Ram auch nur
die Puste ausgegangen.
Ich sollte es mal mit der IDE 1.8.8 unter win7 64Bit und 8GB Ram noch
mal versuchen, aber momentan habe ich zu viele andere Baustellen.
wenn ich was an meiner wordclock ändern will bleibe ich erst mal bei der
IRMP von 2014, da die funktioniert mit nur einem Dekoder aus einer FB
brauche ich da nichts anfassen.
900ss D. schrieb:> Stefan Z. schrieb:>> das endlich mal offiziell und sauber zu machen>> Wenn alle Software so sauber wie diese Library wäre, dann würde einiges> besser funktionieren. ....kopfschüttel.....
Die Aussage bezog sich offensichtlich auf die Einbindung in das Arduino
/ POI Rep System. Denn das finde ich deutlich sauberer als wenn jeder
User das erst wieder für sich macht und nach Updates neu machen muss.
Dass IRMP super edel gebaut ist weiß ich natürlich.
Meine persönliche Meinung: es ist furchtbar diese Arduino IDE zu
unterstützen. Diese IDE ist das Grauen schlechthin. So einen furchtbaren
und nichts beherrschenden Editor gibt es kaum ein zweites mal. Die IDE
ist zwar im Laufe der Zeit etwas besser geworden aber immer noch
grottig.
Und dann das Buildsystem hinter dem Arduino- Zeugs ist sowas von
durcheinander, dass sucht auch seines gleichen. Wenn man
Arduino-Projekte ohne die IDE bauen möchte, ist das sehr aufwendig bis
es geht. Solch ein Chaos. Und komm mir keiner, es gibt ja ein Plugin für
Eclipse. Das ist seit Jahren buggy. Ich habe es mehrmals probiert. Taugt
nicht.
Nun, Arduino ist zum schnellen Basteln erfunden worden und genau dafür
ist sie auch gut und hat da einen guten Platz.
Aber leider steigen alle Hersteller auf dieses Zeug ein, alles ist
plötzlich Arduino kompatibel und man kommt um dieses Zeug kaum herum,
selbst im professionellen Bereich. Und diese Entwicklung finde ich übel.
Und jetzt auch noch IRMP......ich heul gleich ;)
So, war auch etwas OT aber musste ich loswerden. :)
900ss D. schrieb:> Und komm mir keiner, es gibt ja ein Plugin für> Eclipse. Das ist seit Jahren buggy. Ich habe es mehrmals probiert. Taugt> nicht.
Ich empfehle da Sloeber: http://eclipse.baeyens.it/ , mach ich mit
meinen Schülern...
Ist Arduino Ökosystem mit echter IDE.
900ss D. schrieb:> Meine persönliche Meinung: es ist furchtbar diese Arduino IDE zu> unterstützen. Diese IDE ist das Grauen schlechthin. So einen furchtbaren> und nichts beherrschenden Editor gibt es kaum ein zweites mal. Die IDE> ist zwar im Laufe der Zeit etwas besser geworden aber immer noch> grottig.
Darum PlatformIO!
MS Visual Studio Code kostet auch nix und kann alles - wenn man
rausfindet wie…
> Und dann das Buildsystem hinter dem Arduino- Zeugs ist sowas von> durcheinander, dass sucht auch seines gleichen. Wenn man> Arduino-Projekte ohne die IDE bauen möchte, ist das sehr aufwendig bis> es geht. Solch ein Chaos.
Durchaus, aber inzwischen tuts das schon ganz geschmeidig, wenn man die
Libraries gekonnt auswählt. Wie gesagt: PlatformIO.
> Nun, Arduino ist zum schnellen Basteln erfunden worden und genau dafür> ist sie auch gut und hat da einen guten Platz.
Eben. Dank der vielen Libraries weiß man zumindest schnell ob ein Teil
funktioniert.
> Aber leider steigen alle Hersteller auf dieses Zeug ein, alles ist> plötzlich Arduino kompatibel und man kommt um dieses Zeug kaum herum,> selbst im professionellen Bereich. Und diese Entwicklung finde ich übel.> Und jetzt auch noch IRMP......ich heul gleich ;)
Aber, aber, wer wird denn gleich Tränen vergießen?
IRMP bleibt doch guter Code, jetzt halt noch erweitert um auf Arduino zu
compilieren - was ja wie erwähnt mit einer Stunde basteln eh schon geht.
Am Ende ists doch eh nur C(++) Code der auf einer Zielplattform durch
den Compiler raschelt. Wäre halt nice wenn ich ein neues Projekt
aufmache, den GIT link in die .ini paste, dann ein paar Zeilen Code und
ZACK! habe ich eine IRMP Remote auf einem Arduino, ESP, etc.
Man darf auch nicht vergessen, dass nicht nur die µCs schneller/fetter
werden (Moore's Law), sondern sich auch die Komplexität/Macht der
Entwicklungstools alle paar Jahre verdoppelt. Was ja bei den Anwendungen
heute auch ein wichtiger Vorteil ist!
Vor 15 Jahren musste man noch einen riesen Aufriss für eine
Multimediaanwendung machen, heute code ich sowas an einem Abend im
Browser - inkl. Video-In, GPU Rendering und kompletter GUI.
Armin J. schrieb:> Frank es ist wohl am besten, wenn du ein Github Repository Irmp anlegst> und mich https://github.com/ArminJo dafür auch gleich berechtigst.
Habe ich gemacht: https://github.com/ukw100/IRMP> Soll ich erst mal die Library dort zusammenbauen und später schauen wir> dann, wie wir die Synchronisation mit svn hinkriegen?
Jepp.
> 1. Der Arduino Standardport in den Sourcen ist zurzeit B6, das> funktioniert garantiert auf keinem Arduino, da alle dort den Quarz> haben.> Kann man das ändern, z.B. auf D6 oder D4, oder muss das> rückwärtskompatibel bleiben?
Klar kannst Du das ändern. Der Default muss zu nichts kompatibel sein.
> 2. Muss die irmp.c weiter eine C Source sein, oder kann ich auch ein cpp> draus machen? Dann funktioniert nämlich das Logging aus der Tüte mit der> Arduino Klasse Serial. Ist jetzt nicht sooo wichtig, wäre aber nett.> Vielleicht auch nur für die Arduino Version...
Für die Arduino-Version ist das okay.
> Und wie lasse ich Dir Änderungen für das svn zukommen? Vielleicht baue> ich erst mal die library und sage dann, welche Files ich wo geändert> hab.
Das wäre am besten. Bei größeren Änderungen sind diff-Files hilfreich.
Dank und Gruß,
Frank
900ss D. schrieb:> Meine persönliche Meinung: es ist furchtbar diese Arduino IDE zu> unterstützen.
Ich kann Deine Meinung ja verstehen, aber es tut ja keinem weh, Arduino
zusätzlich zu unterstützen. Es wird ja weiterhin auch ohne Arduino
gehen.
Frank M. schrieb:> Es wird ja weiterhin auch ohne Arduino> gehen.
Das ist auch gut so :)
Noch etwas OT:
Das ist bei vielen Libraries oder Projekten leider nicht der Fall. Man
kann sie ohne Arduino nicht bauen, weil dort viele Abhängigkeiten zu
Arduino bestehen. Man kann es dann besser neu machen. Bei IRMP ist alles
in sich geschlossen, da wird jetzt Arduino "oben drüber" gebaut. Dann
ist es auch ok. Aber bei vielem ist es eben nicht so und dadurch ist man
dann zu dem Zeugs verdonnert oder muss es neu machen. Es gibt einige
gute Libs für Arduino aber man kann sie nur mit Arduino nutzen, obwohl
es ja nur Code für ein AVR (o.a.) uc ist. Das stört mich. Ohne Arduino
kann bald niemend mehr ein Projekt bauen.
Stefan Z. schrieb:> Eben. Dank der vielen Libraries weiß man zumindest schnell ob ein Teil> funktioniert.
Hmmm... bedingt stimme ich dir zu. Man weiß oft nicht, wenn es nicht
funktioniert, ob es nicht doch die Library ist.
So die Arduino library ist fertig!
https://github.com/ukw100/IRMP
Jetzt werde ich noch ein bischen an der Doku schreiben.
@Frank, guck dir mal die library.properties an, ob die
Verantwortlichkeiten und Mailadressen in deinem Sinne sind. Die Zeile
paragraph= werde ich noch im Rahmen der Doku erweitern.
Armin J. schrieb:> Hi, ich versuche gerade IRMP zu verstehen und bin dabei über> folgendes gestolpert: {> #ifdef ANALYZE> ANALYZE_PRINTF ("protocol = UNKNOWN\n");> #endif // ANALYZE>> irmp_start_bit_detected = 0;> // wait for another start bit...> }> if (irmp_start_bit_detected) {>> für mich sieht das so aus, dass die Bedingung immer false ist, oder> übersehe ich da was?
Ja, Du übersiehst die Zeile direkt darüber, also hier die 1. Zeile:
1
else
2
#endif // IRMP_SUPPORT_RCMM_PROTOCOL == 1
3
{
4
#ifdef ANALYZE
5
ANALYZE_PRINTF("protocol = UNKNOWN\n");
6
#endif // ANALYZE
7
irmp_start_bit_detected=0;// wait for another start bit...
8
}
9
10
if(irmp_start_bit_detected)
11
{
In das obige "else" geht er nur, wenn ganz spezielle Bedingungen
vorliegen. Beachte auch, dass die noch weiter darüberliegenden
if-Bedingungen noch ein "else" darüber stehen haben - je nachdem, welche
Protokolle aktiviert sind.
Ja, die vielen Preprocessor-Statements machen das ziemlich
unübersichtlich. Aber nur so kann man den Code auf die tatsächlich
genutzten Protokolle reduzieren, damit das auch noch auf einem ATTiny
läuft.
Frank M. schrieb:Frank M. schrieb:> In das obige "else" geht er nur
DANKE!
Bei mir steht das aktive else ca 650 Zeilen vorher, das hab ich glatt
übersehen ;-).
Aber alles gut, ich würde es genauso machen...
Ich versuche gerade IRMP (erstmal nur NEC) mit PinChangeInterrupt zu
betreiben. Klappt schon recht gut.
So,
ich bin so weit, die Library https://github.com/ukw100/IRMP ist jetzt
schön und einfach gemacht.
Wenn Frank zustimmt, würde ich dann ein Release bauen, und beantragen,
es als Arduino Library aufzunehmen.
Hallo Frank,
hab Probleme beim kompilieren des Arduino Samples. Als Board hab ich
Olimex Mod Wifi ESO 8266DEV ausgewählt und bin nur auf kompilieren
gegangen. Wird jedoch abgebrochen da /util/setbaud.h nicht gefunden
wird. Diese hab ich versucht nach zu installieren wird aber weiterhin
nicht gefunden. Hast du eine Idee ?
(Eigenltich möchte ich nur IR Codes analysieren, und wollte es auf dem
Wemos D1 Mini zum laufen bringen).
Installiert habe ich die IRMP.zip von dieser Webseite.
Grüsse
Hallo Frank,
ich habe hier eine Onkyo RC-911R FB, die das NEC-Protokoll verwendet -
zumindest alle Tasten bis auf eine. Im oberen Bereich befinden sich 12
Tasten zur Selektion der Quelle, die letzte davon ist mit Bluetooth
beschriftet und wird von IRMP nicht erkannt. Angehangene Protokolldatei
wurde mit 15kHz Taktung aufgezeichnet. Wirf bitte einen Blick darauf.
Danke vorab.
Die Bluetooth-Taste benutzt auch das NEC-Protokoll. Allerdings verletzt
sie die Regel, dass im vierten und letzten Byte die Bits invertiert zum
dritten Byte wiederholt werden.
Bits im 3. Byte: 00001010
Bits im 4. Byte: 01110000
Aus diesem Grund wird das Ergebnis verworfen, da von einem
Übertragungsfehler ausgegangen wird.
Bei allen anderen Tasten wird die Regel befolgt, z.B. bei PHONO:
Bits im 3. Byte: 11010000
Bits im 4. Byte: 00101111
Hier sieht man schön, wie 1 und 0 immer übereinander bzw. untereinander
stehen.
Wie könnte man jetzt lösen, dass die Taste trotzdem erkannt wird? Ich
möchte die obige Regel eigentlich nicht außer Kraft setzen, denn sie
passt sonst immer. Noch niemand hat mir je einen Code präsentiert, wo
auch diese Regel verletzt wird. Außerdem ist sie im Internet gut
dokumentiert.
Ich schlage folgendes vor:
Ich führe ein neues Protokoll "ONKYO" ein, auf welches gewechselt wird,
wenn die Regel verletzt wird. Dann bekommt man nicht nur 2 Bytes für die
Adresse (Extended NEC), sondern auch 2 Byte (statt nur eins) für das
Kommando.
Interessant ist bei dieser FB auch, dass nicht nur die BLUETOOTH-Taste
eine abweichende Adresse benutzt, sondern auch die Taste BD/DVD. Kann es
sein, dass man diese FB für verschiedene Onkyo-Geräte verwenden kann?
Boris S. schrieb:> hab Probleme beim kompilieren des Arduino Samples. Als Board hab ich> Olimex Mod Wifi ESO 8266DEV ausgewählt und bin nur auf kompilieren> gegangen. Wird jedoch abgebrochen da /util/setbaud.h nicht gefunden> wird.
Ich vermute mal, dass util/setbaud.h nur für AVRs existiert. Ich selbst
habe auch nicht den Arduino-Port gemacht, sondern Armin J. Du findest
seinen letzten Beitrag hier genau über Deinem. Vielleicht kann Armin ja
noch etwas dazu sagen.
Ich selbst kann nur vermuten, dass der Arduino-Code tatsächlich nur für
AVRs getestet wurde.
Frank M. schrieb:> Ich führe ein neues Protokoll "ONKYO" ein, auf welches gewechselt wird,> wenn die Regel verletzt wird.
Gesagt, getan, ist online als Version 3.1.4.
Viel Spaß,
Frank
Hallo Frank,
ich teste gerade die ESP Versionen für Arduino und dabei ist mir
aufgefallen, dass das PENTAX + GREE Protokoll inkompatibel mit dem Lego
+ RCMM Protokoll ist, weil es bei #define F_INTERRUPTS 20000 zu 8 Bit
Überlauf bei den Konstanten PENTAX_START_BIT_PULSE_TIME und
GREE_START_BIT_PULSE_TIME kommt.
Sollte man die beiden Protokolle nicht genauso bei 20000 abschalten, wie
Lego + RCMM bei 15000 abgeschaltet wird?
Hallo Armin,
ich versuche IRMP es auf eine ESP8266 zum laufen zu bringen, in meinem
Fall ein Wemos D1 Mini. Aber wenn ich auch das Borad Olimex Mod Wifi ESO
8266DEV nehme, kommen diverse Fehlermeldungen. z.B. liegt
/util/setbaud.h nicht vor. Ich glaube das brauche ich eigentlich nicht.
Mir geht es spezielle um ACP25 Protokoll (hab ein baugleiche Klimaanlage
von Trotec).
Hast du eine Idee ?
Grüss
Hi Armin,
Armin J. schrieb:> Sollte man die beiden Protokolle nicht genauso bei 20000 abschalten, wie> Lego + RCMM bei 15000 abgeschaltet wird?
Ja, das ist eine gute Idee. Ich habe es gemacht und ins SVN als Version
3.1.5 eingecheckt. Die Änderungen sind alleinig in irmp.h:
# warning F_INTERRUPTS too high, GREE protocol disabled (should be max 16000)
9
# undef IRMP_SUPPORT_GREE_PROTOCOL
10
# define IRMP_SUPPORT_GREE_PROTOCOL 0
11
#endif
P.S.
Ich habe hier mal 16000 als obere Schranke gewählt. Das sollte reichen,
um den Wert für den Startbit-Counter noch unter 256 zu halten. 18000
sollte zwar auch noch gehen, könnte aber knapp bei späteren
Toleranzänderungen werden.
Startbit-Länge bei Pentax ist 13 msec.
Dann gilt für den Zählwert:
Thread beobachten
Seitenaufteilung abschalten