[hpsdr] Operating Configurations

[kd5nwa at cox.net]

The FPGA is not a general purpose computer, it has to be custom
programmed for each application, hence it can know what it's dealing
with.

On Thu, 2006-05-11 at 20:16 -0700, Christopher T. Day wrote:
> ***** High Performance Software Defined Radio Discussion List *****
> 
> 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
>  
> ...
> 
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at hpsdr.org
> Subscription help: http://lists.hpsdr.org/listinfo.cgi/hpsdr-hpsdr.org
> HPSDR web page: http://hpsdr.org
> Archives: http://lists.hpsdr.org/pipermail/hpsdr-hpsdr.org/


 1147404269.0