Bonnie, > Rud Merriam" <k5rud > wrote: > > Or the protocol implementers need to recognize > the need to generate a tone to trigger the VOX. > This would be analogous to the delay they provide for > transmitter keying.
>Bonnie wrote: >IMHO, it is ridiculous to suggest that >the "protocol implementers" should change >the protocol to add overhead to accept >cheapo bogus hardware. In many cases, the >excellent worldwide standards have already >been set, and the proliferation of >sub-standard interfaces on the market is >not going to affect the protocols, like the >tail wagging the dog. The ARQ specification by K9PS clearly states that all <SOH> in a preamble are ignored except one, so in order to make it possible to use MFSK16, with its rather high latency, with ARQ for NBEMS, we simply added 10 <SOH> to each transmission to compensate for the latency. This also made it possible to use MT63-2000 with ARQ. It works, and the additional overhead is so small that the slowdown in throughput is insignificant, especially since MFSK16 is so good, that whole blocks that might ordinarily have to be repeated using a lesser mode are not, which is much more significant to throughput than the time it takes to send 10 <SOH> characters. The K9PS specification has not been deviated from and the NBEMS system also works perfectly with either SignaLink digital VOX or SSB rig VOX. You should clairfy your overly broad statement that the SignaLink will not work with "ARQ" modes, to say it may not work with traditional PC ALE or AMTOR, but is fine to use with other soundcard modes, so you do not continue to mislead others. I think you owe Rud Merriam a personal apology for calling him "ridiculous". It is YOU who are in the wrong, not he... 73, Skip KH6TY NBEMS Development Team
