CQ-Papagei Projektseite


Einführung

Der CQ-Papagei oder auch CQ-Rufer genannt dient dazu, einen aufgesprochenen Text (i.A. den CQ-Ruf) auf Anforderung abzuspielen und damit einen Transceiver zu modulieren und mit ihm auf Sendung zu gehen. Das Aufsprechen eines neuen Textes sollte ebenfalls einfach möglich sein.
Mein CQ-Rufer besteht benutzt einen ATmega8-Mikrocontroller sowie einen ISD2590 Sprachchip [1]. Die einfachere Steuerung (abgeschaut von DG7XO [2]) funktioniert via PTT:

  • die Wiedergabe wird durch kurzes Drücken der PTT eingeleitet und kann jederzeit durch erneutes Drücken der PTT beendet werden.
  • durch 2-maliges Drücken der PTT erreicht man eine Wiedergabe des Ansagetextes in einer Schleife, Beendigung ebenfalls durch PTT. Die Wiederholzeit ist einstellbar.
  • durch ein 3-maliges Drücken der PTT wird eine Aufnahme gestartet, welche nach Loslassen der PTT beendet ist. Nach der Aufnahme erfolgt eine testweise Widergabe über den eingebauten Miniatur-Lautsprecher.
Alternativ lässt sich die Steuerung auch über 3 Tasten ('Play','Repeat' und 'Record') ausführen, der Programmcode sollte in dieser Richtung flexibel änderbar sein.
Der CQ-Rufer ist als externes Gerät ausgeführt, es wird in die Mikrofon- und PTT-Leitung eingeschleift - in meinem Falle beim IC706MkIIG (Mikrofon = HM-103) welcher hauptsächlich bei mir verwendet wird. Bei meinem IC-251 wäre übrigens auch genug Platz für die pfiffige (DG7XO) Einbaumethode 'intern'.

Zusätze:

  • 3 LEDs zeigen den momentanen Betriebszustand des CQ-Rufers an, 'Bereit', 'Wiedergabe' oder 'Aufnahme'. Da das Gerät als externer Zusatz aufgebaut werden soll, besteht die Möglichkeit, eine komfortablere 3-Tasten-Steuerung zu benutzen [3].
  • Tbd: Roger-Beep
  • Tbd: DTMF-Ausgabe, [4]

Hardware - digital -

Zum Einsatz kommt ein ATmega8, obwohl in der Version mit kleinstem Funktionsumfang auch ein 2K-AVR (z.B. AT90S2313 bzw. dessen Nachfolger) ausreichend wäre - abgesehen von den benötigten I/O-Pins.
Die Bilder zeigen verschiedene Aufbauzustände des 'digitalen' Teils der Hardware. Zunächst befindet sich alles auf einem Steckboard (breadboard), der Analogteil benutzt im Wesentlichen nur die Funktionalität des Chips selber, die Signalwiedergabe ist hier leider noch sehr leise.

CQ-Rufer (Digitalteil) auf Breadboard

Die funktionierenden digitalen Schaltungsteile sowie ein 5V-Regler mit Verpolungsschutz wandern nun auf eine Lochrasterplatine, um der Entwicklung und dem Test der analogen Schaltungsteile mehr Raum zu lassen.

CQ-Rufer (Digitalteil) auf Lochrasterplatine

Damit die von mir geplanten (optionalen) Erweiterungsmöglichkeiten des CQ-Rufers auch wirklich möglich sind, müssen einige Anschlüsse am ATmega8 gegenüber dem Original-DG7XO-Schaltbild anders beschaltet werden:

  • da kein Schwingquarz bzw. Quarzoszillator zum Einsatz kommen wird, werden diese Anschlüsse für LEDs benutzt, falls man die Fuse-Bits des AVRs versehentlich "verbrennt" ist eine "Reparatur" in der Schaltung dann allerdings nur noch schwerlich möglich
  • die Pins SDA und SCL müssen für zukünftige Erweiterungen freigehalten werden, d.h. der ISD2590 darf hier nicht angeschlossen werden, zukünftige Erweiterungen wären eine 12-er-Tastatur (DTMF) oder ein LCD-Display (eher unwahrscheinlich)
  • falls das Programm einmal komplexer wird, sollte zumindest TxD frei gelassen werden, damit ist ein Debugging via Terminal-Programm mölich (bei DG7XO auch der Fall)
  • für zukünkftige, DTMF-basierende Optionen sollte zumindest ein OC*-Ausgang frei gehalten werden

Hardware - analog -

Der CQ-Rufer soll als externes Zusatzgerät zu meinem IC706 betrieben werden. Um ihn am Transceiver anzuschliessen kann man entweder über die 8-polige RJ45 Buchse am Bedienteil oder an der Rückseite gehen oder die 14-polige Mini-DIN-Buchse der Rückseite benutzen. Letztere hat den Vorteil, dass dort auch gleich 13,8 V mit ausreichender Belastbarkeit zur Verfügung stehen, während die 8-polige Buchse nur 8 V mit max. 10 mA zur Verfügung stellt [5].Die Ansclüsse 'MIC' (Pin 5) und 'MICE' (Pin 6) der vorder- bzw. rückseitigen RJ45-Buchse sind bis auf einige Serieninduktivitäten identisch, wogegen der Anschluss 'MOD' (Pin 11) der 14-poligen Buchse im Trx erst nach dem Mikrofonverstärker/Kompressor-Schaltkreis aufgeschaltet ist [6].
Eine nicht zu vergessende Erschwernis bei der externen Montage stellt noch eine ggf. erforderliche Potenzialtrennung dar, um Brummschleifen und dgl. zu vermeiden.

Um die Einstreuung von HF zu vermeiden, sollten ähnliche LC-Kombinationen (100 uH, 2,2 nF), wie sie sich an den MIC-Eingangssignale des IC-706 befinden, auch zum Einsatz kommen.

Während der Entstehung bzw. Verbesserung der Schaltung des CQ-Rufers habe ich mich auch ein bisschen mit der freien Version von Eagle beschäftigt, so dass eine recht finale Version der Schaltbilder hier schon mal abgebildet ist. Da dies meine ersten Gehversuche mit Eagle sind, ist leider noch nicht alles so perfekt - aber es ist immerhin besser, als alles auf Skizzen und Fresszetteln zu dokumentieren.

Beschaltung des Mikrocontrollers
Ankopplung an den Trx
CQ-Papagei Schaltung CQ-Papagei Verdrahtung

Zum Vergrössern jeweils bitte anklicken!

Das Schaltbild für die Ankoppelung an den Trx, zeigt einige Jumper-Felder sowie Schaltungsteile, die man am Ende nicht mehr braucht, aber diese Komponenten erleichtern die Entwicklung bzw. das Testen von verschiedenen Varianten. Damit man das Mikrofon mit dem CQ-Papagei alleine austesten kann, ist die Orginal-Phantomspeisung für das HM-103 hier nachgebildet, die Details stammen aus [6].

Wie ich bei meinen Versuchen festgestellt habe, ist es möglich das HM-103 über eine Kapazität mit dem ISD-Sprachchip zu verbinden, das Signal ist stark genug, dass der ISD etwas Abspielbares aufzeichen kann. Trotzdem enthält dieser Testaufbau einen Verstärker, dessen Verstärkung man zwischen 1 und 10 variieren kann, für etwas weniger optimale Anwendungsfälle. Möglicherweise ist dann aber der Wiedergabepegel des ISDs für die Anschaltung an den TRX schon zu gross. Andererseits wäre es wünschenswert, wenn man bei der Wiedergabe eine Art Monitor-Option hätte, vielleicht lässt sich hier ja ein LM386 noch separat einsetzen.

Eine weitere Option, die ich mir gegenwärtig noch offenhalte, ist die Verwendung von Analogschaltern anstelle von Relais, hier habe ich den 74HCT4053 ins Auge gefasst.

Das nächste Bild zeigt dann den Schaltungsteil zur Transceiver-Ankoppelung ebenfalls auf einer Lochrasterplatinen aufgebaut, den Drahtverhau auf dem Steckboard zum Testen der Anschaltung habe ich nicht solange leben lassen, um noch ein paar abschreckende Fotos herzustellen.

Platinen zur Ankopplung an den Trx

Am linken oberen Bildrand ist das Mikrofon über einen 8-pol Stecker angeschlossen. Die Relais sind bewusst nicht auf der Lochrasterplatine sondern über kurze Drähte angeschlossen, wegen der vielen Optionen gibt es viele Pfostenstecker auf der Exp.-Platine. Die Spannungsregler auf der rechten Seite sind für 12V und 8V, die Relais sind (abweichend von DG7XO) ebenfalls für 12V ausgelegt. Im endgültigen Aufbau werden jedoch nur noch ein 8V- und ein 5V-Low-Power-Spannungsregler benötigt, alles andere kann an der 13.8V betrieben werden (evtl. noch 1-2 Si-Dioden dazwischen).


Software

Programmiert wird der Mikrocontroller in C unter Linux (unter Windows mittels AVR-Studio und WinAVR wäre es auch möglich), d.h. der Programmcode basiert auf dem durch den AVR-GCC verfügbar gemachten Sprachstandard. Dies wäre insbesondere bei der Übernahme und Anpassung des Original-Atmel-DTMF-Codes [4] zu berücksichtigen.

Sämtliche, die externe Beschaltung des ATmega8 betreffenden Festlegungen werden in Form von '#define' Preprozessor-Direktiven festgelegt. So war z.B. die Umdefinition der Anschlüsse des ISD2590-Sprachchips am AVR eine Kleinigkeit, nach Neukompilieren steht dann sofort wieder eine funktionsfähige Software zur Verfügung.
In gleicher Weise sind auch die Funktionen zum Ansprechen von Relais, LEDs oder PTT als Makros unter Ausnutzung der obigen '#defines' geschrieben, das hält den Code recht kompakt - was aber angesichts des Gesamtumfangs eigentlich nicht notwendig wäre. Dass dieser Programmierstil mancherorts verpönt ist, ist mir bekannt, stört mich aber nicht.

Die Warteschleifen in der Software sowie das Entprellen der Tastenabfrage ist nicht über Interrupts realisiert, so lässt sich das Programm einfacher halten. Während Aufnahme und Wiedergabe wird die PTT ständig abgefragt, um dann den gerade laufenden Vorgang abzubrechen. Lediglich die Abfrage des !EOM-Pins des ISD-Sprachchips löst den INT0-Interrupt aus, der eine Flagge setzt, welche bei der Wiedergabe ausgewertet wird und zur Beendigung dieser führt.
Notwendig wäre es auch, den !OVF-Pin auszuwerten, um eine Aufnahme über das Pufferende hinaus des ISDs zu vermeiden.

Ohne die oben als Optionen beschriebene Zusätze (DTMF, ...) passt der Code in etwas mehr als 1 KByte rein, d.h. der ATmega8 ist von daher zu eigentlich zu gross gewählt (Mit dem neueren avr-gcc 4.2.2 und avr-libc 1.6.x werden es sogar weniger als 900 Bytes!).


Referenzen