Hallo allerseits, da ich im Zuge diverser Projekte hier immer wieder per Suchfunktion geholfen wurde baue ich auch jetzt auf die Vorzüge der Schwarmintelligenz ;) Ich stehe vor folgender Aufgabenstellung, für die ich ein passendes Konzept entwickeln soll: Hintergrund: ------------ Für ein optisches Messsystem sollen 10 Spannungs-Kanäle (Lichtgitter mit 10 zeilen) A/D-gewandelt werden. Die Erfassung erfolgt jeweils über einen gepulsten IR-Laser (800nm) und eine BPW34 Photodiode mit Transimpedanzverstärker-Schaltung. Überschlagsmäßig hätte ich mir für die Sampling-Rate folgendes überlegt: Die Objekte, die erfasst werden sollen bewegen sich mit ca 330m/s (also in etwa Schallgeschw.) durch das Lichtgitter. Die Objekte (ca. 300Stück, 3mm im Durchmesser) sind stochastisch in einer Wolke verteilt, deren Abmessungen in etwa 3m lang und 1m im Durchmesser beträgt (wobei die 1m Durchmesser hier eher nebensächlich sind). Das bedeutet, eine Ebene, welche normal zur Bewegungsrichtung der Wolke liegt, hat die Wolke in ca 10ms passiert (3m/330m/s). Innerhalb dieses Zeitraums gilt es ausreichend Abtastungen hineinzulegen. Da es ca. 300 objekte sind habe ich überschlagsmäßig mal die doppelte Anzahl an Abtastungen veranschlagt, also 600. 600 Samples in 10ms entspricht einer Abtastfrequenz von 60kHz (pro Kanal), hier würde ich mich auf die sichere Seite begeben und hätte mal 100kHz gewählt Also sprich 10 Kanäle zu je 100kHz mit einer Auflösung von max. 10bit (evtl. sind auch 8bit ausreichend) weitere Anforderungen, die ich jetzt selbst mal gesetzt habe: ------------------------------------------------------------- Versorgungs- und Messspannungen 3,3 oder 5V, da ich dann nur mit einer Spannung am PCB hantieren muss, für die ich auch leicht Bauteile bekomme Laser-Puls (wird vermutlich über DI-Ausgang vom Controller und nachgeschaltenen Transistor oder Optokoppler realisiert): 25kHz Den Laser möchte ich aus dem Grund pulsen, um ein zusätzliches Unterscheidungsmerkmal im Signal der Photodiode zwischen statischen und dynamischen Anteilen zu haben Ob diese Pulsfrquenz mit der Objektgeschwindigkeit konform geht oder ich diese erhöhen muss oder vlt. generell Schwachsinn ist, wird sich dann im Feldversuch zeigen Distanzen vom Controller zu den Messstellen sind im Bereich zwischen 0,5m bis max. 1m, wobei ich vermutlich mit dem Signal nach dem Transimpedanzwandler diese Strecke überwunden hätte (also vor dem ADC) Meine Überlegungen und Fragen zum Design soweit: ------------------------------------------------- µC-Auswahl ist abhängig davon, ob es ein externer ADC-Baustein wird, oder ich den µC-internen verwende --> bei Verwendung des internen hätte ich an einen PIC32 gedacht, da ich damit schon gearbeitet habe (MX200-Serie) und dieser über einen internen ADC mit 1MSmpl/s verfügt (geht sich das mit 100Khz/Kanal aus oder muss ich da Abstriche machen?) Eher würde ich aber zu einem externen ADC mit vorgelagertem MUX und je Kanal einem S/H-Glied tendieren, um die Signale "abtastratenkonform" festzuhalten und nicht zuviel zeitlichen Versatz zwischen den Kanälen zu erhalten Dann würde es als Controller wahrscheinlich ein AVR8 tun (?) Bei Verwendung eines einzelnen ADC, in welcher Geschwindigkeits-Größenordnung müsste ich da schauen, um die Vorgaben von 100kHz/Kanal inkl. multiplexen einhalten zu können? Ist eine besondere Beschaltung des MUX erforderlich, um dessen Umschaltzeiten gering zu halten (Impedanzwandler, etc.), bzw worauf sollte man da generell schauen? Parallele oder serielle Anbindung des ADC an den Controller? Hätte auch über Multi-ADC Lösungen nachgedacht, da wäre aber dann wahrscheinlich der SPI-Bus das Nadelöhr um das generelle Timing einzuhalten. Gäbe es denn schnellere Anbindungen für mehrere ADCs als SPI? Die Messkette würde momentan grob so aussehen: Laser --> Objekt --> Photodiode --> TIA + Verstärker (Signalverstärkung auf 0..5V oder 3,3V) --> Antialiasing-Tiefpass (cut-off 50KHz) --> Impedanzwandler (nötig?) --> MUX --> ADC --> µC --> Speicherung Bei der Speicherung der Werte herrscht bei mir noch eine große Grauzone. Insgesamt beschränkt sich die Aufnahmedauer ja auf die angesprochenen 10ms, d.h. so lange müsste Speicher angefüllt werden, danach kann dieser per PC-Übertragung komplett geleert werden. Für die 10 Kanäle und 600 Werte je Kanal und Aufnahmedauer wären das bei 8bit Auflösung 6000 Byte, bzw. bei 10bit das doppelte, also 12kByte Ist das mit dem internen flüchtigen Speicher des µC noch machbar, oder ist hier ein externer Speicherbaustein erforderlich (FPGA, Flash, ..)? ich entschuldige mich gleich vorab für die sehr grobe Aufgabenstellung und meine Ahnungslosigkeit ;) Ich hoffe man kann mit den Informationen trotzdem was anfangen. Trotz recht umfangreicher Recherche existieren für mich schon jetzt so viele Fragezeichen, dass ich für jeden Anstoß/Hinweis/Kritik dankbar bin MFG und besten Dank im Voraus David
grobe Gedanken: IDee wirkt prinzipiell plausibel, deine Timing und Ausleseschwieirgkeiten kommen dann von selber, sobald du das aufbaust und angehst :) RAM Speicherbedarf, alleine für deine Messwerte wirkt gigantisch, ich weiss nicht wieviel dein ST32 hat, meine MSP430 haben so ca 4kB, ist natürlich variable je nach Baustein, ich nehm aber an bei deinen Messwerten wird das Hauptproblem liegen. Wenn du externe Speicher benutzt, musst du dran denken, dass dein Datenherumschieben immer auch Zeit kostet, evlt machst du noch einen Mittelwert oder sonstige MAthematik und ruck zuck hast du ganz große Probleme für deine Daten und Timings, Probleme bzgl. zu viele Daten zu wenig Speicher etc. Also such dir mal den größten ST aus denk mal am Anfang ob interner ADC reicht, weil das immer einfacher ist als einen externen auch noch über SPI usw anzusprechen.
Hallo, danke für diese erste Einschätzung etste schrieb: > RAM Speicherbedarf, alleine für deine Messwerte wirkt gigantisch, ich > weiss nicht wieviel dein ST32 hat, meine MSP430 haben so ca 4kB, ist > natürlich variable je nach Baustein, ich nehm aber an bei deinen > Messwerten wird das Hauptproblem liegen. Ja, das mit dem RAM-Speicher wird sicherlich eine knappe Angelegenheit der PIC32 MX2xx hat leider auch nur 8kB, müsste daher also wahrscheinlich zum MX4xx greifen (32kB) Vorteil dieser Variante wäre eben genau, dass der RAM-Speicher einfacher anzusprechen ist und wahrscheinlich schneller als der Flash oder externe Speichermodule Was mir auch entgegenkommt ist, dass der Gesamtaufwand an Speicherplatz immer mehr oder minder gleich ist, da ich die Aufnahme per externem Trigger, der das erste (oder eines der vordersten Objekte) detektiert, starte und sich die Wolke mit reproduzierbarer Geschwindigkeit bewegt. Die 3m Länge der Wolke waren schon eine worstcase Abschätzung, also dauert jede Aufnahme in etwa die besagten 10ms und belegt somit gesamt max. 12kB. Danach müssen sowieso die Daten ausgelesen und Speicher geleert werden, wobei hier die zeitliche Komponente egal ist. Ob der interne ADC reicht weiß ich eben nicht, weil ich die realen Geschwindigkeiten des internen MUX beim Kanalwechsel beim PIC32 nicht kenne. Der PIC32 an sich verfügt über einen ADC mit 1,1 MSmpl/s. Wenn ich das aufteile auf 10 Kanäle bin ich im optimalsten Fall bei etwa 100kHz, das ist wahrscheinlich aber eine Milchmädchenrechnung ;) Ich muss mir erst das Datenblatt genauer ansehen, aber ich bezweifle auch, dass die 16 AD-Kanäle des PIC32 jeweils ein S/H-Glied haben, somit hätte ich schon mal einen Versatz zwischen zwei aufeinanderfolgenden Kanälen von mindestens der Wandlungsdauer, was ich eig. vermeiden wollte
David H. schrieb: > Meine Überlegungen und Fragen zum Design soweit: > ------------------------------------------------- > > µC-Auswahl ist abhängig davon, ob es ein externer ADC-Baustein wird, > oder ich den µC-internen verwende --> bei Verwendung des internen hätte > ich an einen PIC32 gedacht, da ich damit schon gearbeitet habe > (MX200-Serie) > und dieser über einen internen ADC mit 1MSmpl/s verfügt (geht sich das > mit 100Khz/Kanal aus oder muss ich da Abstriche machen?) Umschaltzeiten zw. den Kanälen beachten > Eher würde ich aber zu einem externen ADC mit vorgelagertem MUX und je > Kanal einem S/H-Glied tendieren, um die Signale "abtastratenkonform" > festzuhalten und nicht zuviel zeitlichen Versatz zwischen den Kanälen zu > erhalten > Dann würde es als Controller wahrscheinlich ein AVR8 tun (?) AVR? Eher nicht. Bei 16 Bit pro ADC-Wert 10 100 kHz 16 Bit = 16 MBit/s und je nach externem ADC 10 100 kHz 2 Bytes = 2 M Interrupts/s (ein Interrupt pro übertragenem Byte) oder Polling... Selbst bei 32 MHz Takt wären es gerade mal 16 Taktzyklen zw. zwei Bytes, um irgendwas mit den Daten zu machen (wenn SPI2X noch das Maximum bei den AVR-SPI-Modulen ist, sind CPU-Takt/2 maximal möglich) und/oder weiterzusenden (die AVRs hätten, bis auf den XMega384 nicht genug SRAM zum Zwischenspeichern: 2 MByte/s * 10 ms = 20 kByte). Ohne Zwischenspeichern bleibt bei den AVRs nur USB oder z.B. Ethernet als externer Baustein, wenn der Controller nicht mehr mit den Protokollen hantieren muss. > Hätte auch über Multi-ADC Lösungen nachgedacht, da wäre aber dann > wahrscheinlich der SPI-Bus das Nadelöhr um das generelle Timing > einzuhalten. Gäbe es denn schnellere Anbindungen für mehrere ADCs als > SPI? Passender Controller bzw. reicht der PIC32MX200 dazu auch Oder ohne externen ADC statt des PIC32MX einen neueren PIC32MZ EF: Genügend SRAM (bis zu 512 kiB) intern, genügend schnelle Schnittstellen (USB HS, Ethernet) und einen 12-Bit ADC mit bis zu 18 MSps und 6 Sample&Hold-Einheiten (Edit: 6x ADC mit 6x S&H). Der wahrscheinlich auch noch genügend Rechenleistung übrig hat, um die nötigen Berechnungen mit den Daten anzustellen (Double Precision FPU...) und etwas Overkill ist. Div. STM32F4, STM32L4 oder vergleichbares von anderen Herstellern wären ebenso ausreichend
:
Bearbeitet durch User
Hallo, Ich würde einen STM32F4/3 verwenden. ( http://www.st.com/web/en/resource/technical/document/reference_manual/DM00031020.pdf ) Du hast 3 ADC Blöcke die wiederum mit je 1 Megasample/s laufen. Die ADC Wandlung kann mittels Timer getaktet werden -> daher kannst du einfach äquidistant Abtasten. Auflösung: 12 bit laut Datenblatt, genaueres weiß man nicht. Wenn nur ein ADC verwendet wird kommst du auf maximal 100KHz, es können aber bei Devices mit 2 oder mehr ADC Blöcken "parallel" geschaltet werden -> 300kHz Abtastrate. Der ADC kann auch über den DMA Controller ausgelesen werden, daher hat die CPU während des Messens nichts zu tun, kann währendessen die Daten zum PC übertragen. Oder die Daten direkt am Controller verrechnen und nur Komprimierte Daten zum PC senden (F4 beinhaltet FPU). RAM: 96 kB und mehr
So, danke erstmal für alle bisherigen Beiträge, haben mich echt weitergebracht :) @arc irgendwo hatte ich da bei meiner Speicherberechnung noch einen Denkfehler, wenn ich die von dir getroffenen Annahmen nehme, bin ich auch bei 20kB, weiß nicht, wie ich auf 12kB kam Arc N. schrieb: > Umschaltzeiten zw. den Kanälen beachten Hätte jetzt ziemlich intensiv gesucht, aber bin leider zumindest für den PIC32 nicht fündig geworden, werd mal schauen, was da bei externen so üblich ist. Entweder es fällt gegenüber der Sample+Conversion Zeit nicht mehr ins Gewicht, oder es hat sich wirklich noch niemand die Mühe gemacht das nachzumessen Aus dem PIC32-Datenblatt und für MX4xx und MX2xx identisch: tAD = 1/ADC-Clock aber mindestens 65ns (für single-ended Messungen) S/H-settling time: 1 tAD aber mind. 132ns Conversion time: 12 tAD Der ganze Wandlungsvorgang dauert also minimal 132ns + 12*65ns = 912ns also ca. 1us ergibt eine Abtastfrequenz für einen Kanal von 1MHz bzw. bei 10 (ohne MUX-Umschaltzeit) von 100kHz im Optimalfall In der Realität wird das wahrsch. anders aussehen Arc N. schrieb: > AVR? Eher nicht. Bei 16 Bit pro ADC-Wert 10 100 kHz 16 Bit = 16 > MBit/s und je nach externem ADC 10 100 kHz 2 Bytes = 2 M > Interrupts/s (ein Interrupt pro übertragenem Byte) oder Polling... > Selbst bei 32 MHz Takt wären es gerade mal 16 Taktzyklen zw. zwei Bytes, > um irgendwas mit den Daten zu machen (wenn SPI2X noch das Maximum bei > den AVR-SPI-Modulen ist, sind CPU-Takt/2 maximal möglich) und/oder > weiterzusenden (die AVRs hätten, bis auf den XMega384 nicht genug SRAM > zum Zwischenspeichern: 2 MByte/s * 10 ms = 20 kByte). > Ohne Zwischenspeichern bleibt bei den AVRs nur USB oder z.B. Ethernet > als externer Baustein, wenn der Controller nicht mehr mit den > Protokollen hantieren muss. Ja der AVR kommt da dann nicht infrage Arc N. schrieb: > Oder ohne externen ADC statt des PIC32MX einen neueren PIC32MZ EF:.. Danke für den Tipp, würde von den Specs her jetz sehr interessant klingen, aber ich habe dann doch einige Berichte dazu gefunden (auch neuere von 2015), die eher von der Verwendung abraten, da das Ding noch nicht richtig ausgereift zu sein scheint. ich lasse mich natürlich gerne eines besseren belehren @Luke Danke ebenfalls für den Tipp, leider habe ich mit der ARM-Architektur und -Programmierung bis dato gar keine Erfahrung und es soll ja doch einiges an Umgewöhnung sein, was man so liest Irgendwann werde ich mich sowieso mit der Materie auseinandersetzen müssen, aber dieses Projekt verträgt leider den zusätzlichen finanziellen und zeitlichen Aufwand nicht ;) Ansonsten sind die technischen Spezifikationen des von dir genannten µCs sehr überzeugend Luke schrieb: > Der ADC kann auch über den DMA Controller ausgelesen werden,.. Diesen Ansatz werde ich in jedem Fall weiterverfolgen, wird auch beim PIC32 ADC erwähnt Derzeit tendiere ich, v.a. aufgrund des größeren RAM-Speichers (32k) zum PIC32MX4xx (unabhängig davon ob es jetzt ein externer ADC wird oder nicht). Falls jemand ein Gegenargument hat, bin ich ganz Ohr :)
Schnellere A/D-Wandler wirst Du beim TMS320F2809 finden. 2 12 bit A/D-Wandler mit je 12.5 MSPS Abtastrate die von 2 8-fach Muxen bedient werden. Die 36 kByte internes RAM sollten nach Deiner Rechnung ja auch reichen. Dokumentation in der TI-Appnote SPRU716.
David H. schrieb: > den PIC32 Schau doch mal bei den PIC24E.. bzw dsPIC33E... Bis zu 70 Mips, ADC bis 1,1MHz und RAM bis 48k MfG Klaus
>Irgendwann werde ich mich sowieso mit der Materie auseinandersetzen >müssen, aber dieses Projekt verträgt leider den zusätzlichen >finanziellen und zeitlichen Aufwand nicht ;) Der finanzielle Aufwand ist sehr sehr gering, ein STM Nucleo Board bekommst du um 10-15 € (inkl. Debug Interface über USB ) Als IDE verwende ich eclipse mit arm gcc, open ocd und gdb, das ist alles open source/freeware (hab die Lizenzen nicht genau im Kopf) Falls du auf Windows unterwegs bist, kann ich dir eine genaue Anleitung zum Einrichten von Eclipse und allem notwendigen Zubehör schicken. Der zeitliche Aufwand is meiner Meinung nach auch überschaubar da es von ST eine wirklich gute und leicht verständliche Lib gibt und eine große Community. Weiters bringt dir eclipse inkl dem oben genannten Zubehör auch blinky Beispielprojekte für Cortex M0 bis M4 von ST mit. lg Luke
David H. schrieb: > So, danke erstmal für alle bisherigen Beiträge, haben mich echt > weitergebracht :) > > @arc > irgendwo hatte ich da bei meiner Speicherberechnung noch einen > Denkfehler, wenn ich die von dir getroffenen Annahmen nehme, bin ich > auch bei 20kB, weiß nicht, wie ich auf 12kB kam > > Arc N. schrieb: >> Umschaltzeiten zw. den Kanälen beachten > > Hätte jetzt ziemlich intensiv gesucht, aber bin leider zumindest für den > PIC32 nicht fündig geworden, werd mal schauen, was da bei externen so > üblich ist. Entweder es fällt gegenüber der Sample+Conversion Zeit nicht > mehr ins Gewicht, oder es hat sich wirklich noch niemand die Mühe > gemacht das nachzumessen > > Aus dem PIC32-Datenblatt und für MX4xx und MX2xx identisch: > tAD = 1/ADC-Clock aber mindestens 65ns (für single-ended Messungen) > S/H-settling time: 1 tAD aber mind. 132ns > Conversion time: 12 tAD Allgemeine Berechnungen für Multiplexer sind z.B. hier http://www.analog.com/media/en/technical-documentation/application-notes/AN-1024.pdf zu finden Bei externen ADCs ist meistens spezifiziert wie hoch die Abtastrate mit und ohne Kanalumschaltung (scan rate oder ähnlich) ist. Bei den PICs (24/32MX) hier im Einsatz hatte der interne ADC meist nicht viel zu tun,.. kann daher auch nicht mehr als das Datenblatt sagen. > Arc N. schrieb: >> Oder ohne externen ADC statt des PIC32MX einen neueren PIC32MZ EF:.. > > Danke für den Tipp, würde von den Specs her jetz sehr interessant > klingen, aber ich habe dann doch einige Berichte dazu gefunden (auch > neuere von 2015), die eher von der Verwendung abraten, da das Ding noch > nicht richtig ausgereift zu sein scheint. ich lasse mich natürlich gerne > eines besseren belehren 32MZ EC oder 32MZ EF (mit FPU)? Bei letzteren ist das Errata nicht so lang http://ww1.microchip.com/downloads/en/DeviceDoc/80000663A.pdf 10 Punkte EF vs 62 für die älteren EC... > > Derzeit tendiere ich, v.a. aufgrund des größeren RAM-Speichers (32k) zum > PIC32MX4xx (unabhängig davon ob es jetzt ein externer ADC wird oder > nicht). Falls jemand ein Gegenargument hat, bin ich ganz Ohr :) Wenn der MX4xx reicht, warum dann jetzt auf was anderes wechseln? Luke schrieb: > Falls du auf Windows unterwegs bist, kann ich dir eine genaue Anleitung > zum Einrichten von Eclipse und allem notwendigen Zubehör schicken. http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1533/PF261797 bzw. direkter Link http://www.openstm32.org/HomePage Basiert ebenso auf Eclipse. Wird von Ac6 für ST gepflegt. > Der zeitliche Aufwand is meiner Meinung nach auch überschaubar da es von > ST eine wirklich gute und leicht verständliche Lib gibt und eine große > Community. > Weiters bringt dir eclipse inkl dem oben genannten Zubehör auch blinky > Beispielprojekte für Cortex M0 bis M4 von ST mit. Zum Teil ist es Geschmackssache welche Libraries/Frameworks man bevorzugt. Wirklich gut gefällt mir keins der Frameworks. Allerdings ist STM32CubeMX etwas besser als das Pendant Harmony Configurator, auch wenn es nicht mehrere Konfigurationen kennt. Kleiner Hinweis am Rande: Renesas ist jetzt auch bei den kleineren ARMs auf den Cortex-M-Zug aufgesprungen (Cortex A7 bis A15 hatten sie schon in der RZ-Reihe)... und nicht nur halb http://www.renesas.eu/products/embedded_systems_platform/synergy/microcontrollers/index.jsp inkl. eines Komplettpakets an Software, Tools etc. http://www.renesas.eu/products/embedded_systems_platform/synergy/software/index.jsp
Irgendwie habe ich ein Problem damit, deinen Aufbau zu verstehen. Ein Lichtgitter mit einer Höhe (z) zwischen Sender S1 und Empfänger E1 von > 1m (Durchmesser der Wolke) und einem Abstand des keilförmig reflektierter Strahles zwischen S1 und R12 usw. von kleiner 3mm (Durchmesser der Teilchen).
1 | S1 >------------- R11 |
2 | R12 -------------< R11 |
3 | R12 >------------- R13 |
4 | R14 -------------< R13 |
5 | ... ... |
6 | E1 -------------< R1n |
Davon dann 10 hintereinander in Bewegungsrichtung der Teilchen (x) oder auch zum Teil in der Breite (y) angeordnet und ggfls. gegeneinander etwas versetzt (mehrere Teilchen mit selber x-Koordinate). Wenn dem so ist - warum möchtest du das Signal A/D wandeln? Da müßte doch eine simple logische Verknüpfung des Empfängersignals mit dem Sendeimpuls oder ein Filter 25 kHz (schnell genug eingeschwungen hmmm) und ein Komparator ausreichen? Oder sehe ich das komplett falsch und du strebst irgendeine Auswertung des an einem Teilchen reflektierten Laserstrahls an? Mir, und gegebenfalls auch Anderen, würde eine Skizze deiner Anordnung dabei helfen.
Hallo, nochmals danke für die rege Beteiligung und bitte entschuldigt meine späte Rückmeldung @Luke Luke schrieb: > Der finanzielle Aufwand ist sehr sehr gering, ein STM Nucleo Board > bekommst du um 10-15 € .. hatte mit finanziellem Aufwand jetzt eher meine Arbeitszeit für die Einarbeitung in die ARM-Thematik gemeint :) Da das ganze ja kein Privatprojekt sondern ein auf Werkvertrag basierendes für meine FH ist, muss ich natürlich auch meinen zeitlichen Aufwand verrechnen Die Controller-Serie klingt wirklich sehr interessant und scheint auch breiten Zuspruch zu finden. Sobald ich zeitlich wieder etwas flexibler bin, wird der STM32 definitiv von mir näher in Augenschein genommen. Der PIC32 wäre halt einfach die quick&dirty Alternative, da ich damit wie gesagt schon gearbeitet habe, bzw. punkto Programmierung auf einen Kollegen zurückgreifen könnte, der damit auch schon einige gemacht hat (halt leider noch nicht ADC-mäßig) Sollte der PIC32 sich nicht als geeignet herausstellen (hauptsächlich vermutlich aufgrund des internen ADC) werde ich mich mit dem STM32 und ARM beschäftigen. Auf dein Angebot bezüglich Hilfe bei Entwicklungsumgebung einrichten würde ich dann sehr gerne zurückkommen
@Arc Arc N. schrieb: > Allgemeine Berechnungen für Multiplexer sind z.B. hier > http://www.analog.com/media/en/technical-documentation/application-notes/AN-1024.pdf > zu finden Danke für den Link, bin darüber bei meinen Recherchen schon gestolpert. Hab mir das Dokument jetzt ein wenig genauer angeschaut, ich denke ich werde damit mal eine Berechnung für die mögliche Sampling-Rate inkl. der MUX-Verzögerungszeiten durchführen und das Ergebnis dann hier posten Arc N. schrieb: > 32MZ EC oder 32MZ EF (mit FPU)? Bei letzteren ist das Errata nicht so > lang Stimmt, ist mir entgangen, dass es hier bereits 2 Varianten gibt, die meisten Beiträge bezogen sich auf den EC Hab die Errata vom EF kurz überflogen und gesehen, dass hauptsächlich Probleme adressiert werden, die mich für meine Anwendung jetzt nicht unmittelbar betreffen (außer UART evtl.), I2C werde ich nicht brauchen und sleep Modes sind in diesem Fall auch kein Thema Hast du schon mit dem Controller zu tun gehabt bzw. ist dir bekannt wie groß die Umstellung von der MX-Serie ist und ob es ausreichend Support/Community Erfahrungen gibt? Arc N. schrieb: > Wenn der MX4xx reicht, warum dann jetzt auf was anderes wechseln? Naja, den PIC32 würde ich halt hauptsächlich deswegen bevorzugen, weil ich selbst bereits Erfahrungen mit der Serie (allerdings nur MX2xx) habe. Die Überlegungen und Grob-Berechnungen mit denen ich die Wahl begründe, habe ich alle in diesem Thread dargelegt. Ich bin mir aber nicht sicher, ob ich nicht wesentliche Dinge übersehen habe, die die Verwendung des 32er ausschließen oder infrage stellen, deshalb eigentlich meine Frage :)
operdig schrieb: > Irgendwie habe ich ein Problem damit, deinen Aufbau zu verstehen. > > Ein Lichtgitter mit einer Höhe (z) zwischen Sender S1 und Empfänger E1 > von > 1m (Durchmesser der Wolke) und einem Abstand des keilförmig > reflektierter Strahles zwischen S1 und R12 usw. von kleiner 3mm > (Durchmesser der Teilchen). > S1 >------------- R11 > R12 -------------< R11 > R12 >------------- R13 > R14 -------------< R13 > ... ... > E1 -------------< R1n Deine Vermutungen sind bis hier alle zutreffend ;) Da ich kein Optik-Spezialist bin, basiert auch das auf einem Konzept, die genaue Detailkonstruktion wird dann ein Optik-Designingeneur übernehmen, daher kann es auch hier durchaus sein, dass ich wesentliche Fehler eingebaut habe und bin durchaus für Kritik/Anregungen offen. Ich wollte aber die beiden Baustellen (Optisches Konzept, Signalverarbeitung) nicht beide in diesem Thread thematisieren, damit es nicht ausartet. Darum sorry, wenn wesentliche Informationen gefehlt haben, um die Signalverarbeitungskette auslegen zu können. Ich habe einen Sender (in dem Fall das Lasermodul oder eine starke LED mit gebündeltem Strahl), mit Mehrfach-Reflexion des Strahls in möglichst spitzem Winkel (den erforderlichen Winkel dafür bin ich gerade am ermitteln). Über diese "Steigung" gelangt der Strahl auf die vertikal unter dem Sender positionierte Empfangsdiode (selbe x-, selbe y- aber andere z-Koordinate, um bei deiner Nomenklatur zu bleiben ;)) Das wäre dann eine Zeile mit einem zugehörigen Wert von der Photodiode Deren Zeilen hätte ich 10 veranschlagt, die vertikal im Rahmen übereinander (z-Richtung) angeordnet sind und jeweils eine vertikale Distanz von 10cm abdecken sollen (also in Summe 10x10cm = 1m) operdig schrieb: > Davon dann 10 hintereinander in Bewegungsrichtung der Teilchen (x) oder > auch zum Teil in der Breite (y) angeordnet und ggfls. gegeneinander > etwas versetzt (mehrere Teilchen mit selber x-Koordinate). > > Wenn dem so ist - warum möchtest du das Signal A/D wandeln? Da müßte > doch eine simple logische Verknüpfung des Empfängersignals mit dem > Sendeimpuls oder ein Filter 25 kHz (schnell genug eingeschwungen hmmm) > und ein Komparator ausreichen? > > Oder sehe ich das komplett falsch und du strebst irgendeine Auswertung > des an einem Teilchen reflektierten Laserstrahls an? Nein, du siehst das schon richtig, es geht rein um eine Detektion Teilchen da - ja/nein? Und du hast auch recht, dass es sich grundsätzlich um ein rein binäres Problem handelt, mir kam der Gedanke mit dem Komparator auch, wäre auch wesentlich einfacher zu handeln Mein Problem damit ist nur folgendes (und hauptsächlich darin begründet, dass ich mit dem optischen Verhalten eines solchen Systems keine Erfahrung habe): - ergeben mehrere Teilchen, die zufällig gleichzeitig den Strahl einer Zeile durchdringen das selbe Ergebnis (bezogen auf den Output der Photodiode) wie ein einzelnes Teilchen? - wenn nein, wie sollte der Schwellwert des Komparators eingestellt werden um trotzdem eine eindeutige Aussage ja/nein treffen zu können? - oder was eher wahrscheinlich ist, verhält sich das ganze sowieso komplett unterschiedlich bei jedem "Teilchendurchflug" und können nur aus dem dynamischen Verhalten des Signals (Änderung ja/nein und wenn ja wie stark) begrenzte Rückschlüsse gezogen werden? Ist leider alles ziemlich empirisch, aber ist ja auch ein Forschungsprojekt und noch dazu mit bescheidenem Budget ausgestattet Zeichnung bin ich gerade am erstellen, da der Optik-Designer diese auch benötigt, werde sie sobald ich damit fertig bin hochladen
:
Bearbeitet durch User
Klaus schrieb: > Schau doch mal bei den PIC24E.. bzw dsPIC33E... Bis zu 70 Mips, ADC bis > 1,1MHz und RAM bis 48k Danke ebenfalls für den Tipp, Klaus. Die 24er sind mir auch schon ins Auge gesprungen, allerdings die F-Serie. Wäre eine günstigere/abgespeckte Alternative zum 32er Bin jetzt allerdings nicht allzu vertraut mit 16bitern und DSP-µCs
David H. schrieb: > operdig schrieb: >> Irgendwie habe ich ein Problem damit, deinen Aufbau zu verstehen. >> > Deine Vermutungen sind bis hier alle zutreffend ;) Fein. Ich würde dann mit den TIA-Ausgängen und dem Pulssignal auf einen handelsüblichen Logikanalysaor gehen. 3mm/2 (Kugel vs Strahldurchmesser) / 330 m/s ~ 4,5µs/Einzelkugel btw. Bist du dir bei der Lasermodulation mit 25kHz (L=20µs) wirklich sicher? Datenmengen sind damit kein Thema mehr und durch die hohe Zeitauflösung - auf jeden Fall besser als 10 bit - können mehrere Teilchen mit geringer x-Differenz über die Statistik (Pulsverlängerung) erkannt werden. Durch "ver-unden" der Eingänge mit dem Pulssignal (bei der Auswertung) können Umgebungseinflüsse reduziert werden. Wenn die Drift der Detektoren zu hoch ist, kann man auch über eine externe Anpassung der Triggerschwellen per S/H(während Puls=L) + Tiefpass (~10Hz) nachdenken. Das wird aber aufwändiger. Bleibt noch das Problem mit mehreren Teilchen identischer x-Koordinate. Wenn die Optik nicht allzu teuer ist, für die z-Koordinatentrennung versuchen: * Den Strahlengang parallel * mit einem Abstand > Teilchen * in x-Richtung hintereinander * um Abstand/2 in z-richtung versetzt anordnen Das habe ich aber jetzt nicht vollständig durchgedacht, kann also Spuren von Unsinn enthalten. Es wäre aber meiner Meinung nach einen Versuch wert, da der LA im Vergleich zur A/D-Variante nicht viel kostet und du daher jederzeit wieder umschwenken kannst.
@operdig Danke für deine ausführlichen Überlegungen und den alternativen Ansatz operdig schrieb: > 3mm/2 (Kugel vs Strahldurchmesser) / 330 m/s ~ 4,5µs/Einzelkugel > btw. Bist du dir bei der Lasermodulation mit 25kHz (L=20µs) wirklich > sicher? Wenn man es so betrachtet, und davon ausgeht, jedes Kügelchen zu detektieren, hast du Recht, nein dann sind die 25kHz sicher nicht ausreichend. Da ich vom Standpunkt der A/D-Variante betrachtet davon ausgegangen bin, dass unter Berücksichtigung des zur Verfügung stehenden Budgets die 100kHz Abtastrate für 10 Kanäle ohnehin schon das Höchste der Gefühle sind, und ich doch zumindest jeweils 2 Abtastungen für beide Laserzustände erreichen wollte kamen die 25kHz zustande. Wenn ich jetzt vom Standpunkt einer rein digitalen Erfassung ausgehe, würde ich auch, wie ohnehin von dir vorgeschlagen, die Abtastrate wesentlich erhöhen, um eine Detektion jedes einzelnen Kügelchens gewährleisten zu können, also sprich mind. 440kHz. Um beim oben genannten Verhältnis aus Puls-/Abtastfrequenz zu bleiben und mit der Pulsdauer auch noch Nyquist gerecht zu werden, wohl eher Samplingrate 1,6Mhz und Pulsfrequenz 440kHz Logikanalysator bewegt sich so bei ca. 300€ z.B. der http://www.deditec.de/de/logikanalysatoren/prod/usb-logi-500.html?id=Wg&gclid=CjwKEAiAoIK1BRCRiMqphvnlwlwSJAAOebPMPE96ltnKTvfQRVCcYFiVOe_rBJ378DaUp3h-VdePDxoCKInw_wcB wobei der mit 500Msamples/s wahrscheinlich Overkill ist ;) Ansonsten wäre das von dir Vorgeschlagene eine echte Alternative Man müsste dann halt ausprobieren, wie weit der Strahl zu kollimieren ist, um in jedem Fall eine saubere Unterbrechung durch ein so kleines Objekt zu erreichen bzw. welche vorgesetzte Optik zu verwenden wäre, um diese Strahlbündelung auch bei mehrfacher Reflexion bis zur PD (bzw. bis zum letzten Strahlgang direkt vor der PD) aufrecht zu erhalten. Da z.B. der oben verlinkte LA aber ohnehin 36 Kanäle besitzt könnt ich die Anzahl der Lichtquellen erhöhen und mehrere PDs verwenden, damit müsste der jeweils einzelne Strahl weniger oft umgelenkt werden Ist aber natürlich auch ein zusätzlicher Kostenaufwand Datenhandling und Speicherung beim LA sind mir jetzt noch nicht ganz klar, das muss ich mir noch im Detail ansehen operdig schrieb: > Durch "ver-unden" der Eingänge mit dem Pulssignal (bei der Auswertung) > können Umgebungseinflüsse reduziert werden. Bin mir jetzt nicht sicher, ob wir dasselbe meinen, aber das wäre der von mir angedachte Hintergrund für die Verwendung eines gepulsten Signales gewesen, um statische Umgebungseinflüsse wie Umgebungslicht, Störquellen etc ausschließen zu können. Wobei ich hier dazu sagen muss, dass erste Versuche mit der BPW34 und dem Laserstrahl gezeigt haben, dass die Größenordnungen der Amplituden von Laser- und Umgebungslicht sowieso in komplett anderen Größenordnungen liegen, selbst bei diffusem Strahl operdig schrieb: > Wenn die Drift der Detektoren zu hoch ist, kann man auch über eine > externe Anpassung der Triggerschwellen per S/H(während Puls=L) + > Tiefpass (~10Hz) nachdenken. Das wird aber aufwändiger. Auch hier weiß ich nicht, ob ich dich richtig verstanden habe. Mit Drift meinst du die zeitliche Veränderung des PD-TIA-Ausgangssignals bei gleichbleibendem Eingangssignal? Darüber hatte ich mir ehrlich gesagt noch gar keine Gedanken gemacht. Mit unterschiedlichem Signalverhalten für jeden "Teilchendurchflug" (wenn es sich darauf bezog) hatte ich eigentlich gemeint, dass die Schwelle für den Komparator bei jeder einzelnen PD angepasst werden muss, da wahrscheinlich die Voraussetzungen wie Umgebung, Kennlinie, etc. bei jeder PD etwas unterschiedlich sind. Wie meinst du das mit der externen Anpassung der Triggerschwelle per S/H-Glied und Tiefpass bzw. was/wer wird damit beschaltet? Den Ansatz zur Detektion von Teilchen mit gleicher x- aber unterschiedlicher z-Koordinate habe ich jetzt leider gar nicht verstanden. Strahlengang parallel anzuordnen hieße in dem Fall eine zweifache Umlenkung über Spiegel um letztendlich irgendwann zur PD zu gelangen (ich nehme mal an so war es gemeint?), ansonsten müsste ich ja zusätzliche Lichtquellen einsetzen Also quasi ein zweites identisches Gitter, welches in Bewegungsrichtung und zusätzlich vertikal leicht versetzt angeordnet wird?
:
Bearbeitet durch User
Hallo David, ich muß das jetzt erst einmal ein wenig sacken lassen und werde übers Wochenende versuchen, technisch etwas fundiertere Antworten auf deine Fragen bzw. Pro- und Kontraargumente zur LA-Lösung zu finden.
Ja, kein Problem, vlt. handeln wir die Thematik auch per PN ab, da sie ja in Bezug auf das ursprüngliche Thread-Thema ein wenig off-topic ist und ich die anderen, die sich an der Diskussion beteiligt haben, nicht damit langweilen bzw. quälen will, sich das durchlesen zu müssen. Nichtsdestotrotz ist es für mich eine sehr attraktive Alternative :)
David H. schrieb: > Um beim oben > genannten Verhältnis aus Puls-/Abtastfrequenz zu bleiben und mit der > Pulsdauer auch noch Nyquist gerecht zu werden, wohl eher Samplingrate > 1,6Mhz und Pulsfrequenz 440kHz Ich würde es pessimistischer angehen: die 4,5µs/Kugel und 10 Abtastungen wären 2,2Mhz. Für 20ms Aufzeichnung wären dann 44kSample Speicher erforderlich. > Logikanalysator bewegt sich so bei ca. 300€ z.B. der > wobei der mit 500Msamples/s wahrscheinlich Overkill ist ;) Was man vom Speicher (4kSample) nicht behaupten kann. Der USB-LOGI-250 mit 512k kostet gleich doppelt so viel. > Man müsste dann halt ausprobieren, wie weit der Strahl zu kollimieren > ist, um in jedem Fall eine saubere Unterbrechung durch ein so kleines > Objekt zu erreichen bzw. welche vorgesetzte Optik zu verwenden wäre, um > diese Strahlbündelung auch bei mehrfacher Reflexion bis zur PD (bzw. bis > zum letzten Strahlgang direkt vor der PD) aufrecht zu erhalten. Ich habs mit einer Simulation mit einem IR-Empfänger http://www.linear.com/product/LT1328 zur Signalaufbereitung versucht. Der schafft zwar Pulse mit 0.5µ bei Intensitätsverhältnissen 100/90 bis 100/10 µA. Allerdings sagt das nicht wirklich viel aus. Vor allem, da das Erstellen eines Testsignales (z.B. Schnittfläche Kreis-Quadrat als Funktion von x,z) ziemlich aufwendig ist und trotzdem andere Eigenschaften der Strecke nicht berücksichtigt werden. Mich hätte dabei vor allem interessiert, ob die Regelung des Diodenstroms auch mit solchen Signalen (für die er nicht unbedingt gebaut ist) funktioniert. Eventuell könntest du mit einem reinen TIA und einem normalen DSO einen Versuch aufzeichnen. Das hift dann bei der Beurteilung ob LA oder ADC, aber auch beim weiteren Schaltungsentwurf (Filtersimulation...) > dass erste Versuche mit der BPW34 und dem Laserstrahl gezeigt haben, > dass die Größenordnungen der Amplituden von Laser- und Umgebungslicht > sowieso in komplett anderen Größenordnungen liegen, selbst bei diffusem > Strahl Das betrifft vor allem die Hysterese und damit den Triggerpegel H->L wenn eine Kugel den Strahl (teilweise) unterbricht. > Mit Drift > meinst du die zeitliche Veränderung des PD-TIA-Ausgangssignals bei > gleichbleibendem Eingangssignal? Ja - in diesem Zustand ist die Schaltung die meiste Zeit und daran sollte Triggerpegel L->H ausgerichtet werden. Wäre es nicht sinnvoll, während der eigentlichen Messung den Laser nicht zu Pulsen, sondern nur in den Versuchspausen? Puls z.B. 100%/98% Laserleistung (100/0 für ADC) um damit die Triggerschwellen manuell abzugleichen. Innerhalb der Durchlaufzeit sollte sich da nicht wirklich viel verändern. Das würde ein Signal vom Auslöser der Kugeln erforden. > Den Ansatz zur Detektion von Teilchen mit gleicher x- aber > unterschiedlicher z-Koordinate habe ich jetzt leider gar nicht > verstanden. Ich anscheinend auch nicht :( Eigentlich wollte ich über den Versatz (Laufzeit) zwischen Z- Y-Detektoren die Position bestimmen. Kann aber nicht funktionieren, da auf jeden Fall 100 Positionen aufzulösen sind. Bei 1mm Z bedingt das 10mm Y - also ~1,1m insgesamt - hmm. Sehr viel kann ich derzeit also nicht beitragen, so dass auch PN nicht unbedingt nötig erscheint. Auch das Wiederauffinden des PW könnte noch ein Problem sein...
Hallo, sorry für die verspätete Rückmeldung und danke, dass du dir am Wochenende den Kopf mit meinem Problem "zermarterst" operdig schrieb: > David H. schrieb: >> Um beim oben >> genannten Verhältnis aus Puls-/Abtastfrequenz zu bleiben und mit der >> Pulsdauer auch noch Nyquist gerecht zu werden, wohl eher Samplingrate >> 1,6Mhz und Pulsfrequenz 440kHz > Ich würde es pessimistischer angehen: die 4,5µs/Kugel und 10 Abtastungen > wären 2,2Mhz. Für 20ms Aufzeichnung wären dann 44kSample Speicher > erforderlich. Ok, meine Rechnung war eine andere, hätte die Hälfte der 4,5µs für die Pulsdauer herangezogen und dann innerhalb dieser Dauer 4 Abtastungen (je 2 bei H und L) untergebracht, aber ob 1,6 oder 2,2 wird wahrscheinlich in dieser Größenordnung nicht mehr so ins Gewicht fallen :) operdig schrieb: >> Logikanalysator bewegt sich so bei ca. 300€ z.B. der >> wobei der mit 500Msamples/s wahrscheinlich Overkill ist ;) > Was man vom Speicher (4kSample) nicht behaupten kann. Der USB-LOGI-250 > mit 512k kostet gleich doppelt so viel. Stimmt, wäre die wesentlich geeignetere Alternative, leider doppelt so teuer, evtl. besteht die Möglichkeit die 22 MBit/s gleich über den USB 2.0 zu streamen, wobei gelesen hätte ich davon in den Beschreibungen nichts Ja, simulationstechnisch, v.a. was LTspice etc angeht bin ich eher schwach, da bevorzuge ich den Weg über trial and error und probier das direkt am vereinfachten Versuchsaufbau Der LT1328 wäre in dem Fall von dir vermutlich als Komparator- (und TIA-) Ersatz gedacht? Ich hab mir das Teil jetzt noch nicht im Detail angesehen, aber verfügen solche Bauteile über eine einstellbare Triggerschwelle? Sind ja doch wahrscheinlich meistens für standardisierten IR-Lösungen (Fernbedienung, etc) vorgesehen Ja, DSO wäre schon eine Option, allerdings stehen bei unseren nur 2 Kanäle zur Verfügung, wäre für einen Grobtest aber vermutlich ausreichend operdig schrieb: >> dass erste Versuche mit der BPW34 und dem Laserstrahl gezeigt haben, >> dass die Größenordnungen der Amplituden von Laser- und Umgebungslicht >> sowieso in komplett anderen Größenordnungen liegen, selbst bei diffusem >> Strahl > Das betrifft vor allem die Hysterese und damit den Triggerpegel H->L > wenn eine Kugel den Strahl (teilweise) unterbricht. > >> Mit Drift >> meinst du die zeitliche Veränderung des PD-TIA-Ausgangssignals bei >> gleichbleibendem Eingangssignal? > Ja - in diesem Zustand ist die Schaltung die meiste Zeit und daran > sollte Triggerpegel L->H ausgerichtet werden. Drift müsste man wahrscheinlich über den Messzeitraum mal beobachten, aber aufgrund des Amplitudenverhältnisses Laser/Umgebungslicht würde ich vermuten, dass er vernachlässigbar ist. Eine andere Geschichte ist da wohl eher die Teilunterbrechung des Strahls durch eine (oder mehrere) Kugel(n), die müsste man sich definitiv im Versuch ansehen, um die Triggerschwelle richtig zu setzen. operdig schrieb: > Wäre es nicht sinnvoll, während der eigentlichen Messung den Laser nicht > zu Pulsen, sondern nur in den Versuchspausen? > Puls z.B. 100%/98% Laserleistung (100/0 für ADC) um damit die > Triggerschwellen manuell abzugleichen. Innerhalb der Durchlaufzeit > sollte sich da nicht wirklich viel verändern. Das würde ein Signal vom > Auslöser der Kugeln erforden. Ich muss ganz ehrlich gestehen, je länger ich darüber nachdenke, wird mir immer weniger klar, wie ich mir die Einbindung des Pulssignals eigentlich bei der analogen Variante vorgestellt habe und v.a. wie der Puls im Vergleich zur Abtastung eigentlich sein sollte Du meinst in den Messpausen eine länger Dauer bei gepulstem Laser als Kalibriersignal aufzuzeichnen und dieses dann über Mittelwert/Standardabw als Triggerschwelle zu benutzen, klingt auch plausibel. Damit könnte man dann auch eine gezielte/regelmäßige Quasi-Unterbrechung des Strahls simulieren Die Unterscheidungen von Kugeln mit unterschiedlicher z-Koordinate innerhalb einer Zeile würde ich vorerst vernachlässigen. Für den ersten groben Prototypen ist eine Unterscheidung der aufgetretenen Unterbrechungen anhand der angedachten 10 (oder max. 36 bei LA-Variante) Zeilen ausreichend. Außerdem weiß ich ja noch gar nicht welche zusätzlichen Informationen ich aus dem Signal herausklauben kann, die mir vielleicht erst bewusst werden, wenn ich das zeitlliche oder FFT-transformierte Signal vor mir habe Danke für deinen Zeitaufwand. Bringen Bewertungspunkte der Beiträge für den jeweiligen User in diesem Forum effektiv etwas? Kenn leider nur das System, wie es auf CAD.de üblich ist, da haben diese Punkte Vorteile für die Benutzer. Auf die eine oder andere Weise würde ich mich gern für die hilfreiche Unterstützung erkenntlich zeigen
Der Untergrund beim Licht wird sich eher langsam ändern. Wenn überhaupt könnte man überlegen den Untergrund beim Licht durch eine Nullmessung vor der eigentlichen Messung zu kompensieren. Sonst kann man da vermutlich noch einiges optisch gewinnen, indem man dafür sorgt dass die Fotodioden nicht noch Licht aus allen möglichen Richtungen aufnehmen. Das ginge z.B. durch blenden oder ggf. auch mit Fotodioden mit Linse (z.B. BPW24 - die wäre auch schneller). Vorversuche mit DSO und erst einmal nur 2 oder 4 Kanäle wäre sicher sinnvoll. Dann weiss man, ob man mit dem Digitalen Signal auskommt, oder ggf. doch ADCs haben sollte. Digital könnte man ggf. ein paar mehr Kanäle nutzen. Bei nur Komparatoren muss man aber die Optik sehr stabil haben oder ggf. die Schwellen für alle Kanäle irgendwie einzeln Abgleichen können.
Hallo Lurchi Lurchi schrieb: > Sonst kann man da > vermutlich noch einiges optisch gewinnen, indem man dafür sorgt dass die > Fotodioden nicht noch Licht aus allen möglichen Richtungen aufnehmen Ja, guter Ansatz, wird bei uns aber sowieso notwendig sein, die PDs, den Laser, und die Umlenkspiegel einzuhausen, da die Schrotkörner sonst mit der optischen Vorrichtung eine ziemliche Schweinerei veranstalten würden ;) Danke für den Tipp mit der BPW24, werde ich mir demnächst in Hinblick auf Unterschiede ansehen Ansonsten stimme ich deinen Anmerkungen voll und ganz zu
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.