Re: Fwd: Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
Malihe, Please look here for schematics. http://www.ettus.com/download Nick On Fri, 2010-10-29 at 10:36 -0600, Malihe Ahmadi wrote: Can anybody help me with this? I need a full schematics of RFX2400, the one available on gnuradio's site is not complete! Original Message Subject: Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA? Date: Thu, 28 Oct 2010 20:00:53 -0600 From: Malihe Ahmadi ahmad...@ualberta.ca To: Nick Foster n...@ettus.com Hi Nick, I actually changed the nsgpio module so that io_tx_06 and io_rx_06 have fix value and the board is always configured as full duplex but yet the pin 8 (ENOP, on and off switch for RF output) of the U101( AD8349, the modulator) is switching on and off and I don't know which signal is controlling it (b/c it is not shown in the schematics). Can you please send me the complete schematics of RFX2400 or tell me how to control pin ENOP of the U101? Thanks, Malihe Hi Nick, I had few interesting observation yesterday. First of all, I followed what you recommended, stock FPGA and firmware image and the sin wave at TX. looking at the GRC's FFT, I realized that the 1.1MHz spike is there but not always, it is choppy, I see either the spike or white noise! with this setup, I was probing different points on the RFX2400 db and I found in (please look at the schematic) in U209 pin 1 is always 0 and pin 2 is always 1, but in U202 pin 1 is sometime 0 and sometime 1 and pin 2 is its complement. that means TX/RX is not always derived with RF_TX! (and I think that is exactly why the source is choppy and the received signal is choppy ...). Also looking at pin 8 (ENOP, on and off switch for RF output) of the U101( AD8349, the modulator), I found that pin is sometime 0 and sometime 1 (it seems it follows the same pattern as pin 2 of U202), but I can't find what signal is controlling that pin on the schematics?! do you know which signal it is? thus my understanding is that the firmware is not translating the full duplex configuration on the GRC to the correct values on U202 and 101. I'd like to take the control of those signals (io_tx_06 and io_rx_o6 and whatever else) out of the firmware and fix them in FPGA code and see what happens! but first Id' like to know your comments on these observations. Thanks, Malihe On 26/10/2010 7:12 PM, Nick Foster wrote: Malihe, Please run the USRP2 with a stock FPGA and firmware image. Modify your GRC flowgraph so the transmit frequency is 2.451GHz, and the receive frequency is 2.450GHz with gain 50. Instead of a constant source, use a complex sine wave source of amplitude 0.3 and frequency 100kHz. You should see a spike at 1.1MHz on your GRC FFT and your spectrum analyzer should show a spike at 2.4511MHz. Please let me know what your results are. It is impossible to determine if the problem is the USRP2 or not while you are running your custom FPGA code. Nick On Tue, 2010-10-26 at 17:38 -0600, Malihe Ahmadi wrote: Hi Nick, When I was talking about the spectrum, I didn't mean the FFT, I meant the spectrum analyzer we have in the lab, and I can see the spectrum of RF1 output which is a carrier at 2.45GHz with some data on top of it. on the FFT though, I believe the spike is just the carrier detected in the RX path and it seems there is no significant signal coming in on top of that! I captured those ADC and DAC plots more than few minutes after I turned on the board and run the GRC. I actually run the same GRC with two antenna, one connected to RF1 and the second one connected to RF2, yet I am capturing the exact same data from ADC and DAC. here is the new experiment I am running and it made me even more suspicious to the RX path (the reason I am running this experiment is that the DAC gets a continuous non zero flow of data and it lasts enough for the receiver to settle as you said it is required) : I am generating a 16 bit counter that counts from 0 to 2^16-1. this counter is connected to the dac_a while dac_b is always zero. I did this experiment with both antenna and also terminated RF1 and RF2 and their result was the same.In both cases the ADC data (_a and _b) is very small, then I increased the RX gian to 60dB and yet the ADC data has no relation with the DAC data (actually with 60dB gain, it seems to be an amplified white noise!). Then I decided to check some points on the board itself. I looked at the pin 16 of the AD834X and I could see the saw tooth wave. then I looked at pin 8 and 22 of the AD8347 and they are both constantly high with very small bump at some points! That seems not right to me! Thanks, Malihe Nick Foster wrote:
Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
Hi Nick, by FPGA image do you mean the .bit file? Thanks, Malihe Nick Foster wrote: Malihe, Use the USRP2 card burner utility, located in the UHD host code as host/utils/usrp2_card_burner_gui.py. It is also installed to /usr/local/share/uhd/utils/ by default. You may have to run the program as root. If you only specify an FPGA image when you run the program, the firmware image will not be overwritten. Nick On Wed, 2010-09-15 at 12:27 -0600, Malihe Ahmadi wrote: I have changed the FPGA code and I have built the bit file for it. I would like to keep the same firmware but just change the FPGA code. What should I do now? Thanks, Malihe Nick Foster wrote: Malihe, Your understanding is basically correct. I misunderstood your request -- I didn't realize you had an existing FPGA design you were integrating with the USRP2, and figured you were going about things the hard way. Nothing happens to Ethernet packets between the host transmission and GMII_TX -- the USRP2 MAC receives the same data that goes out the host MAC. I was trying to say that modulation is typically done in Gnuradio, not in the FPGA, and so data on the wire is typically baseband modulated and not a data bitstream. If you are implementing the modulation in FPGA you are of course free to define the data on the wire however you like. For your purposes you should be able to take your data straight from the MAC and buffer and encode it in whatever way you see fit. Nick Date: Thu, 2 Sep 2010 18:30:22 -0600 From: ahmad...@ualberta.ca To: bistro...@hotmail.com CC: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA? Hi Nick, I think I should explain my project better. We are developing a physical layer protocol for an asynchronous packet based transceiver all in Verilog. The design has been simulated so far using ModelSim. The target of the project is the VLSI fabrication of this design. Thus all the signal processing (digital modulation (for now we are interested in BPSK digital modulation), packetization, spreading, filtering ) has to be done in FPGA, and it should be as stand alone as possible. The reason we picked USRP2 was that it was a compact board with RF specification quite close to our requirements. Our understanding was that we can get one computer (host) to transmit stream of bits to the USRP2, do the processing in FPGA and send the data over air, and the second USRP2 would capture the signal and again FPGA would do the processing and eventually pass the data (through Ethernet) to the second host (computer). I thought, if I generate a stream of bits in the first host (TX) and do BPSK modulation and pass them to the USRP2 using Gnuradio, the two 16 bit I and Q port that I get at the DSP core of the FPGA are two bytes of that stream of bits and now I can continue with packetization and the rest of my processing inside FPGA (basically replacing the interpolation module with my spreading module) and redo that process at the receiver to retrieve the generated bit stream. I have already read through the DSP codes inside the FPGA. What I understand from your email below was that I can't retrieve the bit stream (generated at the host) in the FPGA and the 16 bits I and Q are modulated, shaped sample representation of the bit stream. This is a bit confusing for me because I thought (assuming the host just generates the bits and does the BPSK modulation) the Ethernet decoder (DP83865) of the USRP2 is basically compensating (undo-ing) the processing that was performed on the bits (by Ethernet encoder) right before they leave the host (computer) so that the Ethernet becomes transparent. If that is not the case, my only solution is to pass the bit stream to the FPGA using the debug port! Would you please let me know which part of my assumption is wrong? Thanks, Malihe Nick Foster wrote: Malihe, Date: Thu, 2 Sep 2010 14:19:54 -0600 From: ahmad...@ualberta.ca Actually we are using the USRP2 not for a SDR application, but we are using it to test our physical layer asynchronous backet based communication. For that I have to change the FPGA code and remove the interpolation/decimation and replace it with a spreading scheme. Assuming your spreading doesn't bring your bandwidth over around 25MHz, you should be able to do the spreading operation on the host and transmit the spread baseband data to the USRP2 via Gnuradio. The host typically does not send unmodulated data to the USRP2; the host side, usually using Gnuradio, performs the desired DSP operations on your raw information such as spreading, shaping, and modulating, and sends the resulting complex waveform to the USRP2 as raw 16-bit samples. The USRP2 itself knows nothing about
Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
Hi Eric, thanks for the insightful reply. I will be using these pins for my design. what else is provided to the board through Ethernet? If I understand correct, the configuration data for DAC (such as the IF frequency, etc) is provided through Ethernet, but we don't really want to change those, so I'd like to program those registers one and won't touch them again. For that do I need to just change the firmware? Is there any other important point I need to care about if I remove the Ethernet modules in FPGA? Thanks, Malihe Eric Blossom wrote: On Wed, Sep 01, 2010 at 07:07:26PM -0600, Malihe Ahmadi wrote: Hi, I am using USRP2+RFX2400 board and trying to adapt our packetized communication on the board. As I understand the Ethernet does its own packetization on information data and we don't like that. therefore we are looking into avoid passing our information data to the board through Ethernet. We are also fine to make the configuration values for other peripherals on the board (such as DAC, ADC and daughter boards) fixed so that we still can get away with no Ethernet interface. so we are interested to know if there is a general purpose input bus (at least 5 pins) that I can use to pass my data serially to the FPGA. The MICTOR debug connector, J301, has 32 uncommitted pins and 2 clks. It's currently configured as an output, but you can use it for whatever you like. Look in u2_rev3.v and/or u2_core.v. output [31:0] debug, output [1:0] debug_clk, That means I would like to see if it is possible to remove all the Verilog codes in FPGA related to handling the Ethernet interface and get the data I'd like to process through a general purpose input bus (at least 5 pins for clock and serial data input and 3 handshaking signals) instead of Ethernet port. For that reason, I need this general purpose bus to be physically accessible on the board so that I can connect them to a digital signal generator. Do you have any suggestion/recommendation for me? Thanks, Malihe Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
On 09/02/2010 02:48 PM, Malihe Ahmadi wrote: I need 5 mega bit per sec of bandwidth and if I understand correct the rate of CMII_TX_CLK is 100 mega bit per second which is higher than what I want. The first reason I don't like GiGe is that it chunks the data and it can cause delay in its stream (I rather have my own protocol to transmit data to the FPGA) but I think I can bear with that! The second reason is that I don't know what is the relation between the stream of data generated at the source (for example by sig_source_i()) and the GMII_TXD input signal to the FPGA and eventually sample_tx input of dsp_core_tx. Can somebody explain that relation for me? Also, does anybody have a ready to use Python code for USRP2 device which generates for example a SIN wave at the transmitter and captures it at the receives? Thanks, Malihe The rate that data is actually sent over the GiGe depends on your decimation/interpolation settings. The FPGA sees a continuous stream of numbers that represent a signal, generally sinusoidal in nature. That stream is a complex-baseband representation of your signal, which the FPGA will interpolate, possibly digitally upconvert, and present to the RF transmitter hardware. Similarly on receive the FPGA gathers the complex baseband data from the A/D, decimates and filters it, and presents it to the GiGe interface for transmission to the host as complex baseband samples. I think you may be confusing the data rate of whatever modulation scheme you want to use in your application, with the rate that the *waveform data* is presented into/out-of your Gnu Radio flow-graph. The packetization is generally not an issue, unless you are running at the edge where the host computer can't keep up, which produces overruns on receive, and under-runs on transmit. But for modest-bandwidth signals, with a decent CPU, this doesn't happen very often. The GiGe interface is simply a convenient and relatively-cheap way of getting complex-baseband data into/out-of the FPGA (along with the occasional programming instructions for the PLL synthesizers, gain controls, etc, on the daughter-cards). -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
Hi Nick, Actually we are using the USRP2 not for a SDR application, but we are using it to test our physical layer asynchronous backet based communication. For that I have to change the FPGA code and remove the interpolation/decimation and replace it with a spreading scheme. for that I need to know exactly what is the nature of data I am receiving at the FPGA and what is its maximum rate or forget about Ethernet and get a separate bus for me to pass the data to the FPGA . Assuming I want to use Ethernet, let's say I want to send the stream '011', and I pick DBPSK as the modulation. can you please explain what is the relation of the DBPSK modulated data and GMII_RXD input to the FPGA or sample input to the dsp_core_tx? is that FPGA receives 8 bits per symbol sent over Ethernet? Also, do you have a ready to use Python code for USRP2 device which generates for example a SIN wave at the transmitter and captures it at the receives? Thanks, Malihe Nick Foster wrote: Malihe, The USRP2 drivers are designed to abstract the user from the device transport, and in normal use you shouldn't have to concern yourself with the transport layer at all. You provide a stream of data in gnuradio, and the USRP2 provides a stream of data out the device (or vice versa). All the magic that happens between should be transparent. To the user, there is no packetization at all on transmitted data -- discrete Ethernet data packets are buffered in the USRP2 and transmitted seamlessly by the device. If you are seeing gaps in signal when viewed on a scope, you are probably experiencing buffer underruns caused by running at a data rate too fast for your CPU to handle. Can you explain the problem you are seeing with your device? Nick Date: Wed, 1 Sep 2010 19:07:26 -0600 From: ahmad...@ualberta.ca To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA? Hi, I am using USRP2+RFX2400 board and trying to adapt our packetized communication on the board. As I understand the Ethernet does its own packetization on information data and we don't like that. therefore we are looking into avoid passing our information data to the board through Ethernet. We are also fine to make the configuration values for other peripherals on the board (such as DAC, ADC and daughter boards) fixed so that we still can get away with no Ethernet interface. so we are interested to know if there is a general purpose input bus (at least 5 pins) that I can use to pass my data serially to the FPGA. That means I would like to see if it is possible to remove all the Verilog codes in FPGA related to handling the Ethernet interface and get the data I'd like to process through a general purpose input bus (at least 5 pins for clock and serial data input and 3 handshaking signals) instead of Ethernet port. For that reason, I need this general purpose bus to be physically accessible on the board so that I can connect them to a digital signal generator. Do you have any suggestion/recommendation for me? Thanks, Malihe ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
Hi Nick, Actually we are using the USRP2 not for a SDR application, but we are using it to test our physical layer asynchronous backet based communication. For that I have to change the FPGA code and remove the interpolation/decimation and replace it with a spreading scheme. for that I need to know exactly what is the nature of data I am receiving at the FPGA and what is its maximum rate or forget about Ethernet and get a separate bus for me to pass the data to the FPGA . Assuming I want to use Ethernet, let's say I want to send the stream '011', and I pick DBPSK as the modulation. can you please explain what is the relation of the DBPSK modulated data and GMII_RXD input to the FPGA or sample input to the dsp_core_tx? is that FPGA receives 8 bits per symbol sent over Ethernet? Also, do you have a ready to use Python code for USRP2 device which generates for example a SIN wave at the transmitter and captures it at the receives? Thanks, Malihe Nick Foster wrote: Malihe, The USRP2 drivers are designed to abstract the user from the device transport, and in normal use you shouldn't have to concern yourself with the transport layer at all. You provide a stream of data in gnuradio, and the USRP2 provides a stream of data out the device (or vice versa). All the magic that happens between should be transparent. To the user, there is no packetization at all on transmitted data -- discrete Ethernet data packets are buffered in the USRP2 and transmitted seamlessly by the device. If you are seeing gaps in signal when viewed on a scope, you are probably experiencing buffer underruns caused by running at a data rate too fast for your CPU to handle. Can you explain the problem you are seeing with your device? Nick Date: Wed, 1 Sep 2010 19:07:26 -0600 From: ahmad...@ualberta.ca To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA? Hi, I am using USRP2+RFX2400 board and trying to adapt our packetized communication on the board. As I understand the Ethernet does its own packetization on information data and we don't like that. therefore we are looking into avoid passing our information data to the board through Ethernet. We are also fine to make the configuration values for other peripherals on the board (such as DAC, ADC and daughter boards) fixed so that we still can get away with no Ethernet interface. so we are interested to know if there is a general purpose input bus (at least 5 pins) that I can use to pass my data serially to the FPGA. That means I would like to see if it is possible to remove all the Verilog codes in FPGA related to handling the Ethernet interface and get the data I'd like to process through a general purpose input bus (at least 5 pins for clock and serial data input and 3 handshaking signals) instead of Ethernet port. For that reason, I need this general purpose bus to be physically accessible on the board so that I can connect them to a digital signal generator. Do you have any suggestion/recommendation for me? Thanks, Malihe ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
Hi MArcus, Assuming I want to use Ethernet, let's say I want to send the stream '011', and I pick DBPSK as the modulation. can you please explain what is the relation of the DBPSK modulated data and GMII_RXD input to the FPGA or sample input to the dsp_core_tx? is that FPGA receives 8 bits per symbol sent over Ethernet? Also, can I get those occasional programming instructions you mentioned to be hard-coded (for example changing the firmware so that it uses some default values instead of passing those values through GiGe) if I am interested in removing Ethernet and using debug bus to pass stream of data to the FPGA? Thanks, Malihe Marcus D. Leech wrote: On 09/02/2010 02:48 PM, Malihe Ahmadi wrote: I need 5 mega bit per sec of bandwidth and if I understand correct the rate of CMII_TX_CLK is 100 mega bit per second which is higher than what I want. The first reason I don't like GiGe is that it chunks the data and it can cause delay in its stream (I rather have my own protocol to transmit data to the FPGA) but I think I can bear with that! The second reason is that I don't know what is the relation between the stream of data generated at the source (for example by sig_source_i()) and the GMII_TXD input signal to the FPGA and eventually sample_tx input of dsp_core_tx. Can somebody explain that relation for me? Also, does anybody have a ready to use Python code for USRP2 device which generates for example a SIN wave at the transmitter and captures it at the receives? Thanks, Malihe The rate that data is actually sent over the GiGe depends on your decimation/interpolation settings. The FPGA sees a continuous stream of numbers that represent a signal, generally sinusoidal in nature. That stream is a complex-baseband representation of your signal, which the FPGA will interpolate, possibly digitally upconvert, and present to the RF transmitter hardware. Similarly on receive the FPGA gathers the complex baseband data from the A/D, decimates and filters it, and presents it to the GiGe interface for transmission to the host as complex baseband samples. I think you may be confusing the data rate of whatever modulation scheme you want to use in your application, with the rate that the *waveform data* is presented into/out-of your Gnu Radio flow-graph. The packetization is generally not an issue, unless you are running at the edge where the host computer can't keep up, which produces overruns on receive, and under-runs on transmit. But for modest-bandwidth signals, with a decent CPU, this doesn't happen very often. The GiGe interface is simply a convenient and relatively-cheap way of getting complex-baseband data into/out-of the FPGA (along with the occasional programming instructions for the PLL synthesizers, gain controls, etc, on the daughter-cards). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
Hi Nick, I think I should explain my project better. We are developing a physical layer protocol for an asynchronous packet based transceiver all in Verilog. The design has been simulated so far using ModelSim. The target of the project is the VLSI fabrication of this design. Thus all the signal processing (digital modulation (for now we are interested in BPSK digital modulation), packetization, spreading, filtering ) has to be done in FPGA, and it should be as stand alone as possible. The reason we picked USRP2 was that it was a compact board with RF specification quite close to our requirements. Our understanding was that we can get one computer (host) to transmit stream of bits to the USRP2, do the processing in FPGA and send the data over air, and the second USRP2 would capture the signal and again FPGA would do the processing and eventually pass the data (through Ethernet) to the second host (computer). I thought, if I generate a stream of bits in the first host (TX) and do BPSK modulation and pass them to the USRP2 using Gnuradio, the two 16 bit I and Q port that I get at the DSP core of the FPGA are two bytes of that stream of bits and now I can continue with packetization and the rest of my processing inside FPGA (basically replacing the interpolation module with my spreading module) and redo that process at the receiver to retrieve the generated bit stream. I have already read through the DSP codes inside the FPGA. What I understand from your email below was that I can't retrieve the bit stream (generated at the host) in the FPGA and the 16 bits I and Q are modulated, shaped sample representation of the bit stream. This is a bit confusing for me because I thought (assuming the host just generates the bits and does the BPSK modulation) the Ethernet decoder (DP83865) of the USRP2 is basically compensating (undo-ing) the processing that was performed on the bits (by Ethernet encoder) right before they leave the host (computer) so that the Ethernet becomes transparent. If that is not the case, my only solution is to pass the bit stream to the FPGA using the debug port! Would you please let me know which part of my assumption is wrong? Thanks, Malihe Nick Foster wrote: Malihe, Date: Thu, 2 Sep 2010 14:19:54 -0600 From: ahmad...@ualberta.ca Actually we are using the USRP2 not for a SDR application, but we are using it to test our physical layer asynchronous backet based communication. For that I have to change the FPGA code and remove the interpolation/decimation and replace it with a spreading scheme. Assuming your spreading doesn't bring your bandwidth over around 25MHz, you should be able to do the spreading operation on the host and transmit the spread baseband data to the USRP2 via Gnuradio. The host typically does not send unmodulated data to the USRP2; the host side, usually using Gnuradio, performs the desired DSP operations on your raw information such as spreading, shaping, and modulating, and sends the resulting complex waveform to the USRP2 as raw 16-bit samples. The USRP2 itself knows nothing about your original unmodulated data. for that I need to know exactly what is the nature of data I am receiving at the FPGA and what is its maximum rate or forget about Ethernet and get a separate bus for me to pass the data to the FPGA . The data you are receiving at the FPGA is whatever you send to it -- the interpolation rate you pick determines the sample rate the USRP2 will run at. The interpolator will handle upsampling the raw samples to match the data rate the DACs run at. It's up to you (using Gnuradio) to encode your data into an appropriate waveform for your application. Assuming I want to use Ethernet, let's say I want to send the stream '011', and I pick DBPSK as the modulation. can you please explain what is the relation of the DBPSK modulated data and GMII_RXD input to the FPGA or sample input to the dsp_core_tx? is that FPGA receives 8 bits per symbol sent over Ethernet? Whatever raw samples you send into gnuradio get sent to the FPGA (I'm simplifying here: see the link below for details). The USRP2 itself does not know or care that you are using DBPSK or that you are sending '011'. It sounds like you might have a misconception of exactly what the USRP2 is doing. This FAQ is for the USRP1, but the overall description applies also to the USRP2: http://gnuradio.org/redmine/wiki/gnuradio/UsrpFAQ Also, do you have a ready to use Python code for USRP2 device which generates for example a SIN wave at the transmitter and captures it at the receives? A simple GRC flowgraph would perform this function for you. You can use a signal source to feed a USRP2 sink, and then a USRP2 source to feed an FFT sink (or whatever sink you like). The parameters for these blocks depend on what daughterboards you are using for TX and RX and whether you are using the UHD driver or
Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
On 09/02/2010 05:11 PM, Malihe Ahmadi wrote: Hi MArcus, Assuming I want to use Ethernet, let's say I want to send the stream '011', and I pick DBPSK as the modulation. can you please explain what is the relation of the DBPSK modulated data and GMII_RXD input to the FPGA or sample input to the dsp_core_tx? is that FPGA receives 8 bits per symbol sent over Ethernet? Also, can I get those occasional programming instructions you mentioned to be hard-coded (for example changing the firmware so that it uses some default values instead of passing those values through GiGe) if I am interested in removing Ethernet and using debug bus to pass stream of data to the FPGA? Thanks, Malihe Marcus D. Leech wrote: Well, I'm not an expert in the way the FPGA works internally, nor on the signals going into or out of if, but the GMII_RXD pin is likely the RXD pin from the 1GiG Ethernet Phy. Your DBPSK modulated bits stream is represented as a discrete-sampled time-series, those (complex) samples are presented to the Ethernet interface, sent over the Ethernet to the FPGA, where those samples are possibly interpolated by the FPGA up to the sample rate of the A/D (200MHz), from the output side of the A/D the signal is a complex analog baseband representation of the signal, which is then typically upconverted to the final target frequency. The normal way that discrete-sampled time series gets to appear at the FPGA is that the resulting waveform is created by a Gnu Radio flow graph that includes the proper modulation stuff to take a series of bits (like your 011) and turn it into a complex baseband waveform. Now, you want to avoid the SDR aspects altogether, and do everything inside the FPGA. So you want to use the USRP2 essentially as your wireless PHY, and totally ignore the SDR aspects of the USRP2 design. You want to know if there are pins available on the FPGA to allow it to take your bits (and related clocks), and have the FPGA do the necessary modulation and spreading, in a standalone manner. I think Eric Blossom already mentioned the MICTOR interface, which may do what you want. Assuming that the MICTOR or some other interface on the FPGA will do what you want, and there's enough room inside the FPGA, then I don't see that you'll have a problem. You can certainly hard-code whatever daughter-card setup you need inside the firmware. You'll find that if you want detailed help making this work, you'll have a hard time finding anyone who'll give you that help for free. The FPGA and aeMB firmware is freely available, and you'll likely get some hints and tips from time to time. But what you're contemplating is a fairly major project that is, to a first approximation, outside of the strict confines of Gnu Radio. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
Malihe, Your understanding is basically correct. I misunderstood your request -- I didn't realize you had an existing FPGA design you were integrating with the USRP2, and figured you were going about things the hard way. Nothing happens to Ethernet packets between the host transmission and GMII_TX -- the USRP2 MAC receives the same data that goes out the host MAC. I was trying to say that modulation is typically done in Gnuradio, not in the FPGA, and so data on the wire is typically baseband modulated and not a data bitstream. If you are implementing the modulation in FPGA you are of course free to define the data on the wire however you like. For your purposes you should be able to take your data straight from the MAC and buffer and encode it in whatever way you see fit. Nick Date: Thu, 2 Sep 2010 18:30:22 -0600 From: ahmad...@ualberta.ca To: bistro...@hotmail.com CC: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA? Hi Nick, I think I should explain my project better. We are developing a physical layer protocol for an asynchronous packet based transceiver all in Verilog. The design has been simulated so far using ModelSim. The target of the project is the VLSI fabrication of this design. Thus all the signal processing (digital modulation (for now we are interested in BPSK digital modulation), packetization, spreading, filtering ) has to be done in FPGA, and it should be as stand alone as possible. The reason we picked USRP2 was that it was a compact board with RF specification quite close to our requirements. Our understanding was that we can get one computer (host) to transmit stream of bits to the USRP2, do the processing in FPGA and send the data over air, and the second USRP2 would capture the signal and again FPGA would do the processing and eventually pass the data (through Ethernet) to the second host (computer). I thought, if I generate a stream of bits in the first host (TX) and do BPSK modulation and pass them to the USRP2 using Gnuradio, the two 16 bit I and Q port that I get at the DSP core of the FPGA are two bytes of that stream of bits and now I can continue with packetization and the rest of my processing inside FPGA (basically replacing the interpolation module with my spreading module) and redo that process at the receiver to retrieve the generated bit stream. I have already read through the DSP codes inside the FPGA. What I understand from your email below was that I can't retrieve the bit stream (generated at the host) in the FPGA and the 16 bits I and Q are modulated, shaped sample representation of the bit stream. This is a bit confusing for me because I thought (assuming the host just generates the bits and does the BPSK modulation) the Ethernet decoder (DP83865) of the USRP2 is basically compensating (undo-ing) the processing that was performed on the bits (by Ethernet encoder) right before they leave the host (computer) so that the Ethernet becomes transparent. If that is not the case, my only solution is to pass the bit stream to the FPGA using the debug port! Would you please let me know which part of my assumption is wrong? Thanks, Malihe Nick Foster wrote: Malihe, Date: Thu, 2 Sep 2010 14:19:54 -0600 From: ahmad...@ualberta.ca Actually we are using the USRP2 not for a SDR application, but we are using it to test our physical layer asynchronous backet based communication. For that I have to change the FPGA code and remove the interpolation/decimation and replace it with a spreading scheme. Assuming your spreading doesn't bring your bandwidth over around 25MHz, you should be able to do the spreading operation on the host and transmit the spread baseband data to the USRP2 via Gnuradio. The host typically does not send unmodulated data to the USRP2; the host side, usually using Gnuradio, performs the desired DSP operations on your raw information such as spreading, shaping, and modulating, and sends the resulting complex waveform to the USRP2 as raw 16-bit samples. The USRP2 itself knows nothing about your original unmodulated data. for that I need to know exactly what is the nature of data I am receiving at the FPGA and what is its maximum rate or forget about Ethernet and get a separate bus for me to pass the data to the FPGA . The data you are receiving at the FPGA is whatever you send to it -- the interpolation rate you pick determines the sample rate the USRP2 will run at. The interpolator will handle upsampling the raw samples to match the data rate the DACs run at. It's up to you (using Gnuradio) to encode your data into an appropriate waveform for your application. Assuming I want to use Ethernet, let's say I want to send the stream '011', and I
[Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
Hi, I am using USRP2+RFX2400 board and trying to adapt our packetized communication on the board. As I understand the Ethernet does its own packetization on information data and we don't like that. therefore we are looking into avoid passing our information data to the board through Ethernet. We are also fine to make the configuration values for other peripherals on the board (such as DAC, ADC and daughter boards) fixed so that we still can get away with no Ethernet interface. so we are interested to know if there is a general purpose input bus (at least 5 pins) that I can use to pass my data serially to the FPGA. That means I would like to see if it is possible to remove all the Verilog codes in FPGA related to handling the Ethernet interface and get the data I'd like to process through a general purpose input bus (at least 5 pins for clock and serial data input and 3 handshaking signals) instead of Ethernet port. For that reason, I need this general purpose bus to be physically accessible on the board so that I can connect them to a digital signal generator. Do you have any suggestion/recommendation for me? Thanks, Malihe ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
Malihe, The USRP2 drivers are designed to abstract the user from the device transport, and in normal use you shouldn't have to concern yourself with the transport layer at all. You provide a stream of data in gnuradio, and the USRP2 provides a stream of data out the device (or vice versa). All the magic that happens between should be transparent. To the user, there is no packetization at all on transmitted data -- discrete Ethernet data packets are buffered in the USRP2 and transmitted seamlessly by the device. If you are seeing gaps in signal when viewed on a scope, you are probably experiencing buffer underruns caused by running at a data rate too fast for your CPU to handle. Can you explain the problem you are seeing with your device? Nick Date: Wed, 1 Sep 2010 19:07:26 -0600 From: ahmad...@ualberta.ca To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA? Hi, I am using USRP2+RFX2400 board and trying to adapt our packetized communication on the board. As I understand the Ethernet does its own packetization on information data and we don't like that. therefore we are looking into avoid passing our information data to the board through Ethernet. We are also fine to make the configuration values for other peripherals on the board (such as DAC, ADC and daughter boards) fixed so that we still can get away with no Ethernet interface. so we are interested to know if there is a general purpose input bus (at least 5 pins) that I can use to pass my data serially to the FPGA. That means I would like to see if it is possible to remove all the Verilog codes in FPGA related to handling the Ethernet interface and get the data I'd like to process through a general purpose input bus (at least 5 pins for clock and serial data input and 3 handshaking signals) instead of Ethernet port. For that reason, I need this general purpose bus to be physically accessible on the board so that I can connect them to a digital signal generator. Do you have any suggestion/recommendation for me? Thanks, Malihe ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?
On Wed, Sep 01, 2010 at 07:07:26PM -0600, Malihe Ahmadi wrote: Hi, I am using USRP2+RFX2400 board and trying to adapt our packetized communication on the board. As I understand the Ethernet does its own packetization on information data and we don't like that. therefore we are looking into avoid passing our information data to the board through Ethernet. We are also fine to make the configuration values for other peripherals on the board (such as DAC, ADC and daughter boards) fixed so that we still can get away with no Ethernet interface. so we are interested to know if there is a general purpose input bus (at least 5 pins) that I can use to pass my data serially to the FPGA. The MICTOR debug connector, J301, has 32 uncommitted pins and 2 clks. It's currently configured as an output, but you can use it for whatever you like. Look in u2_rev3.v and/or u2_core.v. output [31:0] debug, output [1:0] debug_clk, That means I would like to see if it is possible to remove all the Verilog codes in FPGA related to handling the Ethernet interface and get the data I'd like to process through a general purpose input bus (at least 5 pins for clock and serial data input and 3 handshaking signals) instead of Ethernet port. For that reason, I need this general purpose bus to be physically accessible on the board so that I can connect them to a digital signal generator. Do you have any suggestion/recommendation for me? Thanks, Malihe Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
