Wie Signale einer IR Fernbedienung für ComPort empfangen?

[Cyberaxx]

Hallo,

mal wieder ich...
Ich würde gerne eine Fernbedienung in einem meiner Programme nutzen. Die Fernbedienung sendet RC5 Signale soweit ich weiß, da ich das mit Grider oder WinLirc nutzen kann.
Der Aufbau der Steuerung ist sehr einfach gehalten.

http://www.dvbmagic.de/images/fernbe...c_receiver.gif

Wenn ich RTS auf High lege ist der Empfänger aktiv. Signale kommen über DCD, nur High und Low Signale
Nach der Beschreibung des RC5 Protokolls, sieht ein Befehl so aus

2 Startbits (immer 1)
1 Toglebit
5 Adressbits
6 Kommandobits

Insgesamt also 14 ... hmmm ... Signale

Die einfache Prozedur mit ReadFile funktioniert nicht, da ja nicht wirklich Daten übertragen werden.
Eine passende Komponente habe ich auch noch nicht gefunden.

Wenn ich das bei mir am laufen habe, habe ich ein ziemlich grosses Untergrundrauschen drin.
Jedesmal wenn sich der Status an DCD ändert, habe ich einfach mal die Zustände in einem String addiert und nach 14 Zeichen ausgegeben. Da kam ziemlich viel Müll mit an. Habe als noch eine Prüfung aus High der ersten beiden Zeichen eingebaut.
Zusätzlich soll das Signal nur ausgegeben werden, wenn es sich von dem vorherigem unterscheidet.

Delphi-Quellcode:

if CP.DCD = 1 then
  Str := Str + '1'
    else Str := Str + '0';

if ((Length(Str) = 2) and (not(Str = '11'))) then
  Str := '';

if (Length(14) and (Str <> OStr)) then begin
  Memo1.Lines.Add(Str);
  OStr := Str;
  Str := '';
  end;

if Length(Str) = 14 then
  Str := '';

Eben mal schnell getestet gehabt aber da kommt leider auch nicht wirklich was bei heraus, bei fast jedem Tastendruck die Selbe Folge. Hat hier jemand eine Ahnung wie man das Richtig anstellt und mich auf den richtigen Weg schubsen könnte?
Eigentlich müsste der Source auch wenn er nicht sauber ist doch so seinen Zweck erfüllen?!

Ich blick da echt nicht mehr weiter.

Gruß
Daniel

[Reinhard Kern]

Zitat:

Zitat von Cyberaxx

Hallo,

mal wieder ich...
Ich blick da echt nicht mehr weiter.

Gruß
Daniel

Hallo,

RC5 benutzt einen Träger mit 27.8 µsec Periode und eine Bitperiode von 1.78 ms - wo bitte ist in deiner Software die Zeitmessung? Und wo ist die Manchester-Dekodierung?

Eine technische Beschreibung findest du hier:
http://www.ece.umd.edu/class/enee445.S2004/rc5codec.pdf

Gruss Reinhard

[Cyberaxx]

Wieso eigentlich eine Zeitmessung? Ich frage über einen Timer im Intervall immer den Zustand des Pins ab. Timer = Bitperiode.
Müsste es nur anstat der Timer Kompo direkt in einen Thread setzen. das sich hier bei die Signale nach einer Zeit ein wenig verschireben ist auch klar, da sollte dennoch ein Muster zu erkennen sein...

Falls Du das mit Manchaster Code meinst...

Zitat:

11 1 11111 111100
11 1 11111 111111
11 1 11111 111110
11 1 11111 011110
11 1 11111 111111
11 1 01111 111111
11 1 11111 111111
11 1 11111 111110
11 1 11111 111111
11 1 11111 111101
11 1 11111 111111
11 1 11111 111110
11 0 11111 111111
11 1 11111 111111
11 1 11111 111110
11 1 11111 111111
11 1 11111 110011
11 1 11111 111111
11 1 11111 101111
11 1 11111 111111
11 1 11111 111011
11 1 11111 111111
11 1 11101 101111
11 1 11111 111111

[shmia]

Bei 1.78 ms nützt ein Timer nichts mehr.
Wenn die Sache überhaupt Erfolg haben soll, muss dein Programm ständig den Pin DCD abfragen.
Bei jedem Wechsel des Zustand muss der Wert eines hochauflösenden Zählers in einem Array oder Liste gespeichert werden.

Delphi-Quellcode:

type
   TDCDEvent = record
      bitvalue : boolean;
      counter  : Int64;
   end;
var
   DCDevents : array[0..14] of  TDCDEvent;

Nachdem man 14 Mal den High-Zustand gesehen hat, kann man raus aus der Routine und muss das Array auswerten.
Ich würde das Array erst mal als CSV-Datei speichern und manuell auswerten, um zu sehen, ob man daraus überhaupt einen RC5-Code erkennen kann.

[Reinhard Kern]

Zitat:

Zitat von shmia

Bei 1.78 ms nützt ein Timer nichts mehr.
Wenn die Sache überhaupt Erfolg haben soll, muss dein Programm ständig den Pin DCD abfragen.
Bei jedem Wechsel des Zustand muss der Wert eines hochauflösenden Zählers in einem Array oder Liste gespeichert werden.

Delphi-Quellcode:

type
   TDCDEvent = record
      bitvalue : boolean;
      counter  : Int64;
   end;
var
   DCDevents : array[0..14] of  TDCDEvent;

Nachdem man 14 Mal den High-Zustand gesehen hat, kann man raus aus der Routine und muss das Array auswerten.
Ich würde das Array erst mal als CSV-Datei speichern und manuell auswerten, um zu sehen, ob man daraus überhaupt einen RC5-Code erkennen kann.

Hallo,

das ist längst nicht alles:

1.78 ms ist die Zeit für ein ganzes Bit - die Hälfte Hi, die Hälfte Lo. Und um einen Timer auf ein asynchrones Signal halbwegs sicher zu sysnchronisieren, muss man mindestens mit der achtfachen Bit-Frequenz abtasten, so wie bei einem asynchronen UART. Von selbst laufen die Time Interrupts und der IR-Sender ja nicht synchron.

Ausserdem berücksichtigst du nicht, dass für High ja kein Dauersignal, sondern eine Impulsfolge mit Impulsen im µsec-Bereich gesendet wird. Um die nach deiner Methode zu erfassen, müsste man sie erstmal (mit Hardware) integrieren.

Dann erst könnte man langsam anfangen, über Manchester Code nachzudenken. Ich fürchte, bis dahin ist noch ein so weiter Weg, dass ich mich zu dem Thema besser nicht mehr melde.

Gruss Reinhard

[Cyberaxx]

Zitat:

Zitat von Reinhard Kern

Dann erst könnte man langsam anfangen, über Manchester Code nachzudenken. Ich fürchte, bis dahin ist noch ein so weiter Weg, dass ich mich zu dem Thema besser nicht mehr melde.
Gruss Reinhard

Das ist ja mal eine nette Hilfestellung...
Sag doch gleich ich soll aufgeben...

[Reinhard Kern]

Zitat:

Zitat von Cyberaxx

Zitat:

Zitat von Reinhard Kern

Dann erst könnte man langsam anfangen, über Manchester Code nachzudenken. Ich fürchte, bis dahin ist noch ein so weiter Weg, dass ich mich zu dem Thema besser nicht mehr melde.
Gruss Reinhard

Das ist ja mal eine nette Hilfestellung...
Sag doch gleich ich soll aufgeben...

Sagen wirs mal so: ich fürchte, mit dieser Hardware würde ich es auch nicht hinkriegen. Und dann im Fernlehrverfahren...

Aber niemand hindert dich, dein Projekt gegen alle Widrigkeiten durchzuziehen - was uns nicht tötet, macht uns nur härter. Ich lasse mich gern positiv überraschen, also melde dich unbedingt, wenn der Empfang zuverlässig läuft.

Gruss Reinhard

[Cyberaxx]

Zitat:

Zitat von Reinhard Kern

Sagen wirs mal so: ich fürchte, mit dieser Hardware würde ich es auch nicht hinkriegen. Und dann im Fernlehrverfahren...

Wenn man sich z.B. WinLirc oder Grider. Beide Programme arbeiten mit genau der Hardware.

Ich scheitere ja so schon daran nen Delay in so einem kleinen Intervall hinzubekommen. Davon mal abgesehen beschäftigt sich das Programm dann ja nur noch mit dem abtasten, das kann es ja auch nicht sein.

Wo liegt denn mein Denkfehler in dem Moment. Ich habe eine Komponente die auf die Statusänderung des Signales reagiert.
Demnach müssten einmal High / Low ein Bit sein?
Da aber auch mal 2 Low Zustände hintereinander kommen könnten, muss ich also den Status manuell abfragen.
ich lege Spannung an und genau in dem Moment starte ich auch den Timer und zwar mit halber Bitlänge also 1,78ms / 2.
da der Zustand ja eine gewisse Zeit anhällt, warum müsste ich dann mindestens die 8 fache Abtastrate haben?
Wenn ich dann in dem Array immer den übernächsten Zustand lese, müsste ich doch jeweils das Signal haben was für das Bit von Wert ist?

Als Test zum Starten der Aufzeichnung, bräuchte ich doch dann nur 4 mal abtasten. das erste und das dritte Signal müssten dabei dann High sein, das wären dann meine beiden Startbits. Ist das der Fall, Zeichne ich weiter die Signale auf, 24 Zustände, davon sind dann 12 Brauchbare Signale. Sollten die ersten beiden Signale nicht meinen Startbits entsprechen sollen sie verworfen werden und erneut beginnen. Dabei werden die ersten beiden Signale verworfen und die nächsten 2 Signale zusazu geprüft.

Das ist im Moment meine Theorie, korrigiere mich wenn ich da Falsch liege.

[Reinhard Kern]

Zitat:

Zitat von Cyberaxx

Zitat:

Zitat von Reinhard Kern

Sagen wirs mal so: ich fürchte, mit dieser Hardware würde ich es auch nicht hinkriegen. Und dann im Fernlehrverfahren...

Wenn man sich z.B. WinLirc oder Grider. Beide Programme arbeiten mit genau der Hardware.
...
Das ist im Moment meine Theorie, korrigiere mich wenn ich da Falsch liege.

Denkfehler 1 : mit dem Einschalten machst du den Empfänger scharf, deswegen weisst du noch lange nicht, wann der Sender startet - ich denke doch, wenn man auf einen Knopf drückt, oder handelt es sich nicht um eine Fernbedienung? Aber auch sonst weisst du das nicht auf die msec genau.

Ansonsten fehlt da was: was ist vor der gezeichneten Schaltung - ein IR Empfänger, vielleicht ein Carrier Detector oder was? So lässt sich nicht sagen, was da ankommt. Mit den Nadelimpulsen, die ein RC5-Sender abgibt, kann der PC nichts anfangen.

Studiere Seite 2 des genannten Links: http://www.ece.umd.edu/class/enee445.S2004/rc5codec.pdf

Gruss Reinhard

[Cyberaxx]

http://www.sprut.de/electronic/ir/rc5.htm

Da es hier zum Posten zu viel Text ist poste ich auch mal einen Link.

Jetzt schaue ich mir Deinen auch mal an. :)

[Reinhard Kern]

Zitat:

Zitat von Cyberaxx

http://www.sprut.de/electronic/ir/rc5.htm

Da es hier zum Posten zu viel Text ist poste ich auch mal einen Link.

Jetzt schaue ich mir Deinen auch mal an. :)

Laut Link: der 36 kHz Carrier wird vom Receiver detektiert, die einzelnen Impulse muss man also nicht berücksichtigen. Es bleibt aber dabei: es müssen bis zu 28 Flanken erfasst werden im Abstand von 0.89 oder 1.78 msec - wobei das gerade der Unterschied zwischen 0 und 1 ist. Um das zuverlässig abzutasten, müsste man einen Timer mit einer Periode 0.222 msec haben, den es unter Windows nicht gibt. Man könnte höchstens mit WaitCommEvent die Flanken erfassen, aber dann müsste man testen, ob das System tatsächlich alle einzeln erwischt, und ob man den Zeitabstand genau genug bestimmen kann, etwa mit QueryPerformanceCounter.

Natürlich ist sowas für einen PIC-Prozessor u.ä. kein Problem, der muss ja auch nicht Windows ausführen.

Gruss Reinhard

[Cyberaxx]

Nach einigem rumsuchen bin ich auf einen Source gestoßen der das ausgeben des RC5 Codes unter Delphi ermöglicht. Basiert auf der Port.dll, noch einer weiteren DLL und der verarbeitung im Programm. Leider funktioniert er nicht, er läßt sich nicht Compilieren. Nachdem ich mir aber den Source angesehen habe, ist mir da aufgefallen das dort das Delay über den QueryPerformanceCounter geregelt wird. Dieser rechnet in Microsekunden.

Konnte mir aus Zeigründen nicht den ganzen Source gestern ansehen aber ich würde das dann so umsetzen.
Im Hintergrund läuft ein Thread. Er bekommt einen eigenen Constructor in dem der Port festgelegt wird.
Der Port wird geöffnet, das Execute im Thread bleibt so lange in der Schliefe bis man ihn beendet.
Dort setzt man ein Delay mit hilfe des QueryPerformanceCounter.

Muß das am Wochenende mal testen, wäre auf jedenfall gut wenn es funktionieren würde.

[Cyberaxx]

So ich habe da mal etwas gebastelt was aber nun mal wieder nicht funktioniert.

Mal abgesehen davon das er das System ein wenig lahm legt.

Delphi-Quellcode:

const
  fDtrControlEnable    =   16;        // DTR flow control type       $0010
  fRtsControlEnable    = 4096;        // RTS flow control            $1000

  Rc5Time = 24889;   //us
  Rc5BitTime = Rc5Time div 14;
  Rc5HalfBitTime = Rc5Time div 28;
  Rc5QbitTime = Rc5Time div 56;

var
  Freq: Int64;

procedure TRc5Thread.Execute;
  var
    TmpValue: Integer;
    Value: Integer;
    I: Integer;
    T: Integer;
begin
  while not Terminated do begin

    T := 0;

    Windows.QueryPerformanceFrequency(Freq);

    if PegelValue = 0 then begin
      IrDelay(Rc5HalfBitTime);

      if PegelValue = 1 then begin
        IrDelay(Rc5HalfBitTime);

        if PegelValue = 0 then begin
          IrDelay(Rc5HalfBitTime);

          if PegelValue = 1 then begin
            IrDelay(Rc5HalfBitTime);

            TmpValue := PegelValue;
            IrDelay(Rc5HalfBitTime);
            Value := PegelValue;
            if TmpValue <> Value then begin // Zustände müssen unterschiedlich sein
              FCode[1] := 0;
              FCode[2] := 1;
              FCode[3] := 0;
              FCode[4] := 1;
              FCode[5] := TmpValue;
              FCode[6] := Value;

              IrDelay(Rc5HalfBitTime);
              T := 6;

              for I := 7 to 16 do begin
                TmpValue := PegelValue;
                IrDelay(Rc5HalfBitTime);
                Value := PegelValue;

                if TmpValue <> Value then begin
                  FCode[I] := TmpValue;
                  Inc(T);
                  end;
                end;

              for I := 17 to 28 do begin
                TmpValue := PegelValue;
                IrDelay(Rc5HalfBitTime);
                Value := PegelValue;

                if TmpValue <> Value then begin
                  FCode[I] := TmpValue;
                  Inc(T);
                  end;
                end;

              end;
            end;
          end;
        end;
      end;

    if T = 28 then
      Synchronize(SetRC5);

    IrDelay(Rc5QbitTime);
    end;
end;

procedure TRc5Thread.IrDelay(uS: Integer);
  var
    AktCount: Int64;
    NewCount: Int64;
    OldCount: Int64;
begin
  Windows.QueryPerformanceCounter(OldCount);
  NewCount := OldCount + Round((uS * Freq) / 1000000);

    repeat
      Windows.QueryPerformanceCounter(AktCount);
    until AktCount >= NewCount;

  OldCount := NewCount;
end;

Da ich immer die Halbe Bitzeitdurchlaufe und alle Zustände mit schreibe habe im am Ende eines RC5 Codes 28 Zustände

Der Thread läuft in einer Schleife, diese wiederholt sich alle in 1/4 der Bitzeit
Wird ein High Signal gefunden sucht er nach einer Halben Bitzeit nach einem Low Pegel, dann wieder ein High und darauf wieder ein Low, alles im Abstand eines Haben Bits. Das Bit wird ja wie auf dem Link von mir die Halbe Zeit als High und den Rest als Low Pegel ausgegeben.

Danach wird das Toglebit eingelesen, dieses muss einmal als High und auch als Low vorhanden sein. Die Adressbits und die Commandobits ebenfalls. Wenn das der Fall ist sollte T bei 28 liegen und der Rc5 Frame ausgegeben werden. Jedoch habe ich das Problem das er nichtmal soweit kommt. Da Teilweise das Signal beide Hälften den selben Zustand hat.
Liegt da ein Problem meiner Seite vor oder könnte sein das Windows da nicht mit spielt?
Habe doch jetzt alles berücksichtigt....

[Reinhard Kern]

Zitat:

Zitat von Cyberaxx

So ich habe da mal etwas gebastelt was aber nun mal wieder nicht funktioniert.

Mal abgesehen davon das er das System ein wenig lahm legt.

....

Hallo,

wenn ein Signal anliegt, wird im ersten if eine Verzögerung gestartet und (vielleicht) das 2 Halbbit abgefragt. Ohne Signal passiert das gleiche, nur ohne Verzögerung, und alles weitere läuft so ab, wie mit Signal, aber zu falschen Zeitpunkten. Kannst du erklären, was das bewirken soll?

Normal wäre: wenn kein Signal anliegt, passiert NICHTS.

Nur das erste von vielen Problemen, aber bevor das nicht geklärt ist, sind weitere Details nicht von Interesse.

Gruss Reinhard

[hathor]

Warum nimmst Du nicht WINLIRC?

http://winlirc.sourceforge.net/

http://winlirc.sourceforge.net/delphi.html

http://www.ocinside.de/html/ir_recei...winlirc_d.html

[Cyberaxx]

Der Grund ist ich würde es halt gerne selber schreiben und auch verstehen, warum ein weiteres externes Programm nutzen?

Nach der RC5 Beschreibung zu urteilen, sollte das umzusetzen auch nicht so schwer sein, warum ich damit allerdings so große Probleme habe weiß ich auch nicht.
Ich kann aber auch zu wenig C++ um mir den Source von WinLirc näher zu bringen.

[hathor]

http://winlirc.sourceforge.net/delphi.html

http://winlirc.sourceforge.net/winli...od-by-wave.zip
http://winlirc.sourceforge.net/winlirc-delphi.zip

[Cyberaxx]

Meinen Post gelesen?

Ich würde es gerne selber machen und verstehen, was bringt mir dann der Delphi Teil der sich auf WinLirc bezieht?

Zitat:

I wrote an example application in Delphi, which demonstrates how to use
Delphi with WinLIRC.

Dadurch lerne ich es auch nicht wirklich.

[hathor]

Zitat:

Zitat von Cyberaxx

Dadurch lerne ich es auch nicht wirklich.

Lernen und verstehen sind zweierlei:

Man kann ein ANALOGES Signal mit der doppelten Frequenz abtasten (Abtasttheorem), aber für ein asynchrones, DIGITALES Signal gilt das nicht, wenn man kein Bit verlieren will.
Wahrscheinlich hast Du kein Oszilloskop, um zu sehen, was an der seriellen Schnittstelle anliegt.
Wenn ein WINDOWS-Programm zeitkritische Aufgaben erfüllen muss, muss es auf höchster Priorität laufen.
In Assembler würde man kurzzeitig Interrupts sperren - aber Du hast von vielem noch keine Ahnung, deshalb solltest Du von anderen "lernen", dann lernst Du es vielleicht auch zu "verstehen".

Hier ist noch etwas zum LERNEN:

www.b-kainka.de/rc5del.zip

Allerdings sind im Sourcecode ein paar Fehler...

Für den Parallelport:
http://home.tiscali.nl/m.majoor/rc5irda.zip

[Reinhard Kern]

[quote="hathor"]Warum nimmst Du nicht WINLIRC?

Hallo,

ich habe einen kurzen Blick in die Source geworfen - damit das funktioniert, wird mit allen Tricks die Priorität auf die technisch höchstmögliche hochgeschraubt, noch mehr als normale Realtime-Priorität. Das ist höchstens ein Beispiel dafür, wie man absolut nicht programmieren sollte - rücksichtsloses Ansichreissen aller Resourcen für einen völlig nebensächlichen Zweck.

Sicher ein supercooles geiles proggy, aber wenn mehr Leute zu solchen Ideen überredet werden, kann man keinen PC mehr benutzen. Da wird Verantwortungslosigkeit zum vorbildlichen Programmierstil erklärt.

Gruss Reinhard

[Cyberaxx]

Wie wäre es denn mal mit einem Vorschlag einer anderen Variante die Ressourcen schonender ist?

Sollte dementsprechend aber noch kostengünstig sein, denn die jetzige Schaltung kostet gerade mal 2€

Da es ein HTPC werden soll, ist da eine Fernbedienung irgendwie Pflicht.

[Reinhard Kern]

Zitat:

Zitat von Cyberaxx

Wie wäre es denn mal mit einem Vorschlag einer anderen Variante die Ressourcen schonender ist?
....

http://www.cesko.host.sk/IgorPlugUSB/IgorPlug-USB%20(AVR)_eng.htm

Gruss Reinhard

[hathor]

Hallo!
Ich möchte hier mal etwas klarstellen:
Wenn hier jemand experimentieren will, hindere ich ihn nicht daran - ich habe vor ein paar Jahren selbst mit IR am seriellen und parallelen Port, mit Oszilloskop und eigener Software Erfahrungen gesammelt und es hat mir nicht geschadet (und dem PC auch nicht). Wenn ich aber in einem Thread sehe, wie sich jemand erfolglos bemüht, zu einem Ergebnis zu kommen, habe ich 3 Möglichkeiten:
1. ich lese alles und wundere mich, dass da jemand "das Rad nocheinmal erfinden will", weiss aber nicht, was ein Rad ist,
2. ich schreibe, dass es blödsinnig ist, mit Legacy-Ports (COM-Ports, Centronic-Ports) fast 10 Jahre nach dem Abschaffungsbeschluss der bedeutendsten Hardware- und Software-Firmen zu experimentieren,
3. ich "versorge" den Hilflosen mit Links, in der Hoffnung, dass er erkennt, dass es ein schlechter Scherz ist, was er einer 2-3GHz-CPU zumutet - nämlich stundenlang mit einem schlechten Programm am COM-Port zu lauschen, ob da mal jemand die Fernbedienung betätigt...

Ein IR-Empfänger mit Mikrocontroller und USB-Anschluss wäre für so eine Aufgabe besser geeignet!
(z.B. TRUST NB-5100P Multimedia REMOTE Control)

http://www.trust.com/products/defaul...ers&item=14272