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/
Angehängte Dateien:
-
CW_station.jpg
55 KB
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. ;-)
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.
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
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
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.
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.
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.
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.
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.
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.
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.
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...
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!
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.
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
Das ist eigentlich das gleiche Problem wie bei der Dekodierung von DCF77. Eventuell kannst du da gut abkupfern gehen.
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
INteressantes Projekt, aber ziemlich furchtbar in das Gehäuse gepackt. Das sieht ja grauenhaft aus!
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.
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).
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.
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.
... 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
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
DH1AKF K. schrieb: > ausführliche Dokumentation "woki"? - wenn es klappt, hast du ne PDF zum Lesen von mir in deiner email. W.S.
Ist die Doku geheim, oder kannst du die auch hier für alle posten?
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.
Und Google allpass FIR hat dich nicht weitergebracht?
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
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
--- ü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
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.
Angehängte Dateien:
-
12b-Spektrum24.jpg
240 KB
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.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.