Druckbare Version
Hallo Zusammen,
Ich habe folgendes Problem, dass die IR LEDs des ACS scheinbar zu schwach "leuchten".
Ich bekomme so auf normalem Weg keine Reaktion auf den Empfänger. Die Bauteile sind alle in Ordnung, Lötstellen nachgelötet.
Als ich die LEDs über ein Kabel angeschlossen habe und diese direkt vor den Empfänger gehalten habe, bekam ich die Reaktion.
Aber nur bei direkter Einstrahlung auf kurze Distanz.
Was ist da faul?
Vielen Dank!
MfG
Sascha
Wird auch die 36kHz-Trägerfrequenz für das ACS-Signal erzeugt?
Die Reichweite bei richtiger Ansteuerung der IR-Leds ist meiner Meinung nach ausreichend:
http://www.youtube.com/watch?v=0EVu3qImZ0k
http://www.youtube.com/watch?v=5exIBE11L04
naja, ich habe kein oszi um das zu messen, aber da die eigentliche Funktion erfüllt wird wenn ich die IR LEDs direkt vor den Empfänger halte, denke ich das die Frequenz stimmt.
Es muss irgendwas mit der Strahlungsleistung zu tun haben. Entweder zu wenig Spannung oder Strom. kann man da in der Software was einstellen?
Gruß
Hallo
Man kann sogar serielle Zeichen senden ohne IR-Trägerfrequenz, allerdings nur im Ultranahbereich:
https://www.roboternetz.de/community...on-für-den-RP6
IR-Leds kann man meist mit einer Digicam/Handycam sichtbar machen. Der 36kHz-Empfänger wiederrum reagiert meist auf TV-Fernbedienungen. Gegenprobe wäre Cam sieht Fernbedienung.
Da mein probot die orginale Beschaltung der IR-Leds verwenden und auch der TSOP orginal aufgebaut ist, vermute ich einen Programmfehler als Ursache. Mit der Software wird die IR-Led nur ein- oder ausgeschaltet. Mit dem Tastverhältniss von Impuls und Pause der Trägerfrequenz kann man noch spielen, aber das ist im Moment noch Offtopic...
Gruß
mic
[Edit]
Zu: "ich habe kein oszi um das zu messen,"
Wenn die 36kHz an einem Pin ausgegeben werden, was ja ziemlich sicher im Hintergrund per Interrupt erledigt wird, kann man während der Ausgabe gleichzeitig den Pegel des Pins im Hauptprogramm einlesen und jeweils einer anderen Anzeige-LED zuordnen. Wenn beide Anzeigeleds leucheten werden auch beide Pegel ausgegeben.
Ich hoffe dir ist klar das schwere Augenschäden enstehen können,Zitat:
Zitat von safcon
wenn man zu lange in eine solche IR-LED schaut!!!
Hallo
Also das läßt mir jetzt keine Ruhe. Von Augenschäden habe ich noch nie was gelesen. Allerdings scheint da was dran zu sein:
Das ist ein Zitat aus unserem Wiki: http://www.rn-wissen.de/index.php/Leuchtdiode#IR-LEDsZitat:
ACHTUNG, extremes Verletzungsrisiko = Erblindungsgefahr : Bitte keinesfalls direkt in die leuchtende Infrarotdiode sehen - egal ob man denkt, dass die leuchtet oder nicht. Das Licht kann nicht erkannt werden; wenn man etwas merkt, ist der Augenschaden schon da.
Aber warum klebt kein Warnhinweis auf den Sharps und auch in der Anleitung finde ich keinen: http://www.produktinfo.conrad.com/da...GP2Y0A02YK.pdf
Da die Leistung unserer IR- und ACS-Anwendungen durchaus mit einer Fernbedienung vergleichbar sein dürfte, irritiert mich nun diese Aussage etwas:
(Aus http://www.mikrocontroller.net/topic/71326#581735)Zitat:
naja, wenn man bedenkt, dass die fernbedienungen auch mit ir-leds
mittlerer leistungsklasse befeuert werden erledigt sich die frage schon.
Das sollte man doch genauer untersuchen.
Gruß
mic
[Edit]
Da ich nun schon wach bin:
(Aus https://www.roboternetz.de/community...l=1#post498302)Code:'Abszandsmessung mit den linken IR-Dioden!!!
For loop_cnt = 1 To 10
'PWM neu stellen von ca. 28 bis 36Khz (51 = 36Khz)
Timer_T3PWM(62-loop_cnt,TSOP_sensity+(loop_cnt/TSOP_increase),PS_
Dieser Ansatz spielt mit der Frequenz. Das hatten wir mit der bee auch mal versucht und festgestellt, das der TSOP sehr genau auf seine Trägerfrequenz reagiert. Schon bei geringer Frequenzabweichung ignoriert er das Signal. Ein 38kHz-TSOP versteht auch kein RC5 mit 36kHz-Trägerfrequenz.
Nö ist deutlich geringer - jedenfalls beim RP6 vom Probot weiss ichs nicht.Zitat:
Da die Leistung unserer IR- und ACS-Anwendungen durchaus mit einer Fernbedienung vergleichbar sein dürfte
Nur das IRCOMM auf dem RP6 ist mit einer Fernbedienung vergleichbar.
Aber sowohl ACS als auch IRCOMM senden nur sehr kurze Impulse aus...
MfG,
SlyD
Hallo
Ja, das IRCOM hat richtig bumms. Zwei in Reihe geschaltete LD271 über R6 (10Ohm!) und den MosFet RLML2502PBF als Schalter direkt an UBat+. Das dürfte doch deutlich mehr sein als eine Fernbedienung bringt.
Dagegen wirkt die IR-Ausrüstung des probot sehr bescheiden. Dreimal TSUS520 in Reihe mit 150Ohm an zwei IO-Pins des Kontrollers. Verwunderlich, dass da überhaupt was rauskommt. Aber scheinbar funktioniert es:
Zitat:
Zitat von radbruch
Zitat:
Zitat von Besserwessi
Gemessen habe ich allerdings noch nicht, weils ja auf Anhieb funktionierte.Zitat:
Zitat von radbruch
Gruß
mic
[Edit]
Jetzt habe ich auch mal einen Blick in den Schaltplan des probots geworfen. Links wird das PWM-Signal (die 36khz) von OC3A eingespeist, rechts gehts dann über TXD1 (links) bzw. PD5 (rechts) nach GND. Deshalb müssen diese Pins als Ausgang geschaltet sein, der OC3A-Pin muss für den Timer aktiviert sein und, ganz wichtig, der USART1 muss ausgeschaltet sein, wenn man TXD1 selbst kontrollieren möchte. Viele Möglichkeiten für Programmfehler...
btw.: https://www.roboternetz.de/community...l=1#post429810
Na ja, da ist halt jemand auf # sicher gegangen, was auch OK ist. Die LeIstung "einfacher" IR LED's wird (hoffendlich) nicht ausreichen einen nennenswerten Augenschaden zu verursachen, trotzdem ist IR gefährlicher als "sichtbares" Licht. Schaut Mensch in eine starke sichtbare Lichquelle kommt es zum Augenreflex, die Pupille (Blende) macht dicht und schützt so das Auge. Kennt jeder auch von Reflexprüfungen Arzt oder Polizei teste mit Taschenlampe diesen Reflex. Bei voll gekiffte oder Kranke entfällt dieser B.z.w. ist stark verzögert.Zitat:
Zitat von radbruch
Bei "unsichtbaren" Licht IR, UV u.s.w. gibt es diesen Reflex auch nicht, die volle Lichtleistung trifft auf den Augen Hintergrund (Netzhaut) und kann dort (im Fokus) zu Einblutungen oder Verdampfungen führen. :-(
Wenn die Lichtleistung von IR LED's wie in Fehnbedinungen gefährlich wäre, würde es diese Geräte nicht auf den Markt geben! Schließlich ist nicht zu Verhindern das Kleinkinder damit herumspielen......
Gruß Richard
Ich benutze das den Systemtest "ACS - Check"
da sollte doch alles korrekt sein.
Meine Theorie ist auch das die Spannung an LEDs zu gering ist und dadurch die Strahlleistung zu schwach ist.
Gruß
Hallo
Die Leistung kannst du nur erhöhen, wenn du die Vorwiderstände der IR-LEDs änderst. Aber das sollte nicht nötig sein, wenn sie richtig angesteuert werden. Hast du inzwischen überprüft, ob OC3A auch wirklich als Ausgang konfiguriert ist und ob der Pin den Pegel wechselt, wenn die IR-LEDs aktiv sind?
Ich kenne nur die Hardware des probot, mit dem C-Control und seiner Programmierung hatte ich noch keinen Kontakt. Deshalb kann ich nicht sagen, ob und wie der Systemtest "ACS - Check" funktioniert (oder ob er je funktioniert hat).
Gruß
mic
P.S.: Wie sieht denn dein Progamm aus?
Das ist der SystemCHeck den ich verwende:
Code:#define PWM_IR 35
#define IR_left 27
#define IR_right 29
#define TSOP 26
Dim Text(40) As Char
Sub main()
PRO_BOT128_INIT()
Port_DataDirBit(IR_left,PORT_OUT)
Port_DataDirBit(IR_right,PORT_OUT)
Port_DataDirBit(TSOP,PORT_IN)
Timer_T3PWM(51,25,PS_8)
AbsDelay(500)
Do While True
Port_WriteBit(IR_left,PORT_OFF)
Port_WriteBit(IR_right,PORT_ON)
AbsDelay(5)
If Port_ReadBit(TSOP) = 0 Then
Text = "Object right"
Msg_WriteText(Text)
Msg_WriteChar(13)
AbsDelay(500)
End If
AbsDelay(100)
Port_WriteBit(IR_left,PORT_ON)
Port_WriteBit(IR_right,PORT_OFF)
AbsDelay(5)
If Port_ReadBit(TSOP) = 0 Then
Text = "Object left"
Msg_WriteText(Text)
Msg_WriteChar(13)
AbsDelay(500)
End If
AbsDelay(100)
End While
End Sub
Hallo
Das ist ja fast genau das nicht funktionierende Programm aus diesem Thread:
https://www.roboternetz.de/community...ür-Pro-Bot-128
Ausgehend von diesen Kommentaren...
...setzt in Timer_T3PWM der erste Parameter die Periodendauer (51 für 36kHz) und der zweite Parameter steuert das Impuls/Pause_Verhältnis (sollte bei ersten Tests ca. 25 sein). Die Funktion des dritten Parameters (PS_8) kann ich nicht erkennen. Deine Parameter erscheinen also richtig.Code:'Timer_T3PWM(Par1,Par2,PS);
'Period = Par1*PS/FOSC (51*8/14,7456MHz=27,66 µs) = 36Khz
'Pulse = Par2*PS/FOSC (25*8/14,7456MHz=13,56 µs) On Time
'Timer_T3PWM(Word period,Word PW0,Byte PS) '36Khz
'Mit Par1, Par2 kann die Entfernung eingestellt werden
Nun weiß ich nicht, was in PRO_BOT128_INIT() alles erledigt wird, aber in deiner Programmvariante deutet dies...
...darauf hin, dass die Datenrichtung der verwendeten Portpins "von Hand" definiert werden müssen. Hier fehlt allerdings das weiter oben schon erwähnte Setzen der Datenrichtung für den OC3A als Ausgang:Code:Port_DataDirBit(IR_left,PORT_OUT)
Port_DataDirBit(IR_right,PORT_OUT)
Port_DataDirBit(TSOP,PORT_IN)
Timer_T3PWM(51,25,PS_8)
Port_DataDirBit(PWM_IR,PORT_OUT)
Ohne diesen Befehl werden die 36kHz über den internen PullUp ausgegeben. Das würde deine extrem schwache Leistung deiner IR-LEDs erklären.
Gruß
mic
Danke für die kompetente Hilfe, aber es funktioniert immer noch nicht.
"Port_DataDirBit(PWM_IR,PORT_OUT)"
hatte ich auch schonmal, aber hatte sich leider nichts verändert.
Ich werd die Frequenz mal mit nem Oszi testen lassen.
Ich hab nochmal Spannungen gemessen:
OC3A zu Masse sind etwa 2,5V, PD5 zu Masse 5V.
Bleiben also für die 3 LEDs und den Widerstand etwa 2,5V
Gruß
Es funktioniert ja noch nicht, möglicherweise denke ich auch zu kompliziert.
"OC3A zu Masse sind etwa 2,5V" bedeutet 50:50 Tastverhältnis. Also läuft immerhin der Timer. "PD5 zu Masse 5V" ist allerdings schlecht. Wenn der Pin high ist gibt es keinen Strom durch die IR-LEDs und man kann nicht unterscheiden, ob OC3A direkt oder über PullUp gemessen wird. Besser wäre eine Messung des Stroms durch die LEDs an OC3A.
Das Programm wechselt die Seite bei der Abfrage. Zuerst wird rechts gemessen:
Kathoden der linken LEDs auf Low, die der Rechten auf High. Prima, jetzt leuchten aber die linken LEDs. Seiten vertauscht?Code:Do While True
Port_WriteBit(IR_left,PORT_OFF)
Port_WriteBit(IR_right,PORT_ON)
AbsDelay(5)
If Port_ReadBit(TSOP) = 0 Then
Text = "Object right"
Bild hier
[Edit]
Wie lange dauert denn das "AbsDelay(5)"? Der TSOP braucht mindestens 6-10 Impulse bis er das Signal erkennt. Das wären 10 * (1/36000) oder 0,000277Sek bzw. 277µs. Und die Leds leuchten auch nicht schlagartig...
Nein, es bleiben für die drei LEDs und den Widerstand (und den PullUp?) genau 36000 mal 5V und 36000 mal 0V in der Sekunde. ;)Zitat:
Bleiben also für die 3 LEDs und den Widerstand etwa 2,5V
Zu "Besser wäre eine Messung des Stroms durch die LEDs an OC3A."
Mit und ohne "Port_DataDirBit(PWM_IR, PORT_OUT)", jeweils mit "Port_WriteBit(IR_right,PORT_OFF)".
[Edit2]
Vorsichtshalber habe ich mal das Pinout überprüft:
http://www.c-control-pro.de/document...ordnung128.htm
#define IR_right 29: Scheint richtig. PortBit 29 ist PD5.
#define IR_left 27: PortBit 27 ist PD3/TXD1. Auch richtig.
Also bei der Messung habe ich neue Erkenntnisse gewonnen:
1. Ob "PWM_IR OUT" oder nicht, spielte bei der Messung keine Rolle
2. Es fließt ein Strom von 3,5mA im aktiven Strang
3. Bei "PORT_OFF" messe ich 5V zur Masse im ensprechendem Strang, bei "PORT_ON" sind es 0V (sollte es nicht anders herum sein)
AbsDelay(5) dauert 5/1000 sec also 0,005sec, das sollte reichen
Hallo
3,5mA könnten bei 50:50 der Berechnung entsprechen: "Das ergibt (5V-3*1,3V)/150Ohm=0,007A pro Strang".
1 könnte bedeuten, dass Timer_T3PWM() doch Einfluss auf die Pinkonfiguration nimmt. Die mit Port_DataDirBit() gesetzte Datenrichtung wird überschrieben:
Die Bedeutung von "PS_8" ist auch noch nicht klar.Code:Port_DataDirBit(IR_left,PORT_OUT)
Port_DataDirBit(IR_right,PORT_OUT)
Port_DataDirBit(TSOP,PORT_IN)
Port_DataDirBit(PWM_IR,egal)
Timer_T3PWM(51,25,PS_8)
Bei 3 verstehe ich die Frage nicht.
Um AbsDelay() zu testen könntest du eine LED im Sekundentakt blinken lassen.
Gruß
mic
Timer_T3PWM( 51,25,PS_8 )
PS_8 steht für die Zeitbasis (Dauer eines Ticks)
Diese ist bei PS_8 542,5 ns.
Daraus errechnet sich die Frequenz:
Periodendauer = 542,5ns*51 = 0,02766 s
Frequenz = 1/Periodendauer = 36,143 Hz
----------------------------------------------
AbsDelay(Dauer in Millisekunden)
Also bei AbsDelay (1000) blinkt die LED relative genau im Sekundentakt
Gruß
Aha, vielleicht sollte ich mir doch mal die Doku anschauen. PS steht für PreScaler (=Vorteiler). Die Periodendauer bei 36000Hz (36kHz) ist doch 27,7µs oder 0,0000277Sek. (0,0000277+36000=0,9972). Aber leider wird's dadurch auch nicht besser. 542,5ns sind 0,0000005425Sek., mal 51 sind 0,0000276675Sek.Zitat:
PS_8 steht für die Zeitbasis
http://www.c-control-pro.de/document...imer_t3pwm.htm
So müßten 2*0,007mA durch OC3A fliesen. Wenn das klappt kann man wieder ohne aktivierten Timer in der Hauptschleife den OC3A "von Hand" togglen. OC3A ein, Periodendauer warten, OC3A aus, Periodendauer warten usw. Nach jedem Durchgang kann man den TSOP abfragen und den Status an einer LED ausgeben.Code:#define PWM_IR 35
#define IR_left 27
#define IR_right 29
#define TSOP 26
Sub main()
PRO_BOT128_INIT()
Port_DataDirBit(PWM_IR,PORT_OUT)
Port_DataDirBit(IR_left,PORT_OUT)
Port_DataDirBit(IR_right,PORT_OUT)
Port_DataDirBit(TSOP,PORT_IN)
// Timer_T3PWM(51,25,PS_8) // Timer nicht aktivieren
Port_WriteBit(PWM_IR,PORT_ON) // Anoden High
Port_WriteBit(IR_left,PORT_OFF) // Kathoden Low
Port_WriteBit(IR_right,PORT_OFF)
Do While True
End While
End Sub
Gruß
mic
Mir ist grad das Herz in die Hose gerutscht :O
Hab aber grade nochmal genau nachgeschaut:
es ist so Belegt wie erst geschrieben,
OC3A ist 35
PD5 ist 29
PD3 ist 27
OC3A lässt sich auch mit dem code
nicht einfach auf High schalten.Code:#define PWM_IR 35
#define IR_left 27
#define IR_right 29
#define TSOP 26
Sub main()
PRO_BOT128_INIT()
Port_DataDirBit(PWM_IR,PORT_OUT)
Port_DataDirBit(IR_left,PORT_OUT)
Port_DataDirBit(IR_right,PORT_OUT)
Port_DataDirBit(TSOP,PORT_IN)
// Timer_T3PWM(51,25,PS_8) // Timer nicht aktivieren
Port_WriteBit(PWM_IR,PORT_ON) // Anoden High
Port_WriteBit(IR_left,PORT_OFF) // Kathoden Low
Port_WriteBit(IR_right,PORT_OFF)
Do While True
End While
End Sub
Gruß
Du hast recht mit der Belegung der Pins. Sorry. Muss mich noch mehr einlesen...
Gruß
mic
[Edit]
Echt kniffelig. Inzwischen habe ich noch einen dritten Versuch auf der selben Codebasis gefunden. Die funktioniert leider auch nicht:
https://www.roboternetz.de/community...28-ACS-Problem
Warum verwendet ihr nicht die Funktionen aus der probot-Library?
Die Antwort kann ich mir selbst geben: Weil der Code der Library die Basis für eure Varianten ist:Code:ACS_INIT()
Initialisiert das Anti-Collisions-System, muss vor der Benutzung aufgerufen werden.
ACS_LEFT() as byte
Gibt des Status der Hindernis-Erkennung zurück (linker Sensor):
1 = kein Hindernis
0 = Hindernis erkannt
ACS_RIGHT() as byte
Gibt des Status der Hindernis-Erkennung zurück (rechter Sensor):
1 = kein Hindernis
0 = Hindernis erkannt
Code:/---[ ACS System ]-------------------------------------------------------------
void ACS_INIT(byte sensitivity)
{
//Calculating the pulse width modulation
//Timer_T3PWM(Par1,Par2,PS);
//Period=Par1*PS/FOSC (51*8/14,7456MHz=27,66 µs) = 36Khz
//Pulse=Par2*PS/FOSC (25*8/14,7456MHz=13,56 µs) On Time
//Timer_T3PWM(word period,word PW0,byte PS) '36Khz
Timer_T3PWM(51,sensitivity,PS_8); //with Par1, Par2 can reach altered!
//Responding To the ACS must be sensitive To these parameters are screwed!
}
//---[ Read ACS Sensor right ]--------------------------------------------------
byte ACS_RIGHT(void)
{
byte ACS_Right;
Port_WriteBit(IR_left,PORT_OFF);
Port_WriteBit(IR_right,PORT_ON);
AbsDelay(5);
ACS_Right=Port_ReadBit(TSOP);
Port_WriteBit(IR_right,PORT_OFF);
return ACS_Right;
}
//---[ Read ACS Sensor left ]---------------------------------------------------
byte ACS_LEFT(void)
{
byte ACS_Left;
Port_WriteBit(IR_right,PORT_OFF);
Port_WriteBit(IR_left,PORT_ON);
AbsDelay(5);
ACS_Left=Port_ReadBit(TSOP);
Port_WriteBit(IR_left,PORT_OFF);
return ACS_Left;
}
Also ich hab mir jetzt ein SRF02 zugelegt, der die Arbeit übernehmen soll.
Bei dem Timer tipp ich jetzt einfach ma auf einen Defekt.
Besteht eigentlich die Möglichkeit statt des Timer_T3PWM
den Timer_T0PWM zu nutzen?
Gruß