Understanding Connect Plus trunking

[EricCottrell]

Hello,

I can receive 26 Connect Plus sites on 900 MHz alone, with good quality on most. There are two networks with users busy even on weekends. The local systems on VHF/UHF are single site and not as busy.

It is fortunate Motorola decided to use some standard DMR messages as it helps figure out what is going on. I spotted some Unit-to-Unit Voice Headers on a traffic channel and was able to figure out the indicating bit in the Voice GoTo Message. The last bit of the CSBK Voice GoTo message (the bit just before the CSBK CRC) is 1 when it is an unit-to-unit call, and the "Group" value is a radio id.

CSBK          lb:1 pf:0 MtCon+ Voice GoTo CId:001F66 Grp:001F41 LCN:1 Slot:B ?:00000000011  On Slot A of the control channel
VOICE Header  pf:0 UU V Ch Usr DRId:0x001F66 CRId:0x001F41                                  On Slot B of the control channel
voice frames
TLC           pf:0 UU V Ch Usr DRId:0x001F66 CRId:0x001F41                                  On Slot B of the control channel

I wonder if this is part of a call type field with 2 being a group call and 3 being an unit-to-unit call? This is different than the DMR Trunking Standard where they use different CSBKs for group and unit-to-unit calls.

The Connect Plus System Planner mentions 16776352 through 16776415 are not usable as radio IDs (0xFFFCA0 through 0xFFFCDF). The reason is system devices are assigned those addresses. I noticed 16776410 (0xFFFCDA) is involved in sending and receiving data over the system. I added code to dsd that decodes the data headers. My two local 900 systems are using IP Protocol and 16776410 is sending data and responses to radios. It appears some CSBKs on the traffic channel are used for supervisory control of the data transmissions.

73 Eric

 

[N8DRC]

Help

Hello,
Been running DSD+ and DMR Decoder since yesterday just started new user here, great audio everything working great just need a little help with this info on the screen shot mainly the line Control Channel Neighbor List line...


Thanks

 

[Forts]

Well... Most of it is pretty self explanatory. You are monitoring a Connect Plus system with a system ID of 125, and you are on site 11. It's using a color code of 2 and it's neighbour sites are 10 and 5.

 

[N8DRC]

Well... Most of it is pretty self explanatory. You are monitoring a Connect Plus system with a system ID of 125, and you are on site 11. It's using a color code of 2 and it's neighbour sites are 10 and 5.

yes I got all that stuff. I was curious about the the line with all the 0's and the few 1's in the control channel neighbor list line...What are all the 0's and 1's for? Thanks

 

[Forts]

That's the neighbour list in binary.... We had Ian leave the raw data there so it would be studied a little closer.

 

[N8DRC]

That's the neighbour list in binary.... We had Ian leave the raw data there so it would be studied a little closer.

Another question, Now I am on site 5 in which site 11 is linked to but on site 5 it does not show linked to 11. Does this make sense?

Thank you for your help!!!

 

[slicerwizard]

In any networked system, neighbor lists are normally reciprocal (if B is in A's list, A will be in B's list); this makes it easy for subscriber units to hop from one site to another and back again. There are exceptions though; most neighbor lists have fixed sizes, so site A may not be able to broadcast all of its neighbors while some of those neighbors will have room in their lists to include site A. Also, neighbor lists are manually entered by system techs, so anything goes, whether it's appropriate or not.

System design guidelines often recommend that neighbor lists include a site's immediate neighbors and those neighbors' neighbors, e.g. two rings of neighbors, to give subscribers alternate choices if an immediate neighbor site fails. Lists aren't always large enough to do that, so operators have to decide which sites to include and which to leave out, so expect to see some odd choices from time to time.

 

[N8DRC]

In any networked system, neighbor lists are normally reciprocal (if B is in A's list, A will be in B's list); this makes it easy for subscriber units to hop from one site to another and back again. There are exceptions though; most neighbor lists have fixed sizes, so site A may not be able to broadcast all of its neighbors while some of those neighbors will have room in their lists to include site A. Also, neighbor lists are manually entered by system techs, so anything goes, whether it's appropriate or not.

System design guidelines often recommend that neighbor lists include a site's immediate neighbors and those neighbors' neighbors, e.g. two rings of neighbors, to give subscribers alternate choices if an immediate neighbor site fails. Lists aren't always large enough to do that, so operators have to decide which sites to include and which to leave out, so expect to see some odd choices from time to time.

Thanks for the help guys!...This program is great.

 

[dtscho]

I know Privacy wasn't an option on Connect Plus in the past...has this changed?

Thanks,
Dave

 

[Forts]

Yes I believe Connect Plus does support privacy now.

Sent from my SGH-I747M using Tapatalk

 

[EricCottrell]

Hello,

I got involved in DMR on the ham bands a few months ago and use Motorola XPR radios. This has increased my understanding of DMR. I recently got to look at a couple of Connect Plus codeplugs.

Connect Plus runs on an option board in the radio and the radio requires a separate CPS for Connect Plus programming. A Connect Plus radio needs a regular codeplug, a Connect Plus codeplug, and a Network Frequency File to operate. The Network Frequency File lists frequencies and control channels at each site in a network.

The Manufacturer ID (MFID) sent in Connect Plus frames is registered to Trident Microsystems. Trident Microsystems also supplies Passport LTR that runs on the option board and requires a separate CPS. So Trident Microsystems must have developed Connect Plus for Motorola.

The Connect Plus codeplug was configured for single site operation as roaming was disabled and a preferred site was set. Over-The-Air (OTA) file transfer was enabled. I looked at the OTA information in the Connect Plus System Planner.

OTA file transfer is used to send firmware and Network Frequency File updates in an unconfirmed data session. The system manager schedules the transfer at a site for a period of time. The file is sent using one timeslot on a repeater at the site. A message is sent on the control channel indicating the OTA file transfer with file version information. The radio checks the version in the radio and will go over to the timeslot on the repeater sending the file to receive a later version. Since it is a unconfirmed data session, the radio will not send any responses. The file is sent multiple times in case data packets are missed.

OTA file transfer is an interesting feature to keep radios updated. It is also possible to update the Connect Plus codeplug in a radio via a dedicated data session with the radio.

So another control channel message to watch for. It would likely be intermittent rather than continuous 24/7.

73 Eric

 

[DaveNF2G]

RRDB Connect Plus listings

The RRDB shows only odd-numbered LCNs for a multistate CON+ network that I monitor (OneVoice). However, the control channels on the two sites that I can receive show both odd and even numbered LCNs.

Are the evens on the same frequencies as the odds?

 

[Forts]

Yes. 1 & 2 are same freq, 3 & 4 same freq etc etc....

 

[mtindor]

The RRDB shows only odd-numbered LCNs for a multistate CON+ network that I monitor (OneVoice). However, the control channels on the two sites that I can receive show both odd and even numbered LCNs.

Are the evens on the same frequencies as the odds?

To add one to what has already been said, and with the understanding that I have zero familiarity with the Onevoice system or those who administer its entry in the DB, I will say this:

Don't be surprised if you come across something in the DB that has consecutive LCNs or that doesn't seem to track when programmed with the LCN information in the DB. Although everyone should be marking confirmed LCNs properly and then marking unconfirmed LCNs with a really high number (like in the 90s, to differentiate it), you may or may not be able to depend upon that being the case across the board.

On the Staley TriConnex system in my neck of the woods, we try extremely hard to not only determine the actual LCNs but also notate them properly in the DB -- if there are known frequencies in use for which we do not know the LCNs, we mark them high (in the 90s usually). At least that way people know what frequencies are in use even if they do not know the LCN order and they know which ones they can depend upon being accurate.

Mike

 

[EricCottrell]

Hello,

A user stumbled upon a system doing an OTA update of the Network Frequency File in the radios. The user recorded a raw data file using DSDPlus.
http://forums.radioreference.com/vo...decoding-raw-data-rate-1-2-data-messages.html

The control channel was sending this CSBK. It is likely a special CSBK for OTA transfers.

+DMR slot1 BS DATA DCC=6 CSBK [LB=1 CSBKO=10 (?) FID=6 v1=131122 v2=2704 v3=6144]
0A 06 020032 000A90 1800
10001010000001100000001000000000001100100000000000 0010101001000000011000000000001100000100000101

The Type and Version Number is likely encoded in v1. v1 (020032) matches bytes sent in the network frequency file header. v2 (000A90) may indicate the number of segments (0A) and other information. v3 (18) directs the radio to Repeater 1, Slot 2 like a voice call.

The data transmission looks like a regular unconfirmed IP data transmission. There are CSBK Preambles and a Data Header. Each segment is an UDP frame. There is a pad byte and a four byte checksum at the end of each segment.

+DMR slot2 BS DATA DCC=6 Data Header DPF=[2:UcData] TG=16776415 Src=16776410 Conf=0 SAP=[4:IP Data] Blocks=46 Pad=1 Last=0 Seq=0

I was able to extract the UDP data and write a decoder program that printed out most of the information from the file. Unfortunately this file is only sent OTA when the system operator needs to update Network frequency information in the radios and does not want to pull in all the radios for update.

73 Eric

 

[EricCottrell]

To add one to what has already been said, and with the understanding that I have zero familiarity with the Onevoice system or those who administer its entry in the DB, I will say this:

Don't be surprised if you come across something in the DB that has consecutive LCNs or that doesn't seem to track when programmed with the LCN information in the DB. Although everyone should be marking confirmed LCNs properly and then marking unconfirmed LCNs with a really high number (like in the 90s, to differentiate it), you may or may not be able to depend upon that being the case across the board.

On the Staley TriConnex system in my neck of the woods, we try extremely hard to not only determine the actual LCNs but also notate them properly in the DB -- if there are known frequencies in use for which we do not know the LCNs, we mark them high (in the 90s usually). At least that way people know what frequencies are in use even if they do not know the LCN order and they know which ones they can depend upon being accurate.

Mike

Hello,

Sorry for the late reply as I just noticed your post.

DSDPlus uses the same channel numbering scheme for Connect Plus as it does for Capacity Plus. This scheme differs from Motorola and causes confusion. The RRDB is using the DSDPlus scheme and dropping the even channels as they are the same as the corresponding odd channel frequency.

[FONT="Courier New"]
DSDPlus      Motorola Connect Plus
Channel
1              Repeater 1, Slot 1
2              Repeater 1, Slot 2
3              Repeater 2, Slot 1
4              Repeater 2, Slot 2
5              Repeater 3, Slot 1
6              Repeater 3, Slot 2
...
[/FONT]

73 Eric

 

[DaveNF2G]

Each such system in the RRDB should have a prominent notice about identifying even numbered LCNs.