- 12V Akku mit 280 Ah bauen         
Seite 2 von 3 ErsteErste 123 LetzteLetzte
Ergebnis 11 bis 20 von 21

Thema: Einfache IR-Code Übertragung funktioniert nicht

  1. #11
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.703
    Blog-Einträge
    133
    Anzeige

    Praxistest und DIY Projekte
    Zitat Zitat von R2D2 Bastler Beitrag anzeigen
    Ich bin, wie bereits anfangs erwähnt, nicht total auf "meinen" Code fixiert. Ich nehme auch gern jede andere Möglichkeit der Codegestaltung/Übertragung/Auswertung in Kauf. Es sollen lediglich 4 verschiedene Befehle übertragen werden können und keine Wait-Befehle in einer ISR beinhalten, da ich sonst beim weiteren Ausbau des Codes (RC-Signale einlesen etc) Schwierigkeiten bekomme.
    Hallo,
    noch ein Sendecodeschnipsel zu der weiter oben erwähnten Zeitmeßmethode und ein "Übertragungscode". Kann aber nicht absehen, ob Dein weiterer Ausbau des Codes im Empfänger nicht die Hauptschleifenlaufzeit zu lang macht

    Startbit ist immer 400µs lang und wird mit Burst übertragen
    Ein LOW Datenbit wird mit 600µs Länge übertragen
    Ein HIGH Datenbit wird mit 800µs Länge übertragen
    Ob Datenbit mit Burst oder Pause übertragen wird, hängt von seiner Stelle in der Sendereihenfolge ab.
    Das erste, dritte, also alle ungeraden Datenbits (wenn mit eins zu zählen begonnen wird), wird mit Pause (Gap) übertragen.
    Die geraden Datenbits werden mit Burst übertragen.
    Bei einer geraden Anzahl zu übertragender Datenbits ist der Carrier zum Schluß also abgeschaltet.
    Mit dem Startbit kann synchronisiert werden.
    Maximale Rahmenzeit ist incl. Sicherheitszeit zwischen zwei Rahmen 2400µs, min. ist 2000µs

    Habe nicht genau ins Datenblatt geschaut bzw nicht getestet; falls die Erholungszeiten und Ansprechzeiten des TSOP nicht eingehalten werden, kann man an den Zeiten natürlich noch was drehen.

    Bleibt "nur" noch die Auswerteroutine im Empfänger anzupassen und fehlerhafte Berechnungen der Impulse/Pausen ausschließen, wenn sich lange nichts tut (verstrichene Zeit ist größer 255 Timerticks).

    Code:
    do
    
    Waitus 400                                                  'Sicherheitszeit zwischen zwei Commands
    
    'Startbit (Ir_befehl.2) senden (immer 1)
    Ddrb.0 = 1                                                  'carrier on, burst begin
    Waitus 400                                                  'Startbit soll 400µs lang sein
    Ddrb.0 = 0                                                  'carrier off, burst ende
    
    'erstes Datenbit
    Select Case Ir_befehl.1 
      Case 0 : Waitus 600                                       'für erstes datenbit=0 bleibt carrier für 600µs off
      Case 1 : Waitus 800                                       'für erstes datenbit=1 bleibt carrier für 800µs off
    End Select
    
    'zweites Datenbit
    Ddrb.0 = 1                                                  'carrier on, burst begin
    Select Case Ir_befehl.0
      Case 0 : Waitus 600                                       'ist zweites datenbit=0 ist carrier für 600µs on
      Case 1 : Waitus 800                                       'ist zweites datenbit=1 ist carrier für 800µs on
    End Select
    Ddrb.0 = 0                                                  'carrier zum Schluß wieder off, burst ende
    
    loop
    Alles noch halbgar
    Gruß
    Searcher
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  2. #12
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.675
    Zitat Zitat von R2D2 Bastler Beitrag anzeigen
    ... „Infrarot-Kanone“ für Modellflugzeuge ... Ein Start-Bit und 2 Kommand-Bits ...
    Mach Dich vielleicht von solchen Formalismen frei. EIN Burst - bei 400 µs Dauer ists ne eins, bei 700 eine zwei, bei tausend ne drei und bei ... Ohne Start, ohne irgendetwas. Small is beautiful (und klein/simpel/schnell ist eine Steigerungsart von sophisticated).

    Da Du eh einen GANZEN 45er nimmst, hast Du einen Pinn für die LED, einen für den TSOP und drei für die AUSGABEcode: 0, 1, 2 ... 0 - keine Funktion, 1 bis 4 der Befehlscode, 5 6 nc, 7 Fehlercode. Bleiben Vcc, GND und 1 Pinn als Reserve. Unverschlüsselt gings nicht wirklich, weil Du den /RES nur in Ausnahmefällen als Ausgabepin nutzen wirst (aber mit dem gings natürlich total unverschlüsselt mit vier Ausgabezuständen).
    Geändert von oberallgeier (26.01.2014 um 00:32 Uhr)
    Ciao sagt der JoeamBerg

  3. #13
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.703
    Blog-Einträge
    133
    Hallo,
    habe Dein ursprüngliches Programm nochmal unter die Lupe genommen.

    Zitat Zitat von R2D2 Bastler Beitrag anzeigen
    Bild hier   Zitat von Searcher Bild hier  
    Abhilfetest: Nach "Timer1 = 155" ein "set tifr.tov1" (vorsorglich anstehendes TOV1 Flag löschen) einfügen?
    Du wirst lachen, genau das hatte ich auch schon im Code, allerdings blieb die Kontroll-LED dann aus
    Ist auch richtig und muß drinbleiben UND der INT0 Interrupt in der "Daten_sammeln:" ISR wird zu früh enabled. Es könnte je nach übertragenem Bit noch ein rising edge auftreten, da ja in der Mitte eines Bits gepollt wird.

    Also das Enable INT0 aus der ISR rausnehmen und in der Sendepause einfügen, wenn sich sicher nichts mehr an INT0 tut. Außerdem sollte das "Ir_data" initialisiert werden. Habe es mit dieser Sendepause mal getestet, allerdings nicht sehr ausgiebig. Geht.

    Code:
    'Sendepause einlegen
    Ddrb.0 = 0
    Waitus 2000
    Set Gifr.intf0
    Ir_data = 0
    Enable Int0
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  4. #14
    Hallo oberallgeier

    Danke für Deine ausführliche Darstellung des TSOP Verhaltens. So in etwa habe ich mir es gedacht (auch wenn ich es bei weitem nicht so klar formulieren hätte können)
    Ich wusste allerdings nicht, dass der TSOP auch nach dem Abschalten des IR-Signals noch einige Zeit auf low bleibt (habe keine Gerätschaften, um das rauszumessen). Bedeutet das also, wenn ich meine IR-Led z.B. 1000us lang senden lasse (≙ 36cycles), dann wird der TSOP auch 1000us auf low gehen (zeitverschoben um die paar cycles, um die der TSOP verspätet dran ist?


    Zitat Zitat von oberallgeier Beitrag anzeigen
    Das ist jetzt nicht Dein Ernst? Wie langsam tickert denn Dein Controller? Ist das ein tiny13 mit dem internen 128 kHz-Oszillator? Oder noch langsamer?
    Ich habe vor kurzem an einer RC-Baggersteuerung gearbeitet, bei der RC-Signale (1-2ms) eingelesen, bearbeitet und ausgegeben wurden. Hier wurde die "ISR-Register-Speicher-Orgie" von Bascom zum Hauptproblem. Nur mit viel Hilfe aus diesem Forum und ASM konnte es in den Griff bekommen werden (PS: der Attiny lief dort auch mit 8Mhz). Im jetzigen Projekt kommt der RC-Anteil später noch dazu.


    Zitat Zitat von oberallgeier Beitrag anzeigen
    Da Du eh einen GANZEN 45er nimmst, hast Du einen Pinn für die LED, einen für den TSOP und drei für die AUSGABEcode: 0, 1, 2 ... 0 - keine Funktion, 1 bis 4 der Befehlscode, 5 6 nc, 7 Fehlercode. Bleiben Vcc, GND und 1 Pinn als Reserve.
    Versteh ich jetzt nicht wirklich
    Wie ich bereits zu Beginn geschreiben habe, soll das Teil im Modellflugzeug verbaut werden. Dazu wird der Attiny wie folgt verdrahtet:

    1x IR-LED
    1x TSOP
    1x RC Signal Gas (vom RC-Empfänger) rein
    1x RC Signal Gas (zum Motorregler) raus
    1x Optional RC Signal (feuern) rein

    Damit sind alle Pins (außer VCC, GND und Reset) belegt



    @Searcher
    Deinen neuen Code muss ich mir noch ein paar mal durchlesen, Du weißt ja, ich "liebe" ASM



    Ich werde aber in jede Richtung weiter experimentieren und wieder berichten


    mfg
    Robert


    PS: Die Theorie der IR-Fernsteuerung bin ich durchgegangen, aber es scheiter wohl an der praktischen Umsetzung beim Programmieren

  5. #15
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.675
    ... wenn ... IR-Led z.B. 1000us lang senden lasse ... der TSOP auch 1000us auf low gehen ...
    Klar. MUSS ja so sein, sonst könnte ich nicht die verschieden(st)en Protokolle mit ihren unterschiedlichen high-low-Zyklen verarbeiten.

    ... aber in jede Richtung weiter experimentieren und wieder berichten ...
    NEIN, um alles in der Welt nein. Es reicht wenn Du NUR die sinnvollen Richtungen weiter verfolgst. Die Wahrscheinlichkeit dass eine sinnlos erscheindende Richtung das Optiumum oder auch nur einigermassen sinnvoll wird, ist sehr gering, glaub mir.

    ... RC-Baggersteuerung ... wurde ... "ISR-Register-Speicher-Orgie" von Bascom zum Hauptproblem ...
    Mal nur so als kurzen Denkansatz: ICH dekodiere meine Codes, vorzugsweise RC-5, NICHT (ääähhhh nur zum Teil) mit einer eigenen ISR. Ich habe in meinen Controllern praktisch immer einen 50 µs-Heartbeat - und die Controller laufen praktisch immer mit 20 MHz (kann doch der 45er tiny auch: DAtenblatt: – ATtiny25/45/85: 0 - 10 MHz @ 2.7 - 5.5V, 0 - 20 MHz @ 4.5 - 5.5V); von dem abgeleitet zeigt mein 1-sek-LED-Toggle korrekt an, dass zumindest diese ISR noch läuft. Eine sehr praktische Funktionsanzeige. DANEBEN nutze ich diesen 20 kHz-Timer als Zeitmesser - - und hole mir IN dieser ISR manchen Pinzustand im Polling. Meine zugehörigen Zeitscheiben heissen tupsi - Timer Unit Per Sensor Interrupt, wurde irgendwann so eingeführt und seither beibehalten.

    Auch der Zustand des RC-5-Pinns wird in der Timerroutine abgefragt - und die Zeit für eine "Zustandsperiode" festgehalten. Daneben wird in einer ISR zu einem externen Interrupt (im untenstehenden Code PCINT) der Pinzustand abgefragt, weil ich auf JEDE Zustandsänderung/Flanke triggere. Erfahrungsnachweis: immerhin starte ich mit dieser Routine z.B. in meiner Getränkedose MiniD0 und in meinem WALL R bestimmte Tasks - im WALL R auch eine Wegfahrsperre !!, in meinem ArchieKopf ebenfalls Tasks und auch einzelne Funktionsparameter (schneller, langsamer etc).

    Langer Rede kurzer Sinn . . . steht im Codebeispiel. Vielleicht kannst Du etwas damit anfangen.

    Code:
    // ============================================================================== =
    // ===  Nicht unterbrechbare ISR für timer2, Kanal B !! 20 kHz / 50 µs
     ISR(TIMER2_COMPB_vect)         // Vektor 11 Progr.addr. $0014
     {                              //
    //  SetBit (PORTD, 7);
    // - - - - - - - - - - - - - - -
      if (Izeit_b)  Izeit_b --;     //Interrupt-Timer = 1 ... 20 000 ... (1 sec blink)
      else  Izeit_b = Izthrznt;    // in if (Izeit_1 <= Izthrznt) 
    // - -  Ende der eigentlichen Timer2-ISR
    
    // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    // - -  Zeiten für RC-5-Analyse setzen, RC-5-Analyse in ~mot~/(PCINT2_vect)
      if (IsBitSet (RC5prt, RC5pin)) // WENN RC5-pinn high; Encoder empfängt nichts
      {                             //      => zähle Vorstartcounter hoch
                                    // Vorstartcounter wird in IRS(INT2_vect) genullt
        RCvorsc ++;                 // RC-5-Vor-Sequenz-Counter bis 100 hochzählen
        if (RCvorsc > 1000) RCvorsc = 1000;     // RCvorsc max 1000 tupsi / 50 ms
      }                     // Ende if (RC5prt & (1<<RC5pin))
    
    // - - - - - - - - - - - - - - -
      RCbit_zt     ++;            // Zeit für 1 Codebit 1,778ms, in tupsi 33 .. 38
      RCzeit1      ++;            // Tupsicounter uint16_t für RC-5-Decoding
      RCges_zt     ++;
      if (RCges_zt >= 490 && RCDECO) // Endemarkierung RC-5-Deco  27Nov2012-15:22
      {                             //     Endeerkennung: Zeitablauf und RCDECO != 0
        RCBB        = RCDECO;       // Datum wird übernommen
        RCDCO2      = RCDECO;       // Datum sichern zum Dekodieren
        RCTold      = RCTGGB;       // Toggelbit für nächses Lesen sichern
        RCTGGB      = IsBitSet (RCDECO, 1<<10);     // Togglebit lesen + sichern
        if ( RCTGGB == RCTold ) RCTums  =  0;
        else RCTums  = 1;
        RCDECO      = 0;            // RCDECOdierungsbyte leeren
      }                             //
      if ( RCzeit1 > 2000)          // "Reset" Dekodierung bei einer zehntel Sekunde
      {                             //
    //  RC5roff = 1;                // RC5-read-off, 0 <=> Lesen ist an,  1 <=> aus
        RCzeit1 = 0;                //
      }                             //
    
    // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     return;                        //
    }                       // Ende ISR(TIMER2_COMPB_vect)
    // ============================================================================== =
    
    
    // ============================================================================== =
    // ===  INT20/Pin PC4 zum Dekodieren von RC-5 nach folgendem Arbeitsablauf
    //  -   In ~tmr~/ISR(TIMER2.. wird der Vorstartcounter RCvorsc bis 100 hochgetickt
    //  -   Hier wird zuerst das Startbit abgefragt
    //              
     ISR (PCINT2_vect)      // ISR für INT20 auf Pin PC4 zum Dekodieren von RC-5
     {                      //
    // - - - - - - - - - - - - - - - -
    // Start RC5-Decoding: Level (RC5prt & (1<<RC5pin)) ist low <=> IR-Empfang aktiv !!
    // =====               RC-5-DECOding-Byte (RCDECO) ist Null
    //                     RCvorsc >= 99  -- nur dann ist "vorher" länger high
      if ((!(RC5prt & (1<<RC5pin))) && (!RCDECO) && (RCvorsc > 99))  //
      {                             //
        RCvorsc     =   0;  // Vorstartcounter nullen       07. Nov. 2013 11h42
        RCges_zt    =  18;  // ?? Gesamtzeit in tupsi f EINEN kplt CodeSATZ
                            //  hier ein offset, weil ja 1/2 Bit vorbei ist
        RCBptr      =  13;  // RC-5-Code: Bitpointer (0..13) f RC-5-Code-Word
    // - - - - - - - - - - - - - - - -
    //      Hauptaufgabe: Schreibe Bit ins Target
        RCDECO |= ((uint16_t)1<<13 );       // Hier wird nur Bit 13 {13..0} gesetzt
        RCBptr      =  12;          // ... und pointer auf nächstes Bit
        RCbit_zt    =   0;          // Zeit für 1 Codebit 1,778ms, in tupsi 33 .. 38
      }                             //
    // - - - - - - - - - - - - - - - -
      if (RCBptr >= 0)              // war : if ((32 < RCbit_zt) && (RCbit_zt < 39))
      {                             //
        if ((RCbit_zt>26) && (RCbit_zt < 60)) // <<## gute Funktion, so bleibts
        {                             // Ist ein gültiges Bit erkannt worden ?
          if (!(RC5prt & (1<<RC5pin)))                // High oder low level ?
          {                         //
            RCDECO |= ((uint16_t)1<<RCBptr );  // Bei LOW schreib "1" weg
          }                 // Ende if (!(RC5prt & (1<<RC5pin))) : High oder low
          RCBptr      -- ;          // ... und pointer auf nächstes Bit
          RCbit_zt    =   0;        // Zeit für 1 Codebit 1,778ms, in tupsi 33 .. 38
        }                   // Ende if ((RCbit_zt>26) && (RCbit_zt < 48))
      }             // Ende if (RCBptr >= 0)
    // - - - - - - - - - - - - - - - -
    //      TESTWEISE Ausgabe Codewort und Zeitbedarf
      if ((RCBptr < 0) && (RCges_zt < 1000))
      {                             //
        RCBptr      = 0;            // doppelte Ausgabe verhindern
      }                 // Ende if (RCBptr < 0)
    // - - - - - - - - - - - - - - - -
     }              // Ende ISR (PCINT2_vect)
    // ============================================================================== =
    ABER - wie schon oben geschrieben - ich vermute dass Du mit der Abfrage der Pulslänge Deines DEKODIERTEN IR-Pulses alleine Deine Steuerung erfüllen könntest.

    1x IR-LED
    1x TSOP
    1x RC Signal Gas (vom RC-Empfänger) rein
    1x RC Signal Gas (zum Motorregler) raus
    1x Optional RC Signal (feuern) rein
    Jaaaaa - so eine Tabelle ist SEHR aussagekräftig. Danke. Dir reicht also eigentlich a) das Durchschleifen des RC-Gas-rein zum RC-Gas-raus UND die Analyse des RC-Signals (und ich denke für eine erste Funktion brauchst Du NUR die Existenz dieses Signals nachzuweisen, ohne Codecontrolle). Und wenn dieses Signal erreicht wird, dann wird eben das RC-Gas-raus für ne bestimmte Zeit auf "wenig Gas" gesetzt. Oder ?!
    Ciao sagt der JoeamBerg

  6. #16
    @oberallgeier

    mit "in jede Richtung" meinte ich natürlich nur sinvolle

    Kann der Attiny 20MHz OHNE Quarz, also intern? Hab persönlich noch nie was darüber gelesen

    Ansonsten, Du weißt schon, dass Du programmiertechnisch in Spheren über mir schwebst (ich kann nur sehr begrenzt Bascom, kein C oder ähnliches )


    @Searcher

    Hab Deine Änderungen nun auch getestet. Funktioniert leider bei manchen Code-Kombinationen nicht immer.

    Senden 100, empfangen 100 -> LED leuchtet ständig
    Senden 110, empfangen 100 -> LED leuchtet wenn sie aus sein sollte und umgekehrt
    Senden 101, empfangen 100 -> LED leuchtet wenn sie aus sein sollte und umgekehrt
    Senden 111, empfangen 110 -> LED leuchtet oft kurz auf,wenn optische Verbindung unterbrochen oder wieder hergestellt wird
    Senden 111, empfangen 101 -> LED leuchtet oft kurz auf,wenn optische Verbindung unterbrochen oder wieder hergestellt wird


    Ich teste auch mal die Auswertung der Pulslängen, mal sehen, wie genau das wird (es müssen ja nur 4 verschiedene Längen erkannt werden)...

    mfg
    Robert

  7. #17
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.675
    ... Kann der Attiny 20MHz OHNE Quarz, also intern ...
    Kann er nicht, stimmt. Aber da gibts irgendwelche Sonderheiten zu tiny15-Kompatibilität.

    Sorry, dass ich Dir nur Hilfen in C gebe. Bascom kann ich nicht.
    Ciao sagt der JoeamBerg

  8. #18
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.703
    Blog-Einträge
    133
    Hallo,
    Zitat Zitat von R2D2 Bastler Beitrag anzeigen
    Ich teste auch mal die Auswertung der Pulslängen, mal sehen, wie genau das wird (es müssen ja nur 4 verschiedene Längen erkannt werden)...
    da habe ich auch mal exprimentiert und komme immer mehr zu dem Schluß, daß das nicht besonders gut ist:

    Zwischenstand mit meinem verwendeten TSOP31236:
    Fremdlicht kann erheblichen Einfluß auf die vom TSOP weitergegebenen Pulslängen haben.
    Meine Schreibtischleuchtstofflampe hat definitiv erheblichen Einfluß auf die Pulslänge.
    Teilweise abgeblendete IR-Sendediode verändert die Pulslänge auch.
    Bei meinem noch nicht ganz ausgereiftem und schon kompliziert gewordenem Programm führt das zu Kommandofehlinterpretationen.

    Werde jetzt mal versuchen mit Flankenzählung innerhalb einer gewissen Zeitspanne weiterzumachen. Problem finde ich bei der Erkennung von verfälschten Telegrammen - ob man die ganz aussortieren kann

    Gruß
    Searcher
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  9. #19
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    03.09.2009
    Ort
    Berlin (Mariendorf)
    Beiträge
    1.023
    Zitat Zitat von Searcher Beitrag anzeigen
    Fremdlicht kann erheblichen Einfluß auf die vom TSOP weitergegebenen Pulslängen haben.
    Meine Schreibtischleuchtstofflampe hat definitiv erheblichen Einfluß auf die Pulslänge.
    Was ist denn die Zielsituation bzgl. Beleuchtung? Ein Hallenwettbewerb oder OpenAir? Das Produkt darf auf der Werkbank ruhig Fehlfunktionen haben - nur im realen Einsatzszenario eben nicht.

    edit: Ooop, das wurde ja schon ganz am Anfang gesagt: Indoor, also Kunstlicht.

    Zitat Zitat von Searcher Beitrag anzeigen
    Teilweise abgeblendete IR-Sendediode verändert die Pulslänge auch.
    . . . Werde jetzt mal versuchen mit Flankenzählung innerhalb einer gewissen Zeitspanne weiterzumachen.
    Klingt erfolgversprechender.
    Geändert von RoboHolIC (29.01.2014 um 12:14 Uhr)

  10. #20
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.675
    Zitat Zitat von Searcher Beitrag anzeigen
    ... TSOP31236 ... Fremdlicht kann erheblichen Einfluß auf die vom TSOP weitergegebenen Pulslängen haben ...
    Das wundert mich jetzt schon. Ich hatte bei meinen Anwendungen zwar nie TSOPs verwendet - aber soo unterschiedlich können die doch nicht zu den Osram-SFHs sein. Denn bei meinem RC-5-Dekoder ist die Datenübertragung ziemlich gut und sicher, es gibt sehr selten Ausfälle/Störungen. Und der Code ist ja auf relativ genaue Pulslängen angewiesen, sonst gibts sicherlich Fehlinterpretationen.

    Ich hatte allerdings deutliche Störungen gefunden durch die LED-Beleuchtung von Bildschirmen - da gings aber um eine eher "analoge" Auswertung der Photodetektoren - es wurde die Ansprechschwelle des Detektors auf reflektiertes IR-Licht einer gepulsten LED mit variablem duty-cycle bestimmt.

    Zitat Zitat von R2D2 Bastler Beitrag anzeigen
    ... Ich kämpfe zur Zeit mit den Tücken einer „Infrarot-Kanone“ für Modellflugzeuge (indoor) ...
    Meine autonomen Dosen und mein WALL R fahren fast nur indoor, da müsste ich bei massiven Einflüssen durch Kunstlicht doch auffällig viele Störungen feststellen. Wie geschrieben, Fehlfunktionen sind bei mir die Ausnahme - und das bei mittlerweile vielen verschiedenen Beleuchtungssituationen.
    Ciao sagt der JoeamBerg

Seite 2 von 3 ErsteErste 123 LetzteLetzte

Ähnliche Themen

  1. Yeti: Übertragung funktioniert nicht! Hilfe!
    Von Mandy88 im Forum Allgemeines zum Thema Roboter / Modellbau
    Antworten: 3
    Letzter Beitrag: 29.03.2010, 07:08
  2. IR Übertragung funktioniert nicht
    Von -Hunter- im Forum Asuro
    Antworten: 16
    Letzter Beitrag: 18.06.2008, 21:59
  3. Übertragung funktioniert nicht mehr richtig
    Von A.S.U.R.O. im Forum Asuro
    Antworten: 5
    Letzter Beitrag: 23.03.2008, 15:09
  4. AVR UART Übertragung funktioniert nicht
    Von theneutrino im Forum C - Programmierung (GCC u.a.)
    Antworten: 2
    Letzter Beitrag: 08.04.2007, 13:29
  5. Übertragung funktioniert nicht
    Von dominik66 im Forum Asuro
    Antworten: 1
    Letzter Beitrag: 02.10.2006, 16:34

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test