Diskussions- und Newsboard des DARC-Ortsverbandes I40
allgemeine Kategorie => mcHF Projekt Deutsch / English (here you can discuss everything related to mcHF) => Message started by: DD4WH on 16. August 2017, 09:05:57

Title: Experimental RTTY decoding
Post by: DD4WH on 16. August 2017, 09:05:57

Danilo hat in der neuesten daily ein wunderbares (noch experimentelles) feature zur UHSDR-Software hinzugefügt:

RTTY-Decodierung

Standardmäßig verwendet der Decoder 170Hz shift und 915Hz/1085Hz, wie es bei Funkamateuren üblich ist.

Funktioniert aber auch wunderbar für den Deutschen Wetterdienst DWD, allerdings nur, wenn man im Debug-Menü das Richtige (DWD) auswählt:
450Hz shift, 915Hz/1365Hz und 1.5 stop bits.

Hier ein Video von der Decodierung eines DWD-Seewetterberichts von heute morgen:

https://www.youtube.com/watch?v=QU90rp6_tLA

73 de Frank

Title: Re:Experimental RTTY decoding
Post by: DD4WH on 16. August 2017, 14:31:27

In der nächsten daily build anwählbar im Debug Menu:

RTTY decoder (exp):

Ham Radio:
- 170Hz shift,
- mark 915Hz, space 1085Hz
- USB

DWD:
- 450Hz shift
- mark 915Hz, space 1365Hz
- USB

Wer DWD-Decodierung ausprobieren mag, dem seien folgende Frequenzen des DWD in USB empfohlen:

4581.860 kHz
7644.860 kHz
10099.660 kHz
11037.860 kHz
14466.160 kHz

Danke nochmal an Danilo für den tollen decoder!

73 de Frank

EDIT: Frequenzen korrigiert

Title: Re:Experimental RTTY decoding
Post by: DL3ED on 16. August 2017, 16:43:11

:'( hallo zusammen.
die letzte Software läuft bei mir nicht. Das Gerät ist am USB Stick zu erkennen das es ein ist, aber das Display bleibt dunken und auch keine NF.

Gruß DL3ED

Title: Re:Experimental RTTY decoding
Post by: DF8OE on 16. August 2017, 16:55:24

Da muss was beim Runterladen oder Flashen schiefgegangen sein. Bei mir läuft auch die letzte Firmware...


EDIT:
ich habe vorhin die Downloadstruktur für mcHF und OVI40 umgestellt (vereinheitlicht). Bitte achte darauf, dass Du auch die FW für den mcHF nimmst und nicht die für den OVI40...

vy 73
Andreas

Title: Re:Experimental RTTY decoding
Post by: DL3AAA on 16. August 2017, 17:06:30

Bei mir läuft die Software.

Ich bekomme in RTTY keine brauchbare Decodierung hin.
FW: D2.5.52

Und jetzt hat er sich beim ausschalten aufgehängt....Powering of... Saving usw. Bildschirm steht..


73
Dietrich

Nachtrag:
Habe mit FLDIGI parallel mit geschrieben, alles i.O.
Konnte auch Fragmente im mcHF Display nicht zuordnen...

::)
Im schlimmsten Fall Fehler 45 glaube aber nicht daran. (45 cm vorm Display ;) )

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 16. August 2017, 17:20:35

Hallo Dietrich,

das ist natürlich blöd: Steht da "Saving finished sucessfully" oder was anderes?
Aber richtig aufhängen kann er sich da nicht mehr: Dann passiert nicht mehr viel.

Hm. Passiert das immer wieder (reproduzierbar) oder war es nur einmal?

73
Danilo

Title: Re:Experimental RTTY decoding
Post by: DL4HUF on 16. August 2017, 19:48:32

Hallo

erst mal vielen Dank für das neue Feature .

Leider kann ich nichts vernünftiges dekodieren.
mcHF genau wie im Video und auf DWD eingestellt, aber es kommt nur Buchstabensalat.
Mit einem parallel laufenden MixW hingegen wird einwandfrei dekodiert.

Nach langer Suche konnte ich jetzt EW1FR auf 14082 finden.
Aber dekodieren klappt da auch nicht. Auch nicht mit der vorgänger-Version ohne Baud-Umschaltung.
Wobei ich nicht weiß wie genau man die 915/1085Hz treffen muss.
Am Display ist das schwer abzulesen.

Absfürze beim ausschalten hatte ich bis jetzt nicht.

73 de Ronald

Title: Re:Experimental RTTY decoding
Post by: DF5LI on 16. August 2017, 19:56:26

@Frank: Wird die Baudrate in den beiden vordefinierten Sets mit umgeschaltet oder passt sich die Firmware automatisch an? Läuft die Decodierung auch weiter, wenn zeitweise der Mark- oder Spaceton verschwindet (z.B. bei selektivem Fading) ?
Ich werde das morgen mal ausprobieren; bin gespannt wie ein Flitzbogen, denn RTTY habe ich mir schon immer beim mcHF gewünscht. Der erste Versuch mit Danilos erstem Daily Build gestern funktionierte beim DWD nicht, aber das wird wohl an der falschen Baudrate gelegen haben.

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 16. August 2017, 20:17:09

Hallo,

habe gerade den Fehler gefunden: Umschaltung funktioniert leider nicht. Es ist immer Ham eingestellt. (Nur on/off funktioniert).

Fix kommt. Fix ist als Pullrequest in Github, Andreas muss dann bauen. Und ich kann den Seewetterbericht mit der UHSDR Firmware (und einem OVI40) empfangen !!! Habe zwar kein Meer in der Nähe, aber was solls. Nicht viel schlechteres Ergebnis als fldigi übrigens.

73
Danilo

Title: Re:Experimental RTTY decoding
Post by: DF8OE on 17. August 2017, 05:21:09

Ich hatte es nur mit der "per Hand codierten Shift" probiert - und da ging es sehr gut. In der Tat mit dieser Version kein Erfolg (beim DWD). Aber mit der neuen Daily geht das wieder super ;D

vy 73
Andreas

Title: Re:Experimental RTTY decoding
Post by: Michael_K on 17. August 2017, 05:45:07

Guten Morgen,
wunderbar Andreas, selbst unter meiner "bescheidenen" Antennensituation (ringsrum Stahlbetonbauten) einwandfreie Dekodierung des DWD.
vy 73 aus Erfurt
Michael_K

Title: Re:Experimental RTTY decoding
Post by: DD4WH on 17. August 2017, 05:58:27

Moin!

tschuldigung für die von mir verbockte fehlerhafte Umschaltung (HamRadio/DWD) und vielen Dank, Danilo, dass Du meinen Fehler gefixt hast! Hatte gestern abend auch probiert und den Fehler selber nicht gefunden.

Läuft jetzt bestens! "CQ CQ DE DDK2 DDH7 DDK9", danach Durchgabe der Frequenzen (auf 10099.645 USB empfangen).

73 de Frank

Title: Re:Experimental RTTY decoding
Post by: DL3AAA on 17. August 2017, 09:08:46

Hallo Danilo,
die neue Daily arbeitet ufb.

Aber der "Rechner" hat sich beim abschalten wieder aufgehängt mit der Meldung in der letzten Zeile:

Saving settings finished

Zuvor habe ich RTTY gehört und ein paar CW QSOs gemacht.

73
Dietrich

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 17. August 2017, 09:14:25

Hallo Dietrich,

ich denke, wir gehen da mal in den Nachdenkmodus. Ist ja nicht der schlimmste aller Fehler. Es gibt dazu bereits einen Issue in Github.

Du kannst Dich da gerne mit einbringen, dann bekommst Du auch die Nachrichten genau zu diesem Problem.
Hier geht es lang: https://github.com/df8oe/UHSDR/issues/957

73
Danilo

Title: Re:Experimental RTTY decoding
Post by: DF8OE on 17. August 2017, 09:30:13

Ich konnte das bisher weder bei meinen eigenen mcHFs, noch an einem der Reparaturgeräte reproduzieren. Alle gingen brav aus und es gab auch noch keine Rebootschleife.

vy 73
Andreas

Title: Re:Experimental RTTY decoding
Post by: DL4HUF on 17. August 2017, 16:36:57

Hallo

Konnte nun endlich auch testen : DWD auf 4581 geht nun UFB. :=

Aber Afu-RTTY klappt weiterhin nicht. ???
Habe mehrere Stationen um 14085 empfangen und die Mark-Frequenz
genau wie bei DWD in der 16fachen Vergrößerung eingestellt, ohne Erfolg.
Beim DWD konnte ich auch ein wenig testen wie weit man die Frequenz verstellen kann.
Auf 20m hilft das hin- und herdrehen aber auch nicht.
Mehr kann man ja nicht einstellen.
Auch der Versuch mit Revers ( also LSB eingestellt) brachte keine Lösung ...

73 de Ronald


Title: Re:Experimental RTTY decoding
Post by: DF8OE on 17. August 2017, 16:42:09

Hallo Ronald,

da gibt es noch ein paar Fehlermöglichkeiten mehr. Es kann eine andere Shift oder auch eine andere Geschwindigkeit gewesen sein, oder es sind 1.5 anstelle von 2 Stopp-Bits. Ich habe hier mal "mich selbst" (zweiter TRX mit fldigi gefüttert) empfangen können - eine externe Station auch noch nicht. RTTY ist ja auch nicht mehr soooo verbreitet....

Aber wir sind gerade an PSK dran. Es bleibt spannend.

In der aktuellen Daily ist zum ersten mal das Feature, dass man mit dem Keyer in IAMBIC einen Text eingeben kann (der erscheint zur Zeit zum Debuggen einfach auf dem Bildschirm). Das werden wir nutzen, um in RTTY und PSK zu senden - für's erste.

Niemand hätte vor 2.5 Jahren gedacht, dass der mcHF das mal alles können wird...

vy 73
Andreas

Title: Re:Experimental RTTY decoding
Post by: OE1FHB on 17. August 2017, 16:54:18

zunächst einmal Danke an die Software Entwickler , kann auf 7646, 4583,10100,800 die DWD Aussendung Empfangen , aber ich muss um ca.1,1KHz
tiefer die Frequenz einstellen um fehlerfrei zu dekodieren, woher kommt der Versatz von 1,1kHz ?
VY 73 Friedrich
OE1FHB

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 17. August 2017, 16:55:48

Hallo,

ich hätte da aktuell die Stopbits in Verdacht. Wir können auch leicht auf 1 Stopbit umstellen, das funktiioniert dann auch mit 1.5 und 2 Stopbits, ist aber nicht ganz so "sicher" wenn es um Fehldekodierungen geht.

Das soll sowieso alles mal einstellbar werden. Es gibt da ja auch noch die Bauds und die Parity und die Polarität.

73
Danilo

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 17. August 2017, 17:02:01

Hallo Friedrich,
Quote from: OE1FHB on 17. August 2017, 16:54:18
zunächst einmal Danke an die Software Entwickler , kann auf 7646, 4583,10100,800 die DWD Aussendung Empfangen , aber ich muss um ca.1,1KHz
tiefer die Frequenz einstellen um fehlerfrei zu dekodieren, woher kommt der Versatz von 1,1kHz ?
VY 73 Friedrich
OE1FHB


Weil bei RTTY die Frequenz als die Frequenz des "Mark" Trägers angegeben wird (oder ist es Space?). Der Decoder greift seine Daten bei SSB Frequenz plus 915Hz (Mark), plus 1135Hz (Space) ab. Naja, ich denke die Idee ist klar.
Wenn man einen "echten" RTTY Modus einbaut, dann würde man ähnlich zu CW nicht die reale Empfangsfrequenz anzeigen, sondern eben den Versatz bedingt durch die Filter mit einrechnen. Dann passt das auch wieder mit den "offiziellen" Frequenz-Angaben.
Oder eben auch nicht, warum nicht die Mittenfrequenz nehmen? Ich bin da nicht RTTY erfahren genug um zu sagen, was richtig ist.

73
Danilo








Title: Re:Experimental RTTY decoding
Post by: OE1FHB on 17. August 2017, 17:02:57

Danke für Erklärung !
73, Frierich

Title: Re:Experimental RTTY decoding
Post by: DF8OE on 17. August 2017, 17:09:45

Die Büchse, die wir da gerade aufgemacht haben, ist spannend und herausfordernd zugleich. Solche Dinge wie "wie bekomme ich die Einstellmöglichkeiten EINFACH geregelt? Welche Frequenz wird angezeigt?" sind nur zwei der Fragen.

Aber zusammen (ich bin auch nicht RTTY-erfahren genug) wird das was werden - sicher 8)

Ich dachte früher immer daran, die "Modem-Engine" von fldigi einfach zu übernehmen (da haben wir ja alle Tropischen und subtropischen Modes mit drin) - aber es geht natürlich auch anders. Ich bin jedenfalls von Danilos Vorstoß begeistert und überrascht zugleich. Für den OVI40 probiere ich gerade ein externes, eigenständiges LCD für die Darstellung der Digimodes aus...

vy 73
Abndreas

Title: Re:Experimental RTTY decoding
Post by: dg9bfc_sigi on 17. August 2017, 19:37:09

könnte man (zumindest in den zoom stufen 4 8 und 16) die beiden "soll" frequenzen (also mark und space) ins display einblenden (vielleicht in farbe bandwidth balken) ...
dann wäre abstimmen sowohl im ham als auch dwd mode viel einfacher

ist nur kosmetik ... aber erleichtert doch das abstimmen (augendiagramm wäre der hit aber braucht bestimmt zuviel rechenpower)

Title: Re:Experimental RTTY decoding
Post by: DD4WH on 18. August 2017, 11:38:52

Das finde ich eine sehr gute Idee, die mark & space anzuzeigen.

Ich fasse mal als kleine Ideensammlung die toDos zusammen:

- RTTY als eigener DEMOD_MODE (Parameter einstellbar)
- bei Wahl von RTTY automatisch auf magnify 16x schalten und mark & space farbig markieren
- Einstellmöglichkeit für shift & stopbits etc.
- Anzeige der "richtigen" Frequenz (soweit ich weiß, die Mittenfrequenz der RTTY-Aussendung, so ist es auf jeden Fall beim DWD: Frequenz +- (shift/2), z.B. 4583kHz +-225Hz Hub --> shift = 2x225Hz = 450Hz, zu empfangen in USB auf 4581.860, wenn Bandpass für mark bei 915Hz) --> space = mark + 450Hz = 1365Hz, Mitte = 1365Hz - 225Hz = 1140Hz, Empfangsfrequenz USB 4581.860 = 4583kHz - 1140Hz und Anzeigefrequenz = 4583.000kHz: alles klar? ;-)

FlDigi: ich hatte auch mal im source code nachgeschaut, aber das ist bei weitem zu hohe Rechenlast für unseren kleinen Prozessor. Außerdem rechnet FlDigi in double und wir haben nur eine single precision FPU (soweit ich weiß), daher ist rechnen in double unendlich langsam und für realtime Decodierung vermutlich nicht geeignet.

@sigi, hast Du mal ein Beispiel/Foto für ein "Augendiagramm" oder einen link?

73 de Frank

EDIT: Zahlen korrigiert!


Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 18. August 2017, 13:23:27

Hallo Frank,

Ideensammlung ist gut, ich werde in Github mal einen Issue anlegen. Bitte auch auf die dortigen Diskussion zu PSK und RTTY schauen.
Quote from: DD4WH on 18. August 2017, 11:38:52
Das finde ich eine sehr gute Idee, die mark & space anzuzeigen.

Ich fasse mal als kleine Ideensammlung die toDos zusammen:

- RTTY als eigener DEMOD_MODE (Parameter einstellbar)
- bei Wahl von RTTY automatisch auf magnify 16x schalten und mark & space farbig markieren
- Einstellmöglichkeit für shift & stopbits etc.
- Anzeige der "richtigen" Frequenz (soweit ich weiß, die Mittenfrequenz der RTTY-Aussendung, so ist es auf jeden Fall beim DWD: Frequenz +- (shift/2), z.B. 4583kHz +-225Hz Hub --> shift = 2x225Hz = 450Hz, zu empfangen in USB auf 4581.965, wenn Bandpass für mark bei 915Hz) --> space = mark + 450Hz = 1365Hz, Mitte = 1365Hz - 225Hz = 1035Hz, Empfangsfrequenz USB 4581.965 = 4583kHz - 1035Hz und Anzeigefrequenz = 4583.000kHz: alles klar? ;-)

1365-225 = 1140! Nur so am Rande. ;D
Quote:
FlDigi: ich hatte auch mal im source code nachgeschaut, aber das ist bei weitem zu hohe Rechenlast für unseren kleinen Prozessor. Außerdem rechnet FlDigi in double und wir haben nur eine single precision FPU (soweit ich weiß), daher ist rechnen in double unendlich langsam und für realtime Decodierung vermutlich nicht geeignet.

Der STM32F7 hat double, der STM32F4 leider nur single precision.

73
Danilo

Title: Re:Experimental RTTY decoding
Post by: DD4WH on 18. August 2017, 14:52:07

Quote:
1365-225 = 1140! Nur so am Rande.

Hast natürlich Recht, mein Fehler! ich weiß schon, warum ich kein Mathematiker geworden bin. Und jetzt verstehe ich auch, warum meine DWD-Frequenzen zwar funktionierten, aber nie haargenau passten ;-). Ich editiere das mal oben.
Quote:
ich werde in Github mal einen Issue anlegen.

OK. Dann schreibe ich weitere Ideen da rein.

Double/single precision: Oh, dann brauche ich demnächst wohl mal einen F7 ;-).

Wir sollten auch überlegen, ob die Digimodes überhaupt durch den Standard-Audio-Pfad gehen sollten. Vielleicht ist es günstiger, direkt I&Q zu nehmen und dann in der jeweiligen Digimode-Routine spezifisch zu dezimieren und zu filtern (z.B. ist bei PSK ja je nach submode ganz unterschiedliche Filter-Bandbreite notwendig, soweit ich das verstanden habe, und die Filter sind in den jeweiligen libraries [Fldigi, STM32SDR] ja schon eingebaut).

73 de Frank

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 18. August 2017, 15:48:58

Hallo Frank,

ich denke, das hängt eben stark vom verwendeten Code ab. Bei den Digimodes werden wir hoffentlich viel Code-Reuse betreiben können. Das muss dann fallweise entschieden werden. FreeDV hat Baseband-IQ als Input, RTTY hat Baseband-Audio.

Ich denke, im Laufe der Integration der Codecs werden wir da klarer sehen.

Die jetztige Architektur erlaubt es mit ausreichenden geringem Aufwand an verschiedenen Stellen abzuzweigen für die ersten Schritte.

73
Danilo


Title: Re:Experimental RTTY decoding
Post by: dg9bfc_sigi on 18. August 2017, 17:20:20

the nominal frequencies (in Europe) for the Space and the Mark (in 45 bauds) are respectively 1275 and 1445 Hz in 45 bauds speed (170 Hz shift), and 1275 and 1700 Hz otherwise (425 Hz standard shift).

wie bissu nur auf die krummen werte gekommen???

es gibt auch noch die "high tones" ... die sollten eigentlich benutzt werden damit oberwellen des tonsignals ausserhalb des ssb filters liegen

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 18. August 2017, 17:46:30

Hallo Sigi,

die Frequenzen der Filter habe ich mir nicht ausgedacht. Die hatte der Ursprungscode aus dem DSP Tutorial von HA2NON, des Code ich mit freundlicher Genehmigung verwendet habe. Das läßt sich alles ändern, der Thread ist ja mit Experimental RTTY decoding überschrieben. Danke Software ist das ein Kinderspiel. Die Filterung bezüglich der Oberwellen ist wohl eher relevant, wenn wir zum Senden kommen und unsere normalen SSB Filter weiterverwenden wollen.

73
Danilo

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 19. August 2017, 06:33:34

Hallo,

habe soeben auf 40m die (Test) Aussendungen von OM7WFF via RTTY decodieren können: Dazu muss man in LSB (!) arbeiten. Dann klappt es auch. Habe auch weitere Aussendungen sehen können, aber nicht das Rufzeichen gemerkt. Beim DWD muss man USB nutzen.
Scheinbar nutzen die Hams und der DWD unterschiedliche "Polarität" für Mark und Space.

73
Danilo

Title: Re:Experimental RTTY decoding
Post by: OE1FHB on 19. August 2017, 07:19:55

Hallo Danilo !
Auf 7044,500 Test von 9A1CRT
VY73 Friedrich

Title: Re:Experimental RTTY decoding
Post by: Michael_K on 19. August 2017, 07:24:20

Hallo,
bei mir im 20m-Band zig RTTY-Stationen;
leider durch den mcHF keine Dekodierung, egal ob USB oder LSB; Filter ist 1,4kLPF;
abgestimmt habe ich in 10 bzw. 1Hz-Schritten.
Das parallel laufende fldigi dekodiert einwandfrei. nach Augenmaß sieht man ja auch die mark- und space-Frequenz durch die Begrenzungsanzeige.
DWD-Dekodierung ist o.k.
Vielleicht wird's noch
vy 73 aus Erfurt
Michael_K

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 19. August 2017, 07:54:31

Hallo Michael,

ich habe mir die Sidetone-Frequenz in CW auf 900 Hz gestellt. Dann kannst du im CW-L-Mode recht gut das Mark-Signal treffen.
So geht es am besten derzeit.

73
Danilo

Title: Re:Experimental RTTY decoding
Post by: DD4WH on 19. August 2017, 08:29:44

vielleicht auch Filter auf BPF1,4 oder BPF1k6 stellen,
LPF 1k4 könnte zu steil sein.

@Danilo: empfängst Du RTTY in LSB?

73 de Frank

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 19. August 2017, 08:31:14

Hallo Frank,

bei Ham Rtty auf 40m -> ja. Laut meines Wissens wird bei RTTY im Amateurfunk auf LSB gesetzt. Jedenfalls wenn Mark die niedrigere Frequenz im Decoder ist.

73
Danilo

Title: Re:Experimental RTTY decoding
Post by: OE1FHB on 19. August 2017, 13:21:33

Hallo Andreas !
soeben FW 2.5.58 vom neuen System geladen,hat funktioniert.
Aber: wieso fehlen im RTTY Debug menu die Optionen für Ham,DWD
zum umschalten ?
Vy 73 Friedrich

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 19. August 2017, 13:25:18

Hallo Friedrich,

schau mal nach links oben auf den Bildschirm. Da werden dir Shift und Baudrate direkt auf die Encoder gelegt wenn du den RTTY Decoder anmachst.

Ich bin gerade beim Umbauen, sodass es einen "echten" RTTY Mode gibt.

73
Danilo

Title: Re:Experimental RTTY decoding
Post by: DF8OE on 19. August 2017, 13:30:31

Das ist noch etwas buggy... Wenn man RTTY wieder abschaltet bleiben die Encoder trotzdem auf Shift und Baud... Sollten sicher auf STG/CMP und FAS zurückschalten...

Aber gut zum Testen meines neuen Automaten - diese schnellen Commits :D

vy 73
Andreas

Title: Re:Experimental RTTY decoding
Post by: OE1FHB on 19. August 2017, 13:30:38

Hallo Danilo !
Habs gefunden .
Danke
73 Friedrich

Title: Re:Experimental RTTY decoding
Post by: OE1FHB on 19. August 2017, 13:41:48

Hallo Andreas & Danilo !
Hab da noch eine Anmerkung zu RTTY:
Bis zum Zeilenende wird von li. nach re. geschrieben.
wenn Zeile voll wird die ganze Zeile nach li. verschoben.
Das ist schwer zu lesen.
Könnte man mit neuer Zeile beginnen und wieder von li. nach re. schreiben ?

Vy 73 Friedrich

Title: Re:Experimental RTTY decoding
Post by: DF8OE on 19. August 2017, 13:43:44

Würde ich nicht so gut finden. Wer nicht schnell genug gelesen hat ist raus. Lieber "durchschieben" - so, wie es ist.

vy 73
Andreas

Title: Re:Experimental RTTY decoding
Post by: OE1FHB on 19. August 2017, 13:45:47

könnte man langsamer schieben ?

Friedrich

Title: Re:Experimental RTTY decoding
Post by: DF8OE on 19. August 2017, 13:48:37

Nein. Immer, wenn ein neues Zeichen reinkommt, wird verschoben. Die Geschwindigkeit wird also "von Außen" festgelegt.

Etliche Werbedisplays schieben bedeutend schneller...

vy 73
Andreas

Title: Re:Experimental RTTY decoding
Post by: OE1FHB on 19. August 2017, 13:59:23

O.K.

Alles Klar.

VY 73 Friedrich

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 19. August 2017, 14:00:53

Hallo,

ich versteh das schon mit dem Newline. Das geht mir auch zu schnell manchmal. Wir werden da eine clevere Lösung finden.
Aber nicht heute...

73
Danilo

Title: Re:Experimental RTTY decoding
Post by: Michael_K on 19. August 2017, 16:24:14

so,
jetzt geht's bei mir auch auf 40 und 20m.
CW-L, 900Hz CW-Sideton (Danilos Empfehlung zur Abstimmung - nochmals Dankle) da trifft man gut die mark-Frequenz
vy 73 aus Erfurt
Michael_K

Title: Re:Experimental RTTY decoding
Post by: DL4HUF on 19. August 2017, 16:43:12

Kann ich bestätigen geht sehr schön und heute zum Kontest ist richtig Betrieb.

Man kann auch das Filter 500Hz/900Hz verwenden. Space ist zwar an der Kante, geht aber.

73 de Ronald


Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 19. August 2017, 16:48:02

Hallo,

ich habs auch gerade ausprobiert. Der Strich zur Anzeige der Filter-Location ist Pflicht bei dem Betrieb auf den Bänder. Habe auch ein bißchen mitgelesen. CQ TEST ....

Wie auch immer. Das sieht doch recht gut aus.

Ich bin gerade dabei, den RTTY-Mode richtig zu integrieren, d.h. er wird ein eigenständiger Digital-Mode (wie FreeDV).
Das funktioniert schon soweit ganz nett, nur der Strich fehlt noch, der wäre hilfreich. Kombiniert mit dem CW-Input via Keyer könnte man
bald "digital" auf Sendung gehen, der Sende-Teil von RTTY ist vermutlich nicht so richtig herausfordernd (wird aber sicher nicht zum Kontest fertig!).


73
Danilo

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 19. August 2017, 17:12:28

Hallo,

das mit dem Strich habe ich noch hinbekommen. Im nächsten Daily Build muss man für RTTY also den Digital Mode wählen, dann dort RTTY. Das geht per Touch oder per Touch Ersatz Menü. Bei Ham RTTY auf LSB, bei DWD auf USB achten. Die Parameter sind jetzt über Encoder 1 und 2 einstellbar. Der Strich muss auf den Träger mit der "höheren" Frequenz aka Mark eingestellt werden (LSB). Beim DWD ist es USB und die niedrigere Frequenz.

Also entweder selber compilieren oder auf Andreas mit seinem vollautomatischen Skript warten...

73
Danilo

Title: Re:Experimental RTTY decoding
Post by: DL3AAA on 19. August 2017, 20:50:04

Hallo Danilo,

RTTY läuft wieder UFB. Die Einstellungen müssen einem erst zu eigen werden...aber kein Problem. BIN BEGEISTERT ;D

Schönes Wochenende

73
Dietrich

Title: Re:Experimental RTTY decoding
Post by: OE1FHB on 20. August 2017, 05:29:56

Guten Morgen Danilo !
Habe die Option mit warten gewählt (Hi).
Heute morgens nach deiner Anleitung installiert und auf RTTY geschaltet.
Funktioniert wunderbar !! :)
Anmerkung :Habe aber zwischen angezeigter QRG und Soll QRG z.B.
DWD 10100.800 kHz eine Abweichung von 1kHz.

Trotzdem danke für deine Arbeit .

Vy73 Friedrich

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 20. August 2017, 07:19:29

Hallo Friedrich,

die angezeigte QRG ist die SSB QRG (sprich +/- RTTY Filter). Deshalb ca. 1 khZ versetzt. Das muss so. Solange bis wir entscheiden, wie die RTTY Frequenz anzuzeigen ist (Mitte der beiden Signale oder Mark Signal oder Space Signal oder ...).

Da müssen jetzt RTTY Experten ran und mal sagen, wie das da normalerweise gemacht wird. Ich bin da raus.

73
Danilo


Title: Re:Experimental RTTY decoding
Post by: OE1FHB on 20. August 2017, 07:25:06

Hallo Danilo,
danke für Erklärung, schönen Sonntag.
VY73 Friedrich

Title: Re:Experimental RTTY decoding
Post by: DL4HUF on 20. August 2017, 07:52:52

Hallo

Eben auch die Version D2.5.59 eingespielt : einfach Klasse !

Mit der Frequenz muss man aufpassen was es für Angaben sind. Beim DWD scheint es so zu sein, dass die Mittenfrequenz zwischen Mark und Space angegeben ist.
z.B. wird die 4583KHz angegeben.
Wenn man die bei USB/LSB einstellt sieht man schön im Display das Mark und Space links und rechts der 4583KHz liegen, also Mark auf -225Hz .
Wir haben aber Mark auf +915Hz bei RTTY-USB liegen.
Das heißt wir müssen auf 4581,860KHz abstimmen (225 + 915 = 1140Hz).
Mit der Linie im Display geht das hervorragend.

@Danilo: im Debug-Menü steht der RTTY-Decoder noch drinn

Mit der Eingabe zum Senden ... wenn nur die CW-Fähigkeiten besser wären ...
Für den Anfang wäre ein USB-Keyboard sicher eine gute Variante.

73 de Ronald

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 20. August 2017, 08:24:02

Hallo,

der heutige SARTG Contest erlaubt es, den RTTY Teil so richtig zu testen. Leider nur RX.

CW: Ich habe mir vor ein paar Tagen ein 3D Paddle gedruckt und endlich mal den integrierten Keyer ausprobiert. Ist für mich Grobmotoriker natürlich schwer, aber mit Übung vermutlich machbar, man kann ja jetzt wunderbar mit dem TRX üben, denn im CW Mode mit dem integrierten Keyer gibt er die erkannten Zeichen aus (da wo auch bei RTTY der Text kommt). Handtaste (Straight-Key) halte ich für mich für illusorisch, aber Iambic könnte klappen.

USB: Steht auch auf der Liste.

RTTY Menu: Danke, der RTTY Decoder kommt da raus.

73
Danilo

Title: Re:Experimental RTTY decoding
Post by: DF5LI on 20. August 2017, 13:36:36

Ich habe mir mal zeigen lassen, wie das beim Volkstransceiver IC 7300 gelöst worden ist. Die haben 2 Striche im gewünschten Shift-Abstand implementiert. Dann muss man nur die beiden Peaks bzw die beiden Wasserfalllinien unter die Striche schieben und los gehts...

Title: Re:Experimental RTTY decoding
Post by: DL1KBX on 20. August 2017, 14:17:56

Quote from: DF5LI on 20. August 2017, 13:36:36
Die haben 2 Striche im gewünschten Shift-Abstand implementiert. Dann muss man nur die beiden Peaks bzw die beiden Wasserfalllinien unter die Striche schieben und los gehts...

Das gleiche hat man ja auch in allen PC-Programmen, auch AFC einbauen wäre nicht schlecht...

Title: Re:Experimental RTTY decoding
Post by: Michael_K on 20. August 2017, 14:55:31

noch mal zum Testen,
habe soeben auf 14.094kHz UA6LJB (Rostov am Don) und RA6GW (Pyatigorsk) empfangen.
Einwandfreie Dekodierung, Klasse
vy 73 aus Erfurt
Michael_K

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 20. August 2017, 15:16:46

Hallo Harri,

und welche Frequenz wird angezeigt? Das ist spannend, die 2 Striche bekommen wir noch hin, denn wer einen kann, kann auch zwei.
Aber trotzdem muss der 2. Strich auch programmiert werden.

73
Danilo



Title: Re:Experimental RTTY decoding
Post by: DF5LI on 21. August 2017, 00:00:16

Moin Danilo, das muss ich noch mal erfragen. Ich glaube, die Mark-Frequenz wird angezeigt. Das sieht im Display dann so aus :

Title: Re:Experimental RTTY decoding
Post by: jost on 21. August 2017, 18:20:13

hallo mchf gemeinde

habe software auch aufgespielt
im debug menü erscheint rtty exp error!
genau so ft817 clone error!

was mache ich falsch?

habe den mchf rev.06

ps: trx funktioniert sonst super!!!!!!!

habe seit ein paar tagen ein transverter drann für 2m nur gute rapporte.

vy 73 jost


Title: Re:Experimental RTTY decoding
Post by: DL4HUF on 21. August 2017, 19:09:07

Hallo Jost

Der Eintrag im Debug-Menü ist veraltet. Den RTTY-Mode gibt es jetzt normal bei den Digitalen Modi.
Einfach auf die Schaltfläche "Digial" drücken.
Die FT817-Einträge sind ebenfalls nur zum testen für Andreas.

73 de Ronald

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 21. August 2017, 20:24:05

Hallo,

im nächsten Daily Build, der kommt (2.5.60) wird der Wunsch nach 2 Marker-Linien für RTTY erfüllt und wo ich schon mal dabei war, habe ich das auch noch für FreeDV genutzt (da kann man jetzt auch das Signal in die "Zange" nehmen).

Berichtet bitte, wenn es bei den Markierung Auffälligkeiten gibt (insbesondere im Scope-Modus, der Wasserfall ist da eher unkritisch).

73
Danilo




Title: Re:Experimental RTTY decoding
Post by: jost on 22. August 2017, 16:24:02

hallo gemeinde

danke ronald für die hilfe

muss die bedienungsanleitung wohl mal sorgfältiger lesen!

73 jost/DO7AGN


Title: Re:Experimental RTTY decoding
Post by: DF5LI on 22. August 2017, 20:50:16

Hallo Danilo, toll, dass du meine Anregung gleich umgesetzt hast! Falls du dir mal ansehen willst, wie das beim IC7300 gemacht wird, siehe dieses Youtube -Video : https://www.youtube.com/watch?v=tVnwn236fgY
Aber die Abstimmung geht auch schon mit magnify x4 und den Marker auf Mark setzen wunderbar! Selbst völlig verrauschte Signale werden prima decodiert!

Title: Re:Experimental RTTY decoding
Post by: DD4WH on 23. August 2017, 15:35:55

Hallo Danilo,

sieht sehr gut aus mit den beiden Markern! Super!

Ist DWD-Empfang jetzt wieder ausgebaut? Bin nach drei Tagen mal wieder am mcHF und die Einstellung für shift und Baudrate finde ich nicht, gibts da irgendwo Infos? Oder soll ich mal was ins Wiki eintragen? Eine Seite "Digimodes" würde sich ja anbieten . . .

73 de Frank

EDIT: Alles klar, wer sucht der findet ;-) ! Habe es gesehen, ist in den boxen unter AFC und AGC threshold per encoder einstellbar! Sehr schön realisiert! Ich schreibe das demnächst mal in eine Wiki-Seite, sodass man alles zu den Digimodes dort hinein packen kann, OK?

Title: Re:Experimental RTTY decoding
Post by: DD4WH on 23. August 2017, 16:16:39

erste Infos im Wiki:

https://github.com/df8oe/UHSDR/wiki/Digimodes

bitte Hinweise auf Fehler/Optimierungen gerne an mich ;-).

Title: Re:Experimental RTTY decoding
Post by: DL3AAA on 23. August 2017, 19:07:11

Konnte mich auf Grund fehlender Touch-Funktion nicht zu den mark und space Markern melden.

Habe heute den Fehler repariert und kann mich jetzt nicht satt sehen, es funktioniert einwandfrei.

Nicht nur das es gut aussieht, es macht das Abstimmen deutlich einfacher.

DWD auf 10100.8 Khz

73
Dietrich


Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 23. August 2017, 19:55:05

Hallo Dietrich,
Quote from: DL3AAA on 23. August 2017, 19:07:11
Konnte mich auf Grund fehlender Touch-Funktion nicht zu den mark und space Markern melden.

Geht auch alles übers Menu. Siehe Wiki-Seite die Frank oben verlinkt hat.
Quote:
Nicht nur das es gut aussieht, es macht das Abstimmen deutlich einfacher.

Nicht das Aussehen zählt, sondern die Funktion!

73
Danilo

Title: Re:Experimental RTTY decoding
Post by: DL3ED on 24. August 2017, 06:32:47

moin Zusammen,
SW 2.5.60 parallel Disp.
Wo schalte ich von DWD auf AFU um? Welches Menü?
Das Gerät steht immer auf FreeDV.

Gruß DL3ED Ulrich

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 24. August 2017, 06:33:53

Anleitung im Wiki, siehe weiter oben.

73
Danilo

Title: Re:Experimental RTTY decoding
Post by: DF5LI on 24. August 2017, 10:48:55

Ich möchte hier mal meiner Begeisterung für die Implementierung der RTTY-Funktion Ausdruck geben! Das haben unsere "Softies" (Ausdruck von Hans Hilberling für deine Firmware-Entwickler) super hinbekommen! Ich bin schon seit Tagen am Mitschreiben. Mit jeder neuen FW-Version wird die Bedienung einfacher. Der DWD wird sogar mit der falschen Shift-Einstellung noch brauchbar mitgeschrieben... Lediglich mit der Umschaltung per Touch habe ich meine Schwierigkeiten, das kleine Touchfeld immer zu treffen, aber das geht ja auch prima übers Menü.
Vielen Dank für die tolle Arbeit !!!

Title: Re:Experimental RTTY decoding
Post by: DD4WH on 24. August 2017, 15:46:00

Um RTTY auch bei starkem fading und QRM robuster decodieren zu können, benutzt FlDigi eine sog. ATC = automatic threshold correction. Da FlDigi open source ist, habe ich dort ein wenig code geräubert und versucht, das in UHSDR einzubauen.

Für Testzwecke haben wir daher in der neuesten daily die Möglichkeit im Debug-Menü die ATC für RTTY einzuschalten.

Bitte mal testen und vergleichen, ob es sich lohnt, RTTY ATC drin zu lassen. Auch Vergleiche unseres RTTY-Decoders mit dem Original-FlDigi wären gut.

Erste Tests mit DWD-Decodierung ergaben, dass "RTTY ATC" selbst bei der Filtereinstellung 500Hz/950Hz (bei der space ja schon gar nicht mehr im Filter-Passband ist!) noch decodiert. "RTTY" hingegen decodiert dann gar nicht mehr.

"RTTY ATC" sollte demnach sehr viel robuster sein bei selektivem fading.

Aber bei 170Hz shift und 45Bd habe ich RTTY ATC noch gar nicht getestet und würde mich freuen, wenn das ausgiebig getestet würde.

Mehr Infos und links hier: https://github.com/df8oe/UHSDR/wiki/Digimodes

73 de Frank



Title: Re:Experimental RTTY decoding
Post by: DF8OE on 24. August 2017, 16:03:20

Hallo Frank,

"steel from the best" ist eine GRUNDLAGE der Wissenserweiterung. Kritisch wird es nur dann, wenn man seine "eigenen Ergüsse" nicht ebenfalls wieder zur Verfügung stellt.

Ich würde mal schätzen, dass ich 70% meiner jemals geschrieben Code "geklaut" habe. Die Kombination (das "Endergebnis") war dann zwar neu - aber ::)

Ich bin gespannt auf andere Berichte.

Ich kann sagen, das ein Signal, das ich künstlich (durch Abschwächer) verschlechtert habe, mit der neuen Regelung 100% mitgeschrieben wurde, während mit dem alten RTTY nur noch Fragmente ankamen.

Die Schöpfer von fldigi wussten offenbar, was sie taten...

vy 73
Andreas

Title: Re:Experimental RTTY decoding
Post by: DD4WH on 24. August 2017, 16:22:44

Quote:
Die Schöpfer von fldigi wussten offenbar, was sie taten...


Ja, wir können sehr froh sein, dass so viele absolute Top-Spezialisten Ihre Erkenntnisse und Ihren code unter die GNU GPL open source Lizenz stellen! So auch W7AY, der diese Form der ATC erfunden hat:
http://www.w7ay.net/site/Technical/ATC/

und für den code in Fldigi W1HKJ & DO2SMF, die wiederum selber beim code von OH2BNS "geräubert" haben ;-).

https://github.com/ukhas/dl-fldigi/blob/master/src/cw_rtty/rtty.cxx

Viel Spaß!

73 de Frank

Title: Re:Experimental RTTY decoding
Post by: DL1KBX on 25. August 2017, 21:16:34

Bin begeistert, RTTY läuft bestens!!! Danke!

https://www.youtube.com/watch?v=nHb7a_iv0EM


Title: Re:Experimental RTTY decoding
Post by: jost on 26. August 2017, 14:55:35

hallo
habe gerade die neuste fw geladen

rtty läuft super.

danke an die entwickler

73 jost/DO7AGN/H18

Title: Re:Experimental RTTY decoding
Post by: DF5LI on 26. August 2017, 17:05:02

Auf 40m läuft gerade ein RTTY Contest. DIE Gelegenheit, das jetzt ausgiebig zu testen !

Title: Re:Experimental RTTY decoding
Post by: Michael_K on 27. August 2017, 07:53:04

hallo,
auch beim SCC-RTTY-Contest einwandfreie Dekodierung der Sendungen auf 40 und 20m.
Erstmals auch auf 10.099 den DWD empfangen.
Die beiden Linien vereinfachen echt die Abstimmung.
Nochmals DANKE für die Entwicklung.
vy 73 aus Erfurt
Michael_K

Title: Re:Experimental RTTY decoding
Post by: Laddieter on 28. August 2017, 08:26:05

Hallo,
auch von mir ein herzlichen Dank an die Entwickler der RTTY-Dekodierung.
Läuft super und es ist schon erstaunlich, was aus dem mcHF-Projekt bis heute
geworden ist.
Nochmals vielen Dank und schöne Grüße
Dieter, DL1LAD

Title: Re:Experimental RTTY decoding
Post by: DG2NPE on 28. August 2017, 10:53:01

Hallo zusammen,

Ich schließe mich meinem Vorredner voll und ganz an und bin begeistert!!

73, Peter DG2NPE

Title: Re:Experimental RTTY decoding
Post by: dl1avx on 28. August 2017, 17:01:55

Die Dekodierung funktioniert wunderbar!

Werde wohl auch wieder RTTY machen, wenn der rechner nicht mehr benötigt wird ;)

Vielen Dank für die tolle Arbeit!

vy 73 de Peter

Title: Re:Experimental RTTY decoding
Post by: DL4HUF on 28. August 2017, 18:19:23

Hallo Danilo

Ein kleiner Bug ist mir eben mit der 2.5.65 aufgefallen:
Wenn man von RTTY zurück zu LSB schaltet wird der 2. Abstimm-Strich im Spektrum nicht
gelöscht.
Bei FreeDV ist es ok.

73 de Ronald

Title: Re:Experimental RTTY decoding
Post by: peter_77 on 29. August 2017, 11:17:19

Habe nun nach all den positiven Meldungen (auch hier nochmals großen Dank an die Softwerker !) auch mal die aktuelle 2.5.66 heute morgen aufgespielt und mich am DWD auf 10.100 versucht:
- Freq 10.100 DWD mit S9
- Mode auf RT-U
- Filter auf 1,8 khz (WDSP Settings nach Andreas)
- Digital geklickt bis die orange RTTY Box kommt
- Mit M1 50 Baud und mit M2 450 Hz Shift eingestellt
- Magnify auf 16 und die Doppelstriche perfekt auf Mark and Space justiert…
- ...nur Hieroglyphen >:(
Auffallend ist das es scheinbar geht denn bei der RYRYRYRYRY Schleife des DWD wird immer 6464646464 geschrieben, also als ob es irgendwie invers ist.
Umschalten auf RT-L macht es aber nur schlimmer.
Nach einem Ein- Ausschalten schreibt er kurzzeitig sauber mit RYRYRY Schleife kommt dann die Senderkennung, aber sowie er auf die Ziffernebene schaltet bei den Frequenzangaben kommt er davon nicht mehr zurück und schreibt nur Kauderwelsch. Das lässt sich reproduzieren und ist gleiches Verhalten an 3 mcHFs mit gleichem Bootloader und SW Stand (2.5.66).
Was rennt da falsch, denn bei der 2.5.65 sollte das sauber funktionieren wie mir berichtet wurde. Mit der Version muss ich allerdings nochmal testen.


Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 29. August 2017, 11:24:04

Hallo,

gut bemerkt. Das war ich! Habe gestern den TX gefixt, der hatte ein Umschaltproblem, jetzt hat RX ein Umschaltproblem.
Das kriegen wir wieder hin. Ganz schnell.

EDIT: Pull Request ist draußen, sollte in der 2.5.67 raus sein.

73
Danilo

Title: Re:Experimental RTTY decoding
Post by: peter_77 on 30. August 2017, 14:24:39

Röchel....ich dachte schon ich wär zu doof für RTTY :D

<edit> Heute die .67 eingespielt und alles wieder "bella" sowohl auf mcHF als auch I40 :) Beweisfoto anbei (I40)</edit>

Was noch auiffällig ist:
  • Shift und Baudrate werden beim Ausschalten nicht gespeichert
  • Die Doppelstriche der Abstimmhilfe verschwinden nicht bzw. gehen nicht auf Einzelstrich wenn man z.B. auf SSB oder CW per Mode oder übers Touchpanel schaltet

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 30. August 2017, 14:49:52

Hallo Peter,
Quote from: peter_77 on 30. August 2017, 14:24:39
Shift und Baudrate werden beim Ausschalten nicht gespeichert

Das "soll" so sein. Ist noch nicht klar, wie wir das genau machen wollen.
Quote:
Die Doppelstriche der Abstimmhilfe verschwinden nicht bzw. gehen nicht auf Einzelstrich wenn man z.B. auf SSB oder CW per Mode oder übers Touchpanel schaltet.


Da muss ich noch mal genau hinschauen, kann sein, dass das nicht so wie gedacht klappt, ist mir aber noch nicht aufgefallen.

73
Danilo

Title: Re:Experimental RTTY decoding
Post by: dg9bfc_sigi on 05. September 2017, 18:24:54

das müsste man irgendwie beim band stacking register ablegen ...
wenn man ne dwd frequenz dort abgelegt hat sollte es sofort beim bandwechsel funzen
wechselt man auf ein afuband sollte eben auch auf afu-shift und baud gewechselt werden
das wäre am besten ... aber sicher aufwändig
muss keine auto umschalt funktion sein sondern wenn der user die frequenz VORHER mit rtty dwd genutzt hat (oder eben afu shift wenn der user vorher diese nutzte)
wir brauchen einfach ein grösseres band register (oder speicherplätze)
welcher mode dann auf der jeweiligen qrg genutzt wurde sollte sich der mchf "merken" oder der user müsste die möglichkeit haben die momentanen einstellungen irgenwo abzulegen (speicherplätze 11-99)
???

Title: Re:Experimental RTTY decoding
Post by: yo2ldk on 07. September 2017, 18:38:44

I know is a little (or more) to work on code,
but for actual and future decoder text ,
what you say about to rearrange the pieces on display?
I left outside the "Bnd XXm" for more space

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 07. September 2017, 18:48:46

Hi,

in general I think it makes sense to rethink the layout.

There is work underway to work especially on the text mode parts.

However, leaving out the "Bndxx" is not advisable, since this is NOT the same as the "30m" indicator in your picture. It is rather the name of the memory used to store current settings. Right now we have only "Band" memories with fixed names. But in future we will have named memories. And these can be combined with any mode, so we need a way to show this name.

You also left out the WDSP AGC indicator. We do have the lower meter area, which is unused in RX. It could hold values relevant for RX but not for TX. For instance the dbm/hz value, the AGC DSP status, Step size ... That would free up some space elsewhere.


73
Danilo

Title: Re:Experimental RTTY decoding
Post by: peter_77 on 08. September 2017, 08:07:59

In my opinion there is no need to show 2 clocks. Everybody should know his offset to UTC so it makes no sense and is a waste of display space to show 2 clocks.
This can be workedaround with maybe a setup entry to show a single clock either in UTC or local and the UTC offset.
The rest of the proposal is ok.

Title: Re:Experimental RTTY decoding
Post by: DF8OE on 08. September 2017, 11:06:51

Sorry - it's not ok. Some important boxes / infos are missing as Danilo stated already.

We must think about usage of senseless informations (like SWR in RX mode) for missing ones.

AGC Box is absolutely recommended in RX
Bnd storage place is absolutely neccessary, too
...both are missing here.

vy 73
Andreas

Title: Re:Experimental RTTY decoding
Post by: dg9bfc_sigi on 10. October 2017, 11:25:07

we could left out the step size in hz cause we already have the stepsize shown as the step size marker 10 hz 100 hz 1 kc etc ... if step size is 500hz (or 5 kc like in am sam) we could change colour of step size marker (say from white to orange or so) ... so that would free up the step size box (in my view not needed if marker would change colour in that bigger step size)
...
only problem that then persists is

how to switch on dynamic tune and how to show if it is engaged or not?!?!?!

but i am sure the gui layout will be changed anyway soon when more digital modes will come
and when the new lcd experimental becomes part of the project
;D

Title: Re:Experimental RTTY decoding
Post by: DF8OE on 10. October 2017, 12:34:22

We must stay compatible with mcHF 320x240 layout. Of course OVI40 can differ and if it will be implemented to use larger resolution on mcHF (not 100% sure due to RAM) there will be other layouts possible...

vy 73
Andreas

Title: Re:Experimental RTTY decoding
Post by: dg9bfc_sigi on 27. October 2017, 16:48:25

with long press on split and the short press on men we can switch off lower area of display (spectrum/waterfall) ....
why not use it for text modes ?!?

add following to the fw

if lower display is on ... use only the one text line that we have now

if lower display is off (and text mode like rtty or cw is used) ... then use that lower display area for decoded text

maybe selectable in menue??

greetz sigi

Title: Re:Experimental RTTY decoding
Post by: BO_Andy on 01. December 2018, 09:05:44

Ich erreiche gar keinen der Frequenzen DWD kann es sein das nur um bestimmt Zeiten ausgestrahlt wird

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 01. December 2018, 09:16:52

Hallo Andy,

eigentlich nicht, siehe https://www.dwd.de/DE/fachnutzer/schifffahrt/funkausstrahlung/_functions/DownloadBox/Download_Box.html

73
Danilo

Title: Re:Experimental RTTY decoding
Post by: BO_Andy on 01. December 2018, 09:32:22

Okay habe ich vielleicht noch was vergessen einzustellen bd50 auf shf auf 450 Bandpass auf 1.3

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 01. December 2018, 09:34:03

Hallo Andy,

man muss die Aussendung klar im Wasserfall und/oder Scope erkennen, sonst funktioniert der RTTY Decoder nicht wirklich.

Title: Re:Experimental RTTY decoding
Post by: BO_Andy on 01. December 2018, 11:14:54

Okay das ist nicht der Fall muss ich wohl nochmal denn 30m bandpass überprüfen auf 10017,560 habe ich was was sich nach rtty anhört

Title: Re:Experimental RTTY decoding
Post by: DB4PLE on 01. December 2018, 11:17:45

Hallo Andy,

habe eben den DWD auf 4583.0 Khz empfangen.
Dazu musst Du RTTTY USB (RT-U), Frequenz 4581.860 khz einstellen und 450 Hz Shift, 50 Baud.
Die 4581.860 ergeben sich aus der Mittenfrequenz 4583 khz minus 450/2 = 225 Hz für den unteren Träger und davon dann nochdo
die 915 Herz abgezogen, auf der wir den unteren Träger erwarten (sprich insgesamt -1140 Hz von der Mittenfrequenz).

Der Empfang ist aber eher schlecht bei mir die meiste Zeit, hoffe Du hast eine bessere Antenne/Lage.

73
Danilo


Title: Re:Experimental RTTY decoding
Post by: peter_77 on 01. December 2018, 14:22:22

Die genauen Frequenzen für RTTY findest du hier:
https://www.dwd.de/DE/fachnutzer/schifffahrt/funkausstrahlung/_node.html (https://www.dwd.de/DE/fachnutzer/schifffahrt/funkausstrahlung/_node.html)
(Links auf die Sendepläne klicken)
Mit Danilos Settings oben geht der Empfang problemlos.
Senden tun die rund um die Uhr außer zu Wartungszeiten.
Mit dem kostenlosen FLDIGI Programm https://sourceforge.net/projects/fldigi/ (https://sourceforge.net/projects/fldigi/) kannst du sogar deren Fax Sendungen direkt über den USB Port fehlerlos empfangen.
Andere Fax Sendungen hier:
http://www.nws.noaa.gov/os/marine/rfax.pdf (http://www.nws.noaa.gov/os/marine/rfax.pdf)

Interessant auch NavTex:
http://www.dxinfocentre.com/maritimesafetyinfo.htm (http://www.dxinfocentre.com/maritimesafetyinfo.htm)
Kannst du mit einem ebenfalls freien Decoder YaND empfangen:
https://www.ndblist.info/datamodes/YaNDsetup7_0.exe (https://www.ndblist.info/datamodes/YaNDsetup7_0.exe)

Title: Re:Experimental RTTY decoding
Post by: BO_Andy on 02. December 2018, 09:13:49

Danke euch für die viele Tipps endfänge jetzt auch DWD auf 4581.860


Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.