Net Hangtime not being observed

Post Reply
User avatar
kd2lh
Posts: 218
Joined: Mon Dec 02, 2019 2:44 pm

Net Hangtime not being observed

Post by kd2lh » Sun Jan 12, 2020 4:17 pm

I've got a small number of talkgroups configured as Brandmeister static groups on my GD-77 hotspot.

Recently, during a busy period, two of the talkgroups were simultaneously active.

Even though I have a 20 second net network hangtime defined in PiStar, when one conversation transmission on one of the active talkgroups stopped, the hotspot immediately switched to transmitting the conversation for the other active static talkgroup.

The hotspot should delay the number of seconds defined in my net hangtime before opening up to other talkgroups static configured for the hotspot.

User avatar
F1RMB
Posts: 507
Joined: Sat Nov 16, 2019 5:42 am
Location: Grenoble, France
Contact:

Re: Net Hangtime not being observed

Post by F1RMB » Sun Jan 12, 2020 4:24 pm

Hi Marc,
kd2lh wrote:
Sun Jan 12, 2020 4:17 pm
I've got a small number of talkgroups configured as Brandmeister static groups on my GD-77 hotspot.

Recently, during a busy period, two of the talkgroups were simultaneously active.

Even though I have a 20 second net network hangtime defined in PiStar, when one conversation transmission on one of the active talkgroups stopped, the hotspot immediately switched to transmitting the conversation for the other active static talkgroup.

The hotspot should delay the number of seconds defined in my net hangtime before opening up to other talkgroups static configured for the hotspot.
The hotspot has nothing to do with that, it just exchange data with MMDVMHost, and has no control of the network stuff behind.
This multiple TGs on a simplex works like this here, sometimes I get mixed QSO, that's funny to follow ;)

Cheers.
73 de Daniel.

User avatar
kd2lh
Posts: 218
Joined: Mon Dec 02, 2019 2:44 pm

Re: Net Hangtime not being observed

Post by kd2lh » Sun Jan 12, 2020 11:49 pm

Mmmm.... Well, thanks for that observation. I'll play around with it some on various hotspots to verify consistent behavior.

User avatar
W0RMT
Posts: 218
Joined: Sat Nov 16, 2019 12:45 pm
Location: Melbourne, Australia
Contact:

Re: Net Hangtime not being observed

Post by W0RMT » Mon Jan 13, 2020 2:49 am

That is governed by the BM master server, not mmdvmhost. The master just streams the data to your node. The only variation is that if you key up on one of the TGs, the other TG(s) will be held off (silenced) from streaming data to you for a set time (according to the hold-off timer on the master), after which they re-send. On US masters, the hold-off timer is longer than on non-US masters. 3108 is 120 s, and the other 310X are 300 s. The BM "recommended" hold-off is something like 20 s.

The net hangtime setting in pi-star governs how long the hotspot listens to one network before beginning to monitor multiple networks (eg DMR and YSF, or 2 different DMR networks). So it really only pertains if you have multiple networks (or multiple modes) enabled.
Bud W0RMT / VK3BUD
Colorado HD BM TG 31088
coloradodigital.net

VK3KYY
Posts: 1969
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia
Contact:

Re: Net Hangtime not being observed

Post by VK3KYY » Mon Jan 13, 2020 4:25 am

One difference between the normal hotspot and the OpenGD77 hotspot is that the radio stops transmitting when the data from the net has has ended.

So even if you change the Tx hold times, the radio will not continue to transmit an empty carrier when there is nothing from the net.

There are several reasons for this difference.

1. The GD-77 DMR hardware is not designed to transmit a carrier with no ID or data.
2. Transmitting when there is no real data would just cause unnecessary heating of the PA.
3. I never figured out exactly how MMDVMhost signals to the hotspot that the hotspot needs to continue to transmit.

So.. I don't think hotspot mode is ever likely to continue to transmit after the net data has ended.

User avatar
kd2lh
Posts: 218
Joined: Mon Dec 02, 2019 2:44 pm

Re: Net Hangtime not being observed

Post by kd2lh » Mon Jan 13, 2020 3:20 pm

It isn't the RF Hangtime, but the NET Hangtime that I'm concerned with. I need to go back and read the details of their intent and implementation.

I thought that the NET Hangtime would, for a period of time, hold the hotspot to the last active of several groups that are statically or dynamically defined back at the VOIP infrastructure. Thus subsequent incoming transmissions for that talkgroup would have priority over any others that had active conversations.

Now that I reread this, I realize that it's the RF mode and network Mode (DMR vs P25 vs YSF vs NXDN vs DStar) that is being held for the delay period.

Post Reply