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.