Raw data

Status
Not open for further replies.

nocpire

Member
Joined
May 12, 2007
Messages
90
First, I'm not sure if this is the right forum for this thread.
Second, thanks to unitrunker and all others for the previous help.

I'm pulling raw Motorola data from the FCCA public safety (Columbus, OH, Motorola type II) to a file for analysis to see if I can create a monitoring program for the Linux OS. And I can't seem to find any references to the structure of the raw data. I probably missed it in the wiki or some forum. Does anybody have good info or a source that I can check on?

Again, many thanks.
 

slicerwizard

Member
Joined
Sep 19, 2002
Messages
6,793
Location
Toronto, Ontario
Code:
// raw datastream:
//
//           111111111122222222223333333333344444444445555555555666666666677777777778888
// 0123456789012345678901234567890123456789012345678980123456789012345678901234567890123
// ffffffffdddddddddddddddddddpppppppppppppppppppDDDDDDDDDDDDDDDDDDDDPPPPPPPPPPPPPPPPPPP
//         ^                  ^                  ^                   ^
//         first data bit     first parity bit   second data bit     second parity bit
//                                                                  ^                  ^
//                                                      last data bit    last parity bit
//
// ffffffff = frame marker (10101100)
//
//
// deinterleave to data...
//
// dDdDdDdDdDdDdDdDdDdDdDdDdDdDdDdDdDdDdD  (last data bit is unused since it's
// IIIIIIIIIIIIIIIIGCCCCCCCCCCcccccccccc    not protected by two parity bits)
// <-------------->|<--------><-------->
//    ID ^ CC38    | Cmd ^ D5  CRC ^ 3FF
//                 Grp ^ 1
//
//
// ... and parity:
//
// pPpPpPpPpPpPpPpPpPpPpPpPpPpPpPpPpPpPpP
//
//
// for each '1' bit in data:
//
// 000010000010000000110000000000000000
//
// flip corresponding parity bit and next parity bit:
//
// 000011000011000000101000000000000000
//
// this should leave all parity bits zeroed
//
//
// where two consecutive parity bits remain set,
//  it indicates that a '1' data bit was received as a '0' bit,
//  or a '0' data bit was received as a '1',
//  so flip corresponding data bit and clear both parity bits
//
// a single set parity bit should be ignored
// (you should assume that it was received incorrectly)
 

nocpire

Member
Joined
May 12, 2007
Messages
90
maybe using the wrong words

Ok, I appreciate the response, but what I'm using is minicom (Linux version of Hyperterminal). Included is a couple of pdf's from several days apart. The first one is an output with 6 columns. Columns 2 & 4 are in hex as output from the radio, and 5 & 6 are the decimal values. The 3rd is color coded red on the frequency numbers and the 7th is annotated users/groups from the values in the 6th column. Columns 7, 8, and 9 are frequency assignments (decimal-freq-hex) (yellow for control freq's.) for the system. Control info is grayed and orange is what I thought was the control freq. being advertised. Near as I can tell, 5th column frequency references that aren't color coded are I-call's.

The second pdf starts basically the same, but instead of frequency assignments, the output from unitrunker was pasted during the same time that the control data was being collected. Plus, a slightly different color coding to try to anchor time and usage points between the sources.

One thing that sticks out is that the system ID (232E) (single site btw) is designated by (hex) 32B. That day, I checked the OSU system, and it was the same. However, the following sample was using 0x308 (0x is a hexadecimal indicator for the uninitiated following this thread).

Also, 0x3C0 seems to be some sort of system value but I can't figure out quite what it's for. These values, do not change in either sample. I'm guessing (again) that at least one might represent the connect tone, and another might be some sort of mask for boolean processing of some sort to derive values that seem out of place in the other columns.

Any ideas on how to interpret the sections I can't seem to understand?
 

Attachments

nocpire

Member
Joined
May 12, 2007
Messages
90
P.S. For those wondering, the first sample was for just a few seconds. The second was for a full minute. Another thing that sticks out is that the control flow lists all usage for the duration of the transmission.
 

WayneH

Forums Veteran
Super Moderator
Joined
Dec 16, 2000
Messages
7,501
Location
Sitting in an airport somewhere
One thing that sticks out is that the system ID (232E) (single site btw) is designated by (hex) 32B. That day, I checked the OSU system, and it was the same. However, the following sample was using 0x308 (0x is a hexadecimal indicator for the uninitiated following this thread).
The $32B OSW is a Scan Marker for scanning radios so they know they're on the correct system. It's an analog thing so straight digital 3600 systems won't send them. The dual OSW (starts with $308) is the true system ID that's sent out every 3 seconds.

Also, 0x3C0 seems to be some sort of system value but I can't figure out quite what it's for.
It's a system background word. There are two of them for single/Simulcast systems. SmartZone and AMSS will send local ($3C0) site and wide-area ($3BF) versions; SZ will send a fifth which is SZ specific information. I believe they're also used for syncing.

Any ideas on how to interpret the sections I can't seem to understand?
Individual versus group is distinguished by the single bit. Generally speaking, '1' indicates Individual and '0' indicates Group. When a radio sees the command $308 is knows that the following OSW is paired together. There's only one triple OSW and there are a ton of duals. Some don't always start with $308. It's all about context.

If you want to know about specific OSW's single them out individually so it's easier for me to find what it is you're questioning.
 
Last edited:

nocpire

Member
Joined
May 12, 2007
Messages
90
Control output

Thanks Wayne, I really appreciate the help. The first question refers to the 1st.pdf. According to your explanation, at the bottom of sheet 1, Rid's 40843 and 56320 are I-calling each other. It seems to me that the place where the channel numbers usually are, are replaced (throughout the sheet) with 2F8/308/310/30B/322 values. It would seem that these still indicate channel numbers somehow (albeit, in a special way). And, it also seems that in an I-call, a 1 vs: a 0 single bit would indicate the called vs: the calling party.

Is there any signaling going on to show a call being setup and who the parties are? Not necessarily in this short example of course.

Again, many thanks.
 

slicerwizard

Member
Joined
Sep 19, 2002
Messages
6,793
Location
Toronto, Ontario
maybe using the wrong words
Uh, yeah. You said you wanted to know about the raw data, but you're working with fully processed (framed, deinterleaved, FEC'd, CRC checked) OSWs. Their meaning is easily extracted from the Trunker source code. That should be your first stop. That will get you to here:
Code:
Xlat-OSW(32)  Rev 2.46  (c) 1999-2009  W. A. Porrett

Decoding 800 MHz Type II or 800 MHz Type IIi datastream...

30B I 261C  discarded
3C0 G 52C0  System status #2; Reduced data mode; No digital comms echo delay
3C0 G 308F  System status #1; Affiliate on PwrUp; Connect tone: 97.30 Hz; No dispatch timeout; Interconnect timeout: 15 min.
32B I 232E  Scan marker; Auto affiliation; SysID=232E
2A9 G 2A70  Group call; TG=2A7  Chan=2A9
3C0 G 52C0  SS2
3C0 G 308F  SS1
32B I 232E  Scan marker; Auto affiliation; SysID=232E
2A9 G 2A70  Group call; TG=2A7  Chan=2A9
3C0 G 52C0  SS2
3C0 G 308F  SS1
32B I 232E  Scan marker; Auto affiliation; SysID=232E
2A9 G 2A70  Group call; TG=2A7  Chan=2A9
3C0 G 52C0  SS2
3C0 G 308F  SS1
32B I 232E  Scan marker; Auto affiliation; SysID=232E
2A9 G 2A70  Group call; TG=2A7  Chan=2A9
3C0 G 52C0  SS2
3C0 G 308F  SS1
3C0 G 52C0  SS2
3C0 G 308F  SS1
3C0 G 52C0  SS2
3C0 G 308F  SS1
3C0 G 52C0  SS2
3C0 G 308F  SS1
3C0 G 52C0  SS2
308 G 9F8B  Group call grant; TG=57  RID=9F8B  Chan=13F
13F G 0570
3C0 G 308F  SS1
308 G 9F8B  Group call grant; TG=57  RID=9F8B  Chan=13F
13F G 0570
3C0 G 52C0  SS2
308 G 9F8B  Group call grant; TG=57  RID=9F8B  Chan=13F
13F G 0570
3C0 G 308F  SS1
308 G 9F8B  Group call grant; TG=57  RID=9F8B  Chan=13F
13F G 0570
32B I 232E  Scan marker; Auto affiliation; SysID=232E
2A9 G 2A70  Group call; TG=2A7  Chan=2A9
3C0 G 52C0  SS2
3C0 G 308F  SS1
308 I DC00  Private call; From RID=D1F7 to RID=DC00  Chan=117
117 I D1F7
13F G 0570  Group call; TG=57  Chan=13F
308 I DC00  Private call; From RID=D1F7 to RID=DC00  Chan=117
117 I D1F7
32B I 232E  Scan marker; Auto affiliation; SysID=232E
308 I DC00  Private call; From RID=D1F7 to RID=DC00  Chan=117
117 I D1F7
2A9 G 2A70  Group call; TG=2A7  Chan=2A9
000 I 0001  Type2 interconnect; RID=1  Chan=0
308 I DC00  Private call; From RID=D1F7 to RID=DC00  Chan=117
117 I D1F7
2F8 I 0B19  Idle
308 I DC00  Private call; From RID=D1F7 to RID=DC00  Chan=117
117 I D1F7
3C0 G 52C0  SS2
308 I DC00  Private call; From RID=D1F7 to RID=DC00  Chan=117
117 I D1F7
3C0 G 308F  SS1
308 G 7830  Group call grant; TG=51  RID=7830  Chan=EF
0EF G 0510
13F G 0570  Group call; TG=57  Chan=13F
308 I DC00  Private call; From RID=D1F7 to RID=DC00  Chan=117
117 I D1F7
32B I 232E  Scan marker; Auto affiliation; SysID=232E
2A9 G 2A70  Group call; TG=2A7  Chan=2A9
3C0 G 52C0  SS2
3C0 G 308F  SS1
0EF G 0510  Group call; TG=51  Chan=EF
13F G 0570  Group call; TG=57  Chan=13F
308 I DC00  Private call; From RID=D1F7 to RID=DC00  Chan=117
117 I D1F7
32B I 232E  Scan marker; Auto affiliation; SysID=232E
2A9 G 2A70  Group call; TG=2A7  Chan=2A9
3C0 G 52C0  SS2
3C0 G 308F  SS1
0EF G 0510  Group call; TG=51  Chan=EF
13F G 0570  Group call; TG=57  Chan=13F
308 I DC00  Private call; From RID=D1F7 to RID=DC00  Chan=117
117 I D1F7
32B I 232E  Scan marker; Auto affiliation; SysID=232E
2A9 G 2A70  Group call; TG=2A7  Chan=2A9
3C0 G 52C0  SS2
3C0 G 308F  SS1
0EF G 0510  Group call; TG=51  Chan=EF
13F G 0570  Group call; TG=57  Chan=13F
308 I DC00  Private call; From RID=D1F7 to RID=DC00  Chan=117
117 I D1F7
32B I 232E  Scan marker; Auto affiliation; SysID=232E
2A9 G 2A70  Group call; TG=2A7  Chan=2A9
3C0 G 52C0  SS2
3C0 G 308F  SS1
0EF G 0510  Group call; TG=51  Chan=EF
308 G 232E  SysID; SysID=232E  ctl chan=153
30B G 2953
153 I 1FEE  Type1 SysID/CCmarker; ctl chan=153
13F G 0570  Group call; TG=57  Chan=13F
308 I DC00  Private call; From RID=D1F7 to RID=DC00  Chan=117
117 I D1F7
32B I 232E  Scan marker; Auto affiliation; SysID=232E
000 I 0002  Type2 interconnect; RID=2  Chan=0
2A9 G 2A70  Group call; TG=2A7  Chan=2A9
3C0 G 52C0  SS2
3C0 G 308F  SS1
0EF G 0510  Group call; TG=51  Chan=EF
3C0 G 52C0  SS2
3C0 G 308F  SS1
3C0 G 52C0  SS2
3C0 G 308F  SS1
...
101 G 0110  Group call; TG=11  Chan=101
308 G 3F16  Group call grant; TG=5  RID=3F16  Chan=151
151 G 0050
308 I 0992  Affiliation; RID=992  TG=5
310 I 0050
308 G 3F16  Group call grant; TG=5  RID=3F16  Chan=151
151 G 0050
308 I 0992  Affiliation; RID=992  TG=5
310 I 0050
308 G 3F16  Group call grant; TG=5  RID=3F16  Chan=151
151 G 0050
308 I 0992  Affiliation; RID=992  TG=5
310 I 0050
308 G 3F16  Group call grant; TG=5  RID=3F16  Chan=151
151 G 0050
308 I A52C  Private call; From RID=A5C6 to RID=A52C  Chan=18D
18D I A5C6
...
 

nocpire

Member
Joined
May 12, 2007
Messages
90
Thanks for the clairification

And the rest of the information, it will be a great help.

thx!!!
 

nocpire

Member
Joined
May 12, 2007
Messages
90
Update

The trunker source code is a good source of info. Especially for the hex-codes that I was having problems with. Also found out that unitrunkers own "log radio command" output includes comments in the log file. Both are a bit "read-y" though. And you have to dig a bit to find the right file in either situation. I might have an idea on how to filter the output from minicom, but the trick is going to be generating a dynamic table that updates like ut's. Right now I'm looking at a bash script solution. At any rate, "it `aint gonna be next week".

Question: Does the control freq. info appear in the OSW stream? I haven't found that one yet.
 

nocpire

Member
Joined
May 12, 2007
Messages
90
OSW stream structure

For a valid reading, do the OSW pairs have to be right next to each other, or are there situations where they can be offset by the system codes? i.e. are the system codes stripped and tossed into the `ole "bit-bucket" and the rest of the stream concatenated?
 

WayneH

Forums Veteran
Super Moderator
Joined
Dec 16, 2000
Messages
7,501
Location
Sitting in an airport somewhere
For a valid reading, do the OSW pairs have to be right next to each other, or are there situations where they can be offset by the system codes? i.e. are the system codes stripped and tossed into the `ole "bit-bucket" and the rest of the stream concatenated?
OSW pairs must be sequential. That's why you see them sent more than once (sysid and SZ neighbor/alternate info excluded).

One thing to do is not act on the first occurrence of the OSW(s). If it's something that's sent more than once use that to your advantage for error checking. I have seen some controllers send out bogus info and all it takes is some random $308 command to monkey things. It's one of the PITA's with the protocol.
 

nocpire

Member
Joined
May 12, 2007
Messages
90
Sounds like understanding "the context" is a PITA to program for. Also, I take it, that the SZ/neighbor info is for multi-site installations vs: single site systems?
 

nocpire

Member
Joined
May 12, 2007
Messages
90
whoops!

Forgot about the earlier thread:
"SmartZone and AMSS will send local ($3C0) site and wide-area ($3BF) versions; SZ will send a fifth which is SZ specific information. I believe they're also used for syncing."
 
Status
Not open for further replies.
Top