Understanding Capacity Plus trunking, some more

[thewraith2008]

I read in whitepapers for Capacity Plus (CAP+), that private calls can be used.
I can't remember ever seeing a private call occurring but I'm interested if anyone has ever seen these types of calls.
How are private calls announced in a Capacity Plus system?

As we know with CAP+, all calls originate on the rest channel with all non participating parties moving to the new rest channel.
Normally, group calls (or what DSD+ calls TXI*) are announced via the CSBKO:62 FID:16 (Cap+_CH_Status) PDU.
My guess is that the Cap+_CH_Status does not announce private calls that are occurring on the CAP+ system channels is because it can't.
The fields it uses for channel activity only allows for 8 bits which are used to indicate the TG that is active on the channel.
A private call would require 16 bits to indicate target/called MS.

* Can someone remind me what TXI means in the context of DSD+. Are there other indicators used?

The next step in a call activity/setup is the use of the FLCO:4 FID:16 (Cap+_TX_User) in a VoiceLC Header PDU (SlotType: DataType: 1)
My guess is that a private call could be indicated here by the use of the 1st reserved bit (xxRRxxxx) in the (flco) service options.

• Is this what DSD+ uses to indicate TXI ?

This reserved bit (which always seems to be 1) may be used like a g_i field seen in other PDUs (1=GRP, 0=PRIV)

If CAP+ has a private call, does it use the call maintenance PDUs the normal way?

• FLCO:0 (Grp_V_Ch_Usr) for group calls
• FLCO:3 (UU_V_Ch_Usr) for private calls
• Or does it only use the Grp_V_Ch_Usr PDU and use the reserved bit (g_i?) to indicate GRP/PRIV activity?

What have other members observed in regard to this?
Thanks for sticking with me on this.

 

[lwvmobile]

I second this notion, if anybody has a full dump of known PDUs associated with Capacity Plus and how to read them, that'd be swell.

I read in whitepapers for Capacity Plus (CAP+), that private calls can be used.

Does the white papers have any information about the PDUs in general? (CSBK, FLC, SLC?) I literally have 1 CSBK that handles all Capacity Plus stuff in DSD-FME, along with one known Slow Link Control Opcode, and the Voice Link Control with the rest channel stored in it.

dsd-fme/src/dmr_csbk.c at v2.1b-final · lwvmobile/dsd-fme

Digital Speech Decoder - Florida Man Edition. Contribute to lwvmobile/dsd-fme development by creating an account on GitHub.

github.com

dsd-fme/src/dmr_flco.c at v2.1b-final · lwvmobile/dsd-fme

Digital Speech Decoder - Florida Man Edition. Contribute to lwvmobile/dsd-fme development by creating an account on GitHub.

github.com

dsd-fme/src/dmr_flco.c at v2.1b-final · lwvmobile/dsd-fme

Digital Speech Decoder - Florida Man Edition. Contribute to lwvmobile/dsd-fme development by creating an account on GitHub.

github.com

I'm still trying to figure out what the 4 bits that precede the rest channel bits are conveying. Site ID? Or something else?

FWIW, I have observed some proprietary data header and blocks inside of a Capacity Plus system that I have monitored, private calls (data calls perhaps) could be conveyed that way, but without knowing what the p_head and its blocks translates to, it could be anything, maybe not even associated with 'private calls' or the like.

Just for grins though, you aren't mistaken Capacity Plus for Capacity Max by any chance. Far as I can tell, that's mostly the same as a normal TIII Trunking System, uses the same group and private call csbk's as any TIII system does. It just has a FID of 0x10 and now 0x00.

 

[lwvmobile]

Also, was digging in the SDRTrunk source code, found some of these.

MOTOROLA_CAPPLUS_CALL_ALERT(Vendor.MOTOROLA_CAPACITY_PLUS, 31, "CALL ALERT"),
    MOTOROLA_CAPPLUS_CALL_ALERT_ACK(Vendor.MOTOROLA_CAPACITY_PLUS, 32, "CALL ALERT ACK"),
    MOTOROLA_CAPPLUS_DATA_WINDOW_ANNOUNCEMENT(Vendor.MOTOROLA_CAPACITY_PLUS, 41, "ENHANCED DATA REVERT WINDOW ANNOUNCEMENT"),
    MOTOROLA_CAPPLUS_DATA_WINDOW_GRANT(Vendor.MOTOROLA_CAPACITY_PLUS, 42, "ENHANCED DATA REVERT WINDOW GRANT"),
    MOTOROLA_CAPPLUS_NEIGHBOR_REPORT(Vendor.MOTOROLA_CAPACITY_PLUS, 59, "NEIGHBOR REPORT"),
    MOTOROLA_CAPPLUS_CSBKO_60(Vendor.MOTOROLA_CAPACITY_PLUS, 60, "CSBKO 60"),
    MOTOROLA_CAPPLUS_PREAMBLE(Vendor.MOTOROLA_CAPACITY_PLUS, 61, "PREAMBLE"),
    MOTOROLA_CAPPLUS_SYSTEM_STATUS(Vendor.MOTOROLA_CAPACITY_PLUS, 62, "SYSTEM STATUS"),

sdrtrunk/src/main/java/io/github/dsheirer/module/decode/dmr/message/data/csbk/Opcode.java at 75ef3217ac12d380d3622bf1b9fcf2c1d627ebea · DSheirer/sdrtrunk

A cross-platform java application for decoding, monitoring, recording and streaming trunked mobile and related radio protocols using Software Defined Radios (SDR). Website: - DSheirer/sdrtrunk

github.com

 

[thewraith2008]

Does the white papers have any information about the PDUs in general?

No, these are just Motorola documents on CAP+ (features and programming software).
A few patent PDFs exists but these are not 100% to what the PDUs ended up structured like.

I'm still trying to figure out what the 4 bits that precede the rest channel bits are conveying. Site ID? Or something else?

In which PDU?

Just for grins though, you aren't mistaken Capacity Plus for Capacity Max by any chance. Far as I can tell, that's mostly the same as a normal TIII Trunking System, uses the same group and private call csbk's as any TIII system does. It just has a FID of 0x10 and now 0x00.

No, definitely CAP+.
I like you have heavily modified dsd over the years to create something useful to me in regards to DMR trunk following.

 

[lwvmobile]

In which PDU?

Not sure what they are by name, but I'll show you the examples I have. This is from the main thread last night when we were working out a capacity plus rest channel bug.


In this CSBK for Rest Channel status below, we can see that the current rest channel is denoted by the 3 in the byte [C3], but what is the value of C representing here?

12:06:12 Sync: +DMR  [slot1]  slot2  | Color Code=01 | CSBK
 Capacity Plus Channel Status - Rest Channel 3
  Ch1: Idle Ch2: Idle Ch3: Rest Ch4: Idle
  Ch5: Idle Ch6: Idle Ch7: Idle Ch8: Idle
 DMR PDU Payload [BE][10][C3][00][00][00][00][00][00][00][BA][DB]

We can see the same in this Slow Link control. The 4 bits that make the 3 of [30], but the byte before that, the second 0 value. Just peeking more at Denny's SDRTrunk code, I think it may be a site id value. I didn't even know Cap+ carried site id values. I'm still learning as I go myself.

 SLCO Capacity Plus Rest Channel 3
 SLCO Completed Block [F1][00][30][87][70]

In this example, we have some non zero values in slow link control there instead.

17:19:40 Sync: +DMR  [slot1]  slot2  | Color Code=04 | CSBK
 Capacity Plus Channel Status - Rest Channel 2
  Ch1: Idle Ch2: Rest Ch3: Idle Ch4: Idle
  Ch5: Idle Ch6: Idle Ch7: Idle Ch8: Idle
 DMR PDU Payload [BE][10][C2][00][00][00][00][00][00][00][FD][08]
17:19:40 Sync: +DMR   slot1  [slot2] | Color Code=04 | CSBK
 DMR PDU Payload [BB][10][E2][21][12][00][00][00][00][00][03][43] <-- what opcode is 3B? [BB] -- Vendor.MOTOROLA_CAPACITY_PLUS, 59, "NEIGHBOR REPORT"
17:19:40 Sync: +DMR  [slot1]  slot2  | Color Code=04 | CSBK
 DMR PDU Payload [BB][10][C2][21][12][00][00][00][00][00][78][2B]
 SLCO Capacity Plus Rest Channel 34 <--this is based on my first incorrect assumption that rest channel was 8 bits, but it seems to be only 4
 SLCO Completed Block [F1][02][22][01][40] <-what does the 2 in byte [02] mean?
Sync: no sync

I like you have heavily modified dsd over the years to create something useful to me in regards to DMR trunk following.

Well, I'm glad you and hopefully others will find it of use. If nothing else, its a good PDU dumping tool. I like to keep things uniform and easy to read when I can.

 

[thewraith2008]

Not sure what they are by name, but I'll show you the examples I have. This is from the main thread last night when we were working out a capacity plus rest channel bug.

You should know the csbko# and fid# your trying to figure out?
From the sample shown, it's CSBKO:62 FID:16 (Cap+_CH_Status).
The 4 bits (after the FID and before the REST_CH) are FL[2] and TS[1] and [1] bit unknown/not used/reserved.
The FL bits are used like the LCSS bits in CACH (but with different allocation) and make it possible for the Cap+_CH_Status PDU to span multiple PDUs when needed to describe the 16 possible channel activity states.
If your not using them, then your not decoding the whole channel activity information when channel activity is greater than 5/6.

capacity plus rest channel bug.

To which bug do you refer?
The REST_CH is provided in multiple PDUs (SLCO/FLCO/CSBKO) to help keep track of it, if that fails then you must resort to channel hunting to relocate the REST_CH again.

Well, I'm glad you and hopefully others will find it of use. If nothing else, its a good PDU dumping tool. I like to keep things uniform and easy to read when I can.

I know what you mean

This is the RTL free standing trunking mode (one of the four modes it can run in)

It can still display in seizure mode but this is easier to read.

Normally I use a few RTL DSD (CC/CC follower for CAP+) instances with an external call controller program which controls a DSD VC follower to monitor a few different network/systems around me. It's my main go to these days.

The SiteID is also available in a couple PDUs (SLCO(15)/CSBKO(59, other?)) but the DSD current symbol timing/SYNC makes getting it from SLCO problematic when CAP+ is in beacon mode. While I get it, I normally use a user supplied field to make monitoring a few CAP+ networks possible as most CAP+ networks use the same value (e.g. Site 1). At the moment, I'm not sure what is required to make the DSD symbol timing/SYNC better (if that is actually where the issue is at)

 

[lwvmobile]

To which bug do you refer?

The one I had written into DSD-FME.

The FL bits are used like the LCSS bits in CACH (but with different allocation) and make it possible for the Cap+_CH_Status PDU to span multiple PDUs when needed to describe the 16 possible channel activity states.
If your not using them, then your not decoding the whole channel activity information when channel activity is greater than 5/6.

Ah, okay, interesting, didn't know that. Haven't had a system get so busy that I missed that, or maybe I did miss it and didn't realize.

The SiteID is also available in a couple PDUs (SLCO(15)/CSBKO(59, other?)) but the DSD current symbol timing/SYNC makes getting it from SLCO problematic when CAP+ is in beacon mode. While I get it, I normally use a user supplied field to make monitoring a few CAP+ networks possible as most CAP+ networks use the same value (e.g. Site 1). At the moment, I'm not sure what is required to make the DSD symbol timing/SYNC better (if that is actually where the issue is at)

I'm in the same boat, the first frame or so is usually bad, so the initial SLCO will always be bad, but that hardly matters much if your getting CSBKs anyways. Its the way the demodulator stores dibits when there isn't sync, as a string of 1's and 3's, and not actual dibits, well, that's part of the problem anyways. The entire dibit buffer system needs an overhaul. Actually, ideally, what I want to do in the future is just completely make the demodulation completely seperate from DSD-FME so it can just handle decoding dibits, and let a more robust program handle demodulation and just send the decoded symbols/dibits to FME to decode, and reconfigure the dibit buffer to handle 00,01,10,11 symbols instead of 1's and 3's, and maybe that will also fix the NXDN sync issues as well. I was going to prototype with gnu radio companion and see how that works, but I really don't know how much energy I have for that sort of thing anytime soon.

 

[thewraith2008]

Not sure what the other software decoders (i.e. OP25, SDRTrunk and others?) are doing and if they experience the same missed bursts with CAP+ beacon mode.

When I last looked, most open source code out there seems to be allergic to commenting their code which makes it harder to look over it to see what it does at a glance.

Definitely something that would be nice to rectify with DSD.

 

[Forts]

I'm on a Cap+ system here at work. If you want private call captures I could certainly make some.

 

[lwvmobile]

I'm on a Cap+ system here at work. If you want private call captures I could certainly make some.

Raw signal would be great, so we can get a look at any signalling for differences, etc.

 

[Forts]

Copy that. I'll bring in my programming cable tomorrow and do a couple radios up.

 

[lwvmobile]

Just to clarify, wav files of the raw signal from the BS repeater

 

[Forts]

Correct, yes.

Raw recordings from DSD+ ok?

 

[lwvmobile]

Raw recordings from DSD+ ok?

That'll be perfect. Thanks.

 

[thewraith2008]

That would be great to have some samples of these private calls occurring, thanks @Forts.

How is DSD+ indicating these private calls? Normally we see it say 'TXI' for the group type.

 

[lwvmobile]

Well, I found an interesting sample in my own stash of files. Its a capacity plus sample with voice in both slots at different times, and appears that these calls are private calls. It has some interesting FLCO's on the embedded voice bursts (0x23), private call TLCs (0x03), and a VLC with FLCO (0x07). I've had this sample for a while, but honestly never paid much attention to it until I randomly ran it test another thing I was working on. Let's see if it confuses you as much as it confuses me @thewraith2008

It also has instances of this CSBK

20:37:21 Sync: +DMR  [slot1]  slot2  | Color Code=04 | CSBK
 Capacity Plus Channel Status - FL: 1 TS: 0 RS: 0 - Rest Channel 5
  Ch1:  000 Ch2: Idle Ch3: Idle Ch4: Idle
  Ch5: Rest Ch6:  000 Ch7:  000 Ch8:  000
 DMR PDU Payload [BE][10][45][87][00][00][00][00][00][00][75][2C]
20:37:21 Sync: +DMR  [slot1]  slot2  | Color Code=04 | CSBK
 Capacity Plus Channel Status - FL: 2 TS: 0 RS: 0 - Rest Channel 5
  Ch1: Idle Ch2: Idle Ch3: Idle Ch4: Idle 
  Ch5: Rest Ch6: Idle Ch7: Idle Ch8: Idle 
 DMR PDU Payload [BE][10][85][00][00][80][14][02][CF][02][77][0E]

Upload files for free - dmr_dwa_sloty.wav - ufile.io

Download dmr_dwa_sloty.wav for free from ufile.io instantly, no signup required and no popup ads

ufile.io

 

[thewraith2008]

I will have a look at this later as I have a late call out.

A quick look indicates this is a CAP+ with RAS.
I will need to re-enable the code to allow bad CRCs to pass on RAS indication to see the PDUs.
Is the RAS "field" (R2,1,0) always 4? or can it be anything? I don't see them here normally.

 

[lwvmobile]

Is the RAS "field" (R2,1,0) always 4? or can it be anything? I don't see them here normally.

I was unaware there was a RAS 'field'. I was under the impression that any RAS enabled system simply used bad CRC values. When you say (R2,1,0), I am unsure of what you are pointing at.

Anyways, just give it a run at your convenience, and see what you think. I have made a few minor adjustments in my own code to treat (mfid=0x10 flco 0x07) as a Cap+ Private Call with it showing the correct rest channel as well (still can't 100% completely verify that, just a running assumption) and Embedded Voice Burst Sync (mfid 0x10 flco 0x23) as cap+ private call as well, again, could be signally something else, but I find if I do that, then I always get the same tgt and src from all three. Also assuming a TG value of zero on an active channel on a CSBK is indicating a private call as well, though I am unsure of how an MS unit would know how to check that to see if its a called party.

 

[thewraith2008]

The (reserved) R2,1,0 bits are in the payload data for various DataTypes that have BPTC applied.
These bits are normally ignored after the deinterleave/BPTC process.
When used, RAS utilizes these bit(s). Not sure if only the R2 bit is the flag or if more bits are utilized.
When I've come across RAS, these 3 bits always seem to equate to 4.

This is an interesting sample for sure, however been RAS and having both slots active is a little bit of a hindrance in this case.
I hope a non-RAS and single active slot sample can be provided sometime.

The PDUs seem to work this way: (does not just relate to this sample)
FLCO: 4 FID:16: Group call grant (that comes from the Voice LC Header)
FLCO: 7 FID:16: Private call grant (that comes from the Voice LC Header)

FLCO: 0 FID:16: Call maintainance PDU for group call (from the EMB) - I almost expected this to be a FLCO: 3x FID:16.
FLCO: 35 FID:16: Call maintainance PDU for private call (from the EMB)

FLCO: 0 FID:16: Call maintainance PDU for group call (from the TermLC)
FLCO: 3 FID:16: Call maintainance PDU for private call (from the TermLC)

Other PDUs seen in sample: (since the CRC failed on these, not sure if real)
FLCO:15 Unk_15 FID:16: from the Voice LC Header
CSBKO:42 P_MAINT_? FID:16: from the CSBK

So to summarize a private call setup:

• Target MS and Source MS are on rest CH (and anyone else who is not part of an ongoing call)
• FLCO:7 is sent and an MS that is not the Target MS and Source MS moves to the new rest CH. (This PDU indicates who is calling who)
• FLCO:35 (EMB) indicates MS that is talking
• FLCO:35 (TermLC) indicates the talking MS has stopped
• Call activity (channel allocation) will end after hang time (varies) and both MS will return to rest CH

Your TG=0 for slot activity probably confirms my earlier assumption that private calls are not announced with the Cap+_CH_Status (CSBKO:62 FID:0) PDU. If you wish to update a CH activity list, you will need to do it from using one or more of the above mentioned PDUs.

 

[thewraith2008]

Just another note about the RAS flag, it is better to use this than just allow all bad CRC-16 checksums (and potentially bad PDU decodes) to pass.
Currently, I test that SLCO:15, RAS != 0 and that CRC has failed before I say RAS is in use. I could probably tighten this by using RAS == 4.

I've not come across RAS in-use for CAP+ systems locally for awhile now so it was hard to test.
Is RAS used only for CAP+ or does it get used on other Motorola systems? (like DMR BS, CON+, CapMax)