Stand: 20. Oktober 2017

---

  automatic translation by GOOGLE:
https://translate.google.com/translate?sl=de&tl=en&js=y&prev=_t&hl=de&ie=UTF-8&u=http%3A%2F%2Fwww.kh-gps.de%2Frtty.htm&edit-text=&act=url

Die Idee kam mir bei Versuchen zur Ausgabe und Auswertung von Morsesendungen mithilfe von ARDUINO-Prozessoren und ANDROID-Smartphones, An anderer Stelle [1] hatte ich darüber schon ausführlich berichtet. Die elektronische Auswertung empfangener Morsesendungen konnte mich dabei allerdings nie richtig zufriedenstellen. Das Hauptproblem dürften dabei die bei Zeichenempfang zu verarbeitenden unterschiedlichen Geschwindigkeitswerte sein. Günstiger liegen die Verhältnisse dagegen im Falle der Übertragung von RTTY-Signalen. Obwohl mancherorts bereits totgesagt, ist dieses schon viele Jahrzehnte bekannte Übertragungsverfahren immer auch noch zum Austausch von z.B. Textmessages geeignet. Ehemals grossvolumige Endgeräte lassen sich heutzutage durch moderne Computertechniken ersetzen. Neben z.B. Laptops können hierfür auch preiswert erhältliche Mikrocontrollerboards und ANDROID-Smartphones bzw. Tablets genutzt werden, womit sich äusserst kompakte, mobil einsetzbare Einheiten realisieren lassen. Mikrocontroller dienen dabei der Signalverarbeitung, während die Datenein- und ausgabe z.B. über Smartphones/Tablets erfolgen kann.

---

---

Abgewandelt vom bereits erwähnten Konzept eines Morsedecoders entstand eine Einheit zum Empfang von RTTY-Aussendungen. Die Unterschiede beschränken sich dabei im Wesentlichen auf die verwendete ARDUINO-Software. Um auch RTTY-Signale mit Mark/Space-Tonfrequenzen von 1275Hz/1445Hz decodieren zu können, genügte auf der Hardwareseite die Änderung lediglich eines Kondensatorwertes ( C5 in Abb.2 ) am Tondecoderbaustein "LM567"


Die von seinem Ausgang bereitgestellten RTTY-Tastsignale werden von einem ARDUINO-Baustein des Typs "Pro-Mini" weiter verarbeitet und stehen danach als serielle ASCII-Zeichenfolgen an seinem UART-Ausgang zur Verfügung. Zu weiteren Bearbeitung können sie von hier aus via z.B. Bluetoothfunk an ein Smartphone/Tablet gesendet und dort mit einem der hierfür verfügbaren Terminalprogramme zur Anzeige gebracht werden. Als Option ist aber auch eine Direktanzeige ankommender Zeichenfolgen mithilfe eines über Prozessorausgänge angeschlossenen Standard-16x2-Zeichen-LCDisplays möglich.
Im Ursprungszustand ist die verwendete ARDUINO-Software auf die Verarbeitung des RTTY-Signalformates abgestimmt, so wie es im Amateurfunkbetrieb üblicherweise zur Anwendung kommt. Passend dazu arbeitet auch die weiter unten noch zu beschreibenden Sende- bzw. Encodereinheit. Genutzt wird eine Baudrate von 45.45 Bd. mit festgelegter Datenlage für Mark- und Spacefrequenzen.
Die verwendete ARDUINO-Empfangssoftware stammt ursprünglich von JI3BNB aus Japan [3], wurde aber von DD0CW und mir modifiziert und auch erweitert. Zwei zusätzliche Taster erlauben jetzt die Auswahl zwischen verschiedenen gebräuchlichen Baudraten ( 45.45, 50, 75, 100, 110 und 300 Bd. ) und zwischen normaler oder inverser Datenlage. Damit ist auch die Verarbeitung von Signalen kommerzieller Sender möglich, wozu beispielsweise die KW- und LW-Aussendungen des DWD ( Deutschen Wetterdienstes ) gehören ( siehe Abb.3 ). Zur weiteren Nutzung werden die gewählten Betriebseinstellungen auch im EEPROM-Bereich des Prozessors abgelegt, was sich in der Praxis als sehr nützlich erwiesen hat.


Die am seriellen UART-Ausgang des Prozessors mit einer Datenrate von 9600bps bereitstehenden Ausgangssignale können direkt einem Bluetoothmodul, wie z.B. dem weit verbreiteten "HC-06" an dessen RxD-Eingang zugeführt werden. Verbindungen zwischen Smartphone/Tablet und Modul werden dabei immer ausgehend von Erstgenannten aufgebaut. Dazu musste vorher einmalig ein Pairing ( siehe am ANDROID-Gerät: Einstellungen/ Bluetooth ) zwischen beiden Einheiten erfolgt sein. Bei anschliessendem Start eines Terminalprogrammes am ANDROID-Gerät wird eine Liste der dem Gerät bekannten Bluetoothpartner aufrufbar sein. Hierunter sollte sich auch unser "HC-06" finden und zum Aufbau einer Datenverbindung anwählen lassen. Von der Decoderseite ankommende ASCII-Zeichenfolgen sollten anschliessend auch im Eingangsfenster des Terminalprogrammes sichtbar werden. Das beispielsweise von mir an dieser Stelle favorisierte Terminalprogramm ist unter dem Namen "Bluetooth Serial Controller" aus dem GOOGLE Play Store herunterladbar. Es erlaubt dabei sogar einen automatischen Wordumbruch und ein Zeilenscrolling nach gefülltem Fensterinhalt, womit sich ein gut überschaubares Darstellungsbild ergibt.

---

---

Am unteren Bildschirmrand genannten Terminalprogrammes befindet sich eine Eingabezeile für aussendbare Texte ( siehe Abb.3 und Abb.4 ). Ihre Ausgabe erfolgt allerdings erst nach Betätigung der Taste "SEND", so dass sie bei Bedarf auch schon während des Empfangsbetriebes vorgeschrieben werden können.
Eine Besonderheit des verwendeten Terminalprogrammes sind dessen fünf zusätzliche Tastenfunktionen, die den Direktabruf vorabgespeicherter Zeichenfolgen mit je max. 64 Zeichen erlauben. Hierbei kann es sich z.B. um häufig benötigte Folgen, wie CQ-Rufe, Testsendungen und Stationsvorstellungen handeln. 

Ausgesandte ASCII-Zeichenfolgen sind nach Bluetoothübertragung auch am TxD-Ausgang des "HC-06" verfügbar. Ihre Weiterverarbeitung übernimmt ein zweiter ARDUINO-Prozessor des Typs "Pro-Mini" *. Auch der hierbei benutzte Programmcode stammt im Ursprung wieder von JI3BNB, wurde aber von OK1HRA [2] nachbearbeitet und von mir an die vorliegende Anwendung angepasst. Er erlaubt Zeichenausgaben in Form von 45.45 Baud-RTTY-AFSK-Signalen unter Verwendung der Töne 1275Hz und 1445Hz. Zusätzlich wird während ihrer Ausgabezeiten auch ein PTT-Signal bereitgestellt, worüber sich bei Bedarf ein angeschlossener Sender tasten lässt. Für z.B. Handfunksprechgeräte lassen sich beide Signale auch in gewohnter Weise kombinieren. Wird diese Funktion nicht benötigt, sollte Widerstand "R*" unbestückt bleiben.
Am KEY-Ausgang sind darüberhinaus auch RTTY-Tastimpulse verfügbar. Bei vorliegender Anwendung dienen sie allerdings lediglich zur Steuerung einer LED-Anzeige.

* Erste Versuche zur Nutzung nur EINES Prozessors sowohl für die Decoder-, als auch für die Encoderfunktion verliefen aufgrund von Kollisionsproblemen im Timing erst einmal negativ, sollen aber irgendwann noch einmal angegangen werden.

---

---