Understanding Capacity Plus trunking, some more

[thewraith2008]

That's kind of what I was thinking, if I get around to trying it out sometime, I may just force all VC6 to go to the BPTC and look at its payload for grins.

Just had a quick look at passing the buffer to the BPTC code and it did not pass.

The buffer I used did not have the AMBE voice frame de-interlacing applied and I also removed what would have been the 20 bits for the SlotType field so the payload is 196 bits (from the available 216).

I probably should also try it on the original AMBE de-interlaced buffer as well but I think using two types of de-interlacing on a buffer to be odd.

Thanks for the other information on the Late Entry MI.
Definitely a topic for another day for me.

 

[DSheirer]

While updating sdrtrunk to parse the FID 0x10 CSBKO 62 site status messages, I found this example of a Cap+ Multi-Site system recording from Dallas, TX, where an additional bit is set in the data/private options bitmap. There's a cycling between using 0x80 and 0x90 for the data radio IDs bitmap. The 0x90 value seems to correlate with the timeslot where the activity will take place. This example is a data revert channel hosting LSN 1 & 2.

I have several examples of this happening and have reasonably high confidence this is not a bit error.

Initially I thought this might be a flag that indicates 'waiting for call parties to arrive on channel' since it seems to happen when there is a longer sequence of these status messages preceding the activity. However, I'm not sure that's accurate since you wouldn't be able to identify which LSN is waiting for additional radios to show up. But, if it's only sent on the channel/timeslot where the activity will occur, then maybe this is correct.

I wanted to throw this example out there in case anyone is looking in code for a full 0x80 value versus simply looking for a high bit in the first nibble, for the options bitmap.

Denny

---

BE10E2000080803039000320 TS:2 CC:6 CSBK CAP+ SITE STATUS REST LSN:2 [FL] VOICE LSN 1-8:* 9-16:* DATA LSN 1:12345 2:* 3:* 4:* 5:* 6:* 7:* 8:*
BE10C2000090803039007C12 TS:1 CC:6 CSBK CAP+ SITE STATUS REST LSN:2 [FL] VOICE LSN 1-8:* 9-16:* DATA LSN 1:12345 2:* 3:* 4:* 5:* 6:* 7:* 8:*
BE10E2000080803039000320 TS:2 CC:6 CSBK CAP+ SITE STATUS REST LSN:2 [FL] VOICE LSN 1-8:* 9-16:* DATA LSN 1:12345 2:* 3:* 4:* 5:* 6:* 7:* 8:*
BE10C2000090803039007C12 TS:1 CC:6 CSBK CAP+ SITE STATUS REST LSN:2 [FL] VOICE LSN 1-8:* 9-16:* DATA LSN 1:12345 2:* 3:* 4:* 5:* 6:* 7:* 8:*
BE10E2000080803039000320 TS:2 CC:6 CSBK CAP+ SITE STATUS REST LSN:2 [FL] VOICE LSN 1-8:* 9-16:* DATA LSN 1:12345 2:* 3:* 4:* 5:* 6:* 7:* 8:*
BE10C2000090803039007C12 TS:1 CC:6 CSBK CAP+ SITE STATUS REST LSN:2 [FL] VOICE LSN 1-8:* 9-16:* DATA LSN 1:12345 2:* 3:* 4:* 5:* 6:* 7:* 8:*
BE10E2000080803039000320 TS:2 CC:6 CSBK CAP+ SITE STATUS REST LSN:2 [FL] VOICE LSN 1-8:* 9-16:* DATA LSN 1:12345 2:* 3:* 4:* 5:* 6:* 7:* 8:*
BE10C2000080803039007848 TS:1 CC:6 CSBK CAP+ SITE STATUS REST LSN:2 [FL] VOICE LSN 1-8:* 9-16:* DATA LSN 1:12345 2:* 3:* 4:* 5:* 6:* 7:* 8:*
BE10E2000080803039000320 TS:2 CC:6 CSBK CAP+ SITE STATUS REST LSN:2 [FL] VOICE LSN 1-8:* 9-16:* DATA LSN 1:12345 2:* 3:* 4:* 5:* 6:* 7:* 8:*
BE10C2000080803039007848 TS:1 CC:6 CSBK CAP+ SITE STATUS REST LSN:2 [FL] VOICE LSN 1-8:* 9-16:* DATA LSN 1:12345 2:* 3:* 4:* 5:* 6:* 7:* 8:*
BE10E2000080803039000320 TS:2 CC:6 CSBK CAP+ SITE STATUS REST LSN:2 [FL] VOICE LSN 1-8:* 9-16:* DATA LSN 1:12345 2:* 3:* 4:* 5:* 6:* 7:* 8:*
                         TS:1 CC:6 UNCONFIRMED DATA HEADER FM:1531 TO:12345 PROPRIETARY DATA BLOCKS TO FOLLOW:2 FRAGMENT SEQUENCE NUMBER:0(FINAL) PAD OCTETS:0
BE10E2000080803039000320 TS:2 CC:6 CSBK CAP+ SITE STATUS REST LSN:2 [FL] VOICE LSN 1-8:* 9-16:* DATA LSN 1:12345 2:* 3:* 4:* 5:* 6:* 7:* 8:*
                         TS:1 MOTOROLA MNIS HEADER APPLICATION:ARS PACKET:47089 PACKET PREFIX:0009F0 MSG:1F10020133B7F10009F081D5
BE10E2000080803039000320 TS:2 CC:6 CSBK CAP+ SITE STATUS REST LSN:2 [FL] VOICE LSN 1-8:* 9-16:* DATA LSN 1:12345 2:* 3:* 4:* 5:* 6:* 7:* 8:*
                         TS:1 CC:6 RATE 1/2 DATA CONFIRMED:313533310000A552A12F UNCONFIRMED:2004313533310000A552A12F
                         TS:1 CC:6 FM:1531 TO:12345 ARS DEVICE REGISTRATION-INITIAL DEVICE:1531
BE10E2000080803039000320 TS:2 CC:6 CSBK CAP+ SITE STATUS REST LSN:2 [FL] VOICE LSN 1-8:* 9-16:* DATA LSN 1:12345 2:* 3:* 4:* 5:* 6:* 7:* 8:*

 

[lwvmobile]

I wanted to throw this example out there in case anyone is looking in code for a full 0x80 value versus simply looking for a high bit in the first nibble, for the options bitmap.

I wonder who that message is aimed at lol. Your git commit looks awefully familiar

I had wondered myself if (or which) bits of that 'flag' were relevant, and the significance of them. In the samples I had with data going on there, I never saw any value other than 0x80, so I was just going off of what I had seen to that point, and had considered just leaving it to check for any value in there.

Just to make sure though, that we are looking at the same pieces, this is what I see

//lb/pf/op   //fl/res/ts    //lsn1-8  //lsn9-16  //'flag'   //data or private call lsn   //16-bit target     //crc
BE10         E2             00        00         80         80                           3039             00 0320
BE10         C2             00        00         90         80                           3039             00 7C12

So,

The 0x90 value seems to correlate with the timeslot where the activity will take place.

wouldn't the second 0x80 be the lsn the data (or private voice call) would be taking place, and not the first 0x80 or 0x90?

 

[DSheirer]

I wonder who that message is aimed at lol. Your git commit looks awefully familiar

Sorry, I was trying not to call out anyone

Yes, I think we both interpret it the same way, where the first 0x80 (or 0x90) seems to be the options flags and the second 0x80, in this example, is the active LSNs bitmap where LSN 1 is active.

 

[lwvmobile]

Yes, I think we both interpret it the same way, where the first 0x80 (or 0x90) seems to be the options flags

So, any idea on how to intepret the options then? Another thing we discovered is that anything there can refer to either data calls, or private voice calls as was submitted by Forts in his wav files. We still haven't found a way to distinguish (if it is distinguishable or not) the difference between a data call and a private voice call in the channel status CSBK, just that you'll know when you tune to it and see it.

Forts Private Voice Call Sample:

09:35:29 Sync: +DMR  [slot1]  slot2  | Color Code=03 | VLC 
 SLOT 1 TGT=21001 SRC=21002 FLCO=0x07 FID=0x10 SVC=0x00 Cap+ Private Call  Cap+ R-Ch 4
 DMR PDU Payload [07][10][00][00][52][09][04][52][0A][50][ED][7F]
 
09:35:29 Sync: +DMR   slot1  [slot2] | Color Code=03 | CSBK
 Capacity Plus Channel Status - FL: 3 TS: 1 RS: 0 - Rest Channel 4 - Single Block
 F80 Private or Data Call -  LSN 03: TGT 21001;
  LSN 01:  Idle;  LSN 02:  Idle;  LSN 03: 21001;  LSN 04:  Rest; 
  LSN 05:  Idle;  LSN 06:  Idle;  LSN 07:  Idle;  LSN 08:  Idle; 
 DMR PDU Payload [BE][10][E4][00][00][80][20][52][09][00][99][03]
 
 SLCO Capacity Plus Site: 1 - Rest Channel 4 - RS: 00
 SLCO Completed Block [F1][00][40][81][C0]

09:35:29 Sync: +DMR  [SLOT1]  slot2  | Color Code=03 | VC1*
 AMBE F801A99F8CE000 err = [0] [0]
 AMBE F801A99F8CE000 err = [0] [0]
 AMBE F801A99F8CE000 err = [0] [0]
 
09:35:29 Sync: +DMR   slot1  [slot2] | Color Code=03 | CSBK
 Capacity Plus Channel Status - FL: 3 TS: 1 RS: 0 - Rest Channel 4 - Single Block
 F80 Private or Data Call -  LSN 03: TGT 21001;
  LSN 01:  Idle;  LSN 02:  Idle;  LSN 03: 21001;  LSN 04:  Rest; 
  LSN 05:  Idle;  LSN 06:  Idle;  LSN 07:  Idle;  LSN 08:  Idle;

Fun Example with three data and/or private voice at the same time:

09:21:53 Sync: +DMR  [slot1]  slot2  | Color Code=01 | CSBK
 Preamble CSBK - Individual Data - Source: 119 - Target: 1 - Rest Channel: 2 -RAS 4 
 DMR PDU Payload [BD][10][80][02][00][00][01][02][00][77][17][3C]

09:21:53 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Capacity Plus Channel Status - FL: 2 TS: 1 RS: 0 - Rest Channel 2 - Initial Block
 DMR PDU Payload [BE][10][A2][00][00][80][B0][00][01][01][80][A1]

09:21:53 Sync: +DMR  [slot1]  slot2  | Color Code=01 | CSBK
 Preamble CSBK - Individual Data - Source: 119 - Target: 1 - Rest Channel: 2 -RAS 4 
 DMR PDU Payload [BD][10][80][02][00][00][01][02][00][77][17][3C]

09:21:53 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Capacity Plus Channel Status - FL: 1 TS: 1 RS: 0 - Rest Channel 2 - Final Block
 F80 Private or Data Call -  LSN 01: TGT 1; LSN 03: TGT 472; LSN 04: TGT 1;
  LSN 01:     1;  LSN 02:  Rest;  LSN 03:   472;  LSN 04:     1;  
  LSN 05:  Idle;  LSN 06:  Idle;  LSN 07:  Idle;  LSN 08:  Idle;  
 CAP+ Multi Block PDU 
  [BE][10][A2][00][00][80][B0][00][01][01][D8][00][01][00][00][00][00]
 DMR PDU Payload [BE][10][62][D8][00][01][00][00][00][00][03][73]

 SLCO Capacity Plus Site: 1 - Rest Channel 1 - RS: 00
 SLCO Completed Block [F1][00][10][85][D0]

09:21:53 Sync: +DMR  [slot1]  slot2  | Color Code=01 | DATA 
 Slot 1 Data Header - Indiv - Unconfirmed Delivery - Source: 119 Target: 1 
  SAP 09 [Prop PDU] - FMF 1 - BLOCKS 04 - PAD 09 - FSN 0 -RAS 4 
 DMR PDU Payload [02][91][00][00][01][00][00][77][84][00][EB][27]

09:21:53 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Capacity Plus Channel Status - FL: 2 TS: 1 RS: 0 - Rest Channel 2 - Initial Block
 DMR PDU Payload [BE][10][A2][00][00][80][B0][00][01][01][80][A1]

09:21:53 Sync: +DMR  [slot1]  slot2  | Color Code=01 | DATA 
 Slot 1 Data Header - Proprietary Packet Data - P_SAP 04 [IP Based] - MFID 10 [Motorola] -RAS 4 
 DMR PDU Payload [4F][10][11][01][00][00][74][74][88][C8][F4][2B]

09:21:53 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Capacity Plus Channel Status - FL: 1 TS: 1 RS: 0 - Rest Channel 2 - Final Block
 F80 Private or Data Call -  LSN 01: TGT 1; LSN 03: TGT 472; LSN 04: TGT 1;
  LSN 01:     1;  LSN 02:  Rest;  LSN 03:   472;  LSN 04:     1;  
  LSN 05:  Idle;  LSN 06:  Idle;  LSN 07:  Idle;  LSN 08:  Idle;  
 CAP+ Multi Block PDU 
  [BE][10][A2][00][00][80][B0][00][01][01][D8][00][01][00][00][00][00]
 DMR PDU Payload [BE][10][62][D8][00][01][00][00][00][00][03][73]

 SLCO Capacity Plus Site: 1 - Rest Channel 2 - RS: 00
 SLCO Completed Block [F1][00][20][86][20]

09:21:53 Sync: +DMR  [slot1]  slot2  | Color Code=01 | R12U 
 DMR PDU Payload [2C][49][6F][13][D6][01][C1][56][CE][BF][7B][BA]

09:21:53 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Capacity Plus Channel Status - FL: 2 TS: 1 RS: 0 - Rest Channel 2 - Initial Block
 DMR PDU Payload [BE][10][A2][00][00][80][90][00][01][00][A7][CE]

09:21:53 Sync: +DMR  [slot1]  slot2  | Color Code=01 | R12U 
 DMR PDU Payload [5C][53][6D][C9][76][3D][FF][53][F5][AC][C9][40]

09:21:53 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Capacity Plus Channel Status - FL: 1 TS: 1 RS: 0 - Rest Channel 2 - Final Block
 F80 Private or Data Call -  LSN 01: TGT 1; LSN 04: TGT 1;
  LSN 01:     1;  LSN 02:  Rest;  LSN 03:  Idle;  LSN 04:     1;  
  LSN 05:  Idle;  LSN 06:  Idle;  LSN 07:  Idle;  LSN 08:  Idle;  
 CAP+ Multi Block PDU 
  [BE][10][A2][00][00][80][90][00][01][00][01][00][00][00][00][00][00]
 DMR PDU Payload [BE][10][62][01][00][00][00][00][00][00][C3][80]

 SLCO Capacity Plus Site: 1 - Rest Channel 2 - RS: 00
 SLCO Completed Block [F1][00][20][86][20]

09:21:53 Sync: +DMR  [slot1]  slot2  | Color Code=01 | R12U 
 Slot 1 - Multi Block PDU Message
  [2C][49][6F][13][D6][01][C1][56][CE][BF][7B][BA]
  [5C][53][6D][C9][76][3D][FF][53][F5][AC][C9][40]
  [77][5A][FC][11][46][4C][ED][00][C1][6F][67][93]
   
 DMR PDU Payload [77][5A][FC][11][46][4C][ED][00][C1][6F][67][93]

09:21:53 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
 Capacity Plus Channel Status - FL: 3 TS: 1 RS: 0 - Rest Channel 2 - Single Block
 F80 Private or Data Call -  LSN 01: TGT 1;
  LSN 01:     1;  LSN 02:  Rest;  LSN 03:  Idle;  LSN 04:  Idle;  
  LSN 05:  Idle;  LSN 06:  Idle;  LSN 07:  Idle;  LSN 08:  Idle;  
 DMR PDU Payload [BE][10][E2][00][00][80][80][00][01][00][4A][B9]

 

[thewraith2008]

Hi Denny,

Are you saying that when the option bits are 0x90, you think this is indicating DATA revert channel usage?
If I remember right, DATA revert channels are on a separate BS (frequency) to the voice channels BS.
So when it's indicating logical CH 1 or 2, this is different to the logical CH 1 or 2 that the voice would be appearing on?

 

[DSheirer]

It seems like you'd need to set at least one bit in the first optional byte following the mandatory talkgroup activity bytes for lsn 1-8 and lsn 9-16. The remaining bits in that first optional byte can be used to send other features, like the example I posted with the 4th bit being set.

I suspect that these added channels are the data revert channels. The data revert LSN numbering may overlap with the voice LSN numbering, or it may be sequential. I guess a peek at the CPS software and how it presents the data revert channel numbers might give a clue.

But, that leaves the private voice call example that was reflected in this additive LSN chunk ... ?

So far Ive only found 2x systems in my recording samples that are sending this optional channel activity block. One system has 2x data revert repeaters, reflected in the channel bitmap as LSN 1&2 and 3&4. Over many recordings, these channels only send ARS and LRRP, leading me to believe they are data revert channels.

I have another local system that uses 'enhanced' data revert channels with windowing, but I dont recall seeing csbko 62 on that system. It may be con+.

Denny

 

[DSheirer]

Duplicate

 

[Forts]

If you want an encrypted private voice call sample, just let me know....

 

[lwvmobile]

But, that leaves the private voice call example that was reflected in this additive LSN chunk ... ?

So far Ive only found 2x systems in my recording samples that are sending this optional channel activity block. One system has 2x data revert repeaters, reflected in the channel bitmap as LSN 1&2 and 3&4. Over many recordings, these channels only send ARS and LRRP, leading me to believe they are data revert channels.

Was that data header that was sent for individual data, or group data. Your sample didn't seem to indicate in the data header which one it was. My observations to date have shown only individual data on a cap+ system, unless it was there and I missed it.

This is just my personal guess at this point, but I believe the information found after the 0x80 (or 0x90) flag is just to represent any sort of 'private' call, voice or data, anything that requires 16-bit individual target address. From a radio point of view, it doesn't need to know whether or not its a voice or data call first, it just knows that its supposed to be there. (I may be wrong in the assumption about the radio part, I am not very knowledgeable about their operations)

Is there a way for the release versions of SDRTrunk to capture signal in a format for you to read it back easily? I haven't used SDRTrunk in quite a while (not a knock, it worked fantastically for me on P25 in the past) Can you capture the 'bits' format you use in the release version? If so, perhaps Forts and a few others (myself) can submit some samples for you to work over.

 

[lwvmobile]

Here is another one I thought I'd share, 4 items in the appended private/data call bitmap.

06:38:49 Sync: +DMR  [slot1]  slot2  | Color Code=04 | CSBK
 Capacity Plus Channel Status - FL: 2 TS: 0 RS: 0 - Rest Channel 2 - Initial Block
 DMR PDU Payload [BE][10][82][00][00][80][87][03][E7][02][55][2A]
 
06:38:49 Sync: +DMR   slot1  [SLOT2] | Color Code=04 | VC4

06:38:49 Sync: +DMR  [slot1]  slot2  | Color Code=04 | CSBK
 Capacity Plus Channel Status - FL: 1 TS: 0 RS: 0 - Rest Channel 2 - Final Block
 F80 Private or Data Call -  LSN 01: TGT 999; LSN 06: TGT 647; LSN 07: TGT 507; LSN 08: TGT 655;
  LSN 01:   999;  LSN 02:  Rest;  LSN 03:  Idle;  LSN 04:  Idle;
  LSN 05:  Idle;  LSN 06:   647;  LSN 07:   507;  LSN 08:   655;
 CAP+ Multi Block PDU
  [BE][10][82][00][00][80][87][03][E7][02][87][01][FB][02][8F][00][00]
 DMR PDU Payload [BE][10][42][87][01][FB][02][8F][00][00][DE][3E]
 
06:38:49 Sync: +DMR   slot1  [SLOT2] | Color Code=04 | VC5

 SLCO Capacity Plus Site: 1 - Rest Channel 2 - RS: 00
 SLCO Completed Block [F1][00][20][86][20]
 
06:38:49 Sync: +DMR  [slot1]  slot2  | Color Code=04 | CSBK
 Capacity Plus Channel Status - FL: 2 TS: 0 RS: 0 - Rest Channel 2 - Initial Block
 DMR PDU Payload [BE][10][82][00][00][80][85][03][E7][02][B8][42]
 
06:38:49 Sync: +DMR   slot1  [SLOT2] | Color Code=04 | VC6
 SLOT 2 TGT=647 SRC=669 FLCO=0x23 FID=0x10 SVC=0x20 Cap+ Private TXI Call   (CRC ERR)
 DMR PDU Payload [23][10][20][00][02][87][00][02][9D]
  SB: 01100010011 - 313

06:38:49 Sync: +DMR  [slot1]  slot2  | Color Code=04 | CSBK
 Capacity Plus Channel Status - FL: 1 TS: 0 RS: 0 - Rest Channel 2 - Final Block
 F80 Private or Data Call -  LSN 01: TGT 999; LSN 06: TGT 647; LSN 08: TGT 655;
  LSN 01:   999;  LSN 02:  Rest;  LSN 03:  Idle;  LSN 04:  Idle;
  LSN 05:  Idle;  LSN 06:   647;  LSN 07:  Idle;  LSN 08:   655;
 CAP+ Multi Block PDU
  [BE][10][82][00][00][80][85][03][E7][02][87][02][8F][00][00][00][00]
 DMR PDU Payload [BE][10][42][87][02][8F][00][00][00][00][7E][5D]

 

[DSheirer]

Was that data header that was sent for individual data, or group data. Your sample didn't seem to indicate in the data header which one it was. My observations to date have shown only individual data on a cap+ system, unless it was there and I missed it.

I'm not sure. I don't expose the I/G flag for the Unconfirmed Data Header.

Is there a way for the release versions of SDRTrunk to capture signal in a format for you to read it back easily? I haven't used SDRTrunk in quite a while (not a knock, it worked fantastically for me on P25 in the past) Can you capture the 'bits' format you use in the release version? If so, perhaps Forts and a few others (myself) can submit some samples for you to work over.

sdrtrunk has a demodulated bit stream (*.bits) record option for control and traffic channels.

It also includes a DMR recording viewer tool (menu: View > DMR Recording Viewer) for the bitstream recordings.

Denny

 

[DSheirer]

If you want an encrypted private voice call sample, just let me know....

All of the CSBKO 62 site status examples that I've seen so far have either Talkgroup acitvity or Private/Data activity, but not both at the same time.

@Forts are you able to record your system with both a talkgroup call and a private call at the same time, to see how/if both of those call types are reflected in the CSBKO 62 messages?

 

[lwvmobile]

All of the CSBKO 62 site status examples that I've seen so far have either Talkgroup acitvity or Private/Data activity, but not both at the same time.

Here are some samples I got off of a remote using the latest build from Github. The signal is a bit iffy on this system right now, but there should be a good mixture of data and group calls, and they often happen at the same time. Should hopefully help you some with seeing how group voice and data calls get mixed together into the CSBK.

Upload files for free - SDRTRUNK-CASINO-II.zip - ufile.io

Download SDRTRUNK-CASINO-II.zip for free from ufile.io instantly, no signup required and no popup ads

ufile.io

 

[DSheirer]

@lwvmobile Thank you. I made it part way through the samples this morning and have several changes to make in my code now.

It seems that the 1-16 talkgroup chunk and the 1-16 radio/data/private chunk all refer to the same set of 16 LSNs.

I hadn't yet seen where the radio/data/private chunk was sending more than 8x LSNs, but this example shows that it is sending 16 channels:

BE10A420170080800070D4BD CC:1 CSBK CAP+ SITE STATUS REST LSN:4 [F-] VOICE LSN 1:* 2:* 3:23 4:* 5:* 6:* 7:* 8:* 9-16:* DATA LSN 1:112 2:* 3:* 4:* 5:* 6:* 7:* 8:*
BE106400000000000000FB2A CC:1 CSBK CAP+ SITE STATUS REST LSN:4 [-L] CONTINUATION BLOCK

The second or continuation block is sending all zeros and appears to be empty, so why would they send it? It seems that what they're sending in the continuation block is a single byte representing the active state of LSN 9-16 for radios, since they filled up the available space in the first message. In this example, there is no 16-bit radio activity on LSN 9-16, so the bitmap is all zeros.

It seems as though they always send the LSN 1-16 activity bitmap and talkgroup (8-bit) values and optionally send the LSN 1-16 activity bitmaps and radio (16-bit) values when there is data or private radio activity.

I think I'm going to stitch the two arrays together and then append a T or R to indicate talkgroup or radio to the identifiers.

Denny

 

[thewraith2008]

The second or continuation block is sending all zeros and appears to be empty, so why would they send it? It seems that what they're sending in the continuation block is a single byte representing the active state of LSN 9-16 for radios, since they filled up the available space in the first message. In this example, there is no 16-bit radio activity on LSN 9-16, so the bitmap is all zeros.

Yes both 'bitmaps' for 1-8 and 9-16 are sent at same time when indicating group or private/individual[when flagged to exist] active logical channels.
The 2nd byte (the one after the FL,TS,R,REST bits) of the final block is the 9-16 'bitmap' which as you stated, has no activity so is 0x00 with nothing following.

 

[lwvmobile]

It seems that the 1-16 talkgroup chunk and the 1-16 radio/data/private chunk all refer to the same set of 16 LSNs.

That's the conclusion I came to as well a while back. I do wonder though if it is a configurable behavior though, that while in this system instance that is the case, perhaps in others they are separate channels/LSN values.

The second or continuation block is sending all zeros and appears to be empty, so why would they send it?

I observed the same behavior on this system as well, and wondered the same. My theory is that there is one significant byte value in that appended block, but that its just 0x00. Not entirely sure. Could also just be an error on the repeater that does that. Always seems to happen on combinations of one group voice, and one private call. Any more, and those bits are fleshed out.

It seems as though they always send the LSN 1-16 activity bitmap and talkgroup (8-bit) values and optionally send the LSN 1-16 activity bitmaps and radio (16-bit) values when there is data or private radio activity.

Yep, only see that 'flag' when private activity occurs, when no data/private calls, no flag.

I think I'm going to stitch the two arrays together and then append a T or R to indicate talkgroup or radio to the identifiers.

That's what I ended up having to do. Complete pain accounting for the position in the bitstream when stitching them together like that.

I made it part way through the samples this morning and have several changes to make in my code now.

If I had a nickel for every time I've had to do the same.

 

[Forts]

All of the CSBKO 62 site status examples that I've seen so far have either Talkgroup acitvity or Private/Data activity, but not both at the same time.

@Forts are you able to record your system with both a talkgroup call and a private call at the same time, to see how/if both of those call types are reflected in the CSBKO 62 messages?

I can certainly give it a try... Unfortunately I don't have my cable with me today (our radios aren't setup for private call by default) but I can give it a go early next week.

 

[DSheirer]

I can certainly give it a try... Unfortunately I don't have my cable with me today (our radios aren't setup for private call by default) but I can give it a go early next week.

@Forts please disregard ... the samples that @lwvmobile sent provide the answer I needed. Thank you!

 

[lwvmobile]

I was going to ask the same question about this at some point myself but just haven't had the time of late to experiment with things.

I have observed this for quite sometime myself and not just CAP+ but also with some of Motorola's non TIII systems as well.
You see the voice superframe payload for frame 'F' return 'RRR' (repeat) for the 3 voice frames it is supposed to contain.
And/Or you see the voice superframe frame 'F' EMB signalling/RC single fragment return a failed CRC7.

I guessed this maybe a hidden CSBK PDU but I have never tried to decode as such yet.
I also thought this was connected to the ALGO_ID/MI PDU for higher encryption types, but none of the ones I have observed where this is seen use encryption.

This ALGO_ID/MI PDU is also some info I need to look into sometime as well.
I'm sure I saw this was contained in a superframe as well.

I think I might have found some information regarding this. This entire thing seems to be documented in Motorola's patent for "Method for interrupting voice transmissions within a multi site communication system", which I'm pretty sure refers to TXI. The patent found here describes the single burst embedded link control as well as an opcode, 3-bit crc, and information field for the 11-bit PDU, as well as vaguely describing what happens or may happen in the dropped voice burst, but doesn't really say much about how to de-interleave or decode it (BPTC, other encoding?), but looking at the raw payload collected on all three AMBE frames that would occur there shows that the payloads in those locations are the same bits of data broadcast in triplicate, which may or may not be erroneous IF the BS transmits absolutely nothing there but dead air and the demodulator just fills in dibits but still, seems unlikely for it to produce three sets of the exact same bits in AMBE fields 1,2,3 (prior to decoding) and also have a seemingly valid single burst.








All this found, I'm still struggling to find a consistent setup for finding the single burst embedded key/alg id and NOT some other signalling (TXI, or otherwise) I also believe that Cap+ may also signal things in this field (Site ID). I think one thing I did figure out (but couldn't always reproduce) is that if the embedded link control shows a SVC OPT of 0x70, the very next superframes VC6 will be pre-empted for the backwards channel/reverse channel opportunity. Also, still working out how, or which poly a CRC3 might be on this information, and if I should read the bits in the forward or reverse direction.