Hier wollen wir euch einmal die verbaute Technik ein wenig näher vorstellen.
Das HF-Frontend
Als HF-Frontend nutzen wir jeweils Motorola GM-1200 Geräte, die über einen Procom 70/6-Duplexer an die Antenne, eine Diamond X-30, gebracht werden. Im Empfangszweig sitzt noch ein Empfangsverstärker, der das Signal nochmal um einige dB anhebt und damit den Empfänger, der sowieso schon eine gute Grundempfindlichkeit besitzt, noch hellhöriger macht.
Wie man dem Meßprotokoll entnehmen kann, sind die entsprechenden Notch-Filter auf der Eingabe (431.050 MHz) und der Ausgabe (438.650 MHz) mit jeweils -105,96 dB (RX-QRG auf Ausgabe) und -104,97 dB (TX-QRG auf Eingabe) entsprechend effizient wirksam.
Hier sieht man übrigens mal noch ein Bild mit den technischen Daten des LNA, der im Empfangszweig sitzt:
Aktivierungslogik des Repeaters
Der Repeater ist trägergesteuert, ohne CTCSS-Subton. Um dies sauber zu realisieren, ist die Rauschsperre aktuell so eingestellt, dass diese nicht durch etwaige Störungen geöffnet wird.
Der Empfänger liefert ein RSSI-Signal, welches über eine nachgelagerte Elektronik in ein Squelch-Signal gewandelt wird, welches an den Steuerrechner (Raspberry Pi) geht, der daraufhin den Sender aktiviert und mit einer (frei konfigurierbaren) Nachlaufzeit von 20 Sekunden nach Abfallen des Eingangssignals und somit gleichzeitigem Entfallen des Squelch-Signals den Sender wieder deaktiviert.
Die NF wird aktuell über den Mikrofoneingang einer externen USB-Soundkarte vom Empfänger digitalisiert, digital gefiltert und nach einer Preemphasis (Anhebung der Höhen) über die interne Soundkarte des Raspberry Pi auf den Sender gegeben. Auch werden bei dieser Gelegenheit DTMF-Steuertöne aus dem Signal herausgeblendet, damit diese nicht auf die Ausgabe geraten und hier nur unnötige Geräuschkulissen erzeugen.
Steckerbelegung der Kabel zu den Zubehör-Buchsen der GM1200
Die Belegung der Signal-Kabel vom Sender/Empfänger zur Platine sind mit 25-poligen Sub-D-Buchsen-Steckern bestückt und sind nachfolgend belegt:
Hierbei dient auf der Empfänger-Seite der Schalter S1 als Abschaltmöglichkeit des internen Lautsprechers des Funkgerätes.
Interface zu den Funkgeräten
Der aktuelle Stand der elektrischen Anbindung der Funkgeräte entspricht folgender Schaltskizze:
SV1 stellt hierbei die GPIO-Schnittstelle des Raspberry Pi dar. Hier werden die Pins 9 (Masse), 7 (PTT) und 5 (Squelch-Signal) verwendet.
Die PTT-Schaltung erfolgt über einen NPN-Transistor (beispielsweise BC547).
Die mit 2510-5 bezeichnete Anschlussleiste beherbergt folgende Verbindungen:
X1-1: PTT-Leitung vom TX | X1-6: GND (Mikrofon) USB-Soundkarte |
X1-2: GND vom TX | X1-7: Mikrofon-Eingang USB-Soundkarte |
X1-3: NF-In vom TX | X1-8: NF-Out (1k2) vom RX |
X1-4: Lautsprecher-Ausgang Soundkarte | X1-9: GND vom RX |
X1-5: GND (Lautsprecher) Soundkarte | X1-10: RSSI-Signal vom RX |
Die einzelnen Signalleitungen der Funkgeräte sind über Trimmer voranpassbar.
Eine Besonderheit stellt hier das RSSI-Signal auf Pin X1-10 dar: Dieses wird über einen Arduino Nano in ein 5V-Squelch-Signal umgewandelt, welches durch einen 2N7000 FET und entsprechender Beschaltung auf 3.3V reduziert wird, damit der Raspberry Pi dies über den Input-Kanal verarbeiten kann.
Steuerprogramm des Arduino Nano
Der Quellcode des Arduino Nano für die SQL-Signalermittlung sieht aktuell folgendermaßen aus:
int rssiPin = A3; int refPin = A4; int rssi = 0; int ref = 0; void setup() { delay(2000); // Startverzögerung 2 Sekunden pinMode(13, OUTPUT); // setzt Pin 13 als Ausgang } void SchalteSQLSignalAn() { digitalWrite(13, HIGH); // schaltet SQL-Signal auf Pin 13 } void SchalteSQLSignalAus() { digitalWrite(13, LOW); // deaktiviert SQL-Signal auf Pin 13 } void loop() { // wird nach setup() permanent wiederholt rssi = analogRead(rssiPin); // liesst Analogeingang (RSSI) ref = analogRead(refPin); // liesst Analogeingang (Referenz) if (rssi > ref + 20) { // wenn Schaltschwelle überschritten SchalteSQLSignalAn(); // wird das SQL-Signal aktiviert } if (rssi < ref) { // wenn Schaltschwelle unterschritten SchalteSQLSignalAus(); // wird das SQL-Signal deaktiviert } }
Livestream-Technik
Der Livestream wird mittels Doppelung des Audio-Outputs und Generierung eines mp3-Streams erzeugt. Dies geschieht folgendermaßen in der svxlink.conf:
[MultiTx] TYPE=Multi TRANSMITTERS=Tx1,StreamingTx [StreamingTx] TYPE=Local AUDIO_DEV=alsa:plughw:0 AUDIO_CHANNEL=0 PTT_TYPE=Dummy TX_DELAY=0 PREEMPHASIS=0
Das Loopback-Device ist hier als Card-0 im System adressiert und übernimmt den Audio-Stream als 2. Sender, der in der [MultiTX]-Sektion definiert wurde.
Diese Audiostream wird nun durch ices2 zum Streaming-Server gesendet. Die ices2.xml-Konfigurationsdatei sieht hier folgendermaßen aus (Passwörter mit *** maskiert):
<?xml version="1.0"?> <ices> <!-- run in background --> <background>0</background> <!-- where logs go. --> <logpath>/var/log/ices</logpath> <logfile>ices.log</logfile> <!-- size in kilobytes --> <logsize>2048</logsize> <!-- 1=error, 2=warn, 3=infoa ,4=debug --> <loglevel>4</loglevel> <!-- logfile is ignored if this is set to 1 --> <consolelog>0</consolelog> <!-- optional filename to write process id to --> <!-- <pidfile>/home/ices/ices.pid</pidfile> --> <stream> <!-- metadata used for stream listing --> <metadata> <name>DB0VKS</name> <genre>Amateur Radio</genre> <description>Livestream von DB0VKS</description> <url>https://db0vks.de</url> </metadata> <!-- Input module. This example uses the 'alsa' module. It takes input from the ALSA audio device (e.g. line-in), and processes it for live encoding. --> <input> <module>alsa</module> <param name="rate">48000</param> <param name="channels">2</param> <param name="device">hw:Loopback,1,0</param> <!-- Read metadata (from stdin by default, or --> <!-- filename defined below (if the latter, only on SIGUSR1) --> <param name="metadata">0</param> <param name="metadatafilename">/tmp/test</param> </input> <!-- Stream instance. You may have one or more instances here. This allows you to send the same input data to one or more servers (or to different mountpoints on the same server). Each of them can have different parameters. This is primarily useful for a) relaying to multiple independent servers, and b) encoding/reencoding to multiple bitrates. If one instance fails (for example, the associated server goes down, etc), the others will continue to function correctly. This example defines a single instance doing live encoding at low bitrate. --> <instance> <!-- Server details. You define hostname and port for the server here, along with the source password and mountpoint. --> <hostname>stream.db0vks.de</hostname> <port>8000</port> <password>***</password> <mount>/stream</mount> <yp>0</yp> <!-- allow stream to be advertised on YP, default 0 --> <!-- Live encoding/reencoding: channels and samplerate currently MUST match the channels and samplerate given in the parameters to the alsa input module above or the remsaple/downmix section below. --> <encode> <quality>0</quality> <samplerate>48000</samplerate> <channels>1</channels> </encode> <!-- stereo->mono downmixing, enabled by setting this to 1 --> <downmix>1</downmix> </instance> </stream> </ices>
Nach weiterer Testphase ist eine Umstellung der Quell-Software auf ffmpeg vorgenommen worden. Dieses Tool wird aktuell mit folgenden Parametern gestartet:
ffmpeg -ac 1 -f alsa -i hw:Loopback,1,0 -acodec libmp3lame -ab 32k -ac 1 -content_type audio/mpeg -f mp3 icecast://source:…
Als Streaming-Server dient wiederum ein icecast2-Server, der durch einen vorgeschalteten Apache2-Proxy per SSL (https) erreichbar gemacht wird, damit auch moderne Browser mit embedded-Playern keine Probleme machen.
Noch mehr Fotos
Hier mal noch ein paar Fotoeindrücke des Repeaters: