DSP structured output

[smarek]

Hi, thank you for this project, could you please comment on my feature proposal below?

Goal: Run option for dsd-fme so it dumps Normal (Standard), RC and CACH bursts in timeslot+burst-bytes format

Basically i'd want to process the on-air data via different application/project, and currently only parsed output and symbols dump (symbols file) are available.
So lets say "dsd-fme --raw-bursts -i 1R.wav" would either on-stdout or into-file dumped each DMR burst that went into processing by dmr handler methods, eg. like this

# general form:
# timeslot(ascii 1 or 2) [single whitespace] burst-type(ascii 1-9) [single whitespace] burst-bytes-hex-encoded [EOL]
# example: timeslot(1) burst-type(1 normal traffic burst)  on-air-payload (33 bytes, incl. sync-or-embedded burst centre)
1 1 aabbccddeeff........
# example: timeslot(2) burst-type(2 RC burst) on-air-payload(12 bytes)
2 2 00112233445566....

Eventually burst-type field could be [2-chars-ascii] if the feature was gradually rolled-in for more radio networks

[lwvmobile]

I'll have to see what I can do in the future. It probably wouldn't be too difficult if the printing/payloads weren't already spread across a ton of files and so on, would it matter so much if it were direct console output, or would putting that output to a separate file be okay?

Also, while you are here, let me ask you a few questions.

1. When parsing LRRP tokens, what is the first token I should look for? I looked at the tokens you had in ok-dmrlib, but I don't know if I got the order of operations right. It works for some things, but others, just bad decodes triggered off of a random 'token' found in the completed message. I was going with 0x1F //ARRP_TriggeredInformationReport_NCDT, but had enabled some other ones, but the tokens seemed to hit or miss, so I had to disable a lot of them. I was thinking I am looking for the wrong token to start the whole thing.

2. Do you have any information on Connect Plus CSBKs? I have a couple, but other than the neighbor list, and voice grant, the other ones I put in there have been observed, but aren't what I thought they were. Any idea what CSBK FID 0x06 with Opcodes 0x6 and 0xC are for?

See You
Space
Cowboy...

[smarek]

I don't mind any way, stdout can be captured, filtered and passed to other tools, files can be tailed in similar manner, so i think you can choose whatever way is the easiest

(1) lrrp

LRRP (MBXML documents) are appended to each other, and Document Type ID is single-byte (first byte), see https://github.com/OK-DMR/ok-dmrlib/blob/master/okdmr/tests/dmrlib/motorola/test_lrrp.py#L36

Also the first few bytes have meaning, see: https://github.com/OK-DMR/ok-dmrlib/blob/806050b582e5f5c19f04fe11ddc77ec2cd608ce4/okdmr/dmrlib/motorola/mbxml.py#L933

[document type id (single byte)] [document length incl. document type id and self (**uintvar, not single byte int**)] [optionally Document-Specific Constant Data Table] [document body]

So you can check, if you have full pdu of allowed LRRP document (reading 2-4 bytes, checking doc-id and doc-len)

However LRRP protocol PDU can come within data transmission, which can have some padding at the beginning (udp vs extracting un/confirmed dmr packet data transmission)

also "tokens" are either global (mbxml global tokens) or protocol-specific (LRRP has specific tokens for request pdus and different for response pdus)

and at last, if you have any LRRP data where tokens are not-detected correctly, please send them to me, either PR or issue for LRRP support on ok-dmrlib, because I have little to no data for some of the documents i have specifications for.

(2) connect plus

i have no information, specification or testing devices for connect plus, other than what ADK Overview and System Planner EA documents mention, sorry

CSBK opcodes are here, but you already know probably, https://github.com/OK-DMR/ok-dmrlib/blob/master/okdmr/dmrlib/etsi/layer2/elements/csbk_opcodes.py#L10

if you mean MFID (Manufacturer Feature Set ID), see https://github.com/OK-DMR/ok-dmrlib/blob/master/okdmr/dmrlib/etsi/layer2/elements/feature_set_ids.py#L10

0x06 should be Trident Microsystems
CSBK opcode is 6-bit field (values 0-63 inclusive), CSBK Opcode 0xC (0b00_11_00) is not known to me, but given the value is in range 0b00_xx_xx i guess it will be channel or voice service (trunking opcodes start at 0b01_xx_xx or 0b11_xx_xx)

CSBK opcodes overlay (eg. TD_GRANT_MI and BS_Dwn_Act), so when detecting contents, you must take into account whether its MS or BS sourced
Check ETSI TS 102 361-4 V1.10.1 (2019-08) Annex B.1 CSBK/MBC/UDT Opcode List

---

"I'm not going there to die. I'm going to find out if I'm really alive"
-- Spike Spiegel

[smarek]

Also if you wanted to experiment, https://github.com/OK-DMR/dmr-kaitai *.ksy files could be translated into h/c/cpp form and you could use existing structures to parse incoming as whole, with kaitai struct runtime it should report when the PDU seems to be incomplete or help detect unknown fields

But yeah, I tried to orient myself in your codebase, but i was unable to deduce which pointer/heap to use, so i asked directly, since you sometimes work with data in form of unicode string (eg. DMR_BS_DATA_SYNC "313333111331131131331131") instead of extracting the bytes into unified object and handling the pdu with set length (or through intermediary struct), it becomes messy and fragile down the line (i mean managing the pointers). I could not make much sense out of it.

[lwvmobile]

I'll have to review all that you just said on LRRP when I have more time, energy, and focus to go through it all again. Same for the dmr-kaitai stuff as well.

i have no information, specification or testing devices for connect plus, other than what ADK Overview and System Planner EA documents mention, sorry

That's alright, it doesn't seem to be that there is any public information on it, other than what a few others have been able to figure out based on trial and error I presume, but I have a Connect Plus Voice Grant/Grant Update, so that's good enough for trunking.

But yeah, I tried to orient myself in your codebase, but i was unable to deduce which pointer/heap to use, so i asked directly, since you sometimes work with data in form of unicode string (eg. DMR_BS_DATA_SYNC "313333111331131131331131") instead of extracting the bytes into unified object and handling the pdu with set length (or through intermediary struct), it becomes messy and fragile down the line (i mean managing the pointers). I could not make much sense out of it.

Yeah, I agree, I'm not a big fan of the string stuff myself, but that code was in there from the original versions of dsd from dsd author, I have never changed it or attempted to do much with it. It works fine for what it does, with one exception, NXDN frame sync pattern. I have considered changing it a few times, but never wanted to get knee deep in fixing it and end up breaking a lot of other things.

I'll also be the first to admit, I am not a programmer. I wasn't trained or taught how to program, didn't go to school for it, I just jumped in and keep going. A lot of things I do are probably technically wrong for any number of reasons, so don't judge my code too harshly, I just go by results. If it works, it works. There is also multiple hands in the source code, so a lot of different writing styles and preferences all mixed together.

[smarek]

Easy there, not judging you for code style or abilities, but you orient better and i'm not fluent with c/c++, so if you think you can manage best with file output as you suggested, i'll be happy. You keep your community happy and alive, meaning there's nothing to look down on.

Let me know, if I can help you somehow

[smarek]

I see you've been working on other issues, is this one problematic? Do you need/want help? I can definitely try

[lwvmobile]

Sorry about that, just haven't had a chance to get started on it just yet.

[lwvmobile]

Goal: Run option for dsd-fme so it dumps Normal (Standard), RC and CACH bursts in timeslot+burst-bytes format
Eventually burst-type field could be [2-chars-ascii] if the feature was gradually rolled-in for more radio networks

I had a question about that, do you want the second number on the line to be a hex character representing the data burst type? If so, what value would you give to a voice burst type? Another question, do the CACH and RC bursts need to be seperate, or can you just decode that from the relevant bytes presented. Here is a working mock up I made, in the zip file, along with a log from dsd-fme for comparison. You did say 33 bytes, so I'm assuming you didn't want the CACH leading off each line, just going straight to the beginning of the payload. Also, I used the characters d for data burst, f for an initial voice burst sync, and v for continuing voice bursts.

spike.zip

[lwvmobile]

Ignore that, no CACH is 33-bytes. Counting in dibits vs bytes lead to confusion on my end.

[lwvmobile]

I found a few errors in my initial mock up in the code, I think there may have been a few bytes short, and also I restructured it slightly, now its setup such that the first character is the slot, the second two characters are hex values representing data brusts, and the value of 10 (hex 0x10, dec 16) is designated for voice (bs), let me know if this format will work for you. I can tweak it some still if needed. I'm not sure still though how you want both RC and CACH though, do you want the completed CACH after its all put together but before deinterleave, etc? (for Slow Link Control I presume) or should I just add the CACH bytes to the beginning of each line before the payload? Same for RC or Single Burst Embedded (VC F)? Can't you just scrape that from the appropriate location on the line?

spike2.zip

[smarek]

Well man, good work, looks nice already, but data are currently not valid, from what i can tell

TLDR

1. looks like first few bursts are not decoded properly, but we can keep them in the output, filtering can be done later
2. CACH is not first 3 bytes of TDMA burst (see Figure 6.6: CACH burst), but 3 bytes before the timeslot data starts, see screenshots, we need full 264 bits of TDMA burst
3. having RC and CACH is superior feature, if the detect/decode should be too complicated, V+D (voice and data) standard/generic bursts will be enough

longer

i will reference ETSI TS 361-1 V2.5.1 (2017-10) to you (PDF here: https://www.etsi.org/deliver/etsi_ts/102300_102399/10236101/02.05.01_60/ts_10236101v020501p.pdf )

1. to annotate I'd differentiate between these
   • standard (generic) burst (361-1 section 4.2.2, figure 4.3) - meaning voice and data, these can be distinguished by SYNC and contents
   • CACH burst (361-1 section 4.2.2, figure 4.4, 4.5) (361-1 section 6.3 figure 6.6) - only applies to BS sourced TDMA frame
   • RC burst (361-1 section 6.4.1 figure 6.7)
2. In case detecting CACH or RC is difficult, we can output only standard bursts
3. size of these bursts shall be
   • standard (per Figure 6.3: Voice burst with SYNC)
     • voice: 108+48+108=264 bits=33 bytes
     • data: 98+10+48+10+98=264 bits=33 bytes
   • CACH (per Figure 6.6: CACH burst) - 24 bits=3 bytes
   • RC (per Figure 6.7: Standalone inbound Reverse Channel (RC) burst) - where the RC burst is standalone including SYNC - 8+16+48+16+8=96 bits=12 bytes
   • RC (per Figure 6.8: Outbound Reverse Channel (RC) burst) - it's already part of the standard burst, no need to extract it as new row in dsp structured output
4. markup, i'd go with:
   • standard burst (v=voice, d=data, f=voice sync) - or make them all the same (s=standard)
   • CACH (c=cach burst)
   • RC (r=rc burst)

Looking at your data, first 4 rows broken down

1 d 3202E4AB68AB889C13800CFF07D30DE4C13364166865F8406190413B04A1
# sync pattern is wrong
2 d 3D35D001D9E2884FF0000 DFF57D34DF4D130C98040C3E880E60C9A12B51B
# the sync pattern here should be DFF57D75DF5D (BS SOURCED DATA)
1 d 9A11EC85E8EA7AC8C4000DFF57D35DF5D130620331877A8944465297A57C
# almost correct sync,
# DFF57D35DF5D vs.
# DFF57D75DF5D
2 d 3D35D041D9E2884FF0000DFF57D75DF5D130C98040C3E880E60C9A12B51B
# sync is correct BS SOURCED DATA

row no.3 (first valid sync) broken down:

# broken down into parts
(3D35D041D9E2884FF0000)(DFF57D75DF5D)(130C98040C3E880E60C9A12B51B)
(expected 108 bits got 84 bits)(sync 48 bits)(expected 108 bits, got 108 bits)

Example valid data

53DF0A83B7A8282C2509625014FDFF57D75DF5DCADDE429028C87AE3341E24191C
(53DF0A83B7A8282C2509625014F)(DFF57D75DF5D)(CADDE429028C87AE3341E24191C)
(27 letters, 108 bits)(6 letters, 48 bits)(27 letters, 108 bits)
# decoded
[BsSourcedData] [DataTypes.CSBK] [CC: 5]
	[CsbkOpcodes.PreambleCSBK] [LB: 1] [PF: 0] [FeatureSetIDs.StandardizedFID] [TARGET IS INDIVIDUAL] [FOLLOWED BY DATA] [BTF: 29] [DST ADDR: 2308195] [SRC ADDR: 2308155]

Screenshots:

[smarek]

Well you beat me, i had the previous comment drafted for 20 hours, and you fixed everything in the meantime, i love it :)))

1. I am happy with markup [TS] [burst type] [burst data]
2. per screenshot, there is CACH burst for each TDMA outbound burst, so i'd go with chronological output order, see below, you can choose what is best per current codebase status
3. i want the on-air bits/bytes, that goes for RC and CACH as well, that means you output before you process the data, see below
4. i would separate each type of burst in the output on the new line, see Figure 4.11: Traffic channel with guard time for variants, not always is CACH or RC present, so we cannot assume it in the output

output template (proposal)

# for standard outbound (CACH, field AT, indicates which TS follows
[TS 1] [CACH] 0A0B0C (3 bytes)
[TS 1] [DATA TYPE] 53DF0A83B7A8282C2509625014FDFF57D75DF5DCADDE429028C87AE3341E24191C (33 bytes incl. SYNC)
[TS 2] [CACH] A0A1A2 (3 bytes)
[TS 2] [DATA TYPE] ... (33 bytes)

# for standard inbound (no CACH)
[TS 1] [DATA TYPE] 53DF0A83B7A8282C2509625014FDFF57D75DF5DCADDE429028C87AE3341E24191C (33 bytes incl. SYNC)
[TS 2] [DATA TYPE] ... (33 bytes)

# when TS2 is RC
[TS 1] [DATA TYPE] 53DF0A83B7A8282C2509625014FDFF57D75DF5DCADDE429028C87AE3341E24191C (33 bytes incl. SYNC)
[TS 2] [RC] A0A1A2A3A4A5A6A7A8A9A0A1 (12 bytes, incl. SYNC)

IDs - burst type / cach / rc (hex) (proposal)

• "99" = RC BURST
• "98" = CACH BURST
• "10" = VOICE BURST
• other values = DATA BURST

channels use-cases

between TDMA bursts there might be CACH or just "guard time pause"

var.1 (traffic channel with CACH)

var.2 (traffic channel with guard time)

var.3 (bi-directional channel)

---

I found a few errors in my initial mock up in the code, I think there may have been a few bytes short, and also I restructured it slightly, now its setup such that the first character is the slot, the second two characters are hex values representing data brusts, and the value of 10 (hex 0x10, dec 16) is designated for voice (bs), let me know if this format will work for you. I can tweak it some still if needed. I'm not sure still though how you want both RC and CACH though, do you want the completed CACH after its all put together but before deinterleave, etc? (for Slow Link Control I presume) or should I just add the CACH bytes to the beginning of each line before the payload? Same for RC or Single Burst Embedded (VC F)? Can't you just scrape that from the appropriate location on the line?

spike2.zip

[lwvmobile]

Anyways, here is what I have so far, just a small segment, and also a zip file with 30 seconds worth of CACH and Traffic Payload.

When you say [TS 1] [DATA TYPE], do you mean you want it in the file as:

[TS 1] [98] 512A06
[TS 1] [03] 4211109C1EB60DECBAE80E8080CDFF47C30DF4C7567E50F0F33811E095440B235E

or as

1 98 512A06
1 03 4211109C1EB60DECBAE80E8080CDFF47C30DF4C7567E50F0F33811E095440B235E

What I have right now is CACH and Voice/Data Payload

1 98 512A06
1 03 4211109C1EB60DECBAE80E8080CDFF47C30DF4C7567E50F0F33811E095440B235E
2 98 5BF442
2 09 53C25EABA8671DC7383BD936025DFF57D75DF5D4B7F6E465171B48CA6D4FC610B4
1 98 2418E7
1 03 4251141D1EB61DEC3AE80E8180CDFF57D75DF5D7567E50F0F33811E095440B235E
2 98 1FC8B0
2 09 53C25EABA8671DC7383BD936025DFF57D75DF5D4B7F6E465171B48CA6D4FC610B4
1 98 728A06
1 03 4251141D1EB61DEC3AE80E8180CDFF57D75DF5D7567E50F0F33811E095440B235E
2 98 5BF442
2 09 53C25EABA8671DC7383BD936025DFF57D75DF5D4B7F6E465171B48CA6D4FC610B4
1 98 2418E7
1 03 4251141D1EB61DEC3AE80E8180CDFF57D75DF5D7567E50F0F33811E095440B235E
2 98 1FC8B0

What I don't have right now is RC handling, at all. I had some code for it in the past but I scrapped it, it wasn't complete and I didn't have anything to test it with. Also, with MS sourced payloads, its only going to be the Voice and Data payloads, and no CACH. I've found that the data handling can be pretty rough on Simplex due to the way the demodulator works, I can get decent voice out of it, but if it isn't BS sourced audio, then data decoding/demodulation is not very good, and voice can have error as well, usually at the very start.

spike-cach.zip

[smarek]

Added some explanatory screenshots to my responses

If you want, we can connect somewhere else, to solve things faster, telegram/signal/discord/irc/Element(previously Matrix)/... just let me know i'll send you my id on whatever communication platform you prefer

I guess you have one copy of codebase and unless it's working, you don't want to commit/push commits to public,
however for these issues/features "feature branches" might be beneficial to you. Just pointing out something you might not know, since you are not trained to be programmer

[smarek]

@lwvmobile to respond to your last

template was overly verbose, yes please, this format, you already have, is probably the best:

1 98 512A06
1 03 4211109C1EB60DECBAE80E8080CDFF47C30DF4C7567E50F0F33811E095440B235E
2 98 5BF442
2 09 53C25EABA8671DC7383BD936025DFF57D75DF5D4B7F6E465171B48CA6D4FC610B4

ad RC, if you don't have handler for it already, we can skip or postpone RC bursts output, sometime later it might be re-implemented

ad CACH see the screenshots above in #94 (comment)
i understand, not always CACH is present on-air

ad demodulation, i'd have to dive into the code, but if we have something already, in ok-dmrlib i have all the ETSI FEC features already, so if it can be repaired using FEC, i don't worry, if the burst is damaged too much, i will skip it's handling, no need to pre-filter your dsp output

i'll pass the spike-cach.dsp to my tools and tonight we might see the traffic monitoring already working :))

[lwvmobile]

ad demodulation, i'd have to dive into the code, but if we have something already, in ok-dmrlib i have all the ETSI FEC features already, so if it can be repaired using FEC, i don't worry, if the burst is damaged too much, i will skip it's handling, no need to pre-filter your dsp output

I don't think any amount of FEC can fix the demodulator as it is. When there is no sync (MS skipping Time Slots) the noise causes issues for the demodulator and the dibit buffer (the aformentioned 131313 string nonsense that was written in originally). DSD was originally written with P25 in mind, they didn't envision an encoding type where the sync pattern is in the middle of the payload (which even I have to admit, is kind of annoying to place it there). I may fix the demodulator one day, but what I'd rather do is write or modify another program that can be the used as a demodulator (completely externalizing it) and use it to pass symbols directly to DSD-FME.

If you want, we can connect somewhere else, to solve things faster, telegram/signal/discord/irc/Element(previously Matrix)/... just let me know i'll send you my id on whatever communication platform you prefer

I prefer not to. No offense to you or anybody, but I prefer the disconnect and slow pace found here and in forums.

I guess you have one copy of codebase and unless it's working, you don't want to commit/push commits to public,
however for these issues/features "feature branches" might be beneficial to you. Just pointing out something you might not know, since you are not trained to be programmer

Yeah, maybe one day I'll learn more about 'feature branches' but to be honest, I'll push the code when I'm ready to push it. I'm working on a few other things as well at the moment, and when I feel its stable and been thoroughly tested, then I'll push it. I'll try to have it all wrapped up and pushed this upcoming weekend. I also have a 'lite' version to maintain and mirror changes to while maintaining the tweaks to make it work properly in 'windows' so between two different code bases, that's already twice as much as I'd ideally like to deal with. I also enjoy working when its at my own pace, and not me being rushed to get this out. Thanks.

[smarek]

Sure, i get all your points and won't rush you. I think we have discussed the feature in-depth, i certainly don't have anything else to add to topic.
"feature branches" are exactly meant for "unfinished and/or untested code", once the feature is polished out, it should be merged to main/master branch and optionally removed from the public repo. just fyi, not trying to push you to it
Thank you very much for effort you investing and i will wait for your contact, once you're ready to progress.

[smarek]

Btw. i extended CSBK support in ok-dmrlib, from second data-set, aloha pdus look like this, just so you know, there is a lot of info, dsd+ does not expose

> dmrlib-dmr-burst 0027163D35D001D9E2884FF010FDFF57D35DF5D130C98040C3E880E60C9A12B51B

[BsSourcedData] [DataTypes.CSBK] [CC: 4]
	[CsbkOpcodes.AlohaPDUsForRandomAccessProtocol] [LB: 1] [PF: 0] [FeatureSetIDs.MotorolaLtd]
	[TSCCAS support: False] [Timeslot sync enabled: False] [DOC: v2] [TIMING: aligned]
	[TS ACTIVE CONNECTION: True] [MASK: 0] [SERVICE: RandomAccessServiceFunction.ALL_SERVICES]
	[NRAND_WAIT: 7] [REGISTRATION REQUIRED: True] [BACKOFF: TDMA Frame Length = 8]
	[SYSTEM IDENTITY: 53253] [MS ADDRESS: 0]

You can check TS 102 361-4 for C_ALOHA PDU (in my version ETSI TS 102 361-4 V1.10.1 (2019-08) its "Table 7.19: C_ALOHA PDU content") for meaning of the values, if they don't seem familiar to you

More output, just for completenes

# one-liner to pass bursts to ok-dmrlib cli tool 
> grep '^2' spike2.dsp | head -n 10 | awk '{print $3}' | xargs -L1 dmrlib-dmr-burst
0027163D35D001D9E2884FF010FDFF57D35DF5D130C98040C3E880E60C9A12B51B
[EmbeddedSignalling] [LCSS.ContinuationFragmentLCorCSBK] [PreemptionPowerIndicator.CarriesReverseChannelInformation] [CC: 13] [EMB FEC: INVALID]
	[CsbkOpcodes.AlohaPDUsForRandomAccessProtocol] [LB: 1] [PF: 0] [FeatureSetIDs.MotorolaLtd] [TSCCAS support: False] [Timeslot sync enabled: False] [DOC: v2] [TIMING: aligned] [TS ACTIVE CONNECTION: True] [MASK: 0] [SERVICE: RandomAccessServiceFunction.ALL_SERVICES] [NRAND_WAIT: 7] [REGISTRATION REQUIRED: True] [BACKOFF: TDMA Frame Length = 8] [SYSTEM IDENTITY: 53253] [MS ADDRESS: 0]
0027163D35D041D9E2884FF010FDFF57D75DF5D130C98040C3E880E60C9A12B51B
[BsSourcedData] [DataTypes.CSBK] [CC: 4]
	[CsbkOpcodes.AlohaPDUsForRandomAccessProtocol] [LB: 1] [PF: 0] [FeatureSetIDs.MotorolaLtd] [TSCCAS support: False] [Timeslot sync enabled: False] [DOC: v2] [TIMING: aligned] [TS ACTIVE CONNECTION: True] [MASK: 0] [SERVICE: RandomAccessServiceFunction.ALL_SERVICES] [NRAND_WAIT: 7] [REGISTRATION REQUIRED: True] [BACKOFF: TDMA Frame Length = 8] [SYSTEM IDENTITY: 53253] [MS ADDRESS: 0]
0027163D35D041D9E2884FF010FDFF57D75DF5D130C98040C3E880E60C9A12B51B
[BsSourcedData] [DataTypes.CSBK] [CC: 4]
	[CsbkOpcodes.AlohaPDUsForRandomAccessProtocol] [LB: 1] [PF: 0] [FeatureSetIDs.MotorolaLtd] [TSCCAS support: False] [Timeslot sync enabled: False] [DOC: v2] [TIMING: aligned] [TS ACTIVE CONNECTION: True] [MASK: 0] [SERVICE: RandomAccessServiceFunction.ALL_SERVICES] [NRAND_WAIT: 7] [REGISTRATION REQUIRED: True] [BACKOFF: TDMA Frame Length = 8] [SYSTEM IDENTITY: 53253] [MS ADDRESS: 0]
0027163D35D041D9E2884FF010FDFF57D75DF5D130C98040C3E880E60C9A12B51B
[BsSourcedData] [DataTypes.CSBK] [CC: 4]
	[CsbkOpcodes.AlohaPDUsForRandomAccessProtocol] [LB: 1] [PF: 0] [FeatureSetIDs.MotorolaLtd] [TSCCAS support: False] [Timeslot sync enabled: False] [DOC: v2] [TIMING: aligned] [TS ACTIVE CONNECTION: True] [MASK: 0] [SERVICE: RandomAccessServiceFunction.ALL_SERVICES] [NRAND_WAIT: 7] [REGISTRATION REQUIRED: True] [BACKOFF: TDMA Frame Length = 8] [SYSTEM IDENTITY: 53253] [MS ADDRESS: 0]
0027163D35D041D9E2884FF010FDFF57D75DF5D130C98040C3E880E60C9A12B51B
[BsSourcedData] [DataTypes.CSBK] [CC: 4]
	[CsbkOpcodes.AlohaPDUsForRandomAccessProtocol] [LB: 1] [PF: 0] [FeatureSetIDs.MotorolaLtd] [TSCCAS support: False] [Timeslot sync enabled: False] [DOC: v2] [TIMING: aligned] [TS ACTIVE CONNECTION: True] [MASK: 0] [SERVICE: RandomAccessServiceFunction.ALL_SERVICES] [NRAND_WAIT: 7] [REGISTRATION REQUIRED: True] [BACKOFF: TDMA Frame Length = 8] [SYSTEM IDENTITY: 53253] [MS ADDRESS: 0]
0027163D35D041D9E2884FF010FDFF57D75DF5D130C98040C3E880E60C9A12B51B
[BsSourcedData] [DataTypes.CSBK] [CC: 4]
	[CsbkOpcodes.AlohaPDUsForRandomAccessProtocol] [LB: 1] [PF: 0] [FeatureSetIDs.MotorolaLtd] [TSCCAS support: False] [Timeslot sync enabled: False] [DOC: v2] [TIMING: aligned] [TS ACTIVE CONNECTION: True] [MASK: 0] [SERVICE: RandomAccessServiceFunction.ALL_SERVICES] [NRAND_WAIT: 7] [REGISTRATION REQUIRED: True] [BACKOFF: TDMA Frame Length = 8] [SYSTEM IDENTITY: 53253] [MS ADDRESS: 0]
0027163D35D041D9E2884FF010FDFF57D75DF5D130C98040C3E880E60C9A12B51B
[BsSourcedData] [DataTypes.CSBK] [CC: 4]
	[CsbkOpcodes.AlohaPDUsForRandomAccessProtocol] [LB: 1] [PF: 0] [FeatureSetIDs.MotorolaLtd] [TSCCAS support: False] [Timeslot sync enabled: False] [DOC: v2] [TIMING: aligned] [TS ACTIVE CONNECTION: True] [MASK: 0] [SERVICE: RandomAccessServiceFunction.ALL_SERVICES] [NRAND_WAIT: 7] [REGISTRATION REQUIRED: True] [BACKOFF: TDMA Frame Length = 8] [SYSTEM IDENTITY: 53253] [MS ADDRESS: 0]
0027163D35D041D9E2884FF010FDFF57D75DF5D130C98040C3E880E60C9A12B51B
[BsSourcedData] [DataTypes.CSBK] [CC: 4]
	[CsbkOpcodes.AlohaPDUsForRandomAccessProtocol] [LB: 1] [PF: 0] [FeatureSetIDs.MotorolaLtd] [TSCCAS support: False] [Timeslot sync enabled: False] [DOC: v2] [TIMING: aligned] [TS ACTIVE CONNECTION: True] [MASK: 0] [SERVICE: RandomAccessServiceFunction.ALL_SERVICES] [NRAND_WAIT: 7] [REGISTRATION REQUIRED: True] [BACKOFF: TDMA Frame Length = 8] [SYSTEM IDENTITY: 53253] [MS ADDRESS: 0]
0027163D35D041D9E2884FF010FDFF57D75DF5D130C98040C3E880E60C9A12B51B
[BsSourcedData] [DataTypes.CSBK] [CC: 4]
	[CsbkOpcodes.AlohaPDUsForRandomAccessProtocol] [LB: 1] [PF: 0] [FeatureSetIDs.MotorolaLtd] [TSCCAS support: False] [Timeslot sync enabled: False] [DOC: v2] [TIMING: aligned] [TS ACTIVE CONNECTION: True] [MASK: 0] [SERVICE: RandomAccessServiceFunction.ALL_SERVICES] [NRAND_WAIT: 7] [REGISTRATION REQUIRED: True] [BACKOFF: TDMA Frame Length = 8] [SYSTEM IDENTITY: 53253] [MS ADDRESS: 0]
0027163D35D041D9E2884FF010FDFF57D75DF5D130C98040C3E880E60C9A12B51B
[BsSourcedData] [DataTypes.CSBK] [CC: 4]
	[CsbkOpcodes.AlohaPDUsForRandomAccessProtocol] [LB: 1] [PF: 0] [FeatureSetIDs.MotorolaLtd] [TSCCAS support: False] [Timeslot sync enabled: False] [DOC: v2] [TIMING: aligned] [TS ACTIVE CONNECTION: True] [MASK: 0] [SERVICE: RandomAccessServiceFunction.ALL_SERVICES] [NRAND_WAIT: 7] [REGISTRATION REQUIRED: True] [BACKOFF: TDMA Frame Length = 8] [SYSTEM IDENTITY: 53253] [MS ADDRESS: 0]

[lwvmobile]

Yeah, I've got the manuals with all the PDUs in them from ETSI, I just haven't put them all in, just the ones I deem more beneficial than others when it comes to trunking support and who is talking to who, etc.

[lwvmobile]

Thought I'd catch up with you for a moment and see what you might know about Hytera XPT systems. Had a couple of samples I acquired recently and was investigating how the link control and csbks and how to properly decode them.

A few LC and CSBKs that stood out to me include the following:

//site 1
        // 09:26:24 Sync: +DMR  [slot1]  slot2  | Color Code=01 | CSBK
        // Hytera XPT 0x0B 
        // DMR PDU Payload [0B][68][08][20][18][10][20][10][28][20][CC][B4]

        //  SLOT 1 Hytera XPT FLCO=0x13 FID=0x68 SVC=0x20 
        //   DMR PDU Payload [13][68][20][08][11][18][20][12][28]

        //  SLOT 1 Hytera XPT FLCO=0x13 FID=0x68 SVC=0x20 
        //   DMR PDU Payload [13][68][20][08][11][18][20][12][28]

//site 2
        // 09:23:56 Sync: +DMR   slot1  [slot2] | Color Code=01 | CSBK
        // Hytera XPT 0x0B 
        // DMR PDU Payload [0B][68][10][20][18][10][20][10][28][20][EF][DA]

        //  SLOT 1 Hytera XPT FLCO=0x13 FID=0x68 SVC=0x20 
        //   DMR PDU Payload [13][68][20][10][21][18][20][12][28]

I've worked some support in for CSBK 0x3A (site status) and also the TLC for Voice 'Grant'? and Free Repeater, etc.
Anyways, was curious to see if you had any insight into the matter, also, here is a DSP file I made of one of the samples. The system isn't particularly busy, so this is about as busy as it gets.

hyteraxpt.zip

Edit: Here is a second sample if it helps any.
hyteraxpt2.zip

[alwinhb]

@smarek @lwvmobile Do you have any samples for DMR Data burst MS Sourced? I want to test those for my setup.

Also a complete VOICE Superframe MS Sourced sample would be of great help!

[lwvmobile]

MSMS_DMR_Simplex.wav.zip

@alwinhb

Here is a super short sample I got a couple years back of MS sourced Data, its not the best quality, however. I probably have others, but not about to dig around to try to find them.

Not sure if I have any MS audio samples handy, can't seem to find any that I'd be at liberty to share, though.

[alwinhb]

@lwvmobile Thanks for the sample, But I am unable to decode this one. Do you have the hex burst? That would be helpful