Duplex Time Out

[M6NBP]

On a Simplex HotSpot you can key up any Talk Group and it says on that Talk Group.

But on a Duplex HotSpot the Talk Group times out the same as a Repeater does.

Can this be changed as a hotspot uses 7 Dig IDs and the system should know that it is a HotSpot and not a Repeater?


Many thanks

Norman

[KE0FHS]

See the answer by Andrew, M1DNS: viewtopic.php?f=5&t=1479&start=10#p6537

[M6NBP]

Thank you for your reply

But again can this be changed so Duplex HotSpot is treated different to Repeaters ?

As a HotSpot and Repeater is used 100% different to each other, this is why I have asked.

Some form of keep alive added


.

[AF6VN]

If I interpret the referenced thread -- this is how BrandMeister behaves; it is their server which drops the connection, and their server that considers duplex hotspots to be the same thing as a repeater.

There is nothing (that I can see) that Pi-Star can do (after all, does lack of traffic mean BM disconnected the talk group, or just that there is no traffic on the talk group). I'm pretty sure BM would not be happy if duplex hotspots started to "kerchunk" the server just to keep a talk group active.

[KE0FHS]

Some form of keep alive added

If you're running a duplex hotspot with Duplex Repeater selected as your Controller Mode, then you can still go into BrandMeister Self Care and set up a static talkgroup. If you do that, it should become an always on talkgroup that won't time out. If you key up a talkgroup from your radio, it is going to be linked as a dynamic talkgroup that will time out after a set period of inactivity, probably 15 minutes.

If the most important thing to you is to be able to key up a talkgroup and have it remain linked to the talkgroup even when there is no activity on that talkgroup, then you always have the option of running your duplex hotspot with Simplex Node selected as your Controller Mode.

[M6NBP]

I know you can set a static if you so wish.
But then if you want to talk on another TG your fighting the Static and it dropping out after x mins.
In the UK the dynamic talkgroup drops out at 5mins

I know we have two slots before you say use the other slot

Even if one slot could be made to work the same way a simplex hotspot works that would be a huge step forward


.

[VK3KYY]

This is probably something that BM need to add to their SelfCare section e.g. Dynamic TG timeout, and allow a setting of "never" possibly by setting it to zero.

On BM I have to put my duplex HS into Simplex mode, otherwise its virtually unusable, because of the timeout and subsequent disconnection, which means I can't select a TG to monitor just by keying the PTT on that TG.

The big downside with switching to Simplex is that I can't change TG's if the current one is active and the hotspot is transmitting.

The workaround I have for this a physical switch I attached to one of the GPIO pins on the PI (via the MMDVM_HS board's headers), which causes a script I run, to restart the MMDVMHost server, which then briefly disconnects from BM long enough for me to hold the PTT on another TG, so that when it reconnects, I can get onto another TG.

But its far from idea, and I need to be next to the hotspot to do this.

(Actually i have a 3 position switched attached to 2 GPIO pins to allow switching between profiles, but that's a long story ;-0)

[MW0MWZ]

I know you can set a static if you so wish.
But then if you want to talk on another TG your fighting the Static and it dropping out after x mins.
In the UK the dynamic talkgroup drops out at 5mins

I know we have two slots before you say use the other slot

Even if one slot could be made to work the same way a simplex hotspot works that would be a huge step forward


.

If the TGs you want to use are available as reflectors - you can still use those on a repeater, this behaviour is set by the master on DMR, not Pi-Star, so we can't change it.

Another option is that you can set a TG to be static, you can still use dynamics and then revert back to your static when the dynamics time out.

The last TG sticky thing, that is very much a BM feature.