Forum: Digitale Signalverarbeitung / DSP / Machine Learning I2S Frame-Fehler automatisch erkennen/korrigieren


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Burkhard K. (buks)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich ziehe I2S Daten (16bit PCM, Big Endian, 2 Kanäle) mit 4 MBit/s über 
USB via Raspi Zero vom FPGA auf eine SD-Karte, dabei verliert der 
Empfänger gelegentlich die ersten Bytes. Resultiert daraus ein 
Frame-Fehler, ist auf beiden Kanälen effektiv nur weißes Rauschen.

Der Fehler lässt sich manuell einfach beheben - ein oder drei Bytes 
entfernen bis der Rahmen wieder stimmt. Schön wäre es, wenn das sich mit 
irgendeiner Heuristik automatisieren ließe. Natürlich könnte ich eine 
Präambel mitsenden, aber die müsste sendeseitig eingefügt werden. Gibt 
es noch andere Möglichkeiten, weisses Rauschen in einer begrenzten 
Anzahl führender Frames zu detektieren?

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Burkhard K. schrieb:
> Ich ziehe I2S Daten (16bit PCM, Big Endian, 2 Kanäle) mit 4 MBit/s über
> USB via Raspi Zero vom FPGA auf eine SD-Karte, dabei verliert der
> Empfänger gelegentlich die ersten Bytes.

Wie werden die Daten denn zwischen FPGA und Raspberry übertragen? Ich 
würde da eher mal nach der Ursache gucken und die beheben.

Burkhard K. schrieb:
> Schön wäre es, wenn das sich mit
> irgendeiner Heuristik automatisieren ließe.

Klar, wenn der neu empfangene Abtastwert nicht zu den schon vorher 
empfangenen passt. Wobei das halt auch schwierig wird wenn die 
Abtastrate im Vergleich zur Frequenz gering ist.

Mit 16 Bits hast du leider keine freien Bits in zwei Bytes. Du könntest 
aber für jeden Abtastwert 3 Bytes übertragen und die Bits dann so 
verteilen:
00000DD0  DDDDDDD1 DDDDDDD1
Dann ist zumindest mit den 3 LSBs der Rahmen klar. Zuerst muss eines mit 
0 hinten kommen und dann zwei mit 1 hinten.
Ich verwende UART als Übertragung zwischen FPGA und PC. Verlorene Bytes 
hatte ich noch nie.

von Burkhard K. (buks)


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Ich würde da eher mal nach der Ursache gucken und die beheben.

Die ist bekannt: RaspianOS auf dem Zero ist kein RealTime-OS und das 
Dateisystem liegt genau auf der SD-Karte, auf der die Daten landen.
Schau mir deshalb gerade Tiny Core 
(http://tinycorelinux.net/11.x/armv6/releases/RPi/) an. Bei Übertragung 
zum Laptop tritt das Problem nicht auf, aber den kann/will ich nicht 
"ins Feld" mitnehmen.

Gustl B. schrieb:
> für jeden Abtastwert 3 Bytes übertragen
12MBaud sind bereits das Limit meines UARTS (nicht 4MBaud wie 
fälschlicherweise oben geschrieben). Deshalb (und aus weiteren Gründen) 
will ich das Einfügen von zusätzlichen Bytes lieber vermeiden.

Gustl B. schrieb:
> Klar, wenn der neu empfangene Abtastwert nicht zu den schon vorher
> empfangenen passt.
Das war meine Frage - wie läßt sich weißes Rauschen, d.h. fehlende 
Korrelation der Abtastwerte mit einem (z.B. numpy-)Skript möglichst 
einfach diagnostizieren? Visuell ist die Situation ja eindeutig.

Inzwischen gefunden: 
https://machinelearningmastery.com/white-noise-time-series-python/
Der Mittelwert tendiert gegen 0 und die Standardabweichung gegen 1. 
Werde heute mal schauen, ob ich mit meinen Daten passende Schwellwerte 
finde und wieviele Pakete ich anschauen muss, um eine sichere 
Entscheidung zu treffen.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Burkhard K. schrieb:
> RaspianOS auf dem Zero ist kein RealTime-OS und das
> Dateisystem liegt genau auf der SD-Karte, auf der die Daten landen.

Das trifft aber auch auf den Laptop zu. Welchen UART Baustein verwendest 
du? Vielleicht kannst du größere Puffer einstellen oder den häufiger 
abfragen.

Burkhard K. schrieb:
> Das war meine Frage - wie läßt sich weißes Rauschen, d.h. fehlende
> Korrelation der Abtastwerte mit einem (z.B. numpy-)Skript möglichst
> einfach diagnostizieren?

Tja ... finde ich nicht sehr zielführend. Du wirst da immer einige viele 
Abtastwerte verlieren.

von yesitsme (Gast)


Bewertung
0 lesenswert
nicht lesenswert
I2S hat mit Word-select eine Synchronisierung, USB ist auch eher 
packetorientiert.

Ich denke dein Problem ist das Protokoll was du über USB schiebst. 
Vielleicht solltest du da einen Frame-Sync einbauen.

BTW. I2S müsste auch auf der Stiftleiste des RPI liegen.

von Gustl B. (gustl_b)


Bewertung
0 lesenswert
nicht lesenswert
Er überträgt die Daten per UART zum Raspberry. Also weder USB noch I2S.

von Burkhard K. (buks)


Bewertung
0 lesenswert
nicht lesenswert
Ich danke Euch für Eure Bemühungen, mich auf den rechten bzw 
zielführenden Weg zu bringen. Wie gesagt arbeite ich bereits daran, das 
Problem der "dropped Bytes" zu eliminieren.

Das ist aber nicht Thema dieses Threads. (Das Kind liegt bereits im 
Brunnen und ich habe eine Sammlung an "kaputten" Daten, die ich trotzdem 
auswerten will.) Inzwischen habe ich ein bisschen mit numpys std(), 
median() und histogram() herumgespielt. Damit lässt sich die Situation 
tatsächlich recht gut erfassen, ich muss jetzt nur noch geeignete 
Schwellwerte bestimmen.

@Gustl - tatsächlich ist die von mir ursprünglich gewählte Kombination 
aus Zero, RaspianOS und SD-Karte der Grund für die "dropped Bytes":
* Single CPU
* 512 MByte RAM
* Filesystem auf SD-Karte
Der empfangende Prozess konkurriert mit dem Betriebssystem um die 
einzige CPU, selbst wenn er mit RT-Priorität läuft. Hinzu kommen 
Latenzen durch das Logging auf die SD-Karte bzw. Lesen von derselben. 
Tiny Core sollte helfen, da es nach dem Booten nur noch vom RAM-FS 
läuft. Wenn nicht, muss ich wohl auf ein Gerät mit mehr als einer CPU 
(und höherem Stromverbrauch) ausweichen. Oder auf Ethernet.

yesitsme schrieb:
> ist das Protokoll was du über USB schiebst
Das Protokoll (Seriell über USB) ist nicht das Problem, siehe oben.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Burkhard K. schrieb:
> Der empfangende Prozess konkurriert mit dem Betriebssystem um die
> einzige CPU, selbst wenn er mit RT-Priorität läuft.

Ja, genau. Verwendest du Python um vom UART aufzunehmen?
Wie machst du das? Das kann man blocking und nonblocking machen.
Welche Datenmenge musst du denn in welcher Zeit wegschaufeln? Der UART 
kann 12 MBaud, aber wie viele Bytes/s müssen tatsächlich übertragen 
werden?
Wie machst du das im FPGA, schreibt der stumpf Bytes raus sobald der 
UART wieder Ready meldet oder sendet der nur auf Anfrage vom PC?

Ich habe für mich zwei Varianten gebaut:

1. Stumpfes Senden. Der FPGA sendet ohne Anfrage. Da lese ich dann am PC 
immer. Allerdings weiß ich beim Lesen natürlich nicht wo im Paket ich 
neue Daten bekomme. Da muss man dann also eine Art Schieberegister 
implementieren. Ganz grob (mit 3 Bytes und LSB Framing):
ser = serial.Serial("\dev\gerät", 921600, timeout=0)
werte = []
sr = []
und dann regelmäßig:
  data = ser.read(100000) #lese alles was im puffer steht
  if len(data) > 0:
    sr.extend(data)
    if len(sr) >= 3:
      if (sr[0] & 1 == 0) and (sr[1] & 1 == 1) and (sr[2] & 1 == 1):
        wert = (sr[0] >> 1)*128*128 + (sr[1] >> 1)*128 + (sr[2] >> 1)
        werte.append(wert)
      else:
        sr = sr[1:len(sr)]
        print ("RESYNC")

2. Senden auf Anfrage. Im FPGA werden die Werte in einen FIFO 
geschreben. Der PC fragt dann eine Anzahl an Werten an und leist so 
lange bis er die auch bekommt.
Weil da bekannt ist wie viele Werte kommen und wo der Anfang ist braucht 
es kein Framing.
ser = serial.Serial("\dev\gerät", 921600, timeout=0)
werte = []
und dann regelmäßig:
  N = 10 # also 2**10 zu lesende Werte je Lesetransaktion
  uart_data = bytearray()
  ser.write(bytearray([10]))
  ser.flushOutput()
  ser.flushInput()
  while ((len(uart_data) < 2**(N+1): # also 2**11 Bytes bei 2 Byte je Wert
    data = ser.read(2**(N+1))
    uart_data.extend(data)
  for x in range(0,N):
    werte.append((uart_data[x*2])*256+(uart_data[x*2+1]))

Das Problem bei begrenzter Rechenleistung ist, dass wenn du jetzt Fehler 
zu erkennen versuchst, dann braucht das auch Rechenleistung. Du brauchst 
dann also noch mehr Rechenleistung oder es gibt mehr Fehler.

: Bearbeitet durch User
von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Statt

if len(sr) >= 3:

muss da natürlich

while len(sr) >= 3:

stehen.

von Burkhard K. (buks)


Bewertung
0 lesenswert
nicht lesenswert
Manchmal hilft etwas Abstand zum Problem:

1. Die einfachste Heuristik, um Framing-Fehler zu erkennen, schaut auf 
die Dateigröße in Bytes:
    frame_offset = (len(fn) % 4);
    if (frame_offset) {
        remove_initial_bytes_from_file(fn, frame_offset);
    }
Erkennt natürlich nicht alle Fehler, aber den größten Teil - und den 
verbleibenden Rest kann ich manuell bearbeiten. Korrelation und weisses 
Rauschen können in der Schublade bleiben. Merke: "Too much DSP can make 
you short sighted" ;)

2. Das Schreiben einer mehrere MByte großen Datei auf SD kann ein paar 
Sekunden dauern - in dieser Zeit entnimmt der empfangende Prozess keine 
Bytes aus dem Puffer. Abhängig von der gewählten Puffergröße kann es zum 
Overrun kommen. Um den zu vermeiden, muss entweder der Puffer vergrößert 
werden (1 sec entspricht grob 1 MByte) oder aber das Schreiben vom 
Empfang der Daten abgekoppelt werden (eigener Prozess, Datei zunächst im 
RAM erstellen). Werd mal schauen, wie ich das am besten in Python 
abfackele (z.B. SpooledTempFile)

@Gustl - mein Zero ist nicht nur "kopf-" sondern auch "handlos", d.h. 
keine Eingabegeräte. Der Datentransfer wird vom FPGA angestoßen. Die 
Daten kommen dort aus dem RAM. CTS ist FPGAseitig (Nexys4 DDR) ein 
Ausgang, somit eine Flusssteuerung per Hardware damit nicht 
realisierbar. (Habe es auch mit RTS probiert - das funktionierte aus 
irgendwelchen Gründen nicht).

Auf jeden Fall danke für Eure Beiträge.

: Bearbeitet durch User
von Gustl B. (gustl_b)


Bewertung
0 lesenswert
nicht lesenswert
Auch ohne CTS oder Eingabegeräte geht das mit der Anfrage.
Der Raspberry schickt für jede Anfrage ein Byte zum FPGA. In dem Byte 
steht drinnen wie viele Werte das FPGA senden soll. Und dann sendet das 
FPGA die geforderte Anzahl. Dafür braucht man nur RX und TX.

Ja, Schreiben und Lesen kannst du in zwei Threads unterteilen. Oder du 
schreibst jeweils nur wenige Byte auf Karte. Also z. B. 1kByte von UART 
empfangen und sofort auf Karte schreiben. Dann die nächsten 1kByte 
anfordern, der FPGA schickt die und dann schreibt man die weg.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.