One Point on item 5.
Software thru DTR is essentially impossible with modern operating systems.
While the super fast processors would be up to the task, the operating
system would get in the way.
Remember, we still get reports of CW stuttering when sent by the computer,
and this is very slow compared to millisecond timing required to keep low
distortion levels with 22 msec bit times of 45 baud.
So, keep those old ports alive, the 16550 class UARTs are the winners.
It is interesting to think ahead a few years though, and wonder how we will
be able to send 45 baud FSK.
A new computer, no serial ports, no way to use USB converters, such as
Belkin F103s for 5 bit with the new operating systems, hmmmmm cause for
thought at least !!
Ric KV1W
----- Original Message -----
From: "Bob Naumann - N5NJ" <n5nj@gte.net>
To: <n5nj@gte.net>; "Nick Kail" <m3mlr@tiscali.co.uk>; "'FireBrick'"
<w9ol@billnjudy.com>; "'Writelog List'" <writelog@contesting.com>
Sent: Saturday, February 28, 2004 12:50
Subject: [WriteLog] 5 bit mystery unraveled
OK - I think I have a complete explanation of what this is all about.
Here goes:
1) The problem is not really a problem, but rather a feature of most serial
ports, which is an holdover from the early days. The UART (universal
asynchronous receiver-transmitter) device that is part of the serial port
can produce properly timed RTTY characters on it's output, which is the TXD
of the serial port.
2) Newer devices, most notably, USB to serial convertors, do not have this
"old" functionality. I understand that Belkin USB to serial devices may be
an exception to this and have a UART in them. The reason this has changed,
is that this 5 bit capability is only run at 45 baud, and these new devices
are engineered to go so much faster than that, that they have left this
capability out as unnecessary. No one uses 5 bit baudot code any more -
right?
3) The input to a radio - the RTTY jack - is a simple input that receives a
logical off or on, open or closed, a 0 or a 1. It does not receive the 5
bit "data", but instead receives logical open or closed input that follows
the changes in state that produce the 5 bit baudot code. There is no
conversion of the data going on in the radio. If the RTTY input is left
open, the carrier is output on the Mark frequency. When the RTTY input is
shorted, the frequency of the transmitter shifts by 170 Hz. This is all
that happens. Open - the transmitter is on the Mark Frequency; closed - the
radio shifts the transmitted carrier to the Space Frequency offset.
4) The UART in the serial port converts the 5 bit code - not the radio. You
could just connect a momentary pushbutton to the RTTY jack on your radio,
and it might be possible that you could produce 5 bit baudot FSK output from
your radio. The timing is critical enough that you probably cannot
communicate with someone else.
5) It would be possible to use the DTR output of the serial port to provide
the logic necessary for driving the radio's RTTY input - if the
functionality of the UART was emulated in software. However, the approach
is to use the UART since it already has this capability. Sort of a "why
re-invent the wheel" approach. The other school of thought would be to move
this to some other external device rather than doing it in software. We may
see new devices that will provide this capability in the near future.
Summary:
The reason that I wanted to get to the bottom of this, is that I wanted to
understand why we had to sacrifice the radio control capabilities of a
serial port in order to produce a simple switch closure to drive the radio's
RTTY input. The reason is because the UART has the intelligence to convert
the letters and characters to the precisely spaced output which can only be
produced on the TXD output of the serial port. It seemed logical to me
(prior to knowing about the UART stuff) to seek to use the DTR output (CW
normally) instead, as it is not used during RTTY operation.
For the time being, if you want to control your radio, and you want to run
FSK, you will need 2 serial ports. However, you can use any of the USB
serial ports to control your radio, and use the built-in serial port (which
likely has a UART) to do the FSK stuff.
I am now doing this with one of the Microham USB devices to do CW, PTT and
radio control, and the serial port on my computer to do the FSK.
73,
Bob N5NJ
> ------------Original Message------------
> From: Bob Naumann - N5NJ <n5nj@gte.net>
> To: "Nick Kail" <m3mlr@tiscali.co.uk>, "'FireBrick'" <w9ol@billnjudy.com>,
"'Writelog List'" <writelog@contesting.com>, "'FT1000MP List'"
<1000mp@mailman.qth.net>
> Date: Fri, Feb-27-2004 10:43 AM
> Subject: Re: RE: [WriteLog] microHAM USB interface
>
> Can someone explain the 5 bit "problem"?
>
> Why couldn't the CW output just be hooked up to the FSK connection on the
radio? Is that connection on the serial port just not capable of switching
fast enough to do rtty?
>
> -N5NJ
>
_______________________________________________
WriteLog mailing list
WriteLog@contesting.com
http://lists.contesting.com/mailman/listinfo/writelog
WriteLog on the web: http://www.writelog.com/
_______________________________________________
WriteLog mailing list
WriteLog@contesting.com
http://lists.contesting.com/mailman/listinfo/writelog
WriteLog on the web: http://www.writelog.com/
|