search

juribeparada / MMDVM_HS

MMDVM HotSpot: firmware for ZUMspot or MMDVM_HS based boards (D-Star, DMR, YSF, P25, NXDN and POCSAG)
GNU General Public License v2.0
348 stars 140 forks source link

Duplex problem when replying to over after leaving a pause for other stations #70

Closed rogerclarkmelbourne closed 5 years ago

rogerclarkmelbourne commented 5 years ago

Andy

On the duplex hotspot, there appears to be a problem if I leave a pause between the other station's over and when I start transmitting.

The symptoms are that the COS LED and other LED's are not illuminated, and PiStar (MMDVMHost) shows that I'm not transmitting.

But the GD-77 is transmitting and does not beep to indicate that it can't make a connection.

The problem does not occur if I am testing without replying to another station.

If I simply transmit, then leave a pause, then transmit again, it works fine. I tried various lengths of pauses, on several occasions, but I could not replicate the problem at all.

However as soon as I am in a real QSO and leave a pause for for other stations, the problem happens virtually all the time.

juribeparada commented 5 years ago

I need more info to understand you issue. Do you transmit when the board has the TX LED still ON (but the other station finished)?. Maybe you have the hang time too short, that is a very common configuration problem in duplex mode.

juribeparada commented 5 years ago

I think you should look here: https://github.com/g4klx/MMDVM/issues/192 In that case is not a MMDVM_HS firmware issue.

rogerclarkmelbourne commented 5 years ago

Thanks

The issue on MMDVM does seem similar, but I had not noticed it when using the hotspot in Simplex mode.

Perhaps the radio (GD-77) operates differently in simplex

I'll need to do some more testing

juribeparada commented 5 years ago

This issue is only in duplex, wherever a MMDVM_HS or MMDVM system. I simply extend the hang time in my duplex devices and MMDVM repeater, and that's why Pi-Star uses 20 sec for hang time.

rogerclarkmelbourne commented 5 years ago

The problem occurs if I leave a pause of perhaps 1 second. I don't know if the hang time will make any difference.

juribeparada commented 5 years ago

Yes, because the problem is when you press PTT and the duplex board just turns the TX off (and no longer transmit the IDLE frames), but the radio "believes" that the duplex board or repeater is still transmitting, then the DMR radio begin to transmit without starts a DMR activation. It is a matter of timing problem, maybe the GD77 is "slow" between sensing the repeater TX and when the radio actually transmits to the repeater. Then the solution is simply extend the hang time: more DMR TX time after the call finishes.

rogerclarkmelbourne commented 5 years ago

Which hang time do you mean?

RF hangtime and net hangtime are both set to 20 secs. I presume you mean some other hang time?

juribeparada commented 5 years ago

In [DMR] section of MMDVM.ini, the parameter: TXHang=10 (or more seconds), but also in [General] section, NetModeHang >= TXHang, to be sure that you really extend TXHang. I've just tried to reproduce your issue, and I was able to produce only reducing TXHang too much (let's say 3 sec).

rogerclarkmelbourne commented 5 years ago

Hi Andy

My TXHang is currently set to 4 (this is DMR and also some other modes e.g. Fusion)

My NetModeHang is set to 300, so I don't think I'll need to change that.

I'll try changing the TXHang in DMR to 10 seconds and see if that fixes it.

Thanks

Roger

rogerclarkmelbourne commented 5 years ago

I did some tests and I don't think the hang time has resolved the problem.

The duplex hotspot, still occasionally does not seem to accept the incoming traffic from the radio, but the radio things that everything is working OK.

So I'll need to do some more tests to see if I can find a reliable way to reproduce the problem

juribeparada commented 5 years ago

Well, just be sure that actually extended the TX hang time for DMR, and also be sure that when you press PTT, the duplex board is still with the TX on and not about to turn off. For example, when you press the PTT and you note (looking at the log) that the board is not decoding, you should see if the board is still with TX on for several seconds more. If you press the PTT when the board is close to the transition from TX ON to OFF, you will get the problem.

rogerclarkmelbourne commented 5 years ago

I have the DMR Tx Hang time set to 10 secs and the Tx is definitely holding for much much longer.

However, I still had the same problem multiple times, even though I was not leaving a pause of anywhere near 9 secs between overs.

Perhaps its another timeout rather than the Tx Hang time which is causing this.

ea7gwc commented 5 years ago

I do not have MMDVM_HS in duplex but MMDVM in duplex. It seems a common problem. Can you try putting CallHang = 0 .....?

I'm trying it.

juribeparada commented 5 years ago

Roger, if you see a longer TX, then TX Hang is not the problem (when MMDVMHost starts you should see in the log "TX Hang: 10s", for example ). I tested again, and definitely I can't reproduce it, only reducing the TX Hang I get something close to your issue description. Maybe you have a specific problem with GD-77 and duplex board, specially now if you say that even "not leaving a pause". Have you tried simply changing the deviation a little (TXLevel=55 for example)?

rogerclarkmelbourne commented 5 years ago

When I tried DRMTXLevel of 55 (for my MD-380) the GD-77 had problems connecting.

Since no one else seems to have this bug, I'll close it, and re-open if I have time to work out whats causing it

JeffHochberg commented 3 years ago

I would like to request that this issue be re-opened. I can reproduce the issue consistently.

I am experiencing this same problem with a duplex MMDVM. I contacted the manufacturer and they clued me into this issue.

My initial reaction was that this might be related to the RXOffset/TXOffset values. I adjusted them to the point where my BER is incredibly low (at most 0.05%). I am using Motorola DMR radios (XPR 7550, XPR 5550e, and XPR 4550). They've all been sent to a Motorola service center for alignment, so they are dead-on accurate.

I've tried adjusting the offset and hang values and I don't see any improvement. The only thing that helps is waiting a second or two for the COS LED to illuminate. Having to monitor the status of the COS LED is not realistic as it's not reasonable to assume the user will be close to their hotspot.

@juribeparada I understand that you are busy and have not been able to return to development for quite some time. Is there anyone else involved in the development of the MMDVM firmware? Or is it a dead project at this point?