MPT1327 Decoding on Unitrunker

[grant]

I might be a bit thick here but I am stuffed if I can find anything resembling instructions for decoding MPT1327 on Unitrunker - in my home town of Sydney we have VHF, 400Mhz and 500Mhz MPT1327 systems. I have made a few attempts but so far no success. Some other local users have had similar problems. There is virtually nothing in the notes that accompany Unitrunker. This is not a criticism - just looking for guidance. Trunkview on the otherhand seems to be able to decode it - maybe a raw trunkview data file might help to understand how the local systems are setup.


Grant

 

[SCPD]

Hi Grant;

There's nothing special as far as setting the program up for MPT1327. You may want to compare speaker audio to discriminator audio. Some systems include a sub-audible tone with the carrier tone. For those systems, speaker audio works better.

Some systems don't use a standard sync pattern. I need to check my notes to see where Unitrunker stands with these types of systems. I know of at least one fellow from France who was unable to use Unitrunker for this reason.

 

[grant]

I pulled out the cable I was using for the discriminator tap and replaced it with a speaker jack cable that runs from the Uniden 780 speaker jack to the notebook speaker jack. Bingo! Worked straight away! The data channel I am monitoring now (416.200Mhz) is a 20 channel system in Sydney. Looks promising.


Grant

 

[grant]

It took me a little while to work out the Radio numbers on Unitrunker as they don't seem to relate to the user numbers off the screen, until I figured out they related to multiples of 8192

Group 0 - 0
Group 1 - 8192
Group 2 - 16384
Group 3 - 24768 etc

So listening to another system, the Vertel MPT1327 500Mhz system on Sydney Tower with control channel 505.0750 Mhz, I was able to figure out that radio 3-0863 (which works for Group 3 - a waste company and goes by the callsign "Metro 1") relates to number 24768 + 863 = 25631 in the log file


Grant

PS I have yet to submit this 6 site trunking system for the NSW database - must get around it.

 

[SCPD]

It took me a little while to work out the Radio numbers on Unitrunker as they don't seem to relate to the user numbers off the screen, until I figured out they related to multiples of 8192

That's weird. You should see hyphenated IDs. The display choices are hex or decimal.

 

[Comint]

It took me a little while to work out the Radio numbers on Unitrunker as they don't seem to relate to the user numbers off the screen, until I figured out they related to multiples of 8192

There are some Excel formulas here for converting between MPT1327 Prefix/Ident and the decimal format Unitrunker uses in its files.

 

[grant]

That's weird. You should see hyphenated IDs. The display choices are hex or decimal.

I can see the hyphenated ID's on the Unitrunker screen
However when I look up the log text later the numbering is not hyphenated.
If I want to tag the hypenated ID on "insert" with a callsign name eg 3-0863 with "Metro 1", the insert won't work unless you know the number that shows in the log text eg 25631.
I have to do a conversion elsewhere then carry the number over
Hope that makes sense


Grant

 

[grant]

Re the synch pattern:

On the properties screen the following Synch numbers appear

AAAAC4D7 - most of the time it sits on this one
0C96034A
700A01D6
10008F37
7000607B

Grant

 

[SCPD]

If I want to tag the hypenated ID on "insert" with a callsign name eg 3-0863 with "Metro 1", the insert won't work unless you know the number that shows in the log text eg 25631.
I have to do a conversion elsewhere then carry the number over
Hope that makes sense

Now it does. Thanks grant. Typing an ID should match the display format and expect a hyphen. That's an old bug I thought I fixed (fixing this one now).

On the properties screen the following Synch numbers appear

On the [O]ptions screen is an "Ignore sync" option. At the expense of increased CPU load, the program will accept non-standard sync values. Normally you want this feature off unless you've found a system in your area that requires this.

 

[Jay911]

On the [O]ptions screen is an "Ignore sync" option. At the expense of increased CPU load, the program will accept non-standard sync values. Normally you want this feature off unless you've found a system in your area that requires this.

Can you clarify what 'off' means in the above quote? Should you be ignoring sync regularly unless it's needed?

I just flipped it to "Yes" (to ignore sync) and got my decode rocketing to 100% from a point between 57%-85%.

 

[SCPD]

Can you clarify what 'off' means in the above quote? Should you be ignoring sync regularly unless it's needed?

Ignore sync=No is the default. If you set Ignore sync to "Yes" ... you will incur an increase in CPU load ... even when you are not monitoring an MPT1327 signal. Set the option to "No" unless you think you need it.

 

[grant]

Re "25631" should be 25431 ... I goofed up
I am using the 14th beta version which is the latest.
OK re switch the synch off - it was already in the default off position

Grant

 

[grant]

Afew more questions

1. I have noticed that once the calls between the radios have registered on the screen they disappear even though the conversation still continues on the frequency if you are monitoring the frequency(for instance on the Motorola Type 2 Omnilink system I monitor the call remains on the screen and even tracks it around)

2. Do you have any facility for displaying MPT1343 messages (used here in Sydney)

eg:
08:41 - HEAD | Short data message | Org: (014) 4589 Tar: (014) 4709 Codewords: 4
08:41 - | Message (MPT1343 ASCII format) | 9AM F!FOREST CT $65

which decodes as a courier job at 9am French's Forest to the City for $65


Grant

 

[SCPD]

1. I have noticed that once the calls between the radios have registered on the screen they disappear even though the conversation still continues on the frequency if you are monitoring the frequency

Most trunking protocols use "continuation" or "late entry" messages to indicate a call in progress. Either the program isn't decoding these messages correctly - or this system isn't issuing them. Opus made some comments on this issue - but it's been a while.

2. Do you have any facility for displaying MPT1343 messages (used here in Sydney)

No ... no data, other than indicating the presence of a data call.

 

[Jay911]

Most trunking protocols use "continuation" or "late entry" messages to indicate a call in progress. Either the program isn't decoding these messages correctly - or this system isn't issuing them. Opus made some comments on this issue - but it's been a while.

I frequently run Trunkview and Unitrunker simultaneously. This works well, especially if you're trying to look at situations like this. I don't know if others do this (or know it can be done on most machines). You get to see the stuff Unitrunker logs and monitors, and you get the actual messages showing up in realtime with Trunkview (kind of a 'debug mode' if you will, seeing real-time what Unitrunker does in the debug log).

Anyway, speaking to the specific issue mentioned above - I have noticed it on my own monitoring of MPT1327 systems. Continuation messages seem to only be sent once every 10 or so seconds. On the particular system(s) I monitor, only the original calling party is addressed, even in the continuation.. so if radio 2-0203 starts a call, radio 2-0215 answers, radio 2-0305 comes in too, and 2-0215 and 2-0305 continue a conversation for a significant amount of time, the continuation will still show 2-0203, even if 2-0203 hasn't transmitted for quite some time (in the current call).

 

[Comint]

2. Do you have any facility for displaying MPT1343 messages (used here in Sydney)
eg:
08:41 - HEAD | Short data message | Org: (014) 4589 Tar: (014) 4709 Codewords: 4
08:41 - | Message (MPT1343 ASCII format) | 9AM F!FOREST CT $65

which decodes as a courier job at 9am French's Forest to the City for $65

Short Data Messages, and HEAD messages, are part of the MPT1327 Standard, and are not MPT1343 specific, even though that example implies otherwise. See section 5.6.2 of the Standard here.