Talking to radios with same ID

[Mark]

just to add to my previous comments, i thought i'd include these findings i made this week.. i cant decide whether its a bug or feature - operating through our repeater, with the same ID in both the DP3600 and DM4600 - they both work as expected to other ID / users, but if i tx on the DP3600 and listen to myself on the repeater output on the 4600 - the portable's audio is muted - in fact the mobile does not display any talkgroup information at all, just the flashing green LED & the signal meter, but others on the TG can hear me - on both sets, but my 4600 doesn't - despite the repeater being -78dBm... the repeater is IPSC, but this is all on a non routed TG - also i have the repeater input freq programmed in the mobile, to check if i can hear locals, and as expected, the mobile hears the portable - but the mobile receieve the portable on the input ch, but on the incorrect slot - the portable is tx on s2, but only the s1 input freq picks up the portable

Here's the interesting bit though - if i change the radio ID in the DP3600 - to anything other than what's in the DM4600 - the audio passes through the repeater as you would expect.

My guess was, that it was a feature, maybe something like if a portable user gets back in his vehicle - (with the mobile having the same ID as the portable) he would not get 'echo' from the mobile sets speaker on TX .. the problem with that is, if that you were sat in the car, you'd likely using the mobile set, not the portable, also a friend did the same test with DP4801 and DM4600 (both on fw 2.4) yet they did not exhibit this. I'm thinking it's a fw bug now

 

[Fatboy]

We have experienced this bug on and off throughout the firmware revisions. The symptom shows itself as a radio will not unmute speaker audio of a radio transmitting its own ID number. Users who all have the same Radio ID (typically ID 1) or users with a few random duplicates will complain about intermittent loss of RX. This has often been the root cause of these complaints. FB

 

[N4KVE]

My guess was, that it was a feature, maybe something like if a portable user gets back in his vehicle - (with the mobile having the same ID as the portable) he would not get 'echo' from the mobile sets speaker on TX

I believe this is a feature of the Motorola repeater. Here in Florida, on our statewide system which is comprised of 7 Hytera repeaters, this does not happen. Radios with the same ID can talk to each other. However on the DMR-MARC system which is made up of Motorola repeaters, units with the same ID can not talk to each other, & it doesn't matter what fw the radios have. GARY

 

[sswcmw]

I believe this is a feature of the Motorola repeater. Here in Florida, on our statewide system which is comprised of 7 Hytera repeaters, this does not happen. Radios with the same ID can talk to each other. However on the DMR-MARC system which is made up of Motorola repeaters, units with the same ID can not talk to each other, & it doesn't matter what fw the radios have. GARY

I have experienced it on our Motorola system, also, but was able to make it stop by turning off Enhanced Channel Access in the radios. YMMV.

 

[escomm]

We have experienced this bug on and off throughout the firmware revisions. The symptom shows itself as a radio will not unmute speaker audio of a radio transmitting its own ID number. Users who all have the same Radio ID (typically ID 1) or users with a few random duplicates will complain about intermittent loss of RX. This has often been the root cause of these complaints. FB

Can't say any of these conditions are present in my situation. In fact it happens as much with analog transmissions, obviously with no ID, as digital. My digital ID is unique and no other radios in the system use the same ID. Although it is a mixed mode scan list, for what that's worth.

 

[Mark]

I believe this is a feature of the Motorola repeater. Here in Florida, on our statewide system which is comprised of 7 Hytera repeaters, this does not happen. Radios with the same ID can talk to each other. However on the DMR-MARC system which is made up of Motorola repeaters, units with the same ID can not talk to each other, & it doesn't matter what fw the radios have. GARY

i only noticed it as i was playing with Enhanced Channel Access on our trbo repeater - but because i was distracted by the new rebooting feature during scan, i thought it was connected as a fw bug
- not so - as sswcmw was right on the money -

 

[Mark]

I have experienced it on our Motorola system, also, but was able to make it stop by turning off Enhanced Channel Access in the radios. YMMV.

Right on the money sswcmw .. Thanks..

 

[oldfart]

FWIW: For the digital aspects of LRRP/GPS, you can have 2 x radios with the same ID but on different channels. One being the base channel and the other being the GPS Revert channel.
Please feel free to correct me if I'm wrong!

cheers OF

 

[Jutod]

As one person previously mentioned of it being a result of the Mototrbo repeater itself, that is not the case. Mototrbo repeaters are simply passive devices and do not know there are other radios out there that have duplicate IDs, therefore the repeater can't regulate such. Also the repeater doesn't target the transmitted audio to each radio separately, but yet transmits the audio to a group of radios as the talk group ID with the transmitting radio's ID attached. Therefore, it's the trbo radio itself that the firmware knows not to open Rx audio with an ID that matches itself. And this has been changed several times with different firmware loads and releases from moto. They (moto) ought to just make a check box in CPS to turn this on or off in a radio. It obviously can be helpful at times, and others not.

 

[Astro Spectra]

For those people building wide area networks using the Rayfield C-Bridge product be aware that ID 1 is not bridged nor does it show in the NetWatch page. Personally, I can't see why you would not have individual IDs in each radio as many this gives so many useful fleet management benefits.

 

[sswcmw]

For those people building wide area networks using the Rayfield C-Bridge product be aware that ID 1 is not bridged nor does it show in the NetWatch page.

I have to say, respectfully, that this is incorrect. The c-Bridge, by default, will bridge any user ID. That being said, I go in and block any ID that is out of the range that we use so that it will not cross Managers, although obviously the repeater(s) on the same Manager will still repeat the traffic locally unless we use RAS. In the c-Bridge you can block on a per-Manager basis, or across all Managers.

So, for example, I have three Managers set up, and I have named them 1, 2 and 3 and I have the same talkgroup bridged across all three Managers. I can block a radio with an ID of 1 from keying up on a repeater on Manager 2 and passing audio to the repeaters on Manager 1 and 3, but that same radio can key up the talkgroup on a repeater on Manager 1 and the audio will pass to a repeater on Manager 3.

I do have to agree about the different ID's. With the total number available, there really is not a reason to not give every radio a unique ID, assuming logistics is not an issue.

 

[Astro Spectra]

Agree it is not a C-Bridge limitation, I stand corrected.

I've checked and in my case ID 1 is on the blocked radio ID list. It appears that out of the box ID from 1 - 20000 are included in the blocked radio ID list. I have to say appears as while I built and installed the server and C-Bridge software there are two other users with admin rights to the C-Bridge so it is possible that one of them implemented the block list. My C-Bridge version is from 2014 September 27 Revision:8205. Thank you for pointing this out.