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?
On 09/27/2011 04:25 PM, Reginald Cornwallice wrote:
my transmit directly to the DAC output pins, bypassing dsp_core_tx.
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;
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)
Use an E100 (or likely an E110) and write some code on the ARM to do
the control tasks.
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)
There’s a ZPU in the FPGA–it handles some of the protocol and low-speed
interfacing “goop” in the normal firmware/FPGA load.
But the general “model” is that the FPGA/firmware is “dumb”. It
simply provides a fairly generic “peek and poke” interface over
the Ethernet, with all the “smarts” in the host code. I think part
of the motivation for this is that it’s easier to modify host code
for minor performance tweaks, etc, than doing it in the firmware/FPGA
code. But one could certainly enhance the small amount
of firmware that runs on the ZPU to handle all the device register
initialization, etc.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.