This is going to be a very short article, because while this is a really popular topic in my email inbox right now, it’s also a really simple one. The question is how to set up MMDVM for using an MTR2000 and the STM32-DVM-MTR2K?
In my article on programming the MTR2000, I linked out to an excellent article by PD0ZRY that is located here. But I also realized that his article uses a very different MODEM interface. Well, here it is folks, below is the MODEM stanza from one of K0USY Group’s operating MTR2000s with our own STM32-DVM-MTR2K board in it.
[Modem]
Port=/dev/ttyS1
Protocol=uart
TXInvert=0
RXInvert=0
PTTInvert=0
TXDelay=100
RXOffset=0
TXOffset=0
DMRDelay=165
RXLevel=50
TXLevel=50
RXDCOffset=0
TXDCOffset=0
RFLevel=0
RSSIMappingFile=/usr/local/etc/rssi.dat
Trace=0
Debug=0
The parts you might have a hard time with are in bold. The first one is pretty easy, the serial port name is simply different on the OrangePi Zero and NanoPi NEO loaded with Armbian. You might not use Armbian as the base OS on yours, so it may not be /dev/ttyS1, so do be certain this is the case for your situation. I will make a plug for Armbian here – I find it to be a more stable all-around OS distribution for both of the boards I’ve used than others.
The big one, and this one is absolutely critical, is to set the DMRDelay to a number around 165. It doesn’t have to be exact. PD0ZRY calculated it to be 162-168. I used 165 as a starting point and pushed it out higher and lower until the MODEM stopped working properly. I found the midpoint to be… you guessed it, 165. This is really splitting hairs. 162, 165… anything in that neighborhood will be fine.
Perhaps the biggest question is, “what is this number anyway?” The MTR2000 does not have an analog FM detector. The 2nd IF is digitized into PCM data, and the digital information is sent from the receiver to the SCM (system control module), where it is converted into an analog signal in CODEC #5. This creates a delay in the audio path as the ADC and DAC actions come with a small time penalty of around 7ms. Since DMR is TDMA, it is critical that the time a DMR burst was received to the time it is retransmitted is synchronized. DMRDelay is how you tell MMDVM about this delay so that the subscriber can properly synchronize to the repeater.
That’s it. Get the serial port right, get the DMRDelay right, and it’ll probably just work! This really leaves us with just one other piece: RSSI. This is by no means mandatory, but a lot of folks like to use the RSSI feature in MMDVM. the MMDVM.ini requires you specify a location for a mapping file to hold the measured value of the MMDVM RSSI ADC input, and the corresponding signal level in dBm. Not everyone has the means to measure this, so I wanted to offer the mapping file from a typical MTR2000. Please understand that you’ll want to do a calibration for each radio for maximum accuracy. If you don’t have the means to do this, or absolute accuracy isn’t that important to you, the numbers below should get you pretty close:
3226 -30
3128 -35
2992 -40
2812 -45
2657 -50
2454 -55
2320 -60
2123 -65
1986 -70
1785 -75
1650 -80
1447 -85
1313 -90
1112 -95
980 -100
778 -105
643 -110
404 -115
240 -120
94 -125
50 -130
The STM32-DVM-MTR2K will saturate the MMDVM ADC input at signals much stronger than -30dBm. That’s ok, I did that on purpose in order to keep the signal level at the low end up a little higher in order to improve ADC resolution for weaker signals.