MMDVM-Relais - Versionsgeschichte

IN3FQQ: RSSI Anzeige

2025-09-24T12:59:56Z

RSSI Anzeige

← Nächstältere Version		Version vom 24. September 2025, 12:59 Uhr
Zeile 147:		Zeile 147:

	<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.		<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]]		[[Kategorie:Digitaltechnik]]

IN3FQQ am 22. September 2025 um 19:04 Uhr

2025-09-22T19:04:17Z

← Nächstältere Version		Version vom 22. September 2025, 19:04 Uhr
Zeile 122:		Zeile 122:
	<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 (>180s) kann es vorkommen, dass man eine Veränderung des ''pos''-Werts beobachten kann.		Bei längeren DMR-Durchgängen (>180s) kann es vorkommen, dass man eine Veränderung des ''pos''-Werts beobachten kann.

IN3FQQ: /* Kalibrierung */

2025-09-22T18:05:39Z

Kalibrierung

← Nächstältere Version		Version vom 22. September 2025, 18:05 Uhr
Zeile 41:		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 ====

IN3FQQ: /* In-System Flashing Mod */

2025-09-22T18:02:00Z

In-System Flashing Mod

← Nächstältere Version		Version vom 22. September 2025, 18:02 Uhr
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:

IN3FQQ: kleinere korrekturen

2025-09-22T17:53:32Z

kleinere korrekturen

IN3FQQ: MMDVM-POG Dokumentation angelegt

2025-09-22T14:27:53Z

MMDVM-POG Dokumentation angelegt

Neue Seite

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.

← Nächstältere Version		Version vom 22. September 2025, 17:53 Uhr
Zeile 1:		Zeile 1:
	Auf allen ~~MMDVMs~~ des DRC ist aktuell (stand September 2025) das folgende MMDVM Modem Board verbaut:		Auf allen MMDVM-Relais des DRC ist aktuell (stand September 2025) das folgende MMDVM Modem Board verbaut:

	* ~~MMDVM_HS_HAT "POG"~~ Board, nach dem Design von SQ6POG		* '''MMDVM_POG''' Board, nach dem Design von SQ6POG
	** '''STM32F105RBT''' MCU (~~70MHz~~)		** '''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
	** Aktive Butterworth-Tiefpassfilter zweiter Ordnung (Sallen-Key)
	** Hardware-Design: https://github.com/wojciechk8/MMDVM_pog/		** 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.		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 16:		Zeile 16:
	* 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) -> '''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) -> '''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 56:		Zeile 55:


	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.		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 ~~gelange~~, muss der Ermittelte ''TXLevel'' Wert noch mit 95% multipliziert und in der mmdvmhost-Konfigurationsdatei als ''TXLevel'' abgespeichert 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 ====		==== RX Kalibrierung ====
Zeile 68:		Zeile 67:
	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.

	~~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!		<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 82:
	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.

	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'''.		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 ~~Sinussignals~~ sollte genau die Hälfte von VCC, also '''1,65V''' betragen.		Der DC-Offset des Signals 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''~~.'''		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 108:
	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 ~~nachgestellt~~ werden.		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 116:
	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 (~~man liest von~~ >~~175s~~) kann es vorkommen, dass man eine Veränderung des ''pos''-Werts beobachten kann.		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 144:
	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.
			[[Kategorie:Digitaltechnik]]