AnyTone AT-D878UVII V2 PLUS - Teil 2

Was ich von der AnyTone Codeplug-Software (CPS) halte, hatte ich im vorherigen Beitrag schon zum Ausdruck gebracht. Außerdem bin ich Linux-Nutzer und weiche nur im Notfall auf Windows aus. Deshalb hatte ich mich schon seit längerem mit qdmr beschäftigt. Mittlerweile hat diese freie Software einen hohen Reifegrad und läuft gut unter Linux. Hervorzuheben ist die automatische Vervollständigung von Relais-Eingaben über den Relais-Namen. Dazu wird im Hintergrund bei https://radioid.net, https://www.repeaterbook.com und https://repeatermap.de gesucht und Treffer werden vorgeschlagen bzw. nach Auswahl werden die Daten automatisch in die Felder eingesetzt. Damit lassen sich zügig und fehlerarm Kanäle erfassen. Leider haben die beiden letztgenannten vor einigen Monaten den Zugriff auf ihre APIs eingeschränkt, so dass zur Nutzung ein individueller Access-Token beantragt werden muss. Von Repeatermap erhielt ich den recht zügig und hatte noch einen netten Mail-Verkehr mit dem Betreiber (Martin, DK3ML), da ich der erste war, der einen Token beantragt hat. Von Repeaterbook ist der Token verweigert worden mit dem Hinweis, dass qdmr zwischenzeitlich eine sogenannte "approved app" sei und ich den Token nochmals hier beantragen soll.

Für die Entscheidung der API-Betreiber, einen Access-Token einzuführen, habe ich Verständnis. Leider gibt es im Internet zu viele Trittbrett-Fahrer, die freies geistiges Eigentum / Arbeit anderer für sich nutzen und ggf. noch vermarkten.

Das Problem mit dem API-Token bei Repeaterbook betrifft auch eine Software, die ich für OpenGD77 geschrieben hatte. Dort ist es mir aber gelungen, einen Access-Token zu bekommen. Das führte zum Entschluss, eine Software zur Erzeugung von qdmr-Kanälen und -Zonen zu entwickeln. Das hat zusätzlich den Vorteil, dass Kanäle in qdmr nicht mehr manuell erfasst werden müssen. Die Lernkurve, um kompatible qdmr-Daten (YAML) zu erzeugen war steil, aber ein Prototyp funktioniert jetzt. Wenn der hinreichend stabil ist, werde ich die Software auch auf Github veröffentlichen. Jeder Nutzer muss allerdings einen separaten Access-Token bei Repeaterbook beantragen.

Jetzt kann ich jedenfalls nach eigenen Vorstellungen den Codeplug für mein AnyTone erzeugen. Das läuft über Abfragen bei Repeaterbook mit Filtern für Standort, Umkreis, Frequenzband (2m, 70cm) und Modulationsart (FM, DMR). Zusätzlich werden Kanallisten im OpenGD77-Format mit verarbeitet für Direktfrequenzen und Hotspots, die in Repeaterbook nicht zu finden sind. Eine weitere Zone für Seefunk konnte ich einrichten, das AnyTone ist mit den aktuellen Frequenzbändern auch in der Lage auf Seefunk-Kanälen zu senden (nur für den Notfall, versteht sich).

So allmählich werde ich warm mit der Bedienung des AnyTone, trotzdem ist OpenGD77 in Bereich Bedienbarkeit mein Favorit.

Bleibt ein weiterer Kritikpunkt am Gerät: Die extrem leise Modulation. Im Einstellungsmenü lässt sich die Mikrofonverstärkung zwar in 5 Stufen einstellen, aber selbst in der höchsten Stufe ist die Modulation zu leise. Nach längerer Recherche im Internet bin ich auf eine Seite mit Tipps und Tricks zum AnyTone gestoßen. Dort wird das Menü für einen erweiterten Test und Einstellungen beschrieben, das mich weiter gebracht hat. Dort stand bei meinem Gerät im Kanal 65 der Wert 166, der eigentlich nicht einstellbar ist.

Kanal 65 mit irritierendem Mic-Gain-Wert

Nachdem ich mit dem Drehregler einen anderen Wert (0 – 63 ist möglich) eingestellt hatte, hat sich das Lautstärke Problem erheblich entschärft. Die Mic-Einstellung Level 5 muss ich trotzdem beibehalten, alles andere wäre zu leise und noch etwas mehr Lautstärke wäre wünschenswert. Aber ich hoffe, damit kann ich das Gerät erst einmal nutzen. Ich bin gespannt auf die Rückmeldungen meiner QSO-Partner.

AnyTone AT-D878UVII V2 PLUS Neuanschaffung

Seit Ende April liegt ein gebrauchtes Handfunkgerät AnyTone AT-D878UVII V2 PLUS bei mir im Shack und wartet auf Programmierung. Aber der Reihe nach. 

AT-D878UVII V2 PLUS

Meine bisherigen DMR-Funkgeräte basieren alle auf OpenGD77 und mit der Firmware bin ich nach wie vor hoch zufrieden. Doch seit einiger Zeit suche ich ein Gerät, um legal im Auto während der Fahrt zu funken. § 23 Abs. 1a StVO ist da recht eindeutig. Da ich VOX während der Fahrt meinen QSO-Partnern nicht zumuten mag und auch befürchte, dass durch Fahrgeräusche gesendet wird, fällt das flach. Drahtlose Headsets im Ohr gefallen mir auch nicht, deshalb ist mein Ziel, die Kopplung mit der Freisprecheinrichtung im Fahrzeug. Das hat auch den Vorteil, dass die eingebauten Lautsprecher und das Mikrofon des Fahrzeugs verwendet werden und keine Einbauten notwendig sind.

Es gab ein interessantes Projekt (bt-trx) von DC1MIL und DL1COM, die einen Adapter entwickelt haben, um beliebige Funkgeräte über Analoganschlüsse mit dem Fahrzeug zu koppeln. Neben AD-/DA-Wandlern gehört eine Bluetooth-Schnittstelle mit HFP-Protokoll dazu. Leider ist der verbaute Bluetooth-Chip mittlerweile aufgekündigt und nicht mehr im Markt verfügbar. Es gibt zwar Nachfolgechips, aber offensichtlich ist niemand bereit oder fähig, das Projekt entsprechend anzupassen (Hardware-Design, Firmware-Anpassung). Mir ist es gelungen, ein Gebrauchtexemplar zu kaufen. Das konnte ich zwar erfolgreich mit dem Autoradio koppeln, aber die Lautsprecher bleiben stumm und auch modulieren kann ich nicht. Bei Messungen auf der Platine bin ich zum Schluss gekommen, dass genau der nicht mehr lieferbare Chip wohl defekt ist. Also Schrott bzw. Ersatzteile für die Bastelkiste.

Im Frühjahr hat dann ein OM in unserem OV sein AnyTone Handfunkgerät erfolgreich mit seinem Autoradio gekoppelt. Das war der Auslöser für mich, statt Adapter gleich ein ganzes Funkgerät mit Bluetooth zu erwerben. Leider habe ich die Kombination Bluetooth und OpenGD77 im (Gebraucht-)Markt nicht gefunden und so ist es ein AnyTone geworden, mit der Folge, dass ich mich in AnyTone-Firmware einarbeiten muss. Das hatte ich mir leichter vorgestellt, es folgte ein kleiner Kulturschock, da die Firmware aus Amateurfunk-Sicht unnötig komplex ist. Als Starthilfe stand mir ein Codeplug aus unserem C23-OV zur Verfügung (Danke an Bernd, DL1ZAP).

Die Codeplug-Software von AnyTone ist die nächste Zumutung. Läuft nur unter Windows (wie bei allen Mitbewerbern) und präsentiert eine Benutzerschnittstelle, wie sie unter Windows vor 20 Jahren mal aktuell war. Die Menge an Fenstern und Optionen ist unübersichtlich und erschlägt mich förmlich. Der OV-Codeplug ließ sich problemlos laden, die Überraschung kam dann beim Schreiben auf das Gerät: Abbruch wg. falschen Frequenzbereichen. Die Frequenzbereiche passten aber und nach Recherche im Internet dann die Lösung: Der gesamte Codeplug muss im CSV-Format exportiert werden, dann erst einmal einen (leeren) Codeplug vom Gerät einlesen und dann die CSV-Daten wieder einlesen und dann kann alles auf das Gerät geschrieben werden ohne Fehlermeldung. Offensichtlich ist die Software recht empfindlich gegenüber Firmware-Differenzen (bei mir ist V4.00 installiert). Mit dem so betriebsfähigen Gerät konnte ich dann erfolgreich die Kopplung mit dem Autoradio erstellen. Mit im Lieferumfang war eine Bluetooth-PTT, die noch angelernt werden musste und die jetzt per Klettband am Lenkrad befestigt ist. Ich bin gespannt auf die ersten QSOs und Rückmeldungen bzgl. Modulation.

Dann die nächste Überraschung. Durch OpenGD77 bin ich es gewohnt, Zonen, Relais, Talkgroups (TGs) und Timeslot (TS) per Drehregler bzw. Tastendruck schnell zu verstellen. Die (verkürzte) TG-Liste kann je Kanal im Codeplug zugewiesen werden und man kann die bevorzugten TGs schnell durchklicken, der TS wird mit „*“ umgeschaltet. Beim AnyTone funktioniert das nur mit den Zonen und Relais, der TG-Wechsel (bei mir P2) führt immer zur gesamten TG-Liste und muss mit mehreren Klicks vollzogen werden. Gleiches gilt für den TS-Wechsel. Deshalb hat der Autor des OV-Codeplugs in den Kanälen feste TGs und TS programmiert und die TG sowie TS mit in der Relaisbezeichnung aufgeführt. Das erhöht die Kanaleinträge beträchtlich, da jetzt das Produkt aus benötigten TGs, TS und Kanälen abgespeichert werden muss.

Alternativ kann man beim AnyTone die bevorzugten TGs (also Kontaktgruppen) auch an den Anfang der Liste setzen und die häufigsten privaten Kontakte an das Ende der Liste. Dann ist man beim Scrollen in der Liste jeweils schnell am Ziel und kann die mehrfach abgespeicherten Kanäle vermeiden. Die TS-Umschaltung lässt sich auf eine Taste (z.B. PF1) legen. Das ist der Punkt, wo der Wunsch nach einem selbst erstellten Codeplug aufkommt.

Fortsetzung folgt.

Weiterer DMR Zugang: Retevis RT90

Da ich mit meinen beiden DMR-Geräten, die mit OpenGD77 laufen, zufrieden bin, war ich auf der Suche nach einem Stations-/Mobilgerät für DMR. Idealerweise sollte es auch mit OpenGD77 laufen, damit ich nur einen Codeplug für alle DMR-Geräte pflegen muss. Da blieb eigentlich nur das Retevis  RT90 bzw. das baugleiche TYT/Tytera MD-9600 Dual Band. Der Suchauftrag bei Kleinanzeigen.de für ein Gebrauchtgerät wurde endlich fündig und auch der Preis war nach einiger Zeit interessant. Nach kurzem Nachrichtenaustausch auf der Plattform waren wir uns einig und heute kam das Gerät mit der Post an.

OpenGD77 war statt der Orignalfirmware  schon installiert und so konnte ich sofort meinen Codeplug aufspielen und testen. Alles funktioniert wie erwartet. Trotzdem habe ich die Firmware auf die neuste Beta aktualisiert und auch ein deutsches Sprachmodul mit installiert.

Retevis RT90 mit OpenGD77

Nach einem ersten QSO mit einem Funkfreund wurde die Modulation als gut beurteilt. Der kleine Lüfter auf der Rückseite läuft automatisch beim Senden an und ist nicht gerade leise. Beim Empfang bleibt der Lüfter aber ausgeschaltet. Trotz QSO mit 40 W Ausgangsleistung wurde das Gerät nicht warm. Vielleicht finde ich auch noch eine Lüftersteuerung, so dass der Lüfter beim Senden geregelt wird. Wird fortgesetzt.

APRS im 2m-Band

Vor einiger Zeit hatte ich von meinen Versuchen mit APRS und DMR berichtet. Da ich aber auf meinen Hunderunden meist per FM über unser Hausrelais (DB0MIR) funke, wurden keine Positionsdaten übermittelt. Da OpenGD77 aber auch FM-seitig eine APRS-Bake anbietet, war mein Ehrgeiz geweckt. Das Feature hatte ich aber gehörig unterschätzt, um ein amerikanisches Idiom zu benutzen: Down the Rabbit Hole 😎.

Zunächst habe ich im Codeplug für das RT3S die APRS-Bake definiert.

2m-Band Bake

Danach die Bake in die Kanaldefinition für unser Hausrelais übernommen.

Kanaleinstellung mit APRS-Bake

Das wars - dachte ich. Nach der nächsten Runde mit dem Hund rief ich die WebSite aprs.fi auf und sah leider keinen Track meiner Tour. Offensichtlich war ich nicht im Empfangsbereich von 2m-Band-iGates. Das nächstgelegene iGate liegt in Langerringen leider hinter einem Höhenzug und ist nicht erreichbar, dafür sollte der Tegelberg (DB0OAL) per Luftlinie erreichbar sein, was per FM auf dem 70cm-Band kein Problem ist. Aber DB0OAL hat mich ignoriert. Der nächste Versuch fand dann mit der X30 auf dem Hausdach statt und damit gelangen Verbindungen zum Tegelberg und nach Hausham (DB0PM). Damit war klar, dass die Gerätekonfiguration stimmt und die Daten gesendet werden.

Wenn kein 2m-Band-iGate in Reichweite ist, muss man selbst eines bauen. Mit einem Quansheng UV-K5, dem AIOC und einem Raspberry Pi lag passende Hardware herum. Eine Web-Recherche brachte mich zu Direwolf und YAAC. Also schnell ein frisches Raspberry Pi OS auf eine SD-Karte kopiert, Direwolf übersetzt und konfiguriert und das Ergebnis mit YAAC visualisiert. Nebenbei war das auch ein Ritt durch ca. 30 Jahre Packet-Radio-Historie, um zu verstehen, was ich da konfiguriere. Vorläufig ist mein iGate nur ein Provisorium, aber damit war es möglich, meine Hundespaziergänge aufzuzeichnen - QED.

Im Funkgerät hinterlegte APRS-Baken (max. 8 sind möglich) können auch direkt am Gerät eingestellt werden. Hier mit Bildern vom Baofeng DM-1701 dargestellt, weil dies gerade auf dem Schreibtisch lag 😇.

Zuordnung APRS zum Kanal

Im Hauptbildschirm wird oben rechts durch ein kleines "a" das aktive APRS symbolisiert, FMa steht für wide-FM + APRS. NFMa wäre dann narrow-FM + APRS.

FMa: wide-FM + APRS, CTR: TSqelch, Senden, 500 mW, Batterie voll

Die Sendefrequenz der Bake wird durch den APRS Modus beeinflusst. Die Wahlmöglichkeiten sind im OpenGD77 Manual erklärt.

APRS Modus-Auswahl

Die Sendeleistung der Bake kann separat eingestellt werden unabhängig von der Sendeleistung im Sprachkanal. Interessant ist auch die Checkbox "QSY für QSO" bei der APRS-Definition im ersten Bild. Dies bewirkt, dass die aktuellen Einstellungen des Sprachkanals als Kommentar zur Position mitgesendet werden. Damit ist beispielsweise aus aprs.fi heraus sichtbar, wie das getrackte Gerät aktuell erreichbar ist.

Position mit QSY

C123 beschreibt den Subton (CTCSS 123 Hz) und -760 die Ablage des Relais (-7,6 MHz).

AIOC - All In One Cable

Mein Mecklenburger Hotspot hat vor einiger Zeit seine Dienste arg reduziert. Bemerkt hatte ich das durch eine stark nachlassende Reichweite beim Sendebetrieb, die Empfindlichkeit beim Empfang war unverändert. Die Endstufe im SHARI-Hotspot bringt offensichtlich keine Leistung mehr. Probehalber hatte ich den Raspberry Pi, der auch den SHARI mit Energie versorgt am Labornetzteil angeschlossen und die Differenz der Energieaufnahme zwischen Empfangs- und Sendebetrieb gemessen - da war kaum ein Unterschied messbar. Von den erwarteten 1 Watt Sendeleistung kommen vermutlich nur wenige Milliwatt bei der Antenne an. Auf Nachfrage in der ShariSpot-Telegram-Gruppe meldete sich ein OM, der das gleiche Problem hat. Er teilte mir mit, dass es eine Serie gab, die ein zu langes Gewinde am Antennenstecker hat, so dass die aufgeschraubte Antenne keinen zuverlässigen Mittenkontakt herstellt. Das war bei meinem SHARI auch der Fall und deshalb habe ich das Gewinde gekürzt. Damit ist aber die Endstufe nicht repariert. Bei Gelegenheit muss ich den SA818 auslöten und ersetzen.

Zwischenzeitlich lief mir aber ein anderes Projekt über den Weg, ein Adapter, der ein Handfunkgerät mit einem Rechner per USB-C verbindet. Das AIOC verfügt über 3 Schlüsselfunktionen:

1. USB-Soundkarte: Das AIOC erscheint als Standard-USB-Audio-Interface und bietet Mono-Mikrofoneingang und Mono-Lautsprecherausgang. Dadurch können die softwaredefinierten digitalen Schnittstellen Audio senden/empfangen.
2. Virtueller TTY/COM-Port: Der AIOC erstellt einen virtuellen seriellen Port, der als COM-Port auf Windows oder als /dev/ttyACM-Gerät unter Linux und MacOS dargestellt wird. Die serielle Schnittstelle dient zwei Zwecken. Erstens ermöglicht es dem AIOC, als Programmierkabel für das Radio mit Software wie CHIRP zu fungieren. Zweitens liefert es eine traditionelle Methode zur Push-to-Talk (PTT)-Taste, bei der die Software die seriellen Steuerleitungen (normalerweise DTR oder RTS) aktiviert, um zu senden.
3. HID-Endpunkt: Ab der Firmware-Version 1.2.0, erscheint das AIOC als Human Interface Device (HID), das eine universelle Eingabe / Ausgabe (GPIO) für PTT bereitstellt. Ab Version 1.3.0 kann das AIOC ein CM108 vollständig emulieren und ermöglicht so die Kompatibilität mit einer größeren Vielfalt von Software, einschließlich AllStarLink und SvxLink.

Damit war die Idee geboren, den SHARI erst einmal zu beurlauben und mittels AIOC eines meiner Handfunkgeräte (Quansheng UV-K5) mit dem Hotspot zu koppeln. Die oben verlinkte Artikelserie über das AIOC bezieht sich auf eine ältere Hard- und Software-Version. Bei mir kommt die Hardware-Version 1.2 zum Einsatz (Sleeve-Anschluss der 3.5mm Klinke ist geteilt: PTT / TxD) und die Software-Version 1.4.1 mit dem o.g. HID-Endpunkt.

Die Bestellung bei JLCPCB am 21.10. war dank der Anleitung von DL-Nordwest gut zu bewältigen und am 30.10. hielt ich die bestückten Platinen in der Hand.

Das Objekt der Begierde nach Aufspielen der Firmware

Zwischendurch kam ein Anruf vom Zoll in Deutschland über den Inhalt des Paketes, den ich offensichtlich zufriedenstellend beantworten konnte. Für 5 Platinen waren (nach Abzug eines Neukundenrabattes) umgerechnet 105,56 € fällig. Zwischenzeitlich hat ein befreundeter OM (der auch 2 Exemplare abnimmt) mit seinem 3D-Drucker passende Gehäuse und die notwendige Löthilfe für die Klinkenstecker gedruckt.

Löthilfe (oben), AIOC, Gehäuseteile (unten)

Beim Auspacken der bestellten Klinkenstecker stellte sich heraus, dass die 2,5 mm Variante von Lumberg (KLS 13) unpassende Lötanschlüsse hat (keine Lötfahnen). Glücklicherweise hatte der befreundete OM noch passende Stecker in der Bastelkiste, so dass ich gestern zumindest ein AIOC fertigstellen konnte.

Der erste Test mit CHIRP war (nach einem Downgrade von CHIRP, der nichts mit dem AIOC zu tun hat) erfolgreich. Danach kam der Raspi mit dem SHARI-Image zum Einsatz. Durch mehrere Versuche und Recherchen im Internet wurde dann klar, dass SvxLink bei den Soundkarten sehr wählerisch ist und nur den CM108-Chip von C-Media Electronics akzeptiert. Die Identifikation erfolgt über das Auslesen der USB-Id. Das AIOC emuliert zwar den CM108 vollständig, hat aber eine abweichende USB-Id. An dieser Stelle kommt dann der HID-Endpunkt ins Spiel. Mit Python-Skripten, die den AIOC-Release-Notes beigefügt sind, lassen sich diverse Register permanent verändern, so auch die USB-Id des Bausteins (ID 0d8c:000c, C-Media Electronics). Damit bleibt es fast bei den gleichen Einstellungen wie beim SHARI:

Rx:
AUDIO_DEV = alsa:plughw:0
HID_DEVICE = /dev/cm108gpio
HID_SQL_PIN = VOL_DN

/dev/cm108gpio wird durch eine udev-Regel erzeugt, die auch entsprechende Leseberechtigungen anlegt.

Tx:
AUDIO_DEV = alsa:plughw:0
PTT_TYPE = Hidraw
PTT_PORT = /dev/ttyACM0
PTT_PIN = DTRRTS
HID_DEVICE = /dev/hidraw0
HID_PTT_PIN = GPIO3

Mit diesen Einstellungen und dem UV-K5 als TRx konnte ich dann die ersten QSOs führen. Die Modulation hatte ich offensichtlich korrekt eingestellt, weil diesbezüglich die Rückmeldungen gut waren.

UV-K5 mit AIOC

Beim Provisorium auf dem Schreibtisch traten (trotz abgesetzter Antenne) EMV-Probleme auf, die durch Klappferrite, externe Antenne und verringerte Sendeleistung hoffentlich verschwinden.

 

Neuland APRS

Mein kürzlich angeschafftes RT3S hat einen GPS-Empfänger und der sollte etwas mehr tun, als nur die Entfernung zum Relais berechnen oder den Maidenhead-Locater anzuzeigen. Es müsste doch möglich sein, per APRS seine Position zu übermitteln, da openGD77 auch entsprechende Einstellungen kennt.

APRS bietet verschiedene Wege um die Positionsdaten ins Internet zum Map-Server zu transportieren, sogenannte Gateways. Das können Apps auf dem Smartphone sein, aber für Funkamateure interessanter ist die Übermittlung per Funk auf fest vorgegebenen Frequenzen auf vielen Bändern. Daneben gibt es noch sogenannte iGates, die mit geringen Sendeleistungen auf dem 70cm ISM-Band und LoRa-Modulation erreicht werden können. Bei LoRa verwendet man üblicherweise spezielle Tracker, die mit geringer Leistung permanent senden. Da ich die Position durch das RT3S übertragen will, kommt das nicht in Frage. Bei Nutzung einer vorgegebenen APRS-Frequenz kann man aber nur die Datenpakete senden und nicht parallel sprechen - das finde ich auch nicht so schön. Deshalb kam für mich die DMR-Variante in Frage. Dabei werden dem digitalisierten Sprachsignal Zusatzdaten (Talker Alias, APRS) hinzugefügt, so dass beim Auslösen von PTT auch Positionsdaten mit übermittelt werden. Daneben gibt es noch den Baken-Modus, bei dem in einem einstellbaren Zeitraster die Position an das Relais gesendet wird. Ich vermute, der Baken-Modus wird Relais-Betreiber nicht begeistern, da ständig aufgetastet wird und der Stromverbrauch unnötig steigt. Für permanente Positionsmeldungen sind LoRa-Tracker die bessere Option.

Voraussetzung für die Übermittlung der Positionsdaten ist ein Account im Brandmeister-Netzwerk, dort muss unter Selfcare folgendes eingestellt sein:

Brandmeister Selfcare Settings

Im openGD77 Codeplug muss dann noch die APRS-Übermittlung im Kanal eingestellt sein. 

Kanaleinstellung für APRS

Danach drückte ich erwartungsvoll die PTT-Taste um eine Auftastung bei unserem Haus-Relais (DB0MIR) vorzunehmen. Als rücksichtsvoller OM wählte ich die TG 9 (local) im TS 1, um möglichst wenige Zuhörer zu stören. Leider war meine Position auf dem APRS-Map-Server nicht zu sehen. Nach 1 1/2 Tagen erfolgloser Versuche und Parameter-Anpassungen dann die Erkenntnis: Auf TG 9 geht es nicht, da bleibt alles lokal und wird nicht ins Internet/Hamnet abgegeben. Auf allen anderen TGs funktioniert es UFB 😒.

Ergänzung vom 08.09.2025:  Beim Brandmeister Netzwerk basiert die Vergabe der Radio-ID Nummern auf dem ITU-MCC (Mobile Country Code), für Deutschland also 262. APRS-Meldungen können direkt an die ID MCC999 gesendet werden, in Deutschland also 262999. Die früher üblichen IDs 505x (x entspricht der APRS SSID), z.B. 5057 sollten nicht mehr verwendet werden, da der MCC 505 zu Australien gehört.

Quelle: https://bm262.de/gps-aprs-ziel-262999-nutzen/ 

Neuzugang: Retevis RT3S

Kürzlich lachte mich auf eBay eine Anzeige für das Retevis RT3S (baugleich mit dem TYT MD-UV380) zu einem attraktiven Preis an. Ich habe zwar ein DMR-Handfunkgerät, aber eben keins mit integriertem GPS. Ein weiteres Kaufargument ist die Option, ggf. eine M17 Firmware zu installieren (nach einer Hardware-Modifikation). Zwei Tage später konnte ich nicht widerstehen und heute kam das Gerät mit der Post. 

Mit der Firmware von Retevis habe ich mich gar nicht beschäftigt und gleich openGD77 aufgespielt. Danach kam der Codeplug vom DM-1701 drauf und schon war das Gerät einsatzbereit. 

Retevis RT3S

Die Rückmeldungen nach den ersten QSOs waren überwiegend positiv. Die Modulation passt, lediglich bei digitalem Betrieb musste ich die Mikrofonempfindlichkeit etwas erhöhen. Der Akku (2 Ah) hält mit eingeschaltetem GPS und 5 W Sendeleistung den Tag über durch.

Beim GPS (bzw. korrekter GNSS) dauert es etwas länger als beim Smartphone, bis der Sat-Fix da ist, kein Wunder, beim Smartphone wird mit A-GPS und WLAN gemogelt.

GPS Anzeige

Die Entfernung zum Relais wird jetzt angezeigt (erstes Bild) und in APRS muss ich mich noch einarbeiten. 

Im Vergleich zum Baofeng DM-1701 ist das Retevis RT3S etwas kleiner und handlicher, dafür fehlt eine Taste für das Kurzmenü, das durch eine Tastenkombination (SK1+grün) erreichbar ist. 

X-30 Nachbau auch im Süd-QTH

Nach den positiven Erfahrungen im Norden mit dem X-30 Nachbau habe ich mir die gleiche Antenne noch einmal für das südliche Domizil gekauft. Die Antenne lag schon einige Wochen im Shack und heute bin ich endlich dazu gekommen, sie zu montieren. Für die Krabbelei auf dem Dach war trockenes Wetter die Voraussetzung.

Blick vom First

Im Vordergrund rechts meine alte 2m/70cm-Selbstbauantenne

Die alte Antenne bleibt vorerst noch montiert, aber ich denke mittelfristig werde ich die abbauen.

Nach der schweißtreibenden Montage auf der Leiter und auf dem Dach kam der angenehmere Teil. Beim Test mit meinem Retevis RT-95 konnte ich die Relais in unserer Region problemlos auftasten und mit S9+ empfangen. Auch bei Direkt-QSOs mit befreundeten OMs aus meinem DOK wurde eine deutliche Verbesserung bestätigt.
 

SHARI Hotspot für FM-Funknetz

Die Funkabdeckung hier am QTH in Mecklenburg ist nicht so berauschend und in der Bastelecke lag noch ein alter Raspberry Pi 2. Der muss eine Aufgabe bekommen - und vor allem ich auch. Also habe ich mir zum Spielen ein Software-Image für das FM-Funknetz heruntergeladen vom Blog von DC9VQ. Damit konnte ich via Internet den Raspi mit dem FM-Funknetz verbinden und mich schon etwas einarbeiten. Es gab auch einige Hürden, die mit einer entsprechenden Telegram-Gruppe schnell gelöst wurden. Am Raspi war lediglich eine USB-Sprechgarnitur angeschlossen, mit der ich "funken" konnte.

Raspi 2 mit angeschossenem SHARI

Nachdem das gut funktionierte wollte ich natürlich auch einen eigenen Hotspot, also habe ich ein passendes 70cm Funkmodul bestellt (Portable SHARI SA818 Ham Allstar Radio Interface). Dazu gibt es ebenfalls ein vorbereitetes Image und Installationshinweise von DC9VQ mit denen ich schnell zum Ziel kam.

Auf der Live-Map des FM-Funknetz ist mein Hotspot schon zu sehen

Morgen auf der Hunderunde werde ich dann Reichweitentests mit dem Handfunkgerät durchführen. Das Funkmodul leistet 1 Watt und liegt im Obergeschoss unseres Hauses.

Update vom 27.05.2025: Auf der gesamten Hunderunde waren Verbindungen möglich, allerdings bei ca. 1 km Entfernung (3 - 5 W mit einer Diamond SRJ77) musste ich im Stehen funken, da beim Gehen das Fading zu stark wurde. Vielleicht hilft noch eine etwas höhere Antennenposition des Hotspots.

DTMF Mikrofon MH-59A8J

Im vorletzten Beitrag hatte ich schon die fehlenden DTMF-Töne beim FT-897D mit dem Basismikrofon (MH-31A8J) beschrieben und meine Bastelidee dazu. Zwischenzeitlich ist mir bei Kleinanzeigen.de ein günstiges gebrauchtes MH-59A8J über den Weg gelaufen und ich hatte zwischenzeitlich auch die Möglichkeit ein MH-36E8J auszuprobieren. Mit dem MH-36E8J war es schon sehr angenehm, allerdings fehlten weitere Fernsteuermöglichkeiten und etliche Tasten funktionierten nicht. Heute kam das MH-59A8J und hat mich wirklich begeistert, da viele Gerätefunktionen per Fernsteuerung mit dem Mikrofon möglich sind. Damit wird der gesamte Transceiver aufgewertet.

 

MH-59A8J

Es lassen sich u.a. folgende Funktionen direkt über das Mikrofon steuern:

• MHz Schrittweite
• RIT aktivieren
• IF Shift
• Sprung zur Home-Frequenz
• Mode-Umschaltung
• Wechsel zw. VFO- und Memory-Modus
• Band-Umschaltung
• Direkteingabe von Frequenzen
• 1750 Hz Burst
• Seitlicher Drehregler zur Frequenzeinstellung 

Ein kurzer Sprachtest mit der Papagei-Funktion des FM-Funknetz-Hausrelais hat auch die gute Sprachqualität des Mikrofons bestätigt. Jetzt warte ich mal ab, ob das in der Praxis von anderen OMs auch bestätigt wird.

 

X-30 Nachbau funktioniert gut

Heute bin ich endlich dazu gekommen, die vor einer Woche bestellte und mittlerweile gelieferte Antenne zu montieren. Es ist ein X-30 Nachbau mit der Bezeichnung "WUeTo X-30 PL".

WUeTo X-30 PL

Sie ersetzt meinen DIY-Dipol, der auf dem Bild links daneben noch zu sehen ist. Im Vergleich bringt die X-30 auf 2 m satte 6 dB  mehr. Damit kann ich jetzt problemlos mit den umliegenden Relais (DB0GMN, DO0RDG, DB0RUG, DB0FHS) arbeiten. Der Gewinn und die Anpassung auf 70 cm sind subjektiv etwas schlechter aber immer noch besser als mein Selbstbau.

Die Antenne macht einen stabilen und wetterfesten Eindruck. Lediglich die Fixierung der Antenne mit der Alu-Muffe durch nur einer Schraube macht einen kritischen Eindruck. Ich fürchte, dass sich durch Windbelastung und Schwingungen die Schraube lösen kann. Ich werde das beobachten und ggf. berichten.

Neue Erkenntnis zum Datenkabel

Im letzten Beitrag hatte ich ja das selbst gebaute Datenkabel beschrieben und die entsprechende Einstellung, damit WSJT-X funktioniert. Kürzlich kam mir die Idee, über das Datenkabel auch DTMF-Töne zu senden, damit ich bei den FM-Funknetz- und Echolink-Relais die Talkgroups ansteuern kann. Das FT-897 kann DTMF-Eingaben nur mit dem Zubehörmikrofon MH-36E8J senden, leider bin ich nur im Besitz des MH-31 ohne diese Tastatur.

Ein MH-36E8J kaufen ist zu einfach, also sollte ein kleines Programm auf dem PC die DTMF-Töne erzeugen und via Soundkarte an den Transceiver übermitteln. Leider musste ich jetzt feststellen, dass das Einspeisen von NF über die DATA-Buchse nur im Digitalmodus (DIG) funktioniert, bei FM kommt am Transceiver nichts an. Die Gründe für diese Designentscheidung kenne ich nicht und ich muss es wohl akzeptieren.

Belegung Mikrofonstecker

Deshalb überlege ich über einen RJ-45 Verteiler die Soundkarte beim Mikrofon mit einzuschleifen.

Neuanschaffung FT-897 und Datenkabel

Ein befreundeter OM erzählte mir von seinem Yaesu FT-897 und ich habe mir daraufhin die techn. Daten angesehen. Da mir noch ein Gerät für 2m und 70cm für SSB fehlte war ich gleich interessiert. Der FT-897 deckt von 80m bis 70cm alle Modi ab. Wie es der Zufall so wollte stach mir kurz danach bei eBay ein entsprechendes Angebot ins Auge und da sonst niemand darauf bot, war das Gerät kurz darauf meins.

Der FT-897 hat noch keine USB-Schnittstellen, daher habe ich für die CAT-Steuerung noch ein entsprechendes Kabel (CT-62) angeschafft. Damit ist die Steuerung möglich, allerdings können keine Daten vom oder zum Computer übermittelt werden. Dazu bietet der FT-897 eine DATA-Buchse, die unabhängig vom Lautstärkeregler die empfangene NF bereitstellt und auch einen Mikrofoneingang enthält. Die Buchse hat das Mini-DIN-6 Format, welches auch von PS/2-Schnittstellen älterer Rechner verwendet wird. Also war mein erster Ansatz eine alte Computer-Maus zu schlachten und das Kabel mit Stereo-Klinkensteckern für die Soundkarte des Rechners zu versehen. Beim Vergleich der Anschlüsse fiel mir aber auf, dass PS/2 nur 4 Leitungen verwendet und das sind genau die beiden fehlenden Leitungen werden aber bei der DATA-Buchse benötigt.

Also habe ich mir ein voll angeschlossenes Kabel mit Mini-DIN-6 Stecker bestellt und die Stereo-Klinkenstecker selbst angelötet. Vom Verlöten eines Mini-DIN-6 Steckers habe ich abgesehen, da mich mehrere OMs vor den kleinen Anschlüssen gewarnt hatten.

Verdrahtung Datenkabel

Der Test mit WSJT-X war zunächst enttäuschend. Im Wasserfall-Diagramm waren die empfangenen Signale sauber dargestellt, allerdings wurde nichts dekodiert. Erst nachdem ich beim FT-897 im Funktionsmenü den Menüpunkt 38 (DIG MODE) auf den Wert USER-U eingestellt hatte, klappte die Dekodierung einwandfrei.

WSJT-X Empfang mit dem FT-897

Neues Rufzeichen DA1TH

Diesen Winter habe ich gebüffelt und und am 18. Januar die Prüfung von der Lizenzklasse E zur Lizenzklasse A bestanden. Anschließend konnte ich das neue Rufzeichen beantragen und heute kam die Urkunde per Post ☺.

Deshalb habe ich die Subdomain und den Blog-Namen angepasst.

Danach habe ich dann bei radioid.net (DMR), QRZ, LoTW und beim DARC das neue Rufzeichen bekannt gegeben und die Änderung beantragt.

Neuanschaffung Retevis RT95 Vox und Bau Lüfterregelung

Damit ich im Shack nicht immer mit dem Handfunkgerät arbeiten muss, hatte ich mich nach preisgünstigen Mobilgeräten umgesehen. Im OV haben einige OMs das CRT Micron im Einsatz und die Suchmaschine hat auch Treffer auf das baugleiche Retevis RT95 angezeigt. Bei dem Preis musste ich nicht lange überlegen und auch die Rezensionen sahen gut aus. Der Nachteil ist, dass das Gerät keinen Lüfter hat (man kann es akustisch auch als Vorteil interpretieren) und beim Ausreizen der Sendeleistung (25 W sind angegeben) wird es schnell heiß.

Retevis RT95 Vox

Nach den ersten QSOs kam die Rückmeldung, dass die Modulation sehr leise sei. Durch Hinweise von OMs und auch im Internet kamen Hinweise, dass ggf. aktuellere Firmware die Möglichkeit zum Einstellen der Modulation (Mic Gain) ermöglicht. Kommunikation mit dem Verkäufer auf eBay und etwas Recherche im Internet förderten den entsprechenden Link zur Firmware (Support) zu Tage. Daraus geht hervor, dass es drei Versionen des Gerätes gibt (1) ohne Vox, (2) mit Vox und (3) mit Vox und aktueller Firmware (1.41/1.61). Glücklicherweise hatte ich die Version (3) erwischt, so dass kein Firmware-Upgrade mehr notwendig war. Die Dokumentation ist noch auf altem Stand und verschweigt den Menüpunkt zum Einstellen der Modulation.

Einstellung Mic Gain

Leider kann man mit der Programmier-Software die Versionsnummer nicht auslesen. Auch die Programmier-Software muss den Versionsstand 2.01 haben, damit darüber die Modulation eingestellt werden kann.

Programmier-Software mit Mic Level Einstellmöglichkeit

Mit der höchsten Einstellung (3) scheint die Modulation für meine Gesprächspartner akzeptabel zu sein. Zum Programmieren der Kanäle verwende ich allerdings CHIRP. Mit CHIRP lassen sich auch die obigen Einstellungen anpassen bis auf die Modulation. Einen entsprechenden Feature-Request habe ich beim CHIRP-Entwickler-Team hinterlassen.

Damit die 25 W max. Sendeleistung dauerhaft nutzbar sind, habe ich in meinen Hardware-Beständen gesucht und einen passenden 120 mm Computer-Lüfter gefunden, der auch mit 12 V läuft. Der Lüfter liefert ein Tacho-Signal und kann mit einer Pulsweiten-Modulation gesteuert werden. Passende Regelungen gibt es fertig zu kaufen.

Angezeigt wird die Temperatur und sobald der Lüfter anläuft wechselt die Anzeige zwischen der Drehzahl (in 10 U/Minute) und der Temperatur in °C. Jetzt fehlt nur noch eine vernünftige mechanische Befestigung für Lüfter und Regelung.