Trunkview V1.50 released

[morfis]

A new version of Trunkview has been released. Many new features:

http://www.linato.net/trunkview/?Home:Changelog

[ScanDaBands]

anybody got this working with a 396T ?

If so what are your settings ????

[morfis]

Yes - Uniden for scanner type, Dynamic memory for "channel". Works fine

(edit to add quotes)

[Napalm]

Works with all the DMA Uniden's as far as we/I know.

Works flawlessly with my 330, 15 anyway, so chances are it will for all the others.

[DaveH]

For reasons unknown I had been unable to get an older version working;
then tried this one, which worked, then the older one, which now also works.
Strange, but no complaints.

I'm running the software on this networked UHF system:

http://www.radioreference.com/module...me=RR&sid=4307

First I notice is in the site setup is no provision for "offset". No problem,
the base frequency can be extended down to "0" offset. However, there
is no provision for multiple base/offsets, which by the discontinuities in
frequency v. channel numbers, this system uses. Most sites cross at
least one range boundary (some have three), and the ranges seem to vary
by site. Unfortunately it means that most sites will not display all frequencies
correctly, and would not track (if I had one of the required receiver types
hooked up).

My detailed knowledge of MPT-1327 is limited. What are the system
rules regarding ranges and channel numbers? Has anyone else run into these
problems, or is this system more of an anomoly? Could this capability be
added to a future release?

It's a good tool, and I'm happy to have it (considering the price)!

Dave

[morfis]

There is no need for an "offset" and it usually causes more confusion than help if it's put in there.

MPT1327 sites use one base frequency. If it appears that there should be more than one on a site then it must be using a custom channel plan.

[DaveH]

Originally Posted by morfis

There is no need for an "offset" and it usually causes more confusion than help if it's put in there.

MPT1327 sites use one base frequency. If it appears that there should be more than one on a site then it must be using a custom channel plan.

I guess the systems you are familiar with use a single base/offset, but the one
here needs several per site, so the protocol must support it. Outputs are spread
between 451-455 and 460-464 and with stepsize 6.25kHz multiple bases are
needed to support this frequency range. Apart from that, the multiple bases
different by only a channel or two appear to be an attempt to thwart anyone
from tracking the system.

Tronquito supported setting an offset, but only a single range, and rounded
off the 6.25kHz step to 6.2kHz so created a cumulative frequency error.

Dave

[Jay911]

DaveH:

It seems there are two sets of rules for MPT1327: That which is standard for the UK and other EU countries, where most of the programmers of things like Trunkview reside, and another for the US and Canada. The UK/EU folks will insist that there is only the UK/EU standard and nothing else exists, but the US/Canada situation is vastly different.

There is no 'offset' in an MPT system, but at the same time, the lowest frequency your trunking system uses is not necessarily the base. I have an MPT1327 system locally which uses freqs in the 422-424 range, and its base is 420.0000. To make matters worse, there is no set channel plan for MPT like there is for Motorola trunking systems. In the system I hint at above, ch 333 is 424.1625, ch 341 is 424.2625, and 361 is 424.5125. However, another local system also on 400mhz channels uses a completely different channel plan with differing spacing and base. This singular issue is most of the reason that tracking an MPT system here is so awkward.

Does the control channel on the site(s) you are monitoring on TimeTrac move during the day? If so, you may be able to figure out the proper base by doing a little math. It's how I figured out the second MPT system I mention above. Watch for a "MOVE" command on a known control channel and see what it thinks it is, compared to where the control channel actually goes. I can give a more detailed description in a PM or other method if need be. Another easy way is to listen to a voice channel for the little squawk that happens after the voice transmission ends - Trunkview will report that as a "Return to control channel xxx" message. If you know what the actual control channel is at that time, you can identify its channel number by that, and start figuring out what your step rate and base should be.

Another thing you'll find here that the European users are, to the best of my knowledge, not experiencing, is the re-use of system IDs. You'll notice on your TimeTrac system that you have at least two sites broadcasting 40A9. As someone who is most used to Motorola systems, I am baffled at how this functions properly - there are two systems here that broadcast 2309, and are in the same band; I can't imagine how the radio behaves when it latches on to the control channel for the system it's "not" supposed to be on. Maybe this never occurs for some reason that's beyond my understanding. In any case, it makes it a little difficult to keep track of which group IDs/radio IDs belong to which system, if they're not shared. Hopefully, yours are.

I've done a lot of kicking around with MPT1327, Trunkview, and Unitrunker (which now supports MPT) in the past few years. If any of this helps, and/or I can offer anything more, please let me know.

[DaveH]

Thanks for the insight Jay. Control channels do not move on sites with
one exception, and it only jumps between two on rare occasions. I have
no trouble getting all the channel numbers including CC. Channel numbering
follows a linear pattern in some cases, with discontinuities which amount
to three base/offset sets per site, and more than six across the whole
system, so I don't know what the limits are. It's similar to Moto VHF/UHF
systems. I think you'll find your systems can be similarly mapped out.

Duplicate site IDs confuses Trunkview but it allows selecting the correct
site; neighbour site CC channel numbers get screwed up though.

I discovered the VC "return to control channel" message by accident and
it confirms the CC channel number.

The offset in a single-base system has some relevence in that any
channel below it can't or shouldn't be assigned. The author of Tronquito
stated that offset 1 is common (for whatever reason). Take base 451.0000
and offset 1, which could also be set as base 450.99375 offset 0 using step
6.25kHz. Channel 0 should never be used in this case.

So, Morfis is right in his way but we also in our own way...

Dave

[morfis]

Originally Posted by DaveH

I guess the systems you are familiar with use a single base/offset, but the one
here needs several per site, so the protocol must support it. Outputs are spread
between 451-455 and 460-464 and with stepsize 6.25kHz multiple bases are
needed to support this frequency range. Apart from that, the multiple bases
different by only a channel or two appear to be an attempt to thwart anyone
from tracking the system.

Tronquito supported setting an offset, but only a single range, and rounded
off the 6.25kHz step to 6.2kHz so created a cumulative frequency error.

Dave

Hi Dave,

I'm sure there are subtle variations in the implementation around the world BUT a single site (any given single SysID within one system if you like) can only have one base freq or it isn't MPT1327.
The easiest way to support a huge frequency range in quite distinct blocks would be to have a custom channel plan. There are systems here with custom plans but they don't encompass different frequency ranges like yours appears to be doing.

Re-use of SysIDs is probably more common in the UK than elsewhere but they are rarely used within the same band locally to each other. There is no real reason why they couldn't be as each change of frequency is commanded by channel number (be it on a custom plan or plan based on a "base" and "step").

The "offset" in Tronquito was a bit of a misnomer. For most systems the offset was "2"...and in the source code the channel numbers can be seen to be "channel number + offset - 2". ie. the offset is zero - it isn't needed and I suspect was a legacy of decoding things like Smartnet. Another theory is that it was to keep round numbers for the base frequency!

Also note that on a site that doesn't use roving control channels the "return to control channel xxx" command need not contain the true channel number - the radios can be set to automatically return to a different frequency (confused a lot of people trying to monitor one of the nets at Ringway Airport with TrunkView)

Whatever the situation with your net/s please keep us informed as it's interesting to see how other systems are being implemented.

[DaveH]

So the legacy MPT-1327 doesn't use "offsets", but for this system
I've found 10 base/offsets that describe the channel mapping. One
or two might "collapse" into others (I am missing some channel
numbers). No more than 3 sets are used per site. Exact boundaries
are not known, just like blind-mapping of a VHF/UHF Moto system
with finite number of actual channel numbers available.

Dave

[SKEYGEN]

[edited out by me - redundant post ]

[morfis]

Originally Posted by DaveH

So the legacy MPT-1327 doesn't use "offsets", but for this system
I've found 10 base/offsets that describe the channel mapping. One
or two might "collapse" into others (I am missing some channel
numbers). No more than 3 sets are used per site. Exact boundaries
are not known, just like blind-mapping of a VHF/UHF Moto system
with finite number of actual channel numbers available.

Dave

Indeed...a custom channel plan. There is no base/offset. Custom channel plans are fairly rare around Europe.

[SKEYGEN]

Originally Posted by DaveH

I guess the systems you are familiar with use a single base/offset, but the one
here needs several per site, so the protocol must support it.

Yep. Simoco SRM9000 radios support up to fifty bases/offsets.

[morfis]

Originally Posted by SKEYGEN

Yep. Simoco SRM9000 radios support up to fifty bases/offsets.

Yes, it's what allows sites to use a "custom channel plan"

[Comint]

Originally Posted by SKEYGEN

Yep. Simoco SRM9000 radios support up to fifty bases/offsets.

I don't suppose there is a readily available manual around, that explains all that.