Orbital SmartMDT - "Transit-Trunking" Protocol

[inigo88]

Here's another MDT protocol I've been looking at recently. It's used to communicate with MDTs in buses for large mass-transit agencies. Known users include San Diego MTS, San Francisco MUNI and AC Transit (all in California).

This type of system is often called "Transit Trunked," but it isn't a real trunking protocol in the conventional sense. I believe the official name is "Request to Talk." Basically the MDT acts as an intermediary between the driver and the radio in the bus. The driver logs in and out using the MDT (which also does text messaging/AVL), and should they need to contact their dispatcher they push a "Request to Talk" button. This sends a request to talk to a queue on the dispatcher's screen, and the dispatcher can then manually assign the driver one of several temporary voice frequencies (much like voice channels on a trunked system) and answer them. They then carry out a one-on-one conversation for up to 90 seconds, after which the system automatically times out and returns that voice channel to the available pool for other calls. The end result is that none of the drivers hear other drivers talking to the dispatcher, and can't use their radios directly.

If you want to know more, I started a thread on the Orbital SmartMDT system previously (with pictures) here:
ScanDiego.com • View topic - MTS/NCTD 800 MHz digital radio system

I've uploaded a brief sound sample of what the protocol sounds like (in zip format) to this thread.

Just out of curiosity I ran UniScope on it, and was able to produce an hourglass pattern at QPSK 4800 bps.

Here it is with filtering:

And without:

The phase of the signal jitters back and forth a bit with each pulse, but it definitely appears to be QPSK 4800 bps.

Just curious if anyone is familiar with this protocol, and how difficult it might be to decode?

Downlink datastream likely includes text messaging, GPS/AVL data and some sort of channel grant and unkey messages for the operation of the "Transit-Trunked" feature.

Note that the voice channels themselves can already be monitored with conventional scanners (most are conventional analog, although San Diego MTS uses 800 MHz P25 conventional frequencies for voice). I am just curious about monitoring the MDT/data channel that controls them.

 

[SCPD]

Looks interesting. Based on your description, that would qualify as a trunking.

 

[inigo88]

This MDT-based "Request to Talk" trunking variant seems to be very widespread in the mass-transit market, but virtually nowhere else. If I recall you were investigating the OpenSky control channel a while back, and Opensky has been used by mass-transit agencies for this purpose (since it's an MDT computer network with IP-based voice, it kills both birds with one stone so to speak). Orange County Transportation Authority (OCTA) runs two OpenSky systems for their bus operations (here and here).

Some agencies are downright silly because they apparently run two layers of trunking on top of each other. In the case of Los Angeles MTA they have their own dedicated 900 MHz Type II SmartNet trunking system (here), and they also apparently use multiple 900 MHz MDT data channels to run a "Request to Talk" based MDT call queuing system on top of it! In other words driver requests to talk to dispatch via the MDT, which when answered assigns them one of the many arbitrary "Bus Operations" talkgroups (which then requires the site controller to find them a voice channel for that talkgroup). The end result is that when scanning the system there is no rhyme or reason to those bus operations talkgroups since there is an additional layer of MDT signalling controlling their usage. See what I mean by silly?
(For more on this, we were discussing this issue recently in the California forum here.)

Regarding the Orbital SmartMDT system specifically, radioreference user mlangeveld was nice enough to send me headphone audio samples of the data channels from AC Transit and San Francisco MUNI, which I've zipped and attached to this post. Comparing with my original San Diego MTS sample above, it seems that the AC Transit variant comes in periodic bursts (every 0.5 sec or so) while the SF MUNI version is more sporadic. However the overall sound of the protocol seems to be the same in all three cases, which makes sense since that same model MDT has been spotted in use by all three agencies.

My original sample "OrbitalMDT.zip" is discriminator audio, if anyone else would like to take a look at it (I'm not sure if the *.wma format compressed it however, I'll try and get *.wav samples next time).

 

[inigo88]

Some more screenshots with the newer version of Uniscope.

The Orbital signal is an on/off signal, composed of a periodic "beep beep beep" sound. This "on" state occurs with a period of about 4 times per second. The oscilloscope image alternates between a flat line for the off state and the on state shown below:

Some Impulse plots at various symbol rates. Pretty flat at 9600 bps:

At 4800 bps, the nodes where red and blue intersect appear to be at each end.

At 1200 bps, the red and blue sinusoids appear to be 180 degrees out of phase:

A cleaner decode at 1200 bps:

Now here's where it gets interesting... The data appears to be idle when the on/off state is just periodically beeping away and the sound is "clean" and crisp. The signal is in phase in this condition. The signal appears to carry data when there's a lower pitch burst on top of the usual on off beep sound. Kind of like a "chuff chuff chuff" noise in the background. I was pretty sure that since this is a Phase Shift Keying scheme, that "chuff" noise had to be the signal moving slightly out of phase. So I dialed Uniscope all the way down to 300 bps and waited for the noise. It took a couple of tries, but I finally got it:

The red and blue signals have clearly shifted phase slightly. Also at 300 bps, the red and blue signal waveforms are equivalent to the sinusoids on the oscilloscope.

I'm still not quite sure how to interpret this. Is this definitely a 300 baud protocol, since I can visibly identify the phase shift at that symbol rate? Where do we go from here?