[App_rpt-users] Batwing Systel conversion Success! (LONG)
Bryan D. Boyle
bdboyle at bdboyle.com
Sun Jun 9 15:04:48 EDT 2013
Well, thanks to a trade with a fellow participant (KC2VRJ, thanks Paul!)
I am working with a Motorola Systel SE stand-alone repeater on the 440
band. For those unfamiliar with this box, it's a stand alone repeater,
meant for local (real local) usage; it's 2 gutted GP300 HTs, a mobile
duplexer, and control board in a single box, meant for interfacing to a
phone line for autopatch, and is basically a plug-and-play solution for
campgrounds, amusement parks, etc. in the Low Power Industrial band
right above our 440 allotment.
Programmed the radios with the proper RSS, and with the onboard
controller into a dummy load, confirmed the thing works before smoking
rosin and flowing solder.
Problem is...it works well, but it IS a stand-alone device. No ID, real
easy to bring up autopatch (a "*" character forces phone off hook..."#"
goes on-hook), and meant for true appliance operators
So, simplistically, the question becomes how to use the radios in the
box for what they are, some of the circuitry (COR, RX Out, TX audio In,
PTT) while bypassing the controller in the box.
Turns out it was simpler than can be imagined.
What I thought would work was two things:
1. Prevent the internal controller from seeing a valid COR signal, and
redirecting (or using the other active HI signal, CTCSS detect, which
would work since our local Coord folks require some access method
besides carrier, so, CTCSS will be sufficient) that signal or using the
PL detect as a "COR" for the URI. Breaking the circuit for both would
essentially disable the on-board controller from ever seeing a valid
signal. So, yeah, it just sits there munching on electrons from the
2. Inject non-processed mic level audio to the transmit side as close to
the xmt brick as possible.
It should be noted that I'm depending on the radios themselves to do the
CTCSS detection (and raising a signal on one of the lines) as well as
the de/pre-emphasis which simplifies the processing in the app_rpt
application. And, with 6 nodes running on a 1.5gig Althon
mini-tower...need to preserve some processing headroom.
Anyway, turns out it's simpler than can be imagined. Just had to think
about what I was looking at (and buying a magnifying work light...darn
57-year-old presbyopic eyes...). The modifications I made can be turned
back (didn't cut any traces) or used with a TPDT switch to re-enable the
signals to re-work with the onboard if the box is going to be used as a
low-power portable repeater.
It should be noted that, along with the circuit changes I made, I also
built a couple of chassis-mount N Female to BNC jumpers with RG-142 to
bring both RF signals out to the rear panel. This lets me us one of my
higher-power duplexers (I have both a Decibel Prods and a Kathrein that
are good up to about 100W vice the low-power one that was onboard...),
add an amp on the xmt side, or preselectors and AR or Chip's amp on the
So...circuitry changes to the "SRTP Phone Patch/Control Board" (and this
references the SRTP schematic on page 39 of the service manual)
1. I lifted ONE leg of R73, which feeds from pin 4 of jack P3 to the
base of Q10, and is in the Carrier Detect signal path.
2. I lifted ONE leg of R74, which feeds from pin 5 of jack P3 to the
base of Q12, and is in the PL/DPL Detect signal path.
3. I lifted ONE leg of R107, which feeds from the wiper of the repeat
audio level pot to the xmt brick.
4. I lifted ONE leg of R106, which feeds from the wiper of the telco
line audio level pot to the xmt brick
(essentially a mixing circuit, the back sides of both these resistors
are common and then feed to an isolation amp to the xmt brick.
Those are the ONLY circuit changes I made on board. Remember, the less
you change things, the fewer variables you have to work with.
So...where to pick up the signals I wanted to use to interface to the
URI. Well, the URI has AC coupling caps on the AC side, so, normal Moto
practice is to have biasing on audio lines. So first thing is to use
the AC coupled audio paths on both sides.
Second, using a digital meter, with the radio properly programmed, and
receiving a valid signal with the proper CTCSS code, I verified that the
signal went in the right direction so I could configure the sense in
So...used a couple hunks of belden 8451 (1pr shielded) left over from a
radio studio project, and divided up the two lines to receive and
transmit paths. Tied the shields together at one end (the URI end, if
it must be known...:)) and hooked up the leads as follows:
1. RX audio from a test point on the circuit board labeled "RX IN". Big
test pad. Easy to find. Easier to get to.
2. COR signal, active low, from Pin 5 (PL/DPL Detect) on socket P3 at
the rear left of the board (front towards you).
3. Transmit audio from the URI to the radio to pin 10 on socket P4
(labeled TX+ on schematic) at rear right of the board.
4. PTT (active Low) to pin 7 on socket P4 at rear right of the board.
5. Ground to the ground connector in the center of the rear edge of the
Connection of the DB-25 is as normal for these signals, and is left as
an exercise to figure out which ones (hint...Pin 1 is PTT, etc...)
Configuration of the usbradio.conf file, that worked for me (remember,
the radios themselves are doing the ctcss and pre/de-emphasis, so, don't
need to do it in app_rpt); if there are things I don't need
here...well..that's ok...it works, so, still fiddling with it...
Hooked it all up, URI is blinking...and ran radio-tune-menu while
watching on my shack CE6 service monitor to set the levels.
What worked for me, in my config, and yours may be different, is
RX voice is set at 600 (1K @3kc deviation from the SM to give 3k
indication on the screen display)
TX voice is set at 300 (generating internal to the tune program 1K
signal to show 3K deviation on the CE6)
and that's it (rest of the options are not enabled due to the usbradio
configuration). Remember, not depending on the software to do any of the
processing, just routing plain audio around and seeing that the pin
Modifications to rpt.conf are dependent on what you want it to do. But,
it works just fine with most of the standard config I use on other
repeaters on my hub.
So...hope this helps someone somewhere along the line. Only change I'm
thinking of adding in is putting in a switch to re-connect the lifted
legs of the resistors back to their connection pads so I can disconnect
this from the URI and throw in my car with the mobile duplexer and take
it on the road. But for now...it is working (node 27710) at low power
(about 2 mile radius, low antenna), and sounds pretty good.
More information about the App_rpt-users