Page 1 of 1
Phoenix as LTR Transmitter
Posted: Tue May 02, 2006 2:36 pm
by radio_05
We use low-uhf GE Phoenix S/SX's as LTR transmitters in a trunked repeater. On one channel, our transmitter failed (went noisy on TX with proper deviation), likely due to water damage. I attempted replacement with a working GE TMX1000, the trunked version of the Phoenix, low-UHF also, and working well as a voice radio.
My problem is that my "failed" transmitter will handshake fully with a mobile, however noisy the output. The replacement TMX1000 will key on frequency, and send data that will not be recognised by the mobile, regardless of polarity, with data deviation set properly (1KHz). I began with a radio modified for 9600bd packet, and later removed these mods, with no result. I wired the TMX exactly the same as the regular Phoenix, sending data through the testpoint located just below the reference frequency deviation adjust pot. I later used a coupling cap.
Any ideas? I am ready to abandon the radio and choose another transmitter. This is a legacy system to be phased out next year, so hence no new radio.
Re: Phoenix as LTR Transmitter
Posted: Tue May 02, 2006 5:36 pm
by n7maq
radio_05 wrote:We use low-uhf GE Phoenix S/SX's as LTR transmitters in a trunked repeater. On one channel, our transmitter failed (went noisy on TX with proper deviation), likely due to water damage. I attempted replacement with a working GE TMX1000, the trunked version of the Phoenix, low-UHF also, and working well as a voice radio.
My problem is that my "failed" transmitter will handshake fully with a mobile, however noisy the output. The replacement TMX1000 will key on frequency, and send data that will not be recognised by the mobile, regardless of polarity, with data deviation set properly (1KHz). I began with a radio modified for 9600bd packet, and later removed these mods, with no result. I wired the TMX exactly the same as the regular Phoenix, sending data through the testpoint located just below the reference frequency deviation adjust pot. I later used a coupling cap.
Any ideas? I am ready to abandon the radio and choose another transmitter. This is a legacy system to be phased out next year, so hence no new radio.
Is the LTR data getting inverted?
Jim.
AC coupled?
Posted: Tue May 02, 2006 6:39 pm
by Wowbagger
Is the signal AC coupled, and drooping?
Look at the demod on a scope - if the bits are drooping (showing the standard exponential drop-off of AC coupling) that could cause the radios to not like the data.
Posted: Tue May 09, 2006 2:54 am
by AEC
You may want to check tha actual bandwidth also, if it's too wide, garbage will ride along and could cause falsing or prevent the LTR data from being heard.
Inverting the signal will cause loss as the data is not in the proper 'format' for decoding, so no information will pass, or the information will simply be ignored as invalid.
A.C coupling might also introduce hysteresis noise and a lower level if the coupling is not correct, which can cause signal loss and degradation in the audio/data path.
You could try using actual LTR transmitters from E.F Johnson, those should be somewhat easy to locate on the used market, and they are a snap to tune up and get operational as well, but I don't recall if they made UHF LTR transmitters/receivers, I've only had 800 LTR models installed.
Same goes for the LTR logic and ID controllers....all fairly simple to set up and get running with minimal test gear.
Try checking the cavity on the under side, it is adjusted for both TX and RX, and if not adjusted correctly, it will allow desense of the receiver, which can also ruin your decoding of data.
I believe the receiver is fed from a DGFET, and not a GaAs FET like newer units have, like a 3N204 or a bipolar like an MRF901 on the receiver.
I don't remember what type of device the Phoenix has, I'm drawing straws from memory of 5 years ago.
Check to see if you have channel guard(PL) active in the radio, if so, this may also be part of the problem. The C.G tone may be causing data falsing or mixing with the LTR data, which the controller may see as an invalid signal/data and reject it as the LTR data mixing with the C.G tone can produce odd mixing products on the audio, unless the data is fed after the tone filter to prevent this mixing.
Pre-emphasis/de-emphasis used?
You may need to shape the audio characteristics before passing the LTR data to the transmitter.