On Aug 2, 2007, at 7:03 PM, Ron Wright wrote: > Nate, > > Would just disabling one PTT while the other is txing mean the > disabled would think it was transmitting, but not really.
That's not what I recommended. I recommended tying one's PTT signal to the other's RECEIVE signal so it would hold off and not transmit. (TNC's won't transmit over an incoming received signal.) As someone else and myself both pointed out, you have to rely on having a real COS signal from the radio and have your TNC's set up to use that, and not use a "software" DCD (data carrier detect) that looks for real tones, you have to do it the "old fashioned" way with a hardware COS line from the rig. > Unless there is some sort of feedback to tell a TNC to wait then > its data would be lost. I guess some TNCs have this wait line > INPUT allowing one ptt to talk to the other TNC commanding a wait. No, TNC's "buffer" data all the time. If the channel is busy when the computer connected to them sends data to them, they buffer and wait. Then when the channel's clear, they transmit that data. So it's not really a separate "WAIT" line, you're just tricking TNC #2 to think that the channel is busy when TNC #1 is really transmitting, and vice-versa. This is kinda off-topic for RB, so I'll stop now -- but suffice it to say, hooking two TNC's to the same rig would be pretty simple... as long as you're not relying on the TNC to determine if the channel is busy, and you're using the "old-fashioned" system that simply watched the squelch circuit of the receiver... if the squelch was open, the TNC knew it shouldn't transmit. (Once upon a time, there were endless debates about the benefits of doing busy-channel detection by either method, and which one was "better" over the last couple of decades... real "squelch" circuits will also give way to voice traffic on the same frequency... software DCD's won't... etc. etc. etc.) -- Nate Duehr, WY0X [EMAIL PROTECTED]
