Quelltext der Seite MMDVM-Relais

Auf allen MMDVMs des DRC ist aktuell (stand September 2025) das folgende MMDVM Modem Board verbaut:

* MMDVM_HS_HAT "POG" Board, nach dem Design von SQ6POG
** '''STM32F105RBT''' MCU (70MHz)
** '''19.2 MHz''' TCXO
** Open-Source Hardware Design
** Aktive Butterworth-Tiefpassfilter zweiter Ordnung (Sallen-Key)
** Hardware-Design: https://github.com/wojciechk8/MMDVM_pog/

Das Board kann anscheinend Firmwarekompatibel zu den Repeater Builder STM32-DVM v2 (mittlerweile auch nicht mehr unterstützt) gemacht Wenn man den verbauten 19,2MHz TCXO durch einen 12MHz austauscht, ist diversen Berichten zufolge die Firmware der R''epeater Builder STM32-DVM V2'' (Stand 2025 auch nicht mehr offiziell unterstützt) auf diesen Platinen lauffähig.

=== In-System Flashing Mod ===
Damit die Firmware per remote geflasht werden kann, müssen zwei Verbindungen gelötet werden:
[[Datei:Mmdvm-flashing-mod.png|alternativtext=MMDVM In-System-Flashing-Mod|mini|MMDVM In-System-Flashing-Mod]]

* Raspberry PI '''GPIO 21''' (HW Pin 40) -> '''NRST''' (auf ST-LINK Pin Header, das Pin neben dem Kondensator)
* Raspberry PI '''GPIO 20''' (HW Pin 38) -> '''BOOT0''' (JP1 Pin 2), über einen 10kOhm Widerstand


Zum Flashen muss zuerst MMDVMHost gestoppt werden:
 systemctl stop mmdvmhost.timer
 systemctl stop mmdvmhost
Dann kann mit stm32flash mit angabe der Pin-Folge (option -i) geflasht werden:
 # MMDVM Modem in Flash-Modus bringen (BOOT0 high, NRST low->high)
 stm32flash -i 20,-21,21 /dev/ttyAMA0
 # Firmware flashen
 stm32flash -w mmdvm_pog-fw.hex -g 0x0 -R /dev/ttyAMA0
 # MMDVM nochmal via NRST (low->high) resetten
 stm32flash -i -21,21 /dev/ttyAMA0

 # nun kann MMDVMHost wieder gestartet werden
 systemctl start mmdvmhost.timer
 systemctl start mmdvmhost

=== MMDVMHost Einstellungen ===
Der Modem-Type ist auf '''STM32-DVM / MMDVM_HS - Raspberry Pi Hat (GPIO)''' zu stellen.

Baudrate ist '''115200'''. Schnellere Baudraten, wie sie beispielsweise für FM oder andere Betriebsarten notwendig sind, schafft der ''STM32F105'' nicht mehr.

=== Kalibrierung ===
Die Kalibrierung der RX und TX-Pegel vom MMDVM passiert in unserem Fall über die einstellung zweier Trimmerpotentiometer, sowie über die digitale Gain-Einstellung.

Zum Kalibrieren wird das Programm MMDVMCal (in PiStar direkt mit pistar-mmdvmcal aufrufbar) verwendet.

==== TX Kalibrierung ====
Die Pegel für den Sender können durch Auswahl der Funktion <code>D Set DMR Deviation Mode. Generates a 1.2Khz Sinewave. Set radio for 2.75 Khz Deviation</code> eingestellt werden.

Besonders bei DMR ist die Hub-Einstellung kritisch.

Die Einstellung erfolgt mit hilfe eines Spektrum-Analyzers, wobei sich auch ein TinySA oder ein RTL-SDR eignen.

Die Anzeige wird auf die Sendefrequenz zentriert, der angezeigte Bandausschnitt sollte ca 15-20kHz betragen.

Nun wird der Trimmer solange bewegt, bis der Träger (so gut wie möglich) verschwunden ist:
[[Datei:Mmdvm-tx-calibration.png|alternativtext=MMDVM TX-Kalibrierung mit der Bessel-Null-Methode|zentriert|mini|502x502px|MMDVM TX-Kalibrierung mit der Bessel-Null-Methode]]


Für die Feineinstellung kann in MMDVMCal durch die Tasten ''T'' und ''t'' der TX-Pegel digital in halben Prozentschritten erhöht (''i'') oder verringert (''t'') werden.

Nun hat man ca. einen Hub von 2,88kHz eingestellt. Um zum gewünschten Hub von 2,75kHz zu gelange, muss der Ermittelte ''TXLevel'' Wert noch mit 95% multipliziert und in der mmdvmhost-Konfigurationsdatei als ''TXLevel'' abgespeichert werden.

==== RX Kalibrierung ====
Für die Kalibrierung der RX-Pegel gibt es zwei Varianten: die genauere, Messtechnische Variante mit einem Oszilloskop, und alternativ die "Trial and Error"-Methode.

===== "Trial and Error"-Methode =====
MMDVMCal bietet mehrere BER-Testing-Modes, welche entsprechend ein DSTAR/DMR/C4FM Signal erwarten und für jeden empfangenen Datenframe die BER anzeigen.
 K/k	BER Test Mode (FEC) for D-Star
 b	BER Test Mode (FEC) for DMR Simplex (CC1)
 J	BER Test Mode (FEC) for YSF
Nun wird mit einem entsprechenden Digitalfunkgerät ein Signal auf das Relais gegeben und der RX-Trimmer (und somit der NF-Pegel des Empfangssignals) durch "testen" solange variiert, bis etwas decodiert wird.

Danach wird durch die tasten R und r der RXLevel (also der Gain auf der digitalen Seite) angepasst, bis die angezeigten BER-Werte minimal sind.

Am Ende wird der ermittelte Wert unverändert in der MMDVMHost-Konfigurationsdatei als ''RXLevel'' abgespeichert.

ACHTUNG: Die Einstellung des Trimmers ist der kritische Teil! Wenn das analog anliegende Signal über VCC (=3.3V) geht und der ADC somit ins Clipping kommt, hilft jede darauffolgende digitale Gain-Einstellung auch nichts mehr!

===== Messtechnische Methode =====
Mit einem Oszilloskop wird das RX-Signal von einem Testpunkt auf der Platine abgegriffen.

Bei unserem MMDVM-POG Board gibt es dafür den Testpunkt ''TP32'', der sich schaltungstechnisch direkt hinter dem Butterworth-Filter der RX-Eingabe befindet.

Physisch befindet sich der Testpoint ''TP32'' unterhalb der ST-LINK Pins, welche links vom STM32-Prozessor liegen.

Ziel ist es, das Signal so einzustellen, dass der ADC nicht übersteuert wird. Das Signal soll bei einer '''VCC''' von '''3.3V''' also '''nie unter 0V und über 3.3V gehen'''. 

Der DC-Offset des Sinussignals sollte genau die Hälfte von VCC, also '''1,65V''' betragen.

Um sicherzustellen, dass es zu keinen ADC-Overloads kommt, sollte die Amplitude des Signals '''ca. 0,4V bis 0,5V Abstand''' von den beiden Grenzwerten (0V und 3,3V) haben. Das ergibt somit eine '''Nutzsignal-Amplitude von ca. 2,3Vpp am Testpunkt ''TP32''.'''

Auch wenn nur Rauschen am Empfänger anliegt, sollten die 3,3Vpp nicht überschritten werden.

=== Erweiterte Tests ===
Als nächstes setzt man nun in der MMDVMHost-Konfigurationsdatei in der <code>[Modem]</code> Stanza den Wert <code>Debug=1</code>.

Sobald man nach der Änderung den MMDVMHost neu startet, schreibt dieser nützliche Infos ins Logfile, die zur Bestimmung der RX-Frequenzabweichung und für die Beurteilung des Timing-Drifts und der RX-Pegel nützlich sind.

Hier ein Beispiel einer solchen Logzeile:
 M: 2025-09-11 08:08:58.636 Debug: DMRSlotRX: voice header found slot/pos/centre/threshold 2 452 679 631
 M: 2025-09-11 08:08:58.696 Debug: DMRSlotRX: voice header found slot/pos/centre/threshold 2 452 646 632
 M: 2025-09-11 08:08:58.756 Debug: DMRSlotRX: voice sync found slot/pos/centre/threshold 2 452 590 636
 M: 2025-09-11 08:08:59.116 Debug: DMRSlotRX: voice terminator found slot/pos/centre/threshold 2 452 425

==== RX Frequenzabweichung ====
Anhand des Wertes ''centre'' kann man feststellen, ob es einen Frequenzversatz beim Empfänger gibt.

Der Wert sollte sich im Idealfall um 0 herum bewegen (Empfänger ist genau auf der Frequenz).

Sollte der Wert größer als 100 sein, muss der RX nachgestellt werden.

Bei der Bewertung dieser Werte ist darauf zu achten, dass das eingegebene Testsignal selbst keinen Frequenzversatz (oder zumindest einen bekannten) hat. Vor allem bei preisgünstigen DMR-Funkgeräten ist durchaus öfters ein Frequenzversatz zu beobachten.

Die besten Ergebnisse würde natürlich ein kalibriertes DMR Test Set liefern, was jedoch bei den wenigsten im Shack stehen wird.

Am besten man testet also einfach mit mehreren Funkgeräten, nach Möglichkeit mit verschiedenen Modellen von verschiedenen Herstellern.

Wenn das Relais bereits eine Weile im Einsatz war, ist auch eine Langzeit-Auswertung über die Logfiles möglich. Dazu einfach:

<code>grep -i dmrslot /var/log/pistar/MMDVM*.log</code>

=== Timing-Drift ===
Bei längeren DMR-Durchgängen (man liest von >175s) kann es vorkommen, dass man eine Veränderung des ''pos''-Werts beobachten kann.

Dies deutet auf einen Timing-Drift hin, der meistens vom TCXO auf der MMDVM-Platine verursacht wird, wenn dieser eine schlechte Frequenzstabilität aufweist.

Hier ein entsprechendes Beispiel (Log-Auszug aus https://github.com/juribeparada/MMDVM_HS/issues/109), bei welchem dieses Problem auftritt:
 M: 2019-11-06 16:28:10.529 Debug: DMRSlotRX: voice header found slot/pos/centre/threshold 2 447 26 337
 M: 2019-11-06 16:28:10.589 Debug: DMRSlotRX: voice header found slot/pos/centre/threshold 2 447 13 338
 M: 2019-11-06 16:28:10.649 Debug: DMRSlotRX: voice sync found slot/pos/centre/threshold 2 447 7 341
 .......
 M: 2019-11-06 16:31:04.891 Debug: DMRSlotRX: voice sync found slot/pos/centre/threshold 2 385 16 345
 M: 2019-11-06 16:31:05.251 Debug: DMRSlotRX: voice sync found slot/pos/centre/threshold 2 385 11 344
 M: 2019-11-06 16:31:05.611 Debug: DMRSlotRX: voice sync found slot/pos/centre/threshold 2 385 9 348
 M: 2019-11-06 16:31:05.971 Debug: DMRSlotRX: voice sync found slot/pos/centre/threshold 2 385 20 370
 E: 2019-11-06 16:31:08.326 No reply from the modem for some time, resetting it
 M: 2019-11-06 16:31:08.326 Closing the MMDVM
 M: 2019-11-06 16:31:10.352 Opening the MMDVM
 E: 2019-11-06 16:31:23.169 Unable to read the firmware version after six attempts
Zu beobachten ist, dass der erste Wert (''pos'') mit länger werdendem Durchgang immer weiter sinkt, bis schlussendlich das Modem neu startet.

Wenn das bei mehreren verschiedenen Usern/Geräten auffällt (auch hier gilt: es kann auch am Endgerät des Benutzers liegen!), liegt es vermutlich am TCXO auf dem MMDVM Board.

Ggf. sollte dieser durch ein besseres Äquivalent ausgetauscht werden, z.B. ein 12MHz TCXO von namhaften Herstellern.

Achtung: Wenn der Wert von den originalen 19.2MHz auf 12MHz abgeändert wird, '''muss die Firmware neu compiliert werden!''' In der ''Config.h'' muss entsprechend die Zeile für den 19.2MHz TCXO auskommentiert und dafür das Kommentarzeichen beim 12MHz TCXO entfernt werden.