Motorola GM360 Konfigurationsbytes, DMR RX Problem

    Hallo Forum!

    ich versuche einen DMR Hotspot mit einem Motorola GM360 und einem RepeaterBuilder STM32 Digital Voice Modem zu bauen und stoße da auf unerwartete Probleme. Die TX Seite läuft nach einem sauberen Abgleich im Grunde problemlos, die RX Seite macht folgendes Problem: Nach einigen Sekunden Empfang geht das Gerät aus, resettet und geht wieder an. Nach einiger Recherche bin ich auf die Info gestoßen, daß es mit der Rauschsperre zu tun hat, die in diesen alten Analogfunken durch das ständige An- und Aus der DMR Zeitschlitze überfordert ist und dann irgendwann das Gerät abschaltet. Bei mir nach ca. 5 - 7 Sekunden. In einem Artikel wurde auf die Kunfigurationsbytes verwiesen, genauer auf Nr. 2. Hier soll der Wert 04 eingestellt werden um die Entprellung Rauschsperre um weitere Zyklen zu entprellen. Leider bringt das bei mir nicht die gewünschte Zuverlässigkeit und Betriebssicherheit. Kann mir irgendwer noch einen guten Tipp geben was ich noch besser machen kann? Bzw. gibt es Infos darüber, was die Kunfigurationsbytes bewirken? Ich bin ja nun nicht der erste der ein DMR Relais mit diesen Funkgeräten aufbauen will - aber Infos dazu habe ich biher nicht gefunden. Ich freue mich also über hilfreiche Hilfe! DANKE!

    Stefan, DL5STS

    Hallo!
    Das Problem mit den Konfigurationsbits ist das es nur ganz wenige Funktionen gibt, die über alle Firmwarestände gleich geblieben sind. Welche neuen Konfigurationsbits hinzu gekommen sind und was diese bewirken, steht ausschließlich in der Readme-Datei des jeweiligen Upgradetools.
    Vor gefühlt 10 Jahren mal hatte ich die idee all diese Informationen der Upgradekits gebündelt in einer übersichtlichen Funktionstabelle zu tippen. Habe ich aber aufgegeben - denn die Unterschiede sind von Firmware zu Firmware unterschiedlich und ältere wurden nicht mehr weiter genutzt, funktionieren also bei neuerer Firmware nicht mehr.
    Genau das scheint bei dir der Fall zu sein, und ist gleichzeitig der Grund weswegen noch niemandem eine übersichtliche Konfigurationsbit-Auflistung gelungen ist.

    Statt dessen Workaround: Bleibt der Fehler weiter bestehen, wenn du die Squelch komplett abschaltest?

    Nachtrag:
    Hab mal eben geguckt...in Konfigurationsbyte 2 war zuletzt das Bit 2 (= h04) lediglich eine Entprellung um Faktor 4 der Rauschsperre. Gegen DMR-Bursts dürfte diese aber machtlos sein. Besser wäre es die Rauschsperre komplett ab zuschalten und den Ton anderweitig zu killen. Denn weder Rauschen noch das TDMA-Rattern der DMR-Pakete will man hören. Also wahlweise Lautsprecher abziehen (im Bedienteil) oder mittels Tonrauschsperre oder CTCSS/DCS die NF abwürgen, so das diese nur am Flat-Audio Pin zum DVM gelangen, aber nicht über Lautsprecher.

    Jürgen

    Moin Jürgen,

    danke für die detaillierte Aufklärung! Ich habe hier parallel noch ein seltsames Phänomen beobachten können: 2 identische (?) GM360, beide zeigen in der CPS die selben Softwareversionen, verhalten sich aber sehr unterschiedlich. Auf den Geräten stehen die Versionsnummern R03.15.00 bzw. R02.07.05. Wobei die R03... die Probleme macht, die R02... funktioniert tadellos mit DMR-RX. Den Trick mit PL zur Knatterunterdrückung hatte ich eh schon angewendet, das ist hilfreich. Ich benutze also jetzt die R02... - erstmal als Hotspot und später im Relais dann für den RX. Die R03... hat als TX gut funktioniert. Kannst Du mir ggf. noch sagen ob es möglichwäre aus der R03... eine R02... zu machen?

    Gruß Stefan

    Moin Stefan,

    Welche Firmware die Geräte aktuell besitzen, zeigt die CPS om Codeplug an.
    Wären da bei beiden Geräten entweder R02.07.05 oder eben R03.15.00 dann hätte beide die gleiche Firmware. Was hingegen auf den Typenschilder steht ist eher irrelevant in Bezug auf die Firmware - denn da steht nur die Firmware ab Werkszustand.

    Merke R02.xx.xx oder R03.xx.xx ist die Firmwareversion! Die letzte und aktuellste die ich kenne ist die R03.16.00 wo du mit deiner R03.15 schon recht aktuellst wärst, wogegen eine R02.07...ziemlich alt anmutet.

    Zu deiner Frage ob man ein Downgrade von R03.15.00 auf R02.07.05 machen kann:
    Das wäre oberflächlich betrachtet vielleicht möglich, aber nur brutal und mit ungewissem Ergebnis. Denn der Downgrade wäre dann von der Controllerversion abhängig wo es durchaus einige Gab.
    Die TANAPA-Version gibt da eher eine grobe Vorahnung, viel aussagekräftiger wären die Boardnummern die auf der Platine eingeätzt sind. Mit dieser erfährt man dann welche Controller-Generation da drin steckt und wie man einen Downgrade stricken müsste, damit das Funkgerät eben kein Briefbeschwerer wird.

    Beim MMDVM in der Repeaterversion (Analoge Funkgeräteschnittstelle) ist mir bislang nicht klar wozu MMDVM im DMR Mode tatsächlich den Squelch benutzt. Taugen würde solch ein Squelch-Signal nämlich ausschließlich bei analogem FM.

    Es mag da draußen durchaus eine Handvoll Leute geben die meinen ein analoges Squelch-Signal nutzen zu können um den SDR-Signalpfad des Frontends zu entlasten. SDR wird nämlich ab dem AD-Wandler zu einer Datenflut die digital mit immenser Rechenpower schnell genug verarbeitet werden muss. Gerade Anfänger die aus dem analogen Funkbereich kommen, landen daher sehr schnell bei der These man könnte Strom oder Rechenpower/Wärme einsparen, indem man diese SDR-Engine nur startet wenn ein Squelch-Signal Bescheid gibt "Achtung, da ist ein Signal!"
    Blöder weise ist das aber ein Irrweg: Was man für DMR/TDMA da bräuchte wäre ein Squelch der innerhalb von µs öffnet, und eben nicht erst irgendwann nach 5-10ms wie bei den GM3x0 üblich.

    Jürgen