Dispatcher handling multi-mode incoming calls

This forum is for discussions regarding System Infrastructure and Related Equipment. This includes but is not limited to repeaters, base stations, consoles, voters, Voice over IP, system design and implementation, and other related topics.

Moderator: Queue Moderator

Post Reply
User avatar
judoka
Posts: 46
Joined: Thu Oct 27, 2005 4:37 pm

Dispatcher handling multi-mode incoming calls

Post by judoka »

Our dispatcher is handling multiple calls at a time interleaving requests from the field and responses with task allocations. The requests can be analog or P25. What is the best way to set up the dispatch interface to distinguish between replies (must be in same mode as request) and first calls (need to be in the best mode to reach recipient) ?

We have toyed with a timer (any PTT by dispatch within timeout treated as a reply and in tx in same mode as last incoming call) but nobody really likes that.

Anybody got experience, good ideas ?
User avatar
commtek
Batboard $upporter
Posts: 176
Joined: Thu May 08, 2003 6:14 pm

Post by commtek »

Not trying to be a smart a**, but either your dispatchers need to learn to multi task, or you need more dispatchers. I have never heard of this, or the need for this in any of the dispatch centers we maintain, or I have been associated with.
/\/\y 2 cents
On Moderation
Posts: 851
Joined: Sun Nov 11, 2001 4:00 pm
What radios do you own?: iPhone, Blackberry, HT220

Post by /\/\y 2 cents »

Well all they have to do is be able to distinguish with their own ear, whether or not the call came in in P25 or analog. Any trained ear should be able to tell right away since P25 sounds like R2D2 and talking to someone while scuba diving and analog sounds nice and clean. This will give them a cue on which mode to TX back to the RX'd call in. If they work enough hours and have enough exposure they should be able to figure that out in less than 30 minutes. They will get the hang of it. Adapt or die right?
User avatar
nmfire10
Batboard $upporter
Posts: 4109
Joined: Sat Jun 29, 2002 4:41 pm

Post by nmfire10 »

Of course you could use a light or indicator on the console to indicate what mode it is currently RX'ing in. But when was the last time you saw a dispatcher staring at the console screen everytime the radio talked. It isn't practical.
"I'll eat you like a plate of bacon and eggs in the morning. "
- Some loser on rr.com

eBay at it's finest:
Me: "What exactly is a 900Mhz UHF CB?"
Them: "A very nice CB at 900Mhz speed!"

:-?
ASTROMODAT
Posts: 1825
Joined: Tue Nov 05, 2002 12:32 am

Post by ASTROMODAT »

The dispatchers certainly don't need trained ears, etc. and they do not need to be able to recognize IMBE versus analog FM.

The DIU-3000 can be very easily programmed to operate in the slaved mode. In this mode, it auto tracks the dispatcher's outbound call to match the mode of the last incoming call. For example, if the incoming call is in the FM mode, when the dispatcher keys up to respond to this incoming FM call, she will automatically transmit in the FM mode. Alternatively, if the incoming transmission comes in as IMBE mode, then when the dispatcher hits her PTT she will automatically transmit back in the IMBE mode.

The dispatchers mode will change automatically on-the-fly. This is merely one of the many ways the DIU-3000 can be programmed to operate.
User avatar
judoka
Posts: 46
Joined: Thu Oct 27, 2005 4:37 pm

Post by judoka »

Thanks for that
what I don't understand is how the DIU 3000 can tell the difference between a dispatch PTT in response to the last call and a dispatch call for some other reason
ASTROMODAT
Posts: 1825
Joined: Tue Nov 05, 2002 12:32 am

Post by ASTROMODAT »

The Quantar receiver's output signal is input to the DIU. The DIU can easily recognize an analog FM signal versus a digital IMBE stream, and it accordingly assigns the dispatcher's next key-up by automatically mode matching that particular last transmission (e.g., the most recent one).

The DIU could care less from whom or where the last transmission may have come from. The DIU only knows that it is programmed (in this particular scenario/case) to automatically mode slave match the nature of the mode of the last transmission delivered to it via the Quantar receiver.

The output of the Quantar receiver is delivered to the input of the DIU directly via a V.24 connection if the Quantar and DIU are essentially co-located (e.g., must be within 100 feet or so), or via a private line (of virtully unlimited distance) using an ASTRO modem at each end in cases where the Quantar is physically in a remote location from the DIU.

In those cases where the dispatcher is initiating a call that may be unrelated to any particular last transmission received, the DIU can be programmed to: 1) transmit in the mode last used until changed for some reason, or 2) follow the mode as manually selected by the dispatcher, or a combination of both. This last programming option (e.g., both) is what is normally (not always) programmed into most DIU's. This way, the dipatcher's transmission mode is normally slave tracked to match the mode of the last received call, but she can decide to select either FM or IMBE for a dispatcher initiated call by simply selecting the mode on her console or any standard but appropriately equipped EIA Tone Remote Desk Set (which instructs the DIU) on an on-the-fly basis. The dispatcher can, of course, choose to manually override the auto track slave mode DIU decsion at any time she may want to, on an as needed/on-the-fly basis.

There are a zillion+ ways to program a DIU-3000 to mode behave, and there are pages and pages in the CSS that support any possible situation your little heart may desire as to the nature of the outbound mode selection, both for the FM/IMBE mode, the clear/coded mode, and a ton of other mode options.
User avatar
xmo
Moderator
Posts: 2549
Joined: Fri Oct 12, 2001 4:00 pm

Post by xmo »

For this situation I think I would have two BIM's in the CEB.

The first BIM would hook up to the DIU through an ACIM and be used for digital traffic. The second BIM would be for analog traffic and would be parallel connected to the DIU's tone remote input.

The two BIM's would be programmed for cross-busy and cross-mute. I would connect the unsquelch and mode indicate lines from the DIU through custom configured I/O cards to drive the COR indication and high speed mute for each BIM.

That way incoming digital traffic would come from only the digital resource icon and analog from the other.

The Centracom activity log will tell the dispatcher which resource has had the most recent activity in case the dispatcher is unable to look at the screen when the call comes in.

Otherwise the station's resource icon has to be programmed with controls for switching the transmit mode to auto, digital, or analog as needed - not as dispatcher friendly.
ASTROMODAT
Posts: 1825
Joined: Tue Nov 05, 2002 12:32 am

Post by ASTROMODAT »

Why so complicated a solution, xmo? In the military, we were taught that if we saw a horse with stripes, the initial operational assumption should be to assume it is probably a Zebra, and adjust action(s) from there, if and as needed. The KISS principle, if you will.

Why wouldn't the simple programming of the DIU to be mode slaved, with manual override, not work perfectly fine for 95%+ of the cases?
User avatar
xmo
Moderator
Posts: 2549
Joined: Fri Oct 12, 2001 4:00 pm

Post by xmo »

A small investment of $ and/or effort up front will make the dispatcher's job easier for years. This way you have instant transmit for analog, instant transmit for digital, never a confusion about which mode an incoming signal is, and never get out of step and answer back on auto in the wrong mode.

I have worked on public safety dispatch systems for years and I never cease to be amazed at what some dispatchers have to put up with because the installers have no imagination.
User avatar
wavetar
Administrator
Posts: 7340
Joined: Sun Sep 09, 2001 4:00 pm

Post by wavetar »

xmo wrote: I have worked on public safety dispatch systems for years and I never cease to be amazed at what some dispatchers have to put up with because the installers have no imagination.
Or possibly a lack of money. How much does the extra BIM, ACIM & I/O cards cost? T'ain't cheap. Aside from that, I like your resolution to the problem.

Todd
No trees were harmed in the posting of this message...however an extraordinarily large number of electrons were horribly inconvenienced.

Welcome to the /\/\achine.
User avatar
nmfire10
Batboard $upporter
Posts: 4109
Joined: Sat Jun 29, 2002 4:41 pm

Post by nmfire10 »

From the perspective of a dispatcher and a field unit, any system designed to require the regular and normal use of mixed-mode is incredibly stupid.
"I'll eat you like a plate of bacon and eggs in the morning. "
- Some loser on rr.com

eBay at it's finest:
Me: "What exactly is a 900Mhz UHF CB?"
Them: "A very nice CB at 900Mhz speed!"

:-?
User avatar
xmo
Moderator
Posts: 2549
Joined: Fri Oct 12, 2001 4:00 pm

Post by xmo »

"... How much does the extra BIM, ACIM & I/O cards cost? ..."
____________________________________________________

I was assuming the station was already set up with an ACIM for mixed mode. A second ACIM would not be necessary for the analog side. Actually, no ACIM is required if you don't want the Astro signalling capabilities - but that's wasting a great opportunity to have PTT-ID, emergency buttons, status, message & so-on.

So... bottom line: one more BIM & 1 I/O + programming = maybe $2Kus.
ASTROMODAT
Posts: 1825
Joined: Tue Nov 05, 2002 12:32 am

Post by ASTROMODAT »

xmo wrote:This way you have instant transmit for analog, instant transmit for digital, never a confusion about which mode an incoming signal is, and never get out of step and answer back on auto in the wrong mode.
I'm probably being incredibly obtuse here (wouldn't be the first time, nor the last!), but I just don't see how the KISS approach of programming the DIU to INSTANATLY auto track the incoming mode could work incorrectly, or be confusing, etc. Seems extremely simple, and bulletproof.

In the extremely unlikely and very, very rare case(s) where someone comes in via one mode, but the dispatcher wants to answer back in the opposite mode (I can't imagine why!), it is trivially simple for the dispatcher to simply hit the FM or Digital P25 big huge button (as she desires) on the console, and have at it.

What am I missing here? Just curious...
mastr
Posts: 262
Joined: Mon Jan 13, 2003 9:12 am

Post by mastr »

Enable mixed mode RX on the subscriber units and dispatch in analog. When all of your old analog only stuff is gone, then go to Astro for console TX. I cannot think of any reason I would want to do Astro & analog TX from dispatch on a single frequency, it just creates a potential for confusion.
ASTROMODAT
Posts: 1825
Joined: Tue Nov 05, 2002 12:32 am

Post by ASTROMODAT »

I agree that a flash cutover to P25 is the best way to go. In the end, this mixed mode stuff doesn't save money. Mixed mode just prolongs the inevitable before the old analog FM dinasaur needs to be killed off anyways.
Post Reply

Return to “Base Stations, Repeaters, General Infrastructure”