RP - SDR mit kurzer Latenzzeit ??

Hallo Uli,

[off topic]ich dachte gerade bei deiner gewählten Schreibweise von Red-Pitaya an eine exotische Frucht![/off topic]

Und lese weiter fröhlich mit

Hallo Uli,

vielleicht noch etwas sachliches aus meiner Nutzung des PMSDR Empfängers.
Alle damals aufgetretenen technischen Probleme wie USB Einströmung, Masse-Schleife und Softwarebedienung sind Geschichte, was aber bleibt, ist das Problem der RX/TX Verzögerung.

Der PMSDR, schaltet die Antenne zwischen PMSDR und TRX um und es ist das erweiterte Band Filterboard eingebaut.
Als ADC-Wandler nutze ich einen älternen PC: einem Intel 478, 2x 2,6GHz 4GByte Ram, SSD Drive, low noice Netzteil und eine PCI Soundkarte mit max. 96kHz Abtastrate. Die interne Soundkarte "rauscht" etwas mehr.

Fazit: bei dieser PC dreht es sich nur das Dekodieren der I/Q Signale, dazu benötigt er ~2% Systemlast, aber damit kann ich keinen vernünftigen SSB Funkbetrieb machen. Die anderen Sprechen schon, wenn der PC/ PMSDR noch dekodiert und die Antenne umschaltet.
Als Kontrollempfänger ist der PMSDR ein super Gerät bedingt durch seine scharften analogen Filter vor dem Empfänger.
Früher Mischprodukte <= 1,5MHz vom MW-Sendern treten nicht mehr auf.

Link
[1] http://www.iw3aut.altervista.org/index_de.htm

Zitat von dl1sdz

Nach meiner Einschätzung ist die Elecraftloesung 192 kHz stimmiger und sehr viel einfacher zu lösen.

Ohne jetzt einen Glaubenskrieg: Direkt-Sampling versus Schaltmischer-Downconversion/Quadratur-Sampling-Decoder entfachen zu wollen: Es spricht m. E. Überzeugendes für das Direktsampling Prinzip.

Beim QSD hängt die Image Unterdrückung des Empfängers in beträchtlichem Umfang von der Amplituden- und Phasen-Symmetrie des I und Q Decoders und der analogen Sample and Hold Zweige ab. Bauteiltoleranzen, Temperaturdrift und frequenzabhängige Unsymmetrien setzen eine natürliche Grenze, die auch durch Softwareausgleich nur bedingt kompensiert werden kann. Diese Probleme treten systembedingt beim Direktsampler nicht auf. Eingangsbandfilter brauche ich bei Beiden, also wären auch dadurch entstehende "Probleme" vergleichbar.

Die Industrie hat sich sowieso schon entschieden. Anton hin oder her: Der Verdienst des IC-7300 ist es, erstmals einen passablen Direktsampler mit allem SchiSchi in der Einsteiger-Preisklasse verwirktlicht zu haben. Da kommt sicher bald noch mehr.

73
Günter

Hallo Hajo ....
das mit dem Overkill habe ich nicht ganz verstanden ....
Was meinst du damit? Welche Probleme machen schmale Bandfilter?

73's Joe

....es ist ja sehr schön, wenn SDR-Technologie in die breite Diskussion und vielleicht auch Anwendung kommt.
Das ist lange überfällig. Aber bitte etwas weniger emotional und ein bisschen realistischer.

Inzwischen dürfte sich herum gesprochen haben, dass Konzepte auf der Basis eines Mischvorgangs
in die Audioebene nicht der Weisheit letzter Schluß sind. Vor allem bei Signalen in Oszillatornähe haben
manche Empfänger so Ihre Probleme. Vom vorhandenen Spiegelfrequenzempfang mal ganz abgesehen.
Diesen gibt es nämlich auch beim Senden. Und eine Abstrahlung des Oszillators ist auch gegeben.
Entstanden ist das alles, weil (damals) AD-Wandler auf Soundkarten preiswert vorhanden waren.

Vor dem Entwickler des mcHF-Bausatzes ziehe ich trotzdem ob dieser reifen Leistung meinen Hut.
Toller Bausatz, guter Einsatz von SMD, bestechende Größe und saubere Platinen.
Und eine dazu passende Software. Es verwundert nicht, wenn ganze OVs sich in dieses
Bastelabenteuer stürzen und dabei viel Spass haben. Gut so.
Ich möchte trotzdem keinen. Warum ?
Weil ich von Beginn an, sobald verfügbar, direktsampelnde HPSDR-Technologie benutzt habe.
Und der inzwischen dank der Arbeit von Pavel Demin HPSDR-kompatible Red Pitaya Sampler hat doch
offensichtlich deshalb in kürzester Zeit so viele Freunde gefunden, weil es auch ein direktsampelndes,
noch dazu preiswertes Gerät, nutzbar mit einer außerordentlich leistungsfähigen Software, ist.
Die es noch dazu gratis gibt. Das ist keineswegs selbstverständlich.
Auch wenn dem Wandler gegenüber anderen Konzepten 2 Bit fehlen, ist der RP durchaus brauchbar.

Zum Glück werden die stark emotionsgeladenen Berichte zu dem IC7300 nunmehr etwas sachlicher und korrekter.
Kritisch scheint mir der von DF9IC beobachtete Rauschsockel beim Sender zu sein.
Da besteht wohl tatsächlich Bedarf zur Nachbesserung.

Eine AD-Wandlerkennlinie ist irgendwann zu Ende. Bei der weit verbreiteten HPSDR_Platine "HERMES"
sind das in der gewählten Schaltung ca- -15 dBm. Wenn diese Werte an großen Antennen erreicht werden,
hilft nur Selektion oder ein Abschwächer. Aber, ist das was Neues oder Überraschendes ?
Die im Zusammenhang mit dem IC7300 geäußerte Beobachtung, der RX ist ja bei -10dBm übersteuert,
verwundert (mich) nicht. Leute, geht's noch ? -10 dBm entsprechen S9 +63 db ! Braucht das wer ?
Wie man der Literatur entnehmen kann, haben AD-Wandler im Eingang eines Empfängers eher ihre Probleme bei
kleinen Signalen. Daher kennt PowerSDR eine Funktion Dithering. In Verbindung mit dem AD-Wandler wird
künstlich Rauschen erzeugt, damit der Wandler was zu tun hat. Der Rauschsockel steigt dabei natürlich an, was
für praktische Kurzwellenbelange aber ohne Bedeutung ist.

Wenn man sich mal mit der grundsätzlichen Funktion der Signalverabreitung in einem SDR befasst, wird klar,
dass der arg strapazierte Begriff Latenz maßgeblich von der Laufzeit in den gewählten Filtern bestimmt wird.
Hierbei gibt es entweder steile Flanken oder geringe Laufzeit. Beides zusammen geht nicht.
Wiederum PowerSDR bietet eine Einstellung diesbezüglich. In der Grundeinstellung beträgt die Verzögerung
ca. 150 ms, siehe Bild. Mit den Filtern kann man dann spielen.
Latenz ist also keine Frage des Misch- oder Samplekonzeptes sondern wird wesentlich von den gewählten
(programmierten) Filtern und deren Güte bestimmt. Laufzeiten im Bereich etlicher Dutzend Millisekunden
sind leider einer der immer noch vorhandenen Nachteile digitaler Signalverarbeitung.
Demgegenüber stehen aber Funktionen und Eigenschaften , die sich in Hardware nicht realisieren lassen.
Alle aufzuzählen, geht hier nicht, ich denke nur an eine exakte Pegelmessung im Empfänger,
beginnend beim Rauschsockel bis eben S9+63. Derartig lineare Anzeigen lassen sich analog nicht bauen.
Es gibt einen Sender, der sich durch eine extreme Linearität auszeichnet. usw. usw...
Wer einmal den von einem DA-Wandler erzeugte Zweiton gesehen hat, dessen Ehrgeiz zum Bau linearer
Verstärker wird (hoffentlich geweckt).
Ich zeige immer wieder gern den DDS-Zweiton, empfangen von einer Hermes-Platine. Und ein Sendesignal von
der Platine Hermes auf 10m mit 300mW.
Auch wenn es dem Einen oder Anderen (noch) nicht gefällt, digitale Signalverarbeitung ist die Zukunft.
Spannende Sache...ach ja, Äpfel schmecken doch anders als Birnen....

73
Andreas

Zitat von dl5cn

....es ist ja sehr schön, wenn SDR-Technologie in die breite Diskussion und vielleicht auch Anwendung kommt. Das ist lange überfällig. Aber bitte etwas weniger emotional und ein bisschen realistischer.

Nun ich finde, dass hier in Forum die Diskussion eher sachlich und wenig emotional geführt wird.

Zum Thema Grossignalverhalten von SDR ist übrigens schon 2006 im QEX Magazin ein beachtenswerter Artikel von SM5BSZ erschienen, der viel Erhellendes zur derzeit laufenden Diskussion beiträgt (pdf):
"IMD in Digital Receivers - Performance limitations of receivers with the A/D converter at the antenna — how to measure and work around them"

73
Günter

Hallo zusammen,

@ Günter ich finde auch, dass hier wohl die Emotionen eher in den Hintergrund getreten sind ...
@ Hajo ich wollte nur noch mal nachfragen, hätte sein können dass ich etwas überlesen hatte .. aber nun ist es klar ....

Wir bleiben am Ball es wird spannend ...

73#s Joe

Hallo OM´s!

Also ich finde die Diskussionen / Fragestellungen und Antworten hier ganz spannend.
Bin von der Anschaffung eines RP geradezu hin und hergerissen - noch hab ich ihn nicht.
Eine kleine 10 Watt PA liegt hier auch noch bei mir rum und dann könnte es losgehen.
Mal schauen...

Werde die Ausführungen um SDR mit / ohne RP weiter verfolgen. Gefällt mir als Nichttechnicker.

VY 73 de Peter

Hallo,

ich verfolge dieser Diskussion auch schon länger mit Interesse. Um das Ganze mal etwas systematisch anzugehen, habe ich mich gefragt, wo denn überhaupt die Latenzzeiten entstehen. Dabei muss man meiner Meinung nach die unterschiedlichen Stufen betrachten:

1. Aufnehmen der Frequenz und auf I/Q Signal runter Mischen und Filtern (wird in manchen SDR Lösungen noch Analog gemacht)
2. I/Q Signal auswerten, Dekodieren und Filtern (Audio Signal)

Falls man auch noch Senden möchte :

3. Tastsignal/Audio Erfassen, Filtern und in I/Q Umsetzen
4. I/Q Hochmischen, Filtern und digitalisieren.

Alle 4 Punkte zusammen bestimmen dann die Zeit, die benötigt wird, um auf einen Anruf zu reagieren. Hier in der Diskussion wurde, glaube ich, hauptsächlich auf die Schritte 1 und 2 geachtet.

Betrachten wir jetzt den RP, besteht der aus 2 Teilen:
1. FPGA mit DSP Blöcken für HF Mischen und auf I/Q umsetzen
2. CPU mit ARM9 Rechner und einer SDR Software.

Zu 1. Der FPGA Block ist mit 125MHz getacktet: d.h. jeder Takt braucht 8ns , d.h. für 1ms könnten 125k Schritte umgesetzt werden. Bei max. 80 DSP Stufen und 17,6k LTU's wird die Umsetzung in I/Q somit vermutlich keine 1ms brauchen, da so viele Ressourcen nicht auf dem Chip verbaut sind. Selbst, wenn die DSP Stufen vielleicht 10 Schritte benötigen würden (habe ich nicht nachgeschlagen).

Zu 2. Hier hat man vermutlich die gleiche Verzögerung, wie man sie auch im externen PC haben wird. Ein I/Q und Audio DSP ist da natürlich schneller (siehe viele Empfänger mit DSP , z.B. KX3.

Hier mal ein paar Literaturstellen zum Nachlesen der Verzögerungszeiten (interessant ist die Abhängigkeit vom Audio-Filter, wo sie gemessen wurde):
http://www.lz1aq.signacor.com/…Delays_in_Several_SDR.htm
http://www.n1kdo.com/sdr-delay-measured/
https://www.elektormagazine.co…ad/files/EN2014120381.pdf
http://academic.csuohio.edu/yuc/papers/PID2932179.pdf

Meine Schlussfolgerung: Wenn man auf dem RP auch noch einen DSP für I/Q Verarbeitung und Audio implementieren würde, könnte man auch auf Zeiten kommen, wie der KX3 oder K3 vormachen und hätte nicht Zeiten von mehren 100ms für die Signalverarbeitung.

Die Frage an Experten für den FPGA auf dem RP:
Kann man ggf. den FPGA mit mehreren Taktgeschwindigkeiten betreiben und die I/Q Verarbeitung sowie Audi-Verarbeitung auch auf dem FPGA bringen? Dann müsste die CPU nur noch die Audio-Daten auf USB für die Soundkarte umsetzen. Es kann aber sein, dass der FPGA einfach nicht genug DSP Stufen enthält.

vy 73 de Karsten, DD1KT

Hallo Karsten ....
es gibt eine Lösung vom Pavel, die die Verarbeitung bis zur Audio-Ausgabe auf der integrierten ARM-CPU macht. Das macht dann GNU-Radio, genau so wie du das beschrieben hast.
Aber um Filter darzustellen sind letztendlich mehere Multuiplikationen und auch Additionen nötig. Wobei Multiplikationen rechentechnisch auf mehere Additionen zurückgeführt werden.
Die ARM-CPU kann nur eine Adition pro Takt und Kern ausführen.
Du sprachst die herkömmlichen TRX'e mit ZF-DSP an. (auch der K3)
Diese verwenden spezielle DSP-Prozessoren, die mehere Operationen pro Takt parallel verarbeiten.
Ich hoffe, dass ich den DF5SF, Ulli richtig verstehe. Seine Intension die Latenzzeiten zu verringern, ist der CW Betrieb.
Das ist auch der Grund für meine persönlichen Untersuchungen.
Da sieht das dann etwas einfacher aus.
Karsten, das erklärt dann auch, warum deine Punkte 3 und 4 gar nicht zutreffen.
Zu dem RP bin ich wegen der inzwischen preislich erschwinglichen Hardware gekommen. Nun gilt es das Handwerkzeug zu erwerben und zu erlernen, um die Hardware entpsrechend den Bedürfnissen anzupassen.
Soll heissen lernen, wie man eine DSP programmieren kann und auch einem FPGA die erforderliche Strucktur verpasst.
Für mich ist also die Lösung RP und dedizierte DSP.
Übrigens auch die HP-SDR Community denkt über solche Lösungen nach. (z.B. Video DSP-Prozessor, der unter LINUX programmiert werden kann.

Für CW kann man dann aber auch noch ein anderes TRX-Modell programmieren um die Latenzzeiten zu verringern.

Also Dank des RP einfach eine neue Software starten und man hat einen SSB-TRX, ein Messgerät, usw. usw. oder eben auch einen CW TRX.

Na bis dann gibt es noch viel zu tun und zu lernen ... aber es macht Spass ...

73'S Joe

Hallo Joe,

Zitat von DM4EE

ber um Filter darzustellen sind letztendlich mehere Multuiplikationen und auch Additionen nötig. Wobei Multiplikationen rechentechnisch auf mehere Additionen zurückgeführt werden.
Die ARM-CPU kann nur eine Adition pro Takt und Kern ausführen.

Der Vorteil von den im RP FPGA integrierten DSP Slices ist, dass die Multiplikationen in Hardware implementiert haben (aus Beschreibung des FPGAs):

Digital Signal Processing — DSP Slice
Some highlights of the DSP functionality include:
• 25 × 18 two's complement multiplier/accumulator high-resolution (48 bit) signal processor
• Power saving pre-adder to optimize symmetrical filter applications
• Advanced features: optional pipelining, optional ALU, and dedicated buses for cascading

Auch die Cortex ARM9 Prozessoren haben schon "double precision floating point units" mit denen eine normale Mulitplikation als ein Befehl ausgeführt werden kann. Sonst könnten die Filter selbst mit guter C-Programmierung nicht gerechnet werden.

Aber im Prozessor läuft, wie Du es beschrieben hast alles seriell, während so ein FPGA so konfiguriert werden kann, dass die DSP Slices Parallel arbeiten.

Wenn Pavel es schafft, Multiband Empfänger mit dem FPGA zu konfigurieren, dann könnten noch einige DSP slices frei sein, wenn nur ein Kanal empfangen wird. Diese dann langsamer getaktet könnten als Audi DSP und zur I/Q Signalverarbeitung verwendet werden.

Hier ist die Frage, ob sich da schon jemand mit befasst hat?

Zur CW Sende - Tastung: Bis jetzt habe ich nur davon gehört, das bei (PC-)SDRs CW über I/Q SIgnale erzeugt wird und nicht direkt im Sendeteil. Das könnte man natürlich im RP-FPGA anders lösen und den Oszillator mit Frequenzshift direkt tasten. Wurde das schon einmal so implementiert? Das Problem wäre, das dann auch die Anstiegs und Abfallzeiten entsprechend im FPGA implementiert werden müssten, sonst wäre das Signal zu breitbandig.

Also bis jetzt sind die Stufen 3 und 4 in der Verzögerung nach meinen Erkenntnissen mit zu berücksichtigen.

vy73 de Karsten, DD1KT

Hallo Karsten ...
CW tasten schon, im FPGA aber nicht mit Frequenzschift ... sondern auf der Endfrequenz .... natürlich mit als Variablen konfigurierbaren Ein- und Ausgangsverzögerungen,
um kein Rechtecksignal zu erzeugen.
Wäre toll, wenn es ginge mit geringer Latenzzeit sehr schmale Filter im FPGA zu implementieren.
Bei den WSP Empfängern kommt es nicht auf die Latenzzeit an.
Ich hoffe ja noch einen Mitstzreiter zu finden, der sich ausser mir auch damit befassen möchte.
Ich muss mir erst mal die Grundlagen aneignen. Das kann also noch was dauern, bis erste Ergebnisse vorliegen.

73's Joe

Hallo Uli,

danke für den Hinweis auf die Latenzzeit. Darauf hatte ich gewartet..

73 Herbert, DF7DJ