Hallo allerseits, Ich würde mit meiner vorhandenen Schaltung (Screenshots im Anhang - ich hoffe der relevante Teil ist ausreichend nachvollziehbar) gerne eine "beat-Erkennung" bastelt. Ich will also den Takt von Musik erkennen - wichtig ist, dass irgendwie sinnvoll der Zeitpunkt der einzelnen Takte erkannt werden kann - eine tiefergehende Analyse ist nicht von nöten. Am Ende soll eine Art Lichtorgel dabei rauskommen. Ich hatte überlegt das ganze über den ADC des Atmegas (1284 - die Beschriftung im Schaltplan einfach ignorieren) durchzuführen und zwei Kanäle (hoffentlich korrekt) schon einmal nach außen gelegt. Zusätzlich stehen extern 12V, 5V und GND zur Verfügung. Intern sind die Anschlüsse dann auf einen Spannungsteiler geführt (der ist im Augenblick für 12V Maximalpegel ausgelegt, ich könnte ihn aber ohne Probleme auch naträglich zumindest brücken). Hat jemand eine Idee/einen Tipp wie ich nun am besten diese Erkennung realisiere? über ein Mikrofon? Direkt die Audiosignale abgreifen wird wohl keine gute Idee sein, oder doch? Mir fehlt ein wenig das Fachwissen um die richtige Herangehensweise zu erkennen.
Angehängte Dateien:
-
Prozessor.PNG
8,2 KB -
ADC_Anschluss.PNG
3,7 KB
Mal ganz grob würde ich mir das Audiosignal mit einem Operationsverstärker auf den richtigen Pegel bringen und dann mittels Schmitt-Trigger in ein digital verwertbares Signal umwandeln. Dann kannst Du die Flanke entsprechend bestimmen, bei der Mikrocontroller ein Signal registrieren soll und sparst dir die Umwandlung mit dem ADC.
Frederik N. schrieb: > Ich hatte überlegt das ganze über den ADC des Atmegas (1284 Also mit einem ATmega1284 wirst du da nicht weit kommen. Du solltest da besser auf einen 4 Kern-Intel zurückgreifen....
Frederik N. schrieb: > Ich will also den Takt von Musik erkennen > die Anschlüsse dann auf einen Spannungsteiler geführt (der ist im Augenblick für >12V Maximalpegel ausgelegt Wie hoch ist denn der erwartete Pegel genau? Du solltest das Ganze so auslegen, dass der ADC des ATMEGAs immer um 75% herum ausgesteuert ist. Zu wenig Signal stört die spätere Auswertung, zu viel Signal übersteuert den ADC, was ebenfalls die Auswertung stört. Wenn Dein Eingangssignal nicht einem Norm-Line-Pegel von etwa 700mV/600 Ohm oder einem anderen festen Pegel entspricht, der sich nicht großartig ändert, musst Du Dir Gedanken um eine AGC-Schaltung machen (automatische Aussteuerung). Ein einigermassen stabiler RMS-Pegel ist Grundvoraussetzung für eine gute "Beat"-erkennung. Frederik N. schrieb: > Ich hatte überlegt das ganze über den ADC des Atmegas (1284 - die > Beschriftung im Schaltplan einfach ignorieren) durchzuführen Ja, kann man machen. Die komplette Auswertung inklusive Gleichrichtung und Filterung kann in Software passieren. Dazu programmiert man zwei Tiefpässe mit unterschiedlicher Grenzfrequenz um etwa 300Hz herum. Wird das Ergebnis aus beiden Tiefpässen subtrahiert und tritt dann eine Abweichung größer einem eingestellten Grenzwert auf, ist der "Beat" erkannt. Das Stereosignal auszuwerten ist übrigens nicht nötig. Im Gegenteil, Du solltest beide Kanäle mischen und dann nur einen ADC nutzen.
... schrieb: > Also mit einem ATmega1284 wirst du da nicht weit kommen. Du solltest da > besser auf einen 4 Kern-Intel zurückgreifen.... Warum das denn? @Matthias P.: Da fehlt dann aber immernoch so etwas wie ein Tiefpass etc, oder? So würden ja alle Ausschläge registriert... @ Knut Ballhause: Wo ich mein Signal am besten herbekomme ist halt auch eine meiner Fragen. Das hört sich so an, als ob es sinnvoll wäre das Stereo-Signal an den Cinch-Buchsen des Verstärkers direkt abzugreifen? Das hat dann einen maximalpegel von 700mV sagst du? Dann könnte man ja fast direkt die interne 1,1V Reverenzspannung des ADC nehmen. Zur Auswertung in Software: Zwar verstehe ich in Grundzügen wie du das meinst, aber spontan wüsste ich nicht genau wie ich es umsetzen sollte (braucht man für solche Filterfunktionen nicht auch relativ gleiche Aufrufabstände der Funktion etc.? Der Atmega werkelt nebenbei noch an ein paar anderen Sachen (IR-Fernbedienung in zyklischem Interrupt), so dass nicht 100% der Rechenleistung zur Verfügung stehen - meinst du das ist ein Problem?) Ist eine Realisierung in Hardware schwieriger?
>> Also mit einem ATmega1284 wirst du da nicht weit kommen. Du solltest da >> besser auf einen 4 Kern-Intel zurückgreifen.... > Warum das denn? Weil er schlichtweg zu langsam ist. Aber es kommt auch auf deine Anforderungen an, also liegt die Antwort irgendwo dazwischen. Ich habe es selbst mal probiert mit einem ATmega64. Dabei habe ich einfach ein Line-Signal mit einer kleinen Schaltung an den ADC gebracht und den ATmega das Signal bei 4kHz samplen lassen. Nach Nyquist bleiben mir also die Frequenzen bis zu 2kHz. Der Algorithmus hat dann versucht die Energie des Signals über die Zeit zu ermitteln und daraus die Beats abzuleiten. Am Ende leuchtete eine kleine LED im Takt des Signales und für mich war es zufriedenstellend. Die Erkennungsrate lag dabei bei geschätzen 70%. Die restlichen 30% waren entweder falsch erkannte oder nicht erkannte Beats. Was der Kollege meint ist, dass wenn du eine professionelle Lösung mit größerer Erfolgsquote suchst, du mehr Prozessor-Power brauchst. Dann kannst du auch gleich das komplette Spektrum des Audio-Signales erfassen, FFT und andere Filter darauf laufen lassen und landest bei Erkennungsraten wie man sie von Produkten wie NI Traktor oder Abelton Live kennt, also nah an 100%.
Alex schrieb: > Ich habe es selbst mal probiert mit einem ATmega64. Dabei habe ich > einfach ein Line-Signal mit einer kleinen Schaltung an den ADC gebracht > und den ATmega das Signal bei 4kHz samplen lassen. Nach Nyquist bleiben > mir also die Frequenzen bis zu 2kHz. Du hast aber auch hoffentlich einen analogen Filter davorgesetzt. Nyquist sagt nämlich nicht, dass dir dann nur alle Frequenzen bis 2kHz übrig bleiben. Alles darüber ist immer noch in den Daten enthalten und versaut dir durch Spiegelfrequenzen und Aliasing die Messung. Was dir Nyquist sagt ist: Sampelst du mit 4kHz dann musst du bei 2kHz filtern, weil du ansonsten deine Messung in die Tonne treten kannst. > Was der Kollege meint ist, dass wenn du eine professionelle > Lösung mit größerer Erfolgsquote suchst, du mehr Prozessor-Power > brauchst. Was der Intel-Mehrkern Kollege eigentlich ironisch meinte: Um sich vom Ikea die Fussmatte 'Welcomerig' nach Hause zu fahren, kommst du unter einem 40-Tonner LKW mit Ferrari Motor nicht weg. Er meint das genau Gegenteil dessen, was du verstanden hast. Wenn andere eine komplette 32 Kanal FFT auf einem Mega8 rechnen, dann wird er ja wohl noch da Beats rauskriegen. Und er braucht dazu auch keine 128KB Flash, 4KB EEprom oder 16KB SRAM.
Ich würde das Problem mit ein paar analogen Bandpässen für charakteristische Frequenzen lösen. Der µC kann dann die Intensität direkt ablesen und auswerten. Warum zum Teufel sollte man das komplette signal sampeln?!
Ja, ich habe da einen einfachen Tiefpass hingesetzt. Wobei es ohne auch schon halbwegs gut funktionierte. Aber dann habe ich auch Schluss gemacht. Würde ich das Thema heute wieder aufziehen, wäre ich jetzt auf der Suche nach einem gescheiten DSP und ließe den ATmega links liegen. ;-)
Meine erste Idee war auch ein analoger Tiefpass (bis z.B. 500Hz -> Erfahrungen wären hier gut!?) und dann an den ADC (z.B. vom Line-Signal, wenn das einfach so nutzbar ist!?). Nur wie die Schaltung zu dimensionieren ist etc. da fehlt mir das Fachwissen... und dann kommt natürlich noch der Algorithmus...
Frederik N. schrieb: > Nur wie die Schaltung zu > dimensionieren ist etc. da fehlt mir das Fachwissen.. ein kleiner Tip. Wir Kinder der 70-er Jahre wünschten uns in unserer Jugend nichts sehnlicher als eine Billgstorfer Lichtorgel um die an die HiFi-Kompaktanlage (Schneider - 15 Watt) oder den Kasettenrecorder im Partykeller anzuschliessen. Irgendwie musste man ja die holde Weiblichkeit beeindrucken. ´ Und eine der oft zweckentfremdeten Schreibtischlampen mit einem Farbfilter in Form eines Schulheftumschlags davor, MUSSTE im Basstakt blinken. Was anderes wär überhaupt nicht in Frage gekommen. Der Rest war wurscht. Aber bei 'smoke on the water' ging es nicht anders. Zum Headbangen gehörte auch eine entsprechende 'Light-Show' zu den langen Haaren dazu. Alles was nicht im Takt blinkte war per eigener Definition unbrauchbar. Lichtorgeln gab es wie Sand am Meer (und die ELO und Elektor waren voll mit mal mehr, mal weniger aufwändigen Schaltungen. Alle 3 Monate eine neue). Und ... es gibt sie heute noch. Und ... man kann danach googeln.
Hehe. Ja nun ich habe durchaus nach Lichtorgeln gegoogelt. Nur sind das dann meist diskrete Schaltungen mit Transistoren. Ich würde nun aber meinen vorhandenen Aufbau gerne erweitern. Das ganze ist bereits ein RGB-LED-Controller der verschiedene Sachen wie Lauflicht etc schonmal kann. Ich würde nun gerne den vorhandenen Aufbau um diese "Lichtorgel"-Funktionalität erweitern. Dass man das Signal vom Line-In des Verstärkers abgreifen könnte (wg. relativ konstantem Maximalpegel?) habe ich hier rausgelesen. Nur ich bin mit nicht sicher wie man den ADC beschalten sollte damit das ankommt was ich mir wünsche (z.B. erstmal ein analoger Tiefpass/Bandpass!?) Bevor ich nun also ewig probiere und viel zum Teufel jage dachte ich, jemand mit mehr Fachwissen könnte mich dahingehend beraten/ hat vllt sogar schonmal eine Lösung dimensioniert. btw: An dieser Stelle schonmal danke für die vielen hilfreichen Kommentare!
Frederik N. schrieb: > Nur ich bin > mit nicht sicher wie man den ADC beschalten sollte damit das ankommt was > ich mir wünsche (z.B. erstmal ein analoger Tiefpass/Bandpass!?) Nimm einen Single-Supply-OPV und baue ein aktives Filter. Ein guter Ansatz wäre sowas hier: http://de.wikipedia.org/wiki/Linkwitz-Riley-Filter http://www.linkwitzlab.com/filters.htm Die Grenzfrequenz stellst Du auf 2kHz ein. Am Eingang solltest Du eine Schutzschaltung mit Dioden und Vorwiderstand vorsehen. Der Ausgang kann nur Spannungen innerhalb der Betriebsspannungsgrenzen annehmen. Somit ist der Controller sicher. Den ADC lässt Du dann mit 4kHz samplen. Das passiert komplett in Hardware. Der ADC schmeißt einen Interrupt, wenn er fertig ist. In der Zeit bis zum nächsten Sample verarbeitest Du Dein Signal. Da ist dann auch genug Platz für die anderen Aufgaben, die der Controller noch so hat. Dann liest Du noch das hier: http://de.wikipedia.org/wiki/Digitales_Filter
Eigentlich steht das Wichtigste mal wieder auf Wikipedia (Tiefpass). Was den Algorithmus angeht, google bitte mal nach "beat detection algorithm". Der erste Treffer sollte dich schon recht weit bringen. Nebenbei: Was ich oben mit "Power" meinte, bezog sich auf die Taktfrequenz des ATmega64, welchen ich zu dem Zeitpunkt nun mal übrig hatte. Natürlich kann man aus den unteren 2kHz viel an Information herausholen (besonders bei elektronischer Musik, House, Electro, Hardstyle, etc.), aber nicht bei allen Genres. Da ist man besser damit beraten, wenn man die gesamten 44kHz betrachtet und dann wird es bei einem ATmega eng.
Alex schrieb: > Da ist man besser damit > beraten, wenn man die gesamten 44kHz betrachtet und dann wird es bei > einem ATmega eng. Nicht für Beat detection. Sieh Dir mal in einem FFT die Balken über 4kHz an, wenn der Drummer auf die Base tritt, was da oben noch sieht. Da sind die HiHats und die Stimmen und diffuse Oberwellen der Instrumente. Die sind unwesentlich für die Takterkennung, wenn nicht sogar störend.
Angehängte Dateien:
-
AVR-Lichtorgel.png
76 KB
Ich habe einen älteren Beitrag hier gefunden: Beitrag "[C] AVR-Lichtorgel per FFT MEGA8 32 644" Demnach könnte ich ja z.B. den analog-Eingang nach diesem Beispiel (Bild im Anhang, unten links) beschalten und dann im uC eine FFT durchführen. Nun ist das ja mit 6 Kanälen ausgeführt.. da könnte man sich ja aber den richtigen rauspicken. Ist es kritisch diese Eingangsbeschaltung nicht in direkter physikalischer Nähe zum uC zu realisieren? Und kann ich das Stereo-Line-Signal eines Verstärkers einfach zusammenschalten um es zu mischen? (wohl nicht, was? :) )
Wenn Du eine wirklich gute Beat- / Musikerkennung willst, dann versuche einen Schaltplan eines Pulsar Modulator III oder IV zu bekommen. Das waren in den 90ern die besten Lichtsteuerungen was dies betrifft. IMHO waren die Schaltpläne damals beigelegt. Da einzige was in den Dingern prozessorgesteuert war, waren die Abfolge und verschiedenen "Lichtbilder" wie Flip-flop, 1of4, Ladder usw.
Frederik N. schrieb: > Und kann ich das Stereo-Line-Signal eines Verstärkers einfach > zusammenschalten um es zu mischen? Nicht nötig, die Kanäle werden mit R25 und R26 ausreichend voneinander entkoppelt. Du schließt "links" an Pin1 v. JP4 an, "rechts" dementsprechend an Pin3. Oder meinetwegen "rechts" an Pin1 und "links" an Pin3. mfg
Ah von dir war die Schaltung auch, nicht? Dann an dieser Stelle schonmal danke. Verfälscht diese Schaltung in irgend einer Weise denn das Audio-Signal? (Ist ein Line-Signal denn überhaupt Masse-Bezogen? Ist das nicht ein Differenzsignal?) Und um noch einmal auf meine vorherige Frage zurückzukommen: Ist ein räumlicher Abstand der Eingangsbeschaltung zum eigentlichen ADC-Eingang kritisch?
Frederik N. schrieb: > Ist ein Line-Signal denn überhaupt Masse-Bezogen? Ist es immer. Aus einer Cinch-Buchse ist es nur unsymmetrisch, aus einer XLR-Buchse symmetrisch. Frederik N. schrieb: > Ist ein > räumlicher Abstand der Eingangsbeschaltung zum eigentlichen ADC-Eingang > kritisch? Wenn die Platine eine gute Masseführung / Massefläche hat, dann eher nicht.
Ich meinte damit auch eher die Eingangsbeschaltung auf eine externe Platine und dann per Ader an den Eingang... Die eigentliche Platine steht ja nun (leider) schon... zum Thema Symmetrie: Wenn ich dann eine Cinch-Ader an den In-Pin Hänge ung die andere auf GND, dann habe ich doch aber einen Kurzschluss nach Masse!?
Als das Spielzeug entstand, steckte der AVR in einem Pollin-Evalboard und die restliche Mimik befand sich auf Lochraster, mit ca. 15cm Flachbandkabel verbunden. Wenn die zwei Baugruppen nicht arg weit auseinander kommen, ausprobieren!
Ja das ist doch wunderbar - das kriege ich wohl mit weniger Entfernung noch hin. super. Ich kann also einfach die Eingangsschaltung benutzen, ja? Dann noch eins: Hast du zwei Cinch-Kanäle genommen und dann eine Ader jeweils auf die beiden in-pins der Schaltung gelegt und die anderen zusammen mit GND verschaltet? Hat das das Musiksignal sonst nicht beeinflusst?
Frederik N. schrieb: > Hast du zwei Cinch-Kanäle genommen und dann eine Ader jeweils auf > die beiden in-pins der Schaltung gelegt und die anderen zusammen mit GND > verschaltet? Was? So ein NF-Kabel besteht aus einem isolierten Innenleiter, drum herum ein Kupfergeflecht. Selten sind 2 Innenleiter im selben Schirm zusammengefaßt, aber auch möglich. Der (die) Innenleiter kommt an Pin1 bzw. 3, das Schirmgeflecht an Masse. Frederik N. schrieb: > Hat das das Musiksignal sonst nicht beeinflusst? Den Endstüfchen der Soundkarte war es ziemlich egal. mfg
Da habe ich mich wohl etwas missverständlich ausgedrückt. :) Bei einem Cinchkabel ist der Schirm meines Wissens die Rückleitung!? Ich war mir nicht sicher, ob die Ader im Kabel immer Pegel und der Schirm Masse führt - ich dachte es wäre ein Differenzsignal (beide Leiter führen Pegel) - deswegen wäre es ja fatal beide Schirme auf GND zu legen. Aber da es ja scheinbar schon einige so gemacht habe, funktioniert es wohl :) Du hast als OP dann einfach einen solchen hier genommen: !? http://www.conrad.de/ce/de/product/174440/Linear-IC-ST-Microelectronics-LM-358-N-Gehaeuseart-DIL-8-Ausfuehrung-2fach-OP/SHOP_AREA_17311&promotionareaSearchDetail=005
oder diesen: http://www.reichelt.de/ICs-LM-10-LM-999/LM-358-DIP/3/index.html?;ACTION=3;LA=446;ARTICLE=10483;GROUPID=5464;artnr=LM+358+DIP;SID=11UL45wX8AAAIAAAK-vR4ff95518636a4e06864c81fc9c7e0304c Arbeitet der denn ordnungsgemäß bei 5V Versorgungsspannung? (Datenblatt sagt ja 32V - da spricht wohl mein mangelndes Wissen. ^^ ) Sry für den Doppelpost - konnte den alten nicht mehr bearbeiten...
Also ich habe die Schaltung nun einmal gemäß deinem Beispiel aufgebaut (Lötlackl). Ich kann den ADC nur auf minimal 125kHz laufen lassen (16MHz Takt, 128 Vorteiler), das sollte doch aber kein Problem sein!? Ist es normal, dass die Schaltung bei "Ruhe" High-Pegel rausgibt? Ich kriege in Ruhe immer einen Wert von 42956 angezeigt -> Die FFT liefert riesige Werte auf den unteren beiden Bändern. Habe ich einen Bock in der Schaltung? Drehen am Poti ändert eigentlich gar nichts :)
Frederik N. schrieb: > Ich kann den ADC nur auf minimal 125kHz laufen lassen (16MHz Takt, 128 > Vorteiler), das sollte doch aber kein Problem sein!? Klar kannst Du den ADC mit 250kHz laufen lassen, Prescaler=64(Bit's ADPS2..1 gesetzt)! Ansonsten paßt gar nix mehr zusammen. Wozu tut man sowas ohne Not? Frederik N. schrieb: > Also ich habe die Schaltung nun einmal gemäß deinem Beispiel aufgebaut > (Lötlackl). Offensichtlich nicht!
Richtig. War ein Fehler drinnen in der Verdrahtung. Mir war so als hätte ich was von 4kHz gelesen, aber da habe ich mich wohl geirrt. Hat die Schaltung denn einen konstanten Offset in Ruhe? Was regelt denn das Poti?
1 | void capture_wave(int16_t *buffer, uint16_t n) { |
2 | ADMUX= (0<<REFS1) | (1<<REFS0) | (1<<ADLAR) | (0<<MUX4) | (0<<MUX3) | (1<<MUX2) | (1<<MUX1) | (1<<MUX0); // channel |
3 | |
4 | do { |
5 | ADCSRA = _BV(ADEN)|_BV(ADSC)|_BV(ADATE)|_BV(ADIF)|_BV(ADPS2)|_BV(ADPS1); |
6 | while(bit_is_clear(ADCSRA, ADIF)); |
7 | *buffer++ = ADC + INT16_MIN; |
8 | } while(--n); |
9 | |
10 | ADCSRA = 0; |
11 | }
|
Ist die Routine für meinen Atmega1284 denn so korrekt? Zusätzlich wird noch ganz zu beginn des Programmes konfiguriert:
1 | DIDR0=(0<<ADC7D) | (1<<ADC6D) | (1<<ADC5D) | (1<<ADC4D) | (1<<ADC3D) | (1<<ADC2D) | (1<<ADC1D) | (1<<ADC0D); |
2 | ADMUX= (0<<REFS1) | (1<<REFS0) | (1<<ADLAR) | (0<<MUX4) | (0<<MUX3) | (1<<MUX2) | (1<<MUX1) | (1<<MUX0); |
3 | ADCSRA=(0<<ADEN) | (0<<ADSC) | (0<<ADATE) | (0<<ADIF) | (0<<ADIE) | (1<<ADPS2) | (1<<ADPS1) | (0<<ADPS0); |
4 | ADCSRB=(0<<ADTS2) | (0<<ADTS1) | (0<<ADTS0) |
Der Atmega1284 ist dem Mega644 recht ähnlich und für den passen die Sourcen. Wenn Du noch folgende Zeilen anpasst, sollte es auch für den Mega1284 hinhauen. fftest.c
1 | #if defined (__AVR_ATmega8__)
|
2 | ADCSRA = _BV(ADEN)|_BV(ADSC)|_BV(ADFR)|_BV(ADIF)|_BV(ADPS2)|_BV(ADPS1); |
3 | #elif defined (__AVR_ATmega32__) || defined (__AVR_ATmega644__) || defined (__AVR_ATmega1284__) || defined (__AVR_ATmega1284P__)
|
4 | ADCSRA = _BV(ADEN)|_BV(ADSC)|_BV(ADATE)|_BV(ADIF)|_BV(ADPS2)|_BV(ADPS1); |
5 | #endif
|
mydefs.h
1 | #if defined (__AVR_ATmega644__) || defined (__AVR_ATmega168__) || defined (__AVR_ATmega1284__) || defined (__AVR_ATmega1284P__)
|
2 | #define TIMSK TIMSK1
|
3 | #endif
|
Ich finde die Schreibweise im Übrigen furchtbar.
1 | DIDR0=(0<<ADC7D) | (1<<ADC6D) | (1<<ADC5D) | (1<<ADC4D) | (1<<ADC3D) | (1<<ADC2D) | (1<<ADC1D) | (1<<ADC0D); |
Wenn schon alle Bits, ob gesetzt oder nicht, angezeigt werden müssen, dann ist es so übersichtlicher.
1 | ADMUX = (0<<REFS1) \ |
2 | | (1<<REFS0) \ |
3 | | (1<<ADLAR) \ |
4 | | (0<<MUX4) \ |
5 | | (0<<MUX3) \ |
6 | | (1<<MUX2) \ |
7 | | (1<<MUX1) \ // sicher? ist im Original nicht gesetzt |
8 | | (1<<MUX0); |
Frederik N. schrieb: > Zusätzlich wird noch ganz zu beginn des Programmes konfiguriert: Wird doch alles schon in der Funktion capture_wave() erledigt. mfg
Nun über die Schreibweise kann man sich jetzt streiten - ich persönlich finde nebeneinander besser weil Widescreen und so der Byte-Aufbau deutlich ist, aber das ist sicherlich geschmackssache. Die andere MUX-Belegung kommt daher, dass ich einen andern PIN (ADU7) verwende. Es kommt in der Tat auch etwas brauchbares rum bei der FFT - Mitten und Höhen bekomme ich gut raus. Nur das ganz untere Band (FFT-Band 0) müllt etwas - hier liegen auch in Ruhe Werte vor. Mag das an dem leichten Ruheoffset liegen? (In Ruhe liefert mir die Schaltung um die 2,6 V...) Was sollte das Poti denn bewirken? Auf jeden Fall noch einmal vielen Dank für diese super Lösung!
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.