Dual Hat - Difficulty connecting on DMR if other modes are also enabled

[rogerclarkmelbourne]

Steps to reproduce...

Setup hotspot as "Duplex repeater" Setup DMR, with different Tx and Rx frequencies. Enable more than one mode in mmdvmhost, e.g. Enable YSF (Other modes may cause the same problem) Confirm that the HS is cycling though at least 2 modes Attempt top connect via DMR

Note. It takes multiple attempts to connect.

I suspect that possibly the hold time on each mode is not long enough, but I can't see a setting in MMDVMHost.ini which could be used to configure this.

[juribeparada]

I'm afraid there is not solution for this. It is a known "issue" (I will add to the README list) and has been discussed long time ago. A longer hold time will slow mode detection, and a short hold time will produce an incomplete frame decoding. The hold time is in firmware, if you want you can play with the values. This value is optimized for all modes in simplex, but duplex (with the wake up sequence) complicates the mode scan.

See at IO.h, lines 40 and 41.

[rogerclarkmelbourne]

OK. Thanks. I think perhaps that on the duplex hotspot, perhaps people would need to accept slower mode detection.

[rogerclarkmelbourne]

BTW. What does SCAN_PAUSE do ??

[rogerclarkmelbourne]

I've looked what what happens when the GD-77 connects to the hotspot and it only sends one burst of data to the hotspot, and it does not appear to retry :-(

So if the hotspot is not listening for DMR when the GD-77 sends its first connection data, it will not connect.

Extending the SCAN_TIME won't totally resolve the problem on the GD-77, it would just increase the probability of the hotspot listening on DMR at that time.

The only solution to this, I can think of is for every mode to listen for both DMR and also for the mode in question e.g. YSF would need to check the signal for YSF data and also DMR data.

But I have no idea if this is possible, as I don't know whether the firmware handles the mode detection or whether its handled by MMDVMHost.

I guess as this has all been discussed before there is no point discussing it again, as it can't be possible to monitor for two different types of data at the same time.

Ideally, programs like PiStar should prevent multiple modes being selectable for this type of duplex hotpsot.

[juribeparada]

Well, listen more than one mode at once is not possible with ADF7021: you need to configure the RX parameters before receiving, that's why we have mode scanning in MMDVM_HS and not mode detection like MMDVM, where you have access to the samples. With ADF7021 you only have access to the demodulated data stream, and each mode has different demodulation parameters.

[rogerclarkmelbourne]

Thanks for the explanation. I didn’t realise that the ADF7021 was being reconfigured for each mode.

I am going to do some tests with the “signalling system” options in the GD77, because I have been told it’s possible to change the number of retries. IMHO the default of 0 retries seems far too low. Probably a value of 2 or 3 retries would be better and perhaps then the hotspot would be listening for DRM again.

If I get time I will try modifying the firmware to use the DUPLEX define to increase the SCAN_TIME only for DRM on duplex hotspots. I see already the SCAN_TIME is multiplied by 20 for DMR, but this value would probably need to be made much higher to guarantee DRM connection when multiple modes are enabled . And this would be dependant in the retry timing of the radio e.g. GD77 or MD380 etc

[rogerclarkmelbourne]

Andy..

Just a thought, Only for Duplex boards...

perhaps change the order in which the modes are listened for

eg

instead of

DMR D-STAR YSF NXDN

Perhaps do

DMR D-STAR DMR YSF DMR NXDN

But perhaps this would take too long to get to the other modes to make them usable

[juribeparada]

I like the idea of a different mode scanning in duplex mode, maybe will work. I don't have too much time in this moment for testing, but something easy to test is simply increase the DMR time. Maybe you can help me to test if this produces any improvement or not:

change IO.cpp, Line 172: scantime = SCAN_TIME 2U; to: scantime = SCAN_TIME 4U;

or something else.

[rogerclarkmelbourne]

Hi Andy

No worries

I see there is a #define for the duplex board, so its easy to make duplex only changes including changing the DMR scan time to a longer value

I will need to check how often the radio sends the "wakeup" message, I think perhaps its every 250mS.

Changing the scan cycle may not be too difficult either.

If I get time I'll take a look. As I already setup one of my RPi boards to build MMDVM_HS

BTW. I can't figure out how m_modemState_prev or m_modemState state is cycled.

Is this done by MMDVMHost ?

[juribeparada]

Those vars are changed in the MMDVM_HS code, during IDLE state. The modem state is changed by MMDVMHost.

[juribeparada]

I will close this issue since this is a know problem of duplex mode (also added to "know issues" list in README). Feel free to re-open if you find any improvement after changing the MMDVM_HS constants values or code.

[rogerclarkmelbourne]

Thanks. I don't have time to investigate work-arounds for this, at the moment.

I'll re-open if I eventually find a solution.