Geschwindigkeitsproblem: großes array an trigger teilen und sortieren

@lucki

' schrieb:Ich liebe solche Threads, wo sich der Frager mit Informationen immer so bedeckt wie möglich hält - angefangen beim fehlenden VI.^_^

Dein Lieblingsthread ist also der, der nur aus einem Fragezeichen besteht?


Man muss den Fragenden aber zu Gute rechnen, dass das Aufschreiben der Probleme nicht immer ganz leicht ist und dass er einige Dinge implizit als bekannt vorraussetzt, die es für den Helfenden gar nicht sind oder sein können. Manchmal helfen ja auch die zig Nachfragen dem Hilfesuchenden weiter und mehr Klarheit zu bekommen. Ist für den Helfenden zwar etwas unzufriedenstellend.

@ all
Ist finde diesen Thread ok.

Ich befürchte man muss hier viel probieren. Vielleicht doch an der messtechnischen Vorgehensweise was verändern. Oder gar 'nen schnelleren Rechner einsetzen. Doch dazu sind Tipps nur möglich, wenn mehr Information über die Aufgabenstellung und die bisherige Umsetzung gepostet wird.

Anzeige

@unicorn
Du hast natürlich Recht, da gibt es weitaus viel Schlimmeres, bei dem ich mir sage: Finger weg, bloß nicht noch mitmachen.
Aber Du hast ja gegenüber mir auch den Vorteil, daß Du verstanden zu haben scheinst, was tinger will. Würdest Du das mal erklären? Und zwar bitte ohne Worte, indem Du das "Array out" von Schrotti berichtigst.
Also: Gegeben: Array In = [0,1,2,3,4,5,6,7], Triggerpunkt bei Index=3, Array Out = [?,?,?,?,?,?,?,?]
   
Daß das tinger in dieser Form nicht selbst so gemacht hat, war für mich der Stein das Anstoßes, und daß das schiwerig ist zu erklären, das stößt hier ins Leere: jedes erkärende Wort ist überflüssig, wenn man nur die obigen 8 Werte in der richtigen Reihenfolge hinschreibt.

[code]Daten

@unicorn
Danke für die Information. Du hattest ja am Anfang schon gesagt, daß sich an dem von tinger selbst vorgeschlagenen Splitting nicht mehr viel verbessern lässt - dem stimme ich zu.
Alledings sollte man das ganze Konzept mal auf den Prüfstand stellen, und da sind zwei Verbesserungen vorstellbar:[list=1]
[*]Die Datenerfasssung wird ja von der Karte selbst organisiert, d.h die CPU des PCs wird in dieser ganzen Zeit kaum belastet. Es läge doch nahe, mit dem Ordnen schon zu beginnen, wenn die Datenerfassung läuft und nicht erst, wenn 6 Millionen Daten angefallen sind. Genau für so ein Pipelining sind doch Queues schließlich da!<>
[*]Die Karten haben doch selbst immer komfortable interne und externe Triggermöglichkeiten. Sollte es da wirklich nicht möglich sein, bereits die Datenerfassung selbst so zu triggern, daß das Problem mit dem Triggerpunkt mitten in einem gelesenen Daten-Array gar nicht erst entsteht? tinger sagt zwar, das sei nicht möglich, aber ganz glauben kann ich es nicht.<>
[st]Mir fällt da doch noch ein Verbesserung ein: ich habe festgestellt, daß Ques langsam sind, wenn man als Datenelemente Arrays verwendet. Der Grund ist, daß jedes einzelne Array in der Queue intern geclustert werden muß. Besser ist es allemal, die Queue statt mit Arrays mit Einzelwerten füttern - also die Arrays in einer for Schleife zu indizieren und in der Schleife alle Elemente der Queue als Einzelelemente hinzufügen.
Die ganze Sortierung könnte dann grundlegend anders organisiert werden.

Hey, Danke, dass ihr euch immer noch Gedanken macht!

Und Entschuldigung Lucki, dass ich das Problem nicht gut genug darstellen konnte. Ich dachte der Screenshot-Ausschnitt mit den Shiftregistern macht das Problem deutlich.

zu 1. genau dazu verwenden wir die Queues auch! Das hätte ich vielleicht auch besser erklären sollen. Ist für mich, den Fragen stellenden, aber auch wirklich nicht so leicht zu entscheiden was ich alles an Information dazu geben muss und was nur für Verwirrung sorgt. Durch unsere Samplingrate und die Anzahl der Kanäle ergibt sich, dass die 6 mio Messpunkte einer zehntel Sekunde Messzeit entsprechen.

zu 2. Wir haben keine Möglichkeit ein einfaches Triggersignal zu schicken. Unsere Messaufbauten sind räumlich stark von einander getrennt. Und den Trigger in den Messdaten suchen kann die Karte nicht so, wie wir leider müssen (die Triggersuche ist nicht so trivial, deswegen habe ich sie auch bewusst ausgeblendet, um eure Zeit nicht damit zu verscchwenden, dass ihr versucht den Code zu verstehen.).

Dein Verbesserungsvorschlag klingt intressant! Leider verstehe ich ihn nicht ganz. Wie könnte ich dann die Einzelwerte sortieren? Gibts vielleicht ein Beispiel in dem so etwas gemacht wird oder eine Thread in dem so etwas diskutiert wird? Ich habe natürlich versucht zu suchen bevor ich das Thema erstellt habe, aber nichts passendes gefunden, aber vielleicht habe ich nur mit den falschen Begriffen gesucht.

Gern mache ich Dir ein Beispiel, aber ich würde gern wissen wie Du die Triggerbedingung feststellst. Also: Woher kommt die Information, daß der 51.Datenwert eines gelesenen Datensatzes dem Triggerzeitpunkt entspricht?
2. Frage: Wäre es möglich, die Triggerinfomation in den Daten gleich selbst mit unterzubringen? z.B so: I16 unfasst den Wertebereich -32768..32767. Davon wird der Wert -32768 reserviert: Falls er in den Daten vorkommen sollte, wir der durch -32767 ersetzt. Ein in den Datenstrom eingefügter Wert -32768 markiert den Triggerpunkt und ist selbst kein Datenpunkt.

Das wäre natürlich super!

Ich kann dir gerne sagen woher die Information kommt, aber ich fürchte es hilft nichts:

In unserem Signal treten relativ große Kalibrationspulse auf. Also zweimal mehr oder weniger Gaußförmige positive Werte (16 Samples pro Puls), dann zweimal negative Werte, dann zwei mal wieder positive aber nicht ganz so große Werte. Sortieren wollen wir so, dass das Array bei dem ersten großen Puls einer Pulssequenz beginnt. Nach diesen Kalibrationspulsen kommen kleinere Signale bis nach etwa 30 Pulsen wieder Kalibrationspulse kommen. Ich hoffe du verstehst eingermaßen was ich sagen will. Ich habe eine kleine Zeichnung angehängt. Wir suchen also einen hohen Puls, können dann aber nicht sicher sein ob wir nicht den zweiten hohen oder die etwas niedrigeren erwischt haben (Grüne Markierungen in der Zeichnung). Deswegen gehen wir eine feste Anzahl an Samples weiter im Array (Pfeil) und befinden uns nun sicher in einem Bereich zwischen den Kalibrationspulsen. Dann suchen wir wieder einen hohen und können ziemlich sicher sein, das es der erste große Puls einer neuen Pulssequenz ist (Blaue Markierung).

Ich bin mir nicht sicher ob ich das jetzt gut genug erklärt habe. Kannst gerne nochmal nachfragen! Es funktioniert auf jeden Fall ganz gut und ist auch nicht der Flaschenhals.

Also ich kann das nur ganz grob skizzieren.
Ich setze voraus, dass Du es geschafft hast, zwischen den Eingangsdaten (Input Array im Bild) die Triggermarken (-32768) zu platzieren. Dann würde man in der oberen Schleife die Werte in die Queue bringen. In der unteren Schleife werden die Werte wieder ausgelesen, aber mit anderen Datensatzlängen wie beim Einlesen: es wird immer so lange gelesen, bis eine Triggermarke kommt. Die Daten sind damit bereits voll sortiert. Sie verlassen die Schleife oder kommen in eine andere Queue.
Wie gesagt, nimm das nicht zu sehr unter die Lupe, das soll dich nur zu eigenen Ideen anregen.

   

Die Kalibrationspulse fallen aber doch nicht vom Himmel, oder? Sprich sie treten doch nicht zufälligerweise irgendwann auf, sondern sind periodisch, oder? Gibt es da gar kein einfaches Signal (Rechteck, Sinus), das synchron mit der Gruppe der Kalibrationspulse läuft?

Die Antwort wird wohl nein sein und auch hartnäckiges Fragen hilft nicht einen vernünftiges Triggersignal hervorzuzaubern. Dabei sind wir doch nur neugierig und wollen noch ein paar Details über den Messaufbau erfahren.

Die räumliche Trennung könnte signaltechnisch durch ein Delay oder Pre-trigger kompensiert werden.

Aber wenn ich genauer nachdenke, vermute ich, dass Deine Datenerfassung hardwaremäßig gar nicht getriggert ist, sondern frei läuft. Vielleicht hilft folgende Idee:
- Ein Sample mit 6 Mio Punkten erfassen
- Triggerzeitpunkt ermitteln
- Datenerfassung zeitgesteuert neu starten, so dass Triggerzeitpunkt ziemlich zu Beginn in jedem 6 Mio Punkte Sample ist.

Das setzt voraus, das am Ende jeder Periode unwichtige Messwerte sind (die stehen immer noch vorne drin) und die Signale gut periodisch kommen. Wahrscheinlich klappt auch der zeitgesteuerte Neustart nicht. Man sparte aber das Umsortieren sowie eine Queue.

Vielleicht geht auch ein Delay, dass die Messdaten verzögert und von der Software gesteuert wird, so dass die Samplepakete immer zu den Signalen passen und das Umsortieren obsolet machen.

Ich gebe zu, dass das recht wilde Ideen sind, die höchstwahrscheinlich nicht realisiert werden können.

Die Datenerfassung ist hardwaretechnisch überhaupt nicht getriggert, sondern läuft im Free Run. Wenn euch der Messaufbau intressiert kann ich dazu auch ein bisschen was sagen:

Es handelt sich um eine M2i.3033-exp A/D Karte (von Spectrum). Das Signal ist ein modulierter Laserstrahl der über einen Kilometer im Freiraum zurückgelegt hat. Ein einfaches Triggersignal gibt es leider nicht

@Lucki: Vielen Dank für dein Beispiel. Ich versuch das am Wochenende zu verstehen und vielleicht nachzubauen.