[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Make USRP run w/o SW intervention

From: Philip Balister
Subject: Re: [Discuss-gnuradio] Make USRP run w/o SW intervention
Date: Tue, 27 Sep 2011 18:04:04 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110906 Fedora/3.1.14-1.fc14 Thunderbird/3.1.14

On 09/27/2011 04:25 PM, Reginald Cornwallice wrote:
Hello Friends,

My name is Reginald and I am an SDR enthusiast currently pursuing my latest
project with the N210 box. I have the utmost respect for this hardware and
hope to integrate it into my newest intellectual pursuit.

My project is a box that sends and receives cellular SMS messages and with
my expertise being mostly in FPGA I am tackling this venture by modifying
the FPGA code. So far I have been successful implanting my HDL based
cellular receiver in the FPGA after the dsp_core_rx module and a attaching
my transmit directly to the DAC output pins, bypassing dsp_core_tx.

However, it seems that the box cannot run standalone without software
intervention because the ethernet IO is not free running and ADC and DAC
clocks can be shut off by software. Furthermore, it seems running example
programs such as rx_samples_to_file overwrite SPI values programmed to
AD9510 in the firmware burned onto the motherboard,  for example, changing
the divisors for the clocks to ADC and DAC. I confirmed this by probing the

My project works when I run rx_samples_to_file program to force the board to
be active on receive and transmit, and also force the ethernet output to be
active, which I have configured to send out some status messages so I can
tell the demodulator is functioning.

Is there any simple change I can make to the FPGA or firmware in order to
have the box run without intervention, meaning all the SPI programming is
handled by firmware, DAC/ADC clocks are on forever, and the ethernet output
is continuously putting out the output I've wired it up for in the FPGA?

Many thanks for any assistance on this matter.

I see a couple of possibilities;

1) Use a microblaze in the fpga to control the spi bus and other control functions. (It may already use a microblaze, so update the code to do this internally, instead of taking commands from ethernet)

2) Use an E100 (or likely an E110) and write some code on the ARM to do the control tasks.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]