Hallo allerseits Ich habe eine neue FPGA Aufgabe gefasst. Ein FFT Core von Xilinx generiert 26-Bit Imaginär- und Realwerte mit 200MHz. Bis jetzt wurde der Leistungsbetrag von 52-Bit auf eine 31-Bit Fliesskomma Zahl umgerechnet. Damit das Gigabit-Lan mit der Datenmenge zurecht kam musste ich die Frames weiter reduzieren. Nun werden aber die Real- und Imaginärwerte benötigt. Die Umrechnung über Fliesskomma geht hier nicht mehr, da die Zahl auf dem PC nicht 100% rekonstruiert werden kann. Gibt es eine Möglichkeit Datenmenge und Busbreite auf dem FPGA zu reduzieren damit das G-Lan wieder nachkommt und die Werte auf dem PC komplett rekonstruiert werden können? Ich habe bis jetzt den GZIP Core von Xilinx angeschaut, aber es scheint als würde dieser nur mit Dateien zurecht kommen. Gruss Patrick
Kommt ganz darauf an wie viel Redundanz deine Daten enthalten. Wenn das eine komplette Gleichverteilung ist, lässt sich da ohne Verluste nichts machen.
Wie groß ist denn der Overhead für die Übertragung? Wie viele Nutzdaten must du denn übertragen?
Mhm, die Daten entsprechen dem Spektrum. Wieviel Redundanz da drinn ist kann ich momentan nicht sagen. Die Übertragung generiert praktisch kein Overhead. Die Daten werden über UDP versendet. Gemäss Hersteller sind 25Msps @ 32Bit möglich (entspricht 800MBit/s Nutzdaten). Für eine simple Antenne reicht es aktuell aus. Leider wollen Sie mehrere Antennen synchron abtasten um ein Beamforming zu erreichen... dadurch wird das Netzwerk weiter ausgelastet und die Datenrate muss entsprechend weiter reduziert werden.
:
Bearbeitet durch User
Patrick B. schrieb: > Mhm, die Daten entsprechen dem Spektrum. Wieviel Redundanz da drinn ist > kann ich momentan nicht sagen. dann schreibe doch mal die Daten in eine Datei und packe sie mal mit verschiedenen Programmen. Es könnte sein, das bei mehre Antennen mehr Redundanzen vorhanden sind. Damit würde ich es mal auf den PC testen. Aber keine Ahnung wie man das in einen FPGA bekommt https://en.wikipedia.org/wiki/LZ4_(compression_algorithm)
Gfs kann man die Daten funktionell noch reduzieren: Die Spiegelspektren wurden schon beseitigt, nehme ich an und Du hast auch geprüft, ob man den Betrag alleine übertragen kann. Oft ist die Phase ja nicht unbedingt relevant. Ansonsten gelten die üblichen Methoden der verlustlosen Datenkompression mit all ihren Nachteilen, u.a. der Latenz die infolge der Datenpakete entstehen, auf die die Kompression angewendet wird. So richtig effektiv wird das mit einer fortgesetzten Differenzbildung, also einem unendlich langem Paket und wachsendem Wörterbuch. Das wird nach hinten raus immer effektiver - allerdings decken viele FFt-Daten irgendwann auch mal allemöglichen Kombinationen ab und es endet im Rauschen.
Patrick B. schrieb: > Leider wollen Sie mehrere Antennen synchron abtasten um ein Beamforming > zu erreichen... Genau an der Stelle entsteht eine Menge Redundanz. Ist aber sicherlich nicht einfach diese raus zu bekommen. Im Idealfall hat man aber ja ein und das gleiche Signal mit entsprechender Verzögerung und bei unendlich feiner Abtastung reichen zwei Elemente um den Rest perfekt zu prädizieren. In Realität würde man dann eben Residual-Codierung machen. Stellt sich jetzt noch die Frage wie groß die Latenz werden darf. Entsprechend kompliziert wäre eine Prädiktion um dann residual coding zu machen. Letztendlich passiert in der Arrayprozessierung aber nicht ohne Grund sehr viel im FPGA. Die enormen, parallen Datenmenge sind perfekt für eine vollständige Prozessierung im FPGA.
Ich kann mir nicht vorstellen, daß gzip u. Konsorten hier geeignet sind. Ich würde mich eher bei den Video-Codecs umschauen. MPEG-4 ALS z.B. ist ein verlustloses Audio-Kompressionsverfahren, das auch mit Gleitkommawerten umgehen kann. Vielleicht gibt's da ja sogar irgendwo was Fertiges ...
Moin, wenn die Spektralwerte nur der Charakterisierung dienen, könntest Du sie auch einfach in einen Quantisierer jagen - analog JPEG, aufgebohrt auf eine höhere Bittiefe. Falls du dabei noch uninteressante Bereiche ausblenden kannst, hast du mit dem nachgeschalteten Huffman-Encoder gleich nochmal etwas "Gewinn", aber ev. musst du die Hufftables auf deine typischen FFT-Daten optimieren (wenn du was wavelet-artiges vorhast). Was darüber hinausgeht, ist für FPGAs nicht gerade kostenlos oder von der Stange zu finden, oder schlicht einfach vom Aufwand her eher für ne CPU geeignet, aber wenn du einen Zynq hast... Generisches ZIP ist für synchrones low-latency-Prozessing eher nicht so geeignet und braucht Speicher, das wird dann schon mal ein Gestöpsel. Gruss, - Strubi
Patrick B. schrieb: > Die Übertragung generiert praktisch kein Overhead. Die Daten werden über > UDP versendet. Wieviele bytes packst du denn in soein UDP Frame? Könntest du eventuell eine Datei mit Beispieldaten hochladen, damit man sich eine passende Komprimirung ausdenken kann?
Die Paketgrösse beträgt 360 Samples @32Bit. Darauf und auf die UDP Kommunikation habe ich leider keinen Einfluss, da dies vom SDR Hersteller definiert ist. Ich packe aktuell bei den Daten auf Bit31 ein Frame-Start Flag zur Synchronisation und die Bits 30-0 enthalten die FFT Werte. Beim Spektrum selber wird auch nur noch der Bereich innerhalb der Anti-Aliasing Filter übertragen. Und selbst da musste ich um Faktor 8 reduzieren. Aktuell versuche ich die Real und Imaginärwerte mit custom Float Zahlen (6 Bits für Exponent und 9 für Mantisse) zu übertragen. So komme ich auf den 32Bit Wert... (plus Framestart Flag). Da wie gewohnt die Zeit drängt, versuche ich einmal mit diesem Ansatz zu einem Resultat zu kommen. Aber es gibt sicher noch bessere Lösungen. Ein Beispiel-Datensatz kann ich noch nachliefern, falls die float-Umrechnereich funktioniert.
Mehrere Antennen liefern ja daselbe Signal, nur etwas phasenverschonben. Ich wuerd als durch kreuzkorrelation die Phase schon im FPGA herausfinden, was ja eigenlich nur einem Delay entspricht. Glaubst du extern die Rechenleistung zu haben um diese Funtionalitaet nachzubilden ? Eher nicht.
Oh D. schrieb: > Mehrere Antennen liefern ja daselbe Signal, nur etwas phasenverschonben. > Ich wuerd als durch kreuzkorrelation die Phase schon im FPGA > herausfinden, was ja eigenlich nur einem Delay entspricht. > > Glaubst du extern die Rechenleistung zu haben um diese Funtionalitaet > nachzubilden ? Eher nicht. Das meinte ich ja letztendlich auch schon, aber das scheint nicht zu gehen, weil: Patrick B. schrieb: > Darauf und auf die UDP > Kommunikation habe ich leider keinen Einfluss, da dies vom SDR > Hersteller definiert ist.
Praktiker schrieb: > Zwei Netzwerkschnittstellen? Brächte hier wohl nur einen Faktor 2 :-) Da wird man wohl um ein Mehr an Prozessierung IM FPGA nicht herumkommen. Ich kenne die Problematik ebenfalls aus einigen Projekten, sowohl was Bildübertragung über UDP, als auch beam forming / Radar angeht. Oh D. schrieb: > Mehrere Antennen liefern ja daselbe Signal, nur etwas phasenverschoben. Das stimmt leider nicht 100%ig. Es gilt streng genommen nur für das Zielsignal und auch dann nur bei symmetrischen Reflektionen. Sobald mehrere Empfänger im Spiel sind gibt es pro Signal eine Werteschar an (mehr oder weniger !) identischen Reflektionen und ungewollte Störungen, die zudem noch durch die Richtcharakteristik der Antennen im Spektrum deformiert sind. Der Denkansatz, das im FPGA zu machen ist aber komplett richtig. Es gibt da mehrere Lösungen, partielle Informationen aus den Signalen herauszuziehen und nur - sagen wir - die komprimierte Info an das übergeordnete System zu übertragen. Aber die Details kann ich hier aus diversen Gründen nicht posten. Es gibt dazu aber auch Einige, das öffentlich publiziert ist. > Ich wuerd als durch kreuzkorrelation die Phase schon im FPGA > herausfinden, was ja eigenlich nur einem Delay entspricht. Ja, aber da müssen die Signale entsprechen aufbereitet werden, um hohe Genauigkeiten zu erzielen, oder man braucht trotz Pulskompression elend lange Integrationszeiten, um die Störungen rauszukriegen. Um das effektiv zu machen, muss man Annahmen über den Spektralverlauf des gesuchten Signals machen und - soweit es sich um aktives Radar handelt - auch entsprechend(es) senden. Ich kann da aus versändlichen Gründen keine Details nennen, aber das Prinzip ist, so zu senden, dass man einfach "empfangen" kann und die Korrelationen zu einfachen, knappen Werten führen, die dann "oben" auf die transformierten Sendeinformationen angewendet werden, um die echten Signalinformationen zu generieren. Führt aber hier jetzt zu weit. In jedem Fall wird man sich funktionell etwas überlegen müssen (da ganz grob gedacht) ein weitgehend ausgelastetes Gigabit Ethernet in der Regel schon erheblich mehr Informationen liefert, als eine handelsübliche CPU-Plattform permanent verarbeiten kann. Die Daten müssen also irgendwie runterprozessiert werden und das im Idealfall dort, wo sie entstehen, also in einer schlauen, denkenden Antenne, die weiß, was die anderen senden, gesendet haben und gerade empfangen, bzw empfangen werden.
Ich würde die Daten nicht per IP/UDP sondern RAW im Ethernet-Frame verschicken. Das geht natürlich nur im lokalen Netz, ist aber von der Übertragungskapazität her gesehen die beste Variante. Ein Ethernet-Frame fasst bis zu 1500 Bytes, bei Jumbo-Frames gehen (je nach Hardware) bis 9000 Bytes.
Da lässt sich aber nicht viel einsparen und kompliziert das Debuggen. UDP ist auch von der Ausnutzung der Bandbreite nicht so weit weg von RAW und ungeachtet dessen muss ohnehin irgendein Protokoll drauf, für das Format. Das wird das Problem nicht lösen. So wie ich die Aufgabe verstehe, muss hier eine Datenkompression von Faktor 3-4 her, um bei der selben Bandbreite zu bleiben, da es "mehrere Antennen" sein sollen.
Bernhard schrieb: > Ich würde die Daten nicht per IP/UDP sondern RAW im Ethernet-Frame > verschicken. um pro Paket 28 Byte (also 1,87 bzw. 0.3 %) Protokoll-Overhead loszuwerden? Das wird's wohl nicht rausreissen ...
Das Anwendungsgebiet umfasst aktuell 3 Bereiche, die ich nicht detailliert kommunizieren darf. Zum Einen soll es aber für den Unterricht des Lehrer für die Beamforming Thematik verwenet werden (wieso auch immer mit solchen Frequenzen und nicht im Audio Bereich). Zum Anderen befinden sich 2 Projekte in der Entwicklungsphase, bei denen die Leute die Optimierung der Alorithmen gerne auf dem PC offline machen möchten. Dann braucht es nicht für jeden neuen Versuch gleich einen Ortswechsel. Aktuell sollen 4-8 Antennen synchron abgetastet und dann eben die Werte auf dem PC weiter verwendet werden. In einer Endversion soll das ganze dann schon im FPGA untergebracht werden (da dort 4 Kanäle direkt verdrahtet sind), aber wenn man für jede Änderung im VHDL/Verilog dann wieder 40min warten kann bis die Synthese durch ist, und sowieso nie alles so schön Programm-mässig debuggen kann ist der PC-Ansatz am Anfang doch besser. Ich habe heute noch erfahren, das die verwendeten SDR auch noch 10G Lan haben. Demnach sehe ich hier immerhin noch etwas Reserve.
:
Bearbeitet durch User
Es bleibt trotzdem bei der Thematik, dass das im PC nicht zu verarbeiten ist - auch nicht per 10GB. Also geht nur offline und dann ist die Transferrate egal. Dein Lehrer müsste da eigentlich drauf gekommen sein, eine solche reine Evaluierung von SV-Algorithmen im PC mit einfach einem limitierten Datenbestand durchzuführen. Auch sonst, werden neue Algorithmen, Matcher und Follower offline in MATLAB mit gesampelten Daten getestet und dies sogar immer mit denselben, bis die Algos final stehen. Daneben werden sogar generische Daten und real time Simulatoren genutzt. Erst dann geht es in die Hardware. Es würde also vollkommen reichen, einen snapshot einiger ms zu empfangen und diese langsam in den PC zu überspielen. Dafür reicht dann sogar USB 2.0. :-)
:
Bearbeitet durch User
Jürgen S. schrieb: > Es bleibt trotzdem bei der Thematik, dass das im PC nicht zu verarbeiten > ist - auch nicht per 10GB. 10 GBit/s lassen sich problemlos verlustfrei in den RAM schaufeln. BTDT. Aber verarbeitet (im Sinne von signal processing) ist da noch nix, das ist richtig. > Auch sonst, werden neue Algorithmen, Matcher und Follower offline in > MATLAB mit gesampelten Daten getestet und dies sogar immer mit > denselben, bis die Algos final stehen. Daneben werden sogar generische > Daten und real time Simulatoren genutzt. Erst dann geht es in die > Hardware. Das wäre auch mein Ansatz. Erst wenn der Algorithmus was taugt, kann er auf FPGA-Technologie umgesetzt werden. Duke
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.