Hallo liebes Forum, ich möchte ein Projekt mit Hilfe eines SBC oder SBM realisieren. Das Projekt besitzt die folgenden Randbedingungen: - Mikrofon als Sensor - Minimale Abtastrate 1,5 MS (Hertz) - Wünschenswerte Abtastrate 10 MS - Minimale Auflösung des AD-Wandlers 12 Bit - Wünschenswerte Auflösung des AD-Wandlers 18 Bit - Messzeit 3ms Die Recheneinheit soll primär als "Datensklave" arbeiten, also die Sensordaten digitalisieren und speichern. Eine Verarbeitung/Auswertung der Sensordaten ist auf der Recheneinheit nicht erforderlich, hierfür kann ein externer PC zum Einsatz kommen. Das Projekt möchte ich mit Hilfe eines Entwicklungsboards/Einplatinenboard sofern möglich aufbauen. Vor allem die wünschenswerten Randbedingungen stellen eine Herausforderung dar. Wobei diese wohl nicht mit einem SBM realisierbar sind. Zumindest hab ich kein Entwicklungsboard gefunden, dass das leisten kann. Ich habe mich bislang über die Unterschiede Mikroprozessor, Mikrocontroller und Mikrocomputer/Einplatinencomputer/Single-Board-Computer (SBC) informiert. Auf der Recheneinheit selbst muss kein eigenständiges Betriebssystem laufen, das spricht nach meinen Informationen für einen Microcontroller bzw. Single-Board-Microcontroller (SBM). Würdet ihr dem zustimmen? Tendenziell besitzen SBC eine höhere Leistung als SBM, beispielsweise hinsichtlich Prozessor und Speicher. Aber benötige ich diese Leistung auch? Aufgrund der vorgegebenen Randbedingungen resultieren hohe Datenmengen, die ich nach: Datenmenge [Byte] = Auflösung [Bit] * 1/8 * Abtastfrequenz [MS/s] * Messzeit berechnet habe. Wichtig ist, dass die Recheneinheit die Daten speichern kann und die Datenmenge handhaben kann. Konkrete Fragen: - Wann verwendet man ein SBC und wann ein SBM? - Welches eignet sich für den vorliegenden Fall? (Leistungsaspekt) Über die Datenspeicherung informiere mich als nächstes, würde das gerne als wachsenden Beitrag leben lassen. Danke euch! :)
Florian W. schrieb: > Projekt besitzt die folgenden Randbedingungen: > - Mikrofon als Sensor > - Minimale Abtastrate 1,5 MS (Hertz) > - Wünschenswerte Abtastrate 10 MS > - Minimale Auflösung des AD-Wandlers 12 Bit > - Wünschenswerte Auflösung des AD-Wandlers 18 Bit > - Messzeit 3ms Klingt nach einer gehörigen Portion Fehlvorstellungen. Was soll denn da aufgezeichnet werden?
Naja in erster Linie geht es darum zu versuchen die Randbedingungen umzusetzen. Auch ein "ist nicht möglich" wäre ein Erkenntnisgewinn, nur muss diese Erkenntnis erarbeitet werden. Laut deiner Aussage ist das wohl nicht realisierbar. Kannst du mir auch sagen warum?
Was hast du für einen Vorstellung davon für welche Frequenz ein Mikrofon vorgesehen ist?
Das Mikrofon dient nur beispielhaft als Sensor. Wichtig ist die Kette der Digitalisierung.
Es gibt ADCs mit deinen Anforderungen (z.B. LTC2386-18, 18 bit 10 Msps). Mit einem Mikrocontroller wirst du da nicht weit kommen. Klingt eher nach einer Aufgabe für einen FPGA.
Danke für deine Antwort. Die wünschenswerten Randbedingungen werde ich wohl nicht mit einem Microcontroller realisieren können. Dafür aber die minimalen Anforderungen? Das Nucleo L496ZG besitzt einen STM32L496ZG Microcontroller, welcher drei AD-Wandler integriert hat. Die AD-Wandler haben 12-Bit und 5 MS. Damit sollte ich also die Minimalanforderungen erfüllen können. Kritische Stimme dagegen? Die einzige Sorge habe ich aktuell hinsichtlich des Speicherplatzes. Link: https://www.reichelt.de/nucleo-144-arm-cortex-m4-stm32-l496-serie-nucleo-l496zg-p276496.html?&trstct=pol_4&nbc=1
S. W. schrieb: > Auf der Recheneinheit selbst muss kein eigenständiges > Betriebssystem laufen, das spricht nach meinen Informationen für einen > Microcontroller bzw. Single-Board-Microcontroller (SBM). Würdet ihr dem > zustimmen? Nein. Schau Dir mal an, wie ein modernes Speicheroszilloskop funktioniert. Ja, da ist ein Prozessor drin. Der bedient aber nur LAN und USB und macht die Benutzerschnittstelle. Für die eigentliche Datenerfassung ist er zu langsam. Das wird komplett im programmierbarer Digitallogik aufgebaut. Früher waren das Spezialchips, heute nimmt man FPGAs dafür. Die haben sehr schnellen, aber kleinen internen Speicher und oft auch extern angeschlossenen Speicher, der dann aber nicht ganz so schnell ist. Das ist der Weg, den Du gehen wirst, wenn Du Erfolg haben willst. Du wirst wohl bei sowas hier landen. https://digilent.com/shop/zedboard-zynq-7000-arm-fpga-soc-development-board/ So, und zu Deinen sonstigen Anforderungen: Weißt Du, was 18 Bit bedeuten? Da ist dann ein Schritt nur noch 12 millionstel Volt groß. Um das richtig ausnutzen zu können, brauchst Du Wissen und Erfahrung, das Du offenbar nicht hast und so schnell auch nicht haben wirst. Sorry, ist so. Ich denke, selbst die 12 Bit werden für Dich schon mehr als genug sein, damit die letzten Bits nicht im Rauschen verschwinden. fchk
Danke für deine Tipps. Das Wissen und die Erfahrung habe ich noch nicht, da möchte ich von euch profitieren. Im Rahmen meines Projektes möchte ich mir das Wissen entsprechend aneignen, seid nachsichtig mit mir :)
S. W. schrieb: > Das Nucleo L496ZG besitzt einen STM32L496ZG Microcontroller, welcher > drei AD-Wandler integriert hat. Die AD-Wandler haben 12-Bit und 5 MS. > Damit sollte ich also die Minimalanforderungen erfüllen können. > Kritische Stimme dagegen? Ein Versuch wäre es wert. Das Board kostet ja auch nicht viel. > Die einzige Sorge habe ich aktuell hinsichtlich des Speicherplatzes. 5 MSa/s · 3 ms · 2 B/Sa = 30 kB Das sind nur etwa 10% der verfügbaren 320 KiB. Auch die Rechenleistung bei 80 MHz CPU-Takt sollte ausreichen, um die 5 MSa/s in vom ADC zu lesen und in den Speicher zu schreiben. Wahrscheinlich geht das sogar mit DMA, so dass die CPU fast überhaupt nichts tun muss. Erwarte aber nicht zu viel bzgl. der Qualität der ADC-Messungen. Insbesondere die in Mikrocontrollern integrierten ADCs sind oft starken Störungen ausgesetzt, die der Mikrocontroller selbst erzeugt. Dazu kommen das unvermeidbare Messrauschen des ADC selbst sowie dessen Nichtlinearitäten. Ein FPGA braucht man bei 5 oder 10 MSa/s nicht unbedingt. Statt eines Mikrocontrollerboards könntest du auch ein USB-Oszilloskop nehmen. Das ist zwar teurer, dafür aber schon fertig aufgebaut und getestet.
Andreas schrieb: > Was hast du für einen Vorstellung davon für welche Frequenz ein Mikrofon > vorgesehen ist? Es muss ja kein Kohlemikrofon aus einem alten Telefon sein. Die obere Grenzfrequenz besserer Messmikrofone liegt bei deutlich über 100 kHz. Will man das Abtasttheorem nicht bis zum Anschlag ausreizen, sind die genannten 1,5 MSa/s eine durchaus sinnvolle Abtastrate.
Nimm einen RedPitaya. Den gibt es fertig zu kaufen und er erfüllt alle Anforderungen.
S. W. schrieb: > Wichtig ist, dass die Recheneinheit die Daten speichern kann und die > Datenmenge handhaben kann. Schon mal überlegt, wo und in welcher Art die Daten gespeichert werden sollen? - internes / externes RAM, FLASH, USB Stick, Speicherkarte... - Rohdaten (z.B. als Array), aufbereitet (z.B. CSV) - Wie soll der spätere Zugriff / Anzeige erfolgen? Display, Ethernet, Monitor, WLAN, Bluetooth Mal abgesehen von den erwähnten Bedenken gegenüber ADC Auflösungen >12Bit definieren dir unter anderem deine Systemanforderungen Wenn du etwas "Bastelerfahrung" sammeln möchtest und mit verschiedenen Varianten spielen würde ich dir ein Zynq-Board empfehlen (die gibt es bei diversen Händlern auch mit Studenten-Rabaten). Dort hast du zum einen viel Rechenleistung und gleichzeitig ein FPGA in einem Chip... mit den Adapterboards kannst du so mit wenig HW-Tauschen mehrere Varianten durchgehen.
Die Frage ist, mit was hast du Erfahrung? Möchtest du in endlicher Zeit ein Ergebnis haben? Und wie wichtig sind dir die maximalen Anforderungen? Kannst du programmieren? Was für eine Sprache? Kennst du dich mit FPGAs/VHDL aus? Zu den 18Bit: never ever! Vergiss das. Das bekommst du niemals so hin, dass du die 18 Bit auch wirklich nutzen kannst. Wahrscheinlich nicht Mal 16Bit. Was bringen dir 18Bit wenn die unteren 10 Bit rauschen?Außerdem Stelle ich in Frage dass du es wirklich brauchst. Viele Oszis arbeiten auch heute noch mit weniger Auflösung. Außerdem verdoppelt sich deine Datenrate beim Schritt>16 Bit. Zumindest wenn du sauber alignest. Ich würde an deiner Stelle auch mit einem STM32 anfangen. Die Typen mit 3 ADCs können oft interleaved Mode was dann glaube ich 12MSPS sind. Zumindest mit einem Kanal. Und ja, das geht mit DMA. Also ohne jegliche Aktion während des Messzeitraum des uC. Wenn du richtig schaust gibt es dafür bestimmt sogar ein Beispiel das du verwenden kannst.
@N.M. Basiskenntnisse in C bzw. C++ besitze ich. Die wünschenswerten Anforderungen sind nicht besonders wichtig, sie werden wohl auch ein Wunsch bleiben. Ein Ergebnis hätte ich gerne in endlicher Zeit :) Mit FPGAs kenne ich mich nicht aus. Ich verstehe den groben Aufbau und die Unterschied zum Microcontroller und auch, dass die Anwendung im Vergleich zu Microcontrollern deutlich komplexer ist. @Patrick B. Speicherung der Daten: Variante a): - Übertragung der Daten auf einen Laptop während der Messung, sofern möglich? Die Option habe ich noch nicht näher betrachtet. Variante b): - Lokale Speicherung z.B. auf einem USB-Stick oder einer SD-Karte, um längere Messungen (höhere Datenmengen) aufnehmen zu können Danke für den Tipp! Ich werde mir das Board mal ansehen. @all Danke für eure Tipps! Ich werde im Folgenden mit einem Entwicklungsboard mit einem 32-Bit MC weiterarbeiten. Dafür werde ich zunächst erstmal nach Alternativen zum Nucleoboard suchen, um einen Vergleich durchführen zu können.
wie überall, in den Kommentaren ,..FPGA und Fehlvorstellungen .. willkommen im Bastlerforum Deine Anforderungen sind "normal" ADC's mit den betreffenden Eckdaten sind auch nicht so schwierig zu finden. Anstelle eines Mikrocontrollers o.ä. muss man hier halten einen DSP nehmen, ...beides von Texas,.. wie gesagt .. nicht unbedingt etwas für ein Bastlerforum
S. W. schrieb: > Basiskenntnisse in C bzw. C++ besitze ich. Dann würde ich eher in die Richtung gehen. S. W. schrieb: > Mit FPGAs kenne ich mich nicht aus. Denn da ist die Lernkurve für dein Projekt etwas steiler als beim uC. S. W. schrieb: > Übertragung der Daten auf einen Laptop während der Messung, sofern > möglich? Während der Messung, also als lückenloser Stream? Das wäre ambitioniert. Bei 10MSPS und 16Bit Daten + Datensicherung bist du locker flockig bei 240MBit/s+! Ich würde mir überlegen ob du nicht nur Bursts behandelst. Du schreibst oben doch auch was von 3ms Messzeit. Da gehe ich von einem Burst aus (also bei 10MBit 30k Messpunkte). Oder meinst du in einem Ringpuffer? S. W. schrieb: > Messzeit 3ms S. W. schrieb: > Lokale Speicherung z.B. auf einem USB-Stick oder einer SD-Karte, um > längere Messungen (höhere Datenmengen) aufnehmen zu können Kann man machen. Allerdings brauchen gerade SD Karten gerne Mal ein paar Gedenk ms. Sprich, dein benötigter Puffer wird tendenziell eher größer. Außerdem glaube ich nicht dass du diese Datenrate weggeschrieben bekommst. Wie gesagt ist die Übertragung schon ambitioniert. Und das ist nur Fire and forget. Außerdem schreibst du dir auch sehr schnell den NV Speicher kaputt bei den Datenraten wenn du da ständig drauf schreibst. Am ehesten noch 2 stufig. Datenerfassung mit einem uC. Übertragung über ein schnelles Medium. Speicherung in einem SBC o.ä. Alternativ halt die ganz große Keule wie mit einem SoC (CycloneV o.ä.) wo du die Datenerfassung im FPGA machst und ins DDR schiebst. Und das Linux schreibt es weg. Aber wie gesagt, ich würde mir diese Anforderung mit dem Speichern (ohne PC) nochmal gründlich überlegen. Denn der Aufwand steigt dadurch ziemlich.
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.