Forum: HF, Funk und Felder DiscoRedTRX - Ein SDR Transceiver aus Baugruppen


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 DH1AKF W. (wolfgang_kiefer) Benutzerseite


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Kann man in der heutigen Zeit noch einen vollwertigen Kurzwellen- 
Transceiver selber bauen? Wenn ja: Lohnt sich das?
Meine Antwort heißt Ja. Und es macht Spaß, eigene Ideen zu 
verwirklichen.
Der Beitrag im folgenden Link wird ständig aktualisiert, er zeigt den 
Werdegang des Gerätes.

http://www.wkiefer.de/x28/Red%20Pitaya.htm

Viel Spaß beim Anschauen (und Selbermachen).

Hier noch ein Link zu anderen Red Pitaya Anwendern und deren 
Ergebnissen:
http://forum.cq-nrw.de/

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ich fand zwar das Grün auf Rot deines Bildes da oben erstmal
augenkrebsverdächtig :), aber das, was du auf deiner Webseite
zusammengestellt hast, auf jeden Fall interessant!

Der mcHF hat ja auch den Anspruch, ein moderner Eigenbau-TRX zu sein,
aber die Verwendung von fertigen Baugruppen macht den Aufwand natürlich
deutlich überschaubarer.

Ich ärgere mich nach wie vor, dass ich in dem relativ langweilig
rübergekommen Fach namens „Systemanalyse“ im Studium damals nicht so
recht einen Stich gesehen habe.  Wenn mir damals einer gesagt hätte,
dass ich das Zeug mal für digitale Signalverarbeitung benötigen würde,
hätte ich mich vielleicht mehr drum bemüht. ;-)

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
DH1AKF K. schrieb:
> Kann man in der heutigen Zeit noch einen vollwertigen Kurzwellen-
> Transceiver selber bauen?

Eine ähnliche Frage treibt mich schon seit Jahren um, allerdings geht es 
mir eher um Empfänger und um Frequenzen >30 MHz.

Soweit ich das grad sehe, war dein Teil die Bedienoberfläche per 
STM32F-Discovery-board und nicht die eigentliche Musike, die im 
Pitaya-Board abgeht. Hmm.. mir gehen eher die Probleme der eigentlichen 
Signalverarbeitung durch den Kopf. Das Glück, das Jörg hätte gehabt 
haben können... hatte ich nicht. Bei meinem Mathestudium war digitale 
Signalverarbeitung überhaupt kein Thema. Gab's damals noch nicht an der 
Uni. Aber genau DAS ist m.E. der eigentliche Knackpunkt am Eigenbau. Mal 
ne Frage: Wie macht ihr denn das derzeit mit dem SSB-dekodieren? 1x0° 
und einmal 90° per Hilbert oder 2x 45°? Für letzteres suche ich nämlich 
immer noch nach einer praktikablen Lösung.

W.S.

von DH1AKF W. (wolfgang_kiefer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Wie macht ihr denn das derzeit mit dem SSB-dekodieren? 1x0°
> und einmal 90° per Hilbert oder 2x 45°? Für letzteres suche ich nämlich
> immer noch nach einer praktikablen Lösung.

Hallo W.S., ich habe mal ein paar Schnipsel herausgesucht, die Deine 
Frage beantworten.

Hier erst mal eine Grafik von Pavel Demin:
http://pavel-demin.github.io/red-pitaya-notes/img/sdr-transceiver-hpsdr-ddc.png

Wie man sieht, wird hier die komplexe Multiplikation verwendet.
Die I/Q- Komponenten der Generatoren entstehen sozusagen "von selbst", 
ohne Phasenschieber oder Ähnliches. Das ist mit VHDL oder Verilog kein 
Problem. Hier noch eine Erklärung, warum der Cordic- Algorithmus nicht 
verwendet wird:

http://forum.redpitaya.com/viewtopic.php?f=11&t=265&p=2260&hilit=cordic#p2260

Höhere Frequenzen kann man durch Ausnutzung der höheren Nyquist- Ebenen 
nutzen. Das habe ich z.B. bei einer Gruppe an der FHS Jena gesehen. 
(GHz- Funk). Dort wird ebenfalls ein FPGA verwendet, allerdings benötigt 
man Vorselektion und LNA.

Die eigentliche Demodulation findet nicht im FPGA, sondern im 
Prozessor-Teil des Schaltkreises statt. Dort läuft Debian Linux, es wird 
die Library WDSP verwendet.

: Bearbeitet durch User
von manuel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Für die SSB Dekodierung in einem SDR scheint sich (neben den Hilbert 
Filtern) wohl auch die Weaver Schaltung ganz gut zu eignen.

http://www.hanssummers.com/weaver.html

http://www.panoradio-sdr.de/ssb-demodulation/

Mfg

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
DH1AKF K. schrieb:
> Die I/Q- Komponenten der Generatoren entstehen sozusagen "von selbst",
> ohne Phasenschieber oder Ähnliches.

Da hast du mich aber gründlichst mißverstanden.

Also:
Daß man das Superhetprinzip anwenden muß, um Frequenzwahl und Selektion 
voneinander trennen zu können, ist ja klar. Daß man das bei digitaler 
Signalverarbeitung per I/Q-Mischer tut, ist ebenfalls kar.

Dann hat man halt I und Q. Bei ddem Bild in deinem Link wird das 
schlichtweg herunterdezimiert, aber selbst nicht verarbeitet.

So - und nun kommen wir zum eigentlichen Thema von mir: Man will 
natürlich zweierlei:
1. ein Bandfilter, um die eigentliche Selektion zu bewerkstelligen. Das 
hab ich im Griff - aber eben noch OHNE Phasendrehung.
2. einen Demodulator. Für AM und FM geht das ganz prächtig mit einem 
Cordic, der aus den kartesischen Koordinaten I und Q eben die 
Polarkoordinaten Zeigerlänge und Winkel macht. Zeigerlänge-->AM, Winkel, 
davon 1. Ableitung-->FM. Den Kram hab ich ebenfalls soweit im Griff.

Für AM und FM wird dabei auf Signalmitte abgestimmt - soweit auch klaro.

Für SSB hingegen muß man das unerwünschte Seitenband entfernen. Entweder 
wie Manuel schon schrieb per "weaver", was einfach gesagt so geht, daß 
man auf Signalmitte abstimmt, dann I und Q tiefpaßfiltert und dann 
nochmal per Software-I/Q-Mischer und Frequenz = Mitte Durchlaßband 
abmischt, dann wie üblich addiert oder subtrahiert, je nach gewünschtem 
Seitenband.

Aber: die Weaver-Methode macht mir Bauchschmerzen, eben wegen des 
LO-Durchschlages, den man eigentlich NIE vermeiden kann und wegen des 
ominösen 1/f-Rauschens.

Die klassische Methode besteht darin, neben das Signal abzustimmen und 
dann dem gefilterten I/Q-Signal eine weitere 90° Phasendrehung zu 
verpassen, anschließend wieder addieren oder subtrahieren.

Das 90° Drehen kann man auf verschiedene Weise tun:
1. mit nachgeschaltetem Hilbert. Kostet eigentlich sinnlose Rechenzeit
2. mit unterschiedlich gerechneten Taps: ein Signal wird per 
spiegelsymmetrischem Filterkernel gefiltert, das andere per 
punktsymmetrischem Filterkernel. Wie man die punktsymmetrischen Taps 
ausrechnet (ausgehend von einem sin(x)/x Filter), DAS WEISS ICH DERZEIT 
NOCH NICHT.
3. mit zwei prinzipiell gleichen Filterkerneln (einer davon gespiegelt), 
die jeweils zusammen mit dem eigentlichen Bandfilter eine Phasendrehung 
von 45° machen. Das wäre mein Favorit, aber auch DAS habe ich derzeit 
noch nicht drauf.

Ich weiß, daß es geht, also daß man einen FIR-Bandpaß machen kann, der 
wahlweise +45° oder -45° im Durchlaßbereich dreht. Die sogen. 
Hilbert-Filter von IOWA-Hills spucken einem bei Bedarf die fertigen 
Filterkernel aus. Aber solche Fastfood will ich nicht. Ich will's selber 
im µC berechnen. Grund: daß man per Knopf am Gerät sich seine Bandbreite 
und seine Passband-Shift einstellen kann. Obendrein braucht man sowas 
auch, um Ungenauigkeiten bei analogen I/Q-Mischern ein wenig 
auszugleichen. Für VHF und UHF ist ja ohnehin Analog im Frontend 
angesagt.

So, jetzt verstehst du meine Frage, wie ihr das mit dem SSB-Dekodieren 
macht. OK, du benutzt ne fertige Lib und Linux und bist zufrieden damit. 
Das ist ne andere Zielrichtung als meine. Ich will's verstehen wie es 
tatsächlich geht, um es anschließend in einen Cortex M4F oder M7 zu 
stopfen. Und solange ich das nicht gelöst habe, ist meine Laune unter 
Null. Mir fällt dabei eine laxe Bemerkung ein, die vor einigen Jahren 
einer der FA-Redakteure auf deren Stand bei der Hamrad abgelassen hatte: 
"wer programmiert denn schon noch selbst, wo man es doch downloaden 
kann?" - seitdem hab ich ne Allergie auf jede Art Schlaraffenland-Denke.

W.S.

von DH1AKF W. (wolfgang_kiefer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo W.S. !
Falls es Deine Zeit (und Dein Interesse) erlauben: hier ist der Link zur 
WDSP- Library.
https://github.com/g0orx/wdsp
Es wäre (auch für mich) eine große Hilfe, wenn man den einzelnen Dateien 
ihre Funktion zuordnen könnte.
Jedenfalls ist hier die gesamte Signalverarbeitung ab (nach) dem FPGA- 
Teil enthalten.

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Zitat:
1
#include "comm.h"
2
3
void calc_bandpass (BANDPASS a)
4
{
5
  double* impulse;
6
  a->infilt = (double *)malloc0(2 * a->size * sizeof(complex));
7
  a->product = (double *)malloc0(2 * a->size * sizeof(complex));
8
impulse = fir_bandpass(a->size + 1, a->f_low, a->f_high, a->samplerate, a->wintype, 1, 1.0 / (double)(2 * a->size));
9
....
So: der eigentliche Job wird von fir_bandpass(...) erledigt.

Es ist wie immer bei den Linuxern: Ein Haufen Kruscht, keinerlei 
Kommentare, und comm.h heißt soviel wie "hier kommen 99 includes daher" 
- natürlich auch ohne jeglichen Kommentar. Selbst die Funktionsnamen 
sind so spärlich wie immer. Irgend eine lesbare Doku gibt es 
selbstverständlich auch nicht.

Ehe ich mich da durchegwühlt habe, bin ich mit nem Herzinfarkt verreckt.

W.S.

von Löter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Aber: die Weaver-Methode macht mir Bauchschmerzen, eben wegen des
> LO-Durchschlages, den man eigentlich NIE vermeiden kann und wegen des
> ominösen 1/f-Rauschens.

Das macht man doch heute digital. Da ist ein Mischer nur ein 
Multiplizierer. Da gibt's kein 1/f Rauschen und auch keinen LO 
Durchschlag.

Diese Hilbertgeschichten mit +-45° sind auch interessant. Das Problem 
dürfte aber sein, auf der ganzen Bandbreite eine exakte 
Phasenverschiebung zu erreichen, ohne die kann man nämlich die SSB 
Unterdrückung gleich in die Tonne treten.

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Löter schrieb:
> Das macht man doch heute digital. Da ist ein Mischer nur ein
> Multiplizierer. Da gibt's kein 1/f Rauschen und auch keinen LO
> Durchschlag.

Das macht man nur dann digital, wenn man sich auf die KW beschränkt oder 
für 2 Meter per Bandpaß vor dem ADC NUR die Alias hereinläßt, und wie 
der TO erstmal alles durch den ADC jagt.

Aber woanders (geht schon auf 70cm los) ist Schluß mit direkter 
AD-Wandlung, da muß nach wie vor ein analoges Frontend her.

Und was mir beim Lesen diverser Literatur dazu aufgefallen ist, soll es 
angeblich auch im rein Digitalen eine Entsprechung zum 1/f Rauschen 
geben - habe aber genau DAZU bislang weder eine Verifizierung noch eine 
Widerlegung gefunden. Deshalb bin ich erstmal vorsichtig damit.

W.S.

von Löter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mein Vorschlag für 70cm: Zuerst mit einer einfachen Mischerstufe nach 
unten (auf eine ZF) mischen, dann dort digitalisieren und die 
Seitenbandunterdrückung digital machen.

W.S. schrieb:
> Löter schrieb:
> Und was mir beim Lesen diverser Literatur dazu aufgefallen ist, soll es
> angeblich auch im rein Digitalen eine Entsprechung zum 1/f Rauschen
> geben - habe aber genau DAZU bislang weder eine Verifizierung noch eine
> Widerlegung gefunden. Deshalb bin ich erstmal vorsichtig damit.

Welche Literatur soll denn das gewesen sein?

1/f Rauschen beruht doch auf analogen Effekten, digitale Signale haben 
höchstens ein Quantisierungsrauschen. Und das kriegst du mit großen 
Bitbreiten klein.

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Löter schrieb:
> Mein Vorschlag für 70cm: Zuerst mit einer einfachen Mischerstufe nach
> unten (auf eine ZF) mischen, dann dort digitalisieren und die
> Seitenbandunterdrückung digital machen.

Oh mann, klasse Vorschlag. Hast du dir den auch wirklich gut überlegt?

Kopfschüttel...

W.S.

von Löter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hm, keine Ahnung wo das Problem liegt.

Willste deine SSB Dekodierung jetzt analog oder digital machen?
Wenn analog, dann nimm halt nen Superhet mit SSB Filter oder nen 
Direktmischer mit Hilbert und wenn digital eben den Weaver.

Das ist doch mittlerweile alles Kinderkacke...

von DH1AKF W. (wolfgang_kiefer) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Hallo W.S. und Löter,
wäre es nicht sinnvoll, Euer Geplänkel in einem eigenen Thread 
auszutragen?
Hier geht es erst einmal um Kurzwelle, Selbstbau in Verbindung mit der 
Red Pitaya- Baugruppe.
Wenn Ihr dazu Fragen, oder etwas beizutragen habt, dann bitte sehr!

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
DH1AKF K. schrieb:
> Hallo..

Danke - genau das mußte jetzt mal gesagt werden.

Hättest du es nicht getan, dann hätte ich's jetzt geschrieben. 
Schließlich geht es um dein Projekt.

Meine Anfrage an dich wegen der SSB-Details hat sich mit deiner Antwort 
erledigt. Du hast ja vornehmlich mit der mechanischen Konstruktion und 
dem Bildschirm-Menü zu tun, bist also derzeit nicht tief drin in der 
eigentlichen Signalverarbeitung. Schätze mal ab: kommt das noch im 
Detail oder reicht dir das Linux mit der WDSP-Bibliothek so wie es ist 
aus? Ich werd mal nen tieferen Blick da hinein werfen - mal sehen, was 
mich da angrinsen wird.

W.S.

von DH1AKF W. (wolfgang_kiefer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo W.S. und Mitleser,
da ich mich in den letzten Tagen wieder einmal am Thema "Morsedecoder" 
festgebissen habe, wird es demnächst, wie schon damals im Thread
Beitrag "Re: Morse- Decoder mit PSoC"
um die Decodierung der Morsezeichen gehen.
Was schon funktioniert, ist das normgerechte Senden von Morsezeichen, 
auch von Touchscreen- Tastatur aus, auch mit vorgefertigten 
Textkonserven.
Die umgekehrte Aufgabe ist weitaus schwieriger zu lösen.
Bisher gibt es noch keinen NF- Pfad zwischen Audio- Codec und der STM- 
Baugruppe. Statt dessen versuche ich, die im 10 kHz- Takt vom Red Pitaya 
gelieferten Werte der Signalstärke auszuwerten.
Entstanden ist dabei ein Hilfsprogramm, welches die gemessene Dauer der 
Signal- und Pausenzeiten sammelt und in einer Tabelle mit 14 geometrisch 
gestaffelten Zeitintervallen einträgt.
Also 5 7 10 14 20 28 40 56 usw. (Zeiten in Millisek.)
Die gemessene Häufigkeit soll dann zur Unterscheidung von Punkten und 
Strichen, von Pausen innerhalb bzw. zwischen Zeichen dienen.
Wichtig ist auch die Unterscheidung zwischen Rauschen und empfangenen 
Morsezeichen (Stichwort: digitale Rauschsperre).
Ist diese Zuordnung einmal bekannt, dann erfolgt die Decodierung ohne 
größere Probleme. Dazu dient eine Tabelle, welche sofort den gesendeten 
Buchstaben ausgibt, wenn man das (codierte) Zeichen als Index (also als 
Platznummer) eingibt.
                Morsecode Codierung
Beispiele: E -> .      ->  10 (binär)
           T -> -      ->  11
           I -> ..     ->  100
           A -> .-     ->  101
           M -> --     ->  111
           9 -> ----.  ->  111110

Mit dieser Codierung bekommt man jedes Morsezeichen in einem Byte unter, 
(außer der Irrung ........), die wäre dann 9 Bit lang:  100000000

Das linke (höchstwertige) Bit ist das Startbit, es wird benötigt um z.B. 
zwischen . und .. unterscheiden zu können.

Danke für Eure Geduld, bis hier mitgelesen zu haben.
Wolfgang

von Abdul K. (ehydra) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Das ist eigentlich das gleiche Problem wie bei der Dekodierung von 
DCF77. Eventuell kannst du da gut abkupfern gehen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Abdul K. schrieb:
> Das ist eigentlich das gleiche Problem wie bei der Dekodierung von
> DCF77.

Nicht ganz.  Beim DCF77 kennst du vorher bereits das Zeitraster,
beim Morsecode musst du den Takt rekonstruieren.  Wenn der andere
mit der Handtaste gibt, kann sich der Takt auch zwischendrin ändern.
Ist für die Decodierung mit dem Ohr nicht ganz unüblich, dass man
bei nicht so guter Verbindung wichtige Passagen etwas langsamer gibt
und „übliche Höflichkeitsfloskeln“ auch mal etwas schneller
durchrattert.  Bei Contesten erlebt man das mittlerweile auch, wenn
das Signal elektronisch generiert wird: die obligatorische „599“
für den Rapport wird doppelt so schnell gerattert wie die nachfolgende
Kontrollnummer.

Auf sowas sollte sich eine Software-Decodierung einstellen können,
wenn sie den Anspruch hat, mit dem menschlichen Ohr wenigstens
ansatzweise mitzuhalten.

: Bearbeitet durch Moderator
von Tom (Gast)


Bewertung
0 lesenswert
nicht lesenswert
INteressantes Projekt, aber ziemlich furchtbar in das Gehäuse gepackt. 
Das sieht ja grauenhaft aus!

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
So, also ich hab mir mal diese "wdsp" angeschaut. Grausam - jedenfalls 
für mich. Es gibt wirklich keinerlei Dokumentation, es gibt außer den 
ewigen Copyright-Einträgen auch keinerlei Kommentare in den Quellen und 
die Namen von Variable und Funktionen sind einigermaßen kryptisch.

Kurzum, bei diesem Zeug werfe ich das Handtuch.

W.S.

von DH1AKF W. (wolfgang_kiefer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
An W.S.:
Hier sieht man Möglichkeiten, wie man mit dem Red Pitaya höhere 
Frequenzen erschließen kann:
http://saure.org/cq-nrw/2017/02/02/red-pitaya-als-shf-nachsetzer-oder-als-2m-transverter/

An  Tom (Gast):
Ja, es gibt viele bessere Beispiele für einen sauberen Aufbau:
http://forum.cq-nrw.de/viewforum.php?f=17

Aber ich bin eben mehr ein "Softi"...(ehemals Programmierer).

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
DH1AKF K. schrieb:
> Hier sieht man Möglichkeiten

Jaja, das Ausnutzen der Alias kenne ich. Schau mal bei AD in deren 
Beschreibungen ihrer schnellen ADC's nach deren Angaben über die 
Verwendbarkeit bei höheren Frequenzen, was anders gesagt eben immer 
Unterabtastung und damit Alias-Verwendung bedeutet.

Das ist aber hier (und bei mir) garnicht das Thema. Hier geht es um das 
geeignete Umsetzen der Phasing-Methode im digitalen Bereich des 
Empfängers. Und das findet eben ziemlich weit unten, also zumeist im 
Basisband statt. Da hat man die eigentlichen HF-Gefilde ja schon lange 
hinter sich gelassen. Und für nen VHF/UHF-Rx sollte man sich lieber 
nicht auf die n-ten Alias eines ADC verlassen, sondern das Frontend rein 
analog machen. Passende I/Q-Mischer gibt es ja. Solche für Anwendung 
unter 1 GHz haben zumeist einen Taktteiler eingebaut, werden also mit 
2*LO gespeist und diejenigen, die für > 1GHz gedacht sind, haben analoge 
breitbandige Phasenschieber drin. Bei den Frequenzen geht das nur so.

Aber, mein Lieber.. wenn du schon ein Programmierer bist, dann sollte 
dir ja das Finden eines passablen Algorithmus zum Ausrechnen eines 
Filterkernels für +/- 45° deutlich näher liegen als jemandem wie mir - 
oder? Sag mal.

Ach, nochwas: wie bist du eigentlich auf diese ominöse Library gekommen? 
Ist das ein Teil eines anderen Projektes, was du für dich übernommen 
hast?

W.S.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> wenn du schon ein Programmierer bist

Naja, „Programmierer“ bedeutet ja keineswegs, dass man deshalb die
(digitale) Signalverarbeitung hoch und runter rasseln kann.

von DH1AKF W. (wolfgang_kiefer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
... so ist es!
Mein Teil der Aufgabe ist, wie schon gesagt, die Programmierung des 
"Bedien- und Anzeigeteils", also des STM32F7. Falls sich jemand für die 
Programmierung des Red Pitaya interessiert:
https://github.com/pavel-demin/red-pitaya-notes
Hier sind sämtliche Quellprogramme von Pavel Demin veröffentlicht, 
allerdings fast ohne Kommentare. Pavel selbst hat die Verwendung der 
WDSP- Library vorgeschlagen. Hier werden übrigens auch die 
Filterkoeffizienten berechnet, man muss nur suchen...
Noch ein Hinweis für W.S. Vor zwei Jahren habe ich mal das Projekt 
"Simple SDR" auf einen PSoC5 portiert und nachgebaut. Mit entsprechender 
Vorfilterung ("Anti- Aliasing") funktionierte das auch. Hier findet man 
einiges, auch die Quellprogramme:
http://www.simplecircuits.com/SimpleRadios.html

von DH1AKF W. (wolfgang_kiefer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> So, also ich hab mir mal diese "wdsp" angeschaut. Grausam - jedenfalls
> für mich. Es gibt wirklich keinerlei Dokumentation,

Hallo W.S. - Schicke mir mal Deine eMail- Adresse. Dann kann ich Dir die 
ausführliche Dokumentation zur WDSP Library geben.
Ich habe den Verfasser, Dr. Warren Pratt (NR0V) darum gebeten, und er 
hat prompt geantwortet. Auch mit John Melton habe ich mittlerweile 
Kontakt, er hat diese Library von Windows nach Linux portiert, und er 
will mir beim "Morse- Problem" helfen.
Wolfgang

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
DH1AKF K. schrieb:
> ausführliche Dokumentation

"woki"? - wenn es klappt, hast du ne PDF zum Lesen von mir in deiner 
email.

W.S.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ist die Doku geheim, oder kannst du die auch hier für alle posten?

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Ist die Doku geheim

Nö, ist sie eher nicht - aber sie ist erstens nicht das, was du 
vermutest, zweitens mMn wohl nicht für dieses Forum geeignet. Ich habe 
selbst bei db3om.de leise Zweifel, ob die an sowas überhaupt 
interessiert sind. Es geht mir ganz genau um das, was ich weiter oben 
schon mal kurz umrissen habe: nämlich um die digitale Signalverarbeitung 
beim Rx - und dort eben nicht um das Zusamenkopieren von 
unverstandenen Lösungen Anderer, sondern um das tatsächliche eigene 
Verständnis. Ich will ja nicht über unsere Oberfunkamateure sprich 
Redaktion FA mosern, aber den Spruch von vor ein paar Jahren auf der 
Hamradio hatte ich ja schon mal hier gepostet. Ist nicht mein Ding, ich 
bin eher für's selber verstehen und selber können. Beruflich muß ich das 
ja auch.

Also, wenn du selber dich fit genug fühlst und obendrein genug Interesse 
hast, dann sag's einfach. Mein momentanes Thema, an dem ich mir derzeit 
die Zähne ausbeiße, ist tatsächlich, wie man eine dedizierte 
Phasenverschiebung von 45° (+/- 1..2°) in den Filterkernel eines FIR 
hineinkriegt. Das also steht oben auf der Agenda.

W.S.

von Abdul K. (ehydra) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Und Google allpass FIR hat dich nicht weitergebracht?

von DH1AKF W. (wolfgang_kiefer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo allerseits,
mit Einverständnis des Autors Warren C. Pratt, hier der Link zu seinem 
WDSP- Guide:

https://github.com/TAPR/OpenHPSDR-wdsp/blob/master/WDSP%20Guide.pdf

von DH1AKF W. (wolfgang_kiefer) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Für ein Amateurfunk- Treffen in Gera habe ich eine Powerpoint- 
Präsentation erarbeitet. (2,5 MByte)
Sie ist hier zu finden:

http://wkiefer.bplaced.net/funk

Also, wen es interessiert...

Wolfgang

von DH1AKF W. (wolfgang_kiefer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
--- übrigens, wer kein PowerPoint hat, der kann das frei erhältliche 
LibreOffice verwenden:

https://de.libreoffice.org/download/libreoffice-still/

Es braucht allerdings viel Platz auf der Festplatte.
Alternativ kann man auch den kostenlosen PowerPoint Viewer nehmen:

https://www.microsoft.com/de-de/download/details.aspx?id=13

: Bearbeitet durch User
von DH1AKF W. (wolfgang_kiefer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Neue Funktionen

Dank der umfangreichen Bibliothek "WDSP", die von Warren Pratt (NR0V) 
stammt und im RedPitaya läuft, konnte ich ohne Probleme
- neue Modulationsarten FM (genauer: NBFM) und SAM (Synchrondetektor),
- ein Auto- Notch- Filter (mit mehreren Nullstellen),
- Noise Blanker sowie
- zwei verschiedene Noise- Reduction Filter
aktivieren.
Den Benutzern des Programms PowerSDR mRX sind diese Funktionen geläufig, 
jedoch im DiscoRedTRX waren sie bisher nicht zugänglich.
Im Unterschied zu der üblichen Lösung mit PC oder BeagleBoneBlack werden 
die genannten Funktionen direkt im Prozessor des Red Pitaya ausgeführt.
Auch ist es gelungen, einen Decoder für Morsezeichen einzubauen.

von DH1AKF W. (wolfgang_kiefer) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nun gibt es auch ein Spektrum- und ein Wasserfall- Diagramm.
Darüber hinaus ist die Frequenzeinstellung direkt in der Spektrum- 
Anzeige möglich, in Schritten von 100, 1000 oder 10000 Hz.

Beitrag #6336817 wurde von einem Moderator gelöscht.

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]
  • [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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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