[Elecraft] Re: radios on networks

[Brian Lloyd]

On Jun 5, 2007, at 1:34 AM, Julian G4ILO wrote:

> On 6/4/07, Ian Stirling <g4icv at arrl.net> wrote:
>
>>  I think Elecraft missed an opportunity in the design of the K3
>> regarding networking.
>
> I don't agree. I think such a feature would be a gimmick, designed to
> appeal to the kind of buyers who choose a radio because of the bells
> and whistles it has.

Not necessarily. More below.

> Only a small minority of people wish to control their radio remotely
> via a network.

Perhaps. I think that is mostly because they have not done it.

> Such an interface would need nothing that is specific
> to the K3, so there is no need for Elecraft to have to develop it.

It is more than just controlling the radio. It is about building a  
system.

> Lynovation http://ctr-remote.home.att.net/CTR-BlueLync.htm appears to
> have a module that will interface to any radio's serial port via
> Bluetooth. If there is a real demand for one that uses wi-fi or wired
> Ethernet, surely someone will develop one.

Probably.

We tend to think of our radio as being a monolythic stand-alone  
device. After all, it is a black-box that has only one function.  
OTOH, given that most people here have or are buying Elecraft radios  
they already have the idea of the radio as a building block toward  
something that is customized for a given purpose.

As our building blocks become more and more complex we begin to need  
some way for the blocks to communicate with each other. In the past  
such communications was limited to one function per wire. We had  
things like an ALC line, a PTT line, an audio output line, a signal  
input line, etc. Control functions were limited to what we could do  
with our fingers on switches and knobs.

But as things become more complex and automatic we needed to transfer  
more information between devices. We want to know operating  
frequency, operating mode, bandwidth, passband center frequency, etc.  
Controlling these parameters or querying them is a low-data-rate  
operation -- now. In the future it might not be so.

We are moving more and more toward digital communications mode. We  
already have things like PSK31, MFSK, and PACTOR. PSK31 is, frankly,  
more spectrum efficient than CW and capable of operating at S:N  
ratios equal-to the best we can do with CW. Digital voice is on its  
way. After all, we have been using digital voice for quite some time  
now in our handheld mobile telephones.

> As Simon Brown points out, such an interface does nothing to address
> the issue of streaming audio in or out. A PC is inexpensive and can do
> the whole job, and most people already have one connected to the radio
> for when they are not at a remote location.

This is an excellent point. Imagine I am using a digital mode with a  
K3. The K3 performs all modulation and demodulation in DSP, i.e. in a  
computer. Does it make sense to generate a signal digitally in my PC,  
convert it to analog, transfer it to the K3 which converts it to  
digital, translates it to the first IF digitally, and then converts  
it back to analog again? How silly! But that is *precisely* what we  
are going to be doing when running sound-card modes with a K3. Why  
not just keep the signal in the digital domain and transfer it  
directly to the D:A in the K3. That eliminates noise pickup, phase  
shift, quantization artifacts, aliasing, etc.

Now let me think a bit more about my communications system in my  
shack. Let's say I want to use one of the satellites. That requires  
that you manage your antenna position, correct for doppler, and  
communicate. It takes some getting used-to and if you are working a  
satellite in low earth orbit (LEO) you will find yourself busier than  
a one-armed paper hanger.

But much of this is easily handled by computer. If you are doing  
satellite you already use a computer to determine antenna direction.  
Let's just let the computer handle that. But since the computer knows  
the satellite's orbit, it also knows its velocity. That means the  
computer can know the doppler shift and tune the radio. If both ends  
do doppler shift correction independently and do it for both uplink  
and downlink separately, the operator can have a doppler-free  
communications.

(For those of you wondering about the details, you correct the  
doppler in the uplink to fix your signal in the satellite's passband.  
That way the receiver only needs to correct the doppler in the  
downlink. That would allow two stations that don't know their  
combined doppler ahead of time to do their own half of the correction  
and have an apparently doppler-free QSO.)

And as I add more radios and more devices to my station, why should I  
have to add lots more wires? This is a problem that afflicts the  
cockpit of an aircraft. Consider all the radios and all the devices  
that must work together in a cockpit. You have comm radios, nav  
radios, GPS, INS, engine sensors, multiple displays, etc. You need to  
integrate all this. You may find this hard to believe but Airbus has  
standardized on good old ethernet as the way to make all the devices  
talk to each other.

Wouldn't it be nice to be able to add a radio or add a station  
accessory and just plug in one wire in order to integrate it with  
everything else? If I have a set of control messages for my radio I  
can send them over ethernet. If I have a set of control messages for  
my rotator I can send them over the ethernet. If I have an antenna  
tuner I can send control messages to it over the ethernet. If I want  
to control everything from my computer I just do it over one wire --  
my ethernet. If I use multiple radios as the same time (cross-band  
operation) I can control the two radios as one by letting the  
computer do the integration for me.

And ethernet has plenty of bandwidth to move large amounts of data if  
necessary. Most people don't realize that their sound-card interface  
represents a huge data rate. The typical sound card running at CD  
audio rates (44.1Ksps x 16 bits) is transferring 705Kbps of data for  
just one channel. If we increase that to the new standard of 96Ksps  
and 24 bits we are now up to 2.3 *Megabits* per second. You can't do  
that over an RS-232 connection. Now multiply that by all the radios  
that you have! OTOH, 100Mbps ethernet can do that without even  
breathing hard.

So there is more to this "ethernet in the radio" than meets the eye.

I would love to have a universal interface that would plug into the  
ethernet and let me sample and control things in my shack. I want to  
control my antenna switch. If I am doing weak-signal microwave stuff  
I need to coordinate the sequencing of my IF radio, my transverter,  
my preamp and power amp switching, etc. Lots going on. I might want  
to let the DSP in the radio perform the low-level modulation and  
demodulation while letting my computer perform more of the high-level  
protocol functions.

So, as digital communications evolves we are going to want more  
flexibility to use our radios as components in a larger system rather  
than as just standalone devices. Having a single good, fast, reliable  
interface for everything will make future functionality much easier  
to achieve. If we adopt the universal interface that supports a very  
high level of peer-to-peer multiplexing ahead of time, we will not  
have to worry about changing that hardware in the future. Now all the  
new features can be implemented in software because the hardware is  
already there. Think of the possibilities!

>
> -- 
> Julian, G4ILO
> G4ILO's Shack: www.g4ilo.com
> K2 s/n: 392  K3 s/n: ???

73 de Brian, WB6RQN
Brian Lloyd - brian HYPHEN wb6rqn AT lloyd DOT com