Yeah, I hear you there. A lot of the systems near me are pretty quiet at night. And people look at me funny if I tell them I took a day off to go do some logging haha
- Status
Now let me pose this question to Forts and everyone else:
Is the LCN we're seeing in the FLCO=4 PDUs the LCN of the current frequency & timeslot, or the new rest channel frequency & timeslot?
Refering to page 7 of the capacity plus overview pdf:
The reason I ask is with no system controller, what benefit would the radios get by knowing the current LCN and not the LCN of the new rest channel they're supposed to move to? Or maybe the FLCO=4 steers the idle radios to the new rest channel LCN and the CSBK=62 has the current channel LCN buried in it somewhere?
If the rest channel is the only channel with the beacon data burst every 2 seconds, this could be pretty easy to test. Once voice traffic starts on the original frequency (which formerly carried the burst and was formerly the rest channel), scan all the other known system frequencies looking for the burst on a new channel. This would hypothetically be the new rest channel pointed to by the FLCO=4 PDU on the preceding original frequency. This reminds me of the backwards ways LTR system LCNs used to have to be mapped out.
Also, I think we can definitively structure the FLCO=4 PDU as follows:
Bits 0-23: Null (until we find evidence otherwise)
Bits 24-31: Group ID (max value 255 dec = all 8 bits set to 1)
Bits 32-33: May be leading 0s in LCN field, or extra space for something else (LCN likely only needs 6 bits max)
Bits 34-39: Logical Channel Number (LCN) ID of frequency & timeslot. For new rest channel? Or current channel?
Bits 40-55: Source radio ID (16 bits -> max value 65535 dec)
My best guess is that it is the new rest channel LCN, so the FLCO=4 is saying:
"Radio x is talking on group y. If you are on group y, stay here and unmute (and display radio x on screen)! If you aren't on group y, go to the new rest channel (LCN) and continue waiting!" The radio then compares its current group with group "y" and decides what to do.
I know that's a lot of guesses, but that's what makes this process so entertaining.
Regards,
Inigo
Is the LCN we're seeing in the FLCO=4 PDUs the LCN of the current frequency & timeslot, or the new rest channel frequency & timeslot?
Refering to page 7 of the capacity plus overview pdf:
The reason I ask is with no system controller, what benefit would the radios get by knowing the current LCN and not the LCN of the new rest channel they're supposed to move to? Or maybe the FLCO=4 steers the idle radios to the new rest channel LCN and the CSBK=62 has the current channel LCN buried in it somewhere?
If the rest channel is the only channel with the beacon data burst every 2 seconds, this could be pretty easy to test. Once voice traffic starts on the original frequency (which formerly carried the burst and was formerly the rest channel), scan all the other known system frequencies looking for the burst on a new channel. This would hypothetically be the new rest channel pointed to by the FLCO=4 PDU on the preceding original frequency. This reminds me of the backwards ways LTR system LCNs used to have to be mapped out.
Also, I think we can definitively structure the FLCO=4 PDU as follows:
Bits 0-23: Null (until we find evidence otherwise)
Bits 24-31: Group ID (max value 255 dec = all 8 bits set to 1)
Bits 32-33: May be leading 0s in LCN field, or extra space for something else (LCN likely only needs 6 bits max)
Bits 34-39: Logical Channel Number (LCN) ID of frequency & timeslot. For new rest channel? Or current channel?
Bits 40-55: Source radio ID (16 bits -> max value 65535 dec)
My best guess is that it is the new rest channel LCN, so the FLCO=4 is saying:
"Radio x is talking on group y. If you are on group y, stay here and unmute (and display radio x on screen)! If you aren't on group y, go to the new rest channel (LCN) and continue waiting!" The radio then compares its current group with group "y" and decides what to do.
I know that's a lot of guesses, but that's what makes this process so entertaining.
Regards,
Inigo
TampaTyron
Beep Boop, Beep Boop
"""""""""My best guess is that it is the new rest channel LCN, so the FLCO=4 is saying:
"Radio x is talking on group y. If you are on group y, stay here and unmute (and display radio x on screen)! If you aren't on group y, go to the new rest channel (LCN) and continue waiting!" The radio then compares its current group with group "y" and decides what to do."""""""""""
-----My best guess as well. This especially makes sense if you look how cap+ behaves in a failure mode (where one of the repeaters goes off line or the network switch tying the repeaters together dies). There is a specific sequence that happens when a repeater goes missing or are not connected tot he other ones. In the current system planner dated December 2010, in section 4.7.4, it describes what happens and specifically indicates bahaviors of the radios and repeaters. TT
"Radio x is talking on group y. If you are on group y, stay here and unmute (and display radio x on screen)! If you aren't on group y, go to the new rest channel (LCN) and continue waiting!" The radio then compares its current group with group "y" and decides what to do."""""""""""
-----My best guess as well. This especially makes sense if you look how cap+ behaves in a failure mode (where one of the repeaters goes off line or the network switch tying the repeaters together dies). There is a specific sequence that happens when a repeater goes missing or are not connected tot he other ones. In the current system planner dated December 2010, in section 4.7.4, it describes what happens and specifically indicates bahaviors of the radios and repeaters. TT
IanWraith
Member
Hello
I'm seeing 2 kinds of CSBKO 62 PDUs. The first looks like this ..
20:43:13 DMR Data Frame
CACH : TACT AT=1 Ch 1 Continuation fragment of LC
Slot Type : Colour Code 4 CSBK
Capacity Plus CSBK : CSBKO=62
Activity Update : Group 2 call
1100 0011 01000000 00000010 0000000000000000000000000000000000000000
Which telling everyone that there is a call from group 2 on LCN 3 (0011) which we more less understand.
The second type more numerous type looks like this ..
20:06:03 DMR Data Frame
CACH : TACT Ch 2 Continuation fragment of LC
Slot Type : Colour Code 4 CSBK
Capacity Plus CSBK : CSBKO=62
1110 0010 00000000000000000000000000000000000000000000000000000000
Note how this has no group at all but is giving a LCN 2 (0010). I suspect this is telling all mobiles on this channel that the current rest channel LCN is 2. What do you think ?
Regards
Ian
I'm seeing 2 kinds of CSBKO 62 PDUs. The first looks like this ..
20:43:13 DMR Data Frame
CACH : TACT AT=1 Ch 1 Continuation fragment of LC
Slot Type : Colour Code 4 CSBK
Capacity Plus CSBK : CSBKO=62
Activity Update : Group 2 call
1100 0011 01000000 00000010 0000000000000000000000000000000000000000
Which telling everyone that there is a call from group 2 on LCN 3 (0011) which we more less understand.
The second type more numerous type looks like this ..
20:06:03 DMR Data Frame
CACH : TACT Ch 2 Continuation fragment of LC
Slot Type : Colour Code 4 CSBK
Capacity Plus CSBK : CSBKO=62
1110 0010 00000000000000000000000000000000000000000000000000000000
Note how this has no group at all but is giving a LCN 2 (0010). I suspect this is telling all mobiles on this channel that the current rest channel LCN is 2. What do you think ?
Regards
Ian
Last edited:
Ucsd trbo
inigo88,
I'm monitoring the UCSD system using the freqs you posted earlier. I am able to decode the audio with DSD, and I'm looking at the data streams with that and DMR36.
I have also been monitoring the 453.0125, but have not decoded any audio, is that just a control channel or does audio "seldom" show up?
inigo88,
I'm monitoring the UCSD system using the freqs you posted earlier. I am able to decode the audio with DSD, and I'm looking at the data streams with that and DMR36.
I have also been monitoring the 453.0125, but have not decoded any audio, is that just a control channel or does audio "seldom" show up?
Just curious - is there any indication that there's a "system id" of sorts in the data, Ian? One would think it would be included since it is in many other trunking protocols.
Plus it would make it easier for me to understand this mish-mash of frequencies I have at the two sites I mentioned earlier...
Plus it would make it easier for me to understand this mish-mash of frequencies I have at the two sites I mentioned earlier...
I don't think there is any sort of system ID. There is no provision in the CPS for it....
I have been enjoying comparing Cap+ with LTR and its variants. With LTR standard all you get is one "Area bit" which can be 0 or 1. If you have several adjacent systems, this is no longer very helpful. Passport has something called DCC (Digital Color Code?), which could be something like 0 thru 6. As you can see, neither provide for a discreet system id, and thus I think the mototrbo Color Code is the Capacity Plus equivalent.
In other news, I have been trying to use Ian's new LCN CSBK format to map out the LCN IDs of the UCSD system. Unfortunately I have noticed some instances of the same group call on the same frequency showing inconsistent LCN IDs, so we still may not have the CSBK format quite right.
Regards,
Inigo
In other news, I have been trying to use Ian's new LCN CSBK format to map out the LCN IDs of the UCSD system. Unfortunately I have noticed some instances of the same group call on the same frequency showing inconsistent LCN IDs, so we still may not have the CSBK format quite right.
Regards,
Inigo
Hey there, I believe that 453.0125 is a mototrbo "Connect Plus" control channel. Unlike Capacity Plus, Connect Plus has a dedicated control channel. I have been meaning to investigate the other frequencies on the associated license to see if any voice traffic appears but I haven't had the time yet.
The only for sure UCSD Capacity Plus system frequencies are:
462.1375 - possibly LCN IDs 1, 2.
463.5125 - possibly LCN IDs 5, 6.
463.2125
462.0125
In some of the motorola documents I've read it says there can be a maximum of 4 voice frequencies, so 463.9875 may be data only.
Data Stream
I've been scanning all 10 of the UCSD frequencies and it appears that all of them have analog co-channel users, it's difficult picking out the "digital" only stuff. Is there a summary of the data string of which bits are what, (color code, time slot, group id, radio id, etc). from Ians previous post:
20:06:03 DMR Data Frame
CACH : TACT Ch 2 Continuation fragment of LC
Slot Type : Colour Code 4 CSBK
Capacity Plus CSBK : CSBKO=62
1110 0010 00000000000000000000000000000000000000000000000000 000000
Note how this has no group at all but is giving a LCN 2 (0010). I suspect this is telling all mobiles on this channel that the current rest channel LCN is 2. What do you think ?
I've been scanning all 10 of the UCSD frequencies and it appears that all of them have analog co-channel users, it's difficult picking out the "digital" only stuff. Is there a summary of the data string of which bits are what, (color code, time slot, group id, radio id, etc). from Ians previous post:
20:06:03 DMR Data Frame
CACH : TACT Ch 2 Continuation fragment of LC
Slot Type : Colour Code 4 CSBK
Capacity Plus CSBK : CSBKO=62
1110 0010 00000000000000000000000000000000000000000000000000 000000
Note how this has no group at all but is giving a LCN 2 (0010). I suspect this is telling all mobiles on this channel that the current rest channel LCN is 2. What do you think ?
ID Stream
From inigo88's earlier post:
"Also, I think we can definitively structure the FLCO=4 PDU as follows:
Bits 0-23: Null (until we find evidence otherwise)
Bits 24-31: Group ID (max value 255 dec = all 8 bits set to 1)
Bits 32-33: May be leading 0s in LCN field, or extra space for something else (LCN likely only needs 6 bits max)
Bits 34-39: Logical Channel Number (LCN) ID of frequency & timeslot. For new rest channel? Or current channel?
Bits 40-55: Source radio ID (16 bits -> max value 65535 dec)"
Is this about right?
From inigo88's earlier post:
"Also, I think we can definitively structure the FLCO=4 PDU as follows:
Bits 0-23: Null (until we find evidence otherwise)
Bits 24-31: Group ID (max value 255 dec = all 8 bits set to 1)
Bits 32-33: May be leading 0s in LCN field, or extra space for something else (LCN likely only needs 6 bits max)
Bits 34-39: Logical Channel Number (LCN) ID of frequency & timeslot. For new rest channel? Or current channel?
Bits 40-55: Source radio ID (16 bits -> max value 65535 dec)"
Is this about right?
Hey wa6yvx,
Let's move the UCSD-specific system discussion to my thread in the San Diego sub-forum here.
Regarding your questions, Ian and I have come to the same conclusions and he included them in the latest build (36) of DMRDecoder.
Ian:
I appear to have spoken too soon on the CSBK message LCNs being inconsistent. I have gotten the hang of watching the program in real time and comparing with the frequency on the scanner as it scans the known system frequencies, and the LCNs are now consistent (I was lagging behind before since the system trunks to the next channel extremely quickly).
I have also partially cracked the Unknown SLCO=15 messages. You will notice they often follow CSBK=62 Activity Update: Rest Channel LCN messages.
I have noticed the following format: 24 bit total
Bits 0-3: Message type? Always 0001 in my logs.
Bits 12-15: Indicate rest channel LCN!
So far, the rest of the bits are always zero.
Example:
Capacity Plus CSBK : CSBKO=62
Activity Update : Group 204 call on LCN 2
1110 0010 10000000 11001100 0000000000000000000000000000000000000000
Msg | LCN 2 | ??? | Group 204 |
(Ian: Per my email, I suspect the first four bits are the CSBK "message type." Any theories on what bits 8-15 ("10000000") might be saying? Maybe a specifier for call type or something?)
Short LC : Unknown SLCO=15 0001 00000000 0010 00000000
Notice how bits 12-15 repeat LCN 3! This has been consistent in all my logs so far.
Let's move the UCSD-specific system discussion to my thread in the San Diego sub-forum here.
Regarding your questions, Ian and I have come to the same conclusions and he included them in the latest build (36) of DMRDecoder.
Ian:
I appear to have spoken too soon on the CSBK message LCNs being inconsistent. I have gotten the hang of watching the program in real time and comparing with the frequency on the scanner as it scans the known system frequencies, and the LCNs are now consistent (I was lagging behind before since the system trunks to the next channel extremely quickly).
I have also partially cracked the Unknown SLCO=15 messages. You will notice they often follow CSBK=62 Activity Update: Rest Channel LCN messages.
I have noticed the following format: 24 bit total
Bits 0-3: Message type? Always 0001 in my logs.
Bits 12-15: Indicate rest channel LCN!
So far, the rest of the bits are always zero.
Example:
Capacity Plus CSBK : CSBKO=62
Activity Update : Group 204 call on LCN 2
1110 0010 10000000 11001100 0000000000000000000000000000000000000000
Msg | LCN 2 | ??? | Group 204 |
(Ian: Per my email, I suspect the first four bits are the CSBK "message type." Any theories on what bits 8-15 ("10000000") might be saying? Maybe a specifier for call type or something?)
Short LC : Unknown SLCO=15 0001 00000000 0010 00000000
Notice how bits 12-15 repeat LCN 3! This has been consistent in all my logs so far.
From what I can tell the source ID only shows up in the initial Full Link Control FLCO=4 messages. When we started this project the FLCO=4, CSBKO=62 and SLCO=15 message types were all unknown, and each one has its own format. You'll see in the previous posts we can now at least partially decode all three. The format you quoted me on is only the FLCO=4 format, the others are different.
Does the 'color code' have any bearing on anything with regards to CP? In other words, do all the frequencies in a CP system have to have the same color code (or vice versa, do they have to be different)?
I am still struggling to figure out this bunch of frequencies near me and I think I have 2 freqs on color code 8 and 2 on color code 7. Knowing if there's any tie between valid frequencies and color codes would help me a lot - despite the licenses and allocations, it looks like I have certain frequencies in one location and certain others in the other, and determining them is going to be a chore.
I am still struggling to figure out this bunch of frequencies near me and I think I have 2 freqs on color code 8 and 2 on color code 7. Knowing if there's any tie between valid frequencies and color codes would help me a lot - despite the licenses and allocations, it looks like I have certain frequencies in one location and certain others in the other, and determining them is going to be a chore.
IanWraith
Member
Hello Inigo & all
Nice going with the SLCO=15 decoding. What you have makes sense although I also only see ones that start 0001. The next build will decode those.
I'm not so sure about the first 4 bits of the CSBKO=62 PDUs being a type as I see decodes like this ..
19:26:10 DMR Data Frame
CACH : TACT Ch 1 Continuation fragment of LC
Slot Type : Colour Code 6 CSBK
Capacity Plus CSBK : CSBKO=62
Activity Update : LCN 5 is the Rest Channel
1100010100000000000000000000000000000000000000000000000000000000
19:26:10 DMR Data Frame
CACH : TACT Ch 2 Continuation fragment of LC
Slot Type : Colour Code 6 CSBK
Capacity Plus CSBK : CSBKO=62
Activity Update : LCN 5 is the Rest Channel
1110010100000000000000000000000000000000000000000000000000000000
19:26:10 DMR Data Frame
CACH : TACT Ch 1 Last fragment of LC
Slot Type : Colour Code 6 CSBK
Capacity Plus CSBK : CSBKO=62
Activity Update : LCN 5 is the Rest Channel
1100010100000000000000000000000000000000000000000000000000000000
Note how the 3rd bit alternates as if it is a channel indicator. Also look at this different type of CSBK=62 ..
19:00:10 DMR Data Frame
CACH : TACT AT=1 Ch 1 Last fragment of LC
Slot Type : Colour Code 6 CSBK
Capacity Plus CSBK : CSBKO=62
Activity Update : Group 2 call on LCN 6
1100011000010000000000100000000000000000000000000000000000000000
The first 4 bits are also 11x0 (where x alternates).
Pity about Capacity Plus not having any unique system identifier as that would have made things a lot easier for us later.
Regards
Ian
Nice going with the SLCO=15 decoding. What you have makes sense although I also only see ones that start 0001. The next build will decode those.
I'm not so sure about the first 4 bits of the CSBKO=62 PDUs being a type as I see decodes like this ..
19:26:10 DMR Data Frame
CACH : TACT Ch 1 Continuation fragment of LC
Slot Type : Colour Code 6 CSBK
Capacity Plus CSBK : CSBKO=62
Activity Update : LCN 5 is the Rest Channel
1100010100000000000000000000000000000000000000000000000000000000
19:26:10 DMR Data Frame
CACH : TACT Ch 2 Continuation fragment of LC
Slot Type : Colour Code 6 CSBK
Capacity Plus CSBK : CSBKO=62
Activity Update : LCN 5 is the Rest Channel
1110010100000000000000000000000000000000000000000000000000000000
19:26:10 DMR Data Frame
CACH : TACT Ch 1 Last fragment of LC
Slot Type : Colour Code 6 CSBK
Capacity Plus CSBK : CSBKO=62
Activity Update : LCN 5 is the Rest Channel
1100010100000000000000000000000000000000000000000000000000000000
Note how the 3rd bit alternates as if it is a channel indicator. Also look at this different type of CSBK=62 ..
19:00:10 DMR Data Frame
CACH : TACT AT=1 Ch 1 Last fragment of LC
Slot Type : Colour Code 6 CSBK
Capacity Plus CSBK : CSBKO=62
Activity Update : Group 2 call on LCN 6
1100011000010000000000100000000000000000000000000000000000000000
The first 4 bits are also 11x0 (where x alternates).
Pity about Capacity Plus not having any unique system identifier as that would have made things a lot easier for us later.
Regards
Ian
IanWraith
Member
IanWraith
Member
Hi
Has anyone else monitored a Capacity Plus system that also has something called DMRAlert like this ..
http://www.bc-ltd.co.uk/downloads/case-studies/digital/Meadowhall_CaseStudy.pdf
I think it accounts for the huge amount of data only terminals that appear on the system.
Regards
Ian
Has anyone else monitored a Capacity Plus system that also has something called DMRAlert like this ..
http://www.bc-ltd.co.uk/downloads/case-studies/digital/Meadowhall_CaseStudy.pdf
I think it accounts for the huge amount of data only terminals that appear on the system.
Regards
Ian
Now I'm really screwed up.
I now have "rest" pulses on 463.9375 on color code 8, and voice grants on the same frequency on color code 1. The voice grants are for groups and users that don't match the numbering on the trunk system. I get the feeling I'm hearing both the more distant of the two trunk systems, plus a local single-frequency repeater...?
I can't transfer the log file over to this computer to post it, but I will tonight.
I now have "rest" pulses on 463.9375 on color code 8, and voice grants on the same frequency on color code 1. The voice grants are for groups and users that don't match the numbering on the trunk system. I get the feeling I'm hearing both the more distant of the two trunk systems, plus a local single-frequency repeater...?
I can't transfer the log file over to this computer to post it, but I will tonight.
All the frequencies in the system I have been monitoring have the same color code (1), and I have been operating under the assumption that, like the LTR area bit or DCC, it would be the same for every channel. I wonder if it can be set differently in CPS?
I have another thread in the San Diego forum on the specific system I was mapping out (UCSD) here. I wrote an explanation of how I did it, using both CSBK activity updates for calls in progress and new rest channels (and then quickly scanning to find the new data burst). Hope that helps!
Edit: Also a couple frequencies have co-channel TRBO interference here too. I will be able to barely decode (mostly errors) the distant traffic and then the local system will cover it with rest channel data bursts!
Edit 2:
Jay911 said:
Can you hear which one covers the other? By your description, if you hear the data bursts "on top of" the more distant voice grants, then the color code 8 system is the closer one. You can keep an eye out for other color code 8 frequencies, although if they use different color codes on each frequency like Ian has seen in the UK, you'll have to look for continuity of talkgroups and LCN assignments instead. I got lucky with all the same color code.
Last edited:
- Status
Similar threads
