InterceptRadio.com Forums

As a "fair weather" scanner, I don't have the depth of knowledge or history of our local police and fire infrastructure that many of you hardcore guys have, but from my perspective it sure seems like their "MDT's" or "MDC's" (or whatever their onboard computers are called) have a whole lot of down time. It surprises me that the effected officers and firefighters act like this is normal, and no big deal. What gives?

If City Light truck radios or Comcast car to car communications failed as often as our SPD and Fire terminals, their personnel would be foaming at the mouth! I know it's only data (that's a guess) but still, why are so many terminals "not responding" so often and why aren't officers and firefighters up in arms about it?

- Silver in Ballard

Think of it as a 'dropped' call on a cell phone.

the Outlaw said:

"Think of it as a 'dropped' call on a cell phone."

Ah, I see. So do all police departments have this sort of problem? What a pain!

What exactly do you mean by "computer trouble"?

Also, AFAIK, the same towers that transmit control channel data, voice channels, etc. are transmitting the data. Valcom uses 852.7125. If their radio can't pick up the signal, then their laptop is only good for playing solitaire.

Atomic Taco - Yeah, I understand now that the data terminals use a wireless system, so of course they suffer from the same signal issues as other wireless systems, only worse because they move around in and out of good reception areas. Buses and ferries have the same issues, but because their paths are predictable, more reliable coverage can be designed into the system.

The ways in which the terminals fail seem to be inconvenient. It seems like the terminals let you know that they are "down" simply by not responding. It must be irritating not to know if it's just being slow to respond, or if it isn't going to respond at all.

Also, there seem to be lots of times when dispatch sends a message to a car's terminal, and then has to check back later to see if the message was received. Depending on the nature of the message, it sounds like this could be dangerous.

Wouldn't it be better to have some kind of error-checking in the system that does a sort of "call and response" thing where a terminal sends back a "message received" bit, and dispatch is notified if that bit is not received within a certain time period? It could even do an auto-resend until the terminal comes back into range and acknowledges having received the transmission. That way there wouldn't be this crack that messages could fall through unnoticed by the system.

I'm just thinking that I'll bet we paid a bundle for a system that sounds fairly unreliable.

If I was a police officer I would want a big-ass "OFFLINE" button to light up when my terminal was down. AND I would want the dispatcher to be able to see the same thing - that my terminal was unavailable - before trying to send a message to me. They could then choose to get the message to me in a different way.

But perhaps I'm asking too much. ;-)

The system in place is a very old system. They're trying to replace it. You can see all of the details here:
http://www.valleycom.org/News/vccrfp.asp

Just a point of clarification. The Valleycom user agencies utilize a Motorola Private DataTac system. Only Valleycom users operate on this system.

Seattle (PD and FD) utilize a secure commercial provide (Sprint, I think) to transmit CAD and mission critical info.

Not sure what the Eastside is using these days--if anything.

Interesting. Thanks for the info!

There's a bigger learning curve for us casual listeners who have never worked in the field.

Learning slowly,

- Silver in Ballard