UniTrunker 4th Public Beta

[FLANO]

An EDACS control channel has the same sound as ProVoice formatted voice channel. This can cause some confusion if you're hunting for a control channel. The program can identify a Provoice voice channel - but not decode it. If you're hunting for an EDACS control channel - that's you're clue to press the "Search" or "Scan" button to keep looking.

-rick

Rick,

Yep, that's what I'm doing...searching through the frequency range in my area....

So, this is garbage then, yes? Or I should say at least as far as Unitrunker is concerned?

thanks,

 

[FLANO]

That's because it was sampled at 11k samples per second and compressed to MP3 (with a WAV file wrapper). A normal 16 bit PCM coded WAV file sampled at 44,100 samples per second would have been 5 megabytes per minute.

Rick,

Here it is as a 16 bit PCM, sampled at 44.1k, straight from the discrimnator...

 

[SCPD]

So, this is garbage then, yes? Or I should say at least as far as Unitrunker is concerned?

It's definitely a Provoice signal.

 

[SCPD]

There's a fifth public beta available in the usual place. I'll start a new thread with a link to download.

 

[Jay911]

Hi Rick,

I know you're going to create a thread for the 5th beta soon, but I figured I'd provide my comments now since they're fresh in my head - they can either sit at the end of this thread or be moved by a moderator to the new one - doesn't matter to me.

MPT1327 is working splendidly for me with beta 5. 100% decode, and the display shows the prefix/fleet fine. There are a couple of things to discuss, though.

1 - Users on my local system(s) do a LOT of radio-to-radio comms - what others refer to as "I-Calls". When this occurs, the target/destination radio ID is written to the .GID file as a group (and/or if I want the destination RIDs to show up, I have to duplicate them in the GID file). I don't know if it's possible to do what I'm going to suggest, but I wonder if the destination can be checked, and if the root value (stripping off the prefix/fleet value) is >6000, consider it a group; if it is <6000, consider it a radio - and draw the ID, etc., from the appropriate file. (To the best of my knowledge, GIDs in MPT1327 start at 6000.)

2. My groups file has also logged dec id 8185, hex 1FF9 - which is a system benchmark. Specifically, this is "Registration Ident" (REGI) as per the MPT1327 spec. It appears from the spec that anything including and greater than 8000 is a system benchmark/ident and IMO, should not be logged as a group. I expect to see 8101 come into my groups list eventually too, as that is a PSTN Ident - and this system uses phone patches frequently as well.

Finally, on my Motorola Smartzone system.. you may recall I was experiencing Dig and XP calls and other such groups 'blanking' out the "Calling Party" field. I no longer see that on beta 5 - it is now showing the calling party beautifully.

Thanks for the continued hard work!

 

[morfis]

Hi Rick,

I know you're going to create a thread for the 5th beta soon, but I figured I'd provide my comments now since they're fresh in my head - they can either sit at the end of this thread or be moved by a moderator to the new one - doesn't matter to me.

MPT1327 is working splendidly for me with beta 5. 100% decode, and the display shows the prefix/fleet fine. There are a couple of things to discuss, though.

1 - Users on my local system(s) do a LOT of radio-to-radio comms - what others refer to as "I-Calls". When this occurs, the target/destination radio ID is written to the .GID file as a group (and/or if I want the destination RIDs to show up, I have to duplicate them in the GID file). I don't know if it's possible to do what I'm going to suggest, but I wonder if the destination can be checked, and if the root value (stripping off the prefix/fleet value) is >6000, consider it a group; if it is <6000, consider it a radio - and draw the ID, etc., from the appropriate file. (To the best of my knowledge, GIDs in MPT1327 start at 6000.)

This will not work with large systems such as the Fleetcomm networks in the uk.

The logging of 'groups' in the current form is not suitable for MPT1327. The MPT1327 standard uses a three figure Group Prefix and a four figure radio ID. Both are required to uniquely identify a radio.
To make matters more complicated fleets can exist on any defined range of radio idents - to take an example I gave Rick, 009-5350 -> 009-5373 are used by a taxi firm near me on the Billinge Fleetcomm transmitter. They also use a fleetwide address which is 009-8006.
Another use 009-07xx range and that includes a couple of group addresses.

Using the same transmitter site are another 18 Group Prefixs some of which only have one user fleet (040-xxxx) and others which have numerous fleets (009, 012, 017). Some users are national (such as Stagecoach MegaBus 017-11xx) and some are local only ('my' taxi firm).

 

[Jay911]

morfis, I think we're talking about two separate things with regards to groups.

In the terminology used by Unitrunker, and virtually all other trunk systems and types, a 'group' is a "channel" where many users can communicate together. I believe you are referring to this as "fleetwide" in your post above. What you are referring to as "group" is the prefix or fleet, which forms part of, and is integral to, the radio ID.

In most trunk systems that I've been exposed to, fleet users rarely, if ever, talk to/on other fleets - if they are even capable of doing so, which I don't believe they are. However, in the MPT1327 spec, fleets are defined much more loosely, and anyone can talk to virtually anyone else. For the purposes of Unitrunker, though, this doesn't really matter.

I still maintain that group IDs must be separated from radio IDs in some numerical fashion, though I can't find any reference to that in the MPT1327 spec. The reason I used 6000 as my recommendation to Rick is that in all the systems I've worked with or monitored, I've never seen a talkgroup ID that was lower than 6000. Your comment above about "fleetwide" being 8006 in your one system also seems to bear that out. Would you be willing to send me a list of all the info on the systems local to you, and/or are they available for me to grab off the Yahoogroup?

The only place in the MPT1327 spec that appears to impose limitations on IDs in any way is page 35 where it mentions that ID 0 is reserved as the "dummy ID", and IDs 8101 to 8191 are reserved for system use. That makes sense, considering how prefixes are stored (8192*prefixID).

 

[morfis]

I still maintain that group IDs must be separated from radio IDs in some numerical fashion, though I can't find any reference to that in the MPT1327 spec. The reason I used 6000 as my recommendation to Rick is that in all the systems I've worked with or monitored, I've never seen a talkgroup ID that was lower than 6000. Your comment above about "fleetwide" being 8006 in your one system also seems to bear that out.

In one of the other examples I quoted I mentioned two group addresses within 07xx....well below 6000

The only place in the MPT1327 spec that appears to impose limitations on IDs in any way is page 35 where it mentions that ID 0 is reserved as the "dummy ID", and IDs 8101 to 8191 are reserved for system use. That makes sense, considering how prefixes are stored (8192*prefixID).

The spec allows any addresses for any individual OR group beween 0001 and 8100 (check the beginning of the adressing section of the spec document I think it is around the page you mention)

 

[Comint]

MPT1327 &quot;Groups&quot;

Maybe MPT1343 can shed some light on the discussion ( or add to the confusion).

Comint

 

[morfis]

Maybe MPT1343 can shed some light on the discussion ( or add to the confusion).

Comint

Isn't that relating to the specs for the radio equipment rather than the trunking protocol?

 

[Jay911]

Morfis, I can't seem to locate the data for the areas you refer to. I checked ALL of the RadioReference database for Canada, USA, the UK, Australia, NZ, and Japan, as well as all the systems in the files and database areas of the trunkview Yahoogroup, and out of about 100 systems I located, I found no systems reporting talkgroups less than 6000. I'm not doubting your logging, but I still insist there has to be some border between radio IDs and talkgroups. Otherwise, how does the system know what is a talkgroup and what is a radio?

I'd love to see some data from your area. Mine is all published in the Alberta, Canada section of the RR database.

*** To rfmobile *** - In each data file for a given system, the new field for hit count is not included in the header.

 

[Jay911]

Upon reading page 8-13 of the MPT1343 spec (available here), it would seem that we're both right and wrong, in a way. Group IDs are segregated from radio IDs, but it's wholly dependent on fleet size. I'd respectfully submit that the default fleet size is the one that allows talkgroups to begin at 6000 - considering that a lot of systems scream 'default' with regards to their settings (i.e. sysid 2309, etc). A modified version of the wiki page on determining Motorola Type I IDs might help folks understand/determine talkgroups vs radio IDs.

 

[morfis]

I still insist there has to be some border between radio IDs and talkgroups. Otherwise, how does the system know what is a talkgroup and what is a radio?

Why? System definition and radio programming deal with it.

Fleetcomm have a whole host of users and associated fleet addresses are usually (though not always) towards the ends (high or low) of the set of radio idents.
The airport nets over here seem to have quite a few distinct fleets within their groups (though only one Group Prefix normally) and again with fleet addresses towards the ends of the fleet ranges.
Then of course there are the ones like the taxi firm locally that have a fleet address above 8xxx which is no-where near their individual radio addresses!

I'd love to see some data from your area. Mine is all published in the Alberta, Canada section of the RR database.

None of my data is stored on here nor will it be. The only direct submissions I have made to the database here in recent times has been to try and get errors in what was submitted corrected.

There are several yahoo lists etc. that have some connection to MPT1327 decoding...I have yet to see one that had an decent kind of database structure.

A lot of the Uk networks seem to have channels that are in a steady state of flux and in that sense don't lend themselves to documentation online (and that isn't to take into account the legality of doing so).

 

[morfis]

...... - considering that a lot of systems scream 'default' with regards to their settings (i.e. sysid 2309, etc).

Not sure I understand this? SysIDs I've logged in the UK go from 0000 to 7FA9. Some are far more common than others and this seems to be due to the installation/set up being done by a limited range of companies. Each manufacturer seems to have their own "favourite" SysID.

There is no central authority here allocating SysIDs so I can install as many as I like with 3D89 (or whatever). There are a couple that use "national" idents when they clearly aren't national systems.
The vast majority are in the OpID / Private range of numbers

As we are straying from Unitrunker discussion perhaps one of the mods can move the last couple of messages to the MPT1327 bulletin board?

 

[Jay911]

Not sure I understand this? SysIDs I've logged in the UK go from 0000 to 7FA9. Some are far more common than others and this seems to be due to the installation/set up being done by a limited range of companies. Each manufacturer seems to have their own "favourite" SysID.

There is no central authority here allocating SysIDs so I can install as many as I like with 3D89 (or whatever). There are a couple that use "national" idents when they clearly aren't national systems.
The vast majority are in the OpID / Private range of numbers

As we are straying from Unitrunker discussion perhaps one of the mods can move the last couple of messages to the MPT1327 bulletin board?

I don't see a point in continuing this conversation elsewhere as you and I clearly disagree on the fundamentals of how trunking systems work.

"We" are not straying from Unitrunker. My original post on this topic was for the benefit of rfmobile, to help improve the operation of Unitrunker's MPT1327 code. My observations and impressions remain as described above, based on studies of the specs and a professional history working with many different types of trunked and conventional systems for many years. If you wish to discuss this in more depth (with more than "I'm not sure I understand" as a counter-argument), feel free to PM me instead.

 

[SCPD]

Here's my recent understanding of how MPT1327's addressing (group ids and radio ids) is different from other more well-known (to me at least) protocols.

1. Group #s and radio #s share a common number "space". In other words ... the number 1000 can be a talkgroup or a radio id - but not both (in contrast to many other protocols).

2. There is no mathematical relationship between a group id and radio id (in contrast to Type I Motorola). They share the same prefix - that's it.

Right now Unitrunker may display a radio id under the "Groups" view. It will also display an I-call as a group call. I'm considering a few options so that this can be managed by the program. It may require user intervention to distinguish a group id from a radio id.

One unique aspect of this protocol is that group calls and I-calls are indistinguishable ... so ... right now ... with my limited understanding of the protocol ... I can't easily conclude whether the destination ID of a call is a radio ID or a group ID. The user can decide by listening to the call and observing hit counts.

 

[Jay911]

Right now Unitrunker may display a radio id under the "Groups" view. It will also display an I-call as a group call.

Fair enough - not a big deal to manipulate both RID and GID when one or the other changes, for someone like me who mucks about in them often. Thanks.

I don't know if you caught a comment I made in one of those posts above, but the headers of the control files don't include the new "hits" column, which IS included in the data below.

Also - when doing a Find on either a Unit or Group by the RID or GID number, you must enter it in full decimal (i.e. 22387 instead of 2-6003). Any thoughts on whether that can (or should) be changed?

 

[SCPD]

I don't know if you caught a comment I made in one of those posts above, but the headers of the control files don't include the new "hits" column, which IS included in the data below.

I'll fix that.

Also - when doing a Find on either a Unit or Group by the RID or GID number, you must enter it in full decimal (i.e. 22387 instead of 2-6003). Any thoughts on whether that can (or should) be changed?

Yeah ... I remember morfis saying the same thing. I'll add it to the list.

Also, in response to this earlier item ...

2. My groups file has also logged dec id 8185, hex 1FF9 - which is a system benchmark. Specifically, this is "Registration Ident" (REGI) as per the MPT1327 spec. It appears from the spec that anything including and greater than 8000 is a system benchmark/ident and IMO, should not be logged as a group. I expect to see 8101 come into my groups list eventually too, as that is a PSTN Ident - and this system uses phone patches frequently as well.

The reserved high number idents remain useful for the activity display. Some are system defined. By treating these the same as groups (or equivalently as radios) ... the user can edit them to provide a meaningful label. Hypothetical example, one code might be a PSTN gateway while another is a PBX bridge.

The other item you brought up was weak system identity. This is the same problem as EDACS and LTR where multiple systems share the same identifying number. We'll just have to come up with a way to manage this.