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
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%
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
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
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.
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.
:
Bearbeitet durch User
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.
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 ;-)
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.
1 | * Sende ein IR Byte im RS232 Mode, 8E1 */ |
2 | #define BURST 833 /* (us) Bitdauer für 1200 Baud */ |
3 | void SendIRByte(byte db) |
4 | {
|
5 | byte parity = parity_even_bit(db); // Parity Bit errechnen |
6 | |
7 | /* Startbit senden */
|
8 | SendBurst(BURST); |
9 | |
10 | /* Datenbits hinterher */
|
11 | byte mask = 0x80; |
12 | for (byte i = 0; i < 7; i++) { |
13 | if (db & mask) { // Bit = 1; |
14 | delayMicroseconds(BURST); |
15 | } else { // Bit = 0; |
16 | SendBurst(BURST); |
17 | }
|
18 | mask = (mask >> 1); |
19 | }
|
20 | /* Parity Bit */
|
21 | if (parity) { |
22 | delayMicroseconds(BURST); |
23 | } else |
24 | SendBurst(); |
25 | |
26 | delayMicroseconds(BURST); |
27 | delayMicroseconds(BURST); |
28 | }
|
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.
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.
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.
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.
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 ;-)
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.
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
1 | /* Erzeugt den Burst */
|
2 | void SendBurst(uint16_t val) { |
3 | Timer2Enable(true); |
4 | delayMicroseconds(val); |
5 | Timer2Enable(false); |
6 | }
|
7 | |
8 | /* Sende ein IR Byte im RS232 Mode, 8N1 */
|
9 | #define BURST 417 /* (us) Bitdauer für 2400 Baud, 820 für 1200 */ |
10 | void SendIRByte(byte db) |
11 | {
|
12 | static byte counter; |
13 | |
14 | /* Startbit senden */
|
15 | SendBurst(BURST); |
16 | |
17 | /* Datenbits hinterher */
|
18 | byte mask = 0x1; |
19 | for (byte i = 0; i < 8; i++) { |
20 | if (db & mask) { // Bit = 1; |
21 | delayMicroseconds(BURST); |
22 | } else { // Bit = 0; |
23 | SendBurst(BURST); |
24 | }
|
25 | mask = (mask << 1); |
26 | }
|
27 | |
28 | /* Stop Bit + 1 Bit Delay */
|
29 | delayMicroseconds(BURST); |
30 | delayMicroseconds(BURST); |
31 | |
32 | if (counter++ > 20) { |
33 | delay(6); |
34 | counter = 0; |
35 | }
|
36 | }
|
37 | |
38 | /* Startet oder stoppt den Timer 2 */
|
39 | void Timer2Enable(bool stat) |
40 | {
|
41 | /* OC2B Pin = INT 1 Pin (PD 3)
|
42 | OC2A Pin = MOSI Pin (PB 3) */
|
43 | |
44 | cli(); |
45 | if (stat) { |
46 | DDRB |= (1<<PB3); |
47 | TCCR2A = (1 << WGM21) | (1 << COM2A0); // CTC (MODE_2) + Toggle OC2A |
48 | TCCR2B = (1 << CS20); // Clock => Timer2 |
49 | OCR2A = 99; // 40 khz |
50 | TCNT2 = 0; // Reset Timer2 Counter |
51 | }
|
52 | else { |
53 | TCCR2B = 0; // Prescaler 1 und Timer stoppen |
54 | TCCR2A = 0; // Normal Port Operation |
55 | PORTB &= ~(1 << PB3); // PB3 Low |
56 | }
|
57 | sei(); |
58 | }
|
> > 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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.