IR Protokoll für TSOP 17xx

[Christian J. (elektroniker1968)]

Hallo,

ich habe mit dem Datenblatt der Vishay IR Empfänger mal etwas gerechnet 
aber verstehe einiges noch nicht, auch wenn ich eine IR Strecke zum 
Laufen gekriegt habe.

Welches ist der optimale Duty-Cycle der Sendediodenpulse um maximale 
Reichweite zu erreichen? 50%? Ich verstehe da die Diagramme noch nicht 
richtig.

Soll man dem Nutzsignal eine Präambel vorstellen, die den Filter 
einschwingen lässt?

Wie knapp kann man an die Grenzwerte des Bausteins gehen? Im Datenblatt 
steht er würde ab 6 Zyklen bereits ein Signal erkennen?

Da der TSOP kräftig verzerrt schwebt mir folgendes vor:

0 = 10 Zyklen
1 = 20 Zyklen
Datenende = 30 Zyklen
Gap = ?

Softwareprotokoll wie üblich mit Checksumme.

Wie breit muss eigentlich die Gap sein zwischen den 1'sen und Nullen?

Gruss,
Christian

[Thomas (kosmos)]

Hallo, das Protokoll bestimmst du ja selber dieser TSOP tut ja nur deine 
Impulse zerhacken da ist das Duty-Cycle Verhätniss 50%. Schau dir mal 
das Dokument an hier wird einfach durch die Pausenlänge bestimmt ob eine 
1 oder eine 0 übertragen worden ist. Wenn man aber den nicht zerhackten 
Impuls möglichst kurz wählt und die Pausenzeit möglichst lang braucht 
man nicht von 50% Duty Cycle ausgehen und kann die Diode viel stärker 
belasten.

Meine Emmpfehlung LD274-3 da kannste locker mal 3A pro Impuls 
durchschießen, wenn du den Impuls kurz hälst und die Pausen lang 
gestaltest, in dieser hinsicht ist das Protokoll hier gut gemacht, 
andere Protokolle z.B. RS232 wäre hier nicht so gut da wenn 8 mal High 
übertragen wird hat die Diode ja gar keine Pause aus die die durch die 
Modulation kommt aber die ist ja nur 50%

[Christian J. (elektroniker1968)]

Hallo,

danke für den Text, habe ich interessante Werte rausgeholt. Auf die Idee 
die Signale in der Pause zu codieren kam ich auch schon. Meine Frage war 
die, welcher Duty Cycle im Trägersignal die höchste Reichweite 
verspricht. Ein Burst wird bezeichnet als Serie von Trägerimpulsen, in 
diesem Falle wird 250us lang 38 khz gesendet. Das Trägersignal aber 
lässt sich ja auch so gestalten, dass zB 20% ein und 80% aus sind. Dann 
sind es immer noch 38khz.

Beim Rumspielen habe ich gemerkt, dass es ohne Präambel nicht geht oder 
nur sehr fehlerträchtig.

Gruss,
Christian

[Christian J. (Gast)]

Hallo,

mein Beitrag ist zwar jetzt 10 Jahre alt (huh, da war ich noch 
verheiratet :-) aber das Thema stellt sich grad wieder.

Mit einem TSOP1740 möchte einfach die Textausgabe eines Arduino in den 
Raum senden, so dass ich diese auslesen kann wie üblich mit einem FTDI 
Konverter.
Die TSDP Bausteine sind hier nicht so einfach zu kriegen, die dafür 
ausgelegt sind Datenströme zu übertragen aber der TSOP1740 packt das 
sicher auch. Idealerweise wird der TSOP direkt an den FTDI angeschlossen 
und erzeugt auch kphasenrichtige Signale mit einer akzeptablen 
Fehlerrate, so dass der Abtastmechanismus einer Hardware Uart diese 
erkennt.

Hat mal jemand ein RS232 Protokoll mit Parität umgesetzt? D.h. am 
Ausgang des TSOP soll möglich genau 1200 baud oder 2400 heraus kommen. 
Die Fehlerrate bei 2400 (417us pro Bit) ist allerdings enorm, der TSP 
erzeugt bis zu 6/f0 Fehler.

Mich würde nur mal interessieren ob das überhaupt funktioniert, damit 
ich mir nichts eigenes ausdenken muss, sondern RS232 direkt abgreifen 
kann.

Gruss,
Christian

[Wolfgang (Gast)]

Christian J. schrieb:
> Ein Burst wird bezeichnet als Serie von Trägerimpulsen, in
> diesem Falle wird 250us lang 38 khz gesendet. Das Trägersignal aber
> lässt sich ja auch so gestalten, dass zB 20% ein und 80% aus sind. Dann
> sind es immer noch 38khz.

Aus der Tatsache, dass du den alten Thread wieder hervorgeholt hast, 
schließe ich, dass das Thema für dich jetzt wieder aktuell ist.

Damals wie heute sitzt in den TSOP ein Filter, dessen Frequenzgang im 
Datenblatt angegeben ist. Für maximale Reichweite muss möglichst viel 
Energie beim Empfänger ankommen und dazu muss sie durchs Filter.
Guck dir das Spektrum eines Rechtecksignals in Abhängigkeit vom Tastgrad 
an. Je kleiner das Tastverhältnis ist, um so mehr kannst du die LED 
quälen. Jetzt suchst du dir das Optimum unter Berücksichtigung des 
Wirkungsgrades der LED und der Filterkurve raus.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Der Akai VS-9 Videorecorder wurde praktisch mit UART auf IR gesteuert, 
nur das das UART mit 38kHz aufmoduliert wurde. Es sollte also klappen, 
wenn du auf der Sendeseite 38kHz Rechteck mit UART verANDest. Aus dem 
TSOP kommt dann direkt wieder UART raus. Der Akai hatte 2400Baud.
Wohlgemerkt ist aber eine Fehlerkorrektur unbedingt nötig, weil der 
Receiver ohne Sendesignal immer mal wieder Müll ausgibt.

[Christian J. (Gast)]

Wolfgang schrieb:
> Je kleiner das Tastverhältnis ist, um so mehr kannst du die LED
> quälen.

Das sol nach diversen Forenbeiträgen nichts bringen. Finde ich 
allerdings nicht mehr, war irgendwo genau mit Oszillogrammen 
beschrieben. Es zählt die Lichtmenge, nicht in die Intensität. Also die 
Anzahl Photonen, die raus kommen. derjenige hatte mit 10% bis 50% DC 
experimentiert. 50% sind laut Datenblatt bei mir angebracht.  Die 40khz 
erzeugt ein Timer, der TSOP 1740 hat 40, andere habe ich nicht.

Mal schauen, ist ja nicht so schwer, auch wenn ich den Empfänger noch 
nicht gebaut habe.

[Wolfgang (Gast)]

Christian J. schrieb:
> Es zählt die Lichtmenge, nicht in die Intensität. Also die
> Anzahl Photonen, die raus kommen.

Eben nicht. Es zählt nur die Lichtmenge (Energie) die beim Empfänger in 
elektrische Signal umgesetzt wird und dann auch durch das Filter geht. 
Bei geringen Tastverhältnis steigt der Oberwellenanteil, so dass die 
Energie außerhalb des "Empfangsbandes" liegt.

Doppelte Intensität bei halbiertem Tastverhältnis würde nichts am 
mittleren Photonenfluss ändern ;-)

[Christian J. (Gast)]

Wolfgang schrieb:

Ok, danke erstmal, ich brauche nur 1-2m um ein Gerät aus zu lesen, was 
einen durchsichtigen Deckel hat und nur aufschraubar wäre.

Wird wohl etwas Fummelei werden, wenn ich das Signal erstmal auf dem 
Oszi habe und sehe was hinten raus kommt. Die Dinger streuen doch etwas.

* Sende ein IR Byte im RS232 Mode, 8E1 */
#define BURST  833            /* (us) Bitdauer für 1200 Baud */
void SendIRByte(byte db)
{
  byte parity = parity_even_bit(db);   // Parity Bit errechnen
  
  /* Startbit senden */
  SendBurst(BURST);

  /* Datenbits hinterher */    
  byte mask = 0x80;
  for (byte i = 0; i < 7; i++) {
    if (db & mask) { // Bit = 1;
      delayMicroseconds(BURST);
    } else {    // Bit = 0;
      SendBurst(BURST);
    }
    mask = (mask >> 1);
  }
  /* Parity Bit */
  if (parity) {
    delayMicroseconds(BURST);
  } else 
    SendBurst();

  delayMicroseconds(BURST);
  delayMicroseconds(BURST);
}

[Falk B. (falk)]

Matthias S. schrieb:
> Der Akai VS-9 Videorecorder wurde praktisch mit UART auf IR gesteuert,
> nur das das UART mit 38kHz aufmoduliert wurde. Es sollte also klappen,
> wenn du auf der Sendeseite 38kHz Rechteck mit UART verANDest. Aus dem
> TSOP kommt dann direkt wieder UART raus. Der Akai hatte 2400Baud.
> Wohlgemerkt ist aber eine Fehlerkorrektur unbedingt nötig, weil der
> Receiver ohne Sendesignal immer mal wieder Müll ausgibt.

Naja, man muss die Daten halt sinnvoll kodieren. Sprich, lange Sequenzen 
von 0 oder 1 müssen vermieden werden. Im einfachsten Fall nutzt man 
Mnachesterkodierung, sprich, 1 Byte wird als 2 Byte übertragen.

1-Bit -> 01
0-Bit -> 10

Dann klappt das auch recht gut mit der IR-Übertragung.

Die Kodierung und Dekodierung macht ma über eine Tabelle, einfach und 
schnell.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Falk B. schrieb:
> Naja, man muss die Daten halt sinnvoll kodieren.

Wie gesagt, hat der Akai das nicht gemacht. Der hat einfach UART mit 
Startbit gesendet, nicht mal mit Parity. Ich habe damals den Ausgang des 
IR Empfängers mit Wired-OR so verdrahtet, das mein Apple ][ Schnittplatz 
das Ding darüber fernsteuern konnte - mit serieller Karte auf 6850 
Basis. Welche Codes das genau waren, kann ich aber nicht mehr sagen, 
weil die Apple Disketten schon lange nicht mehr existieren.
Aber Versuch macht kluch. Wichtig ist auf jeden Fall die Trägerfrequenz 
beim Senden, um damit UART zu tasten.

[Falk B. (falk)]

Matthias S. schrieb:
> Falk B. schrieb:
>> Naja, man muss die Daten halt sinnvoll kodieren.
>
> Wie gesagt, hat der Akai das nicht gemacht. Der hat einfach UART mit
> Startbit gesendet, nicht mal mit Parity.

Naja, da war der Empfänger recht großzügig und die Datenpakete wohl eher 
klein.

[Christian J. (Gast)]

Falk B. schrieb:
> Sprich, lange Sequenzen
> von 0 oder 1 müssen vermieden werden.

Hmmm.... das sollte eigentlich nicht nötig sein. DIe Burst Seuenz darf 
zwischen 10 und 70 /f0 betragen. Dann muss eine pause kommen. Eine 
Manchester Codierung ist für OOK Sender sinnvoll, bei einem 
Trägerfrequenz basierten System halte ich sie nicht für sinnvoll. Der 
TSOP spuckt ein Low aus, solange was rein kommt und fällt irgendwann 
wieder auf High, wenn die maximale Zeit überschritten wurde, die das 
Signal haben darf.

parity brauche ich auch nicht, egal ob der Text ein falsches Zeichen hat 
oder nicht, er bliebt trotzdem lesbar. Sind reine Text Strings.

Ist mehr oder minder auch für den  TSOP die falsche Sache. Daten werden 
per Irda übertragen - falls das überhaupt noch aktuell ist seit 
Bluetooth. und da gibt es fix und fertige Module, die direkt an TX/RX 
angeschlossen werden von Microchip und Vishay.

[Falk B. (falk)]

Christian J. schrieb:
> Falk B. schrieb:
>> Sprich, lange Sequenzen
>> von 0 oder 1 müssen vermieden werden.
>
> Hmmm.... das sollte eigentlich nicht nötig sein. DIe Burst Seuenz darf
> zwischen 10 und 70 /f0 betragen. Dann muss eine pause kommen. Eine
> Manchester Codierung ist für OOK Sender sinnvoll, bei einem
> Trägerfrequenz basierten System halte ich sie nicht für sinnvoll.

Ich schon, denn diese Empfänger haben einen Art "Doppelfilter" 
eingebaut, welcher sehr viele Signale ausblendet. Dazu gehören auch 
dauermodulierte Signale bzw. Signale mit zu niederfrequenten 
Datensignalen, wie du es hier genannt hast.

> Der
> TSOP spuckt ein Low aus, solange was rein kommt

Nein.

> und fällt irgendwann
> wieder auf High, wenn die maximale Zeit überschritten wurde, die das
> Signal haben darf.

Naja, 70 Trägerpulse sind nicht so viel bei 38kHz, das sind ~1,8ms, bei 
2400 Baud ist das reichlich 1 Bit! Wenn man nun 0xFF sendet, wird das 
eng!

> parity brauche ich auch nicht, egal ob der Text ein falsches Zeichen hat
> oder nicht, er bliebt trotzdem lesbar. Sind reine Text Strings.

Mag sein.

> Ist mehr oder minder auch für den  TSOP die falsche Sache.

Richtig, es ist aber ein brauchbarer Workaround.

> Daten werden
> per Irda übertragen - falls das überhaupt noch aktuell ist

Schon lange tot, wie das Grammophon ;-)

[Christian J. (Gast)]

klappt einwandfrei! Etwas probieren mit den Delays, dann die mitte 
nehmen der beiden Grenzen und schon spult es die Texte runter im 
Terminal :-) 2400 baud, mehr geht nichts.

[Christian J. (Gast)]

Ich pappe es zum Schluss noch hier drunter, vielleicht freut sich ja der 
Nächste drüber:

IR Empfänger: TSOP 1740
IR Sender: TSAL 6000 @ 80mA
Takt: 8 Mhz
CPU: Atmega328P
IR Port: B3 (Arduino 11)
Datenrate: 2400 baud

Alle 20 Bytes wird ein delay von 6ms eingefügt, um die Spec einzuhalten.
20 und 6 sind experimentell ermittelt worden, so dass gerade eben keine 
Ausgabefehler mehr entstehen bei "Dauerfeuer".

Die minimale Distanz beträgt ca 40cm für 2400 baud, dann verzerrt das 
Signal so stark, dass der FTDI es nicht mehr samplen kann. Bei 1200
baud stellt sich dieses Problem nicht.

Erkennung "1" bei 780 - 850us Burst, gewählt 820

/* Erzeugt den Burst */
void SendBurst(uint16_t val) {
  Timer2Enable(true);
  delayMicroseconds(val);
  Timer2Enable(false);
}

/* Sende ein IR Byte im RS232 Mode, 8N1 */
#define BURST 417           /* (us) Bitdauer für 2400 Baud, 820 für 1200 */
void SendIRByte(byte db)
{
   static byte counter;

  /* Startbit senden */
  SendBurst(BURST);

  /* Datenbits hinterher */   
  byte mask = 0x1;
  for (byte i = 0; i < 8; i++) {
    if (db & mask) { // Bit = 1;
       delayMicroseconds(BURST);
    } else {    // Bit = 0;
      SendBurst(BURST);    
    }
    mask = (mask << 1);
  }
  
  /* Stop Bit + 1 Bit Delay */
  delayMicroseconds(BURST);
  delayMicroseconds(BURST);
    
  if (counter++ > 20) {
    delay(6);
    counter = 0;
  }
}

/* Startet oder stoppt den Timer 2 */
void Timer2Enable(bool stat)
{
  /* OC2B Pin = INT 1 Pin (PD 3)
     OC2A Pin = MOSI Pin (PB 3) */

  cli();  
  if (stat) {
    DDRB    |= (1<<PB3);
    TCCR2A  = (1 << WGM21) | (1 << COM2A0); // CTC (MODE_2) + Toggle OC2A
    TCCR2B  = (1 << CS20);                  // Clock => Timer2
    OCR2A   = 99;                           // 40 khz
    TCNT2   = 0;                            // Reset Timer2 Counter
  }
  else {
    TCCR2B  = 0;                // Prescaler 1 und Timer stoppen
    TCCR2A  = 0;                 // Normal Port Operation
    PORTB   &= ~(1 << PB3);      // PB3 Low
  }
  sei();
}

[Olaf (Gast)]

> > per Irda übertragen - falls das überhaupt noch aktuell ist

> Schon lange tot, wie das Grammophon ;-)

Das glaube ich nicht weil es einige moderne Microcontroller gibt wo das 
drin ist. Irgendwer muss es immer noch verwenden.

Olaf