USB IR Remote Receiver (V-USB + IRMP)

Thank You Michael K. (Gast)
I successfully build it..Everything is working fien. Now i want to make 
it short and stable (in eventghost read below for the problem)
Now i would like to know few thing also you can consider some bug..

1)Adding short crystal than the long one.
I added full (big) Quartz Crystal Q1 12Mhz it works. I tried to replace 
it with 12Mhz Small crystal (cut one) but it doesn't work.. The system 
gives error when connected "USB DEVICE NOT RECOGNIZED". Can u tell me 
how can i do it ? How to make this circuit short also which component to 
use to make it short ? I saw a SMD version above do we have a schematic 
or component list ?
small(cut) = 
http://webbuilder.asiannet.com/617/comm/upimage/p_080905_03867.jpg
Full = 
http://webbuilder.asiannet.com/617/comm/upimage/p_080905_03871.jpg

2) DLL intialization and also UNintialize it via windows
In eventghost (program) i add the plugin and done few thing with it. Was 
working fien. but there are few things still giving problem...
A---In event ghost the mouse movement doesn't work  (it is so slow 
slow). I tried to work that out with mouse relative macro. Can u explain 
why we can't use the normal mouse up, down etc thing. This thing works 
perfectly with Igorplug and LIRC receivers which i already have but they 
have limitation like com port windows xp etc etc.
B---In event ghost even after setting the "DISABLE POWERON 
intialization" it doesn't function properly. I mean after selecting the 
option it must do this
 a) Do not work after Initialization (by windows ? or by eventghost ?)
 b) Do work after windows shutdown (here is the problem it works one 
time after that it doesn't)
So in short,
How to make it work how to intialize the plugin and also UNintialize it 
via windows.
How to enable/disable the PowerON function via window "COMMAND LINE"?

3) Can you provide any smaller version of the schematic ? i mean smd and 
normal both ? in eagle cadsoft http://www.cadsoftusa.com/?lang=en

4) One thing more will this support windows 7 32bit and also 64bit 
version ?

Thank you

VERY GOOD PROJECT I LIKE IT..I am trying to make it work and good. I am 
a hobbyist in electronics.

Yes, there is a bug with the "PowerOn Function" in the DLL with 
EventGhost.
The function gets disabled but not anymore enabled so you can't switch 
on the PC with the optocoupler.
It is already fixed but i missed to upload the new DLL.

I will do this in this week!

New DLL is now online: USB IR Remote Receiver

Hallo!

Ich habe den Empfänger laut Anleitung aufgebaut, funktioniert tadellos.
Allerdings habe ich ein kleines Problem:

Die (Noname) Fernbedienung, welche ich mit dem Empfänger verwenden 
möchte, hat einige Tasten, die nicht erkannt werden ("8", "Mute" und 
einige weitere).
Diese Tasten funktionieren jedoch über den IgorPlug problemlos.
Alle anderen werden einwandfrei erkannt.

Hat jemand eine Idee, woran das liegen könnte?
Der einzige Unterschied in meinem Aufbau ist, daß ich einen TSOP 1136 
verwende.....kann es daran liegen?

Daniel S. schrieb:
> Die (Noname) Fernbedienung, welche ich mit dem Empfänger verwenden
> möchte, hat einige Tasten, die nicht erkannt werden ("8", "Mute" und
> einige weitere).

Im IRMP-Artikel findest Du eine kleine Anleitung, wie Du Scans von 
Deiner Fernbedienung machen kannst.

  http://www.mikrocontroller.net/articles/IRMP

Zugehöriger Thread:

  Beitrag "IRMP - Infrared Multi Protocol Decoder"

> Diese Tasten funktionieren jedoch über den IgorPlug problemlos.
> Alle anderen werden einwandfrei erkannt.

Wenn Du mir die Scans zuschickst, kann ich den IRMP entsprechend 
erweitern.
Ich bräuchte Scans von funktionierenden Tasten, wie 1-7 und 9, und dann 
noch die von den nicht-funktionierenden.

Gruß,

Frank

Hallo,
ich habe die Schaltung in SMD nachgebaut, allerdings nicht den ATMEGA8 
sondern den ATMEGA168P-20AU genommen und versuche nun den mit Ponyprog 
über die parallele Schnittstelle zu programmieren.
Leider klappt das ums verrecken nicht. Nun habe ich hier irgendwo 
gelesen, dass Ponyprog den 168p nicht unterstützt.
Stimmt das und wenn ja, mit was programmiere ich das Ding dann? Brauche 
ich einen anderen Programmer, bis jetzt habe ich nur das ganz einfache 
ISP-Interface (siehe Schaltplan hier vom Projekt).

Vielen Dank
Gruß
Stefan

Habe es selber nicht probiert, aber hier geht es anscheinend:
Beitrag "ATmega168 und PonyProg ?"

Hi,
danke, ich habe mittlerweile AVRdude probiert, damit sieht's bis jetzt 
ganz gut aus. Jetzt fehlen mir nur noch die richtigen Fuse-Bits. Das 
wird aber hoffentlich auch noch.

Gruß
Stefan

Hallo,
ich beschäftige mich gerade mit V-USB als ich dieses Projekt gefunden 
habe, habe ich mir gedacht das es ein guter Einstieg in das Thema wäre. 
Mein Problem ist nur das ich keine Verbindung mit dem PC erreiche.

Ich habe mir auf ein Steckboard ein Widerstand-Spannungsteiler aufgebaut 
weil ich keine Z-Dioden mit 3.6V habe. Desweiteren habe ich die 
usbconfig.h verändert und PD2 an D- und PD3 an D+ sowie einen 1.1k Ohm 
Widerstand an PD4 angeschlossen. In Ermangelung eines 68 ohms 
Widerstandes habe ich mit parallelgeschalteten Widerständen 88_Ohm 
erreicht. Mein Mega8 läuft mit einen 20Mhz Quarz wobei ich mein 
compilieren 12Mhz eingestellt habe. Das Gerät wird hin und wieder mal 
angezeigt aber wird einfach nicht erkannt. Ständig meint Windows das es 
ein "unbekanntes Gerät" sei. Auf was muss ich bei V-USB genau achten 
damit ich eine Verbindung bekomme?

im Anhang mal der Spannungsteileraufbau.

Viele Grüße

Hallo,
habe jetzt auch mal den Referenzschaltplan hinzugefügt, den ich versuche 
aufzubauen, nur halt mit anderen Bauteilen.
Geht das ganze eigentlich mit 20Mhz und ein Spannungsteiler oder bewege 
ich mich in eine völlig falsche Richtung?
Ich habe übrigens die IRMP-Bauteile vollkommen weg gelassen, ich wollte 
mich erstmal mit V-USB beschäftigen und das Projekt als mein 
Referenzprojekt nehmen.

Irgendwo muss man ja Anfangen :-)

Viele Grüße

@Lars L.
Das kann so wie du es aufgezeichnet hast nicht funktionieren.
Auch habe ich einmal deine Schaltung vereinfacht nachgezeichnet.

1. Du machst einen Kurzschluss mit D+ und D-.
2. Es gehört nur D- auf ~3,6V Pegel, D+ hängt in der "Luft". Es wird nur 
der Pegel beider Datenleitungen auf 3,6V begrenzt um keine Probleme mit 
moderneren USB Host zu haben.
3. Der 1,5k Ohm Pullup bei D- ist wichtig weil ansonsten der PC nicht 
erkennt ob USB 1.11 oder USB 2.0 Device.
4. Die 68 Ohm begrenzen den Strom zwischen AVR und PC in den 
Datenleitungen, sonst nichts.

Mit Spannungsteilern das aufzubauen ist nicht so einfach und geht 
weniger gut. Der AVR spuckt 5V aus und es dürfen aber nur 3,6V an die 
Datenleitung.

Mann kann auch 2x1N4184 Dioden in die Versorgung als Spannungsabfall (5V 
- 0,6V - 0,6V = 3,8V) des AVRs hängen - wenn dieser dann noch läuft. 
Dann kann man sich die Z-Dioden an den Datenleitungen sparen.

Das einfachste ist und bleiben die 2 Z-Dioden. Die kosten dann auch 
nicht die Welt.

Und wenn du mit 12Mhz kompilierst solltest du auch einen 12Mhz Quarz 
einsetzen.

Hallo,
danke für die Antwort hat mir erstmal geholfen :-)
Also reintheoretisch und aus mein Bauchgefühl heraus müsste ich also 
zwei Spannungsteiler mit widerständen aufbauen und vermutlich noch ein 
paar Gleichrichterdioden einbringen damit es keine Rückkopplung gibt und 
die Pegel sauber an die Datenleitungen gebracht werden?
Bald ist ja wieder Geld aufn Konto da denke ich mal wird Reichelt ne 
Bestellung von mir bekommen :D

Viele Grüße
Lars

Stefan Meyer schrieb:
> Und was auch noch richtig klasse wäre: LEDs, die von einer Software
> angesteuert Zustände anzeigen. Z.B. wenn VDR auf Tuner1 aufzeichnet,
> oder wenn AC3-/DTS Ton aktiv ist, etc.

Dafür würde ich dir dieses Ding hier empfehlen:
http://www.pearl.de/a-HPM1184-5618.shtml

Dafür gibt es einen Hack und Support für VDR mit graphlcd Plugin:
http://www.vdr-portal.de/board1-news/board2-vdr-news/p1015093-announce-graphlcd-base-vdr-plugin-touchcol-branch/#post1015093

Hier noch Infos zum Hack (ist aber etwas veraltet):
http://bastel.dyndns.info/~dockstar/lcd/

Michael K. schrieb:
> Wobei die Hardware natürlich auch unter Linux lauffähig ist, eine
> entsprechende Applikation vorausgesetzt.

Ich habe einen lirc-kompatiblen Daemon auf Basis von inputlirc für den 
Receiver geschrieben, läuft ohne Probleme am VDR. Der kann natürlich die 
zusätzlichen Features nicht.

Wollte ich bei Gelegenheit mal releasen, aber die Nachfrage nach Linux 
Support war bisher eher gering außerdem habe ich meinen Receiver erst 
mal wieder eingemottet.

Ich habe den lirc-kompatiblen Daemon hier 
http://www.vdr-portal.de/board18-vdr-hardware/board13-fernbedienungen/108165-irmplircd-f%C3%BCr-usb-ir-remote-receiver-based-on-irmp 
released.

jar schrieb:
> Hintergrund, eigendlich will ich übers Netz (VNC) meinen VCR
> programmieren, brauche also vordergründig IRSND, IRMP wäre ein nettes
> Gimmik zur PC Fernbedienung, der ATmega168 ist ja groß genug für beides
> mit reichlich Protokolle

Habe ich mit meinem Sohn exemplarisch aufgebaut:

     PC -> my-AVR-USB-UART-Converter -> ATTiny85

also nicht über V-USB.

Am Attiny85 (kleiner µC mit nur 8 Pins) hängen TSOPxxxx, IR-Sendediode, 
eine LED und RX/TX - realisiert als Soft-UART. Über den Soft-UART nimmt 
der ATTiny die Sende-Befehle entgegen und "strahlt" sie mit IRSND ab. 
Empfangene IR-Frames über den TSOP sendet er über die Soft-UART an den 
PC, damit der PC "lernen" kann.

Wir haben das noch nicht veröffentlicht, weil wir im Moment nur ein 
kommandozeilen-orientiertes PC-Programm zum Senden der IR-Befehle und 
zum "Lernen" der Codes haben. Das funktioniert aber schon. Im Moment 
programmiert mein Sohn noch an der graphischen Benutzeroberfläche, 
welche eine frei gestaltbare Fernbedienung unter Windows werden soll.

Wenn Du an der Software für den µC und an dem Kommandozeilenprogramm 
interessiert bist, schreib mir eine PN, dann kann ich Dir den aktuellen 
Stand schon mal schicken. Damit solltest Du das gewünschte realisieren 
können.

Gruß,

Frank

Hallo,

Sorry fuer die dummen Fragen, aber ich habe keine Ahnung von windows und 
brauche "Starthilfe":

Ich moechte den USB_Remote_Receiver als Basis verwenden fuer eine 
Erweiterung , so dass der Empfaneger per IR oder Funk angesprochen 
werden kann und dann einen linux-PC-steuert. Ich habe bereits andere 
Anwendungen mit V-USB auf AVR mit Linux zum Spielen gebracht - wollte 
aber zuerst alles "out of the box" mit windows ausprobieren.
Ich habe die Original Sources genommen, USE_BOOTLOADER in 
configUSBIRREmoteReceiver.h auf 0 gesetzt und alles mit AVR-studio 
kompiliert. Ich hoffe, ich brauche den BootLoader nicht, denn ich weiss 
ehrlich gesagt nicht wirklich was das ist.
Ich habe das hex-file mit avrdude unter linux geflasht(ATMEGA8-16PU). 
Die fuses stehen auf 0xd0(high) und 0xe1 (low).
Wenn ich den controller per USB mit einem windows-XP host verbinde, 
erscheint die Meldung: "USB-Geraet wurde nicht erkannt". Ich habe zwar 
noch keinen IR-Empfaenger angeschlossen, aber das sollte bis hierher ja 
wohl egal sein. Daher hier meine Fragen:

1)Kann ich wie beschrieben ohne den Bootloader arbeiten?

2)Welche fuse-Einstellungen solle ich nehmen (bitte in Hex, in meinem 
GUI (avrfuse) heissen die Bits offenbar anders.

3)wie kann ich XP beibringen, die DLL zu laden?

Danke,

Wolfgang

für die Fuses:
http://www.engbedded.com/fusecalc/

Der Bootloader hat den Vorteil:
Es muss nur einmal der Bootloader mit dem Programmer programmiert 
werden. Danach kann über die DLL die Firmware einfach neu runtergespielt 
werden.
http://www.mikrocontroller.net/articles/USB_IR_Remote_Receiver#Flash.2FUpdate_Firmware_Dialog

Wenn der Empfänger am PC nicht erkannt wird:
Ist ein Programm auf dem AVR?
Ist der Pullup R1 in Ordnung?
Richtiger Quarz?

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

Wenn noch immer nichts geht dann einmal R1 von 1,5 KOhm auf 960 Ohm 
ändern.

XP kannst du gar nicht beibringen die DLL zu laden:
http://www.mikrocontroller.net/articles/USB_IR_Remote_Receiver#USB_IR_Remote_Receiver_DLL

Hallo,

ich fuerchte ich brauche noch konkretere Hilfe. Was bisher geschah:
-Ich habe die fuses geaendert auf
 Low:  0x1F
 high: 0xC1

-Ich arbeite weiterhin mit USB_BOOTLOADER = 0

-Mittlerweile scheint XP das device zu erkennen: Im Geraetemanager 
werden zwei neue USB-HID-devices als betriebsbereit angezeigt.

-Wenn ich aber .../Demo_Sources/Releases/DLL_Demo.exe anklicke bekomme 
ich ein Fenster, in dem ich nur load DLL anklicken kann. Wenn ich das 
tue, passiert nichts weiter.

-Wenn ich von der DOS-Console aus DLL_Demo_Console.exe starte, bekomme 
ich die Fehlermeldung
ERROR: unable to load DLL

Was mache ich falsch? Muss ich die DLL irgendwo hinkopieren? Welche DLL?

Sorry fuer die dummen Fragen, aber ich bin ein UNIX-Mensch und weiss von 
Windows eigentlich nur, wie man es ausschaltet.

Danke

Wolfgang

Wolfgang Buesser schrieb:

> Sorry fuer die dummen Fragen, aber ich bin ein UNIX-Mensch und weiss von
> Windows eigentlich nur, wie man es ausschaltet.

Warum nimmst du dann nicht einfach irmplircd den Daemon für Linux?

http://www.vdr-portal.de/board18-vdr-hardware/board13-fernbedienungen/108165-irmplircd-f%C3%BCr-usb-ir-remote-receiver-based-on-irmp/

Danke fuer den link. Das ist ziemlich genau das, was ich machen will!
Werde ich testen.
Mittlerweile laeufts auch unter windows (ich musste die DLL neben das 
.exe kopieren). Ein 3-zeiliges howto auf der Webseite waere vielleicht 
hilfreich.
Gibt es eigentlich zu IRSND auch einen V-USB-wrapper? So wie ich das 
verstehe stellen die sources "nur" eine subroutine zur Verfuegung.

Wolfgang

@Moto:
Dazu sind mehr Infos notwendig? Ist der Source neu kompeliert worden?
Für welche Frequenz, welche Frequenz hat der Quarz,....
Bei den Fusebits muss der 2048 Bytes Bootloader aktiviert sein...

Moto schrieb:
> ich habe mir den USB IRMP als prototyp auf lochraster nachgebaut, das
> flaschen ging einwandfrei (bootloadHID.hex aus atmaga8/default/).
> allerdings wir er jetzt von windows als unknowen device erkannt. jemand
> eine idee woran das liegen könnte?

Wie immer am Erbauer.

Habe die Schaltung laut Schaltbild aufgebaut.
(alle Teile außer Jumper und Pony-Interface)
Nur den Bootloader geflasht.

Beim Einstecken wird er bereits als HID Interface erkannt.
Also nix unbekanntes!

Die Firmware ist noch nicht drauf, nur der Bootloader!


Peter

Moto schrieb:
> Leiter bahnen sollten passen bauteile eben so. Kalte lötstellen waren
> unter dem mikroscope auch keine ersichtlich

Mein Hinweis sollte Dir dienen um den Fehler in
der selbstgebauten Hardware zu suchen.

Finden ist da wohl nicht Deine Stärke.

Antworten wie "sollten passen" sind schlecht bzw. oberflächlich.
Kalte Lötstellen und Mikroskop, haha.
Mit dem Ohmmeter "durchgeklingelt" wäre schon besser.

Der fertigen Software nicht trauen,
dann selbst kompilieren und klappt auch nicht,
meinem Hinweis auf "aufgebaut und klappt"
und den erfolgreichen vorgenannten Erfolgsmeldungen
auch keinen Glauben schenken.

Ich würde Dir ja eine Leiterplatte überlassen,
aber wenn Du die dann fehlerhaft aufbaust ziehst Du mich runter.

Peter

Stelle doch mal ein Bild Deiner Hardware hier ein.

Ich selber habe bei meinem letzen Aufbau mit der Tonertransfermethode: 
http://www.mikrocontroller.net/articles/USB_IR_Remote_Receiver#Foto_eines_aufgebauten_USB_IR_Remote_Reciever

eine TSOP4838 verwendet. Die ist um einiges kleiner als die "alte" TSOP 
1738. Geht ohne Probleme!

Wichtig für die IR-Diode ist:
>> Die maximale Versorgungsspannung muss 5V oder höher sein
>> Frequenz für das benutzte IR Protokoll (meistens 38kHz ausreichend)
>> Ausgang Active Low. Dies kann aber sicher ansonsten im IRMP Source >> 
irgendwo ausgedreht werden.

@ Andy P.
Was genau willst du denn erreichen? Aus Windows/Linux heraus IR codes 
senden, oder empfangene codes weiterreichen?

Ich arbeite gerade an einer Version, die letzteres kann und 
darüberhinaus eine Uhr zum Aufwecken des PCs und die Möglichkeit den PC 
zu resetten beinhaltet. Ich hatte aber auch schon darüber nachgedacht 
eine Funktion zum Senden von IR codes von Windows/Linux zu 
implementieren. Wäre keine große Sache mehr.

Leider kann ich nur gelegentlich abends daran arbeiten, weswegen das 
Ganze schon eine Weile dauert und auch noch eine Weile dauern wird. 
Wobei die Firmware schon recht weit ist, die Host-Software ist noch die 
größere Baustelle.

@Andy P.
schaut nicht so schlecht aus. Kann es leider nicht durchtesten da ich 
hier kein AVR 4.x Studio habe.

Der usbHidReportDescriptor scheint richtig zu sein. Die Länge passt dann 
auch.

Vom PC schickt man dann per SetFeature: 
http://msdn.microsoft.com/en-us/library/windows/hardware/ff539684(v=vs.85).aspx

die Daten zum AVR.

Der ReportBuffer ist dann:
0A   >> Report ID
02   >> Protokol ID
0000 >> Adresse
0000 >> command
00   >> Flags

1

  else if ( DoWriteReport == SndIRCodeOut )

2

  {

3

   irmp_data.protocol = IRMP_NEC_PROTOCOL;

4

     irmp_data.address  = 0x00FF;

5

     irmp_data.command  = 0x0001;

6

     irmp_data.flags    = 0;

7

     irsnd_send_data (&irmp_data, TRUE);                          // Send IR code out

8

  }

Sollte dann so sein:

1

  else if ( DoWriteReport == SndIRCodeOut )

2

  {

3

    memcpy(&irmp_data, &data[1], sizeof(irmp_data));    

4

    irsnd_send_data (&irmp_data, TRUE);                          // Send IR code out

5

  }

Ist aber nicht getestet und mit irsnd habe ich gar keine Erfahrung...
Bei Delphi ist es zusätzlich wichtig ein "Packed" Record zu verwenden.
http://www.delphibasics.co.uk/RTL.asp?Name=Packed

Ich glaub, dass ist aber Visual Studio sowieso so!?

Jetzt wirklich ungetestet, da ich hier keinen Receiver rumliegen habe!

Im AVR Source ist nun IRSND eingebaut, per USE_IRSND deaktivierbar.
Das kompelierte HEX ist für den Atmega168(p), 12MHz.
Zum IR-Senden wird PD3 verwendet.

In IRSND nur die Standard Protokolle aktiviert.

Anbei auch eine Überarbeitung der Delphi Demo wo man nun einen IR Code 
zum AVR schicken kann. (Auch nicht getestet)

Frage zwischendurch da ich IRSNd noch nie benützt habe:
Kann ich einfach eine alte Fernbedienung wegen der IR Diode 
ausschlachten!?
Muss diese über einen Transistor geschaltet werden oder kann ich die 
Diode direkt auf den Ausgang des AVRs hängen?

EDIT:
Jetzt habe ich ganz vergessen, dass dieses Projekt mit AVR Studio 5 
bearbeitet wurde!

Hugo Portisch schrieb:

> Kann ich einfach eine alte Fernbedienung wegen der IR Diode
> ausschlachten!?

Könnte funktionieren.

> Muss diese über einen Transistor geschaltet werden oder kann ich die
> Diode direkt auf den Ausgang des AVRs hängen?

Da die IR-LED gepulst betrieben wird, empfiehlt es sich, den Strom 
zwecks Reichweitenmaximierung entsprechend hochzutreiben.

Ich benutze die folgende Schaltung für IRMP seit längerem erfolgreich:

  http://www.mikrocontroller.net/articles/IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder

(Bild rechts)

Gruß,

Frank

Genau diese habe ich gesehen.

Ich habe nun eine alte Mouse geschlachtet. Da sind sogar 2+1 STK IR LEDs 
drinnen.

Die 2 kleineren können so mit 20-100mA betrieben werden. Datenblatt gibt 
es natürlich nicht da die Diode keine Beschriftung hat...

Aber meine Idee ist sowieso die IR-Dioden direkt am Empfänger 
(Fernseher, Verstärker) anzubringen. Somit ist die Reichweite kein 
Problem.
Aber ich weis nicht ob die Wellenlänge usw past - muss ich testen.

Bei 20mA brauche ich die Diode nur per Vorwiderstand an PD3 anbringen.
Der Atmega kann 40mA am Ausgang und somit könnte ich die 2 Dioden 
einfach parallel hängen. Dann einfach die 2 Codes nacheinander 
rausschicken. Der Harman Kardon Verstärker versteht das Protokoll vom 
Toshiba Fernseher sowieso nicht ;)

Also ich habe jetzt die Durchsichtige IR LED von der Mouse angebracht.
Mit einem Vorwiderstand von 200 Ohm (also ~20mA) direkt am AVR Output.
Mit dieser IR LED komme ich auf jeden Fall 1 Meter. Weiter bekomme ich 
die 2 IRMP AVRs leider nicht auseinander.

Also das nächste Mal die Mouse nicht einfach in den Müll schmeißen!
Da die IR LED auch Transparent ist sollte man sie ohne Probleme am Gerät 
anbringen können das auch noch die Fernbedienung funktioniert.

Nun habe ich aber ein "Problem" beim NEC Protokoll:

Mit der Fernbedienung werden diese Codes empfangen:
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0001, Flags: 0x00
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0002, Flags: 0x00
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0003, Flags: 0x00
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0004, Flags: 0x00
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0005, Flags: 0x00
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0006, Flags: 0x00
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0007, Flags: 0x00
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0008, Flags: 0x00
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0009, Flags: 0x00
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x5F40, Command: 0x0000, Flags: 0x00

Wenn ich es per IRSND versende:
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0001, Flags: 0x00
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0002, Flags: 0x00
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0003, Flags: 0x00
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0004, Flags: 0x00
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0005, Flags: 0x00
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0006, Flags: 0x00
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0007, Flags: 0x00
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0008, Flags: 0x00
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0009, Flags: 0x00
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x3F40, Command: 0x0000, Flags: 0x00

Man sieht, das statt 0x5F40 als Adresse 0x3F40 gesendet wird!?
Wenn ich als Adresse 0xFFFF eingebe kommt 0x7FFF an.
Das Command bei NEC scheint auch auf 0x00FF begrenzt zu sein. Wird halt 
das Protokoll selber sein.

Wenn ich die Adressen durchteste:
>> Send: 0x0FFF, Receive: 0x0FFF
>> Send: 0x1FFF, Receive: 0x1FFF
>> Send: 0x2FFF, Receive: 0x1FFF
>> Send: 0x3FFF, Receive: 0x1FFF
>> Send: 0x4FFF, Receive: 0x2FFF
>> Send: 0x5FFF, Receive: 0x3FFF
>> Send: 0x6FFF, Receive: 0x3FFF
>> Send: 0x7FFF, Receive: 0x3FFF
>> Send: 0x8FFF, Receive: 0x4FFF
>> Send: 0x9FFF, Receive: 0x5FFF
>> Send: 0xAFFF, Receive: 0x5FFF
>> Send: 0xBFFF, Receive: 0x5FFF
>> Send: 0xCFFF, Receive: 0x6FFF
>> Send: 0xDFFF, Receive: 0x7FFF
>> Send: 0xEFFF, Receive: 0x7FFF
>> Send: 0xFFFF, Receive: 0x7FFF

Meine Originale Fernbedienung vom Toshiba Fernseher sendet aber 0x5F40.
Beide Empfänger und Sender sind mit der letzten IRMP Version vom 
20.09.2011 ausgestattet.

Hugo Portisch schrieb:

>>> Send: 0x0FFF, Receive: 0x0FFF
>>> Send: 0x1FFF, Receive: 0x1FFF
>>> Send: 0x2FFF, Receive: 0x1FFF
>>> Send: 0x3FFF, Receive: 0x1FFF
>>> Send: 0x4FFF, Receive: 0x2FFF
>>> Send: 0x5FFF, Receive: 0x3FFF
>>> Send: 0x6FFF, Receive: 0x3FFF
>>> Send: 0x7FFF, Receive: 0x3FFF
>>> Send: 0x8FFF, Receive: 0x4FFF
>>> Send: 0x9FFF, Receive: 0x5FFF
>>> Send: 0xAFFF, Receive: 0x5FFF
>>> Send: 0xBFFF, Receive: 0x5FFF
>>> Send: 0xCFFF, Receive: 0x6FFF
>>> Send: 0xDFFF, Receive: 0x7FFF
>>> Send: 0xEFFF, Receive: 0x7FFF
>>> Send: 0xFFFF, Receive: 0x7FFF

Kann ich leider nicht nachvollziehen. Unter Linux bekomme ich für jede 
dieser Adressen auch diese Adresse wieder zurück, z.B.

1

 ./irsnd 2 5FFF 0001 0 | ./irmp

Ausgabe:

1

11111111111110101000000001111111 p =  2, a = 0x5fff, c = 0x0001, f = 0x00

Ich bekomme also das raus, was ich gesendet habe.

Bei Dir gehen im obersten Nibble die Bits kaputt, nämlich:

0 -> 0: 0000 -> 0000
1 -> 1: 0001 -> 0001 ???
2 -> 1: 0010 -> 0001
3 -> 1: 0011 -> 0001
4 -> 2: 0100 -> 0010
5 -> 3: 0101 -> 0011 ???
6 -> 3: 0110 -> 0011
7 -> 3: 0111 -> 0011
8 -> 4: 1000 -> 0100
9 -> 5: 1001 -> 0101 ???
A -> 5: 1010 -> 0101
B -> 5: 1011 -> 0101
C -> 6: 1100 -> 0110
D -> 7: 1101 -> 0111 ???
E -> 7: 1110 -> 0111
F -> 7: 1111 -> 0111

Bist Du Dir sicher bei den mit "???" markierten Stellen? Da hätte ich 
nämlich eine 0 statt 1 am Ende erwartet. Dann wäre es eine Division 
durch 2, d.h. eine Bitverschiebung.

So sieht es mir wie eine Verschiebung um eins, wobei das herausfallende 
Bit mit dem nun obersten "geodert" ist. Kann es sein, dass das Senden 
über V-USB da nicht ganz bit-transparent ist?

Vielleicht machst Du mal das Ganze auch mit dem Kommando, sende mal 
0xFFFF als command.

EDIT: Quatsch, das Kommando ist bei NEC auf 0x00FF beschränkt, die 
anderen 8 Bit sind zwecks Datensicherheit/Redundanz einfach invertiert. 
Also Kommando zurück. :-)

Gruß,

Frank

Danke für deine Analyse!
Habe mir schon gedacht, dass da was mit den oberen Nibble vermurkst 
wird.

Ich werde heute noch eine andere IR LED ausprobieren. Kann ja bei meiner 
nicht sicher gehen ob es an dieser liegt. ;)
Die unteren 12 Bits werden jedoch ohne Fehler übertragen.

>> EDIT: Quatsch, das Kommando ist bei NEC auf 0x00FF beschränkt, die
>> anderen 8 Bit sind zwecks Datensicherheit/Redundanz einfach invertiert.
>> Also Kommando zurück. :-)

>> Das Command bei NEC scheint auch auf 0x00FF begrenzt zu sein. Wird halt
>> das Protokoll selber sein.

In IRSND habe ich nur das NEC Protokol reingenommen. Als ich dann auch 
noch NEC16 und NEC42 reingenommen hatte funktionierte es fast gar nicht 
mehr. Werde das heute nocheinmal probieren. Ein Debug kann ich leider 
nicht machen somit kann ich mich nur darauf verlassen, dass mir IRMP die 
richtigen Daten gibt und das 0x5F40 überhaupt stimmt.

Einen Fehler bei der Datenübergabe konnte ich nicht finden. Werde es mir 
nocheinmal ansehen.

Ich glaube ich muss mir morgen mal einen MAX2322 dranbauen ;)

Ich habe nun hier einen Empfänger mit nur IRMP und 20000 für 
F_INTERRUPTS.
Auch habe ich noch einen Sender mit IRMP und IRSND auch mit F_INTERRUPTS 
= 20000.

Beim Empfänger habe ich alle Protokolle für IRMP aktiviert.
Beim Sender habe ich alle Protokolle für IRMP deaktiviert und alle für 
IRSND aktiviert.

Nun sende ich von Protkoll 1-30 immer Adresse 0xFFFF, Command 0xFFFF, 
Flags 0x00. (Egal ob das Protokoll die vollen 16 Bits kann oder nicht)

IRMP empfängt das:
Irmp Version: 20.09.2011
>> Protocol : IRMP_NEC_PROTOCOL, Address: 0x7FFF, Command: 0x00FF, Flags: 0x00
>> Protocol : IRMP_SAMSUNG_PROTOCOL, Address: 0xFFFF, Command: 0x0FFF, Flags: 0x00
>> Protocol : IRMP_MATSUSHITA_PROTOCOL, Address: 0x0FFF, Command: 0x0FFF, Flags: 
0x00
>> Protocol : IRMP_KASEIKYO_PROTOCOL, Address: 0xFFFF, Command: 0xFFFF, Flags: 
0x00
>> Protocol : IRMP_RECS80_PROTOCOL, Address: 0x0007, Command: 0x003F, Flags: 0x00
>> Protocol : IRMP_RC5_PROTOCOL, Address: 0x001F, Command: 0x007F, Flags: 0x00
>> Protocol : IRMP_DENON_PROTOCOL, Address: 0x001F, Command: 0x0000, Flags: 0x00
>> Protocol : IRMP_RC6_PROTOCOL, Address: 0x0000, Command: 0x0000, Flags: 0x00
>> Protocol : IRMP_SAMSUNG32_PROTOCOL, Address: 0xFFFF, Command: 0xFFFF, Flags: 
0x00
>> Protocol : IRMP_RECS80EXT_PROTOCOL, Address: 0x000F, Command: 0x003F, Flags: 
0x00
>> Protocol : IRMP_NUBERT_PROTOCOL, Address: 0x0000, Command: 0x03FF, Flags: 0x00
>> Protocol : IRMP_NOKIA_PROTOCOL, Address: 0x00FF, Command: 0x00FF, Flags: 0x00
>> Protocol : IRMP_FDC_PROTOCOL, Address: 0x003F, Command: 0x03FF, Flags: 0x00
>> Protocol : IRMP_RCCAR_PROTOCOL, Address: 0x0003, Command: 0x07FF, Flags: 0x00
>> Protocol : IRMP_JVC_PROTOCOL, Address: 0x000F, Command: 0x0FFF, Flags: 0x00
>> Protocol : IRMP_RC6A_PROTOCOL, Address: 0x3FFF, Command: 0x7FFF, Flags: 0x00
>> Protocol : IRMP_NEC16_PROTOCOL, Address: 0x00FF, Command: 0x00FF, Flags: 0x00
>> Protocol : IRMP_NEC42_PROTOCOL, Address: 0x1FFF, Command: 0x00FF, Flags: 0x00
>> Protocol : IRMP_THOMSON_PROTOCOL, Address: 0x000F, Command: 0x007F, Flags: 0x00

Man sieht es fehlen ein paar Protokolle - kann am Empfänger oder Sender 
liegen - derzeit nicht so wichtig.

Mann kann erkennen wie z.B. beim SAMSUNG32 die 16 Bits korrekt 
übertragen werden.

Nochmal zum IRMP Logging!
>> irmp_log (uint8_t val)

Mit wievielen startcycles ist den zu rechnen?

Ich bin der Überlegung nahe, den buf[700] von der irmp.c in die irmp.h 
zu verlegen. Somit habe ich von meiner main.c auch darauf Zugriff.

Meine Idee ist statt der Ausgabe über den UART die Daten per USB zu 
übertragen.

Wegen den 700 Bytes ist das aber nicht so einfach:
Zuerst füllt IRMP den buf.
Statt der Ausgabe auf den UART (cnt > ENDBITS) wird dem Host per 
usbSetInterrupt bescheidgegeben das Daten verfügbar sind.
buf muss hier gelocked werden. Ansonsten würden weitere 700 Bytes nötig 
sein.
Der Host holt sich dann über ein GetFeature selber die Daten vom Device 
(Example VUSB: HID Data).
Nun kann der buf wieder freigeben werden um weitere Daten zu loggen.
Danach soll der Host die Daten in die '0' und '1' zerlegen um mit IRMP 
kompatible zu sein.

EDIT:
>> for (i = 0; i < STARTCYCLES; i++)

STARTCYCLES ist ja eh eine Konstante (2) und somit muss ich die 
beginnenden '0' nicht übertragen werden.

Hugo Portisch schrieb:

> Mit wievielen startcycles ist den zu rechnen?

Das kommt aufs Protokoll an. Bei RECS80 sind es ganz wenige, bei NEC 
sind es einige dutzend. Hier soll eigentlich nur verhindert werden, dass 
kurze Störungen, die durchaus beim TSOP auftreten, nicht versehentlich 
den Scan triggern.

> Ich bin der Überlegung nahe, den buf[700] von der irmp.c in die irmp.h
> zu verlegen. Somit habe ich von meiner main.c auch darauf Zugriff.

Kannst Du natürlich machen. Ich würde den buf aber nicht verlagern, 
sondern lediglich aus der log-Funktion rausziehen und damit global 
machen, z.B. mit

1

   uint8_t  irmp_log_buf[DATALEN];

und dann in irmp.h ein:

1

   extern uint8_t  irmp_log_buf[DATALEN];

> Meine Idee ist statt der Ausgabe über den UART die Daten per USB zu
> übertragen.

Ja, schon klar :-)

> Wegen den 700 Bytes ist das aber nicht so einfach:

Oft reichen schon 256 Bytes aus, um einen kompletten Frame einzufangen.

> STARTCYCLES ist ja eh eine Konstante (2) und somit muss ich die
> beginnenden '0' nicht übertragen werden.

Das ist richtig, spart 2 Bytes ;-)

Warum benutzt Du eigentlich für F_INTERRUPTS den Wert 20000? Gehe besser 
mal auf 15000 runter. Sollte eigentlich reichen und auch den erzeugten 
Code verkleinern, da dann teiweise 8-Bit-Counter (statt 16-Bit) reichen.

Vielleicht als Anregung:

Um den Fehler zu finden, würde ich erstmal checken, ob die 
USB-Kommunikation bzgl. µC-Richtung korrekt funktioniert. Du könntest 
einfach mal als Hack die IRMP_DATA-Struct an IRSND übergeben, welches 
die über USB empfangenen Werte dann einfach wieder über USB 
zurückschickt. Wenn das 1:1 funktioniert, tippe ich auf einen Fehler im 
IRSND. Aber komischerweise kann ich den nicht reproduzieren...

Gruß,

Frank

Frank M. schrieb:
> Warum benutzt Du eigentlich für F_INTERRUPTS den Wert 20000? Gehe besser
> mal auf 15000 runter. Sollte eigentlich reichen und auch den erzeugten
> Code verkleinern, da dann teiweise 8-Bit-Counter (statt 16-Bit) reichen.

Nur mal so zu Erinnerung: ich hatte schon mehrfach berichtet, dass der 
Empfang mit INTERRUPTS != 10000 nicht funktioniert (zumindest bei mir). 
Evtl. ist das beim senden genauso.

>> Vielleicht als Anregung:

>> Um den Fehler zu finden, würde ich erstmal checken, ob die
>> USB-Kommunikation bzgl. µC-Richtung korrekt funktioniert. Du könntest
>> einfach mal als Hack die IRMP_DATA-Struct an IRSND übergeben, welches
>> die über USB empfangenen Werte dann einfach wieder über USB
>> zurückschickt. Wenn das 1:1 funktioniert, tippe ich auf einen Fehler im
>> IRSND. Aber komischerweise kann ich den nicht reproduzieren...

Danke für den Tipp! Der war schnell umgesetzt.

1

  #if USE_IRSND

2

  } 

3

  else if ( DoWriteReport == SndIRCodeOut )                        // send received ir code from host

4

  {

5

    memcpy(&irmp_data, &data[1], sizeof(irmp_data));

6

    //irsnd_send_data(&irmp_data, FALSE);                          // Send IR code out  

7

    SendINTData();

8

  #endif

9

  }

Es werden also die Daten vom Host gleich wieder 1:1 an den Host 
zurückgeschickt ohne über IRSND oder IRMP:

Send: Protocol : IRMP_NEC_PROTOCOL, Address: 0xFFFF, Command: 0xFFFF, 
Flags: 0x00
Receive: Protocol : IRMP_NEC_PROTOCOL, Address: 0xFFFF, Command: 0xFFFF, 
Flags: 0x00

Und auch Danke für den Tipp mit irmp_log_buf!
Bin einfach kein C++ Programmierer...


>> Warum benutzt Du eigentlich für F_INTERRUPTS den Wert 20000? Gehe besser
>> mal auf 15000 runter. Sollte eigentlich reichen und auch den erzeugten
>> Code verkleinern, da dann teiweise 8-Bit-Counter (statt 16-Bit) reichen.

Das hatte ich nur drinnen, damit alle Protokolle auf dem AVR sind.
Heute habe ich aber gemerkt, dass eine Fernbedienung mit SIRCS nur gut 
mit 10000 funktioniert. Bei 15000 kommt nichts gutes mehr raus.


>> Nur mal so zu Erinnerung: ich hatte schon mehrfach berichtet, dass der
>> Empfang mit INTERRUPTS != 10000 nicht funktioniert (zumindest bei mir).
>> Evtl. ist das beim senden genauso.

Tut leid. ich bin mit IRMP Artikel nicht so Uptodate ;)
Ich habe jetzt Sender UND Empfänger auf 10000 eingestellt.
Nun geht es:
Protocol : IRMP_NEC_PROTOCOL, Address: 0xFFFF, Command: 0x00FF, Flags: 
0x00

Wenn nur IRSND auf 10000 war und IRMP auf 15000-20000. Ging es auch 
nicht ohne Fehler. Wenn beide auf 10000 eingestellt sind geht es!

Gut das dass jetzt geht! Dann kann ich mir jetzt mit dem Logging 
einbauen etwas Zeit lassen ;)


Ich bin auch noch auf keine Idee gekommen wie das mit IRSND am besten 
umgesetzt werden soll:
Wie erkennt der AVR ob der PC nun läuft oder aus ist!?
Mein AVR Verstärker hat einen extra Code für Ein und Aus. Somit muss das 
erkannt werden.
Dann wär es besser wenn die IR Codes für IRSND im EEPROM hinterlegt sind 
damit IRSND gleich beim Einschalten des PCs auch die anderen Geräte 
einschalten kann ohne erst auf ein Commando vom Host zu warten.
Dann bräuchte man auch noch eine variable Verzögerung (0-10 Sekunden 
z.B) beim IRSND. Den ich muss dank HDMI meinen Fernseher nach dem PC 
Ausschalten und beim Einschalten vor dem PC - sonst kommt es zu 
Problemen. usw usw...

Danke vielmals! Wünsche noch schöne Feiertage!

Hugo Portisch schrieb:
> Tut leid. ich bin mit IRMP Artikel nicht so Uptodate ;)
Das war hier im Thread nicht bei IRMP.

> Ich habe jetzt Sender UND Empfänger auf 10000 eingestellt.
> Nun geht es:
> Protocol : IRMP_NEC_PROTOCOL, Address: 0xFFFF, Command: 0x00FF, Flags:
> 0x00
>
> Wenn nur IRSND auf 10000 war und IRMP auf 15000-20000. Ging es auch
> nicht ohne Fehler. Wenn beide auf 10000 eingestellt sind geht es!

Ok, jetzt weiß ich wenigstens, dass es nicht an meinem Empfänger liegt, 
sondern ein prinzipielles Problem ist. Es wäre schön zu wissen, woran 
das liegt, da manche Protokolle nicht mit F == 10000 funktionieren.

Ging besser und schneller als ich mir gedacht habe!
Der Source ist noch nicht ganz sauber und es müsste auch in IRMP was 
angepasst werden... ;)

Aber zuerst einmal ein Beispiel um Überprüfen zu können ob die Daten 
überhaupt stimmen:

1

Protocol : IRMP_NEC_PROTOCOL, Address: 0xBF40, Command: 0x0001, Flags: 0x00

2

ReportID : NewLogAvailable, 0x0B, Data Length (Bits) : 0x0890

3

Read IRMP Log Buffer is done

4

Data : 

5

00000000000000000000FFFFFFFFFF0F7CC0073EF0810F7CC0FF3FF081FF7FC0

6

FF3FF0FF0FFCFF03FEFF81FF7FE003FEFF81FF7FE0031FF8810F7CE0031FF881

7

FF7FE0FF1FF8FF0FFCFF03FFFFC0FF7FE0FF1FF8FFFFFFFFFFFFFFFFFFFFFFFF

8

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

9

FFFFFFFFFF0100000000000000000000F0FFFF81FFFFFFFFFFFFFFFFFFFFFFFF

10

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0000000000

11

0000000000000000000000000000000000000000000000000000000000000000

12

0000000000000000000000000000000000000000000000000000000000000000

13

000000000000000000000000000000000000

14

15

Protocol : IRMP_NEC_PROTOCOL, Address: 0xBF40, Command: 0x0001, Flags: 0x00

16

ReportID : NewLogAvailable, 0x0B, Data Length (Bits) : 0x0890

17

Read IRMP Log Buffer is done

18

Data : 

19

00000000000000000000FFFFFFFFFF0F7CC0073EF0810F7CE0FF3FF081FF7FE0

20

FF3FF0FF0FFCFF03FFFF80FF7FE003FFFF80FF7FE0031FF8800F7CE0031FF880

21

FF7FE0FF1FF8FF0FFCFF03FFFFC0FF7FE0FF1FF8FFFFFFFFFFFFFFFFFFFFFFFF

22

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

23

FFFFFFFFFF0100000000000000000000F8FFFF81FFFFFFFFFFFFFFFFFFFFFFFF

24

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0000000000

25

0000000000000000000000000000000000000000000000000000000000000000

26

0000000000000000000000000000000000000000000000000000000000000000

27

000000000000000000000000000000000000

28

29

Protocol : IRMP_NEC_PROTOCOL, Address: 0xBF40, Command: 0x0002, Flags: 0x00

30

ReportID : NewLogAvailable, 0x0B, Data Length (Bits) : 0x0891

31

Read IRMP Log Buffer is done

32

Data : 

33

00000000000000000000FFFFFFFFFF0FFCC0073EF0810F7CC0FF3FF081FF7FE0

34

FF3FF0FF0FFCFF03FEFF81FF7FE003FFFF810FFCFF031FF0810F7CE0031FF0FF

35

0F7CE0FF1FF8FF0FFCFF03FFFFC0FF3FE0FF1FF8FFFFFFFFFFFFFFFFFFFFFFFF

36

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

37

FFFFFFFFFF0300000000000000000000F0FFFF01FFFFFFFFFFFFFFFFFFFFFFFF

38

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0000000000

39

0000000000000000000000000000000000000000000000000000000000000000

40

0000000000000000000000000000000000000000000000000000000000000000

41

000000000000000000000000000000000000

42

43

Protocol : IRMP_NEC_PROTOCOL, Address: 0xBF40, Command: 0x0002, Flags: 0x00

44

ReportID : NewLogAvailable, 0x0B, Data Length (Bits) : 0x0890

45

Read IRMP Log Buffer is done

46

Data : 

47

00000000000000000000FFFFFFFFFF1FF8C0073EF0811FF8C0FF3FF081FF7FC0

48

FF3FF0FF0FFCFF07FEFF81FF7FC003FEFF810FFCFF033EF0810F7CE0033EF0FF

49

0F7CE0FF3FF0FF0FFCFF03FFFF81FF7FE0FF1FF8FFFFFFFFFFFFFFFFFFFFFFFF

50

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

51

FFFFFFFFFF0100000000000000000000F8FFFF81FFFFFFFFFFFFFFFFFFFFFFFF

52

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0000000000

53

0000000000000000000000000000000000000000000000000000000000000000

54

0000000000000000000000000000000000000000000000000000000000000000

55

000000000000000000000000000000000000

Die DataLength = buf_idx, sollten also Bits sein.
Die Daten sind der Inhalt von buf[DATALEN].

Stimmt das und wenn ja, was kommt Binär raus. Nur damit ich dann die 
Umwandlung in den Binären String richtig mache ;)

EDIT:
Damit ich es gleich testen kann!
Hier ein Log von der OK Taste meiner Toshiba Fernbedienung. IRMP erkennt 
sie nicht, einen Log bekomme ich aber:

1

ReportID : NewLogAvailable, 0x0B, Data Length (Bits) : 0x068C

2

Read IRMP Log Buffer is done

3

Data : 

4

00000000000000000000FFFFFFFFFF0FFCC0073EF0810F7CE0FF3FF081FF7FE0

5

FF1FF0FF0FFCFF03FEFF81FF7FE003FFFF81FF7FE0031FF8810FFCFF031FF881

6

0FFCFF03FFFFC0FF7FE0FF1FF8C0FF7FE0FF1FF8FFFFFFFFFFFFFFFFFFFFFFFF

7

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

8

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

9

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0000000000

10

0000000000000000000000000000000000

Hugo Portisch schrieb:
> Heute habe ich aber gemerkt, dass eine Fernbedienung mit SIRCS nur gut
> mit 10000 funktioniert. Bei 15000 kommt nichts gutes mehr raus.

Wahrscheinlich gibt es da Timing-Probleme im Zusammenhang mit V-USB. 
IRMP/IRSND funktionieren eigentlich ganz gut sowohl bei 10kHz, 15kHz und 
auch bei 20kHz. Die Belastung des µCs steigt natürlich. Wahrscheinlich 
kommen sich da irgendwann V-USV und IRMP in die Quere...

> Wenn nur IRSND auf 10000 war und IRMP auf 15000-20000. Ging es auch
> nicht ohne Fehler. Wenn beide auf 10000 eingestellt sind geht es!

Ich benutze bei meinen Anwendungen meist 15kHz und habe diese Probleme 
dabei nicht.

Gruß,

Frank

Hugo Portisch schrieb:
> Stimmt das und wenn ja, was kommt Binär raus. Nur damit ich dann die
> Umwandlung in den Binären String richtig mache ;)

Die IRMP-Log-Funktion schiebt nur Nullen und Einsen auf dem UART raus, 
d.h. die Umwandlung in den "Binärstring" erfolgt noch auf dem µC. Bei 
der USB-Übertragung könntest Du diese Umwandlung erst auf dem PC machen, 
das schrumpft die zu übertragene Datenmenge auf ein Achtel.

> Hier ein Log von der OK Taste meiner Toshiba Fernbedienung. IRMP erkennt
> sie nicht, einen Log bekomme ich aber:

Ich wandle das mal in einen "Binärstring" und schicke es anschließend in 
den IRMP. Mal schauen, was da rauskommt.

Gruß,

Frank

Ich habe einen Deiner Logs mit folgendem C-Progrämmchen unter Linux in 
einen "Binärstring" gewandelt:

1

#include <stdio.h>

2

3

static void

4

hex2bin (int value)

5

{

6

    int i;

7

8

    for (i = 0; i < 8; i++)   // send LSB first!

9

    {

10

        if (value & (1<<i))

11

        {

12

            putchar ('1');

13

        }

14

        else

15

        {

16

            putchar ('0');

17

        }

18

    }

19

}

20

21

int

22

main ()

23

{

24

    int value;

25

26

    while (scanf ("%02x", &value) == 1)

27

    {

28

        hex2bin (value);

29

    }

30

    putchar ('\n');

31

32

    return (0);

33

}

Dieses dann compiliert als hex2bin und anschließend folgendes 
aufgerufen:

./hex2bin <usblog.txt | ./irmp

Dabei kam dann folgendes raus:

1

00000010111111010100000010111111 p =  2, a = 0xbf40, c = 0x0002, f = 0x00

2

                                 p =  2, a = 0xbf40, c = 0x0002, f = 0x01

(Die 2. Zeile ist ein NEC-Repetition-Frame)

Der Logbuffer hat also einen korrekten Inhalt. Was mir aber aufgefallen 
ist, dass Du wohl den kompletten Log-Buffer sendest. Dadurch werden am 
Ende noch jede Menge Nullen geschickt, die da nicht hingehören. Du 
solltest daher noch die gefüllte Länge des Log-Buffers berücksichtigen. 
Das ist insb. dann wichtig, wenn später der Logbuffer ein zweites Mal 
verwendet wird, aber der Frame kürzer ist. Dann würdest Du noch den 
verbliebenen (noch nicht überschriebenen) Rest des ersten Frames als 
Datenschrott mitsenden.

Am Schluss habe ich den Frame getestet, den IRMP bei Dir nicht erkennen 
konnte. Bei mir hat IRMP den Frame direkt erkannt.

Ausgabe:

1

00000010111111011000010001111011 p =  2, a = 0xbf40, c = 0x0021, f = 0x00

Das verstehe ich nicht.

Gruß,

Frank

Danke!

Jetzt stehe ich aber etwas auf dem Schlauch!
Linux hab ich keines um es nachzustellen.
Aber soweit ich sehe wandelst du den Datenbuffer in einen Binären String 
und lässt in gleich mit IRMP auswerten.

Wenn ich die Daten in einen Binären String Umwandle komme ich auf diesen 
String:

1

000000000000000000000000000000000000000000000000000000000000000000000000000000000000111111111111111111111111111111111111111100001111011111001100000000000111001111101111000010000001000011110111110011000000111111110011111111110000100000011111111101111111110000001111111100111111111100001111111100001111111111001111111100000011111111101111111110000001111111110111111111100000000000111111111011111111100000011111111101111111111000000000001100011111111110001000000100001111011111001110000000000011000111111111100010000001111111110111111111100000111111110001111111111000111111110000111111111100111111110000001111111111111111111100000011111111011111111110000011111111000111111111100011111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

Das ist jetzt vom ersten Log mit Command 0x01. Zusätzlich fehlt aber 
noch am Anfang ein '00' (STARTCYCLES).

Stimmt diese Übersetzung? Kann IRMP diesen Binär String richtig 
auswerten?
Kann es leider wegen fehlendem Linux selber nicht testen.

>> Was mir aber aufgefallen
>> ist, dass Du wohl den kompletten Log-Buffer sendest. Dadurch werden am
>> Ende noch jede Menge Nullen geschickt, die da nicht hingehören.

Oben die Logs sind zu lang, stimmt!
Der AVR sendet per Interrupt die Anzahl Bits (buf_idx) an den Host.
Danach holt sich der Host die Daten. Derzeit holt er sich dann immer 700 
Bytes wegen der Buffergröße. Ich habe noch nicht Probiert, wie V-USB 
darauf reagiert wenn ich jetzt nur 250 Bytes hole...

Der Buffer[700] wird aber dann mit buf_idx gekürzt. Und da ist mir oben 
ein Fehler untergekommen. Ich habe alle Bits von buf_idx genommen. 
eigentlich brauche ich aber nur: buf_idx - 1000 + 20 Bits.
Also aus 0x890 werden 0x4BC Bits. Dann sind hinten auch keine Nullen 
mehr drann.

>> Am Schluss habe ich den Frame getestet, den IRMP bei Dir nicht erkennen
>> konnte. Bei mir hat IRMP den Frame direkt erkannt.

Ich glaube da habe ich mir wieder selber ein Ei gelegt. Ich glaube meine 
PowerOn Funktion hat den Code gesperrt...

Hugo Portisch schrieb:

> Linux hab ich keines um es nachzustellen.

Es ging mir ja nur ums Prinzip.

> Wenn ich die Daten in einen Binären String Umwandle komme ich auf diesen
> String:
>

1

000000000000000000...

Dieser ist nicht korrekt. Du hast die Bytes mit MSB first in den 
Binärstring gewandelt, Du musst es aber mit LSB first machen, deshalb 
hatte ich oben in meiner Funktion hex2bin() extra den Kommentar gesetzt 
;-)

Also: Erst das unterste Bit rausschreiben, das höchstwertigste erst am 
Schluss eines jeden Bytes.

> Das ist jetzt vom ersten Log mit Command 0x01. Zusätzlich fehlt aber
> noch am Anfang ein '00' (STARTCYCLES).

Ja, die beiden Nullen sollten auch noch mit rein. Und dann am Ende noch 
ein '\n' um die Zeile abzuschließen. Wenn Du dann noch vor Deine eigenen 
Kommentar-Ausgaben noch ein Kommentarzeichen '#' setzt, wäre es perfekt.

Siehe dazu auch die Beispiel-Log-Dateien unter IR-Data/*.txt

> Kann es leider wegen fehlendem Linux selber nicht testen.

Eine irmp.exe für Windows ist im IRMP-Paket dabei, Du kannst das also 
testen mit

   irmp.exe <irgendwas.txt

bzw.

   irmp.exe -v <irgendwas.txt

> Der Buffer[700] wird aber dann mit buf_idx gekürzt. Und da ist mir oben
> ein Fehler untergekommen. Ich habe alle Bits von buf_idx genommen.
> eigentlich brauche ich aber nur: buf_idx - 1000 + 20 Bits.
> Also aus 0x890 werden 0x4BC Bits. Dann sind hinten auch keine Nullen
> mehr drann.

Prima.

> Ich glaube da habe ich mir wieder selber ein Ei gelegt. Ich glaube meine
> PowerOn Funktion hat den Code gesperrt...

:-))))

Gruß,

Frank

>> Is it something else that should be enabled in the configuration besides
>> enabling the RC6 code?

No, I don't think so.
But I remember that there where some problems with RC6 and IRMP because 
of missing logs/hardware. I don't know if this got already fixed.
You can try to clear the trained poweron code by the options dialog of 
the dll. After this again the first decoded IR code will be stored as 
poweron code. Or you deaktivate the PowerOn function and check if the 
received IR code is changing when pressing the button multiple times on 
the remote.

If this will not help:
I currently working on implementing the IR log function by USB.

For this I uploaded a beta for Atmega168(p) and Atmega8.
Flash this HEX file on the device and use the new included 
'USB_IR_Remote_Receiver_Demo.exe' from the archive.
Each received IR code will be stored in a text file 'IRMP_Log.txt' 
located in the same folder like the exe. This text file can be decoded 
by 'irmp.exe' (included in the IRMP package) itself:

>> D:\Eigene Datein\VB\AVR_IRMP>irmp.exe <IRMP_Log.txt
>> -------------------------------------------------------------------
>> # OK
>> -------------------------------------------------------------------
>> # 29.12.11 15:35:55
>> 00000010111111011000010001111011 p =  2, a = 0xbf40, c = 0x0021, f = 0x00

Please remember that the poweron function will block the trained code. 
So may clear the trained code and use another dummy button on the remote 
- just for logging.

Ich habe nun den Artikel USB IR Remote Receiver wieder etwas 
überarbeitet.

Neu: IRMP Logging über die USB Schnittstelle.
Es können nun die Rohdaten des IR Signals auch über USB (vorher nur über 
RS232) geloggt werden. Dazu einfach den Source mit IRMP_LOGGING = 1 neu 
kompilieren.

Ich hoffe ich bekomme nicht zu viel haue von Frank M. weil ich sein IRMP 
etwas "plump" umgeschrieben habe... ;)

erwin@DVBViewer schrieb:
> Für
>
> EventGhost fehlten mir bisher die Informationen. Die wollte ich mir nun
>
> aus der Source von USB_IR_Remote_Receiver.dll raussuchen. Die ist im
>
> Download nicht dabei?

Hallo erwin!

Nein, der Source der DLL ist nicht mit dabei. Die DLL selber hat aber 
auch nichts mit EventGhost zu tun. Dafür ist das Plugin "__init__.py" 
zuständig.
Dieses Plugin lädt die DLL wie ein normales Programm über die 
"InitPAnsiChar" Funktion. Über eine Callback Funktion werden die Daten 
an EventGhost übergeben. Die InitPAnsiChar und InitNative sind für 
externe/andere Programme damit sie die DLL verwenden können. (Die 
Funktionen sind im PDF beschrieben)

Dieses Plugin habe ich selber aus verschiedene Plugins die bei 
EventGhost dabei waren zusammen gebaut...

Hugo Portisch schrieb:
> Neu: IRMP Logging über die USB Schnittstelle.
> ...
> Ich hoffe ich bekomme nicht zu viel haue von Frank M. weil ich sein IRMP
> etwas "plump" umgeschrieben habe... ;)

Hast Du das mit Frank abgestimmt, damit er die Änderungen übernimmt? 
Jetzt kann man den IRMP-Teil im Receiver nicht mehr so ohne weiteres via 
DropIn-Update aktualisieren.
Prinzipiell ist das USB-Logging eine gute Sache, mich stört aber der 
IRMP-Fork.

Dirk W. schrieb:
> Hast Du das mit Frank abgestimmt, damit er die Änderungen übernimmt?

Hugo hatte mich wg. dem Logging bereits vor Weihnachten angeschrieben, 
ich hatte aber über die Feiertage keine Zeit, ihm zu antworten. So hat 
er es erstmal allein eingebaut, um es überhaupt schon mal zum Laufen zu 
bekommen.

Ich werde mir Hugos Änderungen näher anschauen und dann in Abstimmung 
mit ihm versuchen, eine allgemeinere Lösung für das USB-Logging zu 
finden, so dass der Source weiterhin einheitlich bleibt.

> Jetzt kann man den IRMP-Teil im Receiver nicht mehr so ohne weiteres via
> DropIn-Update aktualisieren.

Das wird demnächst wieder gehen, keine Sorge.

> Prinzipiell ist das USB-Logging eine gute Sache, mich stört aber der
> IRMP-Fork.

Es wird keinen Fork geben. Hugo hat da nichts im Alleingang gemacht. 
Betrachte Hugos Implementation des Loggings über USB erstmal als ersten 
Prototyp.

Gruß,

Frank

P.S.
Ich verfolge diesen Thread sowieso, bin daher immer auf dem Laufenden 
:-)

Ok, das hört sich gut an :)

Frank M. schrieb:
> Es wird keinen Fork geben. Hugo hat da nichts im Alleingang gemacht.
> Betrachte Hugos Implementation des Loggings über USB erstmal als ersten
> Prototyp.
>
> Gruß,
>
> Frank

Danke!

Genau so war es gedacht!
Ich habe um es erst einmal überhaupt umzusetzen etwas unschön so 
umgebaut.
Ist nicht Sinn der Sache das es so bleibt.

Mit einem neuem IRMP_LOGGING_USB Kompilerswitsch in der irmpconfig.h 
könnte man das schon gut lösen. Aber wie gesagt - ich bin hier nicht der 
richtige um das zu Entscheiden (auch zwecks fehlendem können)

@erwin
> Ich schicke mal voraus: Python ist total neu für mich.
War es für mich auch. war eine ganz schöne Bastelei um das Plugin für 
EventGhost zu schreiben.

Beim Start von EventGhost werden alle Plugins in den Unterordnern 
gesucht ("__init__.py"). Je nach optionen wird dann das Plugin geladen 
oder halt nicht.

Hallo,

ich habe schon länger nach einer Lösung gesucht um meinen guten alten 
seriellen PIC12c509 IR-Empfänger zu ersetzen der schon gut 12 Jahre alt 
ist. Dabei bin ich nun hier über das geniale Projekt gestolpert, 
allerdings hatte ich mir in den Kopf gesetzt das ganze auf 
minimalistischer Hardware laufen zu lassen. Das könnte ggf. auch für 
andere interessant sein, deshalb habe ich das mal zusammengeschrieben.


Ich habe Hugos aktuelle Quellen angepasst (USB Infrarot Receiver V1.8 
vom 02.01.2012), so dass sie sich für einen ATtiny85 kompilieren lassen.

Viel war wirklich nicht mehr zu tun - was gefehlt hat war neben kleinen 
Änderungen durch die andere Hardware die Synchronisierung für V-USB, das 
wollte zunächst einfach nicht funktionieren bis ich über George 
Ruinellis Seite gestolpert bin, er hat hier beschrieben was für den 
ATtiny fehlt:
http://www.ruinelli.ch/how-to-use-v-usb-on-an-attiny85

Vorhanden war bereits ein "USB-Dongle" welches bislang nur mal zur 
Belustigung von Kollegen diente ("Capslocker"), daran habe ich lediglich 
einen Infrarotempfänger angelötet. Der Schaltplan ist als Bild im 
angehängten Zip enthalten, das soll nicht als Referenzdesign dienen, 
siehe Warnungen :)

Eckdaten:
* der ATtiny85 ohne Quarz mit V-USB, mit dem internen Oszillator
  bei 12.8MHz
* IRMP mit 15k Interrupts/s (andere Werte habe ich nicht getestet)

Im Gegensatz zur Originalhardware nicht vorhanden sind derzeit:
- Bootloader
- Remote-Wakeup

Getestete Fernbedienungen (IR-Protokolle):
* Standard Hauppauge (RC5)
* Panasonic TV (KASEIKYO)
* mit Tevii Sat-Karte gelieferte Fernbedienung (NEC)

PC-seitig auf einem Linux-PC in Verwendung:
* irmplircd von Dirk W. als 1:1-Ersatz für den original lircd
* lirc-clients: VDR und lircrc/irexec

Das ganze läuft hier seit zwei Tagen störungsfrei und hat meinen
seriellen Empfänger somit einfach 1:1 ersetzt.


Ein paar Warnungen zum Schaltplan:
- Der ATtiny läuft bei ~3.6V / 12.8MHz außerhalb der Atmel-Spec, die
  Spannungsreduktion mit zwei Dioden statt Verwendung von Z-Dioden in
  D+/D- ist eine Notlösung weil ich schlicht keine hatte als ich das
  zusammengelötet habe - aber lieber die USB-Spec als die Atmel-Spec
  erfüllen wollte um meine restliche Hardware zu schützen. Status:
  "works for me", keine Garantie.

- aktuell benutze ich statt dem beschriebenen TSOP1738 einen unbekannten
  angesteckten IR-Empfänger (mit 1.2m Kabel und 3.5mm Klinke, wurde bei
  einer Sat-Karte mitgeliefert). Meinen letzten TSOP1738 habe ich mir
  aus Versehen zerschossen, und zerschneiden möchte ich das Kabel des
  Empfängers nicht, deshalb ist der Chip unbekannt. Der IR-Empfänger ist
  aber ebenfalls Active Low und die Schaltung sollte damit auch
  problemlos mit den TSOPxxxx laufen


Die im Zip-File enthaltenen Dateien können entweder einfach so 1:1 in 
Hugos Originalsourcen kopiert werden und lassen sich dort mit einem 
"make" von avr-gcc übersetzen, ein kleines aus V-USB übernommenes 
Makefile ist vorhanden. AVR Studio benutze ich nicht, für meine Zwecke 
war das bislang nie nötig, ich verwende hier einen Debian-PC mit avr-gcc 
V4.3.5 und avr-libc v1.6.8.

Ich habe mir Mühe gegeben die Änderungen minimalinvasiv durchzuführen 
und frage über Direktiven ab für welchen Controller kompiliert wird, der 
Source übersetzt sich hier genauso wenn ich atmega8 / 12MHz einstelle, 
die wenigen Änderungen könnten also theoretisch auch im 
Originalsourcecode übernommen werden falls Interesse besteht -> Hugo, 
ich weiss nicht was Du davon hälst.

Das Verzeichnis "libs-device" stammt aus den aktuellen V-USB - Quellen.

Da der AtTiny85 nur PORTB besitzt ändert sich natürlich auch die Config, 
hier bin ich mir auch nicht sicher ob es Sinn macht so etwas über 
Direktiven abzufragen, ich habe es jetzt mal so umgesetzt. Feedback ist 
gerne gesehen.


Gruß,
Lars

Lars, coole Sache und danke für dein Feedback. Besonders interessant 
finde ich, dass bei dir der Empfänger auch mit 15k HZ läuft. Den 
ruinelli Link zum Sync sollte man sich wohl näher anschauen, evtl 
klappts dann auch künftig mit F != 10k HZ

Lars Bürding schrieb:
> Originalsourcecode übernommen werden falls Interesse besteht -> Hugo,
>
> ich weiss nicht was Du davon hälst.

Das Problem dabei ist, dass ich es selber nicht testen kann. Wenn ich 
also was ändere kann ich nicht garantieren ob's auch geht ;)

Wenn ich wieder etwas Zeit habe werde ich mir die Änderungen ansehen und 
wahrscheinlich auch übernehmen. Wegen den IRMP_Logging steht sowieso 
noch eine Änderung aus.

Generell arbeite ich im Moment mit dem Atmega168, da der Atmega8 eh 
schon zu wenig Speicher für IRMP mit allen Protokollen hat.

Aber ATtiny (besonders weil ohne Quarz) ist eine gute Alternative!

Willi schrieb:
> Leider habe ich noch ein Problem:
>
> Die Software/das Plugin empfängt keinen einzigen IR-Code (mehrere FB
>
> probiert)! Die LED blinkt aber auf und signalisiert damit, dass etwas
>
> empfangen wird. Kann es trotzdem an der IR-Empfängerdiode liegen?
>
> Ich habe die "SFH5110-36" in Verwendung.

Äh... welche LED?

Im HEX-File was im Paket dabei ist sind nur die Standard Protokolle in 
IRMP aktiviert.
Um zu überprüfen ob wirklich IR Signale reinkommen kannst du auch die 
Hexdatei "_with_IRMP_Logging" verwenden.
Hier werden alle empfangene IR Signale dann Roh an den PC gesendet egal 
ob das Protokoll in IRMP mit drinnen ist oder nicht.
Um die Daten zu empfangen muss der Optionen Dialog der DLL geöffnet 
sein.
Die Textdatei kannst du dann einfach hier anhängen.

http://www.mikrocontroller.net/articles/USB_IR_Remote_Receiver#IRMP_Logging

Dann hat das USB Logging schon mal was gebracht! ;)

Ich habe dein IRMP_Log.txt durch die "irmp.exe" gejagt und raus kommt 
das:
>> C:\Temp\löschen>irmp.exe <IRMP_Log.txt
>> -------------------------------------------------------------------
>> # TT1
>> -------------------------------------------------------------------
>> # 17.01.12 21:23:39
>> 0
>> 1010100001
>> 1110101000011 p =  7, a = 0x0015, c = 0x0003, f = 0x00

Also Protokoll 7 == RC5!

Das ist Standardmäßig im Receiver nicht mit drinnen! Ich hänge dir 
einmal das HEX File für den Atmega168(p) an wo RC5 mit drinnen ist.

Mit AVR Studio v5 kann man sich ansonsten schnell und einfach das HEX 
Files selber erstellen. Bei der v5 braucht man kein extra WinAVR mehr.
Der Download ist halt dann um einiges größer. Programmieren und Debuggen 
geht aber um einiges besser als bei der v4.

Also einfach v5 installieren und fertig!

mfg
Portisch

Also da der AVR mit 5V versorgt wird, werden natürlich auch 5V an den 
Optokoppler ausgegeben. Bei 560 Ohm also ~9mA.

Die Schaltzeit ist um ca. 250ms. Das wirst du mit einem Messgerät nicht 
sehen. Ich habe ja einen Optokoppler im DIL Gehäuse und ich habe zum 
Testen einfach eine LED statt den Optokoppler eingesetzt.
Dann kann man schön kontrolieren ob es geht.
Der KB817 scheint SMD zu sein, aber man kann ja trotzdem testweise 
einfach eine LED statt den Optokoppler an Pin 1 u 2 anlöten.

Wenn es noch immer nicht geht am besten einmal eine andere Fernbedienung 
die nicht RC5 hat probieren!

Auch ist die Polarität am Optokopplerausgang wichtig da es sich um einen 
Transistorausgang handelt.

Ich glaube, dass am Mainboard beim PowerOn 5V durchgeschaltet werden. 
Die 5V müssen an Pin 4 des KB817 liegen. Der Pin3 ist dann der 
geschaltete Ausgang des Optokopplers.

chris16 schrieb:
> Ist es möglich auch das MCE Protokoll in der nächsten Version mit auf zu
> nehmen.
> Wäre toll wenn das ohne viel aufwand gehen würde.

Soweit ich das Verstehe wird das nicht so einfach gehen. Es müsste ein 
Programm her, dass die IR Signale für die richtigen MCE Befehle 
auswertet und sozusagen übersetzt.
Ich glaube die MCE Befehle sind globale Befehle.
Die DLL muss aber von einem Programm geladen werden...

Ich habe aber keine MCE Fernbedienung und kann nichts probieren.

Ich hoffe du meinst auch den USB IR Remote Receiver. Andere Empfänger 
können von der DLL sowieso nicht verwendet werden.

Werden die Tastendrücke der Fernbedienung überhaupt erkannt!? Soweit ich 
das jetzt rausgefunden habe sollte das IR Protokoll das RC5 und/oder RC6 
sein.

chris16 schrieb:
> Das was ich im Netz gefunden habe soll das MCE Protokoll über RC5/RC6
> anzusteuern sein,leider funktionieren die RC5/RC6 Protokolle die jetzt
> schon dabei sind nicht.

Hast du einmal die Version mit dem Logging versucht?
Hier kann nur ein Log helfen:
http://www.mikrocontroller.net/articles/USB_IR_Remote_Receiver#IRMP_Logging

Ok, schön langsam kommt Licht in die Sache.

Also kannst du mit der DLL Demo die IR Befehle der Fernbedienung 
auswerten!?
Wenn IRMP keine Daten ausspuckt kann man mit dem Log den RAW IR Code 
auswerten und schauen ob ein Decoden mit IRMP überhaupt möglich ist.

Die DLL selber unterstützt aber das J.River MediaCenter nicht.
Jedoch habe ich gesehen, dass das Mediacenter Inputplugins unterstützt.
Mal sehen ob da was möglich ist...

Ich habe mir einmal die Mühe gemacht und einen USB-Stick gebaut um einen 
"mobilen" Empfänger zu haben.

Als Gehäuse dient ein transparenter Labello ;)

c00l :)

Du hast nicht zufällig noch eine Platine übrig?
Veröffentlichst Du das Layout?

hm, gibt es den source zur DLL auch zufaellig? oder bin ich blind und 
hab was uebersehen? :)

danke schonmal fuer den schematic btw! :)

also ich hab jetzt mal ein bisschen rumprobiert aber entweder ist es 
schon zu spaet bzw. ich bin zu doof oder ich hab hier 1-2 bugs gefunden.

beim parsen der version (vermutlich direkt in der DLL) kommt teilweise 
bitmuell mit. ich vermute jetzt einfach mal das nicht oder falsch 
terminiert wird (\0). aber das ist mir eher so nebenbei aufgefallen und 
eigentlich auch nicht weiter schlimm.. wollte es nur loswerden :P

das zweite ist:
beim ersten start sah ich einen bereits gespeicherten IR code fuer 
poweron. diesen habe ich geloescht und wollte dann halt die 
entsprechende taste meiner FB dafuer verwenden aber weder im settings 
dialog noch ausserhalb wird die taste gespeichert. habe sowohl die 
console app als auch die C# und delphi app getestet. (vllt. liegt auch 
hier ein problem in der DLL vor?)
weder "Read Trained IR Code" noch "Received IR Code" zeigen irgendwas 
an.
das empfangen scheint ansich aber zu funktionieren da ich im settings 
dialog nach den descriptions gefragt werde und die dann auch im log 
auftaucht.

ich bin mir jetzt nicht 100% sicher ob es vllt. doch an "mir" liegt 
daher meine frage jetzt: kann das jemand anderes azch 
bestaetigen/reproduzieren?

so.. kleines update:

das problem mit den IR codes hat sich erledigt.
F_INTERRUPTS muss fuer meine wunsch FB 15000 sein, nicht 10000. %)

btw. es gibt updates fuer IRMP und V-USB, scheint beides bei mir zu 
laufen so far.
es waere auch toll wenn du/wir das IRMP_LOGGING unberuehrt lassen 
wuerden und alternativ IRMP_LOGGING_USB benutzen wuerden, so kann man 
auch weiterhin UART o.ae. benutzen. dadurch wird die firmware ja nicht 
groesser und ich denke auf dauer wird das maintainen/updaten auch 
einfacher.

ich hab das ganze jetzt mal ein bisschen unter linux getestet und habe 
festgestellt das:

sobald ich bestimmte tasten druecke (z.b. 4, 5 u. 6, habe alle noch 
nicht getestet) wird das device aus unerklaerlichen gruenden resetet.
<snip>

1

Apr 13 22:36:54 vdr kernel: [ 9352.454051] hub 5-0:1.0: state 7 ports 2 chg 0000 evt 0004

2

Apr 13 22:36:54 vdr kernel: [ 9352.454069] uhci_hcd 0000:00:1d.3: port 2 portsc 008a,00

3

Apr 13 22:36:54 vdr kernel: [ 9352.454085] hub 5-0:1.0: port 2, status 0100, change 0003, 12 Mb/s

4

Apr 13 22:36:54 vdr kernel: [ 9352.454091] usb 5-2: USB disconnect, device number 9

5

Apr 13 22:36:54 vdr kernel: [ 9352.454096] usb 5-2: unregistering device

6

Apr 13 22:36:54 vdr kernel: [ 9352.454101] usb 5-2: unregistering interface 5-2:1.0

7

Apr 13 22:36:54 vdr kernel: [ 9352.454178] drivers/usb/core/file.c: removing 0 minor

8

Apr 13 22:36:54 vdr kernel: [ 9352.454386] usb 5-2: usb_disable_device nuking all URBs

9

Apr 13 22:36:54 vdr kernel: [ 9352.558039] hub 5-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100

10

Apr 13 22:36:55 vdr kernel: [ 9353.660810] usb usb1: usb wakeup-resume

11

Apr 13 22:36:55 vdr kernel: [ 9353.660820] usb usb1: usb auto-resume

12

Apr 13 22:36:55 vdr kernel: [ 9353.660827] ehci_hcd 0000:00:1d.7: resume root hub

13

Apr 13 22:36:55 vdr kernel: [ 9353.690034] ehci_hcd 0000:00:1d.7: port 8 low speed --> companion

14

Apr 13 22:36:55 vdr kernel: [ 9353.704093] hub 5-0:1.0: state 7 ports 2 chg 0000 evt 0004

15

Apr 13 22:36:55 vdr kernel: [ 9353.704114] uhci_hcd 0000:00:1d.3: port 2 portsc 01a3,00

16

Apr 13 22:36:55 vdr kernel: [ 9353.704127] hub 5-0:1.0: port 2, status 0301, change 0001, 1.5 Mb/s

17

Apr 13 22:36:55 vdr kernel: [ 9353.781041] ehci_hcd 0000:00:1d.7: GetStatus port:8 status 003002 0  ACK POWER OWNER sig=se0 CSC

18

Apr 13 22:36:55 vdr kernel: [ 9353.792039] hub 1-0:1.0: hub_resume

19

Apr 13 22:36:55 vdr kernel: [ 9353.808047] hub 5-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x301

20

Apr 13 22:36:55 vdr kernel: [ 9353.910038] usb 5-2: new low-speed USB device number 10 using uhci_hcd

21

Apr 13 22:36:56 vdr kernel: [ 9354.051645] usb 5-2: skipped 1 descriptor after interface

22

Apr 13 22:36:56 vdr kernel: [ 9354.056651] usb 5-2: default language 0x0409

23

Apr 13 22:36:56 vdr kernel: [ 9354.085640] usb 5-2: udev 10, busnum 5, minor = 521

24

Apr 13 22:36:56 vdr kernel: [ 9354.085647] usb 5-2: New USB device found, idVendor=16c0, idProduct=05df

25

Apr 13 22:36:56 vdr kernel: [ 9354.085653] usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0

26

Apr 13 22:36:56 vdr kernel: [ 9354.085658] usb 5-2: Product: USB IR Remote Receiver

27

Apr 13 22:36:56 vdr kernel: [ 9354.085663] usb 5-2: Manufacturer: www.mikrocontroller.net/articles/USB_IR_Remote_Receiver

28

Apr 13 22:36:56 vdr kernel: [ 9354.085794] usb 5-2: usb_probe_device

29

Apr 13 22:36:56 vdr kernel: [ 9354.085803] usb 5-2: configuration #1 chosen from 1 choice

30

Apr 13 22:36:56 vdr kernel: [ 9354.088658] usb 5-2: adding 5-2:1.0 (config #1, interface 0)

31

Apr 13 22:36:56 vdr kernel: [ 9354.088759] usbhid 5-2:1.0: usb_probe_interface

32

Apr 13 22:36:56 vdr kernel: [ 9354.088768] usbhid 5-2:1.0: usb_probe_interface - got id

33

Apr 13 22:36:56 vdr kernel: [ 9354.177668] usbhid 5-2:1.0: looking for a minor, starting at 0

34

Apr 13 22:36:56 vdr kernel: [ 9354.177843] generic-usb 0003:16C0:05DF.0009: hiddev0,hidraw0: USB HID v1.01 Device [www.mikrocontroller.net/articles/USB_IR_Remote_Receiver USB IR Remote Receiver] on usb-0000:00:1d.3-2/input0

35

Apr 13 22:36:56 vdr kernel: [ 9354.177972] hub 1-0:1.0: state 7 ports 8 chg 0000 evt 0000

36

Apr 13 22:36:56 vdr kernel: [ 9354.177995] hub 5-0:1.0: state 7 ports 2 chg 0000 evt 0004

37

Apr 13 22:36:58 vdr kernel: [ 9356.700052] hub 1-0:1.0: hub_suspend

38

Apr 13 22:36:58 vdr kernel: [ 9356.700068] usb usb1: bus auto-suspend, wakeup 1

39

Apr 13 22:36:58 vdr kernel: [ 9356.700073] ehci_hcd 0000:00:1d.7: suspend root hub

</snip>

ich habe das ganze mit 4 fernbedienungen getestet, alle 4 haben 
unterschiedliche protokolle, sowohl mit als auch ohne USB autosuspend.
das ist sicherlich nicht gewollt/normal allerdings bin ich mir jetzt 
nicht sicher ob es an diesem prokelt oder an V-USB liegt. IRMP wuerde 
ich jetzt erstmal ausschliessen. auch mit den neusten versionen von IRMP 
und V-USB laesst sich das ganze reproduzieren, getestet mit kernel 
3.3.1. mit und ohne bootloader getestet.

FUSE bits:
High: 0xD4
Low: 0xFF
Extended: 0xF8
die schaltung entspricht "ganau" der des projekts ausser das ich einen 
6pin header (AVR ISP) zum programmmieren verwende anstatt ponyprog/LPT.

irgendwelche ideen?

Mit Linux kann ich wirklich nicht weiterhelfen!

Dazu kenne ich nur diesen Beittrag:
http://www.vdr-portal.de/board18-vdr-hardware/board13-fernbedienungen/108165-irmplircd-für-usb-ir-remote-receiver-based-on-irmp/?s=ad451c0e66656d76f77dcf9d42839916f61b40ff

Passiert das unter Windows auch?
V-USB macht beim Init ein Connect/Disconnect/Connect für das HID 
Handling.

Hugo Portisch schrieb:
> Mit Linux kann ich wirklich nicht weiterhelfen!
>
> Dazu kenne ich nur diesen Beittrag:
> 
http://www.vdr-portal.de/board18-vdr-hardware/board13-fernbedienungen/108165-irmplircd-für-usb-ir-remote-receiver-based-on-irmp/?s=ad451c0e66656d76f77dcf9d42839916f61b40ff
>
> Passiert das unter Windows auch?
> V-USB macht beim Init ein Connect/Disconnect/Connect für das HID
> Handling.

ich hab jetzt mal UART (nicht von IRMP) mit eingebaut.. habe ein debug 
"print" nach dem irmp_init() gesetzt und ein paar testen gedrueckt und 
siehe da: das ganze device kriegt nen reset.

die main event loop sollte ja eigentlich nicht verlassen werden soweit 
ich das sehen kann.
eventuell disable ich gleich mal den watchdog und adde weitere debug 
prints.

Ich kann das Problem mit dem USB-Disconnect bei mir hier auch 
reproduzieren. Aber nur, wenn irmplircd nicht läuft:

1

Apr 15 22:14:40 server kernel: usb 3-5.5: USB disconnect, device number 5

2

Apr 15 22:14:41 server kernel: usb 3-5.5: new low-speed USB device number 11 using ehci_hcd

3

Apr 15 22:14:41 server kernel: usb 3-5.5: New USB device found, idVendor=16c0, idProduct=05df

4

Apr 15 22:14:41 server kernel: usb 3-5.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0

5

Apr 15 22:14:41 server kernel: usb 3-5.5: Product: USB IR Remote Receiver

6

Apr 15 22:14:41 server kernel: usb 3-5.5: Manufacturer: www.dvbviewer.info

7

Apr 15 22:14:41 server kernel: generic-usb 0003:16C0:05DF.0008: hiddev0,hidraw4: USB HID v1.01 Device [www.dvbviewer.info USB IR Remote Receiver] on usb-0000:04:06.2-5.5/input0

Ziemlich strange.

falls es hilft:
es werden genau 3 keypress events akzeptiert danach gibt es nen komplett 
reset vom device.

*edit
bevor ich es vergesse..
ganz ohne IRMP passiert das nicht. ich werde jetzt noch versuchen 
herauszufinden warum und vorallem wo genau der fehler liegt.

Christian Ruppert schrieb:
> falls es hilft:
> es werden genau 3 keypress events akzeptiert danach gibt es nen komplett
> reset vom device.

Dann liegts wohl daran, daß die Events nicht abgeholt werden und 
irgendwas intern überschrieben wird.

Dirk W. schrieb:
> Christian Ruppert schrieb:
>> falls es hilft:
>> es werden genau 3 keypress events akzeptiert danach gibt es nen komplett
>> reset vom device.
>
> Dann liegts wohl daran, daß die Events nicht abgeholt werden und
> irgendwas intern überschrieben wird.

also ich habe das nochmal mit dem irmplcd (hidraw) getestet und auch 
dann passiert das.
und meine vorherige aussage muss ich nochmal korrigieren:
auch bei einem oder zwei keypress events passiert das, dauert aber nen 
moment und wenn ich das richtig sehe auch nicht immer...

es liegt definitiv an:
usbSetInterrupt(&replyBuf[0], sizeof(irmp_data) + sizeof(uchar));
in void SendINTData(void) der main.c

und es muesste normal betriebssystem unabhaengig sein, d.h auch unter 
windows muesste es zu diesem fehler kommen.

Dirk W. schrieb:
> Dann liegts wohl daran, daß die Events nicht abgeholt werden und
> irgendwas intern überschrieben wird.

Richtig! Es liegt an der V-USB Funktion: usbInterruptIsReady

Ändert einmal das in der SendINTData ab:

1

      while (!usbInterruptIsReady()) usbPoll();                      // check if USB int is ready

2

          usbSetInterrupt(&replyBuf[0], sizeof(irmp_data) + sizeof(uchar));        // send ReportID + IR data

Neu:

1

          usbSetInterrupt(&replyBuf[0], sizeof(irmp_data) + sizeof(uchar));        // send ReportID + IR data

Das "while (!usbInterruptIsReady()) usbPoll();" überprüft ob der 
USB-Interrupt vom Host PC bereit ist. Je nach Datenmenge * Durchläufe 
bleibt es hier dann hängen wenn die Daten nicht abgeholt werden -> 
Watchdog -> Reset.
Bei diesem Fall sind es ca. 3 Durchläufe, dann hängt es.
Wenn man das Warten auf den Interrupt deaktiviert werden die Daten 
einfach gesendet. Egal ob der Host sie abholt oder nicht -> Datenverlust 
möglich, aber es sollte hier dann nicht mehr hängenbleiben. Der 
Datenverlust ist jetzt hier nicht so wichtig.

Das ist mir schon länger Zeit aufgefallen und ist auch schon längst 
geändert worden - aber halt noch nicht offiziel hochgeladen!

Hallo zusammen,

ich war ja seit längerem dabei eine Host-Anwendung zu schreiben mit dem 
Ziel den Empfänger (um einige Funktionen erweitert) in MediaPortal 
einzubinden. Je umfangreicher die Firmware wurde, desto öfter tauchten 
Probleme auf, d.h. die Hardware wurde nicht (mehr) richtig von Windows 
erkannt, funktionierte nur eine zeitlang und ähnliches.

Daher habe ich beschlossen den ATMEGA168 samt V-USB durch einen 
STM32L15x mit USB-Device-Funktionalität in Hardware zu ersetzen. Zu 
diesem Zweck habe ich ein kleines Adapterplatinchen mit dem STM32 
entwickelt, das statt dem MEGA168 auf die vorhandene Platine bestückt 
wird. Die restliche Hardware kann also gleich bleiben. Mit der Software 
möchte ich demnächst beginnen.

Falls jemand das Ganze mit dem MEGA168 weiter entwickeln will habe ich 
einen älteren Stand der C#-Host-Anwendung angehängt, die mit Hugo's 
Firmware läuft und gänzlich ohne seine DLL auskommt und stattdessen nur 
Windows-Funktionen nutzt. Soweit hat das immer recht gut funktioniert, 
da ich das aber aus einem älteren Stand rekonstruiert (neue 
Funktionalitäten wieder entfernt) habe, ist nicht ausgeschlossen, dass 
es an ein paar kleineren Stellen klemmt.

Bisher lief das immer nur unter XP, andere Windows-Versionen wurden 
nicht getestet, müssten aber auch gangbar zu machen sein.

Viel Spass damit und vielen Dank an Hugo für die gute Basis.

Ich habe mir mal den Source angesehen. Da ist das drinnen was ich immer 
schon einmal machen wollte - mich aber nie gefreut hat: Ein Mapping für 
die IR-codes auf globale Tastendrücke (Tastatur Emulator).

Am besten wär es wenn das Programm mit dem originalen USBIRRR kompatibel 
bleibt. Die Sachen wie RTC kann man dann im Programm je nach Empfänger 
deaktivieren/aktivieren.

Um die Empfänger auseinander zu kennen würden sich die Daten der HID 
Reports anbieten. Man kann sich für jedes HID Gerät die verfügbaren 
ReportIDs anzeigen lassen.
Wenn nun die RTC eine neue zusätzliche ReportID hat, die der Originale 
nicht hat kann man einfach in der Anwendung die Funktion 
aktivieren/deaktivieren.

Am besten wär es noch bei den ReportIDs etwas höher zum Zählen 
anzufangen.
Z.B. bei 20 statt einfach bei 10 weiter zu zählen.
Beim Originalen geht es aktuell bis ID 9. Wenn deine dann erst bei 20 
Anfangen hätte man noch einen Buffer um dem Originalen in Zukunft 
erweitern zu können.

mfg
Portisch

Also kompilieren und starten lies es sich.
Habe hier aber keinen Empfänger und kann es nicht testen.

Das mit den IDs werde ich AVR aber auch noch etwas abändern.
Z.b. wenn die PowerON Funktion nicht gwünscht ist, dass dann auch nicht 
die ReportID auftaucht. Diese wird jetzt ja trotzdem an den Host 
gesendet.
Wenn diese dann auch nicht an den Host geschickt wird kann sich dieser 
auch darauf einstellen was der Empfänger alles kann.

Hugo Portisch schrieb:
> Dirk W. schrieb:
>> Dann liegts wohl daran, daß die Events nicht abgeholt werden und
>> irgendwas intern überschrieben wird.
>
> Richtig! Es liegt an der V-USB Funktion: usbInterruptIsReady
>
> Ändert einmal das in der SendINTData ab:      while (!usbInterruptIsReady()) 
usbPoll();                      // check if USB int is ready
>           usbSetInterrupt(&replyBuf[0], sizeof(irmp_data) + sizeof(uchar)); 
// send ReportID + IR data
> Neu:          usbSetInterrupt(&replyBuf[0], sizeof(irmp_data) + sizeof(uchar)); 
// send ReportID + IR data

funktioniert wunderbar.
btw. in der main.c koennte man einige der functions auch noch als static 
deklarieren was noch ein paar zusaetzliche bytes verschaffen sollte.

Erst mal vielen Dank für das Projekt, funktioniert einwandfrei!
Ich hoffe natürlich, dass es noch weiterentwickelt wird, auch wenn es in 
Kombination mit Eventghost eigentlich schon alles macht, was ich 
benötige.

Noch ein paar Bilder von meinem Empfänger. Muss noch ein bisschen 
verschönert werden, aber funktioniert schon sehr gut =). Das Gehäuse war 
von einem WLAN-Stick, der irgendwann mal ein anderes Gehäuse bekommen 
hat. Gerne stelle ich auch das Layout zur Verfügung, falls Interesse 
besteht. Bei meinem Layout ist zu beachten, dass man evtl. zum 
Programmieren noch für ISP Pads oder dgl. einfügen sollte und sowohl 
USB, als auch IR-Empfänger müssen in dem Fall oben verlötet werden, wenn 
die Platine einseitig bleiben soll.

Auch wenns nichts mit dem Empfänger zu tun hat, hab ich noch ne Frage. 
Und zwar hab ich 2 SMD-Kondensatoren gegrillt, den 10µ, wo auf meiner 
Platine sehr unschön jetzt ein tht Kondi angelötet ist, weils mir das 
Lötpad weggeschmort hat. Am USB-Port eingesteckt und nach 5 Min hats 
ordentlich geraucht und gestunken ;). Das war so ein gelber, wie der 
4,7µ rechts neben dem IR-Empfänger. Ich gehe mal davon aus, dass die 
Markierung Minus sein soll oder lieg ich da falsch? Außer durch 
Verpolung kann ich mir das grad nicht erklären...aber bei 2 kann das ja 
fast nicht sein^^
achja Bauteile(smd/tht) hab ich wild alles verbaut, was ich grad 
gefunden hab ;)

Schönen Abend,
pedro

pedro f. schrieb:
> Ich gehe mal davon aus, dass die
> Markierung Minus sein soll oder lieg ich da falsch?

Und wie! Bei SMD Elkos ist der Strich !Plus!

Wegen der IR Diode:
Schaue dir einmal die TSOP4838 an. Ist um einiges kleiner und geht genau 
so gut!

mikrocontroller p_73 schrieb:
> Bei SMD Tantals ist der Strich das PLUS
Bei THT Tantals ist ebenso meist + markiert.

Hi,
habe mal eine Version auf Basis eines USBasp gebaut.
Ich habe auch ein kleines Kommandozeilentool geschrieben.

http://www.easyvdr-forum.de/forum/index.php?topic=13723.msg117780#msg117780

Wiki:
http://wiki.easy-vdr.de/index.php/USBASP_Einschalter

muebau

Hallo Hugo,

load source firmware for USB IR Remote Receiver (V-USB + IRMP). Where is 
you.

Best Regards,

Wie wertest du die IR-Codes aus?
Ich selber habe kein IR Tastatur. Stöbere einmal den Thread von IRMP 
durch:
Beitrag "IRMP - Infrared Multi Protocol Decoder"

Da habe ich was in Erinnerung das dort einmal beschrieben wurde wie das 
mit "Shift" usw funktioniert.
Ich glaube beim Drücken der "Shift" Taste wird ein Code X gesendet. Nun 
weis die auswertende Software das Shift gedrückt ist. Beim Loslassen der 
Shift Taste sollte ein anderer Code Y kommen was bedeutet, dass die 
Shift Taste losgelassen wurde.

Also sozusagen ein Shift/CAP/...-Down und Up.

Sebastian schrieb:
> Da ich die Caps-Taste drücken muss und dann eine andere Taste kommt
> nachher ja beim Drücken der Caps-Taste der Großbuchstabe heraus. Man
> müsste also bei Großbuchstabenzuweisungen mehrere IR-Codes miteinander
> verknüpfen, oder?

Hast Du Dir schon einmal

  http://www.mikrocontroller.net/articles/IRMP#IR-Tastaturen

durchgelesen? Da ist erklärt, was passiert, wenn Du die 
SHIFT/STRG-usw-Taste drückst bzw. loslässt. Du musst Dir diese Events 
als Status speichern, um dann die richtige Taste zu ermitteln, wenn Du 
ein 'a' bekommst.

Dort ist auch eine kleine C-Funktion abgebildet, welches genau das 
erledigt.

Sebastian schrieb:
> die C-Funktion steht doch schon in der irmp.c drin, oder?

Ja, aber durch Preprocessor-Defines deaktiviert. Die steht da nur drin, 
damit man sie da rauskopieren kann.

Wo nämlich aus Protokoll, Adresse & Kommando der eigentliche Tastencode 
gebildet wird, ist eigentlich egal. Das kann auf dem µC sein, es kann 
aber auch erst auf dem PC passieren.

> Irgendwo hab ich auch das aktuelle irmp.zip gefunden.

Download-Link im Artikel IRMP.

> In diesem Archiv war die irmp.exe wozu ist die eigentlich?

Steht auch im Artikel. Benötigst Du aber nicht.

> Ich muss doch nach wie vor z.B. mit EventGhost die Tasten-Events den
> einzelnen Buchstaben zuweisen, sodass ich mit der Tastatur auch tippen
> kann, oder?

Ich kenne Eventghost nicht und kann deshalb nichts dazu sagen.

Hat sich erledigt.
Eine von den Zenerdioden war durch ( beidseitig durchgang )
Den Bootloader bekomme ich zwar trotzdem nicht ans laufen, aber das 
Hauptprogramm läuft.

Ich habe hier schon länger nichts mehr gemacht.
Eigentlich habe ich schon mal angefangen den Source nach GitHub zu 
bringen:
https://github.com/Portisch/USB-IR-Remote-Receiver

Aber hier fehlt noch die neue DLL!

Die DLL sucht per USB_CFG_VENDOR_ID, USB_CFG_DEVICE_ID und dem 
USB_CFG_DEVICE_NAME den Empfänger. Diese IDs sind im AVR Source fix 
definiert.

Wo kann ich die
USB_IR_Remote_Receiver.DLL
herunterladen?
thx

Hab mir den Empfänger gebaut und er funktioniert unter W10 mit DVBViewer 
sehr gut.

Danke schön für die Arbeit, super gelungen!!

https://github.com/Portisch/USB-IR-Remote-Receiver/issues/2