Dispatcher handling multi-mode incoming calls
Moderator: Queue Moderator
Dispatcher handling multi-mode incoming calls
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 ?
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 ?
-
- On Moderation
- Posts: 851
- Joined: Sun Nov 11, 2001 4:00 pm
- What radios do you own?: iPhone, Blackberry, HT220
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?
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!"
- 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!"
-
- Posts: 1825
- Joined: Tue Nov 05, 2002 12:32 am
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.
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.
-
- Posts: 1825
- Joined: Tue Nov 05, 2002 12:32 am
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.
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.
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.
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.
-
- Posts: 1825
- Joined: Tue Nov 05, 2002 12:32 am
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?
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?
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.
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.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.
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.
Welcome to the /\/\achine.
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!"
- 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!"
"... 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.
____________________________________________________
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.
-
- Posts: 1825
- Joined: Tue Nov 05, 2002 12:32 am
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.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.
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...
-
- Posts: 1825
- Joined: Tue Nov 05, 2002 12:32 am