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.
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 ;)
