[CQ-Contest] Mode 516 Suggestions

[Bill Coleman]

On 7/6/01 7:57 PM, W. Wright, W5XD at w5xd at writelog.com wrote:

>
>"Ethernet" sounds best to me, but that can mean lots of different things.
>I'd add some qualifications. Before listing them, let me describe the end
>result. You buy your radio and the ONLY connectors on it are power, 10BaseT
>ethernet, and an RF connector. You plug the 3 of them in (the ethernet goes
>into a 10BaseT hub).

That's one point in favor of USB -- you could dispense with the Power 
connector. <grin>

>Bring up your favorite internet browser, type in the URL for the radio, and
>the radio serves up a web page with its front panel on it and feeds your
>browser the received audio.
>
>Here are the specs I think would accomplish that:
>
>hardware:
>
>10BaseT	100Mbps

10BaseT is only 10Mbps -- but plenty fast enough.

>software/protocol:
>
>1. the radio has a TCP/IP stack and serves port 80--the default one for HTTP
>
>2. the radio serves HTTP on port 80 (that is, the radio is a web server).
>
>3. the "traditional" radio control commands/queries use an industry standard
>RPC over HTTP. That would almost certainly be SOAP, but its a little new.
>This is what the logging programs would use to control the radio. This can
>be accessed simultaneous with the standard browser also talking to the
>radio.

Naw, you have the radio contain the code for a Java applet. When you 
access the page, the applet downloads and communicates with the radio 
over RMI. No need for nasty SOAP....

>4. The radio's audio--both transmit and received--is digitized and served
>over the very same HTTP protocol under a published URL. The digitization
>should be according to some standard and should be available compressed.
>11.025KHz sample rate, 16 bits/sample should be available, and MP3
>compression should be available. The client of the web server should be able
>to select the desired sample rate/compression by specifying an appropriate
>URL.

Why would you need compression? Full telephone-quality audio is only 64 
Kbps (that's using compandored 8-bit samples), and 128 Kbps for 16-bit 
samples. Neither would swamp 10BaseT or USB.

Compression might be useful if you were trying to access this animal 
remotely, but you should be able to disable it by default.

This type of computer/radio integration gets more interesting when the 
"audio" stream ends up being more than just "audio". Why limit yourself 
to 300-3000 Hz? Why not pump 30 kHz of decoded radio signals to the 
computer, and have it do the final selection and demodulation?

>5. The radio gets its IP name/address assignments by DHCP when it boots up,
>and maybe a dip switch to make it come up on some fixed IP address (I think
>10.0.0.n is reserved for this kind of application). I'm real fuzzy on this
>part, but I am sure there is a simple and standard solution.

Yup, there are.

>This list may sound like a rediculously complex/expense software product.
>But it is not a big deal. There is at least one company that sells a single
>chip that implements a TCP/IP stack and a web server. And the amount of
>software power required to do all the above could hardly be more taxing or
>complex than the stuff done by the microprocessors running the front panel
>on today's rigs.

Yup.

And you could make the radio simpler by putting some of the operations 
into that Java applet you download into the host computer. Who says the 
entire radio has to be made of hardware?




Bill Coleman, AA4LR, PP-ASEL        Mail: aa4lr at arrl.net
Quote: "Not within a thousand years will man ever fly!"
            -- Wilbur Wright, 1901


--
CQ-Contest on WWW:        http://lists.contesting.com/_cq-contest/
Administrative requests:  cq-contest-REQUEST at contesting.com