search

juribeparada / MMDVM_CM

Cross-mode conversion tools for MMDVM software
44 stars 55 forks source link

YSF2DMR not recovering after YSF interruption #12

Open narspt opened 5 years ago

narspt commented 5 years ago

Hi Andy, I'm using YSF2DMR to bridge a YSF reflector to a XLX, all is working fine so far except that when there is some small interruption in a YSF transmission then YSF2DMR is apparently unable to recover (despite it shows on YSF2DMR log) and continue passing the audio after interruption to the XLX, until user stops and starts a new transmission. I did confirm that other users connected on the YSF are able to correctly get my audio after the interruption, YSF2DMR just doesn't seem to pass it to the XLX.

See logs below, I made a single continuous YSF transmission and during it I did intentionally interfere on it with a 2nd (analog) radio just to cause the interruption, very easy to reproduce:

MMDVMHost:
M: 2019-01-11 19:19:03.215 YSF, received RF header from CT2HRB     to ALL       
M: 2019-01-11 19:19:11.608 YSF, transmission lost, 8.4 seconds, BER: 4.2%, RSSI: -66/-47/-64 dBm
M: 2019-01-11 19:19:16.215 YSF, received RF late entry from CT2HRB     to ALL       
M: 2019-01-11 19:19:24.816 YSF, received RF end of transmission, 8.7 seconds, BER: 1.5%, RSSI: -66/-65/-65 dBm

YSFReflector:
M: 2019-01-11 19:19:03.240 Received data from CT2HRB     to ALL        at CT2HRB    
M: 2019-01-11 19:19:13.032 Network watchdog has expired
M: 2019-01-11 19:19:16.242 Received data from CT2HRB     to ALL        at CT2HRB    
M: 2019-01-11 19:19:24.838 Received end of transmission

YSF2DMR:
M: 2019-01-11 19:19:03.242 Received YSF Header: Src: CT2HRB     Dst: *****E03qG
M: 2019-01-11 19:19:03.242 DMR ID of CT2HRB: 2683149, DstID: TG 4004
M: 2019-01-11 19:19:16.243 Received YSF Header: Src: CT2HRB     Dst: **********
M: 2019-01-11 19:19:16.243 DMR ID of CT2HRB: 2683149, DstID: TG 4004
M: 2019-01-11 19:19:24.843 YSF received end of voice transmission, 8.6 seconds

XLX:
Jan 11 19:19:03 s4 xlxd: Opening stream on module D for client CT2HRB  B with sid 27186
Jan 11 19:19:13 s4 xlxd: Closing stream of module D

And another example doing it faster (YSFReflector didn't even "notice" the cut on this one):

MMDVMHost:
M: 2019-01-11 19:19:47.727 YSF, received RF header from CT2HRB     to ALL       
M: 2019-01-11 19:19:49.919 YSF, transmission lost, 2.2 seconds, BER: 14.6%, RSSI: -65/-47/-61 dBm
M: 2019-01-11 19:19:50.327 YSF, received RF late entry from CT2HRB     to ALL       
M: 2019-01-11 19:19:58.827 YSF, received RF end of transmission, 8.6 seconds, BER: 1.4%, RSSI: -66/-63/-64 dBm

YSFReflector:
M: 2019-01-11 19:19:47.755 Received data from CT2HRB     to ALL        at CT2HRB    
M: 2019-01-11 19:19:58.850 Received end of transmission

YSF2DMR:
M: 2019-01-11 19:19:47.759 Received YSF Header: Src: CT2HRB     Dst: *****E03qG
M: 2019-01-11 19:19:47.759 DMR ID of CT2HRB: 2683149, DstID: TG 4004
M: 2019-01-11 19:19:50.352 Received YSF Header: Src: CT2HRB     Dst: **********
M: 2019-01-11 19:19:50.352 DMR ID of CT2HRB: 2683149, DstID: TG 4004
M: 2019-01-11 19:19:58.855 YSF received end of voice transmission, 8.5 seconds

XLX:
Jan 11 19:19:47 s4 xlxd: Opening stream on module D for client CT2HRB  B with sid 20160
Jan 11 19:19:51 s4 xlxd: Closing stream of module D
w1bsb commented 5 years ago

We have noticed similar behavior on our YSF2DMR setup as well. We have YSFReflector running and YSF2DMR connected to XLX307D, and occasionally for some unknown reason it will just drop its connection to the XLX system and require a restart, sounds similar to this issue, but I haven't been able to pinpoint it yet.

narspt commented 5 years ago

@w1bsb: from your description seems not the same problem, mine never drops connection to XLX (but I run both on same server, meaning no network issues...) and doesn't require restart... the problem I describe is just that if some YSF TX is interrupted then it stops passing audio to XLX but next TX is ok again, just that. Maybe your problem is actually related to https://github.com/juribeparada/MMDVM_CM/issues/16 issue, if YSF2DMR and XLX are not on same server then occasional network issues may trigger it... check if when it happens you can see YSF2DMR connection on XLX nodes but without module letter, from some tests I made on past I think when YSF2DMR reconnects to XLX it doesn't "link" to a module.

w1bsb commented 5 years ago

@narspt we run it on the same server as well. One thing I did notice is the call drops off the module list. I forgot to check tonight when it dropped off though if it was still connected to the XLX master. It is running on the same system though so as you said networking should not be an issue. I will try to check next time it happens and see what I can find on the XLX end of things.

w1bsb commented 5 years ago

Just found this on the xlx log: Apr 1 12:31:29 n7mq xlxd[19091]: DMRmmdvm client KG7PRH B unlinking

Seems consistent with what you are talking about in your comment, its connected but not linked to a module.

narspt commented 5 years ago

Strange, that seems actually an intentional module unlink request from YSF2DMR? do you have on YSF2DMR config EnableUnlink=0 (on [DMR Network]) and EnableWiresX=0 (on [YSF Network])? if not try to disable both, maybe something is triggering a WiresX disconnect command... I have both disabled.

narspt commented 5 years ago

Just for curiosity... I run mine on XLX140A and it runs for months with no problems at all, other than the small problem I describe at my issue at top (only reproducible when a TX interruption occurs). Btw you can't see the YSF2DMR connection on my XLX because I did modify the XLX dashboard to hide it and to instead list the nodes connected to the YSFReflector along with XLX nodes, seems like a XLX with YSF support but it's really XLX+YSF2DMR+YSFReflector with dashboard "cosmetics" :)

w1bsb commented 5 years ago

I have EnableUnlink=0 but EnableWiresX=1. We have a wiresx connection. But honestly, I don't understand a whole lot about the YSF2DMR.

narspt commented 5 years ago

When YSF2DMR is working directly with MMDVMHost and EnableWiresX=1 it allows YSF2DMR to accept/reply WiresX-like commands so that you can use your radio WiresX features to control YSF2DMR (change what TG it is connected to, disconnect, etc...), also I guess EnableUnlink/TGUnlink/PCUnlink options control what to do when YSF2DMR receives a WiresX disconnect command (usually YSF2DMR should key on TG 4000 to unlink the TG from DMR master/XLX). Using YSF2DMR to bridge YSFReflector doesn't require any of such features, as it is not supposed to be controlled by WiresX commands to change anything, then you can surely disable these options. Anyway you already have EnableUnlink disabled, I don't really see how/why it would unlink... I can only tell that I did never see it happening on my setup... Maybe would help you check YSF2DMR log to see if there is something logged at exact time when that unlink happened...

w1bsb commented 5 years ago

Thanks, for some reason I was having a hard time digging into the logs to find the relevant information but it looks as if a user issued a disconnect command which caused YSF2DMR to unlink from the XLX module. I've disabled Wires-X in YSF2DMR, so we'll see if that fixes it.