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 > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
