Re: DMRLink - bridge streams over writing.
Peter M0NWI
Hi Cort,
Thanks for you're answer, even if it's not what I wanted š
Do you believe I can replicate what I have now under Confbridge, if so I'll start to do that work, it's just been, ain't broke, don't fix it territory!!
73,
Peter
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 11 July 2018 13:14
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
Sent: 11 July 2018 13:14
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMRLink - bridge streams over writing.
Ā
Peter (and group),
* None of my code EVER plays favorites with a TGID based on some designator assigned by one of the ānetworksā. That would go completely against what I stand for with these projects.
* Bridge.py is a retired application. It hasnāt been developed for some time and is not supported.
The goal of the contention handler routines was to keep something like this from happening. I suspect one of two scenarios ā the contention handler is outright failing and sending the wrong traffic, or itās failing not quite outright and sending BOTH streams
to the repeater, which is picking the āotherā stream.
Iād really like to figure out which of those things is happening. In IPSC, Motorola has some kind of convoluted (to me) method of determining who gets access to the channel. Iām sure it makes sense to them, but when youāre reverse engineeringā¦. I really
am not entirely sure how they make the choice, but it appears significantly more complicated than āwho got here firstā.
Can anyone duplicate this behavior with confbridge.py? If so, then Iāll dig into it for sure. If itās just bridge.pyā¦. then I think the best answer I have is to move to confbridge, then weāll deal with it if it comes back. I know thatās not the answer
Peter wants to hearā¦ but itās the one I have.
0x49 DE N0MJS
On Jul 11, 2018, at 5:11 AM, Peter M0NWI <peter-martin@...> wrote:
Cort,
As you know I've got a fairly stable DMRLink bridge, this hosts 8 repeaters.Ā I was asked by one keeper to link the local S2TG9 from repeater A, toĀ repeater B S1TG9, I added both way rules to the bridge.py files, and it seemed to be OK, when user on A keys, output is send to the repeater B no problem.
Then I got reports that while listening on repeater B (connected to bridge Master B), to the stream from repeater A (bridge Master A), if another stream arrived into repeater B, same slot, different TG, say a National or International group from Master C in the same bridge, repeater B would drop the TG9 stream and play out the new Master C stream.
I thought that as the repeater B (Master B) was already outputting network traffic, it would ignore further traffic until the first stream finished, and a hang time had expired.Ā
Wonder if because they are streaming from different Masters in the same bridge, that that scenario hasn't been considered, and so hold off is not invoked?
Is there a priority that can/has been set within the streams, which is allow the national groups to take precedence over the local traffic?
73,
Peter
--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206