I just pushed DMR2M17 to my fork of the MMDVM_CM repo:

The quality from DMR radio to M17 is excellent. This is with the PCM data passed directly from the md380 vocoder to the codec2 vocoder. I added a configuration option ‘GainAdjustDb’ in DMR2M17.ini with a default setting of -6dB for PCM data returned from codec2, because without this level of attenuation the M17 transmissions were blowing out my DMR radio speaker. Values of -6dB to -10dB seem to get the audio to a reasonable level, but the quality from any of the current options for M17 (mvoice, dudestar, droidstar) to the DMR radio is far from excellent, as demonstrated in this video:

This should be considered a work in progress, but it’s something to play with for now.


Can i connect this to mmdvm_bridge ?

I don’t know anything about mmdvm_bridge.

OK DONE i think :slight_smile:
HBLink >><< mmdvm_bridge >><cross port 31100:31103><< mmdvm_bridge <<>> DMR2M17.
I hear DMR voice on M17 Reflector ( nice and clear ) , but i can’t check back audio, i don’t have M17 device.
Can you pls update DroidStar M17 ref database and add M17-GBR ? Thx.

My M17Host file is generated from every hour. Just do File->Update host files to get the latest list.

Many thanks Doug - MMDVM_CM works fine like crosslink.
Great job , GL for future.

Great job Doug,
currently it can only be used with MMDVMHost.
Is it possible, on the DMR side, to enable a “peer” connection, inbound or outbound, in order to use it as a “bridge”?
I hope I have explained.

73 de Roby IV3JDV

When I complete M172DMR that can be used to connect an M17 reflector to a DMR server or XLX.

Hi Doug
I have a small problem. after 2-3 hours of work the temperature on the raspberry 3B+ goes up to 62 degrees C.
its not very comfortable when you have a hotspot in your pocket with a powerbank. I checked what happened and it turns that the DMR2M17 is using 100% of the processor power. Can you do something about that ?

second question I have is why does the DMR2M17 reply with my own DMR_ID ? ist is possible for the DMR2M17 to have its own DMR_ID and a static TG

The 100% cpu usage should be fixed in latest git. If by ‘DMR2M17 reply’ you mean M17 transmissions that are being received, then that is correct behavior for M17 transmissions from users that do not have a DMR ID listed in the DMRIDs.dat file. If you didn’t download one, you can get one from the link below which is updated daily. The path and file name are defined in the DMR2M17.ini file, the default is DMRIDs.dat in the same directory as the executable.

See my post under the M172DMR about those cross mode utilities working well now: