MTS/NCTD 800 MHz digital radio system

[inigo88]

I've scanned the MTS (San Diego Transit)/NCTD digital 800 MHz frequencies off and on for a while now, and was always interested to learn more about how the system worked. Like most transit radio systems, it uses a "Request to Talk" (RTT) feature where the driver has to push a button, wait for the dispatcher to acknowledge their call request and automatically assign their radio a voice channel before they can start talking. In a sense it operates kind of like a trunking system, only with a real person in the dispatch center (not a site controller computer) responding to the call request.

The MTS and NCTD frequencies can be found here: http://www.radioreference.com/apps/db/? ... #cid-11160

I've been riding MTS a lot lately, and was really surprised to see that the drivers have no direct access to their radio. In fact the only evidence of a radio at all is an easy to miss telephone style handset hanging behind and to the left of the driver. Instead, the radio system (along with GPS Automatic Vehicle Location, farebox integration and a host of other data and messaging features) is integrated into the gray "Orbital SmartMDT" Mobile Data Terminal which hangs from the ceiling above and to the right of the driver's head.

When riding on the North County Transit "Breeze" buses I noticed the same set-up, same Orbital SmartMDT model, and same P25 NAC of 339 on their sole 800 MHz voice frequency.

It turns out that back in 2003 MTS and NCTD teamed up and contracted with Motorola (who in turn hired Orbital and other companies) to build an integrated GPS, data and countywide simulcast voice communications system called the "Regional Transportation Management System" (RTMS). MTS and NCTD still operate on separate frequencies (and I believe separate dispatch centers - NCTD still IDs as "Control 2"), but the combined RTMS effort explains why they share the same NAC and use identical Orbital SmartMDT equipment (and the same digital protocol on their MDT frequencies).

http://sandiegohealth.org/sandag/sandag ... 8_9290.pdf
http://www.orbital.com/NewsInfo/release.asp?prid=437

That explains why things are the way they are, but I was still curious how exactly the radio system aspect of the integrated MDTs worked.

I was able to find this photo of the same Orbital SmartMDT model (this one taken from AC tranist in Alameda County):



and I was also able to find a closeup of the unit itself from an eBay auction:



Operation of the integrated radio system looks to be extremely simple. The driver doesn't select the channel they talk on. They simply pick up the telephone handset and push one of two buttons on the MDT. The two buttons on the top right of the unit say "RTT" and "PRTT", which stand for "Request to Talk" and "Priority Request to Talk" respectively. This likely sends a signal to put the driver's call request into a waiting queue in the dispatch center CAD, and likely sounds a talk permit tone when the dispatcher answers the call (since usually the driver just starts talking).

Even though MTS has four available conventional frequencies for voice (plus the fifth MDT frequency), there's no real way to label them since each "Request To Talk" call is automatically assigned an available voice frequency when it's answered by the dispatcher. In essence there's a pool of voice frequencies (like on a trunked system) and each transmission on the system is like a private-call on between the driver and the dispatcher. I also heard one of the MTS dispatchers mention today that they have 90 seconds to carry out the call before it times out and gets dropped, and the voice frequency goes back into the pool. So for one call they had to RTT twice. Since the radio system control is integrated into the MDT, I wouldn't be surprised if there's an ASTRO Spectra or XTL5000 hidden in the equipment cabinet behind the driver that's being controlled via data cable from the Orbital SmartMDT unit - which tells it which voice channel to switch to when it gets the channel grant over the MDT frequency.

I'm curious what kind of MDT signalling protocol they use - whether it's proprietary to the Orbital SmartMDT or more common (I believe San Francisco Muni and AC Transit use the same format, but AC Transit has the same model MDT and SF might too). I wonder if the packets are encrypted?

Anyway, this is probably not that interesting to 99% of you, but it cleared up the mystery for me of how the system works.

[Mike_G_D]

Actually I found your info interesting - I monitor the single NCTD voice frequency typically (it sometimes can be humorous). I don't usually monitor MTS as I don't get down south much these days but have seen the brief mentions of the "RTT" feature in the RR database and have often wondered what that really meant. Your info clears that up so thanks! One thing I am wondering - I am assuming that the bus drivers have a PTT switch on the telephone style handset to switch between transmit and receive? Otherwise, they either would have to have a full duplex system (unlikely) or some form of voice activation.

I have noticed on the NCTD channel that the drivers will often try to interrupt the dispatcher (as if they think that they are on a normal telephone and are unfamiliar with standard two way radio simplex/semi-duplex PTT operation). What you hear is the dispatcher trying to explain something to the driver but when he/she finishes you hear the driver already in midstream/mid sentence in reply (obviously the driver attempted to talk back to the dispatcher before the dispatcher was finished transmitting)! In many cases this goes on for awhile forcing the dispatcher to keep trying to repeat his/her info and getting more and more frustrated until finally getting the driver to stop keying up before the dispatcher finishes talking!

-Mike

[inigo88]

Haha I have noticed the exact same issues. I do believe there's a PTT button on the telephone handset. One thing I've noticed lately on the MTS frequencies is if the driver starts talking while the dispatcher is still transmitting, you can hear them in the background coming out the speaker at the dispatcher's console. (This usually results in the dispatcher sighing in annoyance and unkeying haha.) So the driver can key up the input as the dispatcher is talking on the output and the dispatcher can still hear them, but it isn't really full-duplex because once the driver hits the PTT they can't hear the dispatcher anymore. If both try and key up at once, the dispatcher takes priority (like most radio systems).

[Mike_G_D]

From what you are describing that sounds like the dispatcher has full duplex capability - that's very common on dispatcher systems with linked remote receiver(s)/transmitter(s)/repeater(s) sites (from a listener's standpoint it is indistinguishable from a simple repeater system - except for the dispatcher full duplex capability). The CHP does this and I have heard the same thing from the SDG&E 900MHz radio systems (can hear the field unit's audio over the dispatcher's speaker in the background if the dispatcher is still transmitting while the field unit is transmitting).

However, I don't recall hearing it on the NCTD single voice channel system. I may have, just can't recall it in recent memory. It may be possible that the NCTD dispatcher has more limited equipment than what the MTS folks use - NCTD may just have a standard radio base station at the dispatch center rather than a remotely linked (via T1, microwave, whatever) console as MTS obviously have. Given the greater volume of traffic that MTS must contend with that may make sense as a cost savings for NCTD with less traffic. I say this because from what I have heard on the NCTD channel, when the issue occurs of the driver breaking in too early during the dispatcher's transmission, it doesn't seem like the dispatcher notices it until after he unkeys - if he had true full duplex at his station he would do as you describe and stop talking (and likely "sigh" alot!;-) to listen, if with some degree of exasperation, to the driver's interruption. I'll have to pay more attention in future - of course, their equipment can be upgraded so things can change and easily could have already changed.

I think telephone style handsets tend to encourage this sort of behavior in the non-radio savvy users (I would assume, in this case, most drivers are non-radio savvy at least when initially hired). However, based on some stuff I have heard, I can also understand why they prefer those handsets (over standard handheld microphone) in order to keep the passengers from overhearing the dispatcher's responses as they sometimes have to tell the driver stuff that the passengers might "get upitty" about in some situations.

What I think would help if this is a significant problem for them (drivers prematurely interrupting the dispatchers' radio transmission) is a loud "busy bonk" tone in the earpiece of the driver whenever he/she tries to interrupt the dispatcher! This should quell the bad behavior within a short time and should be quite doable technically. I can see two reasons that they may be reluctant to do this, however:

1) In true emergency situations the driver may really need to transmit asap.

2) If the dispatcher system is somehow stuck on transmit either from technical issues or "operator error".

For the first issue, I would make some extra but simple step necessary to interrupt the dispatcher such as a rapid double or triple clicking of the PTT switch or a completely separate slightly offset PTT switch dedicated to emergency override transmissions.

For the second, the above could still work, of course, but to really forestall "false transmit inhibition" on the field units without user interaction it gets more complicated. Some form of detection of true voice audio from the dispatcher (in case of a dead hanging key) or else I guess the best overall bet is to simply disable the transmit inhibit remotely via a timer in the field radio which is set to disable normal transmit inhibition if the dispatcher carrier is on (with the correct NAC, of course) for a preset specified time just setting things back to what they are now. Of course, the transmit inhibit control might also be sent over the telemetry channel.

That begs a question from me: Does the telemetry system have a dedicated radio or does it share one radio with voice?

In the future, they might use TDD - "Time Division Duplex" operation which, essentially appears as full duplex to the users of digital radio systems. Modern cellphones no longer need their own antenna duplexers built in as the transceiver rapidly switches between receive and transmit in time divided fashion for incoming and outgoing voice data rather than having the unit transmit and receive simultaneously. This can operate on single frequency systems also. I don't think current P25 Phase 1 systems, such as what the MTS and NCTD systems currently use, can utilize this but I think newer Phase 2 as well as DMR TDMA systems can(?). If they were to upgrade to that type of system, the driver then could have effective "full duplex" without using a RF duplexer at his/her station.

On another note, based on what it sounds like, the buses never talk with each other (understandably, the dispatchers don't want them to and they really don't need to and the system is obviously designed to keep them from doing so) so I doubt the system is even equipped with a simplex non-repeater talk-around channel. Even if they do have that capability I doubt the drivers even know how to use it. I am guessing that the system likely has no fallback to single frequency simplex operation (for if the repeater goes down, for example) but I could be wrong, of course!

-Mike

[inigo88]

Yes it's just like a regular half-duplex system, only the dispatcher can simultaneously hear the repeater input in the headset while transmitting, and "interrupt" units on the repeater output. Most modern systems are set up this way, including trunking systems like the RCS. As for the system itself, the easiest way to think about it is like a trunking system that only does private calls (I-calls) between the user radio and the dispatch center. The user has no direct control over their radio or what channel it's on, and does everything through a very dumbed-down MDT interface. (Push Request To Talk -> Pick up telephone handset -> start talking, or if dispatcher calls you just pick up the phone.)

Searching around I found another photo of the Orbital SmartMDT, and this time you can see the screen:



If you look closely it's showing a list of mechanical problem messages the driver can select and send the dispatcher. "Hot Engine/UTC" (unable to continue) is highlighted. Below that it says "SCROLL to Msg, SELECT to Send. HOME for Main Menu."

I've also seen the drivers scroll to and send pre-selected messages on the MDT when picking up a wheelchair passenger... presumably to explain to the dispatcher why they were falling behind schedule.

I also noticed some MTS buses are missing the Orbital SmartMDT unit entirely, and have full color touchscreen "Luminator" sign control panels like the one shown below:



At first I thought maybe this unit could be both an MDT and sign controller, but after speaking to a friend I found out this wasn't the case. He explained that these new buses (with the new sign controllers) are operated by Veolia Transportation, which operates some routes on contract for MTS. Not all of Veolia's buses have been equipped with the MTS SmartMDT/Motorola radio system, and on the ones that aren't the drivers just keep in touch with the dispatch center via NEXTEL.

[inigo88]

Another interesting thing about this setup is that it's one of the only ones I'm familiar with (other than the CHP CHPERS vehicle upgrades) where the Mobile Data Terminal is an in between interface between the user and the radio(s).

But that got me thinking, the dreaded Harris (M/A-COM) OpenSky trunking system works basically the same way. It started off as an MDT data and text-messaging system designed for Fedex (called "Monarch"), which they added Voice-over-IP capability to so you could also use it as a "radio" system. It sure as heck isn't a good idea for mission-critical public safety use (Las Vegas Metro PD just finally abandoned their OpenSky system after years of struggling with Harris to get it to work). However it wasn't until learning how San Diego MTS runs their combined SmartMDT/Motorola radio system that I understood the appeal to transit agencies of having a combined mobile data and voice system.

Coincidentally, that's exactly what Orange County Transit Authority (OCTA) did, and they use one Harris OpenSky system for all their MDTs and voice communications.

http://www.radioreference.com/apps/db/?sid=5132
http://www.radioreference.com/apps/db/?sid=7178 (<- apparently they're upgrading to this one)

[Mike_G_D]

So there is only one radio for both the data and voice? Based on what you stated (plus the most likely scenario due to cost issues) I am guessing yes to that.

As for the "half duplex system" - yes, I know about the standard dispatcher "full duplex" capability, as I said, CHP and SDG&E are obvious ones but am well aware of the RCS dispatching capability (at least for the major users). As I mentioned, this is because they have linked consoles via T1, microwave, whatever to the remote transmitter/receiver/repeater/controller/whatever (depends on the type of system - conventional multi-site split receivers and transmitters, conventional repeaters, trunking, etc.). Typically, as far as I know, they do not actually have what we would call "full duplex" on-site radios at the dispatching centers; of course I would think it likely that the do have backup half-duplex radios to use (base/mobiles like the field units) in case the consoles and/or remote link system goes down which might be "patchable" into the consoles (don't know if that is the case but it certainly technically feasible though).

I still think, however, that, at least at some time, the NCTD single channel system has or, at least had, a half duplex console station because of what I noted previously - heard the dispatcher talking and when he unkeyed the driver was in mid stream already and I definitely did not hear the mobile in the background while the dispatcher was transmitting (of course, he may have been wearing headphones rather than using a speaker so that the audio could have been shielded from the mic so I don't really consider this a definitive point in either case's favor). I've heard this many times so that I don't get the feeling that the dispatcher, on the NCTD system, can hear the mobiles while transmitting OR ELSE that feature has a "on/off switch" which, for whatever reason, is/was turned off. As I mentioned also, though, I haven't paid enough attention recently so that I don't know if things are different now but that's what I heard not too long ago, at any rate. This is why I was guessing that the NCTD office might just be using a regular base/mobile radio dispatching system rather than a linked console like the (larger and more active) MTS system uses. Again, all subject to change, of course.

Thanks for the info on the MDT's - based on the conversations I have heard I was guessing they had something like that (description of mechanical failures, etc.). Like you, I do find it interesting that the MDT has control of the drivers' radio usage. It does make sense given the type of user environment in this case (bus). The CHP's system you mentioned gives FAR more control of the radio to the user, of course, for obvious reasons - pretty opposite needs, certainly, in the sense that the bus driver needs a high level of simplicity and minimal distractions for both him/her and the passengers while the CHP officer needs as much flexibility and control as possible.

I am quite ignorant of the OpenSky stuff except for what I've read on RR so I can't comment much on that - so that's what OCTA uses, huh?! Interesting. From what I can tell, it works fine for some environments (like what It was originally designed for) but, as is often the case when extra functions are tacked on after the fact, things don't always go well especially in varying and/or extreme environments (as public safety users would often face). I've seen similar types of things happen before in engineering environments (my background) with obvious marketing influence ("Yeah...sure, we can do that, no problem, right?!").

-Mike

[inigo88]

If anyone's interested I started a thread on radioreference to discuss the technical aspects of this protocol (including a sound sample) here:
http://forums.radioreference.com/trunki ... tocol.html