[Discuss-gnuradio] SSRP update

[David Carr]

A quick update on my progress today.  I apologize if I'm flooding the 
list with my traffic but I hope that what I'm doing is of some interest.

Thanks to Eric's help and a good night's sleep I was finally able to get 
some basic LED flashing code running.  At first I was using the Cypress 
supplied fx2regs.h but apparently it does not correctly define the SFRs 
for use with sdcc.  More interesting is that the SFR definitions are 
just silently borked---leading to great frustration on my part.  A 
switch to the usrpregs.h include solved my I/O port access issues.  From 
this point I'd like to get some basic firmware that will put the GPIF 
into 16 bit mode and then just setup an endpoint that will just 
continuously crank out IN data.  Hopefully I'll have this working in a 
few days.  Some of the USRP code should be helpful here as well.  I'm 
not quite sure of all the steps required to do this yet, but with enough 
reading and maybe a little help I'll get there.

On another front, I've changed my ADC design to use the Linear 
Technology LTC1746 instead of a Maxim MAX1422.  The new converter is 
14bit 25Msps instead of the previous 12bit 20Msps.  This converter also 
comes in 48 SSOP instead of 48 TQFP which should make hand-soldering and 
board production easier.  I plan to run the converter at 12Msps or 
15Msps.  The determining factor here is how much bandwidth I can squeeze 
out of the bus.  (I have the Intel 82801DB ICH4 controller).  I placed a 
sample request for the converter today and I should begin the schematic 
design and board layout relatively soon.  One thing I'm not sure of is 
whether or not I need to use a latch inbetween the GPIF bus and the 
converter outputs.  The ADC datasheet says that the outputs should not 
drive more than 10pF of load capacitance and that a latch is recommended 
but I'd really like to avoid the additional complexity.  Does anyone 
have any experience here?

Finally, I've decided to call the device the Simple Software Radio 
Peripheral because it reflects my design goal of creating something that 
trades some of the USRP's capability for reduced costs yet still remains 
useful.  Hopefully the USRP folks don't have any objections to this. 

Thanks again for your time and for your input,
David Carr