neutralisierung der phaseninvertierung

[georg (Gast)]

hallo,

ich habe hier eine emitterschaltung mit der das signal des arduino 
verstärkt wird, es wird aber auch invertiert, was bei der 
weiterverwendung des signals stört...

gibt es eine einfache möglichkeit die invertierung nach der verstärkung 
wieder rückgängig zu machen? Wäre für jede idee - die ein anfänger auch 
umsetzen kann - sehr dankbar...

[transistor (Gast)]

Einfach in der Software invertieren? Wäre das eine Lösung?

[ArnoR (Gast)]

georg schrieb:
> gibt es eine einfache möglichkeit die invertierung nach der verstärkung
> wieder rückgängig zu machen?

Es gibt sogar die Möglichkeit die Invertierung zu verhindern. Du 
schaltest die LED mit Vorwiderstand einfach zwischen Emitter und Masse 
und den Kollektor an Vin oder +5V. Den Basiswiderstand lässt du weg. Die 
Schaltung hat weniger Aufwand und frisst, im Gegensatz zur 
Emitterschaltung, automatisch nur soviel Baisisstrom wie unbedingt 
nötig.

[wendelsberg (Gast)]

georg schrieb:
> es wird aber auch invertiert, was bei der
> weiterverwendung des signals stört...

Wo wird das Signal invertiert?
Ich sehe: Ausgang wird "1" --> LED leuchtet, also keine Invertierung.

wendelsberg

[Georg K. (inka)]

hallo,

vielen dank für die antworten...

@ArnoR: geändert, wie im schaltplan "ir_bake_2_0-5" gezeichnet, die LED 
blinkt, IR signal wird übertragen, aber im display (nur wirre zeichen..)

@transistor: ich hänge hier doch noch den sketch (sender.ino) dran...

-----------------------------

// 
http://www.meinduino.de/arduino-howto/2014/09/18/serielleuebertragung1.html


// Damit die Pins schnell geschaltet werden können
#include <digitalWriteFast.h>

// Hier ist der Verstärker mit der IR-LED angeschlossen
#define IRLED 8
#define LEDpin 9

// Globale Variablen für den Timer-Interrupt
volatile uint8_t pinZustand = HIGH;
volatile uint8_t sendenAn = false;



/*************************************************************
 *
 * void setup()
 *
 * Wird einmal beim Programmstart ausgeführt
 *
 *************************************************************/
void setup()
{

  pinMode(8, OUTPUT);
  // IRLED ist ein Ausgabe-Pin
  pinModeFast(IRLED, OUTPUT);

  pinMode(9, OUTPUT);

  noInterrupts(); // Jetzt keine Interrupts
  TIMSK1 |= (1<<OCIE1A);  // Timer 1 Output Compare A Match Interrupt 
Enable

  TCCR1A = 0; // "Normaler" Modus

  // WGM12: CTC-Modus einschalten (Clear Timer on Compare match)
  //        Stimmen OCR1A und Timer überein, wird der Interrupt
  //        ausgelöst
  // Bit CS12 und CS10 setzen = Vorteiler: 8
  TCCR1B = (1<<WGM12) | (1<<CS11);

  // Frequenz = 16000000  8  28 = rd. 71,428kHz, da jeweils an- und 
aus-
  // geschaltet wird, ergeben sich rund 36kHz Blinkfrequenz
  OCR1A = 28;

  interrupts(); // Interrupts wieder erlauben
}



/*************************************************************
 *
 * Interrupt Service Routine
 *
 * Wird aufgerufen, wenn der entsprechende Interrupt
 * ausgelöst wird
 *
 *************************************************************/
ISR(TIMER1_COMPA_vect)
{
  noInterrupts();
  if(! sendenAn)
  {
    // IR-LED ausschalten
    digitalWriteFast(IRLED, LOW);
    // Zustand der IR-LED merken
    pinZustand = LOW;
    interrupts();
    return;
  }
  else
  {
    // IR-LED-Pin auf pinZustand schalten
    digitalWriteFast(IRLED, pinZustand);
    // pinZustand invertieren
    pinZustand = (pinZustand == HIGH) ? LOW : HIGH;
  }
  interrupts();
}



/*************************************************************
 *
 * void loop()
 *
 * Wird immer wieder durchlaufen
 *
 *************************************************************/
void loop()
{

  // Sender für 5ms ausschalten
  sendenAn = false;
  delay(5);
  //digitalWrite(9, LOW);

  // Das komplette Alphabet in Großbuchstaben senden
  for(int i='A'; i<='Z'; i++)
  //for(int i=1; i<=9; i++)
  {
    //Serial.write(i);
    sendIR(i);
    digitalWrite(8, LOW);
    digitalWrite(9, LOW);
    delay(250); // Kann entfallen, hier nur, damit man auf
    // dem Empfänger Zeit hat, die Buchstaben
    // zu verfolgen
    digitalWrite(8, HIGH);
    digitalWrite(9, HIGH);
  }
  //digitalWrite(9, HIGH);
}



/*************************************************************
 *
 * void sendIR(uint8_t dataByte)
 *
 * Sendet ein Byte seriell mit 1200bps über die IR-LED
 *
 * dataByte = Das Byte, das gesendet wird
 *
 *************************************************************/
void sendIR(uint8_t dataByte)
{

  // Start-Bit
  sendenAn = false;
  delayMicroseconds(550);
  sendenAn = true;
  delayMicroseconds(230);

  // 8 Datenbits
  for(int i=0; i<8; i++)
  {
    // Falls LSB gesetzt...
    if(dataByte & B00000001 == 1)
    {
      // ... 36kHz-Signal aus (Seriell = Invertierte Logik)...
      sendenAn = false;
      delayMicroseconds(550);
    }
    else
    { // ... andernfalls 36kHz-Signal an
      sendenAn = true;
      delayMicroseconds(230);
    }
    // Das nächste Bit bitte
    dataByte >>= 1;
  }

  // Stopp-Bit
  sendenAn = true;
  delayMicroseconds(550);
  sendenAn = false;

  // kurze Pause
  delay(2);
}

----------------------------------------


@wendelsberg: emitterschaltung invertiert nicht?

gruss  georg

[Achim S. (Gast)]

Georg K. schrieb:
> @wendelsberg: emitterschaltung invertiert nicht?

Kommt darauf an: Wenn du als Ausgangssignal die Spannung am Kollektor 
betrachtest, dann invertiert sie. Das machst du aber nicht.

Wenn du als Ausgangssignal den Strom durch die LED betrachtest, dann 
invertiert sie nicht. Sowohl in deinem ersten Schaltungsentwurf 
(Emitterschaltung) als auch in deiner jetzigen Schaltung, leuchtet die 
LED, wenn der µC-Pin auf high geht.

[wendelsberg (Gast)]

Achim S. schrieb:
> Wenn du als Ausgangssignal den Strom durch die LED betrachtest, dann
> invertiert sie nicht. Sowohl in deinem ersten Schaltungsentwurf
> (Emitterschaltung) als auch in deiner jetzigen Schaltung, leuchtet die
> LED, wenn der µC-Pin auf high geht.

Aber beide Male leuchtet die gruene LED an PWM9, wenn dieser auf 0 ist.
Da wird invertiert.

wendelsberg

[Max H. (hartl192)]

wendelsberg schrieb:
> Aber beide Male leuchtet die gruene LED an PWM9, wenn dieser auf 0 ist.
> Da wird invertiert.
Mach die Invertierung in Software oder verkable die LED so:
µC Pin -- Widerstand -- LED -- GND.

[Georg K. (inka)]

Max H. schrieb:
> wendelsberg schrieb:
>> Aber beide Male leuchtet die gruene LED an PWM9, wenn dieser auf 0 ist.
>> Da wird invertiert.
> Mach die Invertierung in Software oder verkable die LED so:
> µC Pin -- Widerstand -- LED -- GND.

naja, es geht hier aber mehr um die IR-LED, deren Reichweite eben durch 
die Emitterschaltung erhöht werden soll? Wird dort auch invertiert 
(PWM8=0 => IR-LED an?)?
Letztendlich ist es für mich die Frage wie ich diese 
Reichweitenerweiterung erreiche, ohne durch die Phaseninversion das 
Senden innerhalb des IR-pulsbetriebs zu verhindern. Was die aufhebung 
der Hardwareinvertierung durch  Software betrifft habe ich schon einiges 
probiert, funktioniert aber nicht...
Was für Möglichkeiten habe ich sonst noch?

[Achim S. (Gast)]

Georg K. schrieb:
> Letztendlich ist es für mich die Frage wie ich diese
> Reichweitenerweiterung erreiche, ohne durch die Phaseninversion das
> Senden innerhalb des IR-pulsbetriebs zu verhindern. Was die aufhebung
> der Hardwareinvertierung durch  Software betrifft habe ich schon einiges
> probiert, funktioniert aber nicht...

Nichts für ungut, aber ich lese eine Menge aneinandergereihter Begriffe 
ohne zu kapieren, was wirklich deine Frage ist.

Georg K. schrieb:
> Wird dort auch invertiert
> (PWM8=0 => IR-LED an?)?

Das ist doch mal ne Frage, die ich kapiere. Wenn PWM8 auf High steht, 
dann leuchtet die LED. Und das gilt gleichermaßen für beide 
Schaltungsvarianten, die du vorgestellt hast.

In der zweiten Variante (Kollektorschaltung) leuchtet sie etwas weniger 
hell (da ein bisschen mehr Spannung am Transistor hängen bleibt). In der 
ersten Variante (Emitterschaltung) sind die Schaltflanken wohl etwas 
schlapper (wegen der Sättigung des Transistors).

In beiden Fällen ist die Intensität der IR-Diode nicht sehr hoch, da du 
weniger als 20mA durch die IR-Diode schickst. Die meisten Sendedioden 
können deutlich größere Ströme vertragen.

Aber wenn dein Empfänger Unsinn anzeigt, muss das nicht unbeding ein 
Reichweitenproblem sein. Oder klappt die Übertragung plötzlich, wenn du 
Sender und Empfänger näher zusammenbringst? Es kann ebensogut ein 
Timing-Problem deiner Software sein. Ein bisschen komisch finde ich, 
dass du indirekte Steuerung der LED (über sendeAn) und direktes 
Schreiben an den Port (über  digitalWrite(8, HIGH);) mischst. Bist du 
sicher, dass sich das nicht beist? Hast du irgendwelche 
Messmöglichkeiten, um das Timing des IR-Signals zu überprüfen?

[Georg K. (inka)]

Hi Achim,

Also:

ich habe einen RP6-Roboter ( http://rn-wissen.de/wiki/index.php/RP6 ) 
und beschäftige mich damit ihn autonom herumfahren zu lassen. Er soll im 
Bedarfsfall seine Ladestation ( 
http://rn-wissen.de/wiki/index.php/Induktive_Ladestation_für_den_RP6 ) 
finden können, dabei sollen ihm außer einem Kompass auch  IR-Baken ( 
http://rn-wissen.de/wiki/index.php/IR-bake_für_den_RP6 ) helfen. 
IR-Signale kann er über sein ACS empfangen, das funktioniert auch über 
die 5m gut...

Die analogen Baken haben eine Reichweite von gut 5 Metern, sind 
allerdings „dumm“ – sie senden halt nur ein mit 36kHz moduliertes 
Blinksignal (welches der RP6 braucht), deshalb jetzt der Versuch mit 
einer digitalen Bake, basierend auf Arduino mega 2560.
Der Pin des Arduino liefert maximal 20mA, was für eine Reichweite von 
ca. 15 cm reicht, für mehr aber nicht. Verstärkt mit der 
Emitterschaltung komme ich auch auf die ca. 5 m Reichweite, möchte aber 
nun die Intelligenz des mc auch für eine Kommunikation der Bake mit dem 
Roboter nutzen.

Die Software (sender_1.ino) stammt nicht von mir und offen gesagt 
verstehe ich sie auch nur bruchstückhaft.
Der Arduino-Sender und Arduino-Empfänger funktionieren so weit, dass die 
gesendeten 36kHz „Grundsignale“ auch vom Empfänger empfangen werden, 
nicht aber die gesendeten Buchstaben, sondern nur irgendwelche „wirren“ 
zeichen...
Die Ursache dachte ich in der Tatsache gefunden zu haben, dass die 
Emitterschaltung neben des Verstärkens des Signal diesen auch 
invertiert, während die Software von einer nicht invertierenden 
Schaltung ausgeht. Da diese wirren Zeichen aber auch über die 
Collectorschaltung empfangen werden scheint diese These zu widerlegen...

Um aud Deine Fragen einzugehen:
Ich bin alles andere als sicher, dass sich die indirekte Steuerung der 
IR-LED (über sendeAn) und direktes Schreiben an den Port (über 
digitalWrite(8, HIGH);) nicht beist. Auch fehlen mir die
Messmöglichkeiten, um das Timing des IR-Signals zu überprüfen...

[Max H. (hartl192)]

Georg K. schrieb:
> Der Pin des Arduino liefert maximal 20mA, was für eine Reichweite von
> ca. 15 cm reicht
Wie hast du die LED dabei verschalten?

[Georg K. (inka)]

Max H. schrieb:
>> Der Pin des Arduino liefert maximal 20mA, was für eine Reichweite von
>> ca. 15 cm reicht
> Wie hast du die LED dabei verschalten?

so, wie die grüne LED am Pin 9 im Schaltplan im ersten post, also 
zunächstmal ohne den Transistor...

[Achim S. (Gast)]

Georg K. schrieb:
> Der Pin des Arduino liefert maximal 20mA, was für eine Reichweite von
> ca. 15 cm reicht, für mehr aber nicht. Verstärkt mit der
> Emitterschaltung komme ich auch auf die ca. 5 m Reichweite, möchte aber
> nun die Intelligenz des mc auch für eine Kommunikation der Bake mit dem
> Roboter nutzen.

Das kann ich schon mal nicht nachvollziehen, denn deine 
Transistorschaltung ist so dimensioniert, dass ebenfalls weniger als 
20mA fließen (oder in deinem Schaltplan ist der Wert von R2 falsch 
angegeben).

Wenn ich dich richtig verstehe funktioniert die "dumme" 
Lichtbarkenfunktion also über 5m, aber die "intelligente" Übermittlung 
von Zeichen liefert immer Unsinnszeichen (egal welcher Abstand)?

Dann würde ich mal nicht davon ausgehen, dass du ein Reichweitenproblem 
hast, sondern dass die Kodierung der Zeichen oder das Timing der 
Übermittlung nicht stimmen. Ohne echtes Verständnis des Originalcodes 
und ohne Messmöglichkeiten wird es nicht einfach, den Fehler zu finden. 
Als erstes würde ich mal das direkt (statische) Setzen der Ausgänge mit 
digitalWrite(8, HIGH) rauswerfen und nur das (36kHz-modulierte) Steuern 
der Ausgänge mit sendenAn benutzen - ich glaube nicht, dass beides 
zusammen gut gehen kann. Dann würde ich versuche sicher zu stellen, dass 
die Einstellungen des Empfängers zu der des Senders passen (stimmt das 
Timing von 1200bps? Stimmt die Codierung?) Unter "sein ACS" kann ich mir 
leider nichts konkretes vorstellen, da musst du nachlesen, was für 
Einstellungen für die Übertragung genau zu machen sind.

Auch kommt es mir komisch vor, dass die Modulation per Timer-ISR gemacht 
wird, die Bitlänge aber per delayMicroseconds. Wenn dieser Satz aus 
einem Arduino-Forum stimmt, dann kann das nicht gutgehen:

"The delayMicroseconds() function will provide accurate delays as may be 
needed for some types of applications (e.g. SofwareSerial bit banging) 
by disabling interrupts during its core delay code"

Wenn DelayMicroseconds wirklich die Interrupts disabled, dann schaltest 
du damit auch die 36kHz Modulation aus. Wenn es das nicht tut, dann 
werden die zumindest die Bitzeiten ungenau, weil delayMicroseconds 
häufig durch den Timer-Interrupt unterbrochen wird. Sieht für mich nicht 
nach einer funktionsfähigen Kombination aus, auch wenn es in deiner 
Code-Vorlage ebenso gemacht wird. (Allerdings kenne ich mich 
zugegebenermaßen mit den Arduino-Routinen nicht aus).

[Georg K. (inka)]

Achim S. schrieb:
> Wenn ich dich richtig verstehe funktioniert die "dumme"
> Lichtbakenfunktion also über 5m, aber die "intelligente" Übermittlung
> von Zeichen liefert immer Unsinnszeichen (egal welcher Abstand)?
die analoge Bake sendet nur einfache Blinkzeichen (2Hz z.b.), die werden 
vom Empfänger (egal ob RP6 oder Arduino) auch als solche erkannt und der 
Empfang mit einer im gleichen Rhythmus blinkenden LED signalisiert. Das 
macht die digitale Bake auch.


> Dann würde ich mal nicht davon ausgehen, dass du ein Reichweitenproblem
> hast, sondern dass die Kodierung der Zeichen oder das Timing der
> Übermittlung nicht stimmen.
was die Überbrückung der 5m betrifft hatte ich wirklich mit der normalen 
IR-LED ohne die Verstärkerschaltung Probleme mit der Entfernung, mit dem 
Transistor als Verstärker nicht. Aber das ist nicht die Ursache für die 
wirren zeichen die der Arduino-Empfänger vom Arduino-Sender empfängt. 
Und der Abstand auch nicht.

> Als erstes würde ich mal das direkt (statische) Setzen der Ausgänge mit
> digitalWrite(8, HIGH) rauswerfen und nur das (36kHz-modulierte) Steuern
> der Ausgänge mit sendenAn benutzen
habe ich gemacht.

> Dann würde ich versuche sicher zu stellen, dass
> die Einstellungen des Empfängers zu der des Senders passen (stimmt das
> Timing von 1200bps? Stimmt die Codierung?)
beides wohl nicht. Ich habe jetzt die Zählschleife in der Sendefunktion 
rausgenommen un sende bei jedem Durchlauf jetzt die gleiche Zahl. Beim 
Empfänger habe ich die Codierung in der er die Zeichen darzustellen hat 
hinzugefügt (DEC). Jetzt passiert folgendes: Sende ich eine 5, kommt im 
Display eine 16, sende ich eine 6, kommt eine 0. Hängt das evtl. mit dem 
bitweise senden zusammen? Ist noch nicht fertig, aber die zusammenhänge 
werden klarer..

danke erstmal...

[Max H. (hartl192)]

Georg K. schrieb:
> Max H. schrieb:
> Der Pin des Arduino liefert maximal 20mA, was für eine Reichweite von
> ca. 15 cm reicht
>
> Wie hast du die LED dabei verschalten?
>
> so, wie die grüne LED am Pin 9 im Schaltplan im ersten post, also
> zunächstmal ohne den Transistor...
Dann sollte es klappen, wenn du die IR-LED mit einem PNP bzw. P-MOS 
highside schaltest.