Understanding Capacity Plus trunking, some more

[jake_Braker]

And i don't think that dedicated data channels have LCNs.

If that's the case, that's awesome to know! It's weird that the LCNs don't begin with 1, they start with 7 so that's why I figured there were 6 LCNs for just data

 

[hrh17]

I've come across several capacity plus systems which for some reason have dropped LCN 1&2

 

[mtindor]

Keep in mind that some systems (sometimes or all the time) have certain repeaters turned off. For instance, I might monitor a particular site one month and it has six active freqs (six active LCNs). The next month I might monitor it and the control channel has changed to LCN 2 or some other LCN 3 or something, and LCN 1 is totally off. Remember, these are repeaters operating together as a trunked system. At any time one of teh repeaters might fail. Or they might turn off some repeaters on a particular site if the loading of the site isn't high enough to justify having all of the repeaters turned on.

Also keep in mind that the system maintainers can set the LCNs to _any_ number (within the allowed specs) that they want. There does NOT have to be any rhyme or reason to it. For all of the people out there who have made UHF LCN calculators based upon standard UHF bandplan, there is nothing that says that the system maintainer has to ever use a specific bandplan. One of the local shops here who runs a wide area TIII and a wide area CON+ system do NOT adhere to the standard UHF bandplan on their systems. They configure the LCNs for each freq to be whatever they want.

So you can never county on LCNs on Cap+/Con+ being LCNs 1 through whatever in a particular order. And you can never be absolutely sure that LCNs on a TIII system are going to be ones that one of the UHF LCN calculators spit out using a standard UHF bandplan.

 

[Red_Ice]

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.

Hello thewraith2008, sorry for my question, I would be interested to know how this information that you indicate in the thread is obtained since the FLCO values do not match what I thought, it is possible that I am wrong, the information on which I based the I took from table 5.4 of ETSI TS 102 361-2 V2.3.1 (2016-02)

 

[jake_Braker]

So, like I said, I have at least one confirmed data frequency for this system, I more than likely won't need to program that into a scanner or DSD+ in order for those to run correctly?

 

[thewraith2008]

Hello thewraith2008, sorry for my question, I would be interested to know how this information that you indicate in the thread is obtained since the FLCO values do not match what I thought, it is possible that I am wrong, the information on which I based the I took from table 5.4 of ETSI TS 102 361-2 V2.3.1 (2016-02)

Your image only references standard FLCOs when the FID=0.

The DMR standards for SLCO/CSBKO/FLCO are a base line and allow manufacturers the ability to tailor them for there needs. (by using the FID)
Sometimes these have the same structure as the standard ones, other times they are not and need to be determined through testing. This is the point of this thread to understand CAP+ low level structure and operation.

 

[Red_Ice]

Entonces, como dije, tengo al menos una frecuencia de datos confirmada para este sistema, lo más probable es que no necesite programar eso en un escáner o DSD + para que funcionen correctamente.
[/COTIZAR]

Gracias jake_braker por tu respuesta. ¿Hay algún documento del tipo Systen Planner en el que aparezcan estos datos y poder verlos así en los diferentes fabricantes?

 

[lwvmobile]

@Forts Okay, so, going over a few of your samples, its definitely raised some questions from me now that I can observe some behavior that I haven't seen in any other Cap+ system yet. How many channels does your Cap+ system have, and is it configured only for private calls, or do both private and group calls occur on it?

The reason I ask, when your radio keys up, and you speak, there is no bits set to indicate which cap+ channel (or lcn) is active, but in the same CSBK, I can see a few bytes down a 16-bit target radio id that matches the one from the voice link control header.

16:03:43 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]

16:03:43 Sync: +DMR   slot1  [slot2] | Color Code=03 | CSBK
Capacity Plus Channel Status - FL: 3 TS: 1 RS: 0 - Rest Channel 4
  Ch1: Idle Ch2: Idle Ch3: Idle Ch4: Rest
  Ch5: Idle Ch6: Idle Ch7: Idle Ch8: Idle
DMR PDU Payload [BE][10][E4][00][00][80][20][52][09][00][99][03]

The bytes [52][09] = SRC 21001; I should also note that this is a 16-bit value as opposed to the usual 8-bit group values
But, in the entire payload [BE][10][E4][00][00][80][20][52][09][00][99][03] The byte right after [E4] should have one bit on to signify which Cap+ Channel this call is occurring on, but its just [00]. I'm definitely not seeing any other CSBK present nor any other FL on the CSBK to indicate there is another portion to look at.

Here is another scrape I made when the rest channel was different but still had the private call going

08:52:07 Sync: +DMR  [slot1]  slot2  | Color Code=03 | CSBK
Capacity Plus Channel Status - FL: 3 TS: 0 RS: 0 - 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][80][10][52][09][00][09][9A]

I wonder if the byte [80] and the next byte [20] in the first, and [10] in the second is an indicator for the Cap+ channel this private call is occurring on. The next two bytes after it would be the [52][09] = 21001.

I wonder if its a Private Call vs Private TXI call kind of thing, or if it one of those things thats configured on a system by system basis and there is no over the air indication of how it should be read.

@thewraith2008 any thoughts?

 

[thewraith2008]

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.

When you provided your sample, this proved this was the case.

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.

 

[lwvmobile]

When you provided your sample, this proved this was the case.

Or so I thought at the time. I was only looking at either FL1, or FL2 when I made that determination, and I found that (by your recommendation) if you append FL1's relevant data bits to FL2s data bits, you can get the entire picture. Likewise FL3 is just a 'single' contained block, but I speculate that it could also be a third appended block if needed. Having two (or three) blocks worth of data would give enough room to store 16 bit radio target ids.

Looking at new samples and going back to the other foreign speaker sample 'dmr_dwa_sloty.wav' and the samples provided by forts, I've found that the same CSBK is used, but the structure is slightly different. I didn't quite have it all put together in my last message, but I think I've figured it out, at least, figured it out more than I had the first time.

I've worked the code a little bit, and came up with this:

23:17:22 Sync: +DMR [slot1] slot2 | Color Code=04 | CSBK
Capacity Plus Channel Status - FL: 2 TS: 0 RS: 0 - Rest Channel 3 - Initial Block
DMR PDU Payload [BE][10][83][00][00][80][45][00][01][02][AF][71]
23:17:22 Sync: +DMR slot1 [SLOT2] | Color Code=04 | VC6
SLOT 2 TGT=647 SRC=669 FLCO=0x23 FID=0x10 SVC=0x20 Cap+ Private TXI Call (FEC OK) (CRC ERR)
DMR PDU Payload [23][10][20][00][02][87][00][02][9D]
23:17:22 Sync: +DMR [slot1] slot2 | Color Code=04 | CSBK
Private: CH:2 TGT=1; CH:6 TGT=647; CH:8 TGT=655; <== these values are found in the CSBK, but not where you expect;
Capacity Plus Channel Status - FL: 1 TS: 0 RS: 0 - Rest Channel 3 - Appended Block
Ch1: Idle Ch2: Priv Ch3: Rest Ch4: Idle
Ch5: Idle Ch6: Priv Ch7: Idle Ch8: Priv
CAP+ PDU Payload [BE][10][83][00][00][80][45][00][01][02][87][02][8F][00][00][00][00]
DMR PDU Payload [BE][10][43][87][02][8F][00][00][00][00][39][8E]

Likewise, on Forts samples, linked here and around that vicinity, I can pull the same values out:

00:14:51 Sync: +DMR slot1 [slot2] | Color Code=03 | VLC
SLOT 2 TGT=21001 SRC=21002 FLCO=0x07 FID=0x10 SVC=0x00 Cap+ Private Call Cap+ R-Ch 3
DMR PDU Payload [07][10][00][00][52][09][03][52][0A][ED][FD][71]
00:14:51 Sync: +DMR [slot1] slot2 | Color Code=03 | CSBK
Private: CH:4 TGT=21001;
Capacity Plus Channel Status - FL: 3 TS: 0 RS: 0 - Rest Channel 3 - Single Block
Ch1: Idle Ch2: Idle Ch3: Rest Ch4: Priv
Ch5: Idle Ch6: Idle Ch7: Idle Ch8: Idle
CAP+ PDU Payload [BE][10][C3][00][00][80][10][52][09][00][00][00][00][00][00][00][00]
DMR PDU Payload [BE][10][C3][00][00][80][10][52][09][00][09][9A]

In both cases, if you observe the CAP+ PDU Payload, you'll see an 0x80 value, then the next byte seems to contain the bits relevant to active private channels. Then, after that, you can take the two bytes for each active private call and that gives me the same target radio id that is found in the voice link control header and embedded voice link control. The bits you would normally look for for an active talkgroup channel are all zeroes during this signalling. I suspect the 0x80 has some significance, maybe if nothing else, just to signal to look here, this PDU contains private call data. The other though I've had is that I may possibly be putting the appended block relevant data bytes together in the wrong order, but I'm just trying to make it make sense.

 

[thewraith2008]

The CAP+_CH_Status (CSBKO:62) always indicates 16 channel usage regardless of number of blocks (max 3) that makes it up and whether 16 channels are ever used in network. The 8 bit TG (allocation) is fixed for each set channel flag and there is not flag that indicates that 16 bits should be used for the channel that is active.

When you think about it, there is no need to further announce the call (i.e. for late entry purposes) as the two parties are either present or there are not. You see the same in TIII private call where setup/grant PDUs are only sent once if both parties are ready for call. You would see a NACK of some sort if one party is not available.

I will download forts samples and have a look at the way private calls are setup.
I generally find it easier to dump PDUs in binary as most elements in a PDU are not byte align.

 

[thewraith2008]

What am I missing with those two samples from forts?

I sort of get decoding but ends up throwing about a million (OK I lied, about a hundred) errors at the voice parts I'm guessing.
I fired up DSD+ and it does the same thing so that's a relief.

The PDUs it showing for me over the two samples are:

• CSBKO: 62
• FLCO: 0, 3, 4 , 7

I'm not seeing the FLCO: 0x23 (35) that you saw but your log does indicate the PDU was 'CRC ERR' so I'd put that down to a bad decode until we see one that does not have an EDC/FEC error.

 

[thewraith2008]

@lwvmobile

Had some time to look at this some more and it looks like your right about the appended private call flags and RID allocation in the CAP+_CH_Status PDU. It didn't even occur to me that another set of flags could be defined.

If my interpretation is correct, then the following example should be how a CAP+_CH_Status PDU would be laid out.

In this example:

• No Group calls active in 1-8 (as indicated by 1st CH flag bank)
• No Group calls active in 9-16 (as indicated by 2nd CH flag bank)
• Next 8 bits (appended feature flags? after above is used to indicate that private CH/RID activity is to follow
• Private calls active in 1-8 (as indicated by 3rd CH flag bank)
• Private calls active in 9-16 (as indicated by 4th CH flag bank)
• This example would be the maximum blocks(6) used to create the CAP+_CH_Status PDU. (assuming nothing else can be appended after it)

The allocation when a group call for TGs is 8 bits.
The allocation when a private call for RIDs is 16 bits.

Below shows the 7 x 8 bits (56) available from each block of the CAP+_CH_Status PDUs

[00000000] FLAGS_1-8_GRP          (FL:2 - First block)
[00000000] FLAGS_9-16_GRP
[10000000] FLAGS_appended features - MSB indicates private call flags/lcn/RID to follow (RIDs are 16 bit)
[11111111] FLAGS_1-8_PRIV
[xxxxxxxx] LCN_1_RID
[xxxxxxxx] ^^^
[xxxxxxxx] LCN_2_RID

[xxxxxxxx] ^^^                    (FL:0 - Continuation block)
[xxxxxxxx] LCN_3_RID
[xxxxxxxx] ^^^
[xxxxxxxx] LCN_4_RID
[xxxxxxxx] ^^^
[xxxxxxxx] LCN_5_RID
[xxxxxxxx] ^^^

[xxxxxxxx] LCN_6_RID              (FL:0 - Continuation block)
[xxxxxxxx] ^^^
[xxxxxxxx] LCN_7_RID
[xxxxxxxx] ^^^
[xxxxxxxx] LCN_8_RID
[xxxxxxxx] ^^^
[11111111] FLAGS_9-16_PRIV

[xxxxxxxx] LCN_9_RID              (FL:0 - Continuation block)
[xxxxxxxx] ^^^
[xxxxxxxx] LCN_10_RID
[xxxxxxxx] ^^^
[xxxxxxxx] LCN_11_RID
[xxxxxxxx] ^^^
[xxxxxxxx] LCN_12_RID

[xxxxxxxx] ^^^                    (FL:0 - Continuation block)
[xxxxxxxx] LCN_13_RID
[xxxxxxxx] ^^^
[xxxxxxxx] LCN_14_RID
[xxxxxxxx] ^^^
[xxxxxxxx] LCN_15_RID
[xxxxxxxx] ^^^

[xxxxxxxx] LCN_16_RID             (FL:1 - Final)
[xxxxxxxx] ^^^
[00000000] N/A
[00000000] N/A
[00000000] N/A
[00000000] N/A
[00000000] N/A

In your sample 'dmr_dwa_sloty.wav', we see some rapid activity changes but this seems to be how sample is recorded and it seems to be following call activity as it records cause things to jump around a bit.

 

[lwvmobile]

I've had a little bit more time to continue to piece things together, and have discovered that DATA calls are also announced in the same CSBK via the same layout as what we call 'Private Calls'. I haven't figured out a way to tell them apart, but the Preamble CSBK shows its Individual Data, so perhaps CAP+_CH_Status PDU doesn't make a distinction between a private data call and a private voice call, since the unit will need to listen to it regardless.

00:17:03 Sync: +DMR  [slot1]  slot2  | Color Code=01 | CSBK <--target is 1
 Preamble CSBK - Individual Data - Target [1] - Source [131725]  (FEC OK) -RAS 4  (CRC ERR)
 DMR PDU Payload [BD][10][80][02][00][00][01][02][02][8D][F0][92]
 SLCO Capacity Plus Site: 1 - Rest Channel 1 - RS: 08
 SLCO Completed Block [F1][00][10][85][D0]
00:17:03 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 Ch1: TGT 1;
  Ch1: P||D Ch2: Rest Ch3: Idle Ch4: Idle
  Ch5: Idle Ch6: Idle Ch7: Idle Ch8: Idle
 DMR PDU Payload [BE][10][E2][00][00][80][80][00][01][00][4A][B9]
00:17:03 Sync: +DMR  [slot1]  slot2  | Color Code=01 | DATA
  Unconfirmed Data Header: DPF 2 - SAP 09 - Block Count 04 - Padding Octets 01 
  Proprietary Packet Data - Source: [653] Destination: [1] <==target of the packet data
  Proprietary Packet Data Incoming   (FEC OK) -RAS 4  (CRC ERR)
 DMR PDU Payload [02][91][00][00][01][00][02][8D][84][00][68][B4]
00:17:03 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 Ch1: TGT 1; <--target 1
  Ch1: P||D Ch2: Rest Ch3: Idle Ch4: Idle
  Ch5: Idle Ch6: Idle Ch7: Idle Ch8: Idle
 DMR PDU Payload [BE][10][E2][00][00][80][80][00][01][00][4A][B9]  <---check bytes here
00:17:03 Sync: +DMR  [slot1]  slot2  | Color Code=01 | DATA 
  Proprietary Data Header: SAP 4 - Format F - MFID 10  (FEC OK) -RAS 4  (CRC ERR)
 DMR PDU Payload [4F][10][11][01][00][00][F0][74][CD][DC][31][C2]
 SLCO Capacity Plus Site: 1 - Rest Channel 2 - RS: 08
 SLCO Completed Block [F1][00][20][86][20]
00:17:03 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 Ch1: TGT 1;
  Ch1: P||D Ch2: Rest Ch3: Idle Ch4: Idle
  Ch5: Idle Ch6: Idle Ch7: Idle Ch8: Idle
 DMR PDU Payload [BE][10][E2][00][00][80][80][00][01][00][4A][B9]
00:17:03 Sync: +DMR  [slot1]  slot2  | Color Code=01 | R12U
 DMR PDU Payload [41][1D][DB][4B][77][B3][D4][D4][15][73][D8][A3]
00:17:03 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 Ch1: TGT 1;
  Ch1: P||D Ch2: Rest Ch3: Idle Ch4: Idle
  Ch5: Idle Ch6: Idle Ch7: Idle Ch8: Idle
 DMR PDU Payload [BE][10][E2][00][00][80][80][00][01][00][4A][B9]
00:17:03 Sync: +DMR  [slot1]  slot2  | Color Code=01 | R12U
 DMR PDU Payload [DF][26][DB][BE][F8][1A][36][8E][42][4F][78][72]
 SLCO Capacity Plus Site: 1 - Rest Channel 2 - RS: 08
 SLCO Completed Block [F1][00][20][86][20]
00:17:03 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 Ch1: TGT 1;
  Ch1: P||D Ch2: Rest Ch3: Idle Ch4: Idle
  Ch5: Idle Ch6: Idle Ch7: Idle Ch8: Idle
 DMR PDU Payload [BE][10][E2][00][00][80][80][00][01][00][4A][B9]
00:17:03 Sync: +DMR  [slot1]  slot2  | Color Code=01 | R12U
 Slot 1 - Multi Block PDU Message CRC32 ERR
 Slot 1 - Multi Block PDU Message
  [4F][10][11][01][00][00][F0][74][CD][DC][31][C2]
  [41][1D][DB][4B][77][B3][D4][D4][15][73][D8][A3]
  [DF][26][DB][BE][F8][1A][36][8E][42][4F][78][72]
  [B0][BE][81][49][2D][A1][17][00][C7][71][85][9D]
  
 DMR PDU Payload [B0][BE][81][49][2D][A1][17][00][C7][71][85][9D]
00:17:03 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 Ch1: TGT 1;
  Ch1: P||D Ch2: Rest Ch3: Idle Ch4: Idle
  Ch5: Idle Ch6: Idle Ch7: Idle Ch8: Idle
 DMR PDU Payload [BE][10][E2][00][00][80][80][00][01][00][4A][B9]
00:17:03 Sync: +DMR  [slot1]  slot2  | Color Code=01 | CSBK
 Capacity Plus Channel Status - FL: 3 TS: 0 RS: 0 - Rest Channel 2 - Single Block
  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] <--no more data call

And I've also discovered that private call/data signalling can occur at the same time as group calls in the same PDU.

00:28:12 Sync: +DMR  [slot1]  slot2  | Color Code=01 | CSBK
 Capacity Plus Channel Status - FL: 2 TS: 0 RS: 0 - Rest Channel 4 - Initial Block
 DMR PDU Payload [BE][10][84][40][01][00][80][20][00][DE][62][12]
 SLCO Capacity Plus Site: 1 - Rest Channel 3 - RS: 08
 SLCO Completed Block [F1][00][30][87][70]
00:28:12 Sync: +DMR   slot1  [SLOT2] | Color Code=01 | VC6
 SLOT 2 TGT=1 SRC=109 FLCO=0x20 FID=0x10 SVC=0x60 Group Encrypted TXI Call   (FEC OK) (CRC ERR)
 DMR PDU Payload [20][10][60][00][00][01][00][00][6D]
00:28:12 Sync: +DMR  [slot1]  slot2  | Color Code=01 | CSBK
 Capacity Plus Channel Status - FL: 1 TS: 0 RS: 0 - Rest Channel 4 - Appended Block
 F80 Private or Data Call Ch3: TGT 222;
  Ch1: Idle Ch2:  001 Ch3: P||D Ch4: Rest
  Ch5: Idle Ch6: Idle Ch7: Idle Ch8: Idle
 CAP+ Multi Block PDU [BE][10][84][40][01][00][80][20][00][DE][00][00][00][00][00][00][00]
 DMR PDU Payload [BE][10][44][00][00][00][00][00][00][00][80][42]

I pulled those out of this sample.

Upload files for free - audio_858606250Hz_13-09-07_10-01-2023.wav - ufile.io

Download audio_858606250Hz_13-09-07_10-01-2023.wav for free from ufile.io instantly, no signup required and no popup ads

ufile.io

 

[thewraith2008]

Thanks again for supplying a sample with some interesting stuff.

I've now made the required changes to handle the group/private/data announcements.
I now see the LCN activity for data quickly appearing when data goes across network.

I used to use the CAP+_CH_Status as a call setup/late entry/priority (in addition to FLCO:4/7) but I never liked it switching to an LCN and nothing been there half the time because of short burst calls. I can see if you do this you are going to get the data announcements triggering a call following procedure without a way to distinguish between private and data calls. I wonder if there are group data 'calls' this would have the same problem. For now, only using FLCO:4/7 to setup a call is the way around this. Pity the appended flags doesn't help here.

 

[lwvmobile]

I can see if you do this you are going to get the data announcements triggering a call following procedure without a way to distinguish between private and data calls. I wonder if there are group data 'calls' this would have the same problem. For now, only using FLCO:4/7 to setup a call is the way around this. Pity the appended flags doesn't help here.

Yeah, I've been wondering if just simply following the rest channel instead of trying to actively tune to the channels is a better approach, or would even be noticeable. Luckily, I had already made a few user options to tune calls based on group, private, or data for TIII trunking, so I just use that to turn off tuning to private or data calls if desired. I can even turn off all three and cap+ will just follow the rest channel. If I didn't know any better, just from listening casually, I wouldn't even know I was missing anything. The only benefit I can see in using them to tune would be perhaps the off chance you can get to a call a little faster, or if you set up a call tg priority so you immediately go to a higher priority tg.

Messing around with this one CSBK long enough has definitely given me so much more appreciation of the DMR ETSI manuals, even if they are all over the place in trying to read the contents of a PDU and having to sort through tons of other pages trying to figure out how to interpret one particular aspect of a PDU.

BTW, do you have any Cap+ samples with more than 8 LCNs, or tons of activity requiring more than 2 blocks to convey it?

 

[thewraith2008]

This is it flashing away.

 

[lwvmobile]

This is it flashing away.

Yeah, that'll produce some eyestrain in the long run.

 

[thewraith2008]

I thought I had a sample with 10 or more active LCNs but I haven't been able to locate it again.
I need a way of indexing these samples.

I think it was from a stadium of something like that, high traffic and very short call bursts. It had 14 LCN from memory.

 

[thewraith2008]

Yes not the best. Lucky group calls persists longer.
Color was only added to see if activity was group or private rather than looking for TG or RID on screen.

The DMR ETSI standards are poorly laid out. TETRA was ETSI as well but seemed easier to read.
I sometimes have two of the same PDF open so I don't have to keep flipping back and forth.
It almost appears to contradict itself in places about some items. (i.e DATA)