[FADCA] Status of Dual Speak Mitrek for Melbourne LAN

[bud thompson]

(This may be of general interest - If we are successful!)

Since I have not yet received information from PacComm on the true logic of using external (squelch/RF) DCD control on PacComm TNCs, nor have I received the needed PacComm TNCs from PCARS, today we continued our investigation by using two of the PK-96 TNCs donated to PCARS: #1 on 1200b, #2 on 9.6kb.  

Goal: To be able to have 1200b and 9.6kb users on the same frequency (145.09) Melbourne LAN.

Using the individual TNCs with our Motorola Mitrek radio conversion, each TNC TXA will drive the Mitrek to desired deviation (3.5KHz on 1200b, 3.0KHz on 9.6kb - the conversion works for single speed.)  However, with the TXA lines tied together, the apparent impedance miss-match results in available drive on 1200b being less than 1.7Hz.  (1200b ports are generally designed to drive 600 ohm microphone inputs.)  Slightly more than the desired 9.6kb deviation can be reached okay with both TXAs tied together.  Applying a series resistor in line with the 9.6kb TXA line helps some, but the available 1200b deviation is limited to 2.1 KHZ deviation.  

We have an idea for developing a dual-input broad band audio amplifier (mixer) to help this problem and will be investigating that.

Initially tying RXA lines together appears to not offer any apparent distortion, but we may have to make further determination on this matter.  With 1.0uv of RF input to the receiver antenna, we have nearly 2.0v of RX audio for either TNC!

Using proper logic (passive steering diodes) we were able to inhibit each TNC from TX when the other TNC was TX or receiving data.  That part works fine.

The dual speak really does work (i.e. both 1200b and 9.6kb users can use the Mitrek).  However, AX.25 optimum parameter setting may be left to the Gods!  We did not have time to play with a lot of different parameter settings, but if either TNC is set for very aggressive activity it will, in fact, totally take over the time slice on the channel.  

Furthermore, because 1200b packet transmissions are inherently longer (each parameter paclean, frac, paclean, maxframe, slottime, persist, etc. being equal on both TNCs), 1200b users would seem to get a distinct advantage.  We will experiment with making 9.6kb very aggressive - in order to get a 9.6kb user off the channel (finished quickly) so 1200b users may do their thing.  There are a lot of parameters controlling this, so it won't be settled quickly.

Status and one potential major problem - 

With the dual TNCs at the Mitrek (i.e. LAN radio) our dual source PTT/RX data control for cross-DCD works just fine.  The LAN radio will not step on either a 1200b or a 9.6kb station it can hear, nor will either step on the other when TX.  

(Applause, applause)

However, each user on the LAN will have to take local steps to keep from stepping on opposite baud rate on channel transmissions.  

1200 baud users will have to operate with the local radio squelched.  That is so that any signal (of either baud rate) that opens the radio squelch will light the local DCD/RCV LED.  In the case of Kantronics TNCs this means CD internal/internal.  1200 baud users will have little problem setting this up with any radio/TNC combo.

9.6kb users will have to operate using EXTERNAL/RF squelch control.  This means grounding pin 5 of the TAPR 5-pin radio connector when any signal is on the channel.  Otherwise, 9.6kb users would step on any 1200b on-channel signal, including the strong signal from the LAN.  Depending on the location of the 9.6kb user, this will significantly interfere and result in hampering throughput no matter the baud rate. We confirmed this today. 

We will now work at being able to drive EXTERNAL/RF squelch from the LAN Mitreks to inhibit TX from KPC9612 9.6kb ports when 1200b signals are on-channel. (This is for IVAR's and Rick's contribution to minimizing QRM on the Melbourne LAN!)

Until we hear from PacComm on that issue, or from PCARS on the box of goodies we need, our next effort (Tuesday Jan 11) will be to try Bit Error Rate testing to see if that will result in a benefit from fine tuning the IFs in the Mitreks.

Are we having fun yet?

bud N0IA