TS net hold/prio. funktion

[faxe2110]

Hello Jonathan, the DMR Gateway is great. But i, and some others OM´s think it´s miss one little feature. An hold/prio. function for each TS. If there is running too much time between each answer under a QSO, sometimes the Ref. or some other TG from the other net is stealing me the TS on which i'm having a QSO. So if there will be an net hold or prio. for each TS so that the OM can config an hold/prio. time for the last net which was in QSO this will be a super great feature.

73 from Sweden
Tim de SA7BNT

[dg9vh]

To get a bit deeper into the issue is following that the audiosignals of two differnent networks in the same timeslot are mixed "frame by frame" if both are starting very simultaneous their transmissions.

@faxe2110 presents the solution to this to create a so called "network hang time" to stay a few seconds only on the last network where local tx-traffic appeared to keep qso's running and not get mixed up audio.

[dg9vh]

So back to this issue:
After thinking, sleeping a few nights over it and rethinking I come to following conclusion:
We need two hang-timers like we have in the MMDVMHost, one called NetRewriteHangTime (default 3 seconds) and the other called RFRewriteHangTime (default 7 seconds).

Why:
Under some particular setups we get following situation: If you map 2 different ressources from two different timeslots from one and the same network into one and the same timeslot on your repeater (for example if you map DMRplus completely on TS2 on a repeater to keep TS1 clear for BrandMeister national TG-traffic), you get following situation: You can have a QSO on TG9 for example and then after your over traffic from TG262 (TS1) catches the timeslot and disturbs your QSO.

To avoid this, we need those timers above on rewrite-based-manner, so that means that traffic that comes through a specific rewrite-rule locks the timeslot it was on for the specified time of the hang-timer. This could also avoid the situation @faxe2110 described above - mixing up 2 audio-streams.

Using the timers only on network-base would not solve the described problem exactly because TG262 could even catch the timeslot from TG9 if both where mapped to the same TS on the repeater but coming from different TS from network.

So Jonathan, could you please think about this a few minutes and say a word, if this could be done?

tnx.
Kim

[g4klx]

I like the idea of having two timeouts, that'd be easy to add and I will do soon.

I expected the network (DMR+ or BM) to manage individual slots and TGs and so the timeout was used to stay on that network on that slot, and any TG issues would be the responsibility of the network itself.

I think the problem in the code is that the timeout is based on the origin slot rather than the rewritten slot. In effect it's a bug in the code. I will look into that also when I get home. It only affects incoming network traffic not the RF side. I think that maybe this is what you are seeing. I hope so.

Jonathan G4KLX

[dg9vh]

Ok, you got it and we have patience enought to wait for it :-)

[m0lmk]

I would love to help with this if I can. I may need some support to start me off but i'm more than willing to give it a try!

We have 3 networks linked on our repeater (all on TS2, XLX on TG6, DMR+ on TG8 and BM on TG9) and we often lose calls because another network has grabbed the TS before the network traffic from the wanted TG comes back. It would be great if we can detect an RF user and which TG they are using then mute the other networks for x seconds.

[g4klx]

This already exists. It's called Timeout in [General] and you can use NetTimeout and RFTimeout to control the different times for network and RF traffic respectively.

[d51r3verse]

@m0lmk DMRGateway/MMDVMHost does not designed for duplex using
#78 (comment)
Also you can not trigger PTT when you still receiveing on same TS[As for now, MMDVMHost accepts RF, but DMRGateway blocks to write target network even repeater RX:IDLE. you need remove idle check conditions if you want control over congested network]

In multiple DMR networks(with congested), How about use store&forward buffer for conflicted/discarded network traffics?
Simplest way I implemented with using HBLink(few conditions to DMRGateway's dmr#->write sections, then hb_parrot to support more wait time&slot toggle functions)

But this mitigations also has issue: Buffered traffic conflicts realtime network->RF traffics when your DMR network really congested.
-My temporal solutions is: Complicated rewrite rules(modify rewrite rule functions/process order) to "all of DMR network realtime voices to RF:TS2(whatever network TS is)", "RF:TS1 for reflector/TG contol&buffered voice receive"

[g4klx]

Good idea about allowing full duplex through the DMR Gateway. In normal operation this isn't an issue but I can see you point.

Each mode in the MMDVM has its own buffer to handle delayed packets and DMR is no different. Putting it at the MMDVM allows for losses and delays throughout the network up until the modem. There have been cases where people have had their gateways remote from their repeater, and that link was not always reliable.

I'll look into the duplex issue.

[g4klx]

I spoke too soon. I find nothing in the DMR Gateway that will stop full duplex operation. Maybe the issue is in the host?

[d51r3verse]

Lol you spoke too soon...
I addressed duplex issue earlier(/w my aweful english descriptions... sorry)
#74 (comment)

For example... XLX + DMR#1~4 configured/connected.
Someone#1 talks to TG9 via XLXNetwork:TS2, Someone#2 talks to TG91 via Network#2:TS1
Pseudo status should below.
Internet -> DMRGateway : XLXNetwork.RX.TS2=Busy , Network2.RX.TS1=Busy
DMRGateway -> MMDVMHost : RF.TX.TS2=Busy, RF.TX.TS1=Busy

• Until I pressing PTT: Network[X1234].TX.TS[12] = Idle, RF.RX.TS[12]=Idle

Your voice(or TG/Reflector control) always discarded by DMRGateway whatever TS at Network#1,3,4. Also can not control Network#2's TS2.
Why: Every m_dmrNetwork#->write is inside of if (status[slotNo] == DMRGWS_NONE || status[slotNo] == DMRGWS_DMRNETWORK#) condition scope.
=>TS1, TS2 not Idle(used by XLXNetwork, Network#2), Therefore RF->Network only passes XLXNetwork:TS2, Network#2:TS1, others discards without notifications.
=> Only single variable that tracking slot status for both RF and every NET, also not knowing their RX/TX detailed status.

Am I too experimental? I amazed anyone does not yet informed or report duplex issues in multiple network enabled situations.

[g4klx]

I think you misunderstand the way that the gateway works, It is a switch, to allow you to have more than one network per slot. If you talk on a network, then that slot will be linked to that network for a period of time to make sure it doesn't switch away, this will allow a normal QSO to take place. After that time, the slot goes to idle and can go to any network based on either RF or network traffic.

The rewrite rules are there to allow for mapping of the different networks TGs and so that they don't clash and appear logical. That is why not every slot/TG/Id transform is possible.

I think you need something more powerful for experimentation. It may be an idea to start with the DMR Gateway and build on that, but remember this software is for use by normal radio amateurs and is not designed to be complex to understand.