Hi,
schon langsam wird mein Projekt fertig. Deswegen will ich hier einmal
die Vorabversion zur Verfügung stellen. Der eine oder andere kann mir
sicher helfen den AVR-Code noch etwas zu optimieren ;).
Erst einmal vielen Dank an das Forum + Community!
Auch spezielen Dank an Frank M. für sein IRMP: IRMP
Anlass für dieses Projekt war mein veralteter Igor AVR USB AT90S2312-10,
der nur RC5 konnte. Hier war die IR-Code Erkennung nicht ausreichend gut
genug um ein schönes Anwenden zu gewährleisten.
Deswegen habe ich Irmp mit V-USB verbunden um einen IR-MultiCode
Empfänger für die USB Schnittstelle zu haben.
Die Serielle COM Schnitstelle will ich nicht haben, da heutzutage viele
PCs schon nicht mehr über einen COM-Port verfügen.
Der Aufbau des Projektes unterscheidet sich in folgenden Dingen vonanderen IR-Empfänger
IR Multi Protokol Empfänger (Irmp),
Empfangene IR-Codes werden native an den Host übertragen: dies bedeutet,
dass jeder wie er will die IR-Codes am Host auswerten kann. Z.B. ein
Input Plugin für Girder oder auch einfach ein Mapping der IR-Codes zu
globalen Tastendrücken.
Der erste Empfangene IR-Code wird im EEProm abgespeichert. Dieser wird
für die sogenannte "PowerOn" Funktion verwendet.
Die PowerOn Funktion
Entspricht der empfangene IR-Code dem gespeichertem IR-Code wird für
~200ms ein Ausgang des AVR geschaltet. An diesem Ausgang kann z.B. ein
Optokoppler angeschlossen werden um damit den Power-Schalter des PCs zu
betätigen. Die PowerOn Funktion im AVR läßt sich von der Host-Software
einschalten/ausschalten.
Aufbau des AVRs
Verwendet habe ich den Atmega8-16,
mit 12MHz Quarz,
IR-Empfänger (definiert in irmp.c): TSOP1736 an PD4 (siehe Irmp
Beschreibung)
Optokoppler (definiert in main.c): an PC5
D- (defniert in usbconfig.h): PD0
D+ (defniert in usbconfig.h): PD2 (INT0)
Optional Jumper to GND for Bootloader: PD3 (siehe bootloader config)
Datenaustausch AVR <-> Host Software
Der Datenaustausch basiert auf dem Beispiel von V-USB: hid-data.
Es werden per Feature-Requests Daten gesendet/empfangen.
Dazu gibt es folgende Report IDs:
Um an die aktuellen IR-Code zu kommen muss das Feature ID1 durch Polling
abgefragt werden (~10-50ms).
Über die ID6 kann die Polling Frequenz des IR-Empfängers On-The-Fly
geändert werden. Bei mir waren mit der TSOP1736 115µs am besten.
(Bin mir jedoch hier noch nicht sicher ob diese Berechnung richtig ist,
dazu kann mir hier sicher jemand Auskunft geben).
Getestet habe ich das RC5, NEC & SIRCS Protokol.
Bootloader
Durch V-USB bietet sich ein Bootloader an. Um diesen zu benützen müssen
die Fuses richtig gesetzt werden (Screenshot im bootloader.zip). Durch
setzen des Jumpers auf PD3 kann dann einfach per der Software
"HIDBootFlash.exe" eine neue Version des USB IR Remote Receivers
eingespielt werden.
Host Software
Anbei ein Beispiel einer Host-Software mit Delphi2010 Source. Es wird
die JVCL TJvHidDeviceController Komponete benötigt. Mit der
Host-Software kann man alle Funktionen des AVR ausprobieren. Es wird
auch gezeigt wie das Repeat-Flag von Irmp ausgewertet wird. Wird ein
IR-Code mehr als 5 mal wiederholt wird er wieder normal weitergeleitet
(Tastenentprellung).
Hallo Hugo,
Hugo Portisch schrieb:
> schon langsam wird mein Projekt fertig. [...]
Eine interessante Anwendung von IRMP :-)
Mich interessiert die V-USB-Anbindung, damit habe ich bisher noch nicht
gearbeitet. Das scheint aber eine preisgünstige Möglichkeit zu sein,
AVRs an einen PC anzubinden... werde mich da mal einarbeiten.
> *Host Software*> Anbei ein Beispiel einer Host-Software mit Delphi2010 Source.
Ich habe kurz in den Source reingeschaut. Das sieht auf Host-Seite
ziemlich aufwendig aus, ein paar Bytes von links nach rechts zu
schubsen. Ich bin auch kein Freund von Pascal/Delphi, gibt es da
vielleicht irgendwo irgendeinen Beispiel-Source für den Host, der in
C/C++ geschrieben ist?
> Es wird die JVCL TJvHidDeviceController Komponete benötigt.
Ist das ein Treiber? Ich dachte, wegen Hid braucht man keine Treiber?
Ich weiß, dass Du zunächst mit einem PC-Mainboard und V-USB Probleme
hattest. Die sind mit dieser JVCL-Komponente weg... wo bekommt man diese
Komponente? Sorry für die vielleicht blöde Frage.
Gruß,
Frank
Frank M. schrieb:
> Das sieht auf Host-Seite> ziemlich aufwendig aus, ein paar Bytes von links nach rechts zu> schubsen. Ich bin auch kein Freund von Pascal/Delphi, gibt es da> vielleicht irgendwo irgendeinen Beispiel-Source für den Host, der in> C/C++ geschrieben ist?
Kommt halt immer drauf an was man vorhat. Hugo möchte auf PC-Seite die
"Rohdaten" haben und die dann dort weiterverarbeiten. Mein Ansatz wäre
es den AVR als HID-Tastatur zu nutzen. Dadurch dürfte die zu
übertragende Datenmenge wesentlich geringer ausfallen und noch dazu ist
eben keine spezielle Software auf PC-Seite nötig, sondern man kann quasi
mit der FB Texte schreiben (ohne irgendwelche Treiber o.ä.).
> Beispiel-Source für den Host, der in C/C++ geschrieben ist?
Ja, es gibt vom V-USB Paket das Example "hid-data".
In C/C++ kann das HID-Gerät glaube ich nativ angesprochen werden.
Das Beispiel zeigt einen Datatransfer down & up von 128Bytes. Man müsste
es umbauen, damit die Feature Request IDs und die richtigen Anzahl von
Bytes unterstützt werden. Dazu habe ich aber zu wenig Ahnung von C...
http://www.obdev.at/products/vusb/download.html> Ist das ein Treiber?
Nein, kein Treiber. Eine Komponente. Sie wird nur zum Kompilieren des
Sources benötigt. Original kann man mit Delphi nicht mit HID-Geräten
arbeiten. Hatte es zuerst auf Native Art versucht (über hid.dll usw).
Dadurch sind die Probleme entstanden, die ich bei meinem anderen Thread
genannt hatte (V-USB geht nicht an jedem USB-Port).
JVCL ist eine Sammlung von Komponenten, eben auch die HID-Komponente um
einfach mit dem Device arbeiten zu können. JVCL per Google: JEDI Visual
Component Library.
USB-Treiber wird wegen HID nicht benötigt! War auch einer der
Hauptgründe warum ich vom Igor USB weg bin!
Derzeit bin ich daran:
Irmp-Version besser als "String" zu übertragen,
neueste Irmp Version einfügen...
@Frank M.: wenn ich alle Prokolle in irmp.c aktiviere werden ja alle
Protokolle mit kompeliert. Dann kann man aber nicht mehr verschiedene
Protokolle "OnTheFly" deaktivieren/aktivieren, oder?
Dies wäre von Vorteil, denn dann werden einfach alle Protokolle
kompeliert und je nach IR-Diode usw per Host-Software
deaktivieren/aktivieren. -> AVR-Source muss nicht extra kompeliert
werden.
Zu dem IR-Polling-Timer:
Er soll ja ~1/10000-1/15000 sein.
Rechne ich so richtig?: (1/10000) / (1/12000000) -1; = 1199 = 100µs?
für 1/15000:
(1/15000) / (1/12000000) -1; = 799 = 66,58µs?
Zählt der Timer von 0 zu 1199? Eignetlich hatte ich gedacht das er von x
zu 0xFFFF zählt. Das würde sich aber nicht ausgehen.
Es geht darum ob die Berechnung, die im Delphi Source drinnen ist,
richtig ist.
Danke!
Hier gleich zuerst noch ein Update!
Es wird die Irmp Version nun so definiert:
1
//enter here the Irmp build date:
2
const char StrIrmpVersion[] = "17.03.2010";
Maximale Laenge: 11 Char (0-terminierung inkludiert).
Etwas zusammenräumen... Auch hatte ich im ersten Post den falschen
Bootloader hochgeladen.
Delphi Source ist nun auch 1.0.0.1 wegen Änderung Irmp Version auf
C-String.
mfg
Hugo Portisch schrieb:
> Ja, es gibt vom V-USB Paket das Example "hid-data".
Danke für den Tipp, schaue ich mir bei Gelegenheit an.
> @Frank M.: wenn ich alle Prokolle in irmp.c aktiviere werden ja alle> Protokolle mit kompeliert. Dann kann man aber nicht mehr verschiedene> Protokolle "OnTheFly" deaktivieren/aktivieren, oder?
Warum möchtest Du die on-the-fly deaktivieren/aktivieren?
> Dies wäre von Vorteil, denn dann werden einfach alle Protokolle> kompeliert und je nach IR-Diode usw per Host-Software> deaktivieren/aktivieren. -> AVR-Source muss nicht extra kompeliert> werden.
Du kannst einfach alle einschalten (das ist ja auch der Standard). IRMP
erkennt das von der FB gesandte Protokoll automatisch. Ich verstehe
jetzt nicht, warum man da welche abschalten soll - ausser man hat
zuwenig Platz im Flash. Und das hat nur Sinn "At-Compile-Time".
> Zu dem IR-Polling-Timer:> Er soll ja ~1/10000-1/15000 sein.> Rechne ich so richtig?: (1/10000) / (1/12000000) -1; = 1199 = 100µs?> für 1/15000:> (1/15000) / (1/12000000) -1; = 799 = 66,58µs?
Das wird per C-Preprocessor in der Beispiel-main.c doch automatisch
"ausgerechnet":
void
timer_init (void)
{
OCR1A = ((F_CPU / F_INTERRUPTS) - 1);
}
Also bei 12MHz und 10kHz :
OCR1A = ((12000000 / 10000) - 1);
Und das macht 1199 für 10 kHz <==> 100µs bzw 799 für 15 kHz <==> 66µs.
Deine obige Rechnung istg also soweit korrekt.
> Zählt der Timer von 0 zu 1199?
Jepp.
Warum musst Du da was im Delphi-Source berechnen? Warum muss der PC
wissen, mit welcher Interrupt-Frequenz der AVR läuft?
Gruß,
Frank
> Warum möchtest Du die on-the-fly deaktivieren/aktivieren?
Hab mir nur gedacht, dass dann im fertigem Paket eine Hex Datei mit
drinnen ist. Nicht jeder ist in der Lage den Source zu kompelieren.
Somit könnte man dann ein HEX-File haben und je nach dem die Protokolle
benutzen. Wenn es ausser Platzersparnis nix bringt bringt es eigentlich
wirklich nichts...
> Das wird per C-Preprocessor in der Beispiel-main.c doch> automatisch "ausgerechnet":
Ja, dass stimmt! Jedoch geht es bei mir (mit V-USB + TSOP1736) bei 115µs
besser als bei 100µs. Deswegen habe ich mir gedacht diesen Wert
einstellbar zu machen. Derzeit habe ich RC5, RC6, NEC + SIRCS
erfolgreich testen können. (Philips Prestigo sei Dank!)
> Warum musst Du da was im Delphi-Source berechnen? Warum muss der PC> wissen, mit welcher Interrupt-Frequenz der AVR läuft?
Danke für den Tipp! Die Berechnung könnte ich natürlich in den AVR
auslagern! Dann wird die AVR Frequenz am Host nicht mehr benötigt.
Hatte ja in Delphi direkt OCR1A berechnet, dieser neue Wert wurde per
USB runtergeschrieben.
Werd's so umbauen, dass einfach die µs runtergeschickt werden. OCR1A
kann dann ja im AVR berechnet werden.
Habe eh schon wieder einiges am Code herumgeschraubt...
21032010: Update
New
Timer0 (Startup Delay) wird nicht mehr benötigt. Die Timer1 Interrupt
Routine kann nun vom USB Transfer unterbrochen werden. Somit gibt es
keine Probleme mehr beim USB-Init mit dem Host. Das Erkennen von
IR-Codes scheint deswegen aber nicht beeinträchtigt zu sein. ;)
Sonstige Code Optimierungen...
Anbei der aktuelle Irmp+V-USB AVR Source und ein Update vom Delphi
Source.
Auch ist im AVR Source ZIP-File nun eine Schematik des Aufbaues
enthalten.
Auch ein kleines Bild wie man z.B. die IR-Codes am Host dann verwenden
kann.
mfg
Portisch
Update 26032010
Die vom Irmp dekodierten IR-Signale werden nun per USB-Interrupt zum
Host übertragen. Dadurch braucht man den AVR nicht mehr per Polling
abzufragen.
Die Tastenentprellung wird nun im AVR durchgeführt (MinRepeats). Bleibt
die Taste gedrückt wird der Counter durch das Irmp-Repeat-Flag erhöt.
Durch die Variable MinRepeats kann man festlegen wie oft der Befehl
wiederholt werden muss bis er wieder zum Host durchgelassen wird.
Die Anzahl der Widerholungen kann OnTheFly vom Host verstellt werden.
Ein guter Wert sollte so ca. 3-5 sein.
Anbei die neue AVR Version für Interrupt-Übertragung und eine neue Host
Software Demo. Der Code ist weniger geworden, da die Tastenentprellung
nun im AVR erledigt wird.
@Frank M.:
Ist es vielleicht möglich das Debugging auch per USB-Interrupt zu
erledigen? Habe hier eine Universal-Fernbedienung, bei der Irmp beim
NEC-Protokoll das Repeat-Flag erst nach dem 2. mal setzt. Daher kann ich
das nicht entprellen...
Vielleicht wenn man die '0' und '1' per Counter/Bitshift in ein Word
packt und dieses dann überträgt?
Beispiel des LOGs der Demo Software:
EDIT:
Für das Debug wäre es doch eine Idee die Irmp Struktur um 1 Byte/Word
für den Debug zu erweitern. Dann wird der Debug Wert einfach immer bei
einer Eingabe mitgesendet. Am Host kann man den Hexwert ja wieder auf
Text '0000101010...' zurück wandeln.
Hugo Portisch schrieb:
> @Frank M.:> Ist es vielleicht möglich das Debugging auch per USB-Interrupt zu> erledigen?
Du meinst Logging, nicht Debugging, oder?
Könnte gehen. Wie schnell bekommst Du denn Daten mit V-USB über die
Leitung? Bei eingeschaltetem Logging puffert IRMP die Daten bis zu einem
Timeout, bevor sie über UART ausgegeben werden. Damit beeinflusst die
Log-Ausgabe nur unwesentlich das Zeitverhalten der ISR.
> Habe hier eine Universal-Fernbedienung, bei der Irmp beim> NEC-Protokoll das Repeat-Flag erst nach dem 2. mal setzt. Daher kann ich> das nicht entprellen...
Es gab da ein Problem, auf das ich heute hingewiesen wurde: Ein
NEC-Repetition-Frame wird nur einmal erkant, danach werden weitere
Repetition-Frames verworfen. Ich habe das Problem glücklicherweise
schnell finden können und habe eben eine neue IRMP-Version erstellt -
liegt zum Download bereit, siehe
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"> Vielleicht wenn man die '0' und '1' per Counter/Bitshift in ein Word> packt und dieses dann überträgt?
Könnte klappen, schau Dir bitte mal irmp_logIr() näher an. Hier müssten
die Aufrufe von irmp_uart_putc() durch geeignete USB-Funktionen ersetzt
werden.
> 19:07:41: Trained IR Code: Protocol : RC6, Address: 0x0027, Command:> 0x000C, Flags: 0x00
Sehe ich das richtig, dass Deine RC6-FB korrekt erkannt wird? Kannst Du
mir mal Hersteller und Bezeichnung nennen? RC6 ist ja (noch) ein kleines
Sorgenkind von IRMP.
> Du meinst Logging, nicht Debugging, oder?
Klar, mein Fehler!
> Könnte gehen. Wie schnell bekommst Du denn Daten mit V-USB über die> Leitung?
Ich glaube damit könnte es Probleme geben. Bei meinen Messungen mit dem
Oszi habe ich Zeiten von ~4-20ms gemessen.
> NEC
Danke! Werde die neue Version testen.
> RC6
Das müsste ein Nokia Sat-Rekorder sein (jedoch von meiner
Universal-Fernbedienung). Genauer Daten liegen mir davon nicht vor.
Hatte es mit z.B. auch mit Humax versucht, jedoch war hier das Problem
mit dem Repeat-Flag. Welches Gerät das genau ist muss ich in der
Geräte-Liste nachsehen (wenn ich die dann einmal finde)
> Logging
Hatte die Logging Funtkion irmp_logIr (uint8_t val) etwas falsch
verstanden. Nach deinem Hinweis habe ich es jetzt so verstanden:
Es kommt ein Signal über den Input Pin,
Daten werden in den Buffer: static uint8_t s_data[c_datalen]; geladen
Wenn "längere" Zeit kein Input mehr kommt wird der Byte Buffer (max.
c_datalen 700) in '0' und '1' per bitshift zerlegt und am Uart
ausgegeben.
Somit wird sich anbieten gleich s_data[c_datalen] per USB zu übertragen.
Die Zerlegung in nullen und einsen kann dann ja der Host erledigen.
Per Interrupt kann man maximal 8 Bytes auf einen Schwung übertragen.
Somit würden 88 Übertragungen für 700 Bytes notwendig sein. Dies wird
jedoch sowieso durch die for-Schleife abgekürzt.
Per Feature Request kann man die 700 Bytes schon "auf einen Schwung"
übertragen, doch dieser Wert muss dann vom Host angefragt werden.
Wird diese Ausgabe wirklich benötigt?
1
for(i=0;i<c_startcycles;++i)
2
{
3
irmp_uart_putc('0');// the ignored starting zeros
4
}
Da weis ich nähmlich nicht wieviele Interrupts zusammen kommen...
So könnte es einen Versuch wert sein:
1
uint16_ti;
2
staticuint8_ts_data_buffer[9];
3
4
s_data_buffer[0]=ReportIDLogging;
5
s_data_buffer[1]=0x00;
6
7
for(i=0;i<c_startcycles;++i)
8
{
9
while(!usbInterruptIsReady())usbPoll();// check if USB int is ready
10
usbSetInterrupt(&s_data_buffer[0],2);// send ReportID + IR data
11
}
12
13
for(i=0;i<(s_dataIdx-c_endBits+20)/8;++i)// transform bitset into uart chars
14
{
15
memcpy(&s_data_buffer[1]),&s_data[i*8],8);
16
17
while(!usbInterruptIsReady())usbPoll();// check if USB int is ready
18
usbSetInterrupt(&s_data_buffer[0],9);// send ReportID + IR data
Hugo Portisch schrieb:
> Nach deinem Hinweis habe ich es jetzt so verstanden:> Es kommt ein Signal über den Input Pin,> Daten werden in den Buffer: static uint8_t s_data[c_datalen]; geladen> Wenn "längere" Zeit kein Input mehr kommt wird der Byte Buffer (max.> c_datalen 700) in '0' und '1' per bitshift zerlegt und am Uart> ausgegeben.
Korrekt.
> Somit wird sich anbieten gleich s_data[c_datalen] per USB zu übertragen.> Die Zerlegung in nullen und einsen kann dann ja der Host erledigen.
Ja, genau. Bei UART werden 0en und 1en übertragen, weil man diese ganz
einfach per Copy&Paste mit jedem Terminalemulationsprogramm abgreifen
kann. Bei USB kann man natürlich auch das Array übertragen, damit
schrumpft dann die Datenmenge auf ein Achtel.
> Wird diese Ausgabe wirklich benötigt?>
1
for(i=0;i<c_startcycles;++i)
2
>{
3
>irmp_uart_putc('0');
4
>// the ignored starting zeros
5
>}
> Da weis ich nähmlich nicht wieviele Interrupts zusammen kommen...
Ja, die Ausgabe wird gebraucht. Und zwar gibt es in der Log-Funktion
eine Art "Störfilter", die erstmal abwartet, wie lang denn da der Puls
ist und einfach nur mitzählt. Erst wenn der Puls eine gewisse Breite
hat, wird mitprotokolliert, d.h. der Scan wird erst dann gestartet.
Obige Schleife schreibt den ersten Impuls des Frames. Du könntest aber
einfach den Wert von c_startcycles übertragen und der Host wandelt das
dann in die entsprechende Zahl von 0en.
> So könnte es einen Versuch wert sein:
Schick mir einfach mal einen Scan-Buffer, den Du über USB übertragen
hast. Ich sag Dir dann, ob der okay ist ;-)
Gruß,
Frank
Update 29032010
Es ist nun die neue Irmp Version vom 29032010 drinnen.
Bei NEC wird nun das Repeat-Flag richtig erkannt! Thx Frank M.
Das mit dem Logging über USB habe ich noch nicht geschafft. Mal sehen ob
das noch was wird...
Das is ja ma was, das ist genau das, was ich suche!! Bei mir
funktioniert das Igor Teil wegen 64 bit betriebssystem nicht...deswegen
suche ich eine Alternative und da scheint mir das genau richtig
Funktioniert schon alles (z.B. RC5)? Was ich noch nicht ganz beim
Überfliegen verstanden hab: wofür genau braucht man das Delphi Programm?
Ist vielleciht für euch eine ziemlich blöde Frage xD
Werde das morgen mal aufm Steckbrett aufbauen, hoffe ich habe alle Teile
da aber sieht gut aus. Bin schon sehr gespannt!
Gruß, Hendi
Danke für das Lob!
Das Delphi Programm ist eine Demo wie man mit dem USB IR Remote Receiver
Daten empfangen/senden kann.
Ich bin gerade dabei eine Demo für C++ Win32 Konsole (VS2008) zu
schreiben.
Auch werde ich noch eine DLL machen, die sich um die Handhabung der
Hardware kümmern soll. Durch die DLL kann man dann einfach mit dem
Empfänger arbeiten ohne mit HID herumzuspielen zu müssen. Die DLL kann
dann ja von anderen Programiersprachen (egal C++, C#,...) verwendet
werden.
RC5 geht sicher. Selber habe ich RC5, RC6, NEC & SIRCS probieren können.
Einfach die letzte Version vom 29032010 nehmen. Die Host-Software-Demo
dazu ist die: Irmp_V-USB_mit_INT_1.0.0.0.zip
mfg
Portisch
Da muss ich mich erst durchlesen...
Ich weis nicht ob WinLirc mit Plugins arbeitet, oder ob die
Hardwareunterstützung direkt in WinLirc enthalten ist.
Wenn es über ein Plugin (ähnlich wie bei Girder) läuft sollte man recht
einfach ein Plugin für Winlirc erstellen können, dass dann die "USB IR
Remote Receiver DLL" (die's "noch" nicht gibt) benutzt um mit der
Hardware zu reden.
Hugo Portisch schrieb:
> Das Delphi Programm ist eine Demo wie man mit dem USB IR Remote Receiver> Daten empfangen/senden kann.
Ah ok praktisch :)
Auch werde ich noch eine DLL machen, die sich um die Handhabung der
Hardware kümmern soll. Durch die DLL kann man dann einfach mit dem
Empfänger arbeiten ohne mit HID herumzuspielen zu müssen. Die DLL kann
dann ja von anderen Programiersprachen (egal C++, C#,...) verwendet
werden.
Nicht schlecht du entwickelst wirklich gerade das Rundumsorglos paket!
Darf ich fragen, wie weit du schon bist?
Naja, mit der DLL habe ich noch nicht angefangen.
Bin noch am Überlegen wie man das am besten Umsetzt.
Die C-Demo ist bis auf den Interrupt Receive eigentlich fertig. Für das
mit dem Interrupt-Receive kenne ich C zu wenig.
Zu Lirc:
Ist Linux, benutze nur Win. Man müsste dort einmal nachfragen ob die den
Empfänger aufnehmen wollen...
Zu Winlirc:
Es scheint so als unterstüzt Winlirc nur IR-Empfänger für RS232 - nix
USB.
Zur DLL überlege ich auch noch folgendes:
derzeit habe ich schon eine DLL die mit DVBViewer als Input-Plugin
läuft. Diese werde ich hernehmen und extra Funktionen exportieren, damit
diese auch für andere Programme verwendet werden kann. Auch überlege ich
in diese DLL einen Support von z.B. Girder zu implementieren. Mal sehen
was die Zeit bringt.
So,
hab jetzt schon einiges geschafft. Es gibt nun eine DLL die direkt im
DVBViewer & Girder verwendet werden kann.
Auch kann man per eigener "Auswerte-Software" die DLL laden und die
IR-Codes empfangen.
Somit muss man sich nicht um das Hardware-Handling kümmern.
Es ist eine Doku dabei, was den Gebrauch für Delphi und C erklärt.
Ob die C Doku ganz stimmt kann ich nicht sagen, da ich es zwecks zuwenig
C Kenntnissen nicht überprüfen kann!
Ob's auch auf 64Bit Systemem geht... hab ich nicht probiert!
Für Probleme/Kritik bin ich jederzeit bereit!
mfg
Portisch
Ich bin schon sehr gespannt!! leider hab ich im mOm wenig Zeit da ich
viele Klausuren schreibe. Ich möchte demnächst ein paar Teile bestellen
und ich hab gesehn dass ich doch nicht alles da habe sonst hätte ichs
schon aufgebaut. Welche Dioden hast du verwendet?
Dioden?
Die Z-Dioden sind 3,6V 0,5W
Bin mit der 1.0.0.3 schon fast fertig!
Zu dieser habe ich dann auch noch eine Demo-Console-Programm in C für
VS2008:
*Update 1.0.0.3*
Es wird nun DVBViewer, Girder und selbst erstellte Programme von der DLL
unterstützt.
Auch ein großes Docu Update...
Auch neu ein VS2008 Demo Console Programm wie man die DLL lädt und IR
Codes empfängt.
mfg
Portisch
Update 1.0.0.4
DLL:
Bugfix mit DVBViewer Settings/Option Dialog,
es kann nun im INI File ein Tastenunterdrückung eingestellt werden (Key
Suppression).
Default ist keine. Siehe USB_IR_Remote_Receiver_DLL_help.htm
AVR:
Optimierung der IR Code Erkennung für die PowerOn Funktion,
Bugfix wenn eine Taste länger als 255 Wiederholungen gedrückt war
mfg
Portisch
Hi,
Hab deinen Empfänger mal aufm Steckbrett nachgbaut. Wird unter Windows
XP SP3, Windows7 32 bit und Windows7 64 bit korrekt erkannt =)
Hab mir mal die Trial von Girder 5.nochwas runtergeladen, plugin in
Ordner und gestartet.Erst gings gar nicht, bis ich drauf gekommen bin ,
dass ich noch ein Häckchen bei dem IR Remote Receiver setzen musste. Jo
die Fernbedienungsaktionen werden einwandfrei un sehr schnell erkannt
und ich kann diese dann zuordnen. So wenn ich jetzt aber z.B. definiert
habe, dass wenn ich den Play knopf drücke, dass dann Play/Pause sein
soll und den Mediaplayer oder VLC aufmache und ein Film starte und jetzt
auf der Fernbedienung den Play bzw Pause Knopf drücke passiert nichts
aber in Girder sehe ich unten links, was gerade für ein Code übertragen
wird. Aber wie gesagt es bleibt alles ohne Funktion?! Woran kann das
kiegen? Ich kenne mich mit Girder leider gar nicht aus deswegen meine
Frage. Hoffe du kannst mir da weiterhlefen. Ansonsten TOP Arbeit!!
Gruß, Hendi
Michael M. schrieb:> girder ist seeehr verbreitet und außerdem auch vom hersteller> hervorragend dokumentiert...> du solltest wirklich alles wichtige finden können.
Also ich kriegs einfach nicht gebacken es funktioniert jetzt alles bis
auf Play/Pause im mediacenter und Mediaplayer. Woran leigt das denn das
kann doch wohl nicht sein?! Grad eine der wichtigsten Tasten. Ich habe
leider nicht gefunden wie ichs beheben kann sonst hätte ich nicht
gepostet, hoffe mir kann jemand helfen!
Gruß, Hendi
Mhm also ich verwende Girder 5 und ich hab keine Ahnung, wo diese
Funktion sein soll sry. ich hab gerade alles durchgeschaut und nichts
gefunden. Ich bin mittlerweile sowet, dass es ansatzweise funktioniert
wenn ich Play und Pause auf zwei getrennte Tasten lege aber es
funktioniert auch nicht richtig, da es eher Zufall ist ob er Pause oder
Play macht.Es sieht dannn so aus als würde man Pause drücken und sofort
wieder Play und das die ganze Zeit.
Soo also ich habs jetzt einigermaßen hingekriegt. Zwar nicht mit dem
Window Picker sondern: Hab mir eine GML fürs Windows 7 Mediacenter
runtergeladen und dann im Expertenmodus nochmal alles neu eingestellt.
Ich hab jetzt festgestellt, dass man einfach nur eins von beiden
definieren darf (glaub ich hab jetzt Pause genommen) und das andere
einfach leer lässt. Es ist zwar so sehr empfindlich aber es geht. D.h.
man muss entweder nur ganz kurz oder länger drücken wenn man ganz
"normal" drückt funktionierts nicht wirklich.Wie bekommt man das ganze
denn ein bisschen unempfindlicher, es reagiert insgesamt sehr
empfindlich?
Hendi schrieb:> Es ist zwar so sehr empfindlich aber es geht. D.h.> man muss entweder nur ganz kurz oder länger drücken wenn man ganz> "normal" drückt funktionierts nicht wirklich.Wie bekommt man das ganze> denn ein bisschen unempfindlicher, es reagiert insgesamt sehr> empfindlich?
Was für eine Fernbedienung ist das? Normalerweise erkennt IRMP
Frame-Wiederholungen, die aufgrund eines längeren Tastendrucks entstehen
und setzt dann das entsprechende Bit IRMP_FLAG_REPETITION in der
flags-Variablen der IRMP_DATA-Struct.
Ich weiss jetzt nicht, ob Hugo das Flag gegenprüft, also alle Frames mit
gesetztem Bit IRMP_FLAG_REPETITION unterdrückt und damit dann die Tasten
"entprellt". Wenn nicht, sollte man wie im IRMP-Artikel
http://www.mikrocontroller.net/articles/IRMP
(nach IRMP_FLAG_REPETITION suchen)
angegeben vorgehen.
Gruß,
Frank
Ja, die 1.0.0.4 AVR Version hat einen Fehler mit der Entprellung!
Hab's selber erst später gemerkt, da durch die Tastenunterdrückung (Key
Suppression) mir das nicht aufgefallen ist. ;)
Aber heute ist ein guter Tag! Ist sich genau mit einer neuen
Irmp-Version ausgegangen!
>> Update 1.0.0.5 (28.04.2010)
1
28.04.2010:
2
DLL: v1.0.0.5, Added possibility to flash or update the device firmware direct with the USB IR Remote Receiver settings/option dialog.
3
AVR: Bugfix code repeats
4
Updated Irmp to 28.04.2010
5
Added modified booloadHID to be able to flash the device without setting a jumper or needed disconnect/reconnect of the device
6
The booloadHID will boot if:
7
+ no USB IR Remote Receiver firmware is flashed
8
+ jumper is set
9
+ the firmware itself is reseting the device for bootloader modus
Mit dem modifizierten Bootloader kann nun einfach einen neue Firmware
runter gespielt werden ohne den Jumper setzen zu müssen oder das Device
aus/ein zu stecken.
Da es hier im Forum wirklich nicht schön ist Software-Revisionen
unterzubringen habe ich nun das Projekt in den Artikeln angelegt:
USB IR Remote Receiver
Bei Fragen, Wünschen oder sonstiges bitte einfach weiter hier rein
schreiben!
Hi gute Idee mit dem Eintrag! Ist jetzt alles schön übersichtlich. Also
ich habe deinen neuen Code gerade nochmal getestet und es funktioniert
jetzt alles wunderbar. auch Play/Pause wo er vorher immer durcheinander
gekommen ist. Lässt sich nun alles sehr komfortabel steuern. Danke für
deine tolle Arbeit!!!
Gruß, Hendi
Schön zu hören ;)
Wollte den Artikel schon früher einstellen, hatte aber bis jetzt nicht
die Motivation dazu da es ganz schön viel Arbeit ist.
Naja, die größte Arbeit ist nun geschafft!
Hugo Portisch schrieb:> Da es hier im Forum wirklich nicht schön ist Software-Revisionen
so?
- du kannst eine datei im wiki hochladen, musst sie aber nicht mal
einstellen. man kann auch direkt darauf verlinken.
- es gibt einen svn-server, der einen direkten zu einem tarball aus
deinem projekt bereitstellt.
Hugo Portisch schrieb:> Da es hier im Forum wirklich nicht schön ist Software-Revisionen> unterzubringen habe ich nun das Projekt in den Artikeln angelegt:>> USB IR Remote Receiver
Sehr schön, ich hsbe nun im IRMP-Artikel direkt mal einen Link darauf
eingefügt :-)
Michael M. schrieb:> - du kannst eine datei im wiki hochladen, musst sie aber nicht mal> einstellen. man kann auch direkt darauf verlinken.> - es gibt einen svn-server, der einen direkten zu einem tarball aus> deinem projekt bereitstellt.
Ja, das kann man natürlich so machen.
Ein eigener Artikel hat aber einen unschlagbaren Vorteil: er bietet
sämtliche notwendigen Infos in kompakter Form an. Ich denke da nur an
den Thread http://www.mikrocontroller.net/topic/156661#new, der ohne
eigenen (begleitenden) Artikel im Chaos versinken würde.
SVN ist eigentlich primär dafür gedacht, mit mehreren Leuten
"konkurrierend" an ein und demselben Quellcode zu arbeiten. Zur
Präsentation von Informationen ist SVN eher weniger geeignet. Daher hat
so ein eigener Artikel durchaus seine Berechtigung.
Gruß,
Frank
Frank M. schrieb:> Ein eigener Artikel hat aber einen unschlagbaren Vorteil: er bietet
ja!
> SVN ist eigentlich primär dafür gedacht, mit mehreren Leuten> "konkurrierend" an ein und demselben Quellcode zu arbeiten. Zur
und ja!
> Präsentation von Informationen ist SVN eher weniger geeignet. Daher hat> so ein eigener Artikel durchaus seine Berechtigung.
ich hab auch nie gegen den artikel gewettert. mein wettern galt nur der
aussage, man können hier keinen code vernünftig preisgeben.
das projekt an sich finde sehr gelungen.
Super Projekt!
Aber...
>Wenn eine neue Irmp Version kompiliert wird sollte das Build Datum von Irmp>in der main.c geändert werden:>//enter here the Irmp build date:>const char IrmpVersion[] = "28.04.2010";
Ich meine das geht auch per _DATE_ also ein vordef. DEFINE...
>> Ich meine das geht auch per DATE also ein vordef. DEFINE...
Hatten wir schon mal, ist nicht der Build Date vom Projekt sondern das
Release Datum von Irmp!
Dewegen muss dieses manuell eingegeben werden.
Eventghost....
Es ist anscheinend auch Möglich DLLs zu laden und CallBacks (Empfang von
IR-Codes) auszuwerten. Somit braucht man nicht direkt mit dem HID-Gerät
arbeiten.
Jedoch ist das Plugin dann in Python zu programmieren, da habe ich
leider Überhaupt keine Idee wie man das Umsetzt.
Vielleicht kann das ja jemand hier aus dem FF - ich kann und werde auf
jeden Fall Hilfe dazu geben wie man mit der DLL umgeht!
Hugo Portisch schrieb:> Es ist anscheinend auch Möglich DLLs zu laden und CallBacks (Empfang von> IR-Codes) auszuwerten. Somit braucht man nicht direkt mit dem HID-Gerät> arbeiten.
Und was ist mit dem HID Plugin, vlt ist ja schon alles da? Ich denk dein
Teil ist ein HID Gerät?
Also EventGhost->HID-Plugin hinzu(schon dabei)->deine Hardware
Werde mir das mit Eventghost noch genauer ansehen.
Bin mir nicht sicher wie das mit dem HID-Plugin genau gehen soll und ob
es besser ist geich über die DLL zu gehen.
So,
habe jetzt einmal was für EventGhost fertig.
Die Datei einfach im EventGhost\Plugins\USBIRRemoteReceiver entpacken.
Die DLL muss sich dann auch in diesem Ordner befinden.
Jedoch habe ich EventGhost selber noch nie benützt und kann deswegen
nicht sagen ob das Plugin schon so fertig ist.
(kleiner Tipp: beim ersten Laden des Plugins kann man den
Settings/option Dialog nicht öffnen! Zuerst zumachen und dann nocheinmal
auf Configure gehen)
Mal sehen wie's geht!
Habe heute ein kleines Update im Artikel
09.05.2010: USB IR Remote Receiver
vorgenommen!
Neu ist ein Plugin für EventGhost,
DLL v1.0.0.6, kleiner Bugfis mit Standby,
Docu Update
Hi wollte hier mal ein paar Bilder von meinem aktuellsten Empfänger
reinstellen. Denke damit kann sich jeder gut vorstellen, wie so ein
fertiger Empfänger aussehen könnte. Die Platine ist wie ihr seht
doppelseitig aber hat noch ein paar kleinere Mängel^^. Werde versuchen,
diese zu beheben und die Größe noch weiter zu drücken.(Die erste Version
war ungefähr 4 mal so groß aber es ist immer noch Potential vorhanden
:D)
Gruß, Hendi
Hallo!
Ich hab da mal ne Frage betreffend der Power ON/OFF Funktion durch den
Opptokoppler. Wie soll das Gerät den PC einschalten, wenn der PC
heruntergefahren ist. Die Schaltung hat doch garkeine Spannung um zu
funktionieren. Oder übersehe ich da etwas ?
mfg,
Bjoern
Tishima schrieb:> Die Schaltung hat doch garkeine Spannung um zu> funktionieren. Oder übersehe ich da etwas ?
Kommt drauf an wie sie versorgt wird. Viele Mainboards bieten die
Möglichkeit auch im ausgeschalteten Zustand (eine oder mehrere)
USB-Buchsen mit Spannung zu versorgen.
Micha schrieb:> Kommt drauf an wie sie versorgt wird. Viele Mainboards bieten die> Möglichkeit auch im ausgeschalteten Zustand (eine oder mehrere)> USB-Buchsen mit Spannung zu versorgen.>
Ah, Danke für die Info wusste ich noch garnicht, mir ist so ein
Mainboard noch nicht untergekommen.
gruß,
Bjoern
Hi,
hab gerade den Empfänger auf dem Steckbrett aufgebaut - was soll ich
sagen? "Works like a charm!"
Was mir zur Hardware eingefallen ist: Wie wäre es, die Firmware auf den
Attiny85 zu portieren? Die Pins würden ausreichen und der Quarz
wegfallen. Ich würde schon fast behaupten, das Teil auf 2cm²
Platinengröße zu bringen.
Als Empfängerbaustein dürfte sich der "SFH 5110-36" von Reichelt
anbieten, der doch einiges kleiner als die TSOP ist und bei der
Empfindlichkeit mithalten dürfte.
Einziger Knackpunkt (nach dem Überfliegen des Quelltextes): der nicht
vorhandene 16-Bit-Timer.
Noch eine kleine Frage an Hugo: Gibt es zur DLL auch einen Quelltext?
Wäre auf jeden Fall interessant :)
Viele Grüße
Chris
Chris R. schrieb:> Was mir zur Hardware eingefallen ist: Wie wäre es, die Firmware auf den> Attiny85 zu portieren? Die Pins würden ausreichen und der Quarz> wegfallen. Ich würde schon fast behaupten, das Teil auf 2cm²> Platinengröße zu bringen.
Müsste gehen.
> Einziger Knackpunkt (nach dem Überfliegen des Quelltextes): der nicht> vorhandene 16-Bit-Timer.
Nicht schlimm, dann nimmst Du halt einen 8-Bit-Timer. Wichtig ist
lediglich, dass F_INTERRUPTS exakt ist und einen Wert möglichst zwischen
10000 und 15000 hat.
Gruß,
Frank
Muss mich korrigieren, nach Studium von
http://www.obdev.at/products/vusb/index-de.html
klappts nicht mit dem ATTiny85, jedenfalls nicht ohne Quarz.
Zitat:
"Can be clocked with 12 Mhz, 15 MHz, 16 MHz or 20 MHz crystal or from a
12.8 MHz or 16.5 MHz internal RC oscillator."
Da der interne Oszillator vom ATTiny85 nur max. 8MHz liefert, ist der
Quarz zwingend erforderlich.
Gruß,
Frank
> Ah, Danke für die Info wusste ich noch garnicht, mir ist so ein> Mainboard noch nicht untergekommen.
Das nennt man dann 5VSB. Das bedeutet das 5V auch im ausgeschalteten
Zustand mit kleiner Anschlussleistung (0,5-2W) zur Verfügung stehen.
Neue Mainbaords & ATX Netzteile haben das eigentlich von Haus aus
drinnen. Früher musste, falls vorhanden, eventuell ein Jumper gesetzt
werden.
> "Can be clocked with 12 Mhz, 15 MHz, 16 MHz or 20 MHz crystal or from a> 12.8 MHz or 16.5 MHz internal RC oscillator."
Ja, da wird VUSB nicht mitmachen! Hatte bei den ersten Versuchen die
Fusebits falsch gesetzt und der Atmega8 ist mit dem internen Oscillator
gelaufen. Da wurde dann beim Anstecken kein USB-Gerät erkannt.
Jedoch ist der ATiny85 schon interessant. Werd mal sehen ob ich die SOIC
Version (kostenlos) bekomme.
> Noch eine kleine Frage an Hugo: Gibt es zur DLL auch einen Quelltext?> Wäre auf jeden Fall interessant :)
Gibt's schon, aber "noch" NonPublic ;)
Aber die DLL macht eigentlich das gleiche wie die Interrupt Demo was
weiter oben zu finden ist:
Beitrag "Re: USB IR Remote Receiver (V-USB + IRMP)"
Die anderen Demos im Complete Packet zeigen wie man die DLL selber
nutzen kann. Man braucht sich dann nicht mehr um die Kommunikation
Host <-> Gerät kümmern.
Portisch
Hugo Portisch schrieb:
> Ja, da wird VUSB nicht mitmachen! Hatte bei den ersten Versuchen die> Fusebits falsch gesetzt und der Atmega8 ist mit dem internen Oscillator> gelaufen. Da wurde dann beim Anstecken kein USB-Gerät erkannt.
das ist kein Problem, es gibt eine Version von V-USB die direkt auf die
Tinyx5 zugeschnitten ist.
Mit der Taktkalibrierung per USB-Framelength braucht man sich auch über
das Einstellen der PLL keinen Kopf mehr machen.
> Gibt's schon, aber "noch" NonPublic ;)> Aber die DLL macht eigentlich das gleiche wie die Interrupt Demo was> weiter oben zu finden ist:
Danke, werde ich mir mal anschauen.
Viele Grüße
Chris
Hi,
hier mein erster Versuch, den Empfänger auf den Attiny85 zu portieren.
Leider will das Teil noch nicht so recht.
Ich weiß zwar, wo der Fehler liegt, habe aber keine Möglichkeit
gefunden, ihn zu beseitigen:
Der Timer scheint V-USB auf dem AVR so stark zu beeinflussen, dass er
nicht mehr erkannt wird.
Ob es mit der Kalibrierung zu tun hat, kann ich nicht sagen, vermute
aber eher nein, da es auch nicht funktioniert, wenn ich timer_init()
nach dem Aufruf von calibrateOscillator() (Zeile 471) aufrufe.
Ich habe auch schon versucht, den Timer erst nach einigen Durchläufen
der Endlosschleife in main() zu initialisieren, mit selbem Ergebnis.
Kommentiere ich timer_init(); aus, wird das Device am USB erfolgreich
erkannt.
Da ich anfangs vermutet habe, dass der ISR nicht stimmt, lasse ich im
Interrupt PB0 togglen, dabei kommt ein Rechteck von ca. 5,3kHz raus, was
in etwa den 10kHz Abfragerate entspricht.
Habe zusätzlich zu meinen veränderten Quellen auch einen Standard-Diff
rangehängt (Ordner diff), damit ihr meine Änderungen nachvollziehen
könnt.
Vielleicht fällt einem noch etwas ein, wie man das Teil zum fliegen
bring ;)
Viele Grüße
Chris R. schrieb:> Da ich anfangs vermutet habe, dass der ISR nicht stimmt, lasse ich im> Interrupt PB0 togglen, dabei kommt ein Rechteck von ca. 5,3kHz raus, was> in etwa den 10kHz Abfragerate entspricht.
"In etwa" hört sich so an, als ob der ATTiny mit internem Oszillator
läuft... mit Quarz sollten da schon 5,0kHz rauskommen oder?
Gruß,
Frank
Frank M. schrieb:> "In etwa" hört sich so an, als ob der ATTiny mit internem Oszillator> läuft... mit Quarz sollten da schon 5,0kHz rauskommen oder?
In etwa, weil sich der AVR anhand der USB-Framelänge kalibriert
(zumindest sollte er das). In etwa auch, weil ich bei einem Vortteiler
von 8 und dem 8-Bit Timer nicht genau auf 10kHz komme. Entweder bisschen
drunter oder drüber.
Hi, ich bins mal wieder. Da die Girder Testversion schon länger
abgelaufen ist wollte ich mal Eventghost probieren. Aber das Programm
macht mich grad wahnsinnig!! Hat jemand, der sich mit dem Proggi
auskennt schon mal den Eventghost Plugin ausprobiert?
Ich will am Anfang einfach mal, dass im Mediacenter Pause gemacht wird,
wenn ich einen bestimmten Knopf auf der FB drücke aber egal was ich
mache es geht nix ich kann kein Makro, Ereignis oder sonst noch was
konfigurieren, er zeigt kein gesendeten IR Code an oder wie läuft das
eigentlich in dem Programm? Ich finde immer nur total Oberflächliche
Anleitungen, die anscheinend vorraussetzen, das man das Programm kennt.
Ihh habe allerdings keine Ahnung davon aber das muss ja funktionieren,
schließlich wird es immer in den höchsten Tönen gelobt?!
Naja vielleicht kann ja jemand mal einen Tipp abgeben bzw. sagen,ob das
überhaupt funktioniert.
Gruß, Hendi
Also mit EventGhost funktioniert das alles einwandfrei hatte nur zuerst
Probleme mit der Benutzerkontensteuerung, die hat geblockt jetzt
funktioniert alles, wie es soll!
hallo!
ich habe ein problem mit dem remote-receiver. vorweg: ich bin kein
elektronik-profi ;-)
die schaltung habe ich schon gelötet. wenn ich den receiver per usb
anschließe, wird auch schon mal ein unbekanntes usb-gerät angezeigt. der
usb standard scheint also schon mal zu stimmen.
nun habe ich versucht den receiver per ponyprog2000 zu programmieren.
ich habe die anleitung von portisch schritt für schritt befolgt. beim
auslesen der fuse-bits schon das erste prob: anfangs hat er immer
"missing device" gemeldet; nach ein paar mal "retry" hat er aber die
bits ausgelesen. ich habe die bits richtig gesetzt und dann "write"
geklickt. das hat dann auch funktioniert. jedenfalls kam keine
fehlermeldung.
danach habe ich auf "write all" für das programm geklickt. anfangs ging
es wieder nicht, aber nach ein paar mal "retry" hat es funktioniert und
er hat geschrieben, verifiziert,...und dann kam "write failed".
ich habe den receiver nun schon x mal abgesteckt, den reset-pin gesetzt
usw, aber er reagiert nun nicht mehr. wenn ich bei den fuse-bits auf
"read" klicke, kommt immer "missing device".
was könnte da nicht stimmen? wäre für ein paar tipps wirklich sehr
dankbar!
habe alles nach der liste von portisch gebaut. IC ist also ein atmega8.
zickzack schrieb:> was könnte da nicht stimmen? wäre für ein paar tipps wirklich sehr> dankbar!
Den Fehler in PonyProg suchen.
"Calibration" durchgeführt ?
pk
hi,
ja, calibration habe ich durchgeführt. eben genau die anleitung von
portisch befolgt.
den lpt-port hatte ich beim ersten versuch auf SPP. dann habe ich auf
EPP+ECP umgestellt, jedoch hat es deswegen auch nicht funktioniert.
zickzack schrieb:> den lpt-port hatte ich beim ersten versuch auf SPP. dann habe ich auf> EPP+ECP umgestellt, jedoch hat es deswegen auch nicht funktioniert.
Ich nutze PonyProg mit dem seriellen Interface.
War für mich schneller und einfacher zu bauen.
ParPort mag ich nicht.
pk
Hallo Leute, ich kann nur sagen: Tolles Projekt!
Ich hab mal alles fix zusammen gebaut und was soll ich sagen, es hat auf
Anhieb funktioniert. Ich bin über die Suche nach einer Möglichkeit eine
FDC-3402 Tastatur unter WIN und Linux zu betreiben, auf dieses schöne
Projekt gestoßen. Leider habe ich zu meinen Lötkolben ein besseres
Verhältnis, als zur AVR Programmierung. Kann mir jemmand einen Tipp
geben, was ich machen müsste, damit der IRMP Empfänger sich wie eine
ordinäre Tastatur unter Windows bzw. Linux verhält?
Vielen Dank.
Zur Tasttaur Simulation muss man beim USB IR Remote Receiver eine
Hostsoftware verwenden. Z.B. Girder.
Da kann man einstellen welcher empfangene IR-Code z.B. ein 'a' oder 'b'
ist.
Oder man macht sich eine eigene kleine Software mit der man die Codes in
Tastendrücke umsetzt.
Hugo Portisch schrieb:> Oder man macht sich eine eigene kleine Software mit der man die Codes in> Tastendrücke umsetzt.
Das ist halt meine Schwäche ;-)
Mit der Tastatur Simulation ist mir schon klar, ich habe auch schon mit
EventGhost die Sache halbwegs unter Windows zum laufen bekommen. Aber
wie ich das Ganze unter Linux zum Laufen kriege, da bin ich noch
ziemlich planlos, zumal der USB IR Remote Receiver nicht von lirc
erkannt wird und es auch noch ohne X, in der Konsole funktionieren soll.
In meinem unwissenden Leichtsinn dachte ich, dass es kein größeres
Problem seien sollte, die AVR Firmware so zu kompilieren, das sich der
AVR als HID Keyboard beim Betriebssystem anmeldet und dann die
entsprechenden Keycodes für eine USB Tastatur sendet.
Hi,
sorry for using english, I don't know any German. I am the winlirc
developer. The winlirc plugin design is really flexible, so you can do
really what you want internally. The only thing you must do is spit out
the name of the button on the remote when a button is pressed, how you
get there doesn't really matter. It looks like you guys have spent a
great deal of effort writing your own decoder for many remotes ? If you
can supply the raw pulse/space lengths we can easily decode all
protocols with winlirc :)
Hi Ian,
it's nice to hear that you are interrested. You are invited to take a
look at this Project, it's cheap to build and work very well. The output
of the USB IR Remote Receiver is a with IRMP decoded IR Protocol
Information
(not a Pulse or. Space lengths).
Perhaps can you support the USB IR Remote Receiver in your lirc Software
in the Future? (I hope it) Sorry for my bad english. ;-)
@Ian
I was already taking a look to Winlirc. But I was thinking it support
only RS232 IR receiver.
USB IR Remote Receiver is an USB-HID Device.
So no virtual COM Port or something else is used.
Also I didn't found anything how to write plugins for Winlirc.
Would be nice if the receiver can be supported by Winlirc.
The included DLL already support NATIVE, DVBViewer, Girder, EventGhost.
I can include also Winlirc support in the DLL if I know how to...
Take a look to the included demos how to use this receiver.
The receiver will send the native IRMP data to the host:
irmp_data_p->protocol
irmp_data_p->address
irmp_data_p->command
irmp_data_p->flags
The handling of the command(s) is done by the host.
Kann mir jemand verraten welche Fusebits im AVRStudio setzen muss. Am
bestens wäre ein Screenshot. Ich denke das macht schon Sinn, da das
Projekt mit dem AVR-Studio umgesetzt ist. Danke für eure Hilfe.
Hallo,
feine Sache dieser IR Decoder, aber hat es denn nun schon mal jemand
unter Linux "nativ" ( ohne Tools im wine o.ä. ) zum laufen bekommen oder
gibt's vielleicht schon eine lirc Unterstüzung?
Hi,
gibt es vielleich schon eine Quelle, wo alles diesbezüglich
zusammengefasst ist? Ich würde es auch gerne nachbauen, habe aber leider
keine Zeit ein eigenes Layout zu entwerfen. Ich bin bislang immer ganz
gut mit dem IgorPlug gefahren, aber seit win7(64bit) kann ich diesen
nicht mehr verwenden. Wäre also super nett, wenn mir Jemand eine
Zusammenfassung schreiben kann, wie weit die Entwicklung dieses tollen
Adapters ist und ob dieser mit Girder unter win7(64bit) funktioniert.
Wenn ja dann wäre ich auch dankbar für jegliche Layouts mit Stücklisten
(egal wie viele Layer die Platine hat und wie klein die SMD-Bauteile
sind, ich kann alles verbauen, selbst tqfc Gehäuse. Habe auf der Arbeit
eine Durchlichteinheit)
Würde mich dafür auch erkenntlich zeigen und euch einige Platinen zum
Selbstkostenpreis mitbestücken.
Danke!
Hi, also es gibt sowei ich weiß auch einen Artikel, wo alles drin steht.
Außerdem istr in dem zip Archiv eine Anleitung enthalten. Funktionieren
tut das ganze wirklich einwandfrei, ich benuttze es mitlerweile mit
EventGhost, da dieses Programm kostenlos ist. Mit der Testversion von
Girder hat aber auch alles sehr gut funktioniert. SMD Layouts habe ich
mittleriwel über 3 versheidene.
1. Sehr großzügig geroutet, mit richtiger ISP Buchse Maße ca 4x4cm
dinseitig
2. so groß, wie ein USB Stick, noch recht viele Vias, Programmierung
über Platine möglich aber nicht mit ISp Adapter, doppelseitig, mit THT
IR Empfänger
3 neuestes Layout, aber bisher noch nicht getestet, da Bauteile fehlen,
sehr weinge Vias trotz übersichtlichem Layout, doppelseitig, noch
kliner/kürzer als variante 2, mit SMD IR Empfänger
Frohe Weihnachten, Hendi
Chris R. schrieb:> Autor:>> Chris R.> (hownottobeseen)
Hi Chris,
I finded the resolution to your problem. You must use these code:
void usbEventResetReady(void) {
cli(); // usbMeasureFrameLength() counts CPU cycles, so disable
interrupts.
calibrateOscillator();
sei();
I recommend check the code on this place:
else if ( DoWriteReport == SetIRPollingTime ) {
OCR1A = (F_CPU PRESCALER ((data[2] << 8 ) | data[1])) - 1;
You used Timer 0 and here is OCR1A, you should use the PRESCALER here
maybe.
P.
Hallo!
Ich hab mit viel Interesse den Großteil des Beitrages und Wikis gelesen.
Nun hätte ich noch ein paar Fragen:
- Muss zu dem Empfänger zwingend Sichtkontakt bestehen oder kann ich ihn
einfach hinter den Rechner legen / ihn aus einer Lüfteröffnung "gucken"
lassen? (danach richtet sich dann ja auch ob ich es an einen internen
oder externen USB Anschluss klemme)
- Ist der Jumper für das erstmalige Bespielen mit PonyProg2000 notwendig
oder kann man ihn mit der "neuen" bootloadHID komplett weglassen?
- Wie ich gelesen hab, reicht der Flashspeicher des Atmega8 nicht mehr
für die komplette Unterstützung von Irmp. Gibt es eine Alternative, die
von der Schaltung genauso verbaut wird und wo das gesamte Irmp in den
Flashspeicher passt?
- Ich hab keine anderen Möglichkeiten als die Schaltung auf einer
Lochrasterplatine zusammenzubauen, hat jemand für diesen Fall ein klein
bauenendes Layout was er zur verfügung stellen würde (mit PowerON)? Auf
welche Abmaße kommt man auf einer Lochrasterplatine ca.? Ich würde gern
gleich bei Reichelt noch ein kleines passendes Kunsstoffgehäuse o.ä.
mitbestellen.
Ich würde mich über Anregungen freuen!
Willi
Hallo!
Das Projekt klingt wirklich interessant. Hatte mir grade einen
Igor-USB-IR-Empfänger gebastelt - um dann festzustellen, dass dieser mit
meinem Win7 x64 nur über Umwege funktioniert.
Hat jmd schon irgendwo ein Layout bereitgestellt, dass ich nachbauen
könnte?
Auf der Projektseite selbst sieht man nur ein Foto einer fertigen
Lochraster-Platine.
Ich wär auch dran interessiert, wenn jmd einige Platinen ätzen möchte :)
Außerdem wollte ich fragen ob man bei dem Design noch ne LED einbauen
könnte, die den Empfang von Infrarotsignalen bestätigt (blinkt) -
zumindest hatte meine jetzige Version (Igor) diese Funktion
Gruß
Mock
Habe Heute einmal ein Update des Artikels gemacht!
USB IR Remote Receiver> - Muss zu dem Empfänger zwingend Sichtkontakt bestehen oder kann ich ihn> einfach hinter den Rechner legen / ihn aus einer Lüfteröffnung "gucken"> lassen? (danach richtet sich dann ja auch ob ich es an einen internen> oder externen USB Anschluss klemme)
IR braucht Sichtkontakt. Ist ja Licht - und nicht Funk!
Es kann sein, dass es hinten auch geht. Vielleicht ein kleiner Spiegel
dahinter um das IR Licht umzulenken!?
> - Ist der Jumper für das erstmalige Bespielen mit PonyProg2000 notwendig> oder kann man ihn mit der "neuen" bootloadHID komplett weglassen?
Mit dem "neuen" Bootloader kann man ihn komplett weglassen! Man
programiert nur den Bootloader mit PonyProg2000 auf den AVR.
Die eigentlich Anwendung wird dann über die Flash-Option draufgespielt.
> - Wie ich gelesen hab, reicht der Flashspeicher des Atmega8 nicht mehr> für die komplette Unterstützung von Irmp. Gibt es eine Alternative, die> von der Schaltung genauso verbaut wird und wo das gesamte Irmp in den> Flashspeicher passt?
Vielleicht ein Atmega16!? Der hat 16KB Speicher. Oder ein Atmega32 mit
32KB Speicher. Alle Protokolle wird man aber nie brauchen, deswegen
sollte der Atmega8 ausreichen.
> - Ich hab keine anderen Möglichkeiten als die Schaltung auf einer> Lochrasterplatine zusammenzubauen, hat jemand für diesen Fall ein klein> bauenendes Layout was er zur verfügung stellen würde (mit PowerON)? Auf> welche Abmaße kommt man auf einer Lochrasterplatine ca.? Ich würde gern> gleich bei Reichelt noch ein kleines passendes Kunsstoffgehäuse o.ä.> mitbestellen.
Es ist beim Beitrag ein Foto von einem Lochrasteraufbau dabei. Ich habe
es auch einfach nach Schaltplan aufgebaut.
> Hat jmd schon irgendwo ein Layout bereitgestellt, dass ich nachbauen> könnte?> Auf der Projektseite selbst sieht man nur ein Foto einer fertigen> Lochraster-Platine.> Ich wär auch dran interessiert, wenn jmd einige Platinen ätzen möchte :)> Außerdem wollte ich fragen ob man bei dem Design noch ne LED einbauen> könnte, die den Empfang von Infrarotsignalen bestätigt (blinkt) -> zumindest hatte meine jetzige Version (Igor) diese Funktion
Ich selber habe kein Layout erstellt. Vielleicht später noch einmal.
kommt drauf an ob wir hier einen PCB-Protoyper bekommen...
Für die Led-Anzeige müsste es reichen wenn du die Kathode der Led an dem
IR Dioden Ausgang hängst. Die Led Anode über einen Widerstand (~560-1000
Ohm) auf +5V hängen. Den Widerstand halt nicht zu gering auswählen
ansonsten kann es zu Problemen der Stromversorgung über den USB-Port im
Ruhezustand/Standby kommen.
Hallo und Danke für das Klasse Projekt.
Aufgebaut, geflasht , funktioniert ....
Leider nur unter Windows :-(
Ich würde das Teil gern unter Linux einsetzten da ich bis jetzt mit
(fast) allen anderen Varianten mehr oder weniger gescheitert bin.
(es funktioniert nur ein UIRT2 über einen USBtoSerial-Wandler, aller
andere mit MCE oder imon nur teilweise)
Jetzt dachte ich das Teil hier wäre DIE Lösung. Leider auch noch nicht.
Beim einstecken kommt das im Log :
1
Jan 30 11:18:31 ion kernel: [ 1735.172036] usb 4-1: new low speed USB device using uhci_hcd and address 12
2
Jan 30 11:18:31 ion kernel: [ 1735.356189] usb 4-1: configuration #1 chosen from 1 choice
3
Jan 30 11:18:31 ion kernel: [ 1735.411161] generic-usb 0003:16C0:05DF.000A: hiddev96,hidraw0: USB HID v1.01 Device [www.dvbviewer.info USB IR Remote Receiver] on usb-0000:00:1d.2-1/input0
Unter /proc/bus/input/devices wird leider kein neuer Eintrag erzeugt.
Aber es erscheint ein :
Doch wie kann ich das nutzen ?
Mit inputlircd scheint es nicht zu gehen.
Hat jemand eine Idee wie ich das unter Linux benutzen kann ?
Vielen Dank Ronald
Hi!
Ich habe mich mal rangesetzt und die Schaltung Rasterplatinen-kompatibel
aufgezeichnet. Ist die so korrekt? Hatte noch keine Gelegenheit die
nachzubauen. Alle Leitungen sind auf der Unterseite der Platine wobei
die roten isolierte Kabel sein sollten, da sie die dunkelblauen sonst
kreuzen. Die Widerstände R2-R4 dienen gleichzeitig als Brücken.
Ich hoffe der Plan kann einigen weiterhelfen
Hoppla... da hab ich doch glatt die Pins des TSOP vertauscht :)
Für meine Zwecke verbaue ich die die IR Diode auf der Unterseite und
klappe sie um, so dass sie von der Platine weg zeigt. Alternativ kann
man ja auch Pins hinlöten und die IR Diode über ein Kabel verbinden.
Habe gleich eine korrigierte version geuploadet
ich schrieb:> Ob die 16k reichen weiß ich allerdings nicht.
Zur Not gibt es auch noch den ATmega328 mit 32K.
Ist alles pinkompatibel, da eine Familie. Aber ich glaube, dass Du mit
den 16K dicke auskommst :-)
Gruß,
Frank
@Ronald
ja, der Receiver ist ein USB HID Device. Deswegen braucht man auch keine
Treiber ;)
Ich kann dir für Linux leider nicht helfen, aber vielleicht findet sich
ja was per Google wie man in Linux mit einem HID Device spricht.
Ich bin mir jetzt nicht sicher ob die HID Kommunikation mit dem Device
im Source enthalten ist. Ich glaub da ist nur mehr der Source wie man
mit der DLL umgeht dabei. die geht unter Linux natürlich nicht.
Ansonsten melde dich bei mir, ich kann dir dann den Source für Windows
zumindest geben. Dann kann man sich die HID Handhabung für Linux
abschauen.
Sollte was daraus werden würde ich gerne den Linux source mit in das
Projekt aufnehmen!
Danke für die Antworten!
> Willi schrieb:>> Gibt es eine Alternative, die von der Schaltung genauso verbaut wird und>> wo das gesamte Irmp in den Flashspeicher passt?> Mega168 ist pinkompatibel. Nötige SW-Anpassungen siehe:> http://www.atmel.com/dyn/resources/prod_documents/...> http://www.atmel.com/dyn/resources/prod_documents/...
Ohje, davon hab ich ja mal garkeinen Ahnung :( Ich hab ja gelesen, dass
die sogenannten fuse-bits geändert werden müssen (was das auch immer ist
;) )
Sind sonst noch Anpassungen in dem Programmcode/Plugin nötig oder "nur"
der bootloader (wo mir vielleicht jemand helfen könnte!?)
Wenn nicht nehm ich halt den direkt unterstützten Atmega8!
Also ich habe hier einen Atmega168 und einen Atmega168p rumliegen.
Die Firmware selber habe ich schon zum laufen gebracht.
Jedoch geht der Bootloader nicht. Habe die Address auf 0x3800 geändert
aber es wird kein USB Device erkannt.
Mit dem Fuse Calc:
http://www.engbedded.com/fusecalc/
Hätte ich diese eingestellt:
Low 0xDF
high 0xD5
Ext 0xF8
Jedoch läuft es nicht. Hatt jemand einen Tipp?
Hugo Portisch schrieb:> Jedoch geht der Bootloader nicht. Habe die Address auf 0x3800 geändert> aber es wird kein USB Device erkannt.
0x3800 (in Bytes, 0x1C00 in Worten) wäre korrekt.
> Hätte ich diese eingestellt:> Low 0xDF> high 0xD5> Ext 0xF8
Der µC läuft doch mit 5V, oder? Dann hätte ich folgendes genommen:
Low 0xFF
high 0xD4
Ext 0xF8
Die Unterschiede sind marginal: Längere Anlaufzeit für den Quartz und
Brown-Out-Level auf 4,3 statt 2,7 Volt.
Gruß,
Frank
> 0x3800 (in Bytes, 0x1C00 in Worten) wäre korrekt.
Ja klar, Word = 2 Bytes.
Beim Atmega8 0xC00 Words -> 0x1800 in Bytes.
Ich habe im Forum von www.obdev.at auch andere gefunden, die auch das
Problem hatten, dass es auf den Atmega168 nicht geht.
die Modifizierte Version schreibt ja ein Byte in das EEPROM und dieses
wird auch geschrieben. Jedoch geht V-USB trotzdem nicht.
D.H. der Bootloader startet zwar, aber irgendwas anderes stimmt hier
nicht.
Auch mit der originale Version vom Release 2010-07-29 bekomme ich V-USB
nicht zum Laufen.
Ok, habe jetzt den originalen bootloader doch zum laufen gebracht. Der
brauchte ja den Jumper ... ;)
Jedoch beim Atmega168p:
> Device: atmega168p>> Program: 2078 bytes (12.7% Full)> (.text + .data + .bootloader)>> Data: 60 bytes (5.9% Full)> (.data + .bss + .noinit)
Das geht sich nicht in den bootloader aus. Mal sehen ob man hier was
kürzen kann.
Hugo Portisch schrieb:> Jedoch beim Atmega168p:>> Device: atmega168p>>>> Program: 2078 bytes (12.7% Full)>> (.text + .data + .bootloader)>>>> Data: 60 bytes (5.9% Full)>> (.data + .bss + .noinit)
Wie sieht das beim ATmega168 ohne P aus? Generiert der Compiler
tatsächlich so viel anderen Code für den 168P?
> Das geht sich nicht in den bootloader aus. Mal sehen ob man hier was> kürzen kann.
Wo kann man sich den Bootloader anschauen? Mittlerweile kenne ich da ein
paar Tricks, wie man hier und da ein paar Bytes einsparen kann.
Gruß,
Frank
Es lag an dem "p". V-USB hat ein Update gebraucht.
Das Speicherproblem habe ich auch in den Griff bekommen indem ich nun
statt eeprom_write_block ein eeprom_write_byte verwende. as hat mir ~100
Bytes verschafft.
Ich habe nun den Artikel USB IR Remote Receiver erneuert.
Im Download ist nun auch der Source für dem Atmega168p mit dabei.
Also neuer bootLoader (für beide Microcontroller) und neuer USB IR
Remote Receiver.
Die 16kB reichen wirklich bei Weitem! Das Project braucht ~8300 Bytes.
> Wo kann man sich den Bootloader anschauen?
Naja, nicht richtig anschauen ;)
Im Bootloader wurde nur Automatisch ein eeprom_write durchgeführt und im
Programmer habe ich dann die Warnung erhalten, dass das EEPROM nicht
leer ist. Somit musste der Bootloader angelaufen sein.
Hallo,
ich bin auf der Suche nach einer Anbindung für meine Logitech Harmony an
den HTPC (XBMC) und dabei auf dieses Projekt gestoßen.
Gibt es die Möglichkeit die auf MCE-Einsatz eingestellte Harmony über
den IR Empfänger anzubinden? Wenn der Atmega auf RC6 programmiert ist,
würde das dann direkt erkannt werden?
freundliche Grüße
Christian
Der Empfänger kann die Harmony sicher empfangen.
Ich habe meine Universal Fernbedienung z.b. auf ein Humax PVR
eingestellt (NEC-Protokol).
Jedoch weis ich nicht wie die Auswertung der Daten erfolgen soll.
Unterstützt XBMC Inputplugins? Dann könnte ich den Support in der DLL
hinzufügen.
Ansonsten kann man es über EventGhost oder Girder auswerten und die
IR-Befehle in Tastendrücke umwandeln.
Hallo,
danke für die schnelle Antwort!
Ich habe mich ein wenig eingelesen und es gibt im Internet Lösungen das
Programm XBMC über Girder oder Eventghost zu steuern.
Dann ist ja eigentlich alles bestens :-D
Die Logitech Harmony unterstützt sehr viele Codes. Ich kann ich mir dann
einen zum flashen auswählen.
Ich werde mich auf die Suche nach den Bauteilen machen.
Schwierig ist scheinbar die Fotodiode TSOP 17**. Meinst Du ich kann
dafür auch die Osram SFH 5110 einsetzen? Die Betriebsspannung und der
Betriebsstrom sind laut Datenblatt recht nah beieinander.
In welcher Bauform benötige ich die Kondensatoren?
Die im Foto verbauten sehen aus wie Tantal-Kondensatoren?
Christian schrieb:> Schwierig ist scheinbar die Fotodiode TSOP 17**. Meinst Du ich kann> dafür auch die Osram SFH 5110 einsetzen? Die Betriebsspannung und der> Betriebsstrom sind laut Datenblatt recht nah beieinander.
Ja, geht. Beachte aber die inkompatible Pinbelegung.
Gruß,
Frank
Hugo Portisch schrieb:> Im Download ist nun auch der Source für dem Atmega168p mit dabei.
Funktioniert das beiliegende hex-file auch mit nem Mega168 ohne P?
> Funktioniert das beiliegende hex-file auch mit nem Mega168 ohne P?
Also ich habe den Source (bootloadHID und USB IR Receiver) gerade für
den Atmega168 neu kompiliert.
Es kommt das gleiche Hex File wie beim "p" raus.
Sollte also gehen...
Hugo Portisch schrieb:> Also ich habe den Source (bootloadHID und USB IR Receiver) gerade für> den Atmega168 neu kompiliert.> Es kommt das gleiche Hex File wie beim "p" raus.> Sollte also gehen...
Danke. Werde ich demnächst testen.
Hugo Portisch schrieb:> Zur DLL überlege ich auch noch folgendes:> derzeit habe ich schon eine DLL die mit DVBViewer als Input-Plugin> läuft. Diese werde ich hernehmen und extra Funktionen exportieren, damit> diese auch für andere Programme verwendet werden kann.
Gibt es deinerseits Bestrebungen das für MediaPortal zu realisieren?
> Gibt es deinerseits Bestrebungen das für MediaPortal zu realisieren?
Eigentlich schon, aber ich finde kein Source Beispiel wie das in
Mediaportal funktioniert!
Hugo Portisch schrieb:> Eigentlich schon, aber ich finde kein Source Beispiel wie das in> Mediaportal funktioniert!
Irgendwo in "RemotePlugins" gibt es vermutlich was worauf man aufbauen
könnte, aber beschäftigt habe ich mich damit noch nicht.
Danke,
habe aber hier trozdem keinen durchblick wie das in Mediaportal
funktioniert. Wohin und wie werden die Empfangenen IR Daten an
Mediaportal gesendet? Wo wird das Mapping der IR Codes auf Mediaportal
Funktionen gemacht? Kann man die wie bei Girder für jeden IR-Code
anlernen?
Mal sehen ob ich noch mehr finde.
Hugo Portisch schrieb:> Wohin und wie werden die Empfangenen IR Daten an Mediaportal gesendet? Wo> wird das Mapping der IR Codes auf Mediaportal Funktionen gemacht?
Leider kenne ich mich damit nicht aus da ich ebenfalls noch nie etwas
für MePo entwickelt habe.
Hugo Portisch schrieb:> Kann man die wie bei Girder für jeden IR-Code anlernen?
Das wäre das Schönste.
Im Prinzip könnte man es so lösen, dass der USB-IRRR sich wie eine
HID-Tastatur verhält (à la
http://www.obdev.at/products/vusb/hidkeys.html) und IR-Codes als
Tastendrücke weitergibt. Das Problem ist allerdings, dass eine Tastatur
maximal ein Datenbyte verschicken darf. D.h. man dürfte nur
entsprechende IR-Codes (NEC) verwenden. Mir persönlich würde das
reichen, aber insgesamt ist das wohl zu unflexibel.
Kannst du mir auf die schnelle sagen wo ich für den Mega168 einstellen
kann an welchem Pin der Jumper angeschlossen ist? Ich habe eine etwas
andere Pinbelegung gewählt als du. Evtl. wäre das noch was für die
"configUSBIRRemoteReceiver.h".
Was hältst du von der zusätzlichen Integration von IRSND? Ich habe bei
mir das Problem, dass mein Verstärker etwas verdeckt steht und nicht
alle IR-Kommandos mitbekommt. Daher würde ich gerne die empfangenen
Kommandos 1-zu-1 "weiterleiten".
Micha schrieb:> Im Prinzip könnte man es so lösen, dass der USB-IRRR sich wie eine> HID-Tastatur verhält (à la> http://www.obdev.at/products/vusb/hidkeys.html) und IR-Codes als> Tastendrücke weitergibt. Das Problem ist allerdings, dass eine Tastatur> maximal ein Datenbyte verschicken darf. D.h. man dürfte nur> entsprechende IR-Codes (NEC) verwenden. Mir persönlich würde das> reichen, aber insgesamt ist das wohl zu unflexibel.
Da eine FB eine sehr beschränkte Anzahl von Tasten hat, reicht dieses
eine Datenbyte vollkommen aus. Man braucht lediglich eine Tabelle,
welche das empfangene Kommando (evtl. in Zusammenhang mit der Adresse)
auf ein eindeutiges Byte mappt. Das ist dann für alle von IRMP
unterstützten Protokolle möglich, nicht nur für NEC.
Gruß,
Frank
Frank M. schrieb:> Man braucht lediglich eine Tabelle, welche das empfangene Kommando (evtl.> in Zusammenhang mit der Adresse) auf ein eindeutiges Byte mappt.
... was aber nicht ganz einfach ist, vor allem wenn man mehrere
Eingangscodes erlaubt (z.B. NEC und RC5). Oder wie würdest du die
Tabelle aufbauen um nicht unnötig viel Rechenzeit und Speicher zu
verbrauchen?
Micha schrieb:> ... was aber nicht ganz einfach ist, vor allem wenn man mehrere> Eingangscodes erlaubt (z.B. NEC und RC5). Oder wie würdest du die> Tabelle aufbauen um nicht unnötig viel Rechenzeit und Speicher zu> verbrauchen?
zum Beispiel so:
1
#define MAX_REMOTE_CONTROLS 2 // 2 remote controls, e.g. RC5 + NEC
Das habe ich ins Unreine getippt, sollte aber soweit funktionieren. Die
Daten der Struct könnte man über PROGMEM noch ins Flash legen, wenn der
Speicher knapp werden sollte.
Gruß,
Frank
Frank M. schrieb:> Das habe ich ins Unreine getippt, sollte aber soweit funktionieren. Die> Daten der Struct könnte man über PROGMEM noch ins Flash legen, wenn der> Speicher knapp werden sollte.
Hmm - das sieht ziemlich gut aus. Und falls die Funktion 0xff
zurückgibt, wird der entsprechende Code mit IRSND "weitergeleitet". Das
gefällt mir! Vielen dank!
> Kannst du mir auf die schnelle sagen wo ich für den Mega168 einstellen> kann an welchem Pin der Jumper angeschlossen ist? Ich habe eine etwas> andere Pinbelegung gewählt als du. Evtl. wäre das noch was für die> "configUSBIRRemoteReceiver.h".
Der Jumper wird nur für den Originalen Bootloader gebraucht und ist im
bootloadHID Source zum einstellen.
Der veränderte bootloadHID braucht den Jumper nicht. Dieser wird gar
nicht mehr abgefragt.
Natürlich kann man die Auswertung der IR Daten und Zuordnung im AVR
definieren. Jedoch ist dann die Zuordnung fix und für jede Veränderung
muss eine neue Firmware eingespielt werden. Das passt aber nicht zum USB
IR Remote Receiver Konzept.
Der AVR sollte als einfacher Übersetzer gehandhabt werden und die
Auswertung sollte am Host gemacht werden. Den eine Tabelle im AVR passt
halt dann nur für den einen Typ von Fernbedienung. Hat man eine andere
muss auch die Tabelle im AVR angepasst werden.
Über IRSend habe ich noch nicht nachgedacht, da ich selber dies nicht in
Verwendung habe. Dazu wäre die Frage von wo IRSend gesteuert werden
soll. Vom AVR selber oder vom Host. Ich meine von wo IRSend die Befehle
erhaltet die was gesendet werden sollen.
Hugo Portisch schrieb:> Jedoch ist dann die Zuordnung fix und für jede Veränderung muss eine neue> Firmware eingespielt werden.
Naja, man könnte das Dingens ja lernfähig machen. Z.B. vom PC aus
anweisen neue Befehle zu erhalten und zu speichern. Als
Benutzeroberfläche würde im Prinzip ein Text-Editor ausreichen.
Hugo Portisch schrieb:> Dazu wäre die Frage von wo IRSend gesteuert werden soll. Vom AVR selber> oder vom Host. Ich meine von wo IRSend die Befehle erhaltet die was> gesendet werden sollen.
In meinem Fall sollte es einfach die per IRMP empfangenen Befehle 1-zu-1
mittels IRSND versenden. Sprich der AVR empfängt ein IR-Kommando und
"verschickt" es gleich wieder. Es muss halt garantiert sein, dass er
Kommandos, die er selbst verschickt hat nicht wieder empfangen kann -
eine gewisse räumliche Trennung muss also gegeben sein.
Micha schrieb:> In meinem Fall sollte es einfach die per IRMP empfangenen Befehle 1-zu-1> mittels IRSND versenden. Sprich der AVR empfängt ein IR-Kommando und> "verschickt" es gleich wieder.
Vorsicht, ein Gerät, das beide Signale empfängt (von der FB und von
IRSND), bekommt dann alles doppelt ab.
> Es muss halt garantiert sein, dass er> Kommandos, die er selbst verschickt hat nicht wieder empfangen kann -> eine gewisse räumliche Trennung muss also gegeben sein.
Siehe dazu entsprechenenden Abschnitt unter
http://www.mikrocontroller.net/articles/IRMP#Source-Code_IRSND
Zitat:
1
Möchte man IRMP und IRSND parallel verwenden (also als Sender und
2
Empfänger) schreibt man die ISR folgendermaßen:
3
4
ISR(TIMER1_COMPA_vect)
5
{
6
if (! irsnd_ISR()) // call irsnd ISR
7
{ // if not busy...
8
irmp_ISR(); // call irmp ISR
9
}
10
// call other timer interrupt routines...
11
}
12
13
Das heisst: Nur wenn irsnd_ISR() nichts zu tun hat, dann rufe die ISR des
14
Empfängers auf. Damit ist der Empfänger solange abgeschaltet, während
15
irsnd_ISR() noch Daten sendet. Die Timer-Initialisierungsroutine ist für
> Naja, man könnte das Dingens ja lernfähig machen. Z.B. vom PC aus> anweisen neue Befehle zu erhalten und zu speichern. Als> Benutzeroberfläche würde im Prinzip ein Text-Editor ausreichen.
Ok, man könnte die Empfangen IR-Daten am Host dann einen Key zuweisen (1
Byte). Dann den IR-Code mit dem Key im EEPROM ablegen. Dies würde dann 7
Bytes pro Key in Anpruch nehmen.
Zusätzlich kommt noch das, dass die HID Struktur umgebaut werden muss.
Der AVR muss sich dann als HID Tastatur ausgeben damit der Host die
Befehle als Tastendrücke ausführt. Da sehe ich das größere Problem. Ich
glaube das es da Probleme mit GetFeature/Setfeature gab als ich es als
HID-Tastatur versucht hatte. Der Erstellung des HID Reports war
eigentlich die größte Arbeit!
Derzeit:
0x0b, 0x01, 0x00, 0x00, 0xff, // USAGE (Vendor Defined Page 1:Vendor
Usage 1)
Muss dann:
0x09, 0x06, // USAGE (Keyboard)
werden. Ich werde zuerst einmal rumspielen ob der USB IR Remote Receiver
normal funktioniert, wenn er sich als Keyboard anmeldet. Wenn das nicht
geht weis ich nicht weiter!
Auch das Runterladen der Daten muss angepasst werden. Derzeit kann man
nur einen IR-Code runterladen der für die PowerON Funktion verwendet
werden soll. Dies ist Momentan auch nicht in Verwendung und wird nur zum
Löschen des PowerOn IR-Codes verwendet.
Hendrik S. schrieb:> Also ich fände ja auch eine Anbindung an MediaPortal super :)
Mir geht es auch primär darum. Am liebsten per Plugin oder eben als
Tastatur. Via Eventghost funktioniert zwar, gefällt mir aber wegen des
"Umweges" nicht und perfekt funktioniert hat es bei meinem letzten
Versuch auch nicht. Zugegebenermaßen lief das allerdings auch nicht mit
dem USB-IRRR, sondern auf einer anderen Hardware mit PIC (-> Y.A.R.D.).
Zu MediaPortal: Ich finde einfach keine Doku dazu wie das genau
funktioniert. Und hier alle Sourcen durchzustöbern habe ich Moment gar
keine Lust. Beim DVBViewer oder Girder gibt es eine schöne Doku wie mann
das macht. Ausserdem ist die DLL in Delphi geschrieben und Mediaportal
ist C#. Das macht es nicht gerade einfacher weil man hier noch weniger
bis gar kein Beispiel findet.
Micha schrieb:> Via Eventghost funktioniert zwar, gefällt mir aber wegen des> "Umweges" nicht und perfekt funktioniert hat es bei meinem letzten> Versuch auch nicht
Also ich habe das leider nicht zum laufen gebracht jedenfalls noch nicht
. Gut ich habe mich jetzt nicht intensiv damit auseinandergesetzt(erst
am wochenende)sondern nur mal kurz getestet. Habe jetzt auch mal ein
neues Layout gemacht -> ohne den Jumper und heute das mit dem Bootloader
getestet -> funktioniert astrein, bin echt beeindruckt, was hier aus dem
Projekt schon alles geworden ist.
Also die Umsetzung für den Support von MediaPortal in der DLL schaut
naja aus.
Also in der DLL glaube ich gar nicht, da sich Delphi Win32 und .NET
Assemblies einfach nicht vertragen.
Eine Lösung wäre eine extra DLL die in .NET/C# geschrieben ist um mit
Mediaportal zu funktionieren, die aber auch die nativen DLL Funktionen
der USB_IR_Remote_Receiver.dll verwendet.
Sozusagen eine Brücke MP <-> DLL.
Das könnte auf jeden Fall funktionieren.
Hugo Portisch schrieb:> Eine Lösung wäre eine extra DLL die in .NET/C# geschrieben ist um mit> Mediaportal zu funktionieren, die aber auch die nativen DLL Funktionen> der USB_IR_Remote_Receiver.dll verwendet.
Eine reine .NET-dll würde nicht funktionieren? Nutzt du egtl. irgenetwas
spezielles zur Kommunikation? libusb oder dergleichen?
Nein, aber ich habe zu wenig Erfahrung mit .NET und die DLL müsste auch
komplett neu geschrieben werden.
ich bin gerade dabei mir Sachen wie das hier anzusehen:
http://atozed.com/CrossTalk/index.de.aspx
Jedoch bekomme ich bis jetzt nur einen Absturz wenn ich die Core.dll von
Mediaportal hinzufügen will.
Hugo Portisch schrieb:> Jedoch bekomme ich bis jetzt nur einen Absturz wenn ich die Core.dll von> Mediaportal hinzufügen will.
Noch immer? Bei mir gibt es keine Probleme mit VC# 2008 EE.
Geht nicht, nein. Die Utils.dll funktioniert z.B.
Bei der Core.dll -> Absturz.
Mit VS2008 habe ich auch kein Problem die Metadaten einzulesen. Nur mit
Hydra und Crosstalk geibt es Probleme.
Ich habe eben mal ein bisschen mit dem "generic_hid_cs"-Beispiel von Jan
Axelson (http://www.lvr.com/hidpage.htm) und dem USB-IRRR gespielt.
Ergebnis anbei.
DLL_Demo.txt -> 2x eine Sequenz aus 5 Tasten mit Hugos DLL_Demo
empfangen
generic_hid_cs.PNG -> 1x dieselbe Sequenz aus 5 Tasten mit o.g.
"generic_hid_cs"-Beispiel ohne irgendwelche Anpassungen (außer VID &
PID). Bei "Bytes to Send" oben 01 eintragen und das Häkchen entfernen
oder lassen (macht erstmal keinen Unterschied). Dann auf "Once" klicken
und FB-Taste drücken.
IDE ist VC#2008EE, wie geschrieben ohne weitere Anpassungen, dlls (auch
NICHT die "USB_IR_Remote_Receiver.dll" von Hugo) oder Sonstiges...
Ich habe ehrlich gesagt sehr wenig Erfahrung mit VC# und USB aber so
schlecht sieht das nicht aus, finde ich. Kommentare sind ausdrücklich
erwünscht.
Michael K. schrieb:> Bei "Bytes to Send" oben 01 eintragen und das Häkchen entfernen oder> lassen (macht erstmal keinen Unterschied).
Das scheint das Ganze insgesamt nicht zu beeinflussen.
Die gleichen Ergebnisse lassen sich mit der "generic_hid_vb", ebenfalls
von o.g. Seite, und VB2008EE erzielen. Nur für den Fall dass jemand
Basic bevorzugt...
Hi,
ich würde halt empfehlen die DLL mit deren Funktionen zu benutzen.
Dann spart man sich das ganze HID Zeugs und man hat auch die Optionen
Oberfläche der DLL und auch das Neuflashen des AVR ist gleich mit drin.
Also einfach die DLL über die InitNative benützen.
Sonst macht man sich halt Arbeit, was eh schon gemacht ist...
Hugo Portisch schrieb:> ich würde halt empfehlen die DLL mit deren Funktionen zu benutzen.> Dann spart man sich das ganze HID Zeugs und man hat auch die Optionen> Oberfläche der DLL und auch das Neuflashen des AVR ist gleich mit drin.> Also einfach die DLL über die InitNative benützen.>> Sonst macht man sich halt Arbeit, was eh schon gemacht ist...
Klar, will ich schon so machen. Vorausgesetzt die DLL lässt sich im
Visual Studio benutzen...
Das oben habe ich rein interessehalber einfach mal versucht. Das
Ergebnis wäre ja auch noch stark verbesserungswürdig, stimmt aber nicht
unbedingt negativ.
Die DLL Funktionen sollten sich eigentlich von VS ohne Problem benutzen
lassen. Es ist ja auch eine VS2008 Konsole Demo dabei.
Ist halt nicht .NET aber da kann man sicher auch externe DLL Funktionen
definieren.
Hello everyone!
Sorry for english.
I try build this remote receiver.I use Atmega8. First i try bootLoadHID
v1.1 compile under AVRStudio with AVRGCC and i get this warnings.(you
will see on attached picture) What is the problem and the solution? (The
USB IR Remote Receiver 1.6 compile is working correctly, i am not
getting warning message) Thank You.
@ Hugo
nochmal zum Thema MediaPortal: arbeitest du an der Integration (nativ,
per dll, wieauchimmer) oder nicht?
Ich habe ein bisschen mit VC# und deiner DLL gepielt, aber empfangene
IR-Daten konnte ich dem Ganzen nicht entlocken, sondern lediglich die
Infos à la "PluginName", "Version" und "Copyright". Sachen wie das von
dir erwähnte "CrossTalk" habe ich allerdings nicht probiert.
@San398:
Just ignore this warnings!
@Michael K.:
Nein, habe im Moment keine Zeit mich mit C# oder .NET herumzuschlagen.
Um die IR Daten in deinem Progamm empfangen zu können brauchst du eine
CallBack Funktion. Wenn dann die USB_IR_Remote_Receiver.dll einen Code
empfängt wird diese CallBack (in deinem Programm) aufgerufen.
Mit der Funtkion "InitNative" kann man der DLL den Pointer deiner
CallBack Funktion übergeben. Auch musst du "InitNative" oder
"InitPAnsiChar" mit einem Pointer deiner CallBack Funktion aufrufen.
Ansonsten wird das HID-Device nicht geöffnet und es ist kein IR-Empfang
möglich.
Siehe z.B. hier:
http://www.myelin.co.nz/notes/callbacks/cs-delegates.html
Sieh dir dazu am besten die verschiedenen Demos an. Es sind ja Demos in
Delphi, C++ und Phyton (EventGhost) dabei.
Das CrossTalk wär nur für mich interresant. Dies würde die Benutzung von
.NET Assemblies in Delphi VCL herstellen. Dies ist ansonsten nicht
möglich.
An die Nutzer von MediaPortal:
wie habt ihr euch die Implementierung vorgestellt?
Mir schwebt vor, dass man einfach jeder Tastaturtaste einen IR-Code
zuweist. Man muss dann MePo so konfigurieren, dass man es gut mit der
Tastatur steuern kann und anschließend die IR-Codes vergeben. ShortCuter
und dergleichen kann man trotzdem verwenden.
Nachteil ist unter Umständen, dass man sich erstmal ne Liste erstellen
muss welche Taste was macht. Da ich das aber sowieso schon habe, kann
ich damit leben... ;-)
Das Ganze funktioniert so ohne weiteres aber nur wenn MePo im
Vordergrund ist (z.B. durch "Keep MediaPortal always on top").
an sich hätte ich mit einer solchen liste kein problem. Genial wärs
natürlich, wenn man es direkt zuordnen könnte, sprich man hat alle
möglichen Kommandos, wie z.B pause,play, umschalten usw. auf die man
klickt und anschließend einfach den gewünschten knopf auf der Fb drückt.
Wie genau meinst du das mit dem on top? Es geht also nur wenn man
richtig in Mediaportal drin ist und es nicht minimiert ist? Wenn ja wäre
das für mich völlig ok so lange es nicht die ganze zeit on top ist, ich
es also minimieren kann und mal im internet surfe, es aber dann wieder
maximiere, einmal reinklicke und die fb funktioniert wieder?
lg Hendi
Ich hatte mir gedacht, dass man z.B. eine Eingabemaske mit allen
möglichen Tasten (z.B. a...z, F1...F12, Shift, Ctrl, Enter, usw.) hat.
Zum anlernen markiert man eine dieser Tasten, klickt auf einen Button
(z.B. "Lernen") und anschließend sendet man einen IR-Code. Die Anwendung
speichert diese Daten in einer xml-Datei und fortan wird ein empfangener
IR-Code wie ein Tastendruck auf der Tastatur behandelt.
Z.B.
Protocol=NEC, Address=FD02, Command=000F => Enter
Protocol=NEC, Address=FD02, Command=000A => F1
Protocol=NEC, Address=FD02, Command=00FF => A
usw.
Wie bei einer regulären Tastatureingabe wird die Eingabe aber nur von
der aktiven Anwendung empfangen, irgendeine Applikation im Hintergrund
ist davon nicht betroffen.
Man könnte das Ganze auch als Tray-Applikation erstellen um es auch mit
anderen Programmen nutzen zu können, z.B. um seine Texte in Word auf der
Fernbedienung zu schreiben. ;-)
In deinem o.g. Szenario hieße das dann aber, dass dein Browser die Taste
empfängt und entsprechend (be-)handelt.
Vermutlich werde ich in einem ersten Schritt die genannte Tray-App
schreiben und danach evtl. erst das MePo-Plugin. Mir persönlich würde
das so ausreichen, da ich den entsprechenden Rechner nur für MePo nutze.
Habe für Linux eine Lösung gefunden:
http://forum.xbmc.org/showthread.php?t=88560
die Software-Version in Beitrag #117 (und sicher auch die, die noch
folgen) funktioniert mit meinem Empfänger.
Mit der o. g. Software (hid-mapper) können den empfangenen FB-Codes
entsprechende Tasten unter X zugeordnet werden.
Lirc ist nicht notwendig.
Getestet mit xbmc.
Leider hat es etwas länger gedauert als erwartet: anbei findet ihr ein
Standalone-Programm das die zugeordnete Taste an das Fenster im
Vordergrund sendet.
Zur Benutzung beide Dateien in ein Verzeichnis entpacken, Hugos DLL in
dasselbe Verzeichnis kopieren und das Programm starten. Die xml-Datei
aus dem Anhang soll nur als kleines Muster dienen. Falls nicht vorhanden
wird die Datei beim Programmstart neu erstellt, allerdings sind die
Tastenzuordnungen dann verloren.
Geschrieben wurde das Ganze mit VC# 2008, es wird also das
.NET-Framework 3.5 benötigt.
Wenn ihr einen Bug findet, bitte eine Info an mich mit einer kurzen
Beschreibung wie sich der Fehler reproduzieren lässt.
Des Weiteren habe ich noch eine kleine "Umfrage":
wer hat Interesse an einem Timer, der den PC zu einer bestimmten Uhrzeit
wecken kann?
Ich persönlich fände das sehr praktisch, da ich den PC dann komplett
ausschalten könnte und nicht auf Standby- oder Hibernate-Modi
zurückgreifen müsste, die (zumindest bei mir) nicht zuverlässig
funktionieren.
Die Weckzeit könnte über Hugos DLL eingestellt werden, die Uhrzeit auf
dem AVR könnte mittels eines DCF-Empfängers oder mit Hilfe einer RTC
bezogen/aktualisiert werden. Über Plugins würde die jeweils nächste
Startzeit entsprechend der anstehenden Aufnahmeaufträge eingestellt.
Mhm also iwie is das bei mir komisch. Ich kann einfach kein NET
Framework 3.5 bei mir installieren, hab das 4er drauf. (Windows 7
Ultimate, 64bit) und bekomme gleich beim Start Deines programms einen
Fehler, das versucht wurde eine Datei im falschen Format zu laden. Hängt
das mit dem Net3.5 da zusammen?
LG, Hendi
Wie genau lautet die Fehlermeldung?
Ich habe ehrlich gesagt keinen PC mit Win7 oder Vista, sondern nur WinXP
Pro 32bit mit .Net 3.5. Daher habe ich es auf anderen Systemen nicht
testen können.
@Michael K.:
Du musst im VC Projekt unbedingt den CPU Type von "Any" auf x86
umstellen.
Das war auch bei mir das Problem mit dem Error 0x8007000B.
Bei x64 System wird ansonsten versucht die DLL im x64 Modus zu laden ->
Error da es eine x86 DLL ist.
(habe Win7 x64)
Hugo Portisch schrieb:> Du musst im VC Projekt unbedingt den CPU Type von "Any" auf x86> umstellen.
Das ist mit der Version von 23:21 erledigt. Da ich keine Möglichkeit zum
Testen habe, wäre ich über Rückmeldungen dankbar.
Also es sieht wesentlich besser aus, als bei der alten Version ;) Bis
jetzt funktioniert alles. Werde morgen mal bisschen genauer testen.
Werde dann natürlich Rückmeldung geben.
LG, Hendi
Hendrik S. schrieb:> Werde dann natürlich Rückmeldung geben.
Ich bitte darum - nicht nur dich, sondern auch die anderen, die sich das
Programm runtergeladen haben.
Und ich möchte nochmal an die Frage von oben
(Beitrag "Re: USB IR Remote Receiver (V-USB + IRMP)")
erinnern: wer hätte gerne die Möglichkeit seinen PC via USB-IRRR
zeitgesteuert zu starten?
Herrgott :D ich bin shcon wieder nicht dazu gekommen das mal in Ruhe zu
testen. Ich hoffe, das ich am Wochenende endlich mal Zeit finde. Mhm
also wegen mir musst du die Zeitsteuerung nicht machen. Es wäre zwar
schon interessant aber für mich (wer es brauch soll sich melden) nicht
sinnvoll, da eh alle Aufnahmen über einen Server laufen
Hi, ich habe jetzt ein bisschen rumgespielt und kann jetzt grundlegend
mit der Fernbediunung durch Mediaportal navigieren. Das Programm läuft
bis jetzt stabil und zuverlässig :) Aber ich habe noch Fragen zu der XML
Datei:
Ich will jetzt noch z.B. der Leertsaste einen IR Code zuordnen, Aber wie
mache ich das? bei linker und rechter Pfeiltaste hat es natürlich schön
geklappt mit {left} usw. bei {space} geht das nicht. Warscheinlich ist
die Frage für einen, der programmiert total doof aber ich programmiere
nur sehr selten und dazu hatte ich noch nie was mit XML zu tun ;)
Wie muss ich das also schreiben?
LG,
Hendrik
In der XML-Datei selbst musst du doch gar nichts ändern. Dazu ist der
Dialog "Key assignment" da.
Ich habe ehrlich gesagt nicht alle Tasten getestet, daher ist mir das
mit Space nicht aufgefallen. Das Problem ist, dass beim Einlesen der
XML-Datei <key> </key> nicht als Space interpretiert wird, sondern als
nichts.
In der angehängten Version 1.0.0.2 ist ein Workaround eingebaut.
Allerdings musste ich dazu von der MSDN-Dokumentation abweichen. Dort
läuft Space als " " (ohne "), im Programm muss allerdings "{space}"
(ohne ") verwendet werden.
Noch zwei Bemerkungen zum Programm:
1. es können auch Tastenfolgen verwendet werden, dazu einfach die
entsprechende Folge eingeben, z.B. "test", "{up}{down}{left}", ...
2. es wird nicht überprüft ob ein IR-Code mehrfach zugewiesen ist.
Sollte dies der Fall sein, so wird die erste Zuweisung verwendet,
spätere werden ignoriert. Die Zuweisungsliste wird dabei von oben nach
unten durchsucht.
jaa ka ich hab jetzt halt alles direkt in der XML Datei gemacht :D ist
ja auch nicht wirklich mehr Aufwand. Habs jetzt so gelöst, das ich in
der XML von Mediaportal, wo die shortcuts definiert sind einfach
play/pause auf eine andere Taste umgelegt habe. -> funktioniert perfekt.
Ja mhm also das mit {space} hatte ich auch schon drin aber wie gesagt,
es hat nicht funktioniert aber naja es hat sich ja jetzte erledigt und
dein Programm läuft immer noch einwandfrei :) Vielen Dank für die tolle
Arbeit!
Hendrik S. schrieb:> Ja mhm also das mit {space} hatte ich auch schon drin aber wie gesagt,> es hat nicht funktioniert
In der vorigen Version war diesbezüglich ein Bug und das hat tatsächlich
nicht funktioniert. Danke für den Hinweis! Mit Version 1.0.0.2 sollte
{space} aber funktionieren.
Hallo Hugo,
ich habe mit Begeisterung dein Projekt nachvollziehen, ohne dass ich
mich mit Mikrocontroller auskenne, einfach eine super Sache, Danke für
diese super Idee und Umsetzung.
Es läuft alles bestens, dennoch habe ich hier zwei Fragen:
1. Da der Powerbutton bei der ersten Betätigung gelernt wird, wie kann
man diesen wieder ändern? bzw. wie löscht man das EEProm?
2. Da ich eine Änderung der IR Code machen möchte und die im Quellcode
schon geändert habe, kenne ich mich leider nicht mit den Compiler aus,
gibt es irgend ein HowTo, der das neu erstellen einer *.hex erklärt?
LG Dietmar
>> 1. Da der Powerbutton bei der ersten Betätigung gelernt wird, wie kann>> man diesen wieder ändern? bzw. wie löscht man das EEProm?
Der gelernte Code kann durch die DLL gelöscht werden. Also Optionen
Fenster öffnen und Clear Trained Code auswählen.
Der nächste erkannte IR code wird dann wieder gespeichert.
Tipp: Den Optokoppler entfernen, ansonsten kann es passieren, dass sich
der PC ausschaltet.
>> 2. Da ich eine Änderung der IR Code machen möchte und die im Quellcode>> schon geändert habe, kenne ich mich leider nicht mit den Compiler aus,>> gibt es irgend ein HowTo, der das neu erstellen einer *.hex erklärt?
Du brauchts AVR Studio und WinAVR um den Source kompilieren zu können.
Dazu findet sich sicher einige Anleitungen.
>> @ Hugo>> Ich kenne mich nicht wirklich gut mit USB-Kommunikation aus und habe mir>> u.a. dein Projekt als Beispiel angesehen, da ich gerade ebenfalls an>> einem Projekt mit V-USB arbeite. Dabei ist mir aufgefallen, dass als>> FeatureReport-Länge maximal 6 Bytes eingetragen sind, der>> Versions-Report allerdings 10 Bytes lang ist. Kannst du das bitte kurz>> erklären? Ist das Absicht und wenn ja, wieso?
Der Irmp IR Code besteht aus 6 Bytes: 1 Byte Protokoll, 2 Bytes Adresse,
2 Bytes Command und 1 Byte Repeat Flag = 6 Byte.
>> //enter here the Irmp build date:>> const char IrmpVersion[] = "18.01.2011";
Die 10 Bytes kommen von diesem String. Das sind 10 Zeichen.
Ich selber habe einige Zeit gebraucht, mir diesen HID Report zusammen zu
stellen. Ist gar nicht so einfach:
http://www.usb.org/developers/hidpage/
Besonders habe ich mit dem HID Descriptor Tool gearbeitet.
Wie gesagt, ich selber habe ~50-100 Versuche gebraucht bis das HID
Device dann einmal richtig vom PC erkannt wurde ;)
Hugo Portisch schrieb:>>> const char IrmpVersion[] = "18.01.2011";> Die 10 Bytes kommen von diesem String. Das sind 10 Zeichen.
Richtig. Aber ich vermisse diese Längenangabe im ReportDescriptor. Bei
der Report ID 7 ist dort vier angegeben und nicht 10. Soll das so sein
und wenn ja warum?
Hmmm.. gute Frage.
Ehrlich gesagt weis ich nicht mehr warum.
Es wird auf jeden Fall die usbFunctionRead verwendet, da es mehr als 8
Bytes sind. Bei der Demo 'Irmp_V-USB_mit_INT_1.0.0.0' werden auch 11
Bytes gelesen (Ansistring, Nullterminiert).
Über diese Funktion wird der String häppchenweise zum Host geschickt.
Es könnte sein, dass so der Host weis das per ID7 4 Bytes zu erwarten
sind. Eigentlich sollten es aber 0x0B sein. Könnte egal sein, sollange
der Host die richtige Anzahl anfordert.
Die DLL wertet den HID Descriptor nicht aus sondern die Datenmengen sind
fix definiert somit kann es sein das das 0x04 kein Problem darstellt.
Also vielleicht ein "Fehler" im Source...
Hallo,
wirklich schönes Projekt. Leider gibt es im Wiki keine Stückliste und
ich habe als Elektronik-Laie etwas Probleme die Kondensatoren aus dem
Schaltplan rauszuziehen. Daher die Frage: welche Art von Kondensatoren
C1/C2, EC1/2 werden verwendet?
Dirk W. schrieb:> Daher die Frage: welche Art von Kondensatoren C1/C2, EC1/2 werden> verwendet?
Die Werte stehen dabei. Technologie ist egal, vermutlich läuft es auf
Keramik für C1/C1 und Keramik oder Tantal-Elko für EC1/EC2 raus. Sieh
einfach nach was der Lieferant deiner Wahl in der Bauform deiner Wahl
auf Lager hat.
Es befindet sich im Packet ein PDF: www.reichelt.de.pdf
Das ist eine Stückliste und zeigt was für Kondensatoren verwendet
werden.
Generell ist es nicht so dragisch ob Elko oder Tantal-Elko. Die 2 22p
sind Keramikkondensatoren. Man kann die Elkos auch in SMD Bauform nehmen
wenn man sich ein Layout erstellt.
Hugo Portisch schrieb:> Es befindet sich im Packet ein PDF: www.reichelt.de.pdf>> Das ist eine Stückliste und zeigt was für Kondensatoren verwendet> werden.
Danke für den Hinweis, in das Zip habe ich natürlich noch nicht
geschaut.
Gibts evtl noch eine Empfehlung für ein Gehäuse? Eine offene
Lochraster-Platine findet meine Frau bestimmt nicht so schick.
Ich selber habe immer noch den Lochrasteraufbau im Gebrauch.
Dieser ist aber im PC Gehäuse. Wie man am Foto erkennen kann stecke ich
ihn direkt mit einm 10 poligen IDC Flachband am internen USB-Port an.
Den Empfänger habe ich mit ~10cm Kabel (altes Audiokabel was beim
CD-Laufwerk dabei war) an die Front des PC versetzt damit er die IR
Signale empfangen kann. Somit ist gar nichts mehr sichtbar.
Aber ein Gehäuse kann man sich schnell un günstig bei Reichelt/Rs
Komponents usw besorgen.
Dein Projekt sieht für mich sehr interessant aus.
Ich möchte den Empfänger in leicht abgewandelter Form einsetzen. Und
zwar benutze ich eine Wireless Extender, dieser nimmt die Befehle von
meiner Fernbediung per Funk entgegen und schickt sie dann normaleweise
an eine IR-Diode weiter welche dann letztendlich das Gerät über IR
bedient.
Zur Zeit gehe ich mit diesem Signal aus dem Extender über einen Tiefpass
direkt auf die Com-Schnittstelle. Der Receiver wird dabei als "active
high" genutzt, das ist mit Lirc auch kein Problem. Der TSOP ist ja
"active low".
Funktioniert dein Projekt auch direkt mit "active high", falls nein, an
welcher Stelle im Code müsste ich im Code das ganze umdrehen? Dürfte ja
nur die Stelle sein, wo das Eingangssignal gelesen wird. Dort müsste es
dann einfach invertiert werden.
Ich hab vorhin schonmal ein bischen durchgeguckt, aber da meine AVR
Kenntnisse recht beschränkt sind konnte ich es nicht finden.
Maniac schrieb:> Ich glaub ich habs gefunden. Folgendes müsste das auf active high ändern> oder?>> irmpconfig.h Zeile 81>
1
#define input(x) ((x) & (1 << IRMP_BIT))
> ändern in>
1
#define input(x) ((x) | (1 << IRMP_BIT))
Nein, das ist Unsinn.
Habe ich das richtig verstanden? Willst Du statt des TSOPs einen anderen
Empfänger nutzen, der High- statt Low-Pegel ausgibt? Wenn ja, dann geht
das so:
irmpconfig.h Zeile 81
Genau, ich werde über einen Tiefpass ein Signal nutzen, welches
normalerweise eine IR-Diode ansteuert.
Danke für die Korrektur, ich werd es so mal ausprobieren.
Altainta schrieb:> can u give a alternative for the CNY17III it is not available in the> market...(use following link to check alternative)
As far as I can see, there are a couple of CNY17 available. I think you
are a bit confused because of the ...III. There is CNY17-1 to CNY17-4.
The one you mentioned is the ...-3. I would suggest using ...-3 or
...-4, but it's not a very critical part.
Altainta schrieb:> Also u had a list of the items needed for this project can you please> provide it..
You can find the recent version in the second line below this headline:
http://www.mikrocontroller.net/articles/USB_IR_Remote_Receiver#Download
In this package under
USB_IR_Remote_Receiver_Complete_28022011\AVR_Source\USB IR Remote
Receiver 1.6\www.reichelt.de.pdf you can find a kind of a BOM.
You are right michael i was confused because of III okay i will buy any
cny17 which is available..
Yeah and i also found the BOM. lol
Thx will disturb u again.. have few questions..
I am very ashamed to say this but can u provide a Item List in English
because when i saw the shoplist www.reichelt.de.pdf
it is stated that KB 817 OPTOKOPPLER which is 4 leg but in the guide
they say CNY17III which is 6 leg... Why am i keeping pressure on this
because i need a PC ON / OFF system working properly.. I have Igor plug
but i want a good solution for windows 7 as well and on off.. Destiny
guided me here..
Please provide a completely item list we are hobbyist electronic
guys..thank you
Hallo zusammen,
ich bin jetzt endlich mal dazu gekommen den Receiver aufzubauen und in
Betrieb zu nehmen. Dabei sind mir ein paar Dinge aufgefallen bzw ich
habe da noch ein Problem:
1. Es wäre schön wenn das HexFile und die Source zusammen passen würden.
Wenn man die Source mit WinAVR compiled kommt ein anderes HexFile raus,
weil das Hexfile mit Bootloader=1 übersetzt wurde, im Source aber
Bootloader=0 gesetzt ist.
2. Für die Inbetriebnahme wäre es schön die serielle Schnittstelle für
Logging benutzen zu können. IRMP und V_USB bringen von Hause aus Support
dafür mit. Die Serial kann aber nicht benutzt werden, das RxD mit USB D-
verbunden ist. Imo extrem ungeschickte Wahl für die USB Datenports.
3. Bei mir funktioniert keine F_INTERRUPTS ungleich 10000. Dann werden
keine Remote Codes mehr erkannt bzw. nur noch falsche. Wie passt das
eigentlich zusammen wenn in der Source #define F_INTERRUPTS ein fester
Wert eingestellt wird und dann an dem Schieberegler der DLL rumgezogen
wird?
Da ich sowieso einige FB bzw IR-Tastaturen benutzen will, die nur mit
neueren IRMP Versionen funktionieren, habe ich dem Receiver ein IRMP
Upgrade verpasst. Das Verhalten mit den F_INTERRUPTS ist aber das
gleiche. Hat irgend jemand F_INTERRUPTS != 10000 am laufen?
1. Compiliere es selber. Dann weißt du am besten was du hast. Solche
Unterschiede könnten auch durch unterschiedliche WinAVR-Versionen
kommen.
2. Ändere es. Dafür gibt es den Abschnitt Hardware Config in
usbconfig.h.
3. Niedrigere Werte führen bei mir dazu, dass z.B. das Protokoll von NEC
zu RC5 wird und dieselbe Taste unterschiedliche Adressen und Kommandos
produziert. Höhere Werte führen ebenfalls gelegentlich zu Fehlern. Eine
andere FB habe ich noch nicht getestet und die Einstellung habe ich auf
default da es damit am kaum Probleme gibt.
F_INTERRUPTS wird nur zur ersten Init verwendet. Danach werden die
empfangenen Werte genommen. Siehe timer_init und usbFunctionWrite.
Dirk W. schrieb:> 3. Bei mir funktioniert keine F_INTERRUPTS ungleich 10000. Dann werden> keine Remote Codes mehr erkannt bzw. nur noch falsche. Wie passt das> eigentlich zusammen wenn in der Source #define F_INTERRUPTS ein fester> Wert eingestellt wird und dann an dem Schieberegler der DLL rumgezogen> wird?
Ich habe mir das nochmal angesehen und muss dir recht geben. Das kann
gar nicht funktionieren, da F_INTERRUPTS auch in irmp.c, Zeile 385 bis
599, zur Berechnung der Zeiten verwendet wird. Durch bewegen des
Schiebereglers wird nur die Zeitbasis des Timers verändert, F_INTERRUPTS
bleibt natürlich gleich und dadurch passen die Zeiten der Protokolle
nicht mehr.
After reading few articles online i got to know that the programmer like
serial, parallel etc will only work for new chips (fuse bits) but will
not work with existing chip. So i think i am having a problem while
ready a atmega8 chip. Now i decided to buy a new chip and test it..
1) Is it necessary to add crystal ? what is the purpose ?
2) In the Schematic (usb remote) there is Pin 26,25 mentioned as shield
on printer port what to do with it? i didn't understand where to connect
it...
3) In the schematic the LPT programer things are optional ? (in case if
u have a existing programmer)
4)In the meantime i will make the LPT programmer u suggested in the
schematic.. Will it work with existing atmega8 ?
5) The programmer which i mentioned above works only with the software
they provide http://sbolt.home.xs4all.nl/e-spider_prog.html. Name is
SP12. the program is like AVRDUDE (dos based) if u know about it can u
give me fuse bit setting for it ? in dos mode ? because this is the only
programmer which saved my 2-3 ics attiny 2313 etc. And the existing chip
which i have works with it... But i do not know the command for setting
Fusebit EXACTLY!.
6) One more thing (sorry to bug u) there are two ics Atmega8A 16 Mhz and
Atmega8L 8 Mhz which one to use ? Do they need Differe MHz crystal ?
My apology for asking so many noob question but i am very desperate for
this project diy.
Hallo,
Wie der Kollege "Maniac", habe ich eine Fernbedienung mit Funkempfänger
(Harmony 900), an den 2 sog. IR-Blaster angeschlossen werden können. In
den Dingern sind lediglich IR-Dioden verbaut, was bedeutet, dass sie
über den Anschluß des Funkempfängers bereits ein "fertiges" Signal
bekommen.
Ich dachte nun daran, die "USB IR Empfänger Schaltung" direkt an einen
IR Ausgang des Funkempfängers der Harmony anzuschließen. Das Signal
müsste meiner Ansicht nach nur noch demoduliert werden, was ich gerne
direkt mit dem Atmega8 machen würde.
Frage1: Ich habe gehört, dass man diese Demodulation direkt im AVR
machen kann, indem das Signal auf einen Interrupt Eingang gelegt wird,
mit dem man dann die Flanken zählt. Ist das soweit korrekt?
Frage2: Wie müsste ich in etwa den Code anpassen um das zu erreichen? C
kann ich halbwegs, nur mit AVR Programmierung habe ich mich bislang
weniger beschäftigt.
Frage3: Momentan sind beide Interrupts des Atmega belegt. Muß der
Bootloader Jumper ausgerechnet PD2 blockieren oder kann der auch auf
z.B. PD6 umgelegt werden?
@ altainta
1. Yes, it is. The 8MHz that the internal oscillator can achieve are not
enough for V-USB
2. It should work without shield, but don't forget pin 25.
3. Exactly.
4. Yes, it should. I didn't test it myself as I have a JTAGICE mkII and
used a Mega168.
5. As written in the schematic you could use Ponyprog. On their homepage
they have also some examples of working programmers.
6. They work with the same crystals, but the 8MHz works only up to 8MHz,
while you need at least 12MHz.
@Klez:
Äh.. der Receiver macht genau das was du beschreibst. Er wandelt die
IR-Impulse in Protokolltyp, Adresse und Command um. Schaue dir am besten
einmal den Artikel von IRMP an.
Ich glaube hier liegt ein Mißverständnis vor: Der Receiver ist dafür
ausgelegt das Signal über einen IR Empfänger (z.B. TSOP) zu bekommen.
Dieser entfernt bereits die Trägerfrequenz und füttert den AVR mit dem
reinen Nutzsignal.
Der Funk-Empfänger der Harmony 900 liefert am IR Ausgang aber ein
komplett moduliertes Signal. Ich müsste daher zuerst die Trägerfrequenz
entfernen und das geht angeblich auch direkt im AVR. Darauf war meine
Frage bezogen. "Maniac (Gast)" hat so etwas ähnliches weiter oben schob
beschrieben.
Thank You Michael K. (Gast)
I successfully build it..Everything is working fien. Now i want to make
it short and stable (in eventghost read below for the problem)
Now i would like to know few thing also you can consider some bug..
1)Adding short crystal than the long one.
I added full (big) Quartz Crystal Q1 12Mhz it works. I tried to replace
it with 12Mhz Small crystal (cut one) but it doesn't work.. The system
gives error when connected "USB DEVICE NOT RECOGNIZED". Can u tell me
how can i do it ? How to make this circuit short also which component to
use to make it short ? I saw a SMD version above do we have a schematic
or component list ?
small(cut) =
http://webbuilder.asiannet.com/617/comm/upimage/p_080905_03867.jpg
Full =
http://webbuilder.asiannet.com/617/comm/upimage/p_080905_03871.jpg
2) DLL intialization and also UNintialize it via windows
In eventghost (program) i add the plugin and done few thing with it. Was
working fien. but there are few things still giving problem...
A---In event ghost the mouse movement doesn't work (it is so slow
slow). I tried to work that out with mouse relative macro. Can u explain
why we can't use the normal mouse up, down etc thing. This thing works
perfectly with Igorplug and LIRC receivers which i already have but they
have limitation like com port windows xp etc etc.
B---In event ghost even after setting the "DISABLE POWERON
intialization" it doesn't function properly. I mean after selecting the
option it must do this
a) Do not work after Initialization (by windows ? or by eventghost ?)
b) Do work after windows shutdown (here is the problem it works one
time after that it doesn't)
So in short,
How to make it work how to intialize the plugin and also UNintialize it
via windows.
How to enable/disable the PowerON function via window "COMMAND LINE"?
3) Can you provide any smaller version of the schematic ? i mean smd and
normal both ? in eagle cadsoft http://www.cadsoftusa.com/?lang=en
4) One thing more will this support windows 7 32bit and also 64bit
version ?
Thank you
VERY GOOD PROJECT I LIKE IT..I am trying to make it work and good. I am
a hobbyist in electronics.
altainta altainta schrieb:> Can u tell me how can i do it ? How to make this circuit short also which> component to use to make it short ? I saw a SMD version above do we have a> schematic or component list ?
Using standard components is not a problem here as there are no special
requirements. So any is ok when the rated voltages and currents are
considered. Using other crystals should also be no problem (I'm using
http://www.reichelt.de/Quarze/12-0000-HC49U-S/index.html?;ACTION=3;LA=444;GROUP=B41;GROUPID=3173;ARTICLE=32850),
maybe you'll have to adjust the corresponding capacitors according to
the crystal datasheet.
altainta altainta schrieb:> 3) Can you provide any smaller version of the schematic ? i mean smd and> normal both ? in eagle cadsoft http://www.cadsoftusa.com/?lang=en
No. I also have only a THT version.
The power-on-thing should IMO be implemented in firmware. Currently I'm
working on an alternative firmware and maybe I'll include this.
I can't answer the other questions as I'm not working with Eventghost
and/or Win 7.
Yes, there is a bug with the "PowerOn Function" in the DLL with
EventGhost.
The function gets disabled but not anymore enabled so you can't switch
on the PC with the optocoupler.
It is already fixed but i missed to upload the new DLL.
I will do this in this week!
Hi,
Kann man die angesprochene BugFix Version schon irgendwo runterladen? Da
ich auch mit Eventghost arbeite wäre die für mich sehr nützlich :)
Viele Grüße
Hallo!
Ich habe den Empfänger laut Anleitung aufgebaut, funktioniert tadellos.
Allerdings habe ich ein kleines Problem:
Die (Noname) Fernbedienung, welche ich mit dem Empfänger verwenden
möchte, hat einige Tasten, die nicht erkannt werden ("8", "Mute" und
einige weitere).
Diese Tasten funktionieren jedoch über den IgorPlug problemlos.
Alle anderen werden einwandfrei erkannt.
Hat jemand eine Idee, woran das liegen könnte?
Der einzige Unterschied in meinem Aufbau ist, daß ich einen TSOP 1136
verwende.....kann es daran liegen?
Daniel S. schrieb:> Hat jemand eine Idee, woran das liegen könnte?> Der einzige Unterschied in meinem Aufbau ist, daß ich einen TSOP 1136> verwende.....kann es daran liegen?
Im IRMP-Thread wird dir eher geholfen werden.
Daniel S. schrieb:> Die (Noname) Fernbedienung, welche ich mit dem Empfänger verwenden> möchte, hat einige Tasten, die nicht erkannt werden ("8", "Mute" und> einige weitere).
Im IRMP-Artikel findest Du eine kleine Anleitung, wie Du Scans von
Deiner Fernbedienung machen kannst.
http://www.mikrocontroller.net/articles/IRMP
Zugehöriger Thread:
Beitrag "IRMP - Infrared Multi Protocol Decoder"> Diese Tasten funktionieren jedoch über den IgorPlug problemlos.> Alle anderen werden einwandfrei erkannt.
Wenn Du mir die Scans zuschickst, kann ich den IRMP entsprechend
erweitern.
Ich bräuchte Scans von funktionierenden Tasten, wie 1-7 und 9, und dann
noch die von den nicht-funktionierenden.
Gruß,
Frank
Hallo,
ich habe die Schaltung in SMD nachgebaut, allerdings nicht den ATMEGA8
sondern den ATMEGA168P-20AU genommen und versuche nun den mit Ponyprog
über die parallele Schnittstelle zu programmieren.
Leider klappt das ums verrecken nicht. Nun habe ich hier irgendwo
gelesen, dass Ponyprog den 168p nicht unterstützt.
Stimmt das und wenn ja, mit was programmiere ich das Ding dann? Brauche
ich einen anderen Programmer, bis jetzt habe ich nur das ganz einfache
ISP-Interface (siehe Schaltplan hier vom Projekt).
Vielen Dank
Gruß
Stefan
Hi,
danke, ich habe mittlerweile AVRdude probiert, damit sieht's bis jetzt
ganz gut aus. Jetzt fehlen mir nur noch die richtigen Fuse-Bits. Das
wird aber hoffentlich auch noch.
Gruß
Stefan
Hallo Hugo,
Ich habe mit dem Gedanken gespielt den USB Receiver HTPC tauglich zu
komplettieren, indem man noch ein Samsung 20L203DA12 (z.B. erhältlich
bei eB*y) dazubaut.
Dieses Display ist günstig erhältlich und wird normalerweise via RS232
angesprochen... Ich dachte nun es wäre vielleicht möglich das Ding über
den Atmega laufen zu lassen, da dieser an USB hängt. Meinst Du das ist
machbar, bzw. in die Firmware integrierbar?
Viele Grüße
Hallo,
ich beschäftige mich gerade mit V-USB als ich dieses Projekt gefunden
habe, habe ich mir gedacht das es ein guter Einstieg in das Thema wäre.
Mein Problem ist nur das ich keine Verbindung mit dem PC erreiche.
Ich habe mir auf ein Steckboard ein Widerstand-Spannungsteiler aufgebaut
weil ich keine Z-Dioden mit 3.6V habe. Desweiteren habe ich die
usbconfig.h verändert und PD2 an D- und PD3 an D+ sowie einen 1.1k Ohm
Widerstand an PD4 angeschlossen. In Ermangelung eines 68 ohms
Widerstandes habe ich mit parallelgeschalteten Widerständen 88_Ohm
erreicht. Mein Mega8 läuft mit einen 20Mhz Quarz wobei ich mein
compilieren 12Mhz eingestellt habe. Das Gerät wird hin und wieder mal
angezeigt aber wird einfach nicht erkannt. Ständig meint Windows das es
ein "unbekanntes Gerät" sei. Auf was muss ich bei V-USB genau achten
damit ich eine Verbindung bekomme?
im Anhang mal der Spannungsteileraufbau.
Viele Grüße
Lars L. schrieb:> Ich habe mir auf ein Steckboard ein Widerstand-Spannungsteiler aufgebaut> weil ich keine Z-Dioden mit 3.6V habe. Desweiteren habe ich die> usbconfig.h verändert und PD2 an D- und PD3 an D+ sowie einen 1.1k Ohm> Widerstand an PD4 angeschlossen. In Ermangelung eines 68 ohms> Widerstandes habe ich mit parallelgeschalteten Widerständen 88_Ohm> erreicht.Lars L. schrieb:> im Anhang mal der Spannungsteileraufbau.
Kannst daraus mal einen vernünftigen, kompletten und aufgeräumten
Schaltplan zeichnen? Mit dem von oben kann man nicht wirklich was
anfangen. Zum einen tauchen deine 88ohm nirgends auf, zum anderen sind
D+ und D- ja sicher nicht kurzgeschlossen.
Lars L. schrieb:> Mein Mega8 läuft mit einen 20Mhz Quarz wobei ich mein> compilieren 12Mhz eingestellt habe. Das Gerät wird hin und wieder mal> angezeigt aber wird einfach nicht erkannt. Ständig meint Windows das es> ein "unbekanntes Gerät" sei. Auf was muss ich bei V-USB genau achten> damit ich eine Verbindung bekomme?
Das funktioniert natürlich nicht. Dein AVR rennt mit der Frequenz des
angeschlossenen Quarzes (oder des internen Oszillators), da kannst du
bei compilieren einstellen was du willst - das ändert daran überhaupt
nichts. Das Einzige was du dadurch erreichst ist, dass sämtliche Zeiten,
die mit Hilfe von F_CPU errechnet werden nicht stimmen.
KLez schrieb:> Dieses Display ist günstig erhältlich und wird normalerweise via RS232> angesprochen... Ich dachte nun es wäre vielleicht möglich das Ding über> den Atmega laufen zu lassen, da dieser an USB hängt. Meinst Du das ist> machbar, bzw. in die Firmware integrierbar?
Ich bin zwar nicht Hugo, kann dir aber vielleicht trotzdem helfen:
machbar ist das auf jeden Fall, wobei du prinzipiell auch jedes andere
Display nehmen kannst. Kann halt sein, dass die Aktualisierung länger
dauert, wenn die Ansteuerung komplexer/zeitaufwändiger wird.
Ich arbeite ebenfalls an einer Firmware, die auf Hugos Version basiert,
aber ein paar zusätzliche Features beinhaltet, z.B. eine Uhr und einen
Timer, mit dem der PC zu einer programmierbaren Zeit eingeschaltet
werden kann, auch wenn er ganz aus ist.
Du würdest also eine neue ID einführen und in der entsprechenden
Botschaft den Displayinhalt übermitteln.
Auf PC-Seite sieht das Ganze schon etwas komplizierter aus: entweder du
hoffst auf Hugo, oder du machst dich selbst an die Implementation. Als
Anfang kannst du dir eine Lib von
http://www.mikrocontroller.net/articles/USB_HID_Host_Treiber aussuchen
und entsprechend anpassen. Bei mir ist es die HidLib von jj-jabb
geworden.
Hallo,
habe jetzt auch mal den Referenzschaltplan hinzugefügt, den ich versuche
aufzubauen, nur halt mit anderen Bauteilen.
Geht das ganze eigentlich mit 20Mhz und ein Spannungsteiler oder bewege
ich mich in eine völlig falsche Richtung?
Ich habe übrigens die IRMP-Bauteile vollkommen weg gelassen, ich wollte
mich erstmal mit V-USB beschäftigen und das Projekt als mein
Referenzprojekt nehmen.
Irgendwo muss man ja Anfangen :-)
Viele Grüße
@Lars L.
Das kann so wie du es aufgezeichnet hast nicht funktionieren.
Auch habe ich einmal deine Schaltung vereinfacht nachgezeichnet.
1. Du machst einen Kurzschluss mit D+ und D-.
2. Es gehört nur D- auf ~3,6V Pegel, D+ hängt in der "Luft". Es wird nur
der Pegel beider Datenleitungen auf 3,6V begrenzt um keine Probleme mit
moderneren USB Host zu haben.
3. Der 1,5k Ohm Pullup bei D- ist wichtig weil ansonsten der PC nicht
erkennt ob USB 1.11 oder USB 2.0 Device.
4. Die 68 Ohm begrenzen den Strom zwischen AVR und PC in den
Datenleitungen, sonst nichts.
Mit Spannungsteilern das aufzubauen ist nicht so einfach und geht
weniger gut. Der AVR spuckt 5V aus und es dürfen aber nur 3,6V an die
Datenleitung.
Mann kann auch 2x1N4184 Dioden in die Versorgung als Spannungsabfall (5V
- 0,6V - 0,6V = 3,8V) des AVRs hängen - wenn dieser dann noch läuft.
Dann kann man sich die Z-Dioden an den Datenleitungen sparen.
Das einfachste ist und bleiben die 2 Z-Dioden. Die kosten dann auch
nicht die Welt.
Und wenn du mit 12Mhz kompilierst solltest du auch einen 12Mhz Quarz
einsetzen.
Hallo,
danke für die Antwort hat mir erstmal geholfen :-)
Also reintheoretisch und aus mein Bauchgefühl heraus müsste ich also
zwei Spannungsteiler mit widerständen aufbauen und vermutlich noch ein
paar Gleichrichterdioden einbringen damit es keine Rückkopplung gibt und
die Pegel sauber an die Datenleitungen gebracht werden?
Bald ist ja wieder Geld aufn Konto da denke ich mal wird Reichelt ne
Bestellung von mir bekommen :D
Viele Grüße
Lars
tag,
ich lese ja seit Jahren nur noch mit. aber hier möchte ich auch mal was
sagen:
Danke, klasse Sache.
Details welche ich noch mitgeben möchte: (insbesondere wenn man win2k
nutzen will)
JA es läuft auch unter win2000.
Es wäre schön wenn die Infos ein bischen übersichtlicher aufbereitet
wären.
an manchen details sucht man sich blöd.
zB das man die *.dll mit zu den *.exe Dateien packen muss, damit da was
läuft. Ist im nachhineien sicher offensichtlich aber für jemand der nur
µc bezogen software macht nicht sofort offensichtlich (irgendwie).
Was auch nett wäre, wäre das makefile WinAVR oder die Einstellungen im
AVR-Studio. von wegen Optimierung usw. kann sich ja doch immer mal
anders verhalten zudem wären dort ja dann auch alle benötigten files
enthalten.
Angehängt habe ich mal eine minimalversion im Eagle-format. ich habe das
auf lochraster aufgebaut ! ich hatte eine beidseitg kaschierte
lochrasterplatine daher konnte ich GND oben führen.
In dem Bild von des Schaltplans kann man die Z-Diodenwerte 3,6 sehr
schlecht lesen.
Als Ersatz für die TSOP17..-Serie eigent sich die TSOP312.. Serie sind
pin- und dimensionskompatibel
Von Eventghost bin ich ebenfalls recht begeistert. Auf Win2k läuft
allerdings nur noch Version 0.4.0r1397 die neuren nicht mehr sondern
erzeugen nur noch einen Eintrag im Fehler log.
Das GDI+ muss man microsoft laden und dann die gdi+.dll kopieren.
Der SAMSUNG32 Ferbedienungstyp bedient sich der 38kHz Trägerfrequenz
so damit hätte ich meine gedanken und mein Danke niedergelegt.
schönen tag noch
Balu
ps: damit kann man echt werbung machen. ich werde es auf jeden fall tun
damit das eine breitere Unterstützung bekommt
Hallo,
Michael K. schrieb:> Ich arbeite ebenfalls an einer Firmware, die auf Hugos Version basiert,> aber ein paar zusätzliche Features beinhaltet, z.B. eine Uhr und einen> Timer, mit dem der PC zu einer programmierbaren Zeit eingeschaltet> werden kann, auch wenn er ganz aus ist.
das ist noch genau das, was ich vermisse. Wirst Du das veröffentlichen?
Und was auch noch richtig klasse wäre: LEDs, die von einer Software
angesteuert Zustände anzeigen. Z.B. wenn VDR auf Tuner1 aufzeichnet,
oder wenn AC3-/DTS Ton aktiv ist, etc.
Es gab mal ein Projekt von Th. Breuer, der hat das tbe-ExtensionBoard
(http://www.tb-electronic.de/vdr/vdr_extension_board.html) entwickelt,
das konnte das alles und es gibt auch ein Plugin für VDR dafür.
Für Thin Clients ist das allerdings nix, Scart-Anschlüüse sind out und
eine Com-Schnittstelle hat auch kaum noch ein Mainboard.
Die Remote-, Wakeup- und LED-Funktionen auf einer kleinen USB-Platine
wären schon der Knaller.
Leider habe ich keinen Plan von Mikrocontroller-Programmierung,
vielleicht hat aber jemand von Euch nun Lunte gerochen. :-)
Gruß
Stefan
Hi Dirk,
das Display habe und kenne ich (habe auch ein Dockstar).
Aber ich will doch kein Display sondern nur ein paar Status-LEDs (mir
reicht es eigentlich, wenn ich sehe, ob eine (mehrere) Aufnahme läuft
ohne ins OSD schauen zu müssen, bzw. so sehe ich das auch sofort, wenn
der TV aus ist). Die LEDs kriegt man in jeden ThinClient rein, das
Display mußt Du irgendwo hinstellen und kannst es dann von der Couch aus
doch nicht lesen...
In dem Plugin zu dem ExtensionBoard von tbe kann man sogar für mehrere
Tuner jeweils eine LED schalten. Sehr praktisch. Und der AVR könnte das
doch nebenbei im Schlaf.
Gruß
Stefan
Stefan Meyer schrieb:> das ist noch genau das, was ich vermisse. Wirst Du das veröffentlichen?
Ja. Allerdings nutze ich MediaPortal unter XP, sprich dotNET-basierend.
Wobei die Hardware natürlich auch unter Linux lauffähig ist, eine
entsprechende Applikation vorausgesetzt. Vielleicht bekommt man es mit
Mono auch direkt zum Laufen, wobei ich mich damit absolut nicht
auskenne.
Michael K. schrieb:> Wobei die Hardware natürlich auch unter Linux lauffähig ist, eine> entsprechende Applikation vorausgesetzt.
Ich habe einen lirc-kompatiblen Daemon auf Basis von inputlirc für den
Receiver geschrieben, läuft ohne Probleme am VDR. Der kann natürlich die
zusätzlichen Features nicht.
Wollte ich bei Gelegenheit mal releasen, aber die Nachfrage nach Linux
Support war bisher eher gering außerdem habe ich meinen Receiver erst
mal wieder eingemottet.
Dirk W. schrieb:> Ich habe einen lirc-kompatiblen Daemon auf Basis von inputlirc für den> Receiver geschrieben, läuft ohne Probleme am VDR. Der kann natürlich die> zusätzlichen Features nicht.
Ja gut, in dem Fall gibt es doch schon eine Basis. Es kommen dann halt
ein paar neue IDs mit entsprechendem Inhalt dazu. Sollte ja kein allzu
großes Problem sein.
hi, ich habe mal das Pollin BAS rs232 Modul (ATmega8) geordert, das war
ja hier schon als Bauvorschlag zum IR Empfänger Thema, nun mit dem
ATmega168 und IRMP scheint perfekt hier reinzupassen, Empfang ist klar
mit der DLL, nur wie bekomme ich IRSND rein ? gibt es einen Treiber für
Send über USB ? oder müsste man auf USB zu RS232 Libs wechseln ? da wäre
mit Treiber Receive und Send möglich
hat da jemand schon Ideen oder einen passenden Link ? vielen Dank
Hintergrund, eigendlich will ich übers Netz (VNC) meinen VCR
programmieren, brauche also vordergründig IRSND, IRMP wäre ein nettes
Gimmik zur PC Fernbedienung, der ATmega168 ist ja groß genug für beides
mit reichlich Protokolle
jar schrieb:> Hintergrund, eigendlich will ich übers Netz (VNC) meinen VCR> programmieren, brauche also vordergründig IRSND, IRMP wäre ein nettes> Gimmik zur PC Fernbedienung, der ATmega168 ist ja groß genug für beides> mit reichlich Protokolle
Habe ich mit meinem Sohn exemplarisch aufgebaut:
PC -> my-AVR-USB-UART-Converter -> ATTiny85
also nicht über V-USB.
Am Attiny85 (kleiner µC mit nur 8 Pins) hängen TSOPxxxx, IR-Sendediode,
eine LED und RX/TX - realisiert als Soft-UART. Über den Soft-UART nimmt
der ATTiny die Sende-Befehle entgegen und "strahlt" sie mit IRSND ab.
Empfangene IR-Frames über den TSOP sendet er über die Soft-UART an den
PC, damit der PC "lernen" kann.
Wir haben das noch nicht veröffentlicht, weil wir im Moment nur ein
kommandozeilen-orientiertes PC-Programm zum Senden der IR-Befehle und
zum "Lernen" der Codes haben. Das funktioniert aber schon. Im Moment
programmiert mein Sohn noch an der graphischen Benutzeroberfläche,
welche eine frei gestaltbare Fernbedienung unter Windows werden soll.
Wenn Du an der Software für den µC und an dem Kommandozeilenprogramm
interessiert bist, schreib mir eine PN, dann kann ich Dir den aktuellen
Stand schon mal schicken. Damit solltest Du das gewünschte realisieren
können.
Gruß,
Frank
Hallo,
Sorry fuer die dummen Fragen, aber ich habe keine Ahnung von windows und
brauche "Starthilfe":
Ich moechte den USB_Remote_Receiver als Basis verwenden fuer eine
Erweiterung , so dass der Empfaneger per IR oder Funk angesprochen
werden kann und dann einen linux-PC-steuert. Ich habe bereits andere
Anwendungen mit V-USB auf AVR mit Linux zum Spielen gebracht - wollte
aber zuerst alles "out of the box" mit windows ausprobieren.
Ich habe die Original Sources genommen, USE_BOOTLOADER in
configUSBIRREmoteReceiver.h auf 0 gesetzt und alles mit AVR-studio
kompiliert. Ich hoffe, ich brauche den BootLoader nicht, denn ich weiss
ehrlich gesagt nicht wirklich was das ist.
Ich habe das hex-file mit avrdude unter linux geflasht(ATMEGA8-16PU).
Die fuses stehen auf 0xd0(high) und 0xe1 (low).
Wenn ich den controller per USB mit einem windows-XP host verbinde,
erscheint die Meldung: "USB-Geraet wurde nicht erkannt". Ich habe zwar
noch keinen IR-Empfaenger angeschlossen, aber das sollte bis hierher ja
wohl egal sein. Daher hier meine Fragen:
1)Kann ich wie beschrieben ohne den Bootloader arbeiten?
2)Welche fuse-Einstellungen solle ich nehmen (bitte in Hex, in meinem
GUI (avrfuse) heissen die Bits offenbar anders.
3)wie kann ich XP beibringen, die DLL zu laden?
Danke,
Wolfgang
Hallo,
ich fuerchte ich brauche noch konkretere Hilfe. Was bisher geschah:
-Ich habe die fuses geaendert auf
Low: 0x1F
high: 0xC1
-Ich arbeite weiterhin mit USB_BOOTLOADER = 0
-Mittlerweile scheint XP das device zu erkennen: Im Geraetemanager
werden zwei neue USB-HID-devices als betriebsbereit angezeigt.
-Wenn ich aber .../Demo_Sources/Releases/DLL_Demo.exe anklicke bekomme
ich ein Fenster, in dem ich nur load DLL anklicken kann. Wenn ich das
tue, passiert nichts weiter.
-Wenn ich von der DOS-Console aus DLL_Demo_Console.exe starte, bekomme
ich die Fehlermeldung
ERROR: unable to load DLL
Was mache ich falsch? Muss ich die DLL irgendwo hinkopieren? Welche DLL?
Sorry fuer die dummen Fragen, aber ich bin ein UNIX-Mensch und weiss von
Windows eigentlich nur, wie man es ausschaltet.
Danke
Wolfgang
Danke fuer den link. Das ist ziemlich genau das, was ich machen will!
Werde ich testen.
Mittlerweile laeufts auch unter windows (ich musste die DLL neben das
.exe kopieren). Ein 3-zeiliges howto auf der Webseite waere vielleicht
hilfreich.
Gibt es eigentlich zu IRSND auch einen V-USB-wrapper? So wie ich das
verstehe stellen die sources "nur" eine subroutine zur Verfuegung.
Wolfgang
Hallo,
erst einmal danke für so ein super projekt!
ich habe mir den USB IRMP als prototyp auf lochraster nachgebaut, das
flaschen ging einwandfrei (bootloadHID.hex aus atmaga8/default/).
allerdings wir er jetzt von windows als unknowen device erkannt. jemand
eine idee woran das liegen könnte?
grüße
@Moto:
Dazu sind mehr Infos notwendig? Ist der Source neu kompeliert worden?
Für welche Frequenz, welche Frequenz hat der Quarz,....
Bei den Fusebits muss der 2048 Bytes Bootloader aktiviert sein...
Moto schrieb:> ich habe mir den USB IRMP als prototyp auf lochraster nachgebaut, das> flaschen ging einwandfrei (bootloadHID.hex aus atmaga8/default/).> allerdings wir er jetzt von windows als unknowen device erkannt. jemand> eine idee woran das liegen könnte?
Wie immer am Erbauer.
Habe die Schaltung laut Schaltbild aufgebaut.
(alle Teile außer Jumper und Pony-Interface)
Nur den Bootloader geflasht.
Beim Einstecken wird er bereits als HID Interface erkannt.
Also nix unbekanntes!
Die Firmware ist noch nicht drauf, nur der Bootloader!
Peter
Wie ich solche antworten liebe... Momentan ist die platine bestückt mit
rst pullup, quarz mit c's, isp buchse und dem usb zweig mit 4 R's und 2
z-dioden
Leiter bahnen sollten passen bauteile eben so. Kalte lötstellen waren
unter dem mikroscope auch keine ersichtlich
Grüße
Moto schrieb:> Leiter bahnen sollten passen bauteile eben so. Kalte lötstellen waren> unter dem mikroscope auch keine ersichtlich
Mein Hinweis sollte Dir dienen um den Fehler in
der selbstgebauten Hardware zu suchen.
Finden ist da wohl nicht Deine Stärke.
Antworten wie "sollten passen" sind schlecht bzw. oberflächlich.
Kalte Lötstellen und Mikroskop, haha.
Mit dem Ohmmeter "durchgeklingelt" wäre schon besser.
Der fertigen Software nicht trauen,
dann selbst kompilieren und klappt auch nicht,
meinem Hinweis auf "aufgebaut und klappt"
und den erfolgreichen vorgenannten Erfolgsmeldungen
auch keinen Glauben schenken.
Ich würde Dir ja eine Leiterplatte überlassen,
aber wenn Du die dann fehlerhaft aufbaust ziehst Du mich runter.
Peter
Stelle doch mal ein Bild Deiner Hardware hier ein.
So das problem ist nun behoben, der quarz wars. Es stand zwar 12mhz
drauf, waren aber scheinbar nicht drin. Da nach einem tausch des quarzes
der bootloader sofort erkannt wurde.
Grüße
Gutentag,
ich habe den Empfänger aufgebaut, die einzige Änderung ist das ich den
TSOP31238 anstelle eines 17.. verbaut habe. Der Empfänger läuft auch
soweit allerdings erkennt er mir kein RC5, NEC funktioniert. (Source ist
neu kompiliert, mit samsung, nec und rc5 auf 1 der Rest auf 0). Muss ich
etwas weiteres einstellen damit RC5 erkannt wird?
Rezzo
Ich selber habe bei meinem letzen Aufbau mit der Tonertransfermethode:
http://www.mikrocontroller.net/articles/USB_IR_Remote_Receiver#Foto_eines_aufgebauten_USB_IR_Remote_Reciever
eine TSOP4838 verwendet. Die ist um einiges kleiner als die "alte" TSOP
1738. Geht ohne Probleme!
Wichtig für die IR-Diode ist:
>> Die maximale Versorgungsspannung muss 5V oder höher sein>> Frequenz für das benutzte IR Protokoll (meistens 38kHz ausreichend)>> Ausgang Active Low. Dies kann aber sicher ansonsten im IRMP Source >>
irgendwo ausgedreht werden.
Hallo, Nachdem ich über das vdr-Portal und dessen daemon für diesen
IR-Empfänger hier gelandet bin, hab ich mich auch gleich mal an den
Nachbau gemacht (geniales Projekt! Danke Frank + Hugo). Das funktioniert
auch soweit ganz gut, aber ich wollte mich auch einen Schritt weiter
wagen und IRSend mit implementieren. Nur leider stolpere ich schon beim
Einsetzen der irsnd.c in die main.c.
Was ich bislang gemacht habe:
1. in der main.c die Includes
//from irsnd
#include <inttypes.h>
#include "Irsnd\irsndconfig.h"
#include "Irsnd\irsnd.h"
vorn hinzugefügt.
2. in den USB-Descriptoren die Werte auf
PROGMEM char usbHidReportDescriptor[107] ... else PROGMEM char
usbHidReportDescriptor[98]
Geändert
3. in den USBDescriptoren
vor 0cx0 (dem ende)
0x85, 0x0a, // REPORT_ID (10)
0x95, 0x06, // REPORT_COUNT (6)
0x09, 0x00, // USAGE (Undefined)
0xb2, 0x02, 0x01, // FEATURE (Data,Var,Abs,Buf)
hinzugefügt.
4. in den V-USB-Feature-Const
const uchar SendIRCodeOut = 10;
hinzugefügt.
5. In init_io
/* config Snd pin */
SND_PORT ^= _BV (SND_BIT); /* deactivate pull-ups on SND pin */
SND_DDR ^= _BV (SND_BIT); /* set snd pin as digital output */
hinzugefügt.
6. im Timer1 cor irmp_ISR()
irsnd_ISR(); //
call irsnd ISR
Hinzugefügt.
7. in usbfunctionWrite nach SetTrainedIRCode
else if ( DoWriteReport == SndIRCodeOut )
{
irmp_data.protocol = IRMP_NEC_PROTOCOL;
irmp_data.address = 0x00FF;
irmp_data.command = 0x0001;
irmp_data.flags = 0;
irsnd_send_data (&irmp_data, TRUE); // Send IR code out
eingefügt
8. in der main Func tion vor irmp_init()
irsnd_init(); // initialize irsnd
eingefügt.
9. in der configUSBIRRemoteReceiver_h
//define output pin for IRsnd:
#define USE_IrSndFunction 1 /* 1, use IRsend function (default), 0
to disable */
#if USE_IrSndFunction
#define IRSND_PORT PORTD /* PORTx - register for IRsnd output
*/
#define IRSND_BIT PD6 /* bit where IRS-diode will be connected
*/
#define IRSND_DDR DDRD /* Switch data direction register */
#endif
Es lässt sich kompilieren, aber ich weiß nicht, wie ich dem Teil dann am
besten Daten übergeben soll oder ob es überhaupt so funktioniert.
(meine C /C++ Kenntnisse sind .... mangelhaft). Vielleicht greift ja
jemand das Ganze auf und rundet es ab. (Anbei die das USB-Irmp-zip-File
mit IRsnd ergänzt.)
@ Andy P.
Was genau willst du denn erreichen? Aus Windows/Linux heraus IR codes
senden, oder empfangene codes weiterreichen?
Ich arbeite gerade an einer Version, die letzteres kann und
darüberhinaus eine Uhr zum Aufwecken des PCs und die Möglichkeit den PC
zu resetten beinhaltet. Ich hatte aber auch schon darüber nachgedacht
eine Funktion zum Senden von IR codes von Windows/Linux zu
implementieren. Wäre keine große Sache mehr.
Leider kann ich nur gelegentlich abends daran arbeiten, weswegen das
Ganze schon eine Weile dauert und auch noch eine Weile dauern wird.
Wobei die Firmware schon recht weit ist, die Host-Software ist noch die
größere Baustelle.
@Andy P.
schaut nicht so schlecht aus. Kann es leider nicht durchtesten da ich
hier kein AVR 4.x Studio habe.
Der usbHidReportDescriptor scheint richtig zu sein. Die Länge passt dann
auch.
Vom PC schickt man dann per SetFeature:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff539684(v=vs.85).aspx
die Daten zum AVR.
Der ReportBuffer ist dann:
0A >> Report ID
02 >> Protokol ID
0000 >> Adresse
0000 >> command
00 >> Flags
1
elseif(DoWriteReport==SndIRCodeOut)
2
{
3
irmp_data.protocol=IRMP_NEC_PROTOCOL;
4
irmp_data.address=0x00FF;
5
irmp_data.command=0x0001;
6
irmp_data.flags=0;
7
irsnd_send_data(&irmp_data,TRUE);// Send IR code out
8
}
Sollte dann so sein:
1
elseif(DoWriteReport==SndIRCodeOut)
2
{
3
memcpy(&irmp_data,&data[1],sizeof(irmp_data));
4
irsnd_send_data(&irmp_data,TRUE);// Send IR code out
5
}
Ist aber nicht getestet und mit irsnd habe ich gar keine Erfahrung...
Bei Delphi ist es zusätzlich wichtig ein "Packed" Record zu verwenden.
http://www.delphibasics.co.uk/RTL.asp?Name=Packed
Ich glaub, dass ist aber Visual Studio sowieso so!?
@kichi:
Ich habe beim Zusammenstellen der Platine erst versucht, das ganze in
einen ATTiny85 zu verfrachten, was mit Kampf auch geht. Dann habe ich
aber gesehen, daß die ganzen Protokolle komplett (inkl V-USB etc.) nicht
in den kleinen Speicher passen, ergo musste ein größerer 16K-AVR her.
Daraus wurde dann eine einseitige Platine nur mit
DIL-Chips+Drahtbauteilen die kaum größer als ein USB-Stick ist. Da aber
noch immer Platz war, gabs halt das Hühnerfutter für IRsend mit hinzu.
Die ganze Platine ist dann für HTPCs gedacht - entweder außen dran als
Stick oder innen drin hochkant direkt auf einen der 9-poligen
USB-Steckplätze eines Mainboards (Platine ist leicht +klein genug, um
dort sich selbst auf den Kontakten zu halten).
Und wenn das Teil schon so hardwarefertig da steht und sich um die
kontolle des HTPCs kümmert, dann kann das auch gleich die passende
Hardware sein, um sich um die andere Braune Ware zu kümmern. (Lautstärke
des AV-Verstärkers, TV-Eingangsumschaltung etc).
Bei mir soll das Teil als Empfänger für VDR unter Linux dienen. Hier
wäre es sehr einfach möglich, im Menü des VDR oder bei Einschalten des
PC auch andere Geräte zu wecken. Somit sendet der Linux-PC via USB
selbst die Signale.
Auch kann der entsprechende Daemom unter Linux auch eine
Repeaterfunktion oder ein Codeumsetzer spielen.
Theoretisch kann ein Repeater oder Codeumsetzer auch im AVR sitzen, wenn
man es nicht mit der Anzahl der Codes übertreibt. (Spontane Idee, noch
nicht zuende gedacht).
Dazu muß ich aber lirc-ersatz-Daemon von Glotzi aufbohren und dazu
werden mit Sicherheit meine Programmierkenntnisse nicht reichen. (Hab ja
oben lediglich in den Quellen "rumgeschmiert" Sorry, Hugo).
Für den Einsatz innerhalb von Windows kann ich nicht viel sagen. Hugos
Demo hab ich hier testweise am Start, um der Intention des Programmiers
zu folgen,
aber für den realen Einsatz fehlen Motiv, Gelegenheit, Knowhow und
Wille.
@Pottisch:
Vielen Dank fürs Drüberschauen. Vielleicht können wir das ja zusammen
hinbekommen: Du bohrst deine Demo-DLL um ein SendButton + ein
6byte-Eingabefeld auf und ich seh zu, daß das auf der AVR-Seite korrekt
weitergegeben wird.
Andy P.
Jetzt wirklich ungetestet, da ich hier keinen Receiver rumliegen habe!
Im AVR Source ist nun IRSND eingebaut, per USE_IRSND deaktivierbar.
Das kompelierte HEX ist für den Atmega168(p), 12MHz.
Zum IR-Senden wird PD3 verwendet.
In IRSND nur die Standard Protokolle aktiviert.
Anbei auch eine Überarbeitung der Delphi Demo wo man nun einen IR Code
zum AVR schicken kann. (Auch nicht getestet)
Frage zwischendurch da ich IRSNd noch nie benützt habe:
Kann ich einfach eine alte Fernbedienung wegen der IR Diode
ausschlachten!?
Muss diese über einen Transistor geschaltet werden oder kann ich die
Diode direkt auf den Ausgang des AVRs hängen?
EDIT:
Jetzt habe ich ganz vergessen, dass dieses Projekt mit AVR Studio 5
bearbeitet wurde!
Hugo Portisch schrieb:> Kann ich einfach eine alte Fernbedienung wegen der IR Diode> ausschlachten!?
Könnte funktionieren.
> Muss diese über einen Transistor geschaltet werden oder kann ich die> Diode direkt auf den Ausgang des AVRs hängen?
Da die IR-LED gepulst betrieben wird, empfiehlt es sich, den Strom
zwecks Reichweitenmaximierung entsprechend hochzutreiben.
Ich benutze die folgende Schaltung für IRMP seit längerem erfolgreich:
http://www.mikrocontroller.net/articles/IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder
(Bild rechts)
Gruß,
Frank
Genau diese habe ich gesehen.
Ich habe nun eine alte Mouse geschlachtet. Da sind sogar 2+1 STK IR LEDs
drinnen.
Die 2 kleineren können so mit 20-100mA betrieben werden. Datenblatt gibt
es natürlich nicht da die Diode keine Beschriftung hat...
Aber meine Idee ist sowieso die IR-Dioden direkt am Empfänger
(Fernseher, Verstärker) anzubringen. Somit ist die Reichweite kein
Problem.
Aber ich weis nicht ob die Wellenlänge usw past - muss ich testen.
Bei 20mA brauche ich die Diode nur per Vorwiderstand an PD3 anbringen.
Der Atmega kann 40mA am Ausgang und somit könnte ich die 2 Dioden
einfach parallel hängen. Dann einfach die 2 Codes nacheinander
rausschicken. Der Harman Kardon Verstärker versteht das Protokoll vom
Toshiba Fernseher sowieso nicht ;)
Also ich habe jetzt die Durchsichtige IR LED von der Mouse angebracht.
Mit einem Vorwiderstand von 200 Ohm (also ~20mA) direkt am AVR Output.
Mit dieser IR LED komme ich auf jeden Fall 1 Meter. Weiter bekomme ich
die 2 IRMP AVRs leider nicht auseinander.
Also das nächste Mal die Mouse nicht einfach in den Müll schmeißen!
Da die IR LED auch Transparent ist sollte man sie ohne Probleme am Gerät
anbringen können das auch noch die Fernbedienung funktioniert.
Nun habe ich aber ein "Problem" beim NEC Protokoll:
Mit der Fernbedienung werden diese Codes empfangen:
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0001, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0002, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0003, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0004, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0005, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0006, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0007, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0008, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0009, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0000, Flags: 0x00
Wenn ich es per IRSND versende:
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0001, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0002, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0003, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0004, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0005, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0006, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0007, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0008, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0009, Flags: 0x00>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0000, Flags: 0x00
Man sieht, das statt 0x5F40 als Adresse 0x3F40 gesendet wird!?
Wenn ich als Adresse 0xFFFF eingebe kommt 0x7FFF an.
Das Command bei NEC scheint auch auf 0x00FF begrenzt zu sein. Wird halt
das Protokoll selber sein.
Wenn ich die Adressen durchteste:
>> Send: 0x0FFF, Receive: 0x0FFF>> Send: 0x1FFF, Receive: 0x1FFF>> Send: 0x2FFF, Receive: 0x1FFF>> Send: 0x3FFF, Receive: 0x1FFF>> Send: 0x4FFF, Receive: 0x2FFF>> Send: 0x5FFF, Receive: 0x3FFF>> Send: 0x6FFF, Receive: 0x3FFF>> Send: 0x7FFF, Receive: 0x3FFF>> Send: 0x8FFF, Receive: 0x4FFF>> Send: 0x9FFF, Receive: 0x5FFF>> Send: 0xAFFF, Receive: 0x5FFF>> Send: 0xBFFF, Receive: 0x5FFF>> Send: 0xCFFF, Receive: 0x6FFF>> Send: 0xDFFF, Receive: 0x7FFF>> Send: 0xEFFF, Receive: 0x7FFF>> Send: 0xFFFF, Receive: 0x7FFF
Meine Originale Fernbedienung vom Toshiba Fernseher sendet aber 0x5F40.
Beide Empfänger und Sender sind mit der letzten IRMP Version vom
20.09.2011 ausgestattet.
Hugo Portisch schrieb:>>> Send: 0x0FFF, Receive: 0x0FFF>>> Send: 0x1FFF, Receive: 0x1FFF>>> Send: 0x2FFF, Receive: 0x1FFF>>> Send: 0x3FFF, Receive: 0x1FFF>>> Send: 0x4FFF, Receive: 0x2FFF>>> Send: 0x5FFF, Receive: 0x3FFF>>> Send: 0x6FFF, Receive: 0x3FFF>>> Send: 0x7FFF, Receive: 0x3FFF>>> Send: 0x8FFF, Receive: 0x4FFF>>> Send: 0x9FFF, Receive: 0x5FFF>>> Send: 0xAFFF, Receive: 0x5FFF>>> Send: 0xBFFF, Receive: 0x5FFF>>> Send: 0xCFFF, Receive: 0x6FFF>>> Send: 0xDFFF, Receive: 0x7FFF>>> Send: 0xEFFF, Receive: 0x7FFF>>> Send: 0xFFFF, Receive: 0x7FFF
Kann ich leider nicht nachvollziehen. Unter Linux bekomme ich für jede
dieser Adressen auch diese Adresse wieder zurück, z.B.
1
./irsnd 2 5FFF 0001 0 | ./irmp
Ausgabe:
1
11111111111110101000000001111111 p = 2, a = 0x5fff, c = 0x0001, f = 0x00
Ich bekomme also das raus, was ich gesendet habe.
Bei Dir gehen im obersten Nibble die Bits kaputt, nämlich:
0 -> 0: 0000 -> 0000
1 -> 1: 0001 -> 0001 ???
2 -> 1: 0010 -> 0001
3 -> 1: 0011 -> 0001
4 -> 2: 0100 -> 0010
5 -> 3: 0101 -> 0011 ???
6 -> 3: 0110 -> 0011
7 -> 3: 0111 -> 0011
8 -> 4: 1000 -> 0100
9 -> 5: 1001 -> 0101 ???
A -> 5: 1010 -> 0101
B -> 5: 1011 -> 0101
C -> 6: 1100 -> 0110
D -> 7: 1101 -> 0111 ???
E -> 7: 1110 -> 0111
F -> 7: 1111 -> 0111
Bist Du Dir sicher bei den mit "???" markierten Stellen? Da hätte ich
nämlich eine 0 statt 1 am Ende erwartet. Dann wäre es eine Division
durch 2, d.h. eine Bitverschiebung.
So sieht es mir wie eine Verschiebung um eins, wobei das herausfallende
Bit mit dem nun obersten "geodert" ist. Kann es sein, dass das Senden
über V-USB da nicht ganz bit-transparent ist?
Vielleicht machst Du mal das Ganze auch mit dem Kommando, sende mal
0xFFFF als command.
EDIT: Quatsch, das Kommando ist bei NEC auf 0x00FF beschränkt, die
anderen 8 Bit sind zwecks Datensicherheit/Redundanz einfach invertiert.
Also Kommando zurück. :-)
Gruß,
Frank
Danke für deine Analyse!
Habe mir schon gedacht, dass da was mit den oberen Nibble vermurkst
wird.
Ich werde heute noch eine andere IR LED ausprobieren. Kann ja bei meiner
nicht sicher gehen ob es an dieser liegt. ;)
Die unteren 12 Bits werden jedoch ohne Fehler übertragen.
>> EDIT: Quatsch, das Kommando ist bei NEC auf 0x00FF beschränkt, die>> anderen 8 Bit sind zwecks Datensicherheit/Redundanz einfach invertiert.>> Also Kommando zurück. :-)>> Das Command bei NEC scheint auch auf 0x00FF begrenzt zu sein. Wird halt>> das Protokoll selber sein.
In IRSND habe ich nur das NEC Protokol reingenommen. Als ich dann auch
noch NEC16 und NEC42 reingenommen hatte funktionierte es fast gar nicht
mehr. Werde das heute nocheinmal probieren. Ein Debug kann ich leider
nicht machen somit kann ich mich nur darauf verlassen, dass mir IRMP die
richtigen Daten gibt und das 0x5F40 überhaupt stimmt.
Einen Fehler bei der Datenübergabe konnte ich nicht finden. Werde es mir
nocheinmal ansehen.
Nochmal zum IRMP Logging!
>> irmp_log (uint8_t val)
Mit wievielen startcycles ist den zu rechnen?
Ich bin der Überlegung nahe, den buf[700] von der irmp.c in die irmp.h
zu verlegen. Somit habe ich von meiner main.c auch darauf Zugriff.
Meine Idee ist statt der Ausgabe über den UART die Daten per USB zu
übertragen.
Wegen den 700 Bytes ist das aber nicht so einfach:
Zuerst füllt IRMP den buf.
Statt der Ausgabe auf den UART (cnt > ENDBITS) wird dem Host per
usbSetInterrupt bescheidgegeben das Daten verfügbar sind.
buf muss hier gelocked werden. Ansonsten würden weitere 700 Bytes nötig
sein.
Der Host holt sich dann über ein GetFeature selber die Daten vom Device
(Example VUSB: HID Data).
Nun kann der buf wieder freigeben werden um weitere Daten zu loggen.
Danach soll der Host die Daten in die '0' und '1' zerlegen um mit IRMP
kompatible zu sein.
EDIT:
>> for (i = 0; i < STARTCYCLES; i++)
STARTCYCLES ist ja eh eine Konstante (2) und somit muss ich die
beginnenden '0' nicht übertragen werden.
Hugo Portisch schrieb:> Mit wievielen startcycles ist den zu rechnen?
Das kommt aufs Protokoll an. Bei RECS80 sind es ganz wenige, bei NEC
sind es einige dutzend. Hier soll eigentlich nur verhindert werden, dass
kurze Störungen, die durchaus beim TSOP auftreten, nicht versehentlich
den Scan triggern.
> Ich bin der Überlegung nahe, den buf[700] von der irmp.c in die irmp.h> zu verlegen. Somit habe ich von meiner main.c auch darauf Zugriff.
Kannst Du natürlich machen. Ich würde den buf aber nicht verlagern,
sondern lediglich aus der log-Funktion rausziehen und damit global
machen, z.B. mit
1
uint8_tirmp_log_buf[DATALEN];
und dann in irmp.h ein:
1
externuint8_tirmp_log_buf[DATALEN];
> Meine Idee ist statt der Ausgabe über den UART die Daten per USB zu> übertragen.
Ja, schon klar :-)
> Wegen den 700 Bytes ist das aber nicht so einfach:
Oft reichen schon 256 Bytes aus, um einen kompletten Frame einzufangen.
> STARTCYCLES ist ja eh eine Konstante (2) und somit muss ich die> beginnenden '0' nicht übertragen werden.
Das ist richtig, spart 2 Bytes ;-)
Warum benutzt Du eigentlich für F_INTERRUPTS den Wert 20000? Gehe besser
mal auf 15000 runter. Sollte eigentlich reichen und auch den erzeugten
Code verkleinern, da dann teiweise 8-Bit-Counter (statt 16-Bit) reichen.
Vielleicht als Anregung:
Um den Fehler zu finden, würde ich erstmal checken, ob die
USB-Kommunikation bzgl. µC-Richtung korrekt funktioniert. Du könntest
einfach mal als Hack die IRMP_DATA-Struct an IRSND übergeben, welches
die über USB empfangenen Werte dann einfach wieder über USB
zurückschickt. Wenn das 1:1 funktioniert, tippe ich auf einen Fehler im
IRSND. Aber komischerweise kann ich den nicht reproduzieren...
Gruß,
Frank
Frank M. schrieb:> Warum benutzt Du eigentlich für F_INTERRUPTS den Wert 20000? Gehe besser> mal auf 15000 runter. Sollte eigentlich reichen und auch den erzeugten> Code verkleinern, da dann teiweise 8-Bit-Counter (statt 16-Bit) reichen.
Nur mal so zu Erinnerung: ich hatte schon mehrfach berichtet, dass der
Empfang mit INTERRUPTS != 10000 nicht funktioniert (zumindest bei mir).
Evtl. ist das beim senden genauso.
>> Vielleicht als Anregung:>> Um den Fehler zu finden, würde ich erstmal checken, ob die>> USB-Kommunikation bzgl. µC-Richtung korrekt funktioniert. Du könntest>> einfach mal als Hack die IRMP_DATA-Struct an IRSND übergeben, welches>> die über USB empfangenen Werte dann einfach wieder über USB>> zurückschickt. Wenn das 1:1 funktioniert, tippe ich auf einen Fehler im>> IRSND. Aber komischerweise kann ich den nicht reproduzieren...
Danke für den Tipp! Der war schnell umgesetzt.
1
#if USE_IRSND
2
}
3
elseif(DoWriteReport==SndIRCodeOut)// send received ir code from host
4
{
5
memcpy(&irmp_data,&data[1],sizeof(irmp_data));
6
//irsnd_send_data(&irmp_data, FALSE); // Send IR code out
7
SendINTData();
8
#endif
9
}
Es werden also die Daten vom Host gleich wieder 1:1 an den Host
zurückgeschickt ohne über IRSND oder IRMP:
Send: Protocol : IRMP_NEC_PROTOCOL, Address: 0xFFFF, Command: 0xFFFF,
Flags: 0x00
Receive: Protocol : IRMP_NEC_PROTOCOL, Address: 0xFFFF, Command: 0xFFFF,
Flags: 0x00
Und auch Danke für den Tipp mit irmp_log_buf!
Bin einfach kein C++ Programmierer...
>> Warum benutzt Du eigentlich für F_INTERRUPTS den Wert 20000? Gehe besser>> mal auf 15000 runter. Sollte eigentlich reichen und auch den erzeugten>> Code verkleinern, da dann teiweise 8-Bit-Counter (statt 16-Bit) reichen.
Das hatte ich nur drinnen, damit alle Protokolle auf dem AVR sind.
Heute habe ich aber gemerkt, dass eine Fernbedienung mit SIRCS nur gut
mit 10000 funktioniert. Bei 15000 kommt nichts gutes mehr raus.
>> Nur mal so zu Erinnerung: ich hatte schon mehrfach berichtet, dass der>> Empfang mit INTERRUPTS != 10000 nicht funktioniert (zumindest bei mir).>> Evtl. ist das beim senden genauso.
Tut leid. ich bin mit IRMP Artikel nicht so Uptodate ;)
Ich habe jetzt Sender UND Empfänger auf 10000 eingestellt.
Nun geht es:
Protocol : IRMP_NEC_PROTOCOL, Address: 0xFFFF, Command: 0x00FF, Flags:
0x00
Wenn nur IRSND auf 10000 war und IRMP auf 15000-20000. Ging es auch
nicht ohne Fehler. Wenn beide auf 10000 eingestellt sind geht es!
Gut das dass jetzt geht! Dann kann ich mir jetzt mit dem Logging
einbauen etwas Zeit lassen ;)
Ich bin auch noch auf keine Idee gekommen wie das mit IRSND am besten
umgesetzt werden soll:
Wie erkennt der AVR ob der PC nun läuft oder aus ist!?
Mein AVR Verstärker hat einen extra Code für Ein und Aus. Somit muss das
erkannt werden.
Dann wär es besser wenn die IR Codes für IRSND im EEPROM hinterlegt sind
damit IRSND gleich beim Einschalten des PCs auch die anderen Geräte
einschalten kann ohne erst auf ein Commando vom Host zu warten.
Dann bräuchte man auch noch eine variable Verzögerung (0-10 Sekunden
z.B) beim IRSND. Den ich muss dank HDMI meinen Fernseher nach dem PC
Ausschalten und beim Einschalten vor dem PC - sonst kommt es zu
Problemen. usw usw...
Danke vielmals! Wünsche noch schöne Feiertage!
Hugo Portisch schrieb:> Tut leid. ich bin mit IRMP Artikel nicht so Uptodate ;)
Das war hier im Thread nicht bei IRMP.
> Ich habe jetzt Sender UND Empfänger auf 10000 eingestellt.> Nun geht es:> Protocol : IRMP_NEC_PROTOCOL, Address: 0xFFFF, Command: 0x00FF, Flags:> 0x00>> Wenn nur IRSND auf 10000 war und IRMP auf 15000-20000. Ging es auch> nicht ohne Fehler. Wenn beide auf 10000 eingestellt sind geht es!
Ok, jetzt weiß ich wenigstens, dass es nicht an meinem Empfänger liegt,
sondern ein prinzipielles Problem ist. Es wäre schön zu wissen, woran
das liegt, da manche Protokolle nicht mit F == 10000 funktionieren.
Ging besser und schneller als ich mir gedacht habe!
Der Source ist noch nicht ganz sauber und es müsste auch in IRMP was
angepasst werden... ;)
Aber zuerst einmal ein Beispiel um Überprüfen zu können ob die Daten
überhaupt stimmen:
Die DataLength = buf_idx, sollten also Bits sein.
Die Daten sind der Inhalt von buf[DATALEN].
Stimmt das und wenn ja, was kommt Binär raus. Nur damit ich dann die
Umwandlung in den Binären String richtig mache ;)
EDIT:
Damit ich es gleich testen kann!
Hier ein Log von der OK Taste meiner Toshiba Fernbedienung. IRMP erkennt
sie nicht, einen Log bekomme ich aber:
1
ReportID : NewLogAvailable, 0x0B, Data Length (Bits) : 0x068C
Hugo Portisch schrieb:> Heute habe ich aber gemerkt, dass eine Fernbedienung mit SIRCS nur gut> mit 10000 funktioniert. Bei 15000 kommt nichts gutes mehr raus.
Wahrscheinlich gibt es da Timing-Probleme im Zusammenhang mit V-USB.
IRMP/IRSND funktionieren eigentlich ganz gut sowohl bei 10kHz, 15kHz und
auch bei 20kHz. Die Belastung des µCs steigt natürlich. Wahrscheinlich
kommen sich da irgendwann V-USV und IRMP in die Quere...
> Wenn nur IRSND auf 10000 war und IRMP auf 15000-20000. Ging es auch> nicht ohne Fehler. Wenn beide auf 10000 eingestellt sind geht es!
Ich benutze bei meinen Anwendungen meist 15kHz und habe diese Probleme
dabei nicht.
Gruß,
Frank
Hugo Portisch schrieb:> Stimmt das und wenn ja, was kommt Binär raus. Nur damit ich dann die> Umwandlung in den Binären String richtig mache ;)
Die IRMP-Log-Funktion schiebt nur Nullen und Einsen auf dem UART raus,
d.h. die Umwandlung in den "Binärstring" erfolgt noch auf dem µC. Bei
der USB-Übertragung könntest Du diese Umwandlung erst auf dem PC machen,
das schrumpft die zu übertragene Datenmenge auf ein Achtel.
> Hier ein Log von der OK Taste meiner Toshiba Fernbedienung. IRMP erkennt> sie nicht, einen Log bekomme ich aber:
Ich wandle das mal in einen "Binärstring" und schicke es anschließend in
den IRMP. Mal schauen, was da rauskommt.
Gruß,
Frank
Ich habe einen Deiner Logs mit folgendem C-Progrämmchen unter Linux in
einen "Binärstring" gewandelt:
1
#include<stdio.h>
2
3
staticvoid
4
hex2bin(intvalue)
5
{
6
inti;
7
8
for(i=0;i<8;i++)// send LSB first!
9
{
10
if(value&(1<<i))
11
{
12
putchar('1');
13
}
14
else
15
{
16
putchar('0');
17
}
18
}
19
}
20
21
int
22
main()
23
{
24
intvalue;
25
26
while(scanf("%02x",&value)==1)
27
{
28
hex2bin(value);
29
}
30
putchar('\n');
31
32
return(0);
33
}
Dieses dann compiliert als hex2bin und anschließend folgendes
aufgerufen:
./hex2bin <usblog.txt | ./irmp
Dabei kam dann folgendes raus:
1
00000010111111010100000010111111 p = 2, a = 0xbf40, c = 0x0002, f = 0x00
2
p = 2, a = 0xbf40, c = 0x0002, f = 0x01
(Die 2. Zeile ist ein NEC-Repetition-Frame)
Der Logbuffer hat also einen korrekten Inhalt. Was mir aber aufgefallen
ist, dass Du wohl den kompletten Log-Buffer sendest. Dadurch werden am
Ende noch jede Menge Nullen geschickt, die da nicht hingehören. Du
solltest daher noch die gefüllte Länge des Log-Buffers berücksichtigen.
Das ist insb. dann wichtig, wenn später der Logbuffer ein zweites Mal
verwendet wird, aber der Frame kürzer ist. Dann würdest Du noch den
verbliebenen (noch nicht überschriebenen) Rest des ersten Frames als
Datenschrott mitsenden.
Am Schluss habe ich den Frame getestet, den IRMP bei Dir nicht erkennen
konnte. Bei mir hat IRMP den Frame direkt erkannt.
Ausgabe:
1
00000010111111011000010001111011 p = 2, a = 0xbf40, c = 0x0021, f = 0x00
Danke!
Jetzt stehe ich aber etwas auf dem Schlauch!
Linux hab ich keines um es nachzustellen.
Aber soweit ich sehe wandelst du den Datenbuffer in einen Binären String
und lässt in gleich mit IRMP auswerten.
Wenn ich die Daten in einen Binären String Umwandle komme ich auf diesen
String:
Das ist jetzt vom ersten Log mit Command 0x01. Zusätzlich fehlt aber
noch am Anfang ein '00' (STARTCYCLES).
Stimmt diese Übersetzung? Kann IRMP diesen Binär String richtig
auswerten?
Kann es leider wegen fehlendem Linux selber nicht testen.
>> Was mir aber aufgefallen>> ist, dass Du wohl den kompletten Log-Buffer sendest. Dadurch werden am>> Ende noch jede Menge Nullen geschickt, die da nicht hingehören.
Oben die Logs sind zu lang, stimmt!
Der AVR sendet per Interrupt die Anzahl Bits (buf_idx) an den Host.
Danach holt sich der Host die Daten. Derzeit holt er sich dann immer 700
Bytes wegen der Buffergröße. Ich habe noch nicht Probiert, wie V-USB
darauf reagiert wenn ich jetzt nur 250 Bytes hole...
Der Buffer[700] wird aber dann mit buf_idx gekürzt. Und da ist mir oben
ein Fehler untergekommen. Ich habe alle Bits von buf_idx genommen.
eigentlich brauche ich aber nur: buf_idx - 1000 + 20 Bits.
Also aus 0x890 werden 0x4BC Bits. Dann sind hinten auch keine Nullen
mehr drann.
>> Am Schluss habe ich den Frame getestet, den IRMP bei Dir nicht erkennen>> konnte. Bei mir hat IRMP den Frame direkt erkannt.
Ich glaube da habe ich mir wieder selber ein Ei gelegt. Ich glaube meine
PowerOn Funktion hat den Code gesperrt...
Hugo Portisch schrieb:> Linux hab ich keines um es nachzustellen.
Es ging mir ja nur ums Prinzip.
> Wenn ich die Daten in einen Binären String Umwandle komme ich auf diesen> String:>
1
000000000000000000...
Dieser ist nicht korrekt. Du hast die Bytes mit MSB first in den
Binärstring gewandelt, Du musst es aber mit LSB first machen, deshalb
hatte ich oben in meiner Funktion hex2bin() extra den Kommentar gesetzt
;-)
Also: Erst das unterste Bit rausschreiben, das höchstwertigste erst am
Schluss eines jeden Bytes.
> Das ist jetzt vom ersten Log mit Command 0x01. Zusätzlich fehlt aber> noch am Anfang ein '00' (STARTCYCLES).
Ja, die beiden Nullen sollten auch noch mit rein. Und dann am Ende noch
ein '\n' um die Zeile abzuschließen. Wenn Du dann noch vor Deine eigenen
Kommentar-Ausgaben noch ein Kommentarzeichen '#' setzt, wäre es perfekt.
Siehe dazu auch die Beispiel-Log-Dateien unter IR-Data/*.txt
> Kann es leider wegen fehlendem Linux selber nicht testen.
Eine irmp.exe für Windows ist im IRMP-Paket dabei, Du kannst das also
testen mit
irmp.exe <irgendwas.txt
bzw.
irmp.exe -v <irgendwas.txt
> Der Buffer[700] wird aber dann mit buf_idx gekürzt. Und da ist mir oben> ein Fehler untergekommen. Ich habe alle Bits von buf_idx genommen.> eigentlich brauche ich aber nur: buf_idx - 1000 + 20 Bits.> Also aus 0x890 werden 0x4BC Bits. Dann sind hinten auch keine Nullen> mehr drann.
Prima.
> Ich glaube da habe ich mir wieder selber ein Ei gelegt. Ich glaube meine> PowerOn Funktion hat den Code gesperrt...
:-))))
Gruß,
Frank
Hello,
Can someone confirm that the ON/OFF function is working with an RC6
remote? (Generic PC-MCE remote with RC6 code).
All the keys of the remote work as they should, but the ON/OFF button
doesn't do nothing.
By using the demo program I can see that the power code is inserted in
the EEPROM (Address 0x000F, Command 0x040c) but still it won't do
nothing.
Just for testing, to be sure that the circuit or the uC aren't damaged,
I've tried with an RC5 remote with the default .hex file and it works!
Is it something else that should be enabled in the configuration besides
enabling the RC6 code?
>> Is it something else that should be enabled in the configuration besides>> enabling the RC6 code?
No, I don't think so.
But I remember that there where some problems with RC6 and IRMP because
of missing logs/hardware. I don't know if this got already fixed.
You can try to clear the trained poweron code by the options dialog of
the dll. After this again the first decoded IR code will be stored as
poweron code. Or you deaktivate the PowerOn function and check if the
received IR code is changing when pressing the button multiple times on
the remote.
If this will not help:
I currently working on implementing the IR log function by USB.
For this I uploaded a beta for Atmega168(p) and Atmega8.
Flash this HEX file on the device and use the new included
'USB_IR_Remote_Receiver_Demo.exe' from the archive.
Each received IR code will be stored in a text file 'IRMP_Log.txt'
located in the same folder like the exe. This text file can be decoded
by 'irmp.exe' (included in the IRMP package) itself:
>> D:\Eigene Datein\VB\AVR_IRMP>irmp.exe <IRMP_Log.txt>> ------------------------------------------------------------------->> # OK>> ------------------------------------------------------------------->> # 29.12.11 15:35:55>> 00000010111111011000010001111011 p = 2, a = 0xbf40, c = 0x0021, f = 0x00
Please remember that the poweron function will block the trained code.
So may clear the trained code and use another dummy button on the remote
- just for logging.
I can't work on my receiver anymore as I've finally installed it into my
HTPC, so I'm sorry but I can't try the new hexfile.
After a few more tries I gave up trying to make the RC6 PowerOn function
work, so I programmed RC5+RC6 codes and currently use another remote
(RC5) to power ON/OFF the HTPC.
But I can tell you that by using the dll it was impossible to change the
PowerOn code: Once you erased the RC6 PowerOn code it wouldn't accept it
anymore.
Ich habe nun den Artikel USB IR Remote Receiver wieder etwas
überarbeitet.
Neu: IRMP Logging über die USB Schnittstelle.
Es können nun die Rohdaten des IR Signals auch über USB (vorher nur über
RS232) geloggt werden. Dazu einfach den Source mit IRMP_LOGGING = 1 neu
kompilieren.
Ich hoffe ich bekomme nicht zu viel haue von Frank M. weil ich sein IRMP
etwas "plump" umgeschrieben habe... ;)
Hallo Portisch!
Ich kenn dich aus dem DVBViewer Forum. Ich hab selbst ein Inputplugin
(X10) für mehrere Hosts geschrieben. DVBViewer und Girder sind OK. Für
EventGhost fehlten mir bisher die Informationen. Die wollte ich mir nun
aus der Source von USB_IR_Remote_Receiver.dll raussuchen. Die ist im
Download nicht dabei?
Wenn du die nicht als Ganzes freigeben möchtest wäre ich dir dennoch für
ein par Hints dankbar.
Grüße erwin
erwin@DVBViewer schrieb:> Für>> EventGhost fehlten mir bisher die Informationen. Die wollte ich mir nun>> aus der Source von USB_IR_Remote_Receiver.dll raussuchen. Die ist im>> Download nicht dabei?
Hallo erwin!
Nein, der Source der DLL ist nicht mit dabei. Die DLL selber hat aber
auch nichts mit EventGhost zu tun. Dafür ist das Plugin "__init__.py"
zuständig.
Dieses Plugin lädt die DLL wie ein normales Programm über die
"InitPAnsiChar" Funktion. Über eine Callback Funktion werden die Daten
an EventGhost übergeben. Die InitPAnsiChar und InitNative sind für
externe/andere Programme damit sie die DLL verwenden können. (Die
Funktionen sind im PDF beschrieben)
Dieses Plugin habe ich selber aus verschiedene Plugins die bei
EventGhost dabei waren zusammen gebaut...
Hugo Portisch schrieb:> Neu: IRMP Logging über die USB Schnittstelle.> ...> Ich hoffe ich bekomme nicht zu viel haue von Frank M. weil ich sein IRMP> etwas "plump" umgeschrieben habe... ;)
Hast Du das mit Frank abgestimmt, damit er die Änderungen übernimmt?
Jetzt kann man den IRMP-Teil im Receiver nicht mehr so ohne weiteres via
DropIn-Update aktualisieren.
Prinzipiell ist das USB-Logging eine gute Sache, mich stört aber der
IRMP-Fork.
Dank dir für die schnelle Antwort.
Ich schicke mal voraus: Python ist total neu für mich.
Also ich hab dich jetzt mal so verstanden: EventGhost besteht nicht auf
speziell exportierte Funktionen wie etwa DVBViewer und Girder. Das
steckt in der "__init__.py". ???
> Über eine Callback Funktion werden die Daten an EventGhost übergeben.
???
Bei einem DVBViewer-Input-Plugin wird ja die Adresse einer
Callbackfunktion vom DVBViewer durch den Aufruf einer speziellen
Funktion die die DLL exportieren MUSS seitens des DVBV übergeben. Wie
ist das bei EventGhost?
erwin
Dirk W. schrieb:> Hast Du das mit Frank abgestimmt, damit er die Änderungen übernimmt?
Hugo hatte mich wg. dem Logging bereits vor Weihnachten angeschrieben,
ich hatte aber über die Feiertage keine Zeit, ihm zu antworten. So hat
er es erstmal allein eingebaut, um es überhaupt schon mal zum Laufen zu
bekommen.
Ich werde mir Hugos Änderungen näher anschauen und dann in Abstimmung
mit ihm versuchen, eine allgemeinere Lösung für das USB-Logging zu
finden, so dass der Source weiterhin einheitlich bleibt.
> Jetzt kann man den IRMP-Teil im Receiver nicht mehr so ohne weiteres via> DropIn-Update aktualisieren.
Das wird demnächst wieder gehen, keine Sorge.
> Prinzipiell ist das USB-Logging eine gute Sache, mich stört aber der> IRMP-Fork.
Es wird keinen Fork geben. Hugo hat da nichts im Alleingang gemacht.
Betrachte Hugos Implementation des Loggings über USB erstmal als ersten
Prototyp.
Gruß,
Frank
P.S.
Ich verfolge diesen Thread sowieso, bin daher immer auf dem Laufenden
:-)
Frank M. schrieb:> Es wird keinen Fork geben. Hugo hat da nichts im Alleingang gemacht.> Betrachte Hugos Implementation des Loggings über USB erstmal als ersten> Prototyp.>> Gruß,>> Frank
Danke!
Genau so war es gedacht!
Ich habe um es erst einmal überhaupt umzusetzen etwas unschön so
umgebaut.
Ist nicht Sinn der Sache das es so bleibt.
Mit einem neuem IRMP_LOGGING_USB Kompilerswitsch in der irmpconfig.h
könnte man das schon gut lösen. Aber wie gesagt - ich bin hier nicht der
richtige um das zu Entscheiden (auch zwecks fehlendem können)
@erwin
> Ich schicke mal voraus: Python ist total neu für mich.
War es für mich auch. war eine ganz schöne Bastelei um das Plugin für
EventGhost zu schreiben.
Beim Start von EventGhost werden alle Plugins in den Unterordnern
gesucht ("__init__.py"). Je nach optionen wird dann das Plugin geladen
oder halt nicht.
Dank Dir nochmal Hugo!
Mein Inputplugin läuft jetzt u.a. auch mit EventGhost. Mit den richtigen
Hinweisen war das dann auch nicht mehr allzu schwer. Der Punkt war halt
dass EventGhost nicht selbst - wie DVBV oder Girder - eine
Calbackfunktion installlieren so dass man die Signatur der
Installationsfunktion kennen muss und entsprechend in der DLL benutzen
muss - sondern das dies das Script "__init__.py" tut, welches man selbst
erstellt, d.h. man kennt alle benötigten Signaturen und braucht evt.
auch die DLL nicht mehr zu verändern sondern kann z.B die bereits für
den DVBV bereitgestellte Funktion "SetCallback" weiter nutzen.
Hallo,
ich habe schon länger nach einer Lösung gesucht um meinen guten alten
seriellen PIC12c509 IR-Empfänger zu ersetzen der schon gut 12 Jahre alt
ist. Dabei bin ich nun hier über das geniale Projekt gestolpert,
allerdings hatte ich mir in den Kopf gesetzt das ganze auf
minimalistischer Hardware laufen zu lassen. Das könnte ggf. auch für
andere interessant sein, deshalb habe ich das mal zusammengeschrieben.
Ich habe Hugos aktuelle Quellen angepasst (USB Infrarot Receiver V1.8
vom 02.01.2012), so dass sie sich für einen ATtiny85 kompilieren lassen.
Viel war wirklich nicht mehr zu tun - was gefehlt hat war neben kleinen
Änderungen durch die andere Hardware die Synchronisierung für V-USB, das
wollte zunächst einfach nicht funktionieren bis ich über George
Ruinellis Seite gestolpert bin, er hat hier beschrieben was für den
ATtiny fehlt:
http://www.ruinelli.ch/how-to-use-v-usb-on-an-attiny85
Vorhanden war bereits ein "USB-Dongle" welches bislang nur mal zur
Belustigung von Kollegen diente ("Capslocker"), daran habe ich lediglich
einen Infrarotempfänger angelötet. Der Schaltplan ist als Bild im
angehängten Zip enthalten, das soll nicht als Referenzdesign dienen,
siehe Warnungen :)
Eckdaten:
* der ATtiny85 ohne Quarz mit V-USB, mit dem internen Oszillator
bei 12.8MHz
* IRMP mit 15k Interrupts/s (andere Werte habe ich nicht getestet)
Im Gegensatz zur Originalhardware nicht vorhanden sind derzeit:
- Bootloader
- Remote-Wakeup
Getestete Fernbedienungen (IR-Protokolle):
* Standard Hauppauge (RC5)
* Panasonic TV (KASEIKYO)
* mit Tevii Sat-Karte gelieferte Fernbedienung (NEC)
PC-seitig auf einem Linux-PC in Verwendung:
* irmplircd von Dirk W. als 1:1-Ersatz für den original lircd
* lirc-clients: VDR und lircrc/irexec
Das ganze läuft hier seit zwei Tagen störungsfrei und hat meinen
seriellen Empfänger somit einfach 1:1 ersetzt.
Ein paar Warnungen zum Schaltplan:
- Der ATtiny läuft bei ~3.6V / 12.8MHz außerhalb der Atmel-Spec, die
Spannungsreduktion mit zwei Dioden statt Verwendung von Z-Dioden in
D+/D- ist eine Notlösung weil ich schlicht keine hatte als ich das
zusammengelötet habe - aber lieber die USB-Spec als die Atmel-Spec
erfüllen wollte um meine restliche Hardware zu schützen. Status:
"works for me", keine Garantie.
- aktuell benutze ich statt dem beschriebenen TSOP1738 einen unbekannten
angesteckten IR-Empfänger (mit 1.2m Kabel und 3.5mm Klinke, wurde bei
einer Sat-Karte mitgeliefert). Meinen letzten TSOP1738 habe ich mir
aus Versehen zerschossen, und zerschneiden möchte ich das Kabel des
Empfängers nicht, deshalb ist der Chip unbekannt. Der IR-Empfänger ist
aber ebenfalls Active Low und die Schaltung sollte damit auch
problemlos mit den TSOPxxxx laufen
Die im Zip-File enthaltenen Dateien können entweder einfach so 1:1 in
Hugos Originalsourcen kopiert werden und lassen sich dort mit einem
"make" von avr-gcc übersetzen, ein kleines aus V-USB übernommenes
Makefile ist vorhanden. AVR Studio benutze ich nicht, für meine Zwecke
war das bislang nie nötig, ich verwende hier einen Debian-PC mit avr-gcc
V4.3.5 und avr-libc v1.6.8.
Ich habe mir Mühe gegeben die Änderungen minimalinvasiv durchzuführen
und frage über Direktiven ab für welchen Controller kompiliert wird, der
Source übersetzt sich hier genauso wenn ich atmega8 / 12MHz einstelle,
die wenigen Änderungen könnten also theoretisch auch im
Originalsourcecode übernommen werden falls Interesse besteht -> Hugo,
ich weiss nicht was Du davon hälst.
Das Verzeichnis "libs-device" stammt aus den aktuellen V-USB - Quellen.
Da der AtTiny85 nur PORTB besitzt ändert sich natürlich auch die Config,
hier bin ich mir auch nicht sicher ob es Sinn macht so etwas über
Direktiven abzufragen, ich habe es jetzt mal so umgesetzt. Feedback ist
gerne gesehen.
Gruß,
Lars
Lars, coole Sache und danke für dein Feedback. Besonders interessant
finde ich, dass bei dir der Empfänger auch mit 15k HZ läuft. Den
ruinelli Link zum Sync sollte man sich wohl näher anschauen, evtl
klappts dann auch künftig mit F != 10k HZ
Lars Bürding schrieb:> Originalsourcecode übernommen werden falls Interesse besteht -> Hugo,>> ich weiss nicht was Du davon hälst.
Das Problem dabei ist, dass ich es selber nicht testen kann. Wenn ich
also was ändere kann ich nicht garantieren ob's auch geht ;)
Wenn ich wieder etwas Zeit habe werde ich mir die Änderungen ansehen und
wahrscheinlich auch übernehmen. Wegen den IRMP_Logging steht sowieso
noch eine Änderung aus.
Generell arbeite ich im Moment mit dem Atmega168, da der Atmega8 eh
schon zu wenig Speicher für IRMP mit allen Protokollen hat.
Aber ATtiny (besonders weil ohne Quarz) ist eine gute Alternative!
Hallo!
Da ich das erste mal einen µC programmiere, frag ich lieber noch einmal
genauer nach:
Ich habe einene Atmega168 in Verwendung - im Paket ist aber nur die
Datei für den Atmega168P enthalten. --> Muss daher jetzt neu kompiliert
werden? Was ist dabei zu beachten? Welche Fuses muss ich bei mir setzen?
Also die Firmware hab ich nun aufspielen können.
Leider habe ich noch ein Problem:
Die Software/das Plugin empfängt keinen einzigen IR-Code (mehrere FB
probiert)! Die LED blinkt aber auf und signalisiert damit, dass etwas
empfangen wird. Kann es trotzdem an der IR-Empfängerdiode liegen?
Ich habe die "SFH5110-36" in Verwendung.
Willi schrieb:> Leider habe ich noch ein Problem:>> Die Software/das Plugin empfängt keinen einzigen IR-Code (mehrere FB>> probiert)! Die LED blinkt aber auf und signalisiert damit, dass etwas>> empfangen wird. Kann es trotzdem an der IR-Empfängerdiode liegen?>> Ich habe die "SFH5110-36" in Verwendung.
Äh... welche LED?
Im HEX-File was im Paket dabei ist sind nur die Standard Protokolle in
IRMP aktiviert.
Um zu überprüfen ob wirklich IR Signale reinkommen kannst du auch die
Hexdatei "_with_IRMP_Logging" verwenden.
Hier werden alle empfangene IR Signale dann Roh an den PC gesendet egal
ob das Protokoll in IRMP mit drinnen ist oder nicht.
Um die Daten zu empfangen muss der Optionen Dialog der DLL geöffnet
sein.
Die Textdatei kannst du dann einfach hier anhängen.
http://www.mikrocontroller.net/articles/USB_IR_Remote_Receiver#IRMP_Logging
Hugo Portisch schrieb:> Für die Led-Anzeige müsste es reichen wenn du die Kathode der Led an dem> IR Dioden Ausgang hängst. Die Led Anode über einen Widerstand (~560-1000> Ohm) auf +5V hängen. Den Widerstand halt nicht zu gering auswählen> ansonsten kann es zu Problemen der Stromversorgung über den USB-Port im> Ruhezustand/Standby kommen.
Hallo!
Ich habe nach dem darunter geposteten Lochrasterlayout aufgebaut mit
einer LED, die den Empfang anzeigt. Mein LED Vorwiderstand ist 1,2k.
Also auch mit einem Tsop 4838 ergibt sich das gleiche Bild. Es wird
etwas empfangen - IRMT loggen geht - aber nicht vom Plugin erkannt /
übersetzt und an Eventghost oder DVBViewer weitergeleitet. Ich habe eine
Fernbedienung einer TechnoTrend SatKarte, Technisat Receiver, Philips TV
und Philips Hifi-Anlage probiert - nix.
> Im HEX-File was im Paket dabei ist sind nur die Standard Protokolle in> IRMP aktiviert.
Ach ich dachte bei dem HEX des atmega 168 ist alles aktiviert weil der
einen größeren Speicher hat? Wenn ich die irmpconfig.h in AVR Studio 4
angepasst habe, muss ich danach "main.c" öffnen und neu kompilieren
(sorry, hab vorher noch nie etwas mit µC gemacht...)? Kann ich AVR
Studio 4 nehmen oder muss es die 5 sein?
Anbei noch ein IRMP Logfile (TT steht für Technotrend und die Zahlen für
die Nummerntasten)
Dann hat das USB Logging schon mal was gebracht! ;)
Ich habe dein IRMP_Log.txt durch die "irmp.exe" gejagt und raus kommt
das:
>> C:\Temp\löschen>irmp.exe <IRMP_Log.txt>> ------------------------------------------------------------------->> # TT1>> ------------------------------------------------------------------->> # 17.01.12 21:23:39>> 0>> 1010100001>> 1110101000011 p = 7, a = 0x0015, c = 0x0003, f = 0x00
Also Protokoll 7 == RC5!
Das ist Standardmäßig im Receiver nicht mit drinnen! Ich hänge dir
einmal das HEX File für den Atmega168(p) an wo RC5 mit drinnen ist.
Mit AVR Studio v5 kann man sich ansonsten schnell und einfach das HEX
Files selber erstellen. Bei der v5 braucht man kein extra WinAVR mehr.
Der Download ist halt dann um einiges größer. Programmieren und Debuggen
geht aber um einiges besser als bei der v4.
Also einfach v5 installieren und fertig!
mfg
Portisch
Vielen Dank!
Endlich funktioniert alles!
Aber warum sind eigendlich RC5 und die ganzen anderen Protokolle
standardmäßig deaktiviert bei dem atmega168p? Am Speicher kanns ja nicht
liegen ;)
Hallo!
Ich hab leider noch ein Problem mit der PowerOn Funktion! Sie
funktioniert einfach nicht.
Im Plugin kann ich problemlos eine Taste anlernen (bei mir ein
RC5-Code). Ich habe eine LED verbaut, die den Empfang von IR-Signalen
anzeigt - und die blinkt munter - also wird die Schalung auch wenn der
PC aus ist mit Spannung versorgt. Als Optokoppler verwende ich den KB817
von Reichelt mit einem Vorwiderstand von 560 Ohm. Der Optokoppler hängt
an PC5 des Atmega168p.
Kann ich den Fehler noch irgendwie eingrenzen? Könnte ich am Ausgang PC5
mit dem Multimeter was sinnvolles messen oder ist die Schaltzeit zu kurz
dafür?
Wenn ich Spannung kennen würde, die der Atmega an den Optokoppler
anlegen müsste, könnte ich ja noch testen ob es am Optokoppler hängt...
Also da der AVR mit 5V versorgt wird, werden natürlich auch 5V an den
Optokoppler ausgegeben. Bei 560 Ohm also ~9mA.
Die Schaltzeit ist um ca. 250ms. Das wirst du mit einem Messgerät nicht
sehen. Ich habe ja einen Optokoppler im DIL Gehäuse und ich habe zum
Testen einfach eine LED statt den Optokoppler eingesetzt.
Dann kann man schön kontrolieren ob es geht.
Der KB817 scheint SMD zu sein, aber man kann ja trotzdem testweise
einfach eine LED statt den Optokoppler an Pin 1 u 2 anlöten.
Wenn es noch immer nicht geht am besten einmal eine andere Fernbedienung
die nicht RC5 hat probieren!
Auch ist die Polarität am Optokopplerausgang wichtig da es sich um einen
Transistorausgang handelt.
Ich glaube, dass am Mainboard beim PowerOn 5V durchgeschaltet werden.
Die 5V müssen an Pin 4 des KB817 liegen. Der Pin3 ist dann der
geschaltete Ausgang des Optokopplers.
chris16 schrieb:> Ist es möglich auch das MCE Protokoll in der nächsten Version mit auf zu> nehmen.> Wäre toll wenn das ohne viel aufwand gehen würde.
Soweit ich das Verstehe wird das nicht so einfach gehen. Es müsste ein
Programm her, dass die IR Signale für die richtigen MCE Befehle
auswertet und sozusagen übersetzt.
Ich glaube die MCE Befehle sind globale Befehle.
Die DLL muss aber von einem Programm geladen werden...
Ich habe aber keine MCE Fernbedienung und kann nichts probieren.
Ich hoffe du meinst auch den USB IR Remote Receiver. Andere Empfänger
können von der DLL sowieso nicht verwendet werden.
Werden die Tastendrücke der Fernbedienung überhaupt erkannt!? Soweit ich
das jetzt rausgefunden habe sollte das IR Protokoll das RC5 und/oder RC6
sein.
Hugo Portisch schrieb:> Ich hoffe du meinst auch den USB IR Remote Receiver.
Ja ich meine den hier Beschriebenen USB IR Remote Receiver,den ich mir
aufgebaut habe.
An dieser Stelle möchte ich mich für dieses super Projekt Bedanken.
Auch für Anfänger wie ich es bin gut nachzubauen.
Das was ich im Netz gefunden habe soll das MCE Protokoll über RC5/RC6
anzusteuern sein,leider funktionieren die RC5/RC6 Protokolle die jetzt
schon dabei sind nicht.
Ich steuer mein J.River MediaCenter das eigendlich MCE empfangen kann
über Eventghost.
Hallo Hugo Portisch,
bis jetzt bin ich immer so vorgegangen
1. Code in FB gesetzt (Medion FB)
2. DLL Demo gestartet um zu sehen welches Protokoll gesendet wird
(RC5/RC6 oder aber RC6a)
3. J.River MediaCenter geöffnet um zu sehen ob etwas empfangen wird
In wie weit würde mir ein Loggin da weiter helfen das ist mir nicht ganz
schlüssig?
Ok, schön langsam kommt Licht in die Sache.
Also kannst du mit der DLL Demo die IR Befehle der Fernbedienung
auswerten!?
Wenn IRMP keine Daten ausspuckt kann man mit dem Log den RAW IR Code
auswerten und schauen ob ein Decoden mit IRMP überhaupt möglich ist.
Die DLL selber unterstützt aber das J.River MediaCenter nicht.
Jedoch habe ich gesehen, dass das Mediacenter Inputplugins unterstützt.
Mal sehen ob da was möglich ist...
Wenn ich im Code IRMP Logging = 1 setze,habe ich natürlich die
Möglichkeit jeden Tastendruck der FB auszuwerten.
Aber eine Hilfe für J.River ist das nicht,da ich keine FB + Empfänger
für das senden von MCE Code habe.
Aber wie Du oben schon geschrieben hast besitzt der J.River ein MCE
Plugin der auf jeden Fall dieses Protokoll empfangen kann.
Ich kenne mich zwar nicht aus aber wenn der Aufwand nicht zu groß ist
wäre es Möglich in der bestehenden Firmware ein MCE Protokoll
einzubinden.
Ich hoffe ich habe mich nicht allzu umständlich Ausgedrückt,Danke
@Hugo: hättest du das gleich gesagt. ich hab hier noch eine
USB-Stick-große Leerplatine, alles mit THT-Bauteilen zum Dranrumbasteln.
Ich habe das so angelegt, daß man auch einen ISP hat, den USB-Anschluß
gegen eine 4pol. Buchsenlseite für
direktes-auf-den-USB-Port-des-Mainbords-stecken usw. IRsend und
PWR-Switch kann da natürlich auch bedient werden.
Allerdings sind die einzelnen Kompenenten an anderen Pins, sodaß man vor
Compilieren noch ein paar Config-Werte korrigieren muß.
Andy P.
also ich hab jetzt mal ein bisschen rumprobiert aber entweder ist es
schon zu spaet bzw. ich bin zu doof oder ich hab hier 1-2 bugs gefunden.
beim parsen der version (vermutlich direkt in der DLL) kommt teilweise
bitmuell mit. ich vermute jetzt einfach mal das nicht oder falsch
terminiert wird (\0). aber das ist mir eher so nebenbei aufgefallen und
eigentlich auch nicht weiter schlimm.. wollte es nur loswerden :P
das zweite ist:
beim ersten start sah ich einen bereits gespeicherten IR code fuer
poweron. diesen habe ich geloescht und wollte dann halt die
entsprechende taste meiner FB dafuer verwenden aber weder im settings
dialog noch ausserhalb wird die taste gespeichert. habe sowohl die
console app als auch die C# und delphi app getestet. (vllt. liegt auch
hier ein problem in der DLL vor?)
weder "Read Trained IR Code" noch "Received IR Code" zeigen irgendwas
an.
das empfangen scheint ansich aber zu funktionieren da ich im settings
dialog nach den descriptions gefragt werde und die dann auch im log
auftaucht.
ich bin mir jetzt nicht 100% sicher ob es vllt. doch an "mir" liegt
daher meine frage jetzt: kann das jemand anderes azch
bestaetigen/reproduzieren?
so.. kleines update:
das problem mit den IR codes hat sich erledigt.
F_INTERRUPTS muss fuer meine wunsch FB 15000 sein, nicht 10000. %)
btw. es gibt updates fuer IRMP und V-USB, scheint beides bei mir zu
laufen so far.
es waere auch toll wenn du/wir das IRMP_LOGGING unberuehrt lassen
wuerden und alternativ IRMP_LOGGING_USB benutzen wuerden, so kann man
auch weiterhin UART o.ae. benutzen. dadurch wird die firmware ja nicht
groesser und ich denke auf dauer wird das maintainen/updaten auch
einfacher.
ich hab das ganze jetzt mal ein bisschen unter linux getestet und habe
festgestellt das:
sobald ich bestimmte tasten druecke (z.b. 4, 5 u. 6, habe alle noch
nicht getestet) wird das device aus unerklaerlichen gruenden resetet.
<snip>
</snip>
ich habe das ganze mit 4 fernbedienungen getestet, alle 4 haben
unterschiedliche protokolle, sowohl mit als auch ohne USB autosuspend.
das ist sicherlich nicht gewollt/normal allerdings bin ich mir jetzt
nicht sicher ob es an diesem prokelt oder an V-USB liegt. IRMP wuerde
ich jetzt erstmal ausschliessen. auch mit den neusten versionen von IRMP
und V-USB laesst sich das ganze reproduzieren, getestet mit kernel
3.3.1. mit und ohne bootloader getestet.
FUSE bits:
High: 0xD4
Low: 0xFF
Extended: 0xF8
die schaltung entspricht "ganau" der des projekts ausser das ich einen
6pin header (AVR ISP) zum programmmieren verwende anstatt ponyprog/LPT.
irgendwelche ideen?
Ich kann das Problem mit dem USB-Disconnect bei mir hier auch
reproduzieren. Aber nur, wenn irmplircd nicht läuft:
1
Apr 15 22:14:40 server kernel: usb 3-5.5: USB disconnect, device number 5
2
Apr 15 22:14:41 server kernel: usb 3-5.5: new low-speed USB device number 11 using ehci_hcd
3
Apr 15 22:14:41 server kernel: usb 3-5.5: New USB device found, idVendor=16c0, idProduct=05df
4
Apr 15 22:14:41 server kernel: usb 3-5.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
5
Apr 15 22:14:41 server kernel: usb 3-5.5: Product: USB IR Remote Receiver
6
Apr 15 22:14:41 server kernel: usb 3-5.5: Manufacturer: www.dvbviewer.info
7
Apr 15 22:14:41 server kernel: generic-usb 0003:16C0:05DF.0008: hiddev0,hidraw4: USB HID v1.01 Device [www.dvbviewer.info USB IR Remote Receiver] on usb-0000:04:06.2-5.5/input0
falls es hilft:
es werden genau 3 keypress events akzeptiert danach gibt es nen komplett
reset vom device.
*edit
bevor ich es vergesse..
ganz ohne IRMP passiert das nicht. ich werde jetzt noch versuchen
herauszufinden warum und vorallem wo genau der fehler liegt.
Christian Ruppert schrieb:> falls es hilft:> es werden genau 3 keypress events akzeptiert danach gibt es nen komplett> reset vom device.
Dann liegts wohl daran, daß die Events nicht abgeholt werden und
irgendwas intern überschrieben wird.
Dirk W. schrieb:> Christian Ruppert schrieb:>> falls es hilft:>> es werden genau 3 keypress events akzeptiert danach gibt es nen komplett>> reset vom device.>> Dann liegts wohl daran, daß die Events nicht abgeholt werden und> irgendwas intern überschrieben wird.
also ich habe das nochmal mit dem irmplcd (hidraw) getestet und auch
dann passiert das.
und meine vorherige aussage muss ich nochmal korrigieren:
auch bei einem oder zwei keypress events passiert das, dauert aber nen
moment und wenn ich das richtig sehe auch nicht immer...
es liegt definitiv an:
usbSetInterrupt(&replyBuf[0], sizeof(irmp_data) + sizeof(uchar));
in void SendINTData(void) der main.c
und es muesste normal betriebssystem unabhaengig sein, d.h auch unter
windows muesste es zu diesem fehler kommen.
Dirk W. schrieb:> Dann liegts wohl daran, daß die Events nicht abgeholt werden und> irgendwas intern überschrieben wird.
Richtig! Es liegt an der V-USB Funktion: usbInterruptIsReady
Ändert einmal das in der SendINTData ab:
1
while(!usbInterruptIsReady())usbPoll();// check if USB int is ready
2
usbSetInterrupt(&replyBuf[0],sizeof(irmp_data)+sizeof(uchar));// send ReportID + IR data
Neu:
1
usbSetInterrupt(&replyBuf[0],sizeof(irmp_data)+sizeof(uchar));// send ReportID + IR data
Das "while (!usbInterruptIsReady()) usbPoll();" überprüft ob der
USB-Interrupt vom Host PC bereit ist. Je nach Datenmenge * Durchläufe
bleibt es hier dann hängen wenn die Daten nicht abgeholt werden ->
Watchdog -> Reset.
Bei diesem Fall sind es ca. 3 Durchläufe, dann hängt es.
Wenn man das Warten auf den Interrupt deaktiviert werden die Daten
einfach gesendet. Egal ob der Host sie abholt oder nicht -> Datenverlust
möglich, aber es sollte hier dann nicht mehr hängenbleiben. Der
Datenverlust ist jetzt hier nicht so wichtig.
Das ist mir schon länger Zeit aufgefallen und ist auch schon längst
geändert worden - aber halt noch nicht offiziel hochgeladen!
Hallo zusammen,
ich war ja seit längerem dabei eine Host-Anwendung zu schreiben mit dem
Ziel den Empfänger (um einige Funktionen erweitert) in MediaPortal
einzubinden. Je umfangreicher die Firmware wurde, desto öfter tauchten
Probleme auf, d.h. die Hardware wurde nicht (mehr) richtig von Windows
erkannt, funktionierte nur eine zeitlang und ähnliches.
Daher habe ich beschlossen den ATMEGA168 samt V-USB durch einen
STM32L15x mit USB-Device-Funktionalität in Hardware zu ersetzen. Zu
diesem Zweck habe ich ein kleines Adapterplatinchen mit dem STM32
entwickelt, das statt dem MEGA168 auf die vorhandene Platine bestückt
wird. Die restliche Hardware kann also gleich bleiben. Mit der Software
möchte ich demnächst beginnen.
Falls jemand das Ganze mit dem MEGA168 weiter entwickeln will habe ich
einen älteren Stand der C#-Host-Anwendung angehängt, die mit Hugo's
Firmware läuft und gänzlich ohne seine DLL auskommt und stattdessen nur
Windows-Funktionen nutzt. Soweit hat das immer recht gut funktioniert,
da ich das aber aus einem älteren Stand rekonstruiert (neue
Funktionalitäten wieder entfernt) habe, ist nicht ausgeschlossen, dass
es an ein paar kleineren Stellen klemmt.
Bisher lief das immer nur unter XP, andere Windows-Versionen wurden
nicht getestet, müssten aber auch gangbar zu machen sein.
Viel Spass damit und vielen Dank an Hugo für die gute Basis.
Ich habe mir mal den Source angesehen. Da ist das drinnen was ich immer
schon einmal machen wollte - mich aber nie gefreut hat: Ein Mapping für
die IR-codes auf globale Tastendrücke (Tastatur Emulator).
Am besten wär es wenn das Programm mit dem originalen USBIRRR kompatibel
bleibt. Die Sachen wie RTC kann man dann im Programm je nach Empfänger
deaktivieren/aktivieren.
Um die Empfänger auseinander zu kennen würden sich die Daten der HID
Reports anbieten. Man kann sich für jedes HID Gerät die verfügbaren
ReportIDs anzeigen lassen.
Wenn nun die RTC eine neue zusätzliche ReportID hat, die der Originale
nicht hat kann man einfach in der Anwendung die Funktion
aktivieren/deaktivieren.
Am besten wär es noch bei den ReportIDs etwas höher zum Zählen
anzufangen.
Z.B. bei 20 statt einfach bei 10 weiter zu zählen.
Beim Originalen geht es aktuell bis ID 9. Wenn deine dann erst bei 20
Anfangen hätte man noch einen Buffer um dem Originalen in Zukunft
erweitern zu können.
mfg
Portisch
Hugo Portisch schrieb:> Am besten wär es wenn das Programm mit dem originalen USBIRRR kompatibel> bleibt.
So war es ursprünglich gedacht und hat auch so funktioniert.
Hugo Portisch schrieb:> Am besten wär es noch bei den ReportIDs etwas höher zum Zählen> anzufangen.
Habe ich später auch gemacht (beginnend bei 50), aber bei dieser Version
noch nicht.
Wie gesagt: bei obigem Download handelt es sich um einen älteren Stand,
der nur die USBIRRR-Funktionalitäten bietet. Die weiteren Funktionen
kamen erst später dazu. Hast du es mal getestet? Läuft es? Ehrlich
gesagt habe ich das gestern nur zusammengepackt und hochgeladen ohne die
Funktion nochmal zu testen.
Mein Plan sieht vor mich erst um die STM32-Firmware zu kümmern und das
mit der Host-Applikation zum Laufen zu bekommen. Dabei werde ich zwar
versuchen kompatibel zu bleiben, kann aber nichts versprechen. Je
nachdem kann das Programm dann auch mit USBIRRR verwendet werden.
Ich dachte nur ich lade den Stand mal hoch falls jemand daran
weitermachen will bzw. eine Basis für die Kommunikation zwischen Host
(C#) und Device (V-USB) sucht.
Also kompilieren und starten lies es sich.
Habe hier aber keinen Empfänger und kann es nicht testen.
Das mit den IDs werde ich AVR aber auch noch etwas abändern.
Z.b. wenn die PowerON Funktion nicht gwünscht ist, dass dann auch nicht
die ReportID auftaucht. Diese wird jetzt ja trotzdem an den Host
gesendet.
Wenn diese dann auch nicht an den Host geschickt wird kann sich dieser
auch darauf einstellen was der Empfänger alles kann.
Hugo Portisch schrieb:> Dirk W. schrieb:>> Dann liegts wohl daran, daß die Events nicht abgeholt werden und>> irgendwas intern überschrieben wird.>> Richtig! Es liegt an der V-USB Funktion: usbInterruptIsReady>> Ändert einmal das in der SendINTData ab: while (!usbInterruptIsReady())
usbPoll(); // check if USB int is ready
> usbSetInterrupt(&replyBuf[0], sizeof(irmp_data) + sizeof(uchar));
// send ReportID + IR data
> Neu: usbSetInterrupt(&replyBuf[0], sizeof(irmp_data) + sizeof(uchar));
// send ReportID + IR data
funktioniert wunderbar.
btw. in der main.c koennte man einige der functions auch noch als static
deklarieren was noch ein paar zusaetzliche bytes verschaffen sollte.
Erst mal vielen Dank für das Projekt, funktioniert einwandfrei!
Ich hoffe natürlich, dass es noch weiterentwickelt wird, auch wenn es in
Kombination mit Eventghost eigentlich schon alles macht, was ich
benötige.
Noch ein paar Bilder von meinem Empfänger. Muss noch ein bisschen
verschönert werden, aber funktioniert schon sehr gut =). Das Gehäuse war
von einem WLAN-Stick, der irgendwann mal ein anderes Gehäuse bekommen
hat. Gerne stelle ich auch das Layout zur Verfügung, falls Interesse
besteht. Bei meinem Layout ist zu beachten, dass man evtl. zum
Programmieren noch für ISP Pads oder dgl. einfügen sollte und sowohl
USB, als auch IR-Empfänger müssen in dem Fall oben verlötet werden, wenn
die Platine einseitig bleiben soll.
Auch wenns nichts mit dem Empfänger zu tun hat, hab ich noch ne Frage.
Und zwar hab ich 2 SMD-Kondensatoren gegrillt, den 10µ, wo auf meiner
Platine sehr unschön jetzt ein tht Kondi angelötet ist, weils mir das
Lötpad weggeschmort hat. Am USB-Port eingesteckt und nach 5 Min hats
ordentlich geraucht und gestunken ;). Das war so ein gelber, wie der
4,7µ rechts neben dem IR-Empfänger. Ich gehe mal davon aus, dass die
Markierung Minus sein soll oder lieg ich da falsch? Außer durch
Verpolung kann ich mir das grad nicht erklären...aber bei 2 kann das ja
fast nicht sein^^
achja Bauteile(smd/tht) hab ich wild alles verbaut, was ich grad
gefunden hab ;)
Schönen Abend,
pedro
pedro f. schrieb:> Ich gehe mal davon aus, dass die> Markierung Minus sein soll oder lieg ich da falsch?
Und wie! Bei SMD Elkos ist der Strich !Plus!
Wegen der IR Diode:
Schaue dir einmal die TSOP4838 an. Ist um einiges kleiner und geht genau
so gut!
Hugo Portisch schrieb:> Und wie! Bei SMD Elkos ist der Strich !Plus!
Naja
So gaaanz stimmt das nicht.
Bei NORMALEN SMD Elkos ist der Strich ebenso Minus
Bei SMD Tantals ist der Strich das PLUS
Hallo alle zusammen,
ich habe das Projekt nun schon eine lange Zeit im Visier und bin gestern
endlich zum Nachbau gekommen.
Ich verwende die Pollin Tastatur FDC-3402. Die IR-Codes werden richtig
ausgewertet und mit dem USB-IRRR angezeigt. Ich habe die Kleinbuchstaben
erfolgreich zuweißen können, aber bei den Großbuchstaben habe ich
Probleme.
Da ich die Caps-Taste drücken muss und dann eine andere Taste kommt
nachher ja beim Drücken der Caps-Taste der Großbuchstabe heraus. Man
müsste also bei Großbuchstabenzuweisungen mehrere IR-Codes miteinander
verknüpfen, oder?
Gibt es da schon eine Lösung die ich noch nicht herausgefunden habe?
Mit freundlichen Grüßen
Sebastian
Wie wertest du die IR-Codes aus?
Ich selber habe kein IR Tastatur. Stöbere einmal den Thread von IRMP
durch:
Beitrag "IRMP - Infrared Multi Protocol Decoder"
Da habe ich was in Erinnerung das dort einmal beschrieben wurde wie das
mit "Shift" usw funktioniert.
Ich glaube beim Drücken der "Shift" Taste wird ein Code X gesendet. Nun
weis die auswertende Software das Shift gedrückt ist. Beim Loslassen der
Shift Taste sollte ein anderer Code Y kommen was bedeutet, dass die
Shift Taste losgelassen wurde.
Also sozusagen ein Shift/CAP/...-Down und Up.
Sebastian schrieb:> Da ich die Caps-Taste drücken muss und dann eine andere Taste kommt> nachher ja beim Drücken der Caps-Taste der Großbuchstabe heraus. Man> müsste also bei Großbuchstabenzuweisungen mehrere IR-Codes miteinander> verknüpfen, oder?
Hast Du Dir schon einmal
http://www.mikrocontroller.net/articles/IRMP#IR-Tastaturen
durchgelesen? Da ist erklärt, was passiert, wenn Du die
SHIFT/STRG-usw-Taste drückst bzw. loslässt. Du musst Dir diese Events
als Status speichern, um dann die richtige Taste zu ermitteln, wenn Du
ein 'a' bekommst.
Dort ist auch eine kleine C-Funktion abgebildet, welches genau das
erledigt.
Hallo,
die C-Funktion steht doch schon in der irmp.c drin, oder?
Irgendwo hab ich auch das aktuelle irmp.zip gefunden. In diesem Archiv
war die irmp.exe wozu ist die eigentlich?
Ich muss doch nach wie vor z.B. mit EventGhost die Tasten-Events den
einzelnen Buchstaben zuweisen, sodass ich mit der Tastatur auch tippen
kann, oder?
Sebastian schrieb:> die C-Funktion steht doch schon in der irmp.c drin, oder?
Ja, aber durch Preprocessor-Defines deaktiviert. Die steht da nur drin,
damit man sie da rauskopieren kann.
Wo nämlich aus Protokoll, Adresse & Kommando der eigentliche Tastencode
gebildet wird, ist eigentlich egal. Das kann auf dem µC sein, es kann
aber auch erst auf dem PC passieren.
> Irgendwo hab ich auch das aktuelle irmp.zip gefunden.
Download-Link im Artikel IRMP.
> In diesem Archiv war die irmp.exe wozu ist die eigentlich?
Steht auch im Artikel. Benötigst Du aber nicht.
> Ich muss doch nach wie vor z.B. mit EventGhost die Tasten-Events den> einzelnen Buchstaben zuweisen, sodass ich mit der Tastatur auch tippen> kann, oder?
Ich kenne Eventghost nicht und kann deshalb nichts dazu sagen.
Hallo an alle Experten hier,
nachdem ich schon seit einiger Zeit immer mal wieder diverse Beiträge
hier lese, muss ich mich jetzt mit einem Problem an euch wenden.
Ich habe die Schaltung gemäß Schaltplan und BOM aufgebaut ( siehe
Anhang, Schaltplan wurde nur schnell auf Eagle übertragen ))
Leider bekomme ich immer nur Unknown Device unter Windows ( Windows 7
Ultimate x64 ).
Habe schon diverses ausprobiert ( Datenleitungen getauscht, Quarz durch
Resonator getauscht, Original V-USB Bootloader getestet ) leider ohne
Erfolg.
Was kann ich noch Probieren ? Bilder der fertigen Schaltung kann ich
auch gerne noch machen. ( Nach Multimetertest scheint soweit alles in
Ordnung zu sein )
Hat sich erledigt.
Eine von den Zenerdioden war durch ( beidseitig durchgang )
Den Bootloader bekomme ich zwar trotzdem nicht ans laufen, aber das
Hauptprogramm läuft.
Moin!
Hab den Receiver unter Linux im Einsatz und wunderte mich heute, daß
nach einem Kernel-Update, welches gestern eingespielt wurde, für den
Receiver kein hidraw-Gerät mehr angelegt wurde.
Nach einigem Suchen fand ich das hier:
http://www.easyvdr-forum.de/forum/index.php?topic=13723.msg133283#msg133283
Habe auch erfolgreich ein Update mit der neuen Device-ID über VirtualBox
gemacht und es geht auch alles unter Linux, allerdings wird der
Empfänger im Windows nun nicht mehr im Einstellungs-/Optionen- und
Update-Dialog angezeigt.
Kann man entweder eine passende DLL bekommen oder die DLL vielleicht so
erstellen, daß auch Empfänger mit unterschiedlichen Device-IDs
bearbeitet werden können? Die Erkennung läuft doch über die DLL, oder?
Danke.
MfG
MrFX
Ich habe hier schon länger nichts mehr gemacht.
Eigentlich habe ich schon mal angefangen den Source nach GitHub zu
bringen:
https://github.com/Portisch/USB-IR-Remote-Receiver
Aber hier fehlt noch die neue DLL!
Die DLL sucht per USB_CFG_VENDOR_ID, USB_CFG_DEVICE_ID und dem
USB_CFG_DEVICE_NAME den Empfänger. Diese IDs sind im AVR Source fix
definiert.
Hello,
after latest Windows update, the DLL stopped working. It always displays
error "Ungultige Zeigeroperation" and IR codes are not received.
Because the source code of the DLL is not available, I cannot fix it
myself. Please fix it :(
Mek
Windows 10 v1809 has a great bug in hidclass.sys driver. A lot of HID
devices stopped working. We have to wait until windows fixes this bug.
At this time the only change to get the tool working is to go back to
Windows 1803.