DSDPlus CC decoding - "Raw Data" and "Rate 1/2 Data" messages

[Schumi1978]

On a large system in NorCal that I have been monitoring (268-18), over the weekend I have noticed a difference in what is being logged by DSDPlus when it's decoding the CC. I constantly see "Rate 1/2 Data" messages on slot 2 of the frequency that has the CC in slot 1. Every now and then I am also seeing "Raw data" entries that I never seen before either. There is a reference to a TG, Src and Port in the log entry that are consistent in each log entry. Immediately after the Raw data log entry, the Rate 1/2 Data messages disappear then reappear after a Data Header entry on slot 2. Here is a snapshot of what the the logs show:

2016.03.21  8:01:33  +DMR           slot1         BS DATA       DCC=6  CSBK
2016.03.21  8:01:33  +DMR                slot2    BS DATA       DCC=6  Rate 1/2 Data
2016.03.21  8:01:33  +DMR           slot1         BS DATA       DCC=6  CSBK
2016.03.21  8:01:33  +DMR                slot2    BS DATA       DCC=6  Rate 1/2 Data
2016.03.21  8:01:33  +DMR           slot1         BS DATA       DCC=6  CSBK
2016.03.21  8:01:33  +DMR                slot2    BS DATA       DCC=6  Rate 1/2 Data
2016.03.21  8:01:33  +DMR           slot1         BS DATA       DCC=6  CSBK
2016.03.21  8:01:33  
Raw data: 45 00 02 23 00 00 00 00 40 11 90 11 0C FF FC DA E1 FF FC DF 0F A4 0F A4 02 0F 7C 3E 02 00 32 00 07 00 0A 40 17 B2 AE A5 40 02 AE A5 40 17 C2 AE A5 40 02 AE A5 40 17 D2 AE A5 40 02 AE A5 40 17 E2 AE A5 40 02 AE A5 40 18 0A B7 EF 2E 62 B0 4E 0E 18 1A B8 C1 24 72 B1 20 04 18 22 AE A5 40 12 AE A5 40 18 32 AE A5 40 02 AE A5 40 18 42 AE A5 40 02 AE A5 40 18 52 AE A5 40 02 AE A5 40 18 62 AE A5 40 02 AE A5 40 18 72 AE A5 40 02 AE A5 40 18 82 AE A5 40 02 AE A5 40 18 92 AE A5 40 02 AE A5 40 18 A2 AE A5 40 02 AE A5 40 18 B2 AE A5 40 02 AE A5 40 18 C2 AE A5 40 02 AE A5 40 18 D2 AE A5 40 02 AE A5 40 18 E2 AE A5 40 02 AE A5 40 19 0A C7 AB 80 02 C0 0A 60 19 1A CB D3 F4 12 C4 32 D4 19 2A CB DD B8 22 C4 3C 98 19 32 AE A5 40 02 AE A5 40 19 42 AE A5 40 02 AE A5 40 19 52 AE A5 40 02 AE A5 40 19 62 AE A5 40 02 AE A5 40 19 72 AE A5 40 02 AE A5 40 19 82 AE A5 40 02 AE A5 40 19 92 AE A5 40 02 AE A5 40 19 A2 AE A5 40 02 AE A5 40 19 B2 AE A5 40 02 AE A5 40 19 C2 AE A5 40 02 AE A5 40 19 D2 AE A5 40 02 AE A5 40 19 E2 AE A5 40 2016.03.21  8:01:33  02 AE A5 40 1A 0A BD 4D B1 E2 B5 AC 91 1A 1A CC 04 C8 F2 C4 63 A8 1A 22 C8 56 66 02 C0 B5 46 1A 32 AE A5 40 02 AE A5 40 1A 42 AE A5 40 02 AE A5 40 1A 52 AE A5 40 02 AE A5 40 1A 62 AE A5 40 02 AE A5 40 1A 72 AE A5 40 02 AE A5 40 1A 82 AE A5 40 02 AE A5 40 1A 92 AE A5 40 02 AE A5 40 1A A2 AE A5 40 02 AE A5 40 1A B2 AE A5 40 02 AE A5 40 1A C2 AE A5 40 02 AE A5 40 1A D2 AE A5 40 02 AE A5 40 1A E2 AE A5 40 02 AE A5 40 1B 0A CA BD A2 32 C3 1C 82 1B 1A CD 1F FC 42 C5 7E DC 1B 2A B8 FB BC 52 B1 5A 9C 1B 32 AE A5 40 02 AE A5 40 1B 42 AE A5 40 02 AE A5 40 1B 52 AE A5 40 02 AE A5 40 1B 62 AE A5 40 02 AE A5 40 1B 72 AE A5 40 02 AE 00 EE AA 16 10
2016.03.21  8:01:33  +DMR                slot2    BS DATA       DCC=6  Rate 1/2 Data ?; TG=16776415 Src=16776410 Port=4004 4004
2016.03.21  8:01:33  +DMR           slot1         BS DATA       DCC=6  CSBK
2016.03.21  8:01:33  +DMR                slot2    BS DATA       DCC=6  CSBK
2016.03.21  8:01:33  +DMR           slot1         BS DATA       DCC=6  CSBK
2016.03.21  8:01:33  +DMR                slot2    BS DATA       DCC=6  CSBK
2016.03.21  8:01:33  +DMR           slot1         BS DATA       DCC=6  CSBK
2016.03.21  8:01:33  +DMR                slot2    BS DATA       DCC=6  CSBK
2016.03.21  8:01:33  +DMR           slot1         BS DATA       DCC=6  CSBK
2016.03.21  8:01:33  +DMR                slot2    BS DATA       DCC=6  CSBK
2016.03.21  8:01:33  +DMR           slot1         BS DATA       DCC=6  CSBK
2016.03.21  8:01:33  +DMR                slot2    BS DATA       DCC=6  CSBK
2016.03.21  8:01:33  +DMR           slot1         BS DATA       DCC=6  CSBK
2016.03.21  8:01:33  +DMR                slot2    BS DATA       DCC=6  CSBK
2016.03.21  8:01:34  +DMR           slot1         BS DATA       DCC=6  CSBK
2016.03.21  8:01:34  +DMR                slot2    BS DATA       DCC=6  Data Header
2016.03.21  8:01:34  +DMR           slot1         BS DATA       DCC=6  CSBK
2016.03.21  8:01:34  +DMR                slot2    BS DATA       DCC=6  Rate 1/2 Data
2016.03.21  8:01:34  +DMR           slot1         BS DATA       DCC=6  CSBK
2016.03.21  8:01:34  +DMR                slot2    BS DATA       DCC=6  Rate 1/2 Data
2016.03.21  8:01:34  +DMR           slot1         BS DATA       DCC=6  CSBK
2016.03.21  8:01:34  +DMR                slot2    BS DATA       DCC=6  Rate 1/2 Data

Before the weekend this was not the case.

One other thing, while there doesn't seem to be any issue with DSDPlus decoding and following the trunking, the CC Channel Activity window will not populate Ch 1 or 2. Now the CC stays in a row identifying Ch as "?". This is what the CC Activity Window looks like now:

Things seem to working fine. A TG that was on Ch 14 will jump to Ch 3 on the next transmission / channel assignment and I do not appear to lose any voice traffic.

Curious if anyone knows what is going on and can explain what I'm seeing

 

[EricCottrell]

Hello,

I think you stumbled on the Over-the-Air (OTA) update feature of a Connect Plus system.

I noticed 16776410 is a common address for sending data to radios and responses for data sent from radios. The addresses 16776352 through 16776415 are reserved for the system and cannot be used for radio ids. 16776415 could be a special purpose broadcast address.

The Connect Plus System Planner explains that 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.

So if a large system updates the Network Frequency File, it just broadcasts the update on each site to update the radios rather than bringing hundreds of radios back to the shop.

If you see this again, I would be interesting in a raw audio file of the frequency sending this information.

73 Eric

 

[Schumi1978]

Eric,

Thank you for the explanation. It's been consistently like this the past 3 days or so.

I recorded roughly 2 1/2 mins of raw data and posted it here Zippyshare.com - CC-DSDPlus-Raw-Input_2016-03-22@092515.wav.

Let me know if this gives you what you are looking for or if I need to make a longer recording, etc.

 

[EricCottrell]

Hello,

That is exactly what I was looking for and there are multiple rounds of data transmission. Thanks.

I used the very verbose setting (-v4) and got a lot of information. There are a couple of unknown CSBKs on the control channel that may be involved with the data transmission. The data is transmitted in 10 segments using IP protocol and the same data is repeated. It is sent as unconfirmed data, so this seems to match the OTA description. I need to dig into this more.

73 Eric

 

[vince48]

Eric
Greetings, can P25 Motorola systems do this, "Over-the-Air (OTA) update feature"?


vince48

Hello,

I think you stumbled on the Over-the-Air (OTA) update feature of a Connect Plus system.

I noticed 16776410 is a common address for sending data to radios and responses for data sent from radios. The addresses 16776352 through 16776415 are reserved for the system and cannot be used for radio ids. 16776415 could be a special purpose broadcast address.

The Connect Plus System Planner explains that 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.

So if a large system updates the Network Frequency File, it just broadcasts the update on each site to update the radios rather than bringing hundreds of radios back to the shop.

If you see this again, I would be interesting in a raw audio file of the frequency sending this information.

73 Eric

 

[EricCottrell]

Eric
Greetings, can P25 Motorola systems do this, "Over-the-Air (OTA) update feature"?


vince48

Hello,

They do not for frequency information as the P25 site broadcasts a LCN to frequency table. The control channel gives the LCNs that a radio just looks up in the table.

In the case of Connect Plus, there can be up to 15 repeaters per site and they are identified as 1 though 15. When a Connect Plus radio is programmed, there is a codeplug for the Connect Plus option board and a frequency file. The frequency file translates the repeater id to the transmit and receive frequencies.

The file being sent sure looks similar to a Trunked Frequency file. The file is being transferred using the UDP protocol. There are 37 sites defined. All 15 repeaters for each site are defined with unused ones set at a default frequency. It appears they are using UHF High split XPR radios.

I made up a dummy tfn file for system 268 and copied the hex bytes for Site 1. I get reasonable values. Site 1 uses 6 repeaters and each repeater is a different color code.

Site 1
Rptr 1 463.7750 CC 3
Rptr 2 462.9250 CC 4 Control Channel
Rptr 3 462.0250 CC 5
Rptr 4 461.5000 CC 6 Control Channel
Rptr 5 461.7500 CC 7
Rptr 6 464.7000 CC 8

I will look at figuring out the encoding so I can have a program decode the values directly.

73 Eric

 

[Schumi1978]

Hello,

They do not for frequency information as the P25 site broadcasts a LCN to frequency table. The control channel gives the LCNs that a radio just looks up in the table.

In the case of Connect Plus, there can be up to 15 repeaters per site and they are identified as 1 though 15. When a Connect Plus radio is programmed, there is a codeplug for the Connect Plus option board and a frequency file. The frequency file translates the repeater id to the transmit and receive frequencies.

The file being sent sure looks similar to a Trunked Frequency file. The file is being transferred using the UDP protocol. There are 37 sites defined. All 15 repeaters for each site are defined with unused ones set at a default frequency. It appears they are using UHF High split XPR radios.

I made up a dummy tfn file for system 268 and copied the hex bytes for Site 1. I get reasonable values. Site 1 uses 6 repeaters and each repeater is a different color code.

Site 1
Rptr 1 463.7750 CC 3
Rptr 2 462.9250 CC 4 Control Channel
Rptr 3 462.0250 CC 5
Rptr 4 461.5000 CC 6 Control Channel
Rptr 5 461.7500 CC 7
Rptr 6 464.7000 CC 8

I will look at figuring out the encoding so I can have a program decode the values directly.

73 Eric

Awesome work, Eric!

I'm wondering when you have figured out the encoding if it would be possible to programmatically determine the Channel/Frequency pairings instead of having to do it manually like we do now? If we find systems sending these beacons, that would make things easier.

I'm no programmer or engineer but I am curious none the less about which parts and hex values of the raw CC dump (after running the raw data through DSDPlus at the -v4 log setting) you are looking at to come up with the above for example on Site 1? Do you see a correlation/match on Site 18 TelePath Corporation Site 18 DMR Bandplan - The RadioReference Wiki?

Maybe I'm getting in over my head but curiosity has gotten the better of me on this now...

Cheers.

 

[slicerwizard]

I'm wondering when you have figured out the encoding if it would be possible to programmatically determine the Channel/Frequency pairings instead of having to do it manually like we do now? If we find systems sending these beacons, that would make things easier.

Con+ systems typically send this information when new channels or sites are added, so most of the time, you won't be coming across this data.

 

[Schumi1978]

Con+ systems typically send this information when new channels or sites are added, so most of the time, you won't be coming across this data.

But when someone does, being able to easily build out the site configurations programmatically will go a long way. We all want things that make our lives easier

It would be cool if the DSDPlus developers could put a feature in a future release to handle this, either natively or by recording a raw data sample and running it through DSDPlus as is being done here.

 

[EricCottrell]

Awesome work, Eric!

I'm wondering when you have figured out the encoding if it would be possible to programmatically determine the Channel/Frequency pairings instead of having to do it manually like we do now? If we find systems sending these beacons, that would make things easier.

I'm no programmer or engineer but I am curious none the less about which parts and hex values of the raw CC dump (after running the raw data through DSDPlus at the -v4 log setting) you are looking at to come up with the above for example on Site 1? Do you see a correlation/match on Site 18 TelePath Corporation Site 18 DMR Bandplan - The RadioReference Wiki?

Maybe I'm getting in over my head but curiosity has gotten the better of me on this now...

Cheers.

Hello,

I created a Wiki page with the information I extracted and linked it in with the Telepath Wiki info. The system has 31 sites defined (1 - 30, 37).
Telepath Corporation Frequency Order and Color Code List - The RadioReference Wiki

I used the -v4 command line switch to dump as much information as possible.

This is likely a special CSBK for OTA transfers. The Type and Version Number is likely encoded in v1 and v2. v3 directs the radio to Repeater 1, Slot 2.
+DMR slot1 BS DATA DCC=6 CSBK [LB=1 CSBKO=10 (?) FID=6 v1=131122 v2=2704 v3=6144]
0A 06 020032 000A90 1800
100010100000011000000010000000000011001000000000000010101001000000011000000000001100000100000101

The data transmission is like a regular data transmission. There are CSBK Preambles and a Data Header. This indicates IP Protocol is being used and radios will not send confirmations.
+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

Each data frame sent can be broken down as
IP Header
45 		IP Version 4 with five 32 bit longs in the header
00 		Type of Service
02 23	Total Length
00 00	Identification
00 00	Flags and Fragment Offset
40		Time to live
11		Protocol = UDP
90 11	Header Checksum
0C FF FC DA		Source Address (12.255.252.218)
E1 FF FC DF		Destination Address (225.255.252.223)
UDP Header
0F A4	Source Port
0F A4	Destination Port
02 0F	Length
2D E4	Checksum
UDP Data
Frequency File Header
02 00 32  Unknown, possibly version information
00 01 	  File Segment (1 to n)
00 0A	  Total Number of Segments (10)
Frequency File Data
10 C0     Upper 12 bits = Network ID   Lower 4 bits = unknown
46 00     Unknown
Repeater Information follows
01		  Site Number 1
02 CB 4B 3C  TX Frequency Upper 4 bits is Repeater Number - 1 (0 = Rptr 1, 2 = Rptr 2, etc) Next bit is control channel indicator. Lower 27 bits is frequency * 100000, so 2CB4B3C = 46877500 or 468.775 MHz.
32 C3 AA 1C  RX Frequency Upper 4 bits is Color Code (3)  Lower 27 bits is frequency * 100000, so 2C3AA1C = 46377500 or 463.775 MHz.
01        Site Number 1
1A C8 78 94  Repeater 2, Control Channel, 466.9250
42 C0 D7 74  Color Code 4, 461.9250
... Repeats through all the defined sites over 1 or more segments There is one pad byte of zero and a four byte checksum at the end of each segment.
61 70 5F CE   Unknown
C1 6B 8B FF	  Unknown
00 00 00 00 00
00 A8 96 C6 74  Pad character and segment checksum

73 Eric

 

[vince48]

Eric
Super, Super job. Geez, I don't know how you do this, but you are providing a great education to us and helping us monitor these systems better. I tip my hat to you.

vince48

 

[Schumi1978]

Eric,

Thanks so much for the detail explaining the payload as well as creating the wiki article. It's very much appreciated!

 

[AM909]

I created a Wiki page with the information I extracted and linked it in with the Telepath Wiki info. The system has 31 sites defined (1 - 30, 37).
Telepath Corporation Frequency Order and Color Code List - The RadioReference Wiki...

So, in DSDPlus.frequencies format, the entries for site 3 would be:

Con+, 268, 3, 1, 463.7625, 468.7625, 0
Con+, 268, 3, 2, 463.7625, 468.7625, 0
Con+, 268, 3, 3, 461.3750, 466.3750, 0
Con+, 268, 3, 4, 461.3750, 466.3750, 0

Right?

 

[Schumi1978]

Correct. You can also leave out ch 2 and ch 4 in your example. DSDPlus is smart enough to know the TX frequency for ch 2 is the same as ch 1, ch 4 is the same as ch 3 and so on.

Sent from my SM-G920V using Tapatalk

 

[EricCottrell]

Eric
Super, Super job. Geez, I don't know how you do this, but you are providing a great education to us and helping us monitor these systems better. I tip my hat to you.

vince48

Hello,

I have been doing stuff like this as a "hobby" for years. I helped figuring out Passport LTR and Multi-Net LTR protocol years ago.

I am active on Ham DMR, so I have XPR radios and the Motorola CPS. My XPR4580 for the 900 MHz ham band used to be on a Connect Plus system. I read the option board codeplug and network frequency file before I reprogrammed the radio.

Since I have the CPS, I created a similar Network Frequency File for the system and compare it with the OTA file. The CPS comes with sample codeplugs, so I could create files for a UHF High XPR radio without actually having one.

I am a software developer and work with various protocols. I am familiar with various tools to look at raw data. Motorola using IP protocol makes it easier to figure out, since it is an open specification. It is possible to add capability to DSDPlus, or dsd, to take the IP data and dump it to a PCAP file. This allows network tools like Wireshark to look at it.

A lot of the detective work is looking for patterns. All 15 repeaters for each site are defined in the file with unused values set to a default frequency. When I converted the hex value to decimal, the format was obvious.

Icom Multi-Site IDAS (Nxdn Type-D) trunking does a OTA file transfer to a radio when it registers with the system. The file lists all the repeaters at the site with frequency information. This is very handy when figuring out those systems. I was able to monitor a local system and decode that information as well.

73 Eric

 

[EricCottrell]

Hello,

I noticed a small error in the frequency order list for site 26 that I corrected in the wiki. Repeater one's frequency is 454.60625. I looked it up in the FCC ULS and it is part of a block auctioned in Paging auction 40. The auction winner for the San Francisco area is Pacific Gas and Electric. Pacific Gas and Electric has a MPT-1327 system that also uses that block and 454.60625 fits into the channel plan. It appears the Telepath system uses other UHF frequencies licensed to Pacific Gas and Electric.

I noticed frequencies on Sites 19 and 20 are licensed to San Jose Evergreen Community College District. Site 19 is at San Jose City College and Site 20 is at San Jose - Evergreen Community College.

Some detective work is needed to figure out where these sites are located. It appears Site 18 is located on Black Mountain near Palo Alto.

I submitted the network frequency information to the RRDB.

73 Eric

 

[Schumi1978]

Hello,

I noticed a small error in the frequency order list for site 26 that I corrected in the wiki. Repeater one's frequency is 454.60625. I looked it up in the FCC ULS and it is part of a block auctioned in Paging auction 40. The auction winner for the San Francisco area is Pacific Gas and Electric. Pacific Gas and Electric has a MPT-1327 system that also uses that block and 454.60625 fits into the channel plan. It appears the Telepath system uses other UHF frequencies licensed to Pacific Gas and Electric.

I noticed frequencies on Sites 19 and 20 are licensed to San Jose Evergreen Community College District. Site 19 is at San Jose City College and Site 20 is at San Jose - Evergreen Community College.

Some detective work is needed to figure out where these sites are located. It appears Site 18 is located on Black Mountain near Palo Alto.

I submitted the network frequency information to the RRDB.

73 Eric

Yes, Site 18 is located on Black Mountain on the Monte Bello Ridge. I have identified these licenses licensed at the site:

WQND903 (TELEPATH CORPORATION) FCC Callsign Details
WQQT906 (TELEPATH CORPORATION) FCC Callsign Details
WQTF376 (TELEPATH CORPORATION) FCC Callsign Details

 

[EricCottrell]

Hello,

I tried to figure out some other sites, but it was apparent some licensees other than Telepath were being used and frequencies are licensed to multiple locations.

The link below is a listing of sites, but it seems to be just the major ones. I am thinking some sites maybe dedicated to particular Telepath customers, like 19 and 20.
Covergae Maps Overview Motorola Two Way Radio Service Telepath Corporation Fremont Northern California

73 Eric

 

[vince48]

question, what folder does DSDPlus use for the trunking frequencies?

 

[slicerwizard]

DSD+ looks for its data files (.networks, .sites, .groups, .radios and .frequencies) in whatever folder you run DSD+ in. Are you having a problem? If you describe it, we can probably sort it out.