Hallo, Ich versuche eine Simple Fernbedinung zu bauen, Ich verwende dazu einen ATTINY 85 und eine IR LED Hier der Code, am Oszi siehts gut aus, nur der Fernseher macht nix void setup() { DDRB |= (1<<PB0); //Set pin PB0 as output TCNT0 = 0; TCCR0A=0; TCCR0B=0; TCCR0A |=(1<<COM0A0); //Timer0 in toggle mode Table 11-2 TCCR0A |=(1<<WGM01); //Start timer 1 in CTC mode Table 11.5 TCCR0B |= (1 << CS00);// Prescaler table 11.6 OCR0A=105; //CTC Compare value pinMode(1, INPUT); // Pin ist Eingang //Taster } void loop() { int onoff[]={4500,4500,560 .. . .. . }; int laenge = sizeof(onoff) / sizeof(onoff[0]); DDRB &= ~(1<<PB0); // Pin PB0 auf low if (digitalRead(1) == HIGH) { for(int i=0; i<laenge;i=i+2){ DDRB |= (1<<PB0); // Pin PB0 auf high delayMicroseconds(onoff[i]); DDRB &= ~(1<<PB0); // Pin PB0 auf low delayMicroseconds(onoff[i+1]); } } }
Andreas schrieb: > Hier der Code, am Oszi siehts gut aus, nur der Fernseher macht nix Fernseher eingeschaltet?
Andreas schrieb: > Ich verwende dazu einen ATTINY 85 und eine IR LED Schaltung? Geh einfach mal ganz nahe an den Empfänger ran.
Hoffentlich hat die IR-LED einen Vorwiderstand. Irgenwie erkenne ich zwar eine Code-Tabelle, aber keine Verknüpfung mit der "Trägerfrequenz" von z.B. 36 kHz.
Zur Schaltung, Am Pin 1 hängt ein Taster mit Pull Down Widerstand, und am Pin 0 die LED mit vorwiederstand, und zwischen VCC und GND noch ein 100nF Kondensator Bin mit der LED direkt beim Fernseher gewesen
Die Trägerfrequenz vermisse ich auch, und das
1 | DDRB |= (1<<PB0); // Pin PB0 auf high |
2 | DDRB &= ~(1<<PB0); // Pin PB0 auf low |
sollte sicher PORTB ... heißen.
delayMicroseconds() erzeugt nur mit konstanten Parametern halbwegs präzise Zeiten, was bei Dir nicht der Fall ist. Dazu funkt dir noch der Millisekunden-Systemtimer mit seinen Interrupts dazwischen, sie solltest du eventuell sperren. Dann solltest du berücksichtigen, dass die "Farbe" IR ein weiter Bereich ist (nicht so eng definiert wie "grün"). Es ist also wichtig, dass die Wellenlänge deiner IR-LED zum Empfänger passt. Du sendest offensichtlich mit 38 kHz. Bist du sicher, dass dein Empfänger diese Frequenz erwartet? Manche Geräte wollen 36kHz sehen, manche 40kHz.
> Die Trägerfrequenz vermisse ich auch, und das ... > sollte sicher PORTB ... heißen. Das ist schon richtig so. Die Trägerfrequenz erzeugt der Timer. Per Software schaltet aktiviert er lediglich den Ausgang zeitweise, so spart er sich ein Und-Gatter.
@Stefan Us (stefanus) >> Die Trägerfrequenz vermisse ich auch, und das ... >> sollte sicher PORTB ... heißen. >Das ist schon richtig so. Die Trägerfrequenz erzeugt der Timer. Per >Software schaltet aktiviert er lediglich den Ausgang zeitweise, so spart >er sich ein Und-Gatter. Mag sein, aber die Delays sind trotzdem Murks. https://www.arduino.cc/reference/en/language/functions/time/delaymicroseconds/ Ok, da steht nix explizit von konstanten Parametern. Hmm. Ein Blick in den Sourcecode von wiring.c verrät, daß die Funktion TATSÄCHLICH mit Variablen korrekt arbeitet! Siehe Anhang.
Angehängte Dateien:
-
IR_Signal.jpg
100 KB
Stefan U. schrieb: > Dann solltest du berücksichtigen, dass die "Farbe" IR ein weiter Bereich > ist (nicht so eng definiert wie "grün"). Es ist also wichtig, dass die > Wellenlänge deiner IR-LED zum Empfänger passt. Die Farbe Passt, hab die LED mit dem Arduino NANO verwendet und da funktioniert das schalten Stefan U. schrieb: > Du sendest offensichtlich mit 38 kHz. Bist du sicher, dass dein > Empfänger diese Frequenz erwartet? Manche Geräte wollen 36kHz sehen, > manche 40kHz. Zur Frequenz die sollte auch passen siehe Bild
> Ein Blick in den Sourcecode von wiring.c verrät, daß die > Funktion TATSÄCHLICH mit Variablen korrekt arbeitet! Das ist interessant. Ohne großartig nachzudenken war ich einfach davon ausgegangen, dass es sich einfach um ein Makro für _delay_us() handeln würde. Richtig doof finde ich, dass diese Arduino Implementierung ausschließlich mit 8 und 16MHz funktioniert. Arduino ist eine ziemlich Beschränkte Welt. Scheint für Leute optimiert zu sein, die nicht lesen wollen. Wobei: In diesem Fall ich derjenige, der nicht gelesen hat. Das ist mir echt unangenehm. Zurück zur Frage: Nachdem nun die Trägerfrequenz, die Wellenlänge und die Delays geklärt sind, sehe ich in deinem Programm keinen Fehler mehr. Bleibt also nur die Hardware oder noch Banaler: Deine Codierung ist falsch. Kontrolliere mal mit einer Videokamera (geht auch mit Smartphones), ob die IR-Led flackert, wenn du etwas sendest. Bist du denn sicher, dass deine Codierung richtig ist?
Andreas schrieb: > Die Farbe Passt, hab die LED mit dem Arduino NANO verwendet und da > funktioniert das schalten Halt den Schnabel und poste endlich mal ein Foto vom Aufbau und einen Schaltplan dazu! Ansonsten: Du hast die Abblock-Cs vergessen!
Angehängte Dateien:
-
Original_Signal.jpg
240 KB
Das Original Signal gemessen mit VS-1838B und Rigol Oszi
Die Signale von Fernbedienungen haben typischerweise sehr viel mehr Bits, als du auf deinem Oszilloskop sehen kannst. Besorge Dir einen (z.B. Saleae kompatiblen) Logic Analyzer.
Wenn das der Ausgang des ATTiny ist, dann hat S. Landolt doch Recht. S. Landolt schrieb: > Die Trägerfrequenz vermisse ich auch
Irgendwie scheint der Timer mit der Trägerfrequenz nicht zu funktionieren. Teste mal einfach 1ms ON/OFF mit deiner Modulation, dann müßte man den Träger gut sehen.
Mario M. schrieb: > Wenn das der Ausgang des ATTiny ist, dann hat S. Landolt doch Recht. Das ist nicht der ausgang am ATtiny sonder das siganl das ich mit der led ir receiver module, empfangen habe, es fehlen leider am Bild noch zwei ausschläge mit größerem Abstand am ende, sind in summe 8
@ Andreas (Gast) >Das ist nicht der ausgang am ATtiny sonder das siganl das ich mit der >led ir receiver module, empfangen habe, Wer soll das wissen, wenn du das nicht gescheit beschreibst?
Mario M. schrieb: > Wenn das der Ausgang des ATTiny ist, dann hat S. Landolt doch Recht. Genauso wäre das, keine Spur vom Träger zu sehen. Aber: Der Timer ist zumindest nicht so falsch initialisiert, dass garnix mehr herauskommen würde. Zumindest der tatsächlich generierte Träger müsste zu sehen sein. Also: dass kann eigentlich nicht am Pin 5 des Attiny gemessen sein. Allerdings ist sehr fraglich, ob die Trägerfrequenz stimmt:
1 | OCR0A=105; //CTC Compare value |
2 | |
3 | 36000 * 2 * 106 = 7632000 |
Das passt zu keiner der möglichen Clock-Optionen eines Tiny85 wirklich. Zu dem dadurch generierten systematischen Fehler kommt ja u.U. auch noch ungünstig die Abweichung des RC-Oszillators hinzu, was u.U. zu einem Gesamtfehler des Trägers von deutlich mehr als 10% führen könnte. Wenn es daran liegt: Sehr wahrscheinlich würde der TV trotzdem reagieren, wenn man nur nah genug rangeht.
Andreas schrieb: > if (digitalRead(1) == HIGH) { Ähm, Arduino hat doch diesen 1 kHz Interrupt? Der wird Dir das Timing verhageln. Man sieht auch auf dem Oszillogramm des Nachbaus, dass die Lücke in der Mitte später kommt, als beim Original. Vielleicht sollte man mal die for-Schleife mit cli/sei umschließen?
> Das passt zu keiner der möglichen Clock-Optionen eines Tiny85 wirklich. Doch, das passt. Wir haben oben anhand der delay Funktion egsehen, daß es nur 8MHz oder 16MHz sein können. Am Foto sehen wir, daß er den R/C Oszillator verwendet. Bleiben also nur die 8MHz übrig. 8Mhz 2 106 = 38kHz (ungefähr) > 36000 Wo hast du diese Zahl her? > Zu dem dadurch generierten systematischen Fehler kommt ja u.U. auch noch > ungünstig die Abweichung des RC-Oszillators hinzu, was u.U. zu einem > Gesamtfehler des Trägers von deutlich mehr als 10% führen könnte. Dann hätte seine zweite Messung mit dem Oszilloskop am Ausgang des Empfängers kein so schönes Bild ergeben. > Ähm, Arduino hat doch diesen 1 kHz Interrupt? > Der wird Dir das Timing verhageln. Das schrieb ich bereits. Ich hoffe doch sehr, dass der Andres inzwischen den Befehl zum Sperren der Interrupts hinzugefügt hat.... Andreas?
Beinhaltet das onoff[] bereits den Abstand zwischen zwei Befehlsfolgen, so etwa 10, vielleicht auch 20 ms?
Stefan U. schrieb: >> Das passt zu keiner der möglichen Clock-Optionen eines Tiny85 wirklich. > > Doch, das passt. Wir haben oben anhand der delay Funktion egsehen, daß > es nur 8MHz oder 16MHz sein können. Woran sieht man das anhand einer Delay-Funktion? Die ist doch typisch völlig blöd, kann nur um das "delayen", was ihr als Takt vorgegeben ist (Natürlich verrechnet mit dem angegeben Wert für das gewünschte Delay). > Am Foto sehen wir, daß er den R/C > Oszillator verwendet. Bleiben also nur die 8MHz übrig. Nö, das ist definitiv falsch für den Tiny85. Der könnte nämlich z.B. auch mit ~16MHz laufen. PLL-Takt 64MHz und Clock-Prescaler 4. Du kennst dich ganz offensichtlich in der Vielfalt der AVR8 nicht wirklich aus... Genauso interessant: Der Timer könnte dann wirklich mit 64MHz betrieben werden... >> 36000 > Wo hast du diese Zahl her? Das allerdings ist eine wirklich gute Frage. Tatsächlich: Fast reine Spekulation. Geboren allein daraus, dass die überwiegende Mehrzahl der FBs heute tatsächlich genau diese Trägerfrequenz benutzt und der TO sich (idiotischerweise) in keinster Weise zu der tatsächlich gewünschten/erforderlichen geäußert hat, weil er das nämlich mit seinem Arduino-Equipment (und seinen Fähigkeiten) nicht messen kann... Genau so wenig, wie er zum tatsächlichen Takt seines Babys aussagefähig ist. Insgesamt: ein absolut typischer Arduidiot. Und ein schönes Beispiel dafür, warum der Arduino-Weg der falsche Weg ist.
Was du da zeigst, ist kein IR-Code von UE-Fernbedienungen. Da wird kein TV drauf ansprechen! (Und das ist gut so!) Bei den IR-Codes gibt es 3 Varianten: Puls-Dauer variiert, Pausen-Dauer variert, oder Bit-Shift. Auf jeden Fall sieht man als IR-Signal (oder Ansteuerungssignal der LED) nur Bursts mit der Trägerfrequenz (mindestens 8, eher mehr Trägerfrequenz-Perioden) und Pausen mit ähnlicher Mindest-Dauer. Auf deinen Oszillogrammen: - ON-Zeiten > einige Trägerfrequenz-Perioden - Pausen kürzer, als 8..12 Trägerfrequenzperioden - Einzelpulse Ales Mist! Keine Ahnung, warum man dir alle Infos aus der Nase ziehen muss... Schon deine µC-Clock "darf" der Helfer sich als 8 MHz selbst zusammenreimen. (RC/Quarz???) Und der TV-Hersteller ist bestimmt allergrößtes Geheimnis...
@c-hater
> Woran sieht man das anhand einer Delay-Funktion?
Augen auf! Ich zitiere aus dem Quelltext der Arduino Delay Funktion:1 | // for the 20 MHz clock on rare Arduino boards |
2 | ... |
3 | // for the 16 MHz clock on most Arduino boards |
4 | ... |
5 | // for the 8 MHz internal clock on the ATmega168 |
6 | ... |
> Der könnte nämlich z.B. auch mit ~16MHz laufen. > PLL-Takt 64MHz und Clock-Prescaler 4. Siehst du hier irgendwo den dazu nötigen Code? Mit den Fuses kommt man nur auf 1MHz oder 8MHz. Nur bei 8MHz passt der Code. Außerdem liefert sein IR Empfänger im Fernseher ein Signal. Des weiteren ist die Spannungsversorgung 3,7V. Das wäre für 16MHz und 20MHz zu wenig. Also hat er 8MHz. Das ergibt sich aus logischem Denken, eine Fähigkeit, die Programmierer beherrschen sollten. Wie ordnest du dich da ein? Dass der TO deine Frage nach der Taktfrequenz nicht beantwortet, kann ich gut verstehen. Von Dir kann er keine sinnvolle Hilfe erwarten. Du meckerst nur an Punkten herum, die längst mehrfach geklärt sind! Und höre bitte auf, Arduino User zu beleidigen. Du hast selbst keine Ahnung von dem System!
Hallo, Ist schon etwas länger her, aber ich habs geschaft Hab eine NE555 als astabile kippstufe für die träger Frequenz benutzt und über einen Transistor mit dem ATTINY85 die Pulsdauer erzeugt, funktioniert
Fürs nächste Mal schau dir mal bitte IRSND an. Das ist eine Spinoff im IRMP Projekt und sendet alle Codes, die man sich vorstellen kann und das ohne zusätzliche Hardware: https://www.mikrocontroller.net/articles/IRMP
Danke für die info, hätte mir einiges an Zeit erspart aber wenn ich die schaltung mit einem ATTINY realisieren will braucht man einen NE555 für die träger Frequenz, weil der ATTINY das nicht schaft ?
Ich denke schon, dass ein Timer des ATtiny85 geeignet ist, die Trägerfrequenz zu erzeugen. Das macht der (nach Konfiguration) ganz alleine.
@Andreas (Gast) >Danke für die info, hätte mir einiges an Zeit erspart Wieso, weshalb, warum, wer nicht fragt bleibt dumm. >aber wenn ich die schaltung mit einem ATTINY realisieren will braucht >man einen NE555 für die träger Frequenz, weil der ATTINY das nicht >schaft ? Nö, das kann der AVR alleine und langweit sich nebenbei noch.
Ich habe es nicht geschft die 8.8us 17.6us pulsdauer mit dem ATTINY alleine zu erzeugen, bin für vorschläge offen
Falk B. schrieb: > Nö, das kann der AVR alleine und langweit sich nebenbei noch. Taktfrequenz bis 32 MHz Brauche aber carrier frequency: 37.9kHz
Lies im Datenblatt das Kapitel über die Timer. Probiere sie aus und stelle danach sinnvolle Fragen dazu.
Auf ein paar Zerquetschte in der Trägerfrequenz kommts bei den Eingangsfiltern der Reciever nicht an. Ich würde aber nach einigen Reinfällen den Code selbst lieber per Quarz takten oder zumindest den RC kalibrieren.
Jo, auf Skop-Bild sieht man ja auch, wie dein Nachbausignal im Vergleich zum Original total aus dem Frame läuft. Das muß der Empfänger nicht schlucken.
Stefanus F. schrieb: > Lies im Datenblatt das Kapitel über die Timer. Probiere sie aus und > stelle danach sinnvolle Fragen dazu. Hab leider nix gefunden, wie ist es möglich mit eine ATTINY85 8.8us 17.6us zu schalten ?
@Andreas (Gast) >Hab leider nix gefunden, wie ist es möglich mit eine ATTINY85 8.8us >17.6us zu schalten ? Dann lies mal das Kaptitel 13. 8 Bit Timer 0 with PWM. Der Modus 7 mit Fast PWM / OCRA ist dein Freund.
Andreas schrieb: > Ich habe es nicht geschft die 8.8us 17.6us pulsdauer mit dem ATTINY > alleine zu erzeugen, > > bin für vorschläge offen Schaus dir bei IRMP/IRSND an. Frank benutzt logischerweise auch den CTC Modus. Matthias S. schrieb: > ohne zusätzliche Hardware Stimmt nicht ganz. Man muss einen Basisvorwiderstand, einen NPN Treibertransistor und einen Vorwiderstand für die LED hinzufügen. batman schrieb: > Ich würde aber nach einigen > Reinfällen den Code selbst lieber per Quarz takten oder zumindest den RC > kalibrieren. Habe ich bei IRMP/IRSND noch nie machen müssen. Läuft in allen möglichen Apparaten hier, allerdings meistens bei Zimmertemperatur.
:
Bearbeitet durch User
Matthias S. schrieb: > Habe ich bei IRMP/IRSND noch nie machen müssen. Läuft in allen möglichen > Apparaten hier, allerdings meistens bei Zimmertemperatur. Fernbedienungen mit Batteriebetrieb?
batman schrieb: > Fernbedienungen mit Batteriebetrieb? Naja, Batteriebetrieb sieht anders aus: Beitrag "Re: Quick&dirty - schnelle Problemlösungen selbst gebaut" Aber das Dings läuft zuverlässig über 10m zum SAT Receiver (RC5). Hier haben wir es mit einem quarzlosen ATTiny2313 zu tun.
:
Bearbeitet durch User
Ich benutze einen Tiniy45 mit IRMP und zwei kleinen Knopfzellen. Funktioniert sauber die erste Variante hat knapp 1 Jahr gehalten. Mein Fehler war, dass ich die Brown-out detection an hatte. Das konnte ich durch eine größere Kapazität für das Pulsen der Diode vermeiden. Jetzt ist der Ruhestrom im Sleep Mode mit meinen Mitteln nicht mehr messbar. Mal sehen wie lange die Batterie jetzt hält. Gruß Frank
Hallo, okay es geht ohne zusätzliche hardware, aber hab immer noch probleme mit dem Code das es funktioniert
Andreas schrieb: > okay es geht ohne zusätzliche hardware, aber hab immer noch probleme mit > dem Code das es funktioniert Das ist jetzt nicht so aussagekräftig. Welcher Code? Was funktioniert nicht? Hast du jetzt IRSND am Laufen?
okay mein fehler
hier der code
#include <boarddefs.h>
#include <IRremote.h>
#include <IRremoteInt.h>
#include <ir_Lego_PF_BitStreamEncoder.h>
long unsigned int irSignal_Off = 0xE0E040BF;
long unsigned int irSignal_volUp = 0xE0E0E01F;
long unsigned int irSignal_volDown = 0xE0E0D02F;
IRsend irsend;
void setup() {
pinMode(3, OUTPUT);
}
void loop() {
delay(5000);
irsend.sendSAMSUNG(irSignal_Off, 32);// pin 3
delay(5000);
}
Andreas schrieb: > es geht einfach nicht, es macht nix Heisst das, aus dem Mikrocontroller kommt kein Signal heraus? Hast du die Fuses (insbesondere CLKDIV8) richtig eingestellt? Ich würde Dir empfehlen, einen Logic Analyzer zu besorgen und das Signal damit aufzuzeichnen. Dann zeigt du hier einen Screenshot von dem Ergebnis, sowie den aktuellen Schaltplan.
habs jetzt hinbeommen :-)
#include <avr/io.h>
#include <util/delay.h>
unsigned long time_reset = 0;
int
onoff[]={1,1,1,0,0,0,0,0,1,1,1,0,0,0,0,0,0,1,0,0,0,0,0,0,1,0,1,1,1,1,1,1
};
int
volUp[]={1,1,1,0,0,0,0,0,1,1,1,0,0,0,0,0,1,1,1,0,0,0,0,0,0,0,0,1,1,1,1,1
};
int
volDown[]={1,1,1,0,0,0,0,0,1,1,1,0,0,0,0,0,1,1,0,1,0,0,0,0,0,0,1,0,1,1,1
,1};
int laenge = 32;
int Onoff = 2;
int VolUp = 3;
int VolDown = 4;
void setup() {
pinMode(1, OUTPUT); // Traegerfrequenz
pinMode(0, OUTPUT); // LED
pinMode(Onoff, INPUT); // onoff
pinMode(VolUp, INPUT); // volUp
pinMode(VolDown, INPUT); // volDown
// erzeug an PIN 1 die Traegerfrequenz
TCNT1 = 0;
TCCR1 = 0;
GTCCR |= (1 << PSR1); //section 13.3.2 reset the prescaler
TCCR1 |= (1 << CTC1); // section 12.3.1 CTC mode
TCCR1 |= (1 << COM1A0); //togle pin PB1 table 12-4
TCCR1 |= (1 << CS10); //prescaler 1 table 12-5
OCR1C = 104;
OCR1A = 104;
}
Wo ist der Rest vom Quelltext? Wo ist der Schaltplan? Wenn du ständig zwischen völlig anderen Programmen/Libraries hin und her springst, werden deine Zwischenfragen vollkommen unverständlich.
Andreas schrieb: > Hallo hier das fertige Projekt Das kann so nicht funktionieren. Da ist so ziemlich alles sinnlos und falsch, was man falsch machen kann.
@Stefanus F. (stefanus) >> Hallo hier das fertige Projekt >Das kann so nicht funktionieren. Da ist so ziemlich alles sinnlos und >falsch, was man falsch machen kann. Das ist KUNST! (oder kann das weg?)
:
Bearbeitet durch User
Ich würde ja gerne erklären, was er falsch gemacht hat, nur sind da leider mehr Fehler als Bauteile drin. An den TO: Erkläre Du uns mal für jedes einzelne Bauteil, was Du Dir dabei gedacht hast. Sicher wirst du die meisten Fehler dann schon selbst erkennen. Bei dem Rest helfen wir dann gerne.
Stefanus F. schrieb: > da > leider mehr Fehler als Bauteile drin. Naja, man kann eben aus einem Transistor auch ein UND Gatter bauen und das kann auch funktionieren. Allerdings ist dann nur der Portpin als Stromlieferant da und deswegen kommt aus der LED nur mickriges Licht. Man muss dem TE einfach mal sagen, das man so einen Timerausgang ganz einfach abschalten kann, indem man ihn auf Input stellt und dabei den Timer nicht mal stoppen muss. Wenn man dann wieder ein Signal braucht, schaltet man den Pin wieder auf Ausgang. Das ist in der obigen Schaltung auch ganz einfach zu implementieren und man muss dann nur noch den Kollektor des Transistors auf Plus legen. Die komplizierte Mimik, um sich um den Powerdownmodus des MC herumzudrücken, habe ich auch schon in kommerziellen Produkten gesehen, die Jungs haben dann allerdings Dioden zum Entkoppeln der Tasten benutzt. Naja, wir haben alle mal angefangen und wenn der TE hier auch sämtliche Hinweise auf existierende Projekte geflissentlich übergangen hat - immerhin hat er geschafft, das die IR LED etwas ausstrahlt.
:
Bearbeitet durch User
Japp, gut ist, was funktioniert, das ist heute selten genug. Und mal keine Probleme mit Ruhestromverbrauch, Sleepmodus etc. Naja zumindest könnte man nächstesmal den UND-Transistor da unten weglassen und die LED mit Widerstand direkt zwischen die Portpins klemmen.
Angehängte Dateien:
-
Testaufbau.jpg
230 KB
Sicher man kann nimmer noch was verbessern, aber das war mein erstes Projekt in die Richtung, batman schrieb: > Japp, gut ist, was funktioniert, Stefanus F. schrieb: > Das kann so nicht funktionieren. Da ist so ziemlich alles sinnlos und > falsch, was man falsch machen kann. und es funktioniert doch ;)
> Stefanus F. schrieb: >> Das kann so nicht funktionieren. Da ist so ziemlich alles sinnlos und >> falsch, was man falsch machen kann. > > und es funktioniert doch ;) Ist schon schräg. Na dann, viel Spaß damit.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.