On Jul 6, 2021, at 9:50 AM, Justin Mann via groups.io <w9fyi@...> wrote:

FOlks,
I’ve just compiled my Qnet gateway build on one of the boards put out by n5boc:
aka, Lonestar Semi conductor, and the board is a full duplex board. I uninstalled the configuration, created a new configuration indicating that my gateway was using an mmdvm host, and then recompiled the gateway. The gateway seems to work fine, but when I key, and unkey my radio, I get a sound that is kind of like some weird monster, and then I hear the confirmation of transmission. Is there any setting that I can change to aleviate this?
Thanks,
Justin

On Jul 6, 2021, at 11:58 AM, Justin Mann via <w9fyi@...> wrote:

****Update****
I recompiled the Qnet gateway app, choosing the board as a d-star modem, and that appears to work where as using an MMDVM host does not. ?DO full duplex mmdvm boards behave differently?

On Jul 6, 2021, at 9:50 AM, Justin Mann via <w9fyi@...> wrote:

FOlks,
I’ve just compiled my Qnet gateway build on one of the boards put out by n5boc:
aka, Lonestar Semi conductor, and the board is a full duplex board. ?I uninstalled the configuration, created a new configuration indicating that my gateway was using an mmdvm host, and then recompiled the gateway. ?The gateway seems to work fine, but when I key, and unkey my radio, I get a sound that is kind of like some weird monster, and then I hear the confirmation of transmission. ?Is there any setting that I can change to aleviate this?
Thanks,
Justin

On Jul 7, 2021, at 7:12 AM, Ryan Matthew Headley <headley.ryan@...> wrote:

Justin,

From the errors shown in your log, it appears that all of the errors are a result of MMDVMHost and YSFGateway not being able to communicate.?

Would you be able to post ~/MMDVMHost/MMDVM.qn and ~/YSFClients/YSFGateway/YSFGateway.qn ??? If so, I may be a able to offer some help.

On Jul 7, 2021, at 8:45 AM, Ryan Matthew Headley <headley.ryan@...> wrote:

Since you are having issues, my first suggestion would be that you configure and verify the functionality of each voice mode independently.? Disable Fusion and Fusion network and verify that D-Star is working; then configure Fusion.

You appear to be attempting to configure xlx307 directly in MMDMHost under your YSF network, but you also have YSFGateway configured.?

If you wish to XLX307 directly, the your configuration under Fusion Network should look like this:

[System Fusion Network]
Enable=1
LocalAddress=127.0.0.1
LocalPort=0
GatewayAddress=
GatewayPort=42000??? #note that the default for this field is 4200
# ModeHang=3
Debug=0

The advantage connecting directly to an XLX reflector is that you can change the module of the reflector from you radio.? However, this also makes it so that you can only connect to XLX307 modules and nothing else.? That is why I would recommend using YSFGateway instead.? For YSFGateway, the Fusion Network portion on MMDVM.qn should look like this (so long as you haven't changed the ports in YSFGateway.qn):

[System Fusion Network]
Enable=1
LocalAddress=127.0.0.1
LocalPort=3200
GatewayAddress=127.0.0.1
GatewayPort=4200
# ModeHang=3
Debug=0

The other thing I noticed is that your logs paths haven't been configured.? You need to specify an extant path for the log for MMDVMHost and YSFGateway.? I prefer to use /var/log.? I would create a directory for each log:

sudo mkdir /var/log/mmdvmhost
sudo mkdir /var/log/ysfgateway

After that go into MMDVM.qn and YSFGateway.qn and populate the FilePath under [Log] appropriately.? This isn't the only way to do it, but it is a fairly standard configuration for programs running in systemd.

On Jul 7, 2021, at 8:45 AM, Ryan Matthew Headley <headley.ryan@...> wrote:

Since you are having issues, my first suggestion would be that you configure and verify the functionality of each voice mode independently.? Disable Fusion and Fusion network and verify that D-Star is working; then configure Fusion.

You appear to be attempting to configure xlx307 directly in MMDMHost under your YSF network, but you also have YSFGateway configured.?

If you wish to XLX307 directly, the your configuration under Fusion Network should look like this:

[System Fusion Network]
Enable=1
LocalAddress=127.0.0.1
LocalPort=0
GatewayAddress=
GatewayPort=42000??? #note that the default for this field is 4200
# ModeHang=3
Debug=0

The advantage connecting directly to an XLX reflector is that you can change the module of the reflector from you radio.? However, this also makes it so that you can only connect to XLX307 modules and nothing else.? That is why I would recommend using YSFGateway instead.? For YSFGateway, the Fusion Network portion on MMDVM.qn should look like this (so long as you haven't changed the ports in YSFGateway.qn):

[System Fusion Network]
Enable=1
LocalAddress=127.0.0.1
LocalPort=3200
GatewayAddress=127.0.0.1
GatewayPort=4200
# ModeHang=3
Debug=0

The other thing I noticed is that your logs paths haven't been configured.? You need to specify an extant path for the log for MMDVMHost and YSFGateway.? I prefer to use /var/log.? I would create a directory for each log:

sudo mkdir /var/log/mmdvmhost
sudo mkdir /var/log/ysfgateway

After that go into MMDVM.qn and YSFGateway.qn and populate the FilePath under [Log] appropriately.? This isn't the only way to do it, but it is a fairly standard configuration for programs running in systemd.

On Jul 7, 2021, at 11:30 AM, Ryan Matthew Headley <headley.ryan@...> wrote:

For using YSFGateway, MMDVM.qn should have the following under System Fusion Network:

System Fusion Network]
Enable=1
LocalAddress=127.0.0.1
LocalPort=3200
GatewayAddress=127.0.0.1
GatewayPort=4200
# ModeHang=3
Debug=0

If you use the instructions I gave you for creating the log directories, then the log paths would look like this:

FilePath=/var/log/mmdvmhost? #for MMDVMHost, line 28 in the MMDVM.qn file you posted

FilePath=/var/log/ysfgateway? #for YSFGateway, line 29 in the YSFGateway.qn file you posted

For making changes to do with MMDVMHost or YSFGateway, you can stop and restart those specific programs without doing a complete uninstall; but things don't always behave properly when you do that.? The best bet is to run a 'us' command from qnadmin, then run an 'is' command.? There is no need to run qnconfig unless you are making changes to the D-Star side.? As long as you haven't run a 'git pull', there is no need to recompile.

On Jul 7, 2021, at 12:26 PM, Ryan Matthew Headley <headley.ryan@...> wrote:

That happens.? I don't know for sure, but I think it is a temoprary DNS error.? I have waited a bit before trying to connect to one of those listed as 'unable to resolve address' and have been able to connect.? Truthfully, there is really never anything in the error list that I ever connect to.

Glad you got it working!

On Jul 7, 2021, at 3:39 PM, Ryan Matthew Headley <headley.ryan@...> wrote:

You don't need to disable one to use the other.? There are to setting near the top of MMDVM.qn that control what is called 'Mode Hang'.

'RFModeHang' is the time in seconds that MMDVMHost will ignore other modes after you key up on a given mode.

'NetModeHang' in the time in second that MMDVMHost will ignore other modes after a network transmission has been made in a given mode.

As long as these two are set appropriately, you should never have an interrupted QSO in any mode. I personally prefer 20 seconds for RFModeHang and 10 seconds for NetModeHang.

On Jul 7, 2021, at 3:50 PM, Justin Mann via <w9fyi@...> wrote:

So there is no reason then I shouldn’t have DMR enabled as well. ?I don’t have a dmr radio, but if dmr is not enabled, will YSF2DMR work?

On Jul 7, 2021, at 3:39 PM, Ryan Matthew Headley <headley.ryan@...> wrote:

You don't need to disable one to use the other.? There are to setting near the top of MMDVM.qn that control what is called 'Mode Hang'.

'RFModeHang' is the time in seconds that MMDVMHost will ignore other modes after you key up on a given mode.

'NetModeHang' in the time in second that MMDVMHost will ignore other modes after a network transmission has been made in a given mode.

As long as these two are set appropriately, you should never have an interrupted QSO in any mode. I personally prefer 20 seconds for RFModeHang and 10 seconds for NetModeHang.

On Jul 8, 2021, at 11:02 AM, Ryan Matthew Headley <headley.ryan@...> wrote:

You shouldn't need to open ports to use YSF reflectors.? There is constant polling between YSFGateway and the reflector which keep everything open.?

From the log, it seems that YSFGateway is attempting to connect to America-Link on port 4200.? I double-checked, and the correct port for America-Link is 42000 (which is the standard WAN YSF port).?

On Jul 8, 2021, at 12:56 PM, Ryan Matthew Headley <headley.ryan@...> wrote:

Sorry that I wasn't clear.? The Fusion Network port in MMDVM.qn SHOULD be 4200.? This is the port used for communication between MMDVMHost and YSFGateway.

The port used for outbound connection from YSFGateway to a YSF reflector is most often 42000, as in the case of US-Amercia-Link.? The ports for outbound connections to YSF reflectors are found in ~/YSFClients/YSFGateway/YSFHosts.txt

On Jul 8, 2021, at 12:56 PM, Ryan Matthew Headley <headley.ryan@...> wrote:

Sorry that I wasn't clear.? The Fusion Network port in MMDVM.qn SHOULD be 4200.? This is the port used for communication between MMDVMHost and YSFGateway.

The port used for outbound connection from YSFGateway to a YSF reflector is most often 42000, as in the case of US-Amercia-Link.? The ports for outbound connections to YSF reflectors are found in ~/YSFClients/YSFGateway/YSFHosts.txt