Reviving a Motorola Type II trunked radio system

Keith Herbert (KJ7BZC) - last updated 11/08/2022


The intention in this project is to get an original Motorola Smartnet/Smartworks controller up and running again, having radios affiliate and operate just as they would on a real system. This page will act as a log of my findings, and a place for me to share this project with others. I am trying to do this for a few different reasons. I have always been interested in trunked systems since I started getting into commercial radio equipment. The same day I got my first Motorola radio (an HT1000) I was also given a bunch of old 800mhz radios from my uncle as he was working at a local two-way company at the time. I was allowed to use one of the old talkgroups that was no longer in use as long as the system was still up, I learned a lot about how these types of systems worked from it. That went away about 3 years back (08/08/2019) when the system went into failsoft and subsequently was decomissioned, all these 800 radios I had went unused from that point on. My intention is to get my own controller up and running, and experiment with this type of trunking again. I also want to do it to preserve what is (at least to me) an important piece of history in terms of commercial radio systems.


Initial Status And Findings

So far, I've got a lot of progress. A while ago I purchased a 6809-based controller on Ebay and it has arrived. I have cleaned it up a bit, and got it powered by a HP 6623A power supply. From what I can tell so far, it is fully functioning like it should be. I have connected to the CSC terminal interface and learned how to use most the commands. I have also dumped all the EPROMs on all the cards for backup purposes. One of the things I'll have to do eventually is to reverse engineer the data stored in the U48 EPROM, that is the one that stores the channel assignments, connect tone, station id, and a few other important parameters. Based on the system ID (173F according to the CSC terminal), the string "City Of Decatur" in the U48 EPROM, and the seller I got it from stating it was from Illinois, the closest matching system is the Decatur Macon County Public Safety system. Though its not a perfect line-up, as that site has 8 frequencies, and my controller can only handle 7 channels total with the cards it has installed. Maybe this controller was used even before that record existed on Radioreference and they had something else in place? I don't know for sure, but that's the closest matching one.

Speaking of cards, here's what the slots are labelled, from left to right:
TCI | ACB 1 | ACB 1 | CSC | RSC | IRB | RIB 1 | TSC | TIB 1 | MCB | MATRIX | PLIB 1 | TRIB 1

The cards present when I got it were the TCI, ACB 1 (on the left), CSC, RSC, IRB, RIB 1, TSC, and TIB 1. I have since purchased the MATRIX card and installed it. Based on an instruction manual I had obtained prior to getting the controller (which also includes schematics!), replies on a YouTube Video I posted on it, and looking at pictures of them online, I have determined the purposes of the cards as below:

TCI - Trunked Console Interface, connects to a remote Centracom console, and communicates with the RSC/CSC to emulate calls
ACB 1 - Asynchronous Control Board, it basically just has a bunch of RS232 ports on it that are used by other cards like the TCI
CSC - Central Site Controller, manages the main site functions and is pretty much the main processor
RSC - Receiver Site Controller, handles inbound requests from mobiles, and passes them on to the CSC
IRB - Inbound Recovery Board, demodulates and stores RECC packets into memory
RIB 1 - Receiver Interface Board, interfaces to receivers (duh)
TSC - Transmitter Site Controller, controls the transmitters, and handles connect/disconnect signals on voice channels
TIB 1 - Transmitter Interface Board, interfaces to transmitters (duh again)
MCB - Master Control Board, seems to generally interconnect the CSC with the other boards for phone line interconnect
MATRIX - Big ass array of crosspoint switch ICs, likely just used to route audio between various boards
PLIB 1 - Phone Line Interconnect Board, connects to telco lines and allows mobiles to make phone calls through the trunked system
TRIB 1 - Not sure exactly what it stands for, but it has to do with the phone line interconnect


I have traced and determined the pinout of the main molex power connector. Assuming the notch on the connector is facing downwards, and the pins are numbered like this:

1 2 3
4 5 6

Here is the pinout:
1: +12.10v
2: Ground
3: +5.15v
4: -12.10v
5: Ground
6: +5.15v


There is also a convenient two-position molex connector that provides +5v and ground connections.
In terms of the two 12v rails, 0.5 amps is fine. The 5v rail however has been drawing a terrifying 8.85 amps continuous from my power supply. I have had to increase my supply's voltage for this rail because of the voltage drop. This current varies greatly depending on the number of cards installed, I suggest you start at 5.15v, and increase it in very small increments until all the "site controller" cards have a steady RUN light, indicating the processor is operating correctly.

The manual mentions the pinouts of the repeater DB-15 connections, I will list them here:
01: Receiver status input
02: Receiver return (ground)
03: IRB ground
04: Not used
05: Not used
06: Transmitter push to talk
07: Transmitter return (ground)
08: Transmitter data - (ground)
09: Receiver ground
10: Receiver discriminator input
11: IRB test (possible CC indicator?)
12: Not used
13: Transmitter mute
14: Transmitter data + (audio out)
15: Transmitter status input


This system was meant to be connected directly to Quantar and MSF5000 repeaters, but it is actually possible to use any radios for it assuming they have the required signals, and you can provide some extra components to interface them. With the kind help of Jim G on YouTube, who showed me how the transmitter status line worked, I have successfully interfaced a pair of GM300s to this controller. While those are absolutely not the best choice of radios for the transmit side, they work beautifully for receive. I am looking for a low power CDM radio or something else for my transmit, testing with GM300s is hard because they heat up fast and are definitely not meant for constant transmit. Even with my scary Pamotor fans blasting the heatsink on it, I still can only get a short amount of transmit time for the control channel before they heat up past my comfort zone.

Anyways, the connections are very simple. All the digital outputs on the repeater interface are open-collector, 1k pullup resistors to +5 work fine for that. So when I refer to an output being high, I mean the output's optocoupler is not active, and the pullup resistor is "driving" it high. All the input signals are optocouplers, they are easily connected, the controller has current limiting resistors built in for them already. Connect pins 2, 7, 8, and 9 to ground. Connect pin 1 to pin 6 through an inverter, such as a CD4069UBE. Connect pin 6 to your transmitting radio's active-low PTT line, with an appropriate pullup resistor if needed. Connect the flat RX audio line from your receiver to pin 10, this should be unsquelched. Connect pin 1 to your receiving radio's active-high COR line. The transmitting and receiving radio should not be configured for any form of PL or DPL, the controller does all the subaudible signalling internally. I used the PTT switch on the GM300 microphone during initial testing because of their short TX time requirement.

Now the fun part, transmitter audio! The audio from the receiver to the transmitter never passes through the controller itself. It is connected directly, with some form of "switch" in the middle, which is controlled by pin 13 of the controller. When the controller wants to let audio pass from the transmitter to receiver, it holds pin 13 low, otherwise it is high. A reed relay with an appropriate driving transistor should work fine for this purpose. Other than that, you will need to also mix in pin 14 for the data output to the transmitter, this cannot be selected by the mute line, as the controller needs to be able to send subaudible data while audio is passing. This pin outputs a TTL level data signal, and in my case actually had to be passed through an inverter to be decoded properly. This must be sent into a flat TX audio input on the transmitter for it to work.


In terms of getting a radio to talk to this controller, my APX6000 has been the test subject of choice. Even though this trunking system was originally used on 800mhz frequencies, with a bit of math and screwing with OBT configuration, it is absolutely possible to run it on VHF in the HAM bands, which is what I have been doing. Sadly you cannot simply define which frequencies the voice channels operate on, it works on a base/offset system. In 800mhz, the base frequency is 850.9875, the offset is 25khz, and the repeater input frequency is always 45mhz below the transmit. How this works, is instead of having to program all the voice channels into every single radio, it is programmed in the controller's U48 EPROM, and sent as a channel number to the radio. You would just have to enter your up to 4 control channel frequencies, and the control channel tells the radio which channel number to go to for voice. The channel number tells the radio which 25khz "slot" to use, where channel 1 is 851.0125, 2 is 851.0375, and so on incrementing by 25khz. VHF and UHF frequencies were not standardized, so you can actually enter the base frequency and the channel spacing yourself, which is what I set up. In my case, I am running it in ham bands for testing, I have configured the APX to use 146.0000 as it's base RX frequency, and 144.0000 for the TX. I have it set to 10khz channel spacing. Note that the APX's RX frequency is the controller's TX frequency.

In terms of programming the APX, it was pretty straight forward. I got lucky and the system key for my controller was included with it. Strangely the hex values were written on some documentation that came with the controller detailing configuration for the pair of Paradyne modems it had. Otherwise Batlabs could've been an alternate savior with their article on making your own key with a hex editor, though I'm not sure if that works on APX CPS. Apart from entering the system ID and those frequencies, I just set the individual ID to 700001, and setup a trunking personality for talkgroup 1. I also set the coverage type to Smartzone to get that sweet RSSI indicator on the display. The radio decoded the control channel perfectly, and affiliated with the controller extremely quickly, I'm talking like 250ms from going to the channel to it being registered on the controller. When I keyed the radio, it would repeatedly request a voice channel from the controller, and the XMIT light for that channel would come on. No talk permit tone because there was no radio connected to my voice channel, so the APX never heard the LSHS signal, and would repeatedly send the ISW requesting the channel. Nonetheless this is huge progress, next step is getting a voice channel connected.

You might think this is as simple as connecting two more radios, but it actually requires a bit more effort. I had to somehow determine the channel numbers my controller had, without having a copy of the "birth record" that Motorola prints when they program the U48 EPROM for them. Trunker to the rescue! This is a neat little software package that's been around for a long time, it effectively decodes the control channel and adds trunking capability to standard scanners, assuming you can interface with them over serial. It decodes the control channel off the CTS pin of a serial port, typically through a data slicer. I get to cheat and connect it directly to pin 14 on the controller though, which decodes perfectly. In my case, it gave me a few bits of important information. First, it confirmed that the controller was operating in standard type II mode, and that the connect tone was 97.30hz (which is important). Secondly, it gave me the frequencies for each channel, which is exactly what I needed to know. We can do some simple math to convert from frequency to channel number, and vice versa.

To get the channel number from the frequency, its f(x) = (x - 850.9875) / 0.025, where x is the frequency.
To get the frequency from a channel number, its f(x) = 850.9875 + 0.025x, where x is the channel number.

I am using channel 2 on the controller for the control channel, and channel 3 for the voice channel. Channel 1 has an issue with the optocoupler handling the transmitter status input making it sometimes show an error when there isn't one, so I will need to fix it at some point. We can substitute the offset and base to match how I programmed the APX. Channel 2 is #190, and channel 3 is #180. This translates to channel 3 being 147.8000 for tx, and 145.8000 for rx in my VHF bandplan, which works out perfectly.

Well this is where I'm stuck for now. I don't have any more VHF mobiles I can use with this, as they need to have the flat audio capability.


CSC Terminal Interface

Apart from the channel assignments and other parameters stored in the CSC's U48 EPROM, all the system parameters are set through the CSC terminal interface. This is a standard DB-25 serial connection, which can be connected straight through to a modem or to a computer with the appropriate adaptors. The interface uses 8 data bits, no parity, and 1 stop bit, the baud rate is selectable by a jumper on the CSC card.

After waiting for all the Active lights to go out on the cards, I hit RETURN and got the following prompt at the terminal:

SYSTEM 173F LOGON PLEASE:

I logged in with the default username "MASTER" and password "$MASTER$", there also is "CONTROL" and "TRUNKING" as another login. All the parameters configured on the terminal are stored in battery-backed RAM, and are reset when those batteries die or are disconnected. The menu system is very simple and easy to get used to. I have not completely figured out everything about it yet, but I will list below all the submenus and commands that I have figured out so far: