USB IR Remote Receiver (V-USB + IRMP)

[Hugo P. (portisch)]

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 von 
anderen 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:

HidD_GetFeature (hole Daten vom AVR):
ID1:  (6 Bytes) aktueller empfangener IR-Code, Daten entsprechen der Irmp Struktur.
ID2:  (1 Byte, Boolean) aktueller Status ob PowerOn Funktion aktiviert ist oder nicht.
ID3:  (6 Bytes) aktueller trainierter IR-Code fuer die PowerOn Funktion, Daten entsprechen der Irmp Struktur.
ID7:  (4 Bytes) aktuell verwendete Irmp Version. (Day[Byte], Month[Byte], Year[Word])

HidD_SetFeature (schicke Daten zum AVR):
ID4:  (1 Byte, Boolean) setze PowerOn Funktion aktiv/inaktiv.
ID5:  (6 Bytes) setze/loesche trainierten IR-Code im EEProm.
ID6:  (1 Word) setze IR-Polling Frequenz.

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).

[Frank M. (ukw) (Moderator)]

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

[Micha (Gast)]

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.ä.).

[Hugo P. (portisch)]

> 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!

[Hugo P. (portisch)]

Hier gleich zuerst noch ein Update!

Es wird die Irmp Version nun so definiert:

//enter here the Irmp build date:
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

[Frank M. (ukw) (Moderator)]

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

[Portisch (Gast)]

> 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...

[Hugo P. (portisch)]

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

[Hugo P. (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:

19:07:34: USB IR Remote Receiver connected
19:07:38: Irmp Version: 17.03.2010
19:07:40: PowerOn Function status: 1
19:07:41: Trained IR Code: Protocol : RC6, Address: 0x0027, Command: 0x000C, Flags: 0x00
19:07:45: Protocol : RC6, Address: 0x0027, Command: 0x0010, Flags: 0x00
19:07:46: Protocol : RC6, Address: 0x0027, Command: 0x0011, Flags: 0x00
19:07:47: Protocol : RC6, Address: 0x0027, Command: 0x0058, Flags: 0x00
19:07:48: Protocol : RC6, Address: 0x0027, Command: 0x0059, Flags: 0x00
19:07:48: Protocol : RC6, Address: 0x0027, Command: 0x005C, Flags: 0x00
19:07:49: Protocol : RC6, Address: 0x0027, Command: 0x0058, Flags: 0x00
19:07:50: Protocol : RC6, Address: 0x0027, Command: 0x0058, Flags: 0x01
19:07:50: Protocol : RC6, Address: 0x0027, Command: 0x0058, Flags: 0x01
19:07:50: Protocol : RC6, Address: 0x0027, Command: 0x0058, Flags: 0x01
19:07:50: Protocol : RC6, Address: 0x0027, Command: 0x0058, Flags: 0x01
19:07:50: Protocol : RC6, Address: 0x0027, Command: 0x0058, Flags: 0x01
19:07:50: Protocol : RC6, Address: 0x0027, Command: 0x0058, Flags: 0x01
19:07:50: Protocol : RC6, Address: 0x0027, Command: 0x0058, Flags: 0x01

[Hugo P. (portisch)]

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.

[Frank M. (ukw) (Moderator)]

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.

[Hugo P. (portisch)]

> 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?

                    for (i = 0; i < c_startcycles; ++i)
                    {
                        irmp_uart_putc ('0');                                   // the ignored starting zeros
                    }

Da weis ich nähmlich nicht wieviele Interrupts zusammen kommen...

So könnte es einen Versuch wert sein:

                    uint16_t i;
                    static uint8_t  s_data_buffer[9];
                    
                    s_data_buffer[0] = ReportIDLogging;
                    s_data_buffer[1] = 0x00;                    

                    for (i = 0; i < c_startcycles; ++i)
                    {
                        while (!usbInterruptIsReady()) usbPoll();          // check if USB int is ready
                            usbSetInterrupt(&s_data_buffer[0], 2);              // send ReportID + IR data  
                    }

                    for (i = 0;i < (s_dataIdx - c_endBits + 20) / 8; ++i)       // transform bitset into uart chars
                    { 
                        memcpy(&s_data_buffer[1]), &s_data[i*8], 8);
                        
                        while (!usbInterruptIsReady()) usbPoll();          // check if USB int is ready
                            usbSetInterrupt(&s_data_buffer[0], 9);              // send ReportID + IR data                        
                    }

                    s_dataIdx = 0;

[Frank M. (ukw) (Moderator)]

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?
>

                    for (i = 0; i < c_startcycles; ++i)
>                     {
>                         irmp_uart_putc ('0');
> // the ignored starting zeros
>                     }

> 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

[Hugo P. (portisch)]

Danke,

...das mit Interrupt im Logging wird nicht gehen.

Besser wird es so auf die Art sein:

typedef struct
{
  uint8_t               s_startcycles;                                        // number of start cycles
  uint16_t              s_datacount;                                          // number of data bytes
  uint8_t               s_data[700];                                          // data bytes
} IRMP_DATA_LOGGING;

/*---------------------------------------------------------------------------------------------------------------------------------------------------
 *  Get IRMP logging data for USB
 *  @details  gets logged data
 *  @param    pointer in order to store logged data
 *  @return    TRUE: successful, FALSE: failed
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */
irmp_get_logging_data (IRMP_DATA_LOGGING * irmp_data_logging_p)
{
  irmp_data_logging_p->s_startcycles = s_startcycles_p;
  irmp_data_logging_p->s_datacount = s_datacount_p;
  memcpy(&irmp_data_logging_p->s_data[0], &s_data_p[0], s_datacount_p);
  
  if ( irmp_logging_ir_detected )
  {
    irmp_logging_ir_detected = FALSE;
    return !irmp_logging_ir_detected;
  }   
  else
  {
    return irmp_logging_ir_detected;
  }
}

static volatile uint8_t                     s_startcycles_p;
static volatile uint16_t                    s_datacount_p;
static volatile uint8_t                     s_data_p[700];
static volatile uint8_t            irmp_logging_ir_detected;

static void
irmp_logIr (uint8_t val)
{
    static uint8_t  s_data[c_datalen];                                  // logging buffer
    static uint16_t s_dataIdx;                                          // number of written bits
    static uint8_t  s_startcycles;                                      // current number of start-zeros
    static uint16_t s_ctr;                                              // counts sequenced highbits - to detect end

    if ((val == 0) && (s_startcycles < c_startcycles) && !s_dataIdx)    // prevent that single random zeros init logging
    {
        ++s_startcycles;
    }
    else
    {
        s_startcycles = 0;
        s_startcycles_p = 0;
        s_datacount_p = 0;

        if (    (val == 0)                                              // start or continue logging on "0"
            || ((val == 1) && (s_dataIdx != 0)))                        // "1" cannot init logging
        {
            if (val)
            {                                                           // set or clear bit in bitarray
                s_data[(s_dataIdx / 8)] |=  (1<<(s_dataIdx % 8));
            }
            else
            {
                s_data[(s_dataIdx / 8)] &= ~(1<<(s_dataIdx % 8));
            }

            ++s_dataIdx;

            if (val)
            {                                                           // if high received then look at log-stop condition
                ++s_ctr;

                if (s_ctr > c_endBits)
                {                                                       // if stop condition (200 sequenced ones) meets, output on uart
                    uint16_t i;
                    s_datacount_p = c_startcycles;

                    for (i = 0;i < (s_dataIdx - c_endBits + 20) / 8; ++i)       // transform bitset into uart chars
                    {
                      s_datacount_p++;
                      s_data_p[i] = s_data[i];
                    }

                     irmp_logging_ir_detected = TRUE;
                    s_dataIdx = 0;
                }
            }
            else
            {
                s_ctr = 0;
            }
        }
    }
}

Muss ich mich aber noch durch arbeiten!!

[Hugo P. (portisch)]

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...

[SD-Fritze (Gast)]

Hey Hugo,

mach im Source doch einfach

const char build_date[] = __DATE__; \\ Zwei Unterstriche

dann hast du immer das richtige Datum drin. :-)

Gruß,
  SD-Fritze

[Werner B. (werner-b)]

... aber nur wenn DIESE source-Datei neu übersetzt wird.
Im Makefile also ein "touch" auf diese Datei einfügen.

[Hugo P. (portisch)]

Danke,
aber es ist ja nicht das eigentliche Build-Date, sondern die Version 
(Build Date) von Irmp ;)

[SD-Fritze (Gast)]

Ahh, okay :-)

Gruß, SD-Fritze

[Hendi (Gast)]

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

[Hugo P. (portisch)]

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

[Ingo (Gast)]

funktioiert die Hardware mit http://www.lirc.org/ / Winlicr ?

aber schon mal ein super Projekt!

weiter so

[Hugo P. (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.

[Hendi (Gast)]

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?

[Hugo P. (portisch)]

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.

[Hugo P. (portisch)]

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

[Hendi (Gast)]

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?

[Hugo P. (portisch)]

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:

The DLL PluginName is: USB IR Remote Receiver

The DLL version is: 1.0.0.3

The DLL Copyright is: written 2010 by Portisch

Please define if DLL init by native IR Data or by PAnsiChar!
Press [1] for native IR Data
Press [2] for IR Data in PAnsiChar

Please enter a command!
Init DLL with InitPAnsiChar successfull

Press [s] to show settings dialog
Press [x] to exit

Please enter a command!
IR Data received: Protocol: NEC, Address: 0x7282, Command: 0x0084, Flags: 0x00
IR Data received: Protocol: NEC, Address: 0x7080, Command: 0x00C7, Flags: 0x00
IR Data received: Protocol: NEC, Address: 0x7080, Command: 0x00C1, Flags: 0x00
IR Data received: Protocol: NEC, Address: 0x7282, Command: 0x00D0, Flags: 0x00
IR Data received: Protocol: NEC, Address: 0x7282, Command: 0x00D1, Flags: 0x00

[Hugo P. (portisch)]

*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

[Hugo P. (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

[Hendi (Gast)]

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. (Gast)]

girder ist seeehr verbreitet und außerdem auch vom hersteller 
hervorragend dokumentiert...
du solltest wirklich alles wichtige finden können.

[Hendi (Gast)]

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

[Michael M. (Gast)]

klappt es denn über die einstellung "Zum aktiven Fenster senden", wenn 
du als befehl z.b. die leertaste (die ja play/pause macht) schickst?

[Hendi (Gast)]

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.

[Hugo P. (portisch)]

Schau einmal in das PDF:
http://www.promixis.com/pdfs/GirderUserManual.pdf

Punkt 6.13 Window Picker

Bei diesem Fenster kann man definieren wohin der Befehl geschickt werden 
soll.

[Hendi (Gast)]

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?

[Frank M. (ukw) (Moderator)]

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

[Hugo P. (portisch)]

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)

28.04.2010:
    DLL:    v1.0.0.5, Added possibility to flash or update the device firmware direct with the USB IR Remote Receiver settings/option dialog.
    AVR:   Bugfix code repeats
                Updated Irmp to 28.04.2010
                Added modified booloadHID to be able to flash the device without setting a jumper or needed disconnect/reconnect of the device
                The booloadHID will boot if:
                    + no USB IR Remote Receiver firmware is flashed
                    + jumper is set
                    + 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.

[Hendi (Gast)]

Super! werde ich gleich mal testen :)

[Hugo P. (portisch)]

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!

[Hendi (Gast)]

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

[Hugo P. (portisch)]

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!

[Michael M. (Gast)]

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.

[Frank M. (ukw) (Moderator)]

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 :-)

[Frank M. (ukw) (Moderator)]

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

[Michael M. (Gast)]

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.

[... .. (docean)]

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...

[... .. (docean)]

ich nochmal...

Kannst du mal testen ob das Tool http://www.eventghost.org/ geht? die 
haben ein HID Plugin: 
http://www.eventghost.org/forum/viewtopic.php?t=571

[Hugo P. (portisch)]

>> 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!

[docean (Gast)]

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

[Hugo P. (portisch)]

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.

[Hugo P. (portisch)]

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!

[Hugo P. (portisch)]

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

[Hendi (Gast)]

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

[Hugo P. (portisch)]

Update 18.05.2010

USB IR Remote Receiver

Neue IRMP Version - siehe Beschreibung im Artikel

[Frank M. (ukw) (Moderator)]

Hugo Portisch schrieb:

> Neue IRMP Version - siehe Beschreibung im Artikel

Du bist aber flott :-)

Gruß,

Frank

[Hugo P. (portisch)]

Ehrlich gesagt habe ich heute zufällig gesehen das es eine neu IRMP 
Version gibt ;)

[Tishima (Gast)]

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

[Micha (Gast)]

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.

[Tishima (Gast)]

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

[Chris R. (hownottobeseen)]

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

[Frank M. (ukw) (Moderator)]

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

[Frank M. (ukw) (Moderator)]

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

[Hugo P. (portisch)]

> 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

[Chris R. (hownottobeseen)]

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

[Chris R. (hownottobeseen)]

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

[Frank M. (ukw) (Moderator)]

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

[Chris R. (hownottobeseen)]

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.

[Potisch (Gast)]

Update 06.06.2010

Es ist nun die Irmp Version vom 02.06.2010 drinnen.
Auch die DLL wurde etwas überarbeitet.

USB IR Remote Receiver

[Hendi (Gast)]

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

[Hendi (Gast)]

Also mit EventGhost funktioniert das alles einwandfrei hatte nur zuerst 
Probleme mit der Benutzerkontensteuerung, die hat geblockt jetzt 
funktioniert alles, wie es soll!

[Hugo P. (portisch)]

Nur ein kurzes Update für Irmp vom 26.06.2010:

USB IR Remote Receiver

[zickzack (Gast)]

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.

[Peter K. (peterk)]

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

[zickzack (Gast)]

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.

[Peter K. (peterk)]

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

[Fliegenhals (Gast)]

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.

[Hugo P. (portisch)]

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.

[Fliegenhals (Gast)]

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.

[Ian (Gast)]

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 :)

[Fliegenhals (Gast)]

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. ;-)

[Hugo P. (portisch)]

@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.

[Dirk (Gast)]

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.

[Dirk (Gast)]

Habe jetzt mal gesucht und gefunden. Anbei ein Bild für die Leute, die 
mit dem AVRStudio die Fuse einstellen wollen.

[PeterPan (Gast)]

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?

[Oekel (Gast)]

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!

[Hendi (Gast)]

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

[Pavel (Gast)]

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.

[Willi (Gast)]

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

[Mock (Gast)]

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

[Hugo P. (portisch)]

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.

[Ron S. (4huf)]

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 :

Jan 30 11:18:31 ion kernel: [ 1735.172036] usb 4-1: new low speed USB device using uhci_hcd and address 12
Jan 30 11:18:31 ion kernel: [ 1735.356189] usb 4-1: configuration #1 chosen from 1 choice
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 :

ll /dev/input/wake-up
insgesamt 0
drwxr-xr-x 2 root root  80 2011-01-30 11:36 ./
drwxr-xr-x 5 root root 320 2011-01-30 10:49 ../
lrwxrwxrwx 1 root root  17 2011-01-30 11:36 pci-0000:00:1d.2-usb-0:1:1.0 -> ../../usb/hiddev0

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

[Mock (Gast)]

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

[Mock (Gast)]

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 (Gast)]

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/doc2553.pdf
http://www.atmel.com/dyn/resources/prod_documents/doc2554.pdf

[ich (Gast)]

Ob die 16k reichen weiß ich allerdings nicht.

[Frank M. (ukw) (Moderator)]

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

[Hugo P. (portisch)]

@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!

[Willi (Gast)]

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!

[Hugo P. (portisch)]

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?

[Frank M. (ukw) (Moderator)]

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

[Hugo P. (portisch)]

> 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.

[Hugo P. (portisch)]

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.

[Frank M. (ukw) (Moderator)]

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

[Hugo P. (portisch)]

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.

[Christian (Gast)]

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

[Hugo P. (portisch)]

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.

[Christian (Gast)]

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?

[Frank M. (ukw) (Moderator)]

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

[Micha (Gast)]

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?

[Hugo P. (portisch)]

> 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...

[Micha (Gast)]

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?

[Hugo P. (portisch)]

> Gibt es deinerseits Bestrebungen das für MediaPortal zu realisieren?
Eigentlich schon, aber ich finde kein Source Beispiel wie das in 
Mediaportal funktioniert!

[Micha (Gast)]

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.

[Micha (Gast)]

Hilft dir folgendes weiter?
https://sources.team-mediaportal.com/svn/public/trunk/mediaportal/RemotePlugins/
http://wiki.team-mediaportal.com/1_MEDIAPORTAL_1/18_Contribute/6_Plugins/Plugin_Developer%27s_Guide/1_Develop_a_Plugin

[Hugo P. (portisch)]

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.

[Micha (Gast)]

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".

[Frank M. (ukw) (Moderator)]

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

[Micha (Gast)]

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?

[Frank M. (ukw) (Moderator)]

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:

#define MAX_REMOTE_CONTROLS     2    // 2 remote controls, e.g. RC5 + NEC
#define MAX_KEYS                32   // 32 keys per remote control

struct
{
    uint8_t  protocol;
    uint16_t address;
    uint16_t command[MAX_KEYS];
    uint8_t  key[MAX_KEYS];
} cmdkey[MAX_REMOTE_CONTROLS];

uint8_t search_key (uint8_t protocol, uint16_t address, uint16_t command)
{
    uint8_t p;
    uint8_t c;

    for (p = 0; p < MAX_REMOTE_CONTROLS; p++)
    {
        if (cmdkey[p].protocol == protocol && cmdkey[p].address == address)
        {
            for (c = 0; c < MAX_KEYS; c++)
            {
                if (cmdkey[p].command[c] == command)
                {
                    return cmdkey[p].key[c];
                }
            }
            break;
        }
    }
    return (0xff);
}

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

[Micha (Gast)]

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!

[Hugo P. (portisch)]

> 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.

[Micha (Gast)]

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.

[Frank M. (ukw) (Moderator)]

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:

Möchte man IRMP und IRSND parallel verwenden (also als Sender und
Empfänger) schreibt man die ISR folgendermaßen:

ISR(TIMER1_COMPA_vect)
{
  if (! irsnd_ISR())          // call irsnd ISR
  {                           // if not busy...
      irmp_ISR();             // call irmp ISR
  }
  // call other timer interrupt routines...
}

Das heisst: Nur wenn irsnd_ISR() nichts zu tun hat, dann rufe die ISR des
Empfängers auf. Damit ist der Empfänger solange abgeschaltet, während
irsnd_ISR() noch Daten sendet. Die Timer-Initialisierungsroutine ist für
IRMP und IRSND dann natürlich dieselbe.

Gruß,

Frank

[Hugo P. (portisch)]

> 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. (_hendi_)]

Also ich fände ja auch eine Anbindung an MediaPortal super :)

[Micha (Gast)]

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.).

[Hugo P. (portisch)]

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 (Gast)]

Hugo Portisch schrieb:
> 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.
Hilft das weiter?
http://de.team-mediaportal.com/plugins-und-skins-archiv/input/2113-keyboardinputplugin
http://forum.team-mediaportal.com/mediaportal-plugins-47/generic-keyboard-remote-input-plugin-25755/
https://mp-plugins.svn.sourceforge.net/svnroot/mp-plugins/trunk/plugins/KeyboardInputPlugin/

[Hendrik S. (_hendi_)]

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.

[Micha (Gast)]

Hendrik S. schrieb:
> Also ich habe das leider nicht zum laufen gebracht jedenfalls noch nicht.
Wie gesagt: ich hatte es mit einem anderen Empfänger am Laufen. Wenn 
aber das USB-IRRR-Eventghost-Plugin läuft, sollte das Ganze auch mit 
MePo laufen. Schau dir mal 
http://www.htpc-news.de/wiki/index.php?title=EventGhost und 
http://www.eventghost.org/wiki_old/index.php/MediaPortalPlugin an.

[Hugo P. (portisch)]

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.

[Micha (Gast)]

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?

[Hugo P. (portisch)]

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.

[M. K. (kichi)]

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.

[Hugo P. (portisch)]

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.

[M. K. (kichi)]

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.

[M. K. (kichi)]

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...

[Hugo P. (portisch)]

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...

[Michael K. (Gast)]

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...

[Michael K. (Gast)]

Das oben habe ich rein interessehalber einfach mal versucht. Das 
Ergebnis wäre ja auch noch stark verbesserungswürdig, stimmt aber nicht 
unbedingt negativ.

[Hugo P. (portisch)]

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.

[San398 (Gast)]

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.

[M. K. (kichi)]

@ 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.

[Hugo P. (portisch)]

@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.

[San398 (Gast)]

@ Hugo Portisch
Thank You for Your help!

[M. K. (kichi)]

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").

[Hendi (Gast)]

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

[M. K. (kichi)]

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.

[Hendrik S. (_hendi_)]

Hört sich auch gut an mit der Maske. Ich wäre ja dafür auch gleich das 
MePo plugin zu machen :P

[MrFX (Gast)]

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.

[M. K. (kichi)]

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.

[M. K. (kichi)]

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.

[Hendrik S. (_hendi_)]

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

[M. K. (kichi)]

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.

[Hendrik S. (_hendi_)]

Warte, ich mache einen Screenshot. Siehe Anhang sry für evtl falsche 
Bildgröße, Format, was auch immer ich habe gerade nur sehr wenig Zeit

LG, Hendi

[M. K. (kichi)]

Aktualisierte Version im Anhang. Versuch es mal damit.

[Hugo P. (portisch)]

@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)

[M. K. (kichi)]

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.

[Hendrik S. (_hendi_)]

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

[M. K. (kichi)]

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?

[Hendrik S. (_hendi_)]

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

[Hendrik S. (_hendi_)]

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

[M. K. (kichi)]

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.

[Hendrik S. (_hendi_)]

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!

[M. K. (kichi)]

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.

[Hendrik S. (_hendi_)]

Ahaaaa, na dann probier ich das doch gleich nochmal aus.

[Dietmar (Gast)]

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

[ich (Gast)]

@ Dietmar
1. 
http://www.mikrocontroller.net/articles/USB_IR_Remote_Receiver#Settings.2FOptionen_Dialog
2. http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Vorwort

@ 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?

[Hugo P. (portisch)]

>> 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 ;)

[ich (Gast)]

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?

[Hugo P. (portisch)]

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...

[Dirk W. (glotzi)]

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?

[Micha (Gast)]

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.

[Hugo P. (portisch)]

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.

[Dirk W. (glotzi)]

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.

[Hugo P. (portisch)]

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.

[Maniac (Gast)]

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 (Gast)]

Ich glaub ich habs gefunden. Folgendes müsste das auf active high ändern 
oder?

irmpconfig.h Zeile 81

#define input(x)                                 ((x) & (1 << IRMP_BIT))

ändern in

#define input(x)                                 ((x) | (1 << IRMP_BIT))

[Frank M. (ukw) (Moderator)]

Maniac schrieb:
> Ich glaub ich habs gefunden. Folgendes müsste das auf active high ändern
> oder?
>
> irmpconfig.h Zeile 81
>

#define input(x)               ((x) & (1 << IRMP_BIT))

> ändern in
>

#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

#define input(x)                 ((x) & (1 << IRMP_BIT))

ändern in

#define input(x)                 (!((x) & (1 << IRMP_BIT)))

Gruß,

Frank

[Maniac (Gast)]

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.

[Dietmar (Gast)]

Hallo ALL,
kann man dieses Projekt auch unter Linux einsetzten?

LG Dietmar

[Dirk W. (glotzi)]

Dietmar schrieb:
> kann man dieses Projekt auch unter Linux einsetzten?

Wenn du den Thread gelesen hättest wäre dir dieser

Beitrag "Re: USB IR Remote Receiver (V-USB + IRMP)"

aufgefallen.

[Altainta (Gast)]

can u give a alternative for the CNY17III it is not available in the 
market...(use following link to check alternative)
Also u had a list of the items needed for this project can you please 
provide it..


in german language...
kann u geben Alternative für den Optokoppler CNY17III ist es auf dem 
Markt nicht in meinem Land verfügbar ... (Verwendung folgenden Link, um 
alternative Check)
Auch u hatte eine Liste der Begriffe für dieses Projekt benötigt können 
Sie es bitte .


http://in.element14.com/jsp/search/browse.jsp?N=0+551+401+5066210&Ntk=gensearch_001&Ntt=cny17&Ntx=mode+matchallpartial&suggestions=false&ref=globalsearch&_requestid=159760&No=0&getResults=true&appliedparametrics=true&locale=en_IN&catalogId=&prevNValues=0+551+401&filtersHidden=false&appliedHidden=false&originalQueryURL=%2Fjsp%2Fsearch%2Fbrowse.jsp%3FN%3D0%26Ntk%3Dgensearch_001%26Ntt%3Dcny17%26Ntx%3Dmode%2Bmatchallpartial%26suggestions%3Dfalse%26ref%3Dglobalsearch%26_requestid%3D159760%26No%3D0%26getResults%3Dtrue%26appliedparametrics%3Dtrue%26locale%3Den_IN%26catalogId%3D%26prevNValues%3D0

[Michael K. (Gast)]

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.

[Altainta (Gast)]

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..

[Altainta (Gast)]

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

[Michael K. (Gast)]

ATMEGA 8-16 DIP -> Microcontroller (I'd take ATMega168(P) 20MHz)
TSOP 1738 -> IR receiver (I'd take TSOP34838)
RAD 10/35 -> Capacitor 10u/35V
RAD 4,7/35 -> Capacitor 4u7/35V
KERKO 22P -> Capacitor 22p 2pcs
12,0000-HC18 -> oscillator 12MHz
1/4W 100 -> Resistor 1/4W, 5%, 100 Ohm
1/4W 68 -> Resistor 1/4W, 5%, 68 Ohm 2pcs
1/4W 1,5K -> Resistor 1/4W, 5%, 1,5 kOhm
1/4W 1,0M -> Resistor 1/4W, 5%, 1,0 MegOhm
1/4W 10K -> Resistor 1/4W, 5%, 10 kOhm
1/4W 560 -> Resistor 1/4W, 5%, 560 Ohm
KB 817 -> Optocoupler, CNY17-3/-4 is fine for this
ZF 3,6 -> Zener-Diode 0,5W 3,6V 2pcs (I'd take a 3.3V low drop linear 
regulator like MCP1702-3302E instead to power the ATMega & TSOP; take a 
20MHz uc when doing so)
UP 913HP Laborkarte -> PCB

Don't forget some 100n capacitors for bypassing.

[Altainta (Gast)]

Thank you very much Michael K ..
That will be very help full

[Dirk W. (glotzi)]

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?

[Michael K. (Gast)]

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.

[Michael K. (Gast)]

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.

[altainta a. (Firma: altainta) (altainta)]

Will this programmer work ?
http://wearcam.org/ece385/avr/avr_programmer_from_xs4all_sbolt_site.png
asking because i already have it

[Michael K. (Gast)]

altainta altainta schrieb:
> Will this programmer work ?
Compare it to 
http://www.mikrocontroller.net/articles/USB_IR_Remote_Receiver#Schaltplan_des_USB_IR_Remote_Receiver. 
But if you're able to program other AVR there shouldn't be a problem.

[altainta a. (Firma: altainta) (altainta)]

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.

[KLez (Gast)]

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?

[Michael K. (Gast)]

@ 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.

[Hugo P. (portisch)]

@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.

[KLez (Gast)]

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.