[TrunkCom] GRE folks

[Brian J Cathcart]

Todd:

What model scanner are you using?  With the status bit function "on" you
will receive all patched conversations, however not necessarily on the
talkgroup you are expecting.   Example: 57360 and 8208 are cross-patched;
you're monitoring 57360 and expect to see the conversation on 57363 but
actually it appears (on the Trunk Tracker) on 8711.  The Motorola radios,
on the other hand, hear the crosspatch on both talkgroups.  If you watch
Trunker you'll see this happen a lot - the patch is created but shows up
on only one of the talkgroups instead of both (the display log will show
you what talkgroups are patched).  The Motorola radios handle this
properly and hear the audio on both talkgroups, but the Trunk Tracker
only passes audio through to one of the talkgroups (don't know why).  I'd
be willing to bet that when the patches you describe occur, you'd find
the conversation on the "other" talkgroup it's being patched with (it
would be best to watch Trunker when this happens, that way you'd see
which talkgroup the audio is being fed to).

So, the status bit function does work, it just doesn't always show the
conversation on the talkgroup you are expecting.  In Broward County, FL,
the patches *usually* show up +3, +7, etc. but sometimes the audio is
only heard on the "other" talkgroup it's patched to.  It sounds like St.
Louis has theirs set up a little differently, however I would want to
watch Trunker for awhile to see for sure what's happening.  You might
find that when the APB goes out the conversation will appear on the same
talkgroup every time (and you might not have that one scanning).

Hope that helps,



The Scanner Dude
Brian J. Cathcart - KE4PMJ
South Florida Frequency & Trunking Guide 7th Edition
Available in both Printed and CD-ROM format


P.S. Don't be surprised if the PRO-96 does the same thing.  GRE licensed
some of the Motorola trunking features from Uniden beginning with the
PRO-93.



On Wed, 18 Jun 2003 16:32:04 -0500 "Todd Hartzel" <toddh@brick.net>
writes:
> Greetings All,
>       To the folks at GRE working on the PRO-96.  To advise
> you.   Here in St Louis, Mo the 'STATUS BIT' features don't
> exactly work in the normal manner here.   Example:
> 
> I 'HOLD' monitor District 1 & 2 (Only).(STATUS BIT mode 'ON')
> Say the 'District 1 & 2' Dispatcher goes 'All Points'.  1 & 2
> talkgroup is  57360.  So, when the 1 & 2 Dispatcher goes
> out with an APB, you'd expect that 57367 would come out
> over the data channel, right?  Well, NOT here in St Louis.
> 
> It could be any of the Dispatch talkgroups+7 (the status
> bit).  One thing I can tell you.  Even though our trunktrackers
> do not receive it correctly.  The actual system radios:
> 
> - stx-800s (most) & XTS-3000s (few)
> 
> They receive them correctly (everytime). The officer's radios
> receive all APBs correctly.  Its only our trunktrackers that
> do not.  So the 'STATUS BIT' mode on the Uniden models
> is completely useless for us in St Louis, Mo
>  
> Also, using the same example above, monitoring 1 & 2.  Dist
> 1 & 2  is quiet, not much going on (talkgroup not active).  Then
> the District 4 & 5 dispatcher goes out with an APB.  With our
> Trunktrackers, we never hear the APB from 4 & 5.  The APB
> goes out with the talkgroup ID of 57719 (which is the INFO A
> talkgroup+7)  But, at the same time.  All officers with XTS-3000 
> & STX-800 radios receive the broadcast just fine.  (Not a 
> selective APB ; we very rarely, if ever do selective APBs)
> 
> This is a very prominent problem.  Occuring 3 out of every 4 
> times, day or night, round the clock 24/7.  
> 
> Conclusion, the officers radios receive the APBs just fine.  Its
> only our Trunktrackers that do not.  Before the PRO-96 ships
> later this year, could someone from GRE investigate this matter.
> I hope the problem is not unique.  I do not consider the St Louis
> City Police Type II Motorola TRS to be that special, or differant
> from all other systems.  Obviously, the problem lies in our 
> trunktrackers, not the police radios.  Our scanners are ignoring 
> something in the Data Channel's data stream.