MMDVM Duplex hotspot still has problems.

posted in: DMR | 8

Over the last few weeks I’ve been experimenting with the duplex MMDVM board, and it continues to have some problems which I thought I should share the details of…

 

  1. Not all of my radios connect reliably when the board is in duplex mode.The GD-77 seem to have the least issues connecting.

    The MD-380 will only connect if I change the DMRTxLevel to a higher value than is normal (somewhere between 53 and 57 seems to work).
    AFIK this setting changes the FM deviation of the 4FSH being produced by the ADF7021 transceiver chips on the board.

    I’ve had reports where MD-380’s would not connect at all, but I’ve also spoken to people who have a MD-380 and didn’t need to change the Tx Deviation.

    Also… when I change this value, the GD-77 has problem connecting.

    Even when my MD-380 manages to connect, the board seems to occasionally confuse which TimeSlot the MD-380 is transmitting on, with the result that no audio is received by anyone who is listening.

    I discussed this with Andy CA6JAU who writes the firmware, and he said there are general problems with the MD-380 connecting even to the simplex versions (e.g. Zumspot and JumboSpot), which are normally resolved my adjusting the DRMTxLevel.

    The other possible cause of the problem is time delay though the board, between when the MD-380 sending the connect (wake-up) message and when the MD-380 receives the response. However at the moment its unclear quite what is causing this issue, and unfortunately I don’t think Andy has time to investigate.

  2. When leaving a pause (break) before pressing the PTT in response to the last incoming over, the GD-77 seems to occasionally not connect – but does not give any notification that its not connected.It appears that if I press the PTT within one or perhaps two seconds, that the GD-77 seems to connect on most occasions, but anecdotally leaving a pause / break, seems to increase the chances that a connection fails.

    Whats strange is that if the GD-77 can’t connect, it normally beeps and stops transmitting after around 1 second. But in this case it continues to transmit, and the Pi-Star dashboard indicates that the hotspot is not receiving the transmission.

    This could be an issue with the way Pi-Star displays the status, however I think that the duplex hotspot board is not signalling to MMDVM Host that it has an incoming signal, but is still sending data back to the GD-77 hence it thinks that everything is working fine.

    I need to do more tests to attempt to confirm whether this problem is exacerbated by leaving a pause, or whether it happens at random, and to also determine where in the hierarchy the problem lies. i.e MMDVM_HS firmware or perhaps MMDVMHost or even DMR Gateway.
    My guess would be an issue on the board / firmware.

  3. Operating in duplex mode, the board is unable to support DMR and other modes at the same time (i.e where board scans for each mode for a short time.)

    I’ve posted about this before, but basically the ADF7021 chip on the MMDVM hotspot, has to be setup to receive different types of modulation when listening for DMR  to when listening for D-Star or YSF etc. Hence board listens for each type of modulation for a short time, in its scan loop.

    The problem is that for duplex DMR operation, where the transmit and receive frequencies are different, the transceiver e.g. GD-77 sends a connection (wakeup) data packet to the “repeater” and expects a fairly instant response.

    However if the duplex hotspot happens to be listening for D-Star (or YSF or P25 etc) when the transceiver sends this connection data, the duplex hotspot will not send back a response to the transceiver, and hence it won’t connect.

    The transceiver should make multiple (probably 3) connect attempts, with a small gap between each ( I think around 250 mS between attempt), but its possible that the duplex hotspot would not be listening for a DMR signal during any of the connection requests.

    The firmware already listens for DMR signals for something like 10 times longer than it listens for the other modes, but this is not long enough to guarantee it listening at the correct time.

    There may be a partial workaround for this, to change the duplex firmware, to listen for DMR signals for at least the as long as the time required to hear two connection requests, and to not listen for other modes, for longer than the gap between connection requests.
    This would probably mean that the scan loop would need to be changed from (for example)

    DMR
    D-STAR
    YSF
    DMR
    D-STAR
    YSF
    etc

    To

    DMR
    D-STAR
    DMR
    YSF
    DMR
    D-STAR
    DMR
    YSF
    etc

    However I don’t know if this would impact on the detection of D-STAR or YSF or the other modes

    It could also potentially result in the loss of the first second or two of audio for other modes.

  4. Even with the fix that Andy wrote; my board still has a timeout of around 4 minutes.
    Its possible that some boards have a worse timeout, as the value seems related to the difference in clock frequency in the transmitter e.g. GD-77 and the hotspot.

    My understanding of this problem is that there is no way to synchronize the data packets arriving from the transceiver (e.g. GD-77) and the data being sent back to from the hotspot. This is because the ADF7021 does not have a “recovered” clock output.

    I think there may be some hardware and firmware changes which may be able to fix this in the long term, but there is no simple fix for this without modifying the hardware.

 

I suspect there may be other problems that I am not aware of, so please feel free to comment if you have another problem with these boards.

 

My overall view of these boards is still that they are generally good value, as they cost less than $10 more than the Jumbospot. But it is very new technology and you may potentially have to run it in Simplex mode, either permanently or until specific problems are fixed.

 

8 Responses

  1. rswenton
    |

    Hi Roger,

    While I have not been as methodical in my testing as you have I did notice almost every item you noted with the Duplex Hat.

    I don’t have any MD-380 radios. I have Anytone AT-868UV, Radioddity GD-77 and Connect Systems CSI 800D radios. Each one has a different nuance and a different symptom repeatability.

    All my duplex boards and radios run perfectly in simplex. Some of the work-arounds dramatically improve duplex performance. One is not to scan the other modes when using DMR.

    I now have a dedicated hotspot just for NXDN and another just for DMR so I don’t have to use one hotspot in scan mode for both protocols.

    The Hat firmware, now on 1.4.8 has incrementally improved performance. I find it amusing that the cheapest radio I own, the GD-77, has the most consistent access to the duplex hotspots. It’s almost 100%.
    Since the 1.4.8 upgrade I have not noticed the hotspot jumping to a different time slot. However, I have seen symptoms disappear in the past only to magically reappear later.
    I should,note I am using Nextion screens with the Nextion Helper driver. While this shouldn’t have any impact you can never be sure there are no interactions such as CPU load or timing while servicing the display.
    Right now my duplex hotspots are usable. Every so often they miss an incoming transmission. As you noted, it all has to do with how quickly or slowly you being transmitting after the other party is done. Everything seems to be a moving target and no single symptom is pointing to a single cure. You can’t really complain for the price. Thank you so much for all you do for us.

    73

    -Rick, W1RHS

  2. Roger Clark
    |

    Hi Rick

    I’m not sure what version of firmware you were running prior to upgrading to 1.4.8, but the difference between 1.4.7 and 1.4.8 is only to fix USB issues on the Raspberry Pi 3B+ (for compatibility with boards like the Zumspot Libre etc that connect via USB)

    The only recent bug fix that affected the duplex operation, was the partial fix for the timeout problem.

    As I run my hotspots in duplex mode, so that I can have TS1 and TS2 on different DMR networks, I don’t use my MD-380 with it – because the settings needed to make it work, are mutually exclusive with the GD-77, and I have 2 GD-77 radios, hence my preference is for it to work with both of them.

    Re: Nextion driver.

    I don’t have a Nextion display. I have one board that came with a OLED, and I also tried attaching another OLED to another of my duplex hotspots, but only one section of the display works. (because I found its not got quite the same driver chip on the OLED as is supported 🙁 – hence in the photo a lot of the display just has dots on it)

    Looking at the way the displays are connected the OLED is connected directly to the RPi and driven directly my MMDVMHost from linux.

    As far as I can tell the Nextion displays are connected to the STM32 on the duplex board, and hence they would actually load the firmware a bit more than the OLED.
    But as the Nextion just gets sent a few commands via serial, this would not be a big load and I’m not sure it would make any difference at all.

    BTW.
    I’m investigating how to connect a 3.2 in SPI LCD display (with the well supported ILI9341 controller chip on it), as I think it could be a poor man’s Nextion – and because I’ve got lots of those displays in various sizes (from 2.2inch to over 3.2inch)
    This would be directly connected to the RPi via its SPI pins (unfortunately not connected though on these Chinese duplex board clones – but are connected to the board on the original version)
    So would not load the firmware.

    Re: Remaining problems

    I constantly experience the issue when leaving a break, but I can tell straight away that its not working as I’ve noticed the Carrier On Sense (red LED) does not light up when this happens.

    What I don’t understand at the moment is why the GD-77 does not beep to tell me there is a problem.
    If my duplex hotspot is turned off, the GD-77 makes 4 attempts to connect and then beeps… So the hotspot must be transmitting data back to the GD-77 in these cases.

    I’ll raise an issue on Github about this and possibly discuss it with Andy via emial, so that hopefully we can get a fix.

  3. Roger Clark
    |

    Rick

    FYI. I just checked the Tx Preamble setting on the MD380 and it seems to be defaulted to 300mS where as the GD-77 value is 360mS

    I’ve not had time to try changing it, and it may only affect SMS messages, but I think its probably worth increasing it, and see if it helps generally with the MD-380 etc connecting to the duplex hotspot

  4. Robert Fullarton
    |

    Hi Roge
    I have set my preamble time to 960ms! I saw a post somewhere about md380 settings, I thought is was on the vkdmr website but I can’t find it now.

  5. Robert vk4apf
    |

    Found it! it’s in the vkdmr newsletter.
    https://groups.io/g/ScarcNews/attachment/29/0/VK-DMR%208th%20Newsletter%202018.pdf

  6. Roger Clark
    |

    OK. Thanks

  7. Jason Brown
    |

    Hi Roger – I was wondering if you were ever able to get the SPI LCD screen working. I am working on a homebrew MMDVM and happen to have one of those screens you mentioned. I would love to get it working with this setup if you were able to figure it out.

  8. Roger Clark
    |

    I’ve been too busy on other problems to develop code etc to connect a SPI LCD screen to my hotspot.

    The normal Jumbospot hardware, would not have enough connections easily available to attach the screen, so I was going to use a STM32 “Blue Pill” board connected to the “Nextion” pins on the Jumbpspot, (which is Serial data), and then write some firmware to parse the data etc

    If you are developing your own hardware, you could design it so that the SPI LCD could connect directly to it.

Leave a Reply