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 power supply. 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 inbound side...). 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 asterisk properly. 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 board. 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... ;440 Repeater [usbxxxxx] hdwtype=0 rxboost=1 txboost=1 carrierfrom=usb ctcssfrom=no rxdemod=speaker txprelim=no txlibonly=no txmixa=voice txmixb=no invertptt=0 duplex=1 rxondelay=0 rxnoisefiltype=0 eeprom=0 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. 73 all Bryan WB0YLE 27294 etc.