MMDVM-Relais: Unterschied zwischen den Versionen
IN3FQQ (Diskussion | Beiträge) MMDVM-POG Dokumentation angelegt |
IN3FQQ (Diskussion | Beiträge) RSSI Anzeige |
||
| (4 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
Auf allen | Auf allen MMDVM-Relais des DRC ist aktuell (stand September 2025) das folgende MMDVM Modem Board verbaut: | ||
* | * '''MMDVM_POG''' Board, nach dem Design von SQ6POG | ||
** '''STM32F105RBT''' MCU ( | ** '''STM32F105RBT''' MCU (ARM Cortex M3, 72MHz Clock, 128kB Flash) | ||
** '''19.2 MHz''' TCXO | ** '''19.2 MHz''' TCXO | ||
** Sallen-Key Butterworth-Tiefpassfilter für RX und TX | |||
** Open-Source Hardware Design | ** Open-Source Hardware Design | ||
** Hardware-Design: https://github.com/wojciechk8/MMDVM_pog/ | ** Hardware-Design: https://github.com/wojciechk8/MMDVM_pog/ | ||
Wenn man den verbauten 19,2MHz TCXO durch ein 12MHz-Äquivalent austauscht, ist diversen Berichten zufolge die Firmware der ''Repeater Builder STM32-DVM V2'' Boards (Stand 2025 auch nicht mehr offiziell unterstützt) auf diesen Platinen lauffähig. | |||
=== In-System Flashing Mod === | === In-System Flashing Mod === | ||
| Zeile 14: | Zeile 14: | ||
[[Datei:Mmdvm-flashing-mod.png|alternativtext=MMDVM In-System-Flashing-Mod|mini|MMDVM In-System-Flashing-Mod]] | [[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 21''' (HW Pin 40, im Bild das Erste oben links) -> '''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 | * Raspberry PI '''GPIO 20''' (HW Pin 38, im Bild das Zweite von oben links) -> '''BOOT0''' (JP1 Pin 2), über einen 10kOhm Widerstand | ||
Zum Flashen muss zuerst MMDVMHost gestoppt werden: | Zum Flashen muss zuerst MMDVMHost gestoppt werden: | ||
systemctl stop mmdvmhost.timer | systemctl stop mmdvmhost.timer | ||
systemctl stop mmdvmhost | systemctl stop mmdvmhost | ||
Dann kann mit stm32flash mit angabe der Pin-Folge (option -i) geflasht werden: | Dann kann mit ''stm32flash'' mit angabe der Pin-Folge (option <code>-i</code>) geflasht werden: | ||
# MMDVM Modem in Flash-Modus bringen (BOOT0 high, NRST low->high) | # MMDVM Modem in Flash-Modus bringen (BOOT0 high, NRST low->high) | ||
stm32flash -i 20,-21,21 /dev/ttyAMA0 | stm32flash -i 20,-21,21 /dev/ttyAMA0 | ||
| Zeile 42: | Zeile 41: | ||
Zum Kalibrieren wird das Programm MMDVMCal (in PiStar direkt mit pistar-mmdvmcal aufrufbar) verwendet. | Zum Kalibrieren wird das Programm MMDVMCal (in PiStar direkt mit pistar-mmdvmcal aufrufbar) verwendet. | ||
<u>Achtung:</u> MMDVMCal startet immer mit den Default-Einstellungen (alle Gain-Level auf 50%, kein TXInvert und kein RXInvert). Außerdem werden die eingestellten Werte '''<u>nicht</u>''' automatisch in die Konfigurationsdatei übernommen! Das muss manuell erledigt werden. | |||
==== TX Kalibrierung ==== | ==== TX Kalibrierung ==== | ||
| Zeile 56: | Zeile 57: | ||
Für die Feineinstellung kann in MMDVMCal durch die Tasten | Für die Feineinstellung kann in MMDVMCal durch die Tasten <code>T</code> und <code>t</code> der TX-Pegel digital in halben Prozentschritten erhöht (''T'') oder verringert (''t'') werden. | ||
Nun hat man ca. einen Hub von 2,88kHz eingestellt. Um zum gewünschten Hub von 2,75kHz zu | Nun hat man ca. einen Hub von 2,88kHz eingestellt. Um zum gewünschten Hub von 2,75kHz zu gelangen, muss der Ermittelte ''TXLevel'' Wert noch mit 95% multipliziert und anschließend in der mmdvmhost-Konfigurationsdatei als ''TXLevel'' abgespeichert werden. | ||
==== RX Kalibrierung ==== | ==== RX Kalibrierung ==== | ||
| Zeile 68: | Zeile 69: | ||
b BER Test Mode (FEC) for DMR Simplex (CC1) | b BER Test Mode (FEC) for DMR Simplex (CC1) | ||
J BER Test Mode (FEC) for YSF | 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. | 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. | Danach wird durch die tasten <code>R</code> und <code>r</code> 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. | Am Ende wird der ermittelte Wert unverändert in der MMDVMHost-Konfigurationsdatei als ''RXLevel'' abgespeichert. | ||
<u>Achtung:</u> 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 ===== | ===== Messtechnische Methode ===== | ||
| Zeile 83: | Zeile 84: | ||
Physisch befindet sich der Testpoint ''TP32'' unterhalb der ST-LINK Pins, welche links vom STM32-Prozessor liegen. | Physisch befindet sich der Testpoint ''TP32'' unterhalb der ST-LINK Pins, welche links vom STM32-Prozessor liegen. | ||
Nun wird mit einem RF-Generator bzw. mit einem Funkgerät ein Testsignal auf den Empfänger gegeben und das am Testpunkt ''TP32'' anliegende Signal gemessen. | |||
Ziel ist es, das Signal so einzustellen, dass der ADC nicht übersteuert wird. Das Signal soll also '''nie unter 0V und über 3.3V gehen'''. | |||
Der DC-Offset des Signals sollte genau die Hälfte von VCC, also '''1,65V''' betragen. | |||
Die Amplitude des Signals sollte '''ca. 0,4V bis 0,5V Abstand''' von den beiden Grenzwerten (0V und 3,3V) haben. Das ergibt somit '''ca. 2,3Vpp.''' | |||
Auch wenn nur Rauschen am Empfänger anliegt, sollten die 3,3Vpp nicht überschritten werden. | Auch wenn nur Rauschen am Empfänger anliegt, sollten die 3,3Vpp nicht überschritten werden. | ||
| Zeile 107: | Zeile 110: | ||
Der Wert sollte sich im Idealfall um 0 herum bewegen (Empfänger ist genau auf der Frequenz). | 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 | Sollte der Wert größer als 100 sein, muss der RX nachjustiert 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. | 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. | ||
| Zeile 115: | Zeile 118: | ||
Am besten man testet also einfach mit mehreren Funkgeräten, nach Möglichkeit mit verschiedenen Modellen von verschiedenen Herstellern. | 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: | Wenn das Relais bereits eine Weile im Einsatz war, ist auch eine Langzeit-Auswertung über die Logfiles möglich. Dazu einfach den folgenden Befehl verwenden: | ||
<code>grep -i dmrslot /var/log/pistar/MMDVM*.log</code> | <code>grep -i dmrslot /var/log/pistar/MMDVM*.log</code> | ||
=== Timing-Drift === | ==== Timing-Drift ==== | ||
Bei längeren DMR-Durchgängen ( | Bei längeren DMR-Durchgängen (>180s) 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. | Dies deutet auf einen Timing-Drift hin, der meistens vom TCXO auf der MMDVM-Platine verursacht wird, wenn dieser eine schlechte Frequenzstabilität aufweist. | ||
| Zeile 143: | Zeile 146: | ||
Ggf. sollte dieser durch ein besseres Äquivalent ausgetauscht werden, z.B. ein 12MHz TCXO von namhaften Herstellern. | 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. | <u>Achtung:</u> 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. | ||
=== RSSI-Anzeige === | |||
Damit für empfangene Signale die Signalstärke (''RSSI'', Received Signal Strength Indicator) angezeigt werden kann, muss der verwendete Empfänger über ein RSSI-Pin verfügen, auf welchem je nach Empfangspegel eine Spannung ausgegeben wird. | |||
Als erstes muss ermittelt werden, wie hoch die maximal ausgegebene Spannung am RSSI-Pin des empfängers ist. Das kann entweder aus dem Handbuch des Empfängers ermittelt oder messtechnisch durch anlegen eines starken Pegels, z.B. S9+40 und messen der Spannung am RSSI-Pin geprüft werden. | |||
Danach sollte über einen Spannungsteiler die Spannung so reduziert werden, dass am RSSI-Pin des MMDVM-Boards '''maximal 3,3V''' ankommen. | |||
Danach wird ''MMDVMCal'' gestartet und der ''RSSI Mode'' gewählt. | |||
Nun müssen nacheinander definierte RF-Pegel - beispielsweise von S9+40 bis S1 - angelegt und der auf dem Bildschirm ausgegebene Wert (jeweils ''average'' verwenden) aufgeschrieben werden. | |||
Diese werden anschließend in folgender Form die Datei ''/usr/local/etc/RSSI.dat'' gespeichert: | |||
# WERT SIGNALPEGEL | |||
4094 -73 | |||
3912 -83 | |||
3364 -93 | |||
3159 -99 | |||
2900 -105 | |||
2670 -111 | |||
2388 -117 | |||
2131 -123 | |||
1943 -129 | |||
1851 -135 | |||
1820 -141 | |||
[[Kategorie:Digitaltechnik]] | |||
Aktuelle Version vom 24. September 2025, 12:59 Uhr
Auf allen MMDVM-Relais des DRC ist aktuell (stand September 2025) das folgende MMDVM Modem Board verbaut:
- MMDVM_POG Board, nach dem Design von SQ6POG
- STM32F105RBT MCU (ARM Cortex M3, 72MHz Clock, 128kB Flash)
- 19.2 MHz TCXO
- Sallen-Key Butterworth-Tiefpassfilter für RX und TX
- Open-Source Hardware Design
- Hardware-Design: https://github.com/wojciechk8/MMDVM_pog/
Wenn man den verbauten 19,2MHz TCXO durch ein 12MHz-Äquivalent austauscht, ist diversen Berichten zufolge die Firmware der Repeater Builder STM32-DVM V2 Boards (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:
- Raspberry PI GPIO 21 (HW Pin 40, im Bild das Erste oben links) -> NRST (auf ST-LINK Pin Header, das Pin neben dem Kondensator)
- Raspberry PI GPIO 20 (HW Pin 38, im Bild das Zweite von oben links) -> 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.
Achtung: MMDVMCal startet immer mit den Default-Einstellungen (alle Gain-Level auf 50%, kein TXInvert und kein RXInvert). Außerdem werden die eingestellten Werte nicht automatisch in die Konfigurationsdatei übernommen! Das muss manuell erledigt werden.
TX Kalibrierung
Die Pegel für den Sender können durch Auswahl der Funktion D Set DMR Deviation Mode. Generates a 1.2Khz Sinewave. Set radio for 2.75 Khz Deviation 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:
Für die Feineinstellung kann in MMDVMCal durch die Tasten T und t der TX-Pegel digital in halben Prozentschritten erhöht (T) oder verringert (t) werden.
Nun hat man ca. einen Hub von 2,88kHz eingestellt. Um zum gewünschten Hub von 2,75kHz zu gelangen, muss der Ermittelte TXLevel Wert noch mit 95% multipliziert und anschließend 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.
Nun wird mit einem RF-Generator bzw. mit einem Funkgerät ein Testsignal auf den Empfänger gegeben und das am Testpunkt TP32 anliegende Signal gemessen.
Ziel ist es, das Signal so einzustellen, dass der ADC nicht übersteuert wird. Das Signal soll also nie unter 0V und über 3.3V gehen.
Der DC-Offset des Signals sollte genau die Hälfte von VCC, also 1,65V betragen.
Die Amplitude des Signals sollte ca. 0,4V bis 0,5V Abstand von den beiden Grenzwerten (0V und 3,3V) haben. Das ergibt somit ca. 2,3Vpp.
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 [Modem] Stanza den Wert Debug=1.
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 nachjustiert 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 den folgenden Befehl verwenden:
grep -i dmrslot /var/log/pistar/MMDVM*.log
Timing-Drift
Bei längeren DMR-Durchgängen (>180s) 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.
RSSI-Anzeige
Damit für empfangene Signale die Signalstärke (RSSI, Received Signal Strength Indicator) angezeigt werden kann, muss der verwendete Empfänger über ein RSSI-Pin verfügen, auf welchem je nach Empfangspegel eine Spannung ausgegeben wird.
Als erstes muss ermittelt werden, wie hoch die maximal ausgegebene Spannung am RSSI-Pin des empfängers ist. Das kann entweder aus dem Handbuch des Empfängers ermittelt oder messtechnisch durch anlegen eines starken Pegels, z.B. S9+40 und messen der Spannung am RSSI-Pin geprüft werden.
Danach sollte über einen Spannungsteiler die Spannung so reduziert werden, dass am RSSI-Pin des MMDVM-Boards maximal 3,3V ankommen.
Danach wird MMDVMCal gestartet und der RSSI Mode gewählt.
Nun müssen nacheinander definierte RF-Pegel - beispielsweise von S9+40 bis S1 - angelegt und der auf dem Bildschirm ausgegebene Wert (jeweils average verwenden) aufgeschrieben werden.
Diese werden anschließend in folgender Form die Datei /usr/local/etc/RSSI.dat gespeichert:
# WERT SIGNALPEGEL 4094 -73 3912 -83 3364 -93 3159 -99 2900 -105 2670 -111 2388 -117 2131 -123 1943 -129 1851 -135 1820 -141
