discuss-gnuradio
[Top][All Lists]
Advanced

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

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


From: Ian Buckley
Subject: Re: [Discuss-gnuradio] Make USRP run w/o SW intervention
Date: Thu, 6 Oct 2011 19:33:43 -0700

Reginald,
As already pointed out by Philip and Marcus, it is quite possible to modify the 
embedded firmware to initialize/hardcode SPI and internal FPGA register values. 
I've not looked at the firmware for the TCP/IP wrapper on packets that was 
added when UHD was introduced, but presumably you could hardcode an IP address 
there with similar difficulty. It's hard to say if you would find this "simple" 
not knowing your software coding skills, but if you are capable of writing new 
FPGA verilog, then reverse engineering the firmware source should not be too 
challenging for you as it is relatively small and you have the FPGA source and 
H/W schematics to refer to which will help in your understanding.
However this is not the approach I would recommend. I would suggest that whilst 
reading the firmware source will help you understand how the USRP is controlled 
by the host, it would be better to reverse engineer how the regular Source and 
Sink blocks work on the host, then write your own custom Host based application 
that programs FPGA and SPI registers and also packs unpacks the ethernet data 
stream to/from the USRP (which will be in your own proprietary framing format 
once drivers have removed/added UHD/IP/TCP headers). As you have observed it is 
relatively trivial to replace or enhance the DSP datapath on the FPGA and 
interface with the logic that packetizes the network traffic.

If however your project is to make the N210 a fully self contained SMS Tx/Rx 
device then I caution you the project is very big, running even 2G GSM 
protocols on an embedded processor in the FPGA with the limited debugging and 
RAM resources will be very challenging. I'm assuming you have done some 
research on OpenBTS which may give you some good architectural ideas and 
perhaps a great starting point.

-Ian

On Sep 27, 2011, at 1: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 
> hardware.
> 
> 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.
> 
> 
> Reginald
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




reply via email to

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