Wie Jitter und/oder Packet Loss von Signalkette ADC > Ethernet > PC quantifizieren?

Jakob K. schrieb:

a) sollte passen, ADC wird "hart" über einen Interrupt abgetastet.

Interrupt? Das klingt mir sehr nach Software. Da hast Du Jitter, weil der Controller evtl. noch in einem anderen Interrupt ist, Interruptprioritäten, unterschiedliche IRQ-Entry-Zeiten etc.

Besser macht man das mit Trigger Events. Schau mal im Ref. Man. von Deinem STM32-Modell nach "Conversion on external trigger".

b) möchte ich gerne verifizieren. Nur wie?:

=> Jedes Sample mit einem Timestamp versehen und checken, dass alle ankommen? Kostet halt massiv Bandbreite, das auch noch mit zu senden

Wenn a) sichergestellt ist, musst Du nur noch die Übertragung prüfen. Da Du UDP schreibst, solltest Du auch sicherstellen daß die Pakete in der richtigen Reihenfolge ankommen, das garantiert UDP nämlich nicht.

Du musst keinen vollen Timestamp mit jedem Paket mitsenden, da Du ja grob die Zeit des PCs verwenden kannst um die in einem Zeitraum empfangenen Pakete zu zählen und so sicherzustellen daß die Größenordnung stimmt.

Jetzt musst Du Dich nur noch gegen den Verlust einzelner Pakete absichern. Das kannst Du nicht mit der Uhr des PCs machen da die leicht vom Takt des Controllers abweicht. Also füge einfach jedem Deiner Pakete ein extra Byte mit einem 8 Bit Zähler hinzu. Den erhöhst Du mit jedem Paket, nach 256 Paketen läuft er über und fängt wieder bei 0 an. Das sollte reichen um sicher zwischen Zeitabweichung und Paketverlust zu unterscheiden. Außerdem kannst Du so die Paketreihenfolge prüfen.

Moin,

Jakob K. schrieb:

=> Jedes Sample mit einem Timestamp versehen und checken, dass alle ankommen? Kostet halt massiv Bandbreite, das auch noch mit zu senden

Bauste halt auf UDP noch RTP drauf, das macht dann 12Byte mehr pro (UDP)Packerl, dafuer gibts einen Continuitycounter und Timestamps. Sinnvollerweise sendet man mehrere Samples in einem UDP/RTP-Paket oder wenns wirklich so pressiert, verkneift man sich das Jammern ueber zuviel Bandbreite...

Gruss WK

Auf uC Seite würde ich mit einem DMA und einem Ping Pong Buffer die Daten sampeln. Dann bist du uC seitig unabhängig von evtl Jitter innerhalb deiner Tasks und die Hardware übernimmt komplett das Erfassen der Daten.

Damit du nicht noch vor dem Versenden umkopieren musst, schaufelt der DMA direkt in den Member deiner Frames im RAM. Im DMA End Interrupt berechnest du nur noch deine Prüfsumme falls notwendig (nimm die CRC Perepherie im STM, die ist schneller) und startest den Ethernet Transfer über einen zweiten DMA.

Jakob K. schrieb:

abtastet und via Ethernet und UDP an einen Rechner sendet.

Jakob K. schrieb:

Ich möchte sichergehen, dass: b) keine Samples zwischen ADC und PC verloren gehen

Das wiederspricht sich meiner Meinung nach. UDP stellt ja gerade nicht sicher dass es überhaupt ankommt. Was soll denn passieren wenn Frames verloren gehen? Darf das überhaupt passieren? Wenn nein, brauchst du was verbindungsorientiertes. Wenn ja, siehe unten.

Jakob K. schrieb:

=> Jedes Sample mit einem Timestamp versehen und checken, dass alle ankommen?

Du wirst ja nicht nur ein ADC Sample pro UDP Frame versenden? Das wäre ja ineffektiv hoch 10! Mach den Frame relativ voll um wenig Overhead zu haben. Oder halt wenigstens ein paar kB groß. Ein Zeitstempel pro Übertragung reicht ja auch, der Rest ist ja äquidistant abgetastet. RTP würde von Dergute W ja bereits genannt.

Edit: Typo

N. M. schrieb:

Ein Zeitstempel pro Übertragung reicht ja auch

Im Prinzip langt auch ein einfacher Zähler, der bei jedem Paket hochzählt. Da erkennt man Lücken sofort erkenne und Überholungen kann man auch wieder sortieren. Bei Timestamps muss man immer noch etwas rumrechnen, ob dazwischen einer Fehlt oder ob der Timestamp nur eine ungünstige Rundung gemacht hat.

Eine erste Frage waere ob das Ganze nur eine Quantifizierung des Jitters sein soll, oder eher eine Vermeidung. Falls der Jitter minimal sein soll, wuerde man das Timing mit einem CPLD/FPGA produzieren, und der Controller wuerde per Interrupt, resp DMA abholen. UDP ist uebrigens super zuverlaessig wenn man's alleine laufen laesst, dh nicht ueber das Firmennetzwerk.

Wie ueblich fehlt ein wichtiges Detail .. von welcher Sampling rate reden wir ?

Die Laufzeit ist egal solange die Samples konsekutiv sind. Ich wuerd mal mit blockgroessen eines Ethernet Packetes von 1500bytes arbeiten.

Wenn Du von Bandbreitenverlust redest -- wieviele Pakete pro Sekunde werden denn übertragen, und wie viele Samples sind in einem Paket enthalten?

Jakob K. schrieb:

Wie würdet ihr das machen?

Das würde ich von Abtastrate, Datenmenge und Echtzeitanforderungen abhängig machen. Es ist ein Unterschied, ob jede Minute die Raumtemperatur gemessen oder ein 10MHz-Signal abgetastet wird.

N. M. schrieb:

Du wirst ja nicht nur ein ADC Sample pro UDP Frame versenden? Das wäre ja ineffektiv hoch 10! Mach den Frame relativ voll um wenig Overhead zu haben.

Genau das dachte ich auch gerade. Einmal abgesehen dass niemand weiss wie dein Netzwerk aussieht (Switches, andere Teilnehmer...) hast du bei IPv4 UDP schon ohne Daten einen Overhead von 20 Byte. Ein NIC oder Switch wird dir bei einen Buffer-Overflow halt dann auch Pakete verwerfen, erst recht wenn du UDP verwendest. Und dein PC wird sicher nicht die Daten mit deiner ADC-Samplefrequenz bearbeiten müssen...

Ich würde 100-1000 Werte sammeln (DMA, double buffer Prinzip), 1 TimeStamp versehen und dann versenden. TCP hätte ein paar Vorteile z.B. Paket-Reihenfolge und -Loss, muss aber nicht sein. Dann baust du dir halt selber ein entsprechendes Protokoll nach. Deine PC-Applikation kann aus dem TimeStamp und Anzahl Werten dann die Zwischenzeiten wenn nötig wieder errechnen.