Re: DMRLink - bridge streams over writing.
Cort N0MJS <n0mjs@...>
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