[hpsdr] I will miss TeamSpeak this week.

[Christopher T. Day]

Social obligations intervene. As an update:

 

You may have noticed in the ARRL Newletter that KC4AAA, the station at
Amundsen/Scott Base at the South Pole will be on the air during Filed
Day on 20m. Give a listen. One of the folks I worked with down there
over Xmas will likely be one of the operators. She is AB1FG. There's no
way they'll hear me with a measly 8W, so if anybody contacts her, say
"Hi!" for me.

 

I have all the parts for a Janus board in hand except for two
backordered 39k resistors. I want to get all the passive parts on board
(save those two, maybe) before adding any active components. I'm working
on the ESD resistors now.

 

I got some tools to finish my SlimGem enclosure for the PA-100 preamp
from K5OOR. That now moves up in build priority.

 

I've been struggling to assemble a PC for home use with all this radio
stuff. No joy in Mudville so far. I have all new parts assembled as
carefully as I could - and I've been fiddling about in the insides of
computers for 25+ years - but there is no signal coming out the video
card and no evidence of it even reaching anybody's BIOS. Stumped and
frustrated for the moment.

 

I've started going through the exercise of defining USB Descriptors for
what an HPSDR might look like if we make full use of the features
available in the USB Architecture. I've got the required Default
Full-speed Device, Configuration and Interface Descriptors done, For
High-speed, I have the Device Descriptor done as well as two
Configuration Descriptors - one for regular Run-Time and one for Device
Firmware Update Transfer Mode. [The Other Speed Descriptors are also
done.] The Device Firmware Update Transfer Mode Interface Descriptor and
Functional Descriptors are completely standard so won't be hard.

 

All the interesting stuff will be in the High-speed Run-time
Configuration's Interface Descriptors. What I have in mind at the moment
is:

 

1)                   Printer Descriptor for the Parallel Port control
to, for example, an SDR-1000

2)                   Human Interface Device Descriptor with Interrupt IN
Endpoint for the key/paddle interface

3)                   Human Interface Device Descriptor for frequency
measurement/control

4)                   Additional HID Descriptor as needed for other slow
control functions _except_ for audio

5)                   Two Audio Device Interface Descriptor clusters, one
for the Receive chain an one for the Transmit chain.

6)                   The Audio Clusters would also be the Interfaces
where such things as sampling rate selection happens.

 

For Endpoints on the FX2, this would have everything sharing the
Endpoint 0 IN/OUT endpoints, of course. 2) would use Endpoint 1 IN. The
other HID Interfaces don't need endpoints beyond Endpoint 0. For the
Audio Device Chains, each would have two Endpoints, say 2 IN and 4OUT
for one and ^ IN and 8 OUT for the other. These would carry the bulk of
the data. We still get to argue here about Bulk vs. Isochronous
Transfers here.

 

Despite appearances, there are some advantages to this scheme. For one
thing, it eliminates the special-purpose protocol inside the packets of
Audio data; different functions are on different pipes. Changing this
protocol will be annoying since it couples everything together, but
inevitable; it does not allow for ISB as it stands, for example. Also,
we don't have to write or maintain the multiplexing/demultiplexing code.

 

That uses up all but one Endpoint that the FX2 can supply, viz. I OUT.
Other than screams of horror at the complexity of it all, are there any
comments?

 

 

            Chris - AE6VK

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20060623/6d3fa962/attachment-0003.htm>