DMR MMDVM duplex hotspot

posted in: DMR | 74

I few weeks ago, the Duplex MMDVM hotspot board, I ordered from an eBay vendor in China, finally arrived.


There appear to be 2 different types of duplex boards available on eBay.
One which seems to be a direct copy an open source design, and the version of board I ordered; which looks looks like the one I received


This board to be inspired by this open source design, ,


But looking in detail, at the board I received, it’s considerably different from the open source version, and is probably only similar at schematic level.

All the duplex boards use the standard format Raspberry Pi “Hat” and can be connected to a RPi 2,3 or Zero ( or Zero W).

The board is wider than a RPi Zero, and fits neatly onto the top of a RPi 3B (or 3B+)


I had a RPi 3B which I was not using, so I decided to use that as the host board, and I downloaded and installed the latest version of Pi-Star.


Using educated guesswork…
On the Pi-Star configuration page, I selected the “Duplex Repeater (or Half-Duplex on Hotspots)” as the “Controller Mode” and selected  “MMDVM_HS_Dual_Hat” from the “Radio/Modem Type

After applying these settings, I was able to enter a separate transmit and receive frequency. I chose two frequencies 6 MHz apart on the 70cms band, which is used by a repeater about 1000km from me, but not used for any local repeaters.

The board was supplied with two small, cheep looking antennas, which I presume are designed for the 433 MHz ISM band, and using these directly screwed into the SMA connectors, I found was the hotspot did not seem to work very well

This is probably because of the desensitization of the Rx by the Tx.

I’ve seen some YouTube videos where people have used 90 degree adapters attached to the SMA sockets on the board, so that the antennas can be rotated to stick away from each other , but as I didn’t have any SMA adaptors, I simply disconnected the Tx antenna connected the Tx output to an external antenna which is on the roof of the house.

Using at least one external antenna resolved the desensitization problem, and the added benefit of connecting the Tx connector to an external antenna, is that the range of the hotspot should be increased so that it can be accessed from the garden, and up to around 250m down the street!


Unfortunately as soon as I tried using the hotspot to have actual QSO”s, I received reports that my signal was abruptly cutting out after about a minute. In some cases the audio would make a sort of squawk sound as it cut out.

I conducted a some tests and the timeout appeared to be almost exactly 60 secs

Initially I suspected that there was a 1 minute timeout somewhere in the configuration, however after finding and changing any configuration setting which looked like a timing value of “60”. I came to the conclusion that perhaps there was a problem in the firmware which perhaps has a 1 minute timeout for these duplex boards


By coincidence, around this time, I spoke to Steve K2GOG, who told me that he encountered similar issues on his duplex hotspots, but had fixed the problem by using passive cooling on the TCXO, and on the processor on his Raspberry Pi.

Unfortunately, when I tried the a similar solution, by using a PC CPU cooling fan… It made absolutely no difference.


At this point I decided to raise an issue on the firmware GitHub repository, of Andy CA6JAU in the hope that he could shed some light on the problem, and after a few days, Andy confirmed that there was some sort of problem with the firmware, as he could reproduce the problem on his duplex hotspot, but was surprised that on one had noticed the bug before now.


Fast forward a week, and Andy had tracked down the problem, but it wasn’t completely good news.

The reason that the hotspot cuts out, is related to differences between master clock frequency in the hotspot and in the radio. Over time, while the radio is transmitting and the hotspot is receiving and re-transmitting, the hotspot Tx gets far enough out of sync with the radio until a point where the connection is dropped.

The Rx ADF7021 performs “clock recovery” on the incoming signal, but there is no way to transfer this synchronized clock into the Tx ADF7021, as the ADF7021 does not have a clock output.


Andy had managed to modify his firmware, to attempt to detect if there was an offset in the incoming and outgoing data, and cope with some miss-alignment, but all this did is delay the inevitable time when the radio and hotspot were so out of sync the connection gets dropped.


The good news however, is that the time before the hotspot cuts out, has been extended from 1 minute to around 4 minutes (on most radios), and since a lot of DMR repeaters and servers have a 3 minute timeout, the server timeout will occur before the hotspot timeout.

And as this timeout is effectively reset at the start of each over, the problem has effectively been solved.


Andy released firmware version 1.4.7, a few days ago, and all PiStar users can install it by logging into the SSH terminal and using the normal command to update their firmware.


Now, just when you thought this article was complete, I have to report yet another, unresolved problem with these duplex hotspots…

My TYT MD-380 would not connect to the hotspot at all!


Discussing the problem with Andy, he initially thought the problem was the overall latency between the signal being received from the MD-380 to when the hotspot responded (transmitted) back to the MD-380.

In an attempt to resolve this problem, I downloaded the source code for the firmware and the compiler toolchain, onto my Raspberry Pi, and modified the Make file, to use maximum code opimisation (using the -O3 option), as this normally yields a reasonable increase in speed – but can sometimes stop code working completely.

However after recompiling the firmware with this level of optimisation, it didn’t make any difference to the MD-380 problem.

My next step was going to be an attempt to overclock the STM32F103C8 MCU on the hotspot, because although its official maximum speed is 72Mhz, I have overclocked them to 128Mhz with no side effects, apart from the MCU getting a few degrees warmer.

Unfortunately when I looked at the code, it wasn’t going to be that easy to change, as the firmware now uses the STM “Standard peripheral library”, which does not have nice macros’ like the Arduino STM32 core does, to set the PLL multipler, or adjust the baud rate of the UART etc


Luckily before I got stuck into reading the 1000+ page programmers manual for the STM32, in order to work out the correct bit patterns for PLL multipliers etc, Andy got back to me and said that he had a work-around for the MD-380 by increasing the Tx deviation.

The setting that needs to change is in the Expert MMDVM Host page of PiStar and is called DMRTxLevel. Normally this is set to 50 and needs to be increased to around 55 to allow the MD-380 to connect.

I made this change and instantly found the MD-380 would connect, however I noticed that every so often that the PiStar dashboard indicated that the MD-380 was on Timeslot 1 when it was actually transmitting on Timeslot 2.

At the time of writing, there is no other work-around for any MD-380 users who’s radio won’t connect to the hotspot. So its best to keep an eye on PiStar when you are transmitting, to make sure that you are on the TS you expect.
Because if the hotspot is looking on TS1 and you are transmitting the audio on TS2, then the network gets no audio at all.


As I’m now quite happy with my duplex hotspot, as it works fine with my GD-77, I have started to do range testing, but that will be a subject of another blog post.

74 Responses

  1. Rafa_RGB (EA3BIL)


    DUAL HAT is 1.4.16 FW 14.7456Mhz ( both boards )
    Pi-Star is 3.4.17 / 20190324

    I use to keep it runnig overnight in order to autoupdate Pi-Star.

    In the next days I’ll get a new uSD and reload Pi-Star (just in case).

    Will keep you up to date on the progres…

    Thanks for helping !!

  2. DG4EK, Peter

    Regarding known firmware bugs with GD-77 (its the same with the new DM-5R/RD-5R) I read that the radio doesnt decode a channel and its TG if this group isnt found in a RX group. So far I also saw that problem.

    But there seems to be another strange thing:

    RX doesnt work even if TGs listed in an RX group have different timeslots !
    Any TG in timeslot 2 will not be decoded if there are any other timeslot 1 TG listet in that RX Group.

    I put channels having TG1, TG110 both TS1 and TG9 (TS2) into one RX group
    Now a zone contains those TGs so switching TG1, 110 and TG9 is possible.
    If I switch to TG9 nothing is being decoded. But choosing
    any of the TS1 groups, all TS1 group are decoded but TG9 still does not decode.

    Has anybody made the same experience with his GD-77 or DM-5R/RD-5R ?

    Peter, DG4EK

  3. Roger Clark

    What you are describing is how DMR works.

    The channel audio won’t be opened / decoded unless the incoming TG is in your Rx Group List.

    The GD-77 has a “monitor” feature aka promiscuous mode, which does allow this, but this is not a normal mode of operation, and the mode needs to be enabled each time the transceiver is turned on.

    You also the channel has to be on the same timeslot as the incoming signal, and the monitor mode doesn’t help with this.

  4. DG4EK, Peter

    Thats not what I meant Roger.
    If I write some TS1 TGs and a timeslot 2 Group in a RX group then
    the timeslot 2 group will not decoded. I can select that group
    (i.e. TG9) in the channel selector and GD-77 will not decode it
    regardless this TG9 is inside the RX group or not.

    The TS1 groups stops the TS2 group from decoding.
    Thats what I saw.

  5. Carlos J Livingston

    Hello Roger,
    This is KA6CJL here from San Diego, CA. I have a cheap eBay MMDVM_HS_Dual_Hat Duplex like the one you show in the second picture (bottom one). It used to work perfectly with my Anytone 868 but now I bought an AT-D878UV which is basically the same radio and now it won’t receive. When I PTT, I can see a yellow LED light activating on the Hat, and also I see the TX and RX activity on Pi-star but no sound being received on the radio. I updated the Pi-star to version 4.1.0 and tried different modem options on the Pi-star for the hat. Only one seems to allow connectivity with the radio. I chance the Tx delay in the Expert options to -475 as suggested by the eBay vendor but no luck. Any ideas?

  6. Roger Clark

    I’d recommend you set the “Controller mode” to simplex and set the board to “MMDVM_HAT….” rather than Dual hat.

    Get it working in simplex first by adjusting the Rx and Tx offset values, and only when its working with BER < 1% in simplex, set it to Duplex and change the type to DUAL HAT. Note, the setting you need to change is not Tx Delay its Rx and Tx offset. You may need to try values as far as +2000 and -2000 , in steps of 100, to find the required offset to make it work. This can be time consuming but there is no other way to set the offset as far as I'm aware.

  7. Carlos J Livingston

    Hello Roger,
    Thanks for the super quick response. I got it working for a few minutes and then it disconnects and I am unable to make it work again unless I reflash the memory card to its original configuration. This is how it was working when it did
    RXOffset= -475 (this seems to help with the correct BER)
    CWIdTXLevel= 55
    D-StarTXLevel= 55
    DMRTXLevel= 55
    YSFTXLevel= 55
    P25TXLevel= 55
    NXDNTXLevel= 55

    I tried simplex and only DMR and so far no changes there.

  8. Roger Clark

    Normal setting for Level is 50. Some radios like the MD-380 , sometimes need higher values but its not normal to change that setting

    Also if you have enabled multiple modes when in Duplex mode, DMR won’t work because the hotspot will cycle between all modes, and not necessarily be listening on DMR when your radio tries to connect, and hence your radio will not get the response it needs to continue

    BTW. AFIK Its only the Dual Hat boards which won’t work in DMR in duplex, the full MMDVM boards like Repeater Builder sell, which use 2 external transceivers will work with other modes enabled with DMR radios because the 4FSK demodulation is done simultaneously for all modes.


    You may also want to check wether the Anytone’s firmware is up to date.

    Also I read about TX & RX LEVELS (not OFFSETs) that may affect Anytone & 380 radios…

    Sorry I don’t have with me the link right now…some googling may help

  10. Carlos J Livingston

    Thanks again. Now I cannot make it work at all. In the past, this hat was working very well in multimode and was able to use it without any issues with my Anytone 868. Everything started when I got my 878. Unfortunately I sold the other radio so I was not able to test it with the old radio once the problems started to happen. Last night, I installed a different firmware for the hat on pi-star and now the MMDVM is not responding at all. It is stuck with a green light. I guess I hit a wall at this point. I can see everything on the Pi-star but the hat is completely inactive and the MMDVM is not showing on the dashboard. I need the correct firmware I guess and I am not sure which one is it. Bummer!

  11. Roger Clark

    Sounds like you should contact Anytone about this.

  12. Carlos J Livingston

    My 878 is up to date. I will try to find someone with a hotspot and try my radio to see if it works with another one, that would answer whether it is the radio or the hotspot issue. My 878 actually came updated from connectsystems like that and O am certain it has the latest firmware. I this point I wonder if there is anybody in San Diego who would like to help me out.

  13. Rafa BIL

    May I suggest to change the value for “PRE WAVE TIME” under DIGITAL FUNC at the OPERATIONAL SETTINGS ?
    The standard value (If set…) is 360ms, give a try with 420ms and let us know…
    I hope that helps.

  14. Anonymous

    @Rafa Bil, Original Pre Wave Time was set at 100. tried 360 and 420 and nothing. BTW, I was able to make the MMDVM work again and now it is not dropping or freezing and now I see activity in my pi-star dashboard every time I PTT it shows correct BER group call and everything. I just cannot hear anything at all on the radio. Keep in mind it worked perfectly once, so I think is not the radio, but rather some sort of timing out or something on the MMDVM

  15. Peter

    I have a similar MMDVM hotspot that I got from Aliexpress and the card is almost identical to yours.


    I configured my device to use a 2MHz repeater shift and that works better than the suggested 10MHz shift from the supplier. The only issue I have had from firmware version 1.3.3 is the same as you with your TYT and the DMRTXLevel setting solved the issue.

  16. Carlos J Livingston

    Okay, I finally gave up and decided to get some professional help with my issue. As it turned out, under the “DMR Configuration” section, my hotspot password in the “Hotspot Security” got erased on the many resets and testings I did trying to pinpoint the issue. Once I erase it and re-enter it, the hat started working great again.
    It is worth mentioning that we performed an alignment and calibration on this board and we determined that the Prewave Time is -400 and the DMRTXLevel is 53, so for all of you out there running this board at -425 and 50 or 55, these settings should be just fine.
    Thanks to all for the great ideas and suggestions. They were very accurate, clear and especially useful.

  17. Dan

    Nobody mentioned the firmware is the issue and jp1 stops the firmware update, Chinese hiding it under screen.

    Unless handy with a soldering iron the Chinese version has zero support and no firmware upgrade path.

    Once soldered check txco frequency and can be firmware upgraded via ssh.
    Found BER spot on and issues of screeching due to firmware and pi-star version.
    Pi-star forum pretty useless for any decency or a reply on an open source project

  18. Rick Swenton

    Dan, great point! I only have one of the newer HATs that came with JP1 un-jumpered. It took me some time to figure out why I could not flash the latest FW to the board. For the duplex boards Roger outlined some deficiencies that were helped with the latest 1.4.17.

  19. Rafa_RGB

    Hi Dan.
    I agree that no mentions to JP1 where done…
    Anyway, an image may have done “diagnose” easier and… Perhaps someone had noticed that JP1 was not “enabled” in your case.
    I went through the same not updating issue with a “german” board since I noticed about JP1.
    Now you also have experience enought to don’t go again on that mistake about JP1.

  20. F1FQN

    If your transceiver doesn’t work with mmdvm duplex mode, devalidate “talkaround” option in your codeplug !!!!

  21. Eddie Lim

    Hi, i also have one of the Chinese duplex board with black awkward “3d printed” case, google brought me here as i also have difficulties flashing the FW , mine came with FW ver of 1.3.x (no DAPNET support)

    My question is, since the jp1 hidden under the screen, can i permanently soldier the JP1 pin instead ? because i wanna do the 1 time job.

    I remember i have a STM32F108C type of first gen MMDVM, i need to flash the firmware via mapple USB bootloader first then only i can flash via arduino IDE.after that u need to “put back the jumper” in order for the STM32 chip to “save” it.

    Please let me know if you guys have any experience as i do not want to redo the soldiering part (due to my poor soldiering skill)

  22. Rafa_RGB

    Hi Eddie,

    As far as I know, JP1 must be done in order to be able to update the FW.

    As I mentioned en Sep 16th, my “german” board didn’t want to update without it.
    I have keept it done and it still works.
    (with some other problems because of 12Mhz TCXO but.,.. It’s another question)

  23. Roger Clark

    I think it depends on the hardware.

    I think my duplex board has a RPI GPIO connection to enable the firmware to be loaded from the RPi

  24. Rafa_RGB

    I used GPIO for the update…
    It didn’t work till I got the jumper done.

Leave a Reply