Guten Abend die Herrschaften Ich habe 3 gleiche aber verschobene analoge Signale, und möchte die Verschiebungszeit eben dieser bestimmen (minimal 2,5µs maximal 800µs, Signallänge maximal 100ms). Wie ich vorgehen möchte: wenn ein Trigger aktiviert wird, sollen die Signale synchron diskretisiert (Auflösung von 8 Bit genügt) zwei malige Kreuzkorrelation um Verschiebung zu ermitteln Welche Hardware steht zur Verfügung: Um die Synchronität zu gewährleisten sollen dabei 3 ADU eingesetzt werden entweder diese https://www.ti.com/lit/ds/symlink/ads7029-q1.pdf oder von AD die "Kollegen" Typ 7278 https://www.analog.com/media/en/technical-documentation/data-sheets/ad7276_7277_7278.pdf Da beide spätestens im dritten Takt nach dem CS Signal anfangen ihre Daten zu senden, wird es wohl schwierig für die Erfassung einen RPI zu Verwenden oder? Wenn ich aber mit 3MSps 100ms aufzeichne, werden ja 300kByte RAM nur zum Speichern eines Datensatzes benötigt, D.h. Nucleo und solche Kollegen fallen schon kategorisch aus dem Raster (Zumindest kenne ich keine Version die annähernd mit so viel RAM ausgestattet ist). Ein Teensy 4.1 könnte (theoretisch) den Datensatz eines ADU im RAM puffern, wäre durch die FPU auch super für die Kreuzkorrelation geeignet. Allerdings würde ich ja mindestens 3 dieser "Mitarbeiter" für die Umsetzung benötigen, was ich alles in allem als "to much" empfinde. Deshalb frage ich Euch hier nach Expertise, weiteren Anregungen und Ideen, wie man ein solches System umsetzen kann. Das ganze soll (wie immer) natürlich mit ( Triggerwarnung ;-) ) "minimalem Aufwand" realisiert werden. Ich bin gespannt, und freue mich über jede Antwort!
Wie sehen die Signale aus? Kannst du die Kreuzkorrelation nicht ersetzen durch eine Flankendetektion? Das macht die Aufgabenstellung immens einfacher, dann genügt nämlich ein x-beliebiger µC mit timer capture. Es wird schon Fälle geben, in denen das nicht geht, aber ich würde mir sehr gut überlegen, ob ich nicht irgendwie so (analog) vorprozessieren kann, dass es doch so geht. Falls es doch unbedingt per ADC sein muss, es gibt 4-Kanal Simltaneous Sampling ADCs, ich habe mir für eine ähnliche Anwendung mit auch ähnlichen Timing-Anforderungen so ein Board mit dem LTC2324-14 gebaut. Das ist aber schon ein recht nennenswerter Aufwand. Funktionieren tut's aber gut.
Du baust einen Algorithmus der so ein Signal erkennt. Weil die Signale gleiche sind ist dann auch der Zeitunterschied zwischen den Erkennungen der Signale durch den Algorithmus gleich der Verschiebung.
Amin L. schrieb: > D.h. Nucleo und solche Kollegen fallen schon kategorisch aus dem Raster Da bin ich mir nicht ganz sicher. Du brauchst ja nur 3ADCs und externen RAM. Der F407 hat meine ich 3x2.4MSPs ADCs. Der H7 2+1 wo auch ausreichend schnell sein dürften. Vielleicht gibt es noch mehr Typen wie die L4/L5 da bin ich mir nicht sicher. Kurze Suche bei eBay... Da gibt es H7 Boards mit 64MBit SDRAM. Sollte also reichen. Was nicht ganz rauskommt aus deinen Anforderungen ist meiner Meinung nach: Müssen die Berechnungen auf dem Board erfolgen? Oder reicht eine Messererfassung/Weiterleitung und ein PC/Raspi o.ä. macht den Rest? Wenn Weiterleitung, was für eine Schnittstelle? Wie schnell möchtest du solche Aufzeichnungen hintereinander erfassen/berechnen können? Was ist der Trigger und die zulässige Latenz des Triggers? Amin L. schrieb: > wie man ein solches System umsetzen kann Du kannst auch ein Max1000 Board nehmen und 3 ADCs dran schnallen. Theoretisch würden noch mehr ADCs gehen von Speicher. Kennst du dich mit FPGAs aus? Wäre mit Sicherheit eine Alternative.
Erst einmal vielen Dank für eure Antworten Sven B. schrieb: > Wie sehen die Signale aus? Kannst du die Kreuzkorrelation nicht ersetzen > durch eine Flankendetektion? Das macht die Aufgabenstellung immens > einfacher Das geht leider nicht, denn das Signal ist beliebig. Sven B. schrieb: > ähnlichen Timing-Anforderungen so ein Board mit dem LTC2324-14 gebaut Hast du für das synchrone "abholen" der Daten einen µC mit 4x SPI verwendet? Gustl B. schrieb: > Du baust einen Algorithmus der so ein Signal erkennt Der Algorithmus, den ich anwenden möchte nennt sich Kreuzkorrelation? Kannst du deine Antwort ggf. etwas näher erläutern? Irgendwie stehe ich gerade auf dem Schlauch. N. M. schrieb: > Kurze Suche bei eBay... Da gibt es H7 Boards mit 64MBit SDRAM. Sollte > also reichen. Konnte leider nichts mit 64Mbit RAM finden, das würde ja schon alle Probleme lösen .. Habe irgendwo noch einen Nucleo herumliegen der dem von dir vorgeschlagenem Board leistungsmäßig sehr nah kommt allerdings hat der nur ~80kiByte RAM Die Berechnung sollte möglichst auf der vorhandenen Hardware stattfinden aber denke für die KK läuft es schon auf einen RPi hinaus (was nicht schlimm ist) beim Trigger handelt es sich einfach um einen Impuls dachte der könnte einen Interrupt auslösen, und der µC steuert anschließend die ADC an Latenz ist irgendwo um die ~50ms
Amin L. schrieb: > Das geht leider nicht, denn das Signal ist beliebig. Komplett beliebig? Was ist das denn für ein Signal? Schon minimales Vorwissen, z.B. "das Signal ist zu irgendeinem Zeitpunkt größer als 15 mV" lässt sich mit einem Komparator in eine Flanke übersetzen, die dann fast trivial erfasst werden kann.
Amin L. schrieb: > Konnte leider nichts mit 64Mbit RAM finden Dann hast du wahrscheinlich nicht richtig gesucht: https://www.ebay.de/itm/STM32-STM32H743IIT6-MCU-core-board-full-IO-expander-JTAG-SWD-debug-interface/254302488784
1 | IC42S16400J / IS42S16400J: SDRAM 1 Meg Bits x 16 Bits x 4 Banks (64-MBIT) |
Das ist aber dann schon das ganz große Kaliber. Nur für Messdatenerfassung tut es da mit Sicherheit auch ein kleinerer. Es gibt wie gesagt auch noch andere STMs (z.B. G Serie) mit z.B 5ADCs. Müsste man Mal suchen ob es da Boards gibt mit externen Speicher. Wenn du keinen kontinuierlichen Stream brauchst ist das von Core Seite halb so wild. Der Trigger löst einen Timer aus der wiederum den ADC triggert der wiederum den DMA triggert bis dein übergebenes RAM Array voll ist. Das machen manche uCs komplett ohne Core. Bei den anderen braucht's vielleicht 1-2 Steps im Trigger ISR. Für das Übertragen an die eigentliche Verarbeitungsschicht scheint ja viel Zeit vorhanden zu sein. Zumindest hat du dazu noch nichts gesagt.
Sven B. schrieb: > Komplett beliebig? Was ist das denn für ein Signal? Ja komplett beliebig, es handelt sich um 3 DMS die an 3 gleichen Teilen die Krafteinwirkung messen. Die Signale werden verstärkt und das Rauschen gefiltert. Je nach Art der Kraftwirkung sind deshalb völlig unterschiedliche Signale zu erwarten. Eine einfache Flankendetektion ist deshalb LEIDER nicht möglich. N. M. schrieb: > Ebay-Artikel Nr. 254302488784 Vielen Dank! ich habe tatsächlich nichts vergleichbares gefunden. Bei diesen vergleichsweise "geringen" Datenraten ist doch ein DMA nicht zwingend erforderlich? Du würdest also auf externe ADC verzichten, und die des µC verwenden + zusätzlich(SD/F)RAM? Für Übertragung und Verarbeitung sind bis zu 3 Sekunden vorgesehen, das sollte ja aber kein Problem darstellen. Bei bisherigen versuchen, mit einem ADC und einem Referenzsignal habe ich die Daten via UART auf den Rechner geschoben, LabView hat dann den Rest erledigt ;)
Amin L. schrieb: > und das Rauschen gefiltert Musst du Mal schauen. Die G Serie der STMs hat teilweise Filter in Hardware die man beim ADC nutzen kann. Dann brauchst du das später nicht in Software machen. Ich könnte mir vorstellen dass der H das auch hat. Amin L. schrieb: > Bei diesen vergleichsweise "geringen" Datenraten ist doch ein DMA nicht > zwingend erforderlich? Vielleicht nicht, aber warum unnötig verkomplizieren. Nachher musst du doch noch Sachen berechnen oder es kommt doch noch etwas dazu das der Core machen soll und auf einmal wird es knapp. Mit DMA entlastet du extrem den Core. Wenn er nichts machen muss, würde ich mir die Sleepmodes anschauen und noch etwas Strom sparen. Amin L. schrieb: > Du würdest also auf externe ADC verzichten, und die des µC verwenden Wenn du nur so gering Anforderungen hast, wieso nicht. Der interne hat schon 12Bit. Du brauchst 8. Mit Oversampling (was er glaub ich auch in Hardware könnte) sogar mehr, wobei man da wahrscheinlich dann an die Grenze der möglichen Abtastrate kommt. Amin L. schrieb: > zusätzlich(SD/F)RAM Wieso FRAM? Das bekommst du in den großen nicht. Und du musst doch nicht NV speichern, oder? Und selbst wenn... Das kann ja dann der Raspi/PC. Amin L. schrieb: > Für Übertragung und Verarbeitung sind bis zu 3 Sekunden vorgesehen, > das sollte ja aber kein Problem darstellen. Ne definitiv nicht. Der H7 hat USB und Ethernet. Je nach dem was du möchtest. USB sollte mit dem Board von oben direkt gehen. Ethernet brauchst du wahrscheinlich noch etwas Hardware. Wenn du es als Stream übertragen wolltest, siehst du jetzt auch warum der DMA gut wäre. Amin L. schrieb: > Bei bisherigen versuchen, mit einem ADC und einem Referenzsignal habe > ich die Daten via UART auf den Rechner geschoben Kannst du hier theoretisch auch machen wenn du willst. Musst du halt ein CDC Device implementieren. Oder wie gesagt halt Ethernet.
N. M. schrieb: > Die G Serie der STMs hat teilweise Filter in > Hardware die man beim ADC nutzen kann. Danke, ich muss mich vorerst aber in die Spezifikation dieser Filter einlesen, um zu entscheiden ob mir diese auch von Nutzen sein können. N. M. schrieb: > Vielleicht nicht, aber warum unnötig verkomplizieren. Nachher musst du > doch noch Sachen berechnen oder es kommt doch noch etwas dazu das der > Core machen soll und auf einmal wird es knapp. > Mit DMA entlastet du extrem den Core. Wenn er nichts machen muss, würde > ich mir die Sleepmodes anschauen und noch etwas Strom sparen. Da das ganze am Netz betrieben wird, ist Stromverbrauch nicht unbedingt zu berücksichtigen. Aber du hast recht, mithilfe vom DMA wäre es ja auch möglich einen deutlich kleineren µC zu verwenden. Die Berechnungen werden nämlich (sehr wahrscheinlich) auf einem RPi ausgeführt. N. M. schrieb: > Wieso FRAM Mein Fehler, sollte "SRAM" lauten N. M. schrieb: > Der H7 hat USB und Ethernet Dann wird es sicher eine Übertragung via USB geben Ethernet ist dann doch ein wenig op für 3 Sensoren ;)
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.