[hpsdr] Operating Configurations

[Christopher T. Day]

Alex,

Excellent lead in for a comment I wanted to make anyway. 

As you've listed, there are a variety, rapidly expanding, of possible
useful configurations of Atlas and the component cards. All of these -
so far anyway - use OZY as the interface to the PC. Now, think about
what happens when OZY is connected to the PC's USB port. The host sets a
USB address into the FX2 and then asks the FX2 to enumerate the devices
at that address. The FX2 should respond with, among other things, Device
Descriptors for each item. Since there are so many possibilities, it
seems sensible to me for the FX2 to look and see what appears on the
Atlas bus and report that. What seems to me the most natural way to do
this is to have an I2C EEPROM on each component board that contains the
descriptor(s) for that board. 

There seem to be several issues then.

1) Others have mentioned drive issues with I2C across the scale of the
Atlas and component cards. This suggests that a driver on OZY is
required.

2) The I2C address space needs to be partitioned somehow to support
however many cards can ultimately be inserted into the largest Atlas
variant imaginable.

3) Assuming that the number of cards is larger than eight, there has to
be some support decoding circuitry given that the common Microchip
EEPROMs only have three higher order address pins.

4) There has to be some way to either permanently assign address spaces
to particular cards, i.e., a central "authority" assigns 1 to Janus, 2
to Mercury, etc., or some way for the user to configure the address
spaces of the cards in his/her Atlas box. I think I prefer the latter.

5) There has to be some coordination of the Device IDs returned from the
boards so the proper driver can be loaded. This probably can be done by
registering the boards with the DID supplier, probably the same place
the USRP folks get theirs. [Trying to push all this into one driver with
all the demultiplexing done in our own code doesn't get rid of the ID
assignment problem and just introduces a reinvention of stuff already in
the USB protocol.]

Anyway, my solution may be wrong and someone else has a better one, but
the issue is there, I think, no matter what.

Comments?


	Chris - AE6VK


-----Original Message-----
From: Alex [mailto:harvilchuck at yahoo.com] 
Sent: Thursday, May 11, 2006 6:18 PM
To: hpsdr at hpsdr.org
Subject: [hpsdr] Operating Configurations

***** High Performance Software Defined Radio Discussion List *****

So reading through everything the project want to be able to run three
configurations (as it stands right now):
 
 (1) as a computer controlled interface for the SDR-1000
 (2) as a computer controlled 0-30MHz SDR transceiver
(3) as a standalone SDR transceiver using the SDR-1000
 (4) as a standalone SDR transceiver
 
...


 1147403780.0