Jim Lux wrote:
At 10:14 AM 2/28/2006, Bob McGwier N4HY wrote:
It can be implemented in hardware and it should be along with the proper
keyer and sidetone where they both belong.
I respectfully disagree. Isn't the whole point of a software radio with a
minimalist hardware to do as much as possible in software. The SDR1000
itself is essentially a zero delay system.. all it does is translate I/Q
baseband to/from some useful RF frequency.
Yes and no. I'm in sympathy with your argument in principle, but there
are real world limits. Speaking as a long time SDR operator with
something like 150 "SDR countries" under his belt, virtually all CW, and
all of those with the parallel port keyer, I think I have some grounds
to speak.
Basically, the "new keyer" is a marvel of read-time coding in a
non-real-time environment. But, why should we saddle ourselves with
that? We've done that experiment and we know how it comes out. Short
answer: Windows (or Linux) gets in the way.
If a little hardware can get rid of a lot of tricky real-time coding,
even if it is only the transmit part of the problem solved, I'm all for
it, especially as neither Linux nor Windows is really real time.
Glitches notwithstanding, I'm amazed at what I can do with the keyer as
it stands, but the next transmitter should look for an easy way of
making life a little easier for the software here. It's all just too
critical under the constraints.
Either that, or we go with my old "SDR 1497" design and have a separate,
embedded processor (with its own D/A or sound card) on the other end of
a USB cable and so can achieve a true real time discpline in an
"appliance" setting because there's no Windows anymore (and no OS to
speak of, either). That would presumably enable something like this
current design to work with less pain that has so far been required.
However, even if we go with the "1497" type approach, I could still see
advantages to doing this little bit in hardware even there. How much
hardware could it be?
Personally, it would be great to get this to the point where you don't
have to be Bob or Frank to code this stuff. A little less "real time"
in the pathways would really help, I would think.
Larry WO0Z
