The common transmitter input scheme for audio, data and various signaling can be thought of in at least three different paths.
First is the common Mic Audio input, which in many but not all cases a fairly low level. Mic Audio in many but not all typical transmitters goes through a number of stages for processing and limiting before being applied to the actual transmitter modulator oscillator section. Many transmitter Mic Audio input paths (but not all) include a filter section to roll off low frequencies. The low frequency filter does more than simply reduce anyone's attempt to route CTCSS through the Mic Jack. But the quality of various filters is only so good and does only so much, so there are cases where one can brute-force CTCSS in through the Mic Audio Path. Also consider many of the low frequency filters are designed to reduce their attenuation as the audio frequencies increase above the generic CTCSS frequency range (below about 250Hz . So a CTCSS frequency of 250.3 Hz will more easily blow-through the low frequency roll-off filter versus a much lower 77 Hz Tone. Something maybe to keep in mind when you pick your CTCSS Frequency of choice. The second audio route is a less restricted audio path not always mentioned or included with the initial transmitter information. This second path inserts the audio/signaling information past the Mic-Audio Sections. The many times labeled "wide-band", "direct", "signaling", "yadda, yadda" input path is considered to have little or minimal conditioning before reaching the modulator - oscillator section of the transmitter. The actual voltage, drive requirement at the direct/wide-band input is more often done at a higher level versus the Mic Audio Input path. Normally minimal filters are in the path, CTCSS and other signaling information can also be applied here. In kit transmitters this more direct high level path still routes through the final Mic Audio Stage as a buffer or at least through the deviation level pot. The third possible transmitter input is what I might call the information or signaling point. Many times this input is also a much more direct path to the transmitter's modulator/oscillator section. Most often this third path is used to insert a more constant level non-voice signaling information input, i.e. the CTCSS (PL), DCS (Digital-PL), or LTR-Trunking Data. Most often you will find this input path does not route through the deviation control (pot) and it's level is set using the level control at the signal source (the CTCSS board). Now on to your Motorola fun... Depending on your specific radio model... Motorola can and does offer a few different paths toward the transmitter modulator - oscillator section. To be more flexible these paths can require internal (to the radio) simple jumpers to be set in the desired path direction. So a 16 pin Motorhead (Motorola) Radio might have a possible high level Tx-Audio input in the back, which can be configured to pass full "wide-band" (with CTCSS) or just the higher range voice audio information. The trick is the specific radio model and it's other possible applications as designed by Motorola. Radios that were intended for end-user mobile only operation might not have all the available external input and output ports and connections paths available. Without a detailed look at the GTX-900 Mobile Service Manual I'd guess to say this radio is probably not designed to be as flexible through the rear 16 pin jack connections. If you're using this radio as a Repeater Transmitter, you can in the basic radio application setup a desired CTCSS/DCS Code right in the programming software, which is included when you key the radio through the front panel Mic-Jack. But like many other options keying the radio through the rear accessory jack path might transmit with only the bare bones carrier (RF) signal less any other signaling (CTCSS). Sometimes internal and external signaling paths are also controlled in available software options... sometimes the no free lunch rule applies. So depending on your method of keying and applying both voice audio and signaling information to the specific radio model... you may or may not end up with internal or external CTCSS/DCS on the transmitted signal. The hard part with less flexible radio models is to route more than one signaling (CTCSS/DCS) signal through the radio accessory jack when the various path options are not normally made available with simple software and hardware configurations. All this can sometimes be a real head scratcher... cheers, s. > "n9wys" <[EMAIL PROTECTED]> wrote: > > No ideas yet on this? > > I'm wondering of the mic circuit rolls off the low freqs (where PL would > normally be "found") and I need to use the Audio IN pin, or if it really > makes any difference? I suppose I could just take a ride and try it, but if > it DOESN'T make any difference I need to examine other options for getting > PL back on the output - like reprogramming the radio for PL transmit rather > than CSQ. > > Thanks, > > Mark - N9WYS > > > > --- Original Message --- > > From: n9wys [mailto:[EMAIL PROTECTED] > Sent: Monday, January 28, 2008 2:10 PM > > > > OK, I just got my 900 machine back up and running again this morning. For > those who don't remember, this is a MaxTrac Receiver / Com Spec TP-3200 > controller / GTX exciter / Motorola STF2520A paging PA arrangement. > > Anyhow - the machine had no audio output at all. nada, zilch. only a dead > key. I changed out the GTX and this restored the transmit audio - I can now > hear voice audio and the ID-er being passed by the repeater. However, one > problem remains: it is still not encoding PL tone. (So if you are in the > area and plan on using the machine, be sure to use CSQ receive for now.) > > I have checked and double-checked the panel programming and output - it is > encoding the tone. What I wonder is if the audio circuit in the GTX is > scrubbing off the tone coming from the panel? If so, I can reprogram the > GTX for tone encode on TX, but I'd prefer to use the panel's tone. > (Currently, the GTX is programmed for CSQ transmit.) Also, I'm using Pin 2 > (Ext MIC) for the audio input. should I be using Pin 11 (Flat RX audio) > instead? > > Is this an issue that was previously referred to on the list - one regarding > a factory add-on module/fix?? > > > > Mark - N9WYS >
