[Discuss-gnuradio] Ethernet and bursting
Hi, Im trying to understand a little more about the Ethernet communication model used for GNU Radio. I notice that the frames have start of burst and end of burst flags. Is this related to sending Ethernet frames? How many frames can be sent in a single burst? If these are not related to Ethernet, what is their purpose? Any good documents to look at relating to this? Thanks. Charles ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
> I would tend to blame Linux and buffering more than GbE itself (MAC + PHY). > Here is an interesting doc where the > researchers were asking similar questions: > > http://www.hep.man.ac.uk/u/rich/atlas/docs/atlas_net_note_draft5.pdf > > I'm not sure yet how much buffering is done in the USRP2 firmware but we hope > to know shortly as a couple of our guys > are in the process of taking apart the logic, pulling out non-GbE related > sections, and rebuilding. > > -Jeff I glanced over the document briefly and was wondering if your analysis of the linux issue was because of this document, or a separate source. I'm only asking because the document is 10 years old and is using RedHat 5 and Pentium 2s. I would assume the linux kernel support for GigE has improved since then. Charles ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
Thanks for the reply George. I'm still looking for a little more information on this topic. - What is PMT - Why was m-block removed - Has anyone measured latency with the USRP2 and GigE - Is GigE alone not capable of handling MAC turnaround times or is software to blame for this - Is the scheduler the main issue in the way it handles i/o between blocks Charles On Sun, Mar 14, 2010 at 5:52 PM, George Nychis wrote: > Think of it this way... > > MAC *development* is severely limited by GNU Radio... it lacks the > much-needed functionality to make information passing between the > blocks rich, simple, and bi-directional. Some of the building blocks > are in place (e.g., PMT), and the m-block was implemented to solve the > rest of the problems, but was deprecated (maybe removed as of now?). > > MAC *performance* is limited by several things: 1) delay between GNU > Radio and the USRP/USRP2, 2) signal processing delay (GNU Radio), and > (3) jitter (e.g., unpredictable delay) ... (1) is reduced a little by > USRP2 using GigE, but it's still not down to traditional MAC > turnaround times (10s of us). (2) benefits from Moore's law. (3) > kind of depends on whether you use realtime scheduling and how your > data hits delays in queues mainly. > > All in all... still an open problem IMO. > > - George > > > On Sun, Mar 14, 2010 at 5:06 PM, Charles Irick wrote: >> I've been reading some papers related to MAC layer development on the >> USRP, but they seem to have tapered off with the USRP2. Does anyone >> have any information about MAC layer and protocol development for the >> USRP2. Has this been satisfied with things like timestamps and gigE? >> Any current papers or web links related to USRP2 protocol level >> development? Thanks. >> >> Charles >> >> >> ___ >> 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 source and receiving samples question
Hi,
I made a lower level c++ implementation using the code from
rx_streaming_samples.cc in /usrp2/host/apps and manually put in a tx
before the receive portion and it works fine. It seems the issue is
related to noutput_items in my gr- module. As I stated above it uses
8162 for noutput_items for whatever reason and this is what is used to
define the maximum number of samples for the rx_nop_handler. The
reason the c++ one works is because the rx_nop_handler is created with
an nsamples value that is expected which lets has_finished_p() be
triggered. If I manually put in 8162 into the rx_nop_handler in the
c++ implementation I get the "never ending can't even control-c have
to sudo kill the process" behavior as I was in the python
implementation. I'm not adept at the GNU Radio scheduler or this SWIG
stuff, so if anyone could give me some idea of how the number of
output items is determined or why my module is saying it needs 8162 I
would appreciate it.
Charles
On Sat, Apr 3, 2010 at 12:15 PM, Charles Irick wrote:
> Hi,
> I'm trying to write a module that works almost identical to the
> usrp2_source_16sc module, but I'm having trouble with receiving the
> samples. It seems my module is never satisfied with the amount of data
> I send it, it just keeps polling for data in the background loop. What
> I want to do is send a file, run it through a loopback on an external
> hardware device, then read it back in on the host. Here is what my
> code does:
>
> self.asink = afpga.sink_raw(options.interface)
> self.asrc = afpga.source_raw(options.interface)
>
> self.input = gr.file_source(gr.sizeof_int,"in.txt",0) #only send once
> self.output = gr.file_sink(gr.sizeof_int,"out.txt")
>
> self.connect (self.input,self.asink)
> self.connect (self.asrc, self.output)
>
> #control stuff
> tb.start()
> raw_input('Press Enter to quit: \n')
> tb.stop()
> tb.wait()
>
>
> Pretty simple stuff. I the data loops back correctly and my handler
> shows nsamples as correct, but my program never halts or writes the
> samples to the file. It actually won't even let me control-c my python
> script. The only odd thing to me is that noutput_items for my work
> function is 8162. Not sure how this value is set, but to me it should
> be the number of samples.
>
> Some output (file gets split up into two frames, one with 371 samples
> and the second with 142):
> work: noutput items 8162
> data handler: len: 1512
> rx_samples: want more
> work: handled 371 samples
>
> noutput items 8162
> data handler: len: 596
> rx_samples want more
> work:handled 142 samples
> poll for more samples forever..
>
> Any ideas or a description on how the receive system works would be
> much appreciated.
>
> version 3.2.2
> Ubuntu 9.04
>
> Thanks,
> Charles
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 source and receiving samples question
Hi,
I'm trying to write a module that works almost identical to the
usrp2_source_16sc module, but I'm having trouble with receiving the
samples. It seems my module is never satisfied with the amount of data
I send it, it just keeps polling for data in the background loop. What
I want to do is send a file, run it through a loopback on an external
hardware device, then read it back in on the host. Here is what my
code does:
self.asink = afpga.sink_raw(options.interface)
self.asrc = afpga.source_raw(options.interface)
self.input = gr.file_source(gr.sizeof_int,"in.txt",0) #only send once
self.output = gr.file_sink(gr.sizeof_int,"out.txt")
self.connect (self.input,self.asink)
self.connect (self.asrc, self.output)
#control stuff
tb.start()
raw_input('Press Enter to quit: \n')
tb.stop()
tb.wait()
Pretty simple stuff. I the data loops back correctly and my handler
shows nsamples as correct, but my program never halts or writes the
samples to the file. It actually won't even let me control-c my python
script. The only odd thing to me is that noutput_items for my work
function is 8162. Not sure how this value is set, but to me it should
be the number of samples.
Some output (file gets split up into two frames, one with 371 samples
and the second with 142):
work: noutput items 8162
data handler: len: 1512
rx_samples: want more
work: handled 371 samples
noutput items 8162
data handler: len: 596
rx_samples want more
work:handled 142 samples
poll for more samples forever..
Any ideas or a description on how the receive system works would be
much appreciated.
version 3.2.2
Ubuntu 9.04
Thanks,
Charles
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bpsk Simulation
Hi, I'm also having issues with the use of this block if I try the same concept. I'm not concerned with the noise generation and just want to modulate and then demodulate data. I am using the vector creation and packing as stated above. The results I'm getting are deterministic, just incorrect. Here is what i'm using: 099 self.src_data = 3 * [0x40,0x41,0x42,0x43,] 100 self.src0 = gr.vector_source_b(self.src_data) 101 self.mod = blks2.dbpsk_mod(8,0.35,False,True,False) 102 self.demod = blks2.dbpsk_demod(8,0.35,0.1,None,0.5,0.005,False,True,False) 103 self.pack = gr.unpacked_to_packed_bb(1,gr.GR_MSB_FIRST) 104 self.connect(self.src0,self.mod,self.demod,self.pack) 105 106 self.sink1 = gr.vector_sink_b() 107 self.connect(self.pack,self.sink1) 108 109 self.sink2 = gr.vector_sink_b() 110 self.connect = (self.src0,self.sink2) 111 112 def print_data(self): 113 print "data: ",self.src_data 114 print len(self.src_data) 115 print "demod: ",self.sink1.data() 116 print len(self.sink1.data()) 117 print "check: ",self.sink2.data() 118 print len(self.sink2.data()) Here is the output: >>> gr_fir_ccf: using SSE Modulator: bits per symbol: 1 Gray code: False RRC roll-off factor: 0.35 Demodulator: bits per symbol: 1 Gray code: False RRC roll-off factor: 0.35 Costas Loop alpha: 1.00e-01 Costas Loop beta:2.50e-03 M&M mu: 0.50 M&M mu gain: 1.00e-01 M&M omega: 8.00 M&M omega gain: 2.50e-03 M&M omega limit: 0.01 data: [64, 65, 66, 67, 64, 65, 66, 67, 64, 65, 66, 67] 12 demod: (1, 239, 1, 5, 9, 13, 1, 5, 9, 13, 1) 11 check: () 0 Thanks in advance for any help On Thu, Mar 11, 2010 at 11:43 AM, Tom Rondeau wrote: > On Thu, Mar 11, 2010 at 4:09 AM, Axel Belliard wrote: >> Hi, >> >> I'm new to gnu radio. To get familiar with this project, I'm trying to >> simulate a dbpsk link. >> >> My flow graph look like this : >> stream of bits => Modulation => frequency up translation => Noisy channel >> => frequency down translation => Demodulation >> >> But, there is something going wrong!! If the input stream looks like this >> : 0 0 1 1 0 0 1 1 0 0 1 1. the output will be ( after Costa's loop and >> MM are stabilized ) : 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1.. >> I looked for an undesired decimation, but didn't find any. Do you Have >> any idea of what is going wrong? >> >> Axel > > This is a bit confusing, but it makes sense in the way we meant for > the digital modulators to work. The problem is that you are trying to > put in "bits" into the modulator, which actually takes a "packet" > stream of bits. In other words, when you think you are putting in the > bits "0 0 1 1," you are actually telling it that you are putting in > the bytes "0 0 1 1" that gets unpacked into the bit stream "0 0 0 0 0 > 0 0 0, 0 0 0 0 0 0 0 0, 0 0 0 0 0 0 0 1, 0 0 0 0 0 0 0 1" or "0x00 > 0x00 0x01 0x01". > > What you want to put in as the source is a vector of "0x33" instead. > You can also use the gr.unpacked_to_packed_bb on the demod side to > repack the bits. I've edited your code below to show how to do this. > Now, when you do this, you're still going to see some random stuff > going on in the output stream for the first few symbols. These garbage > bits are due to the filters' group delays. > > One final thought. You're doing a frequency shift operation on the > complex baseband signal and then almost immediately downconverting it. > This doesn't really do anything of any consequence to your simulation > except require you to use a larger sampling rate than really required. > If you want to test frequency offset errors, you can use the features > in the channel model that we have (blks2.channel_model), which takes > in a noise voltage, frequency offset, timing offset, and a vector of > taps to simulate multipath. > > >> My code : >> class my_top_block(gr.top_block): >> def __init__(self): >> gr.top_block.__init__(self) >> fg = gr.flow_graph() >> >> sps = 8 >> symbol_rate = 1625000.0 / 6.0 >> sample_rate = sps * symbol_rate >> p_size = 1024 >> lo_freq = 7.5e5 >> lp_cutoff = 2.5e5 >> lp_tw = 5e5 >> noise_mag = 0.0 >> #Source > > N = > self.src_data = N*[0x33, ] # make an N-long vector > with 0x33 in every element > >> self.src0 = gr.vector_source_b (self.src_data) >> ## >> >> ###Modulation >> self.objMod = dbpsk.dbpsk_mod(sps,0.35,False,False,False) >> # >> >> ### Canal >> # Mix to IF >> self.lo = gr.sig_source_c(sample_rate, gr.GR_SIN_WAVE, >> lo_freq,1.0, 0) >> self.mixer
[Discuss-gnuradio] MAC layer development and USRP2
I've been reading some papers related to MAC layer development on the USRP, but they seem to have tapered off with the USRP2. Does anyone have any information about MAC layer and protocol development for the USRP2. Has this been satisfied with things like timestamps and gigE? Any current papers or web links related to USRP2 protocol level development? Thanks. Charles ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Issue transmitting samples using vector i/o
I'm running into issues with the sendmsg command in the vectorized send path. Depending on the buffer size I get an error returned for "Bad Address" >> ethernet:write_packetv: send: Bad address I'm working at the c++ level right now and my program is pretty simple: usrp2::usrp2::sptr u2 = usrp2::usrp2::make(interface,mac_addr); usrp2::tx_metadatamd; md.timestamp = -1; md.start_of_burst = 1; md.send_now = 1; uint32_t buf[1000]; u2->tx_raw(0,buf,sizeof(buf),&md); around a buffer size of 200 I will start seeing some sends get bad address returned, for a size less than 200 it may happen but I have not seen any occurrences. Something like a buffer of 1000 (11 frames needed to be transmitted) never succeeds. Any ideas about the relation between this buffer size/num frames and sendmsg returning bad address? Am I using this incorrectly (i know I should be using something like tx_fc32, but the data doesn't matter to me right now) ? Also, what are the reasons for using the vector i/o in this instance? OS: Ubuntu 9.04 Using dev code from git Charles ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Understanding flow control
Hello, I'm trying to understand the flow control between the USRP2 and host machine. I assume that it needs to be worked out where the USRP2 will always have a constant stream of uninterrupted radio data when sending and receiving (unless a more complex radio is in place which allows the signal to drop). I have read that overruns are not really an issue, is this due to the processing power/throughput of the spartan 3 vs the host processor? I see that pause frames are used to help with flow control but I can only see this being used if an overrun or full fifo has occured on the USRP2, what happens if the fifo becomes empty? I'm trying to catch the pause frames with tcp dump and i'm either doing it wrong or they are not happening. I have tried usrp2_siggen and usrp2_fft. I'm using the dev code from git on ubuntu 9.04 with gnuradio 3.2.2 We are either overflowing, underflowing, or are perfectly in sync. Only overflow with pause frames to control makes sense to me. If this is not the case an explanation would be very much appreciated. Charles ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] carrier signal dropping
FYI, the new git repo doesn't seem to have usrp2_siggen.py under gr-utils. usrp_siggen.py seems to work in the same way with minor differences but the naming makes it seem like it's for the original usrp. I probably wouldn't have thought it was compatible if I was just poking around for the first time. Charles On Wed, Jan 6, 2010 at 4:42 PM, Eric Blossom wrote: > On Wed, Jan 06, 2010 at 04:32:21PM -0500, Charles Irick wrote: >> My apologies, >> Distro: Ubuntu 9.04 >> Kernel: 2.6.28-17-generic >> GNU Radio version: I'm pretty sure it's 3.2.2, I'm using the dev trunk >> but svn doesn't seem to allow me to update right now. >> >> It is indeed complaining about not being able to enable real-time >> scheduling. Since you asked I assumed this was the issue and looked it >> up. It turns out even though I set up the USRP2 to run as non-root by >> changing the permissions of usrp2_socket_opener, this was the issue. >> It seems to work fine as root. I'm guess the tx fifo was emptying >> without scheduling? Is there anywhere that I can read up on this >> real-time scheduling because I will definitely need to solve some >> similar issues in the future. >> >> > > > Edit /etc/security/limits.conf and add this line: > > @usrp - rtprio 50 > > make sure that your user is a member of group usrp, then logout and back in. > > Eric > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] carrier signal dropping
My apologies, Distro: Ubuntu 9.04 Kernel: 2.6.28-17-generic GNU Radio version: I'm pretty sure it's 3.2.2, I'm using the dev trunk but svn doesn't seem to allow me to update right now. It is indeed complaining about not being able to enable real-time scheduling. Since you asked I assumed this was the issue and looked it up. It turns out even though I set up the USRP2 to run as non-root by changing the permissions of usrp2_socket_opener, this was the issue. It seems to work fine as root. I'm guess the tx fifo was emptying without scheduling? Is there anywhere that I can read up on this real-time scheduling because I will definitely need to solve some similar issues in the future. On Wed, Jan 6, 2010 at 4:10 PM, Eric Blossom wrote: > On Wed, Jan 06, 2010 at 03:44:26PM -0500, Charles Irick wrote: >> Hello, >> I hooked my usrp2 up to a spectrum analyzer and tried using the signal >> generator in gr-utils to see what I could get. The carrier signal >> seems to be turning on and off and I'm getting a lot of peaks at >> various frequencies probably from the carrier turning back on. Is this >> a code issue, normal behavior, or something I'm doing wrong? >> > > Exactly what command line did you use? > What version of GNU Radio? > Did it complain about not being able to enable real-time scheduling? > What OS, distribution, hardware? > > In general, we can be of more use to you if you follow these tips: > > http://gnuradio.org/redmine/wiki/gnuradio/ReportingErrors > > Eric > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] carrier signal dropping
Hello, I hooked my usrp2 up to a spectrum analyzer and tried using the signal generator in gr-utils to see what I could get. The carrier signal seems to be turning on and off and I'm getting a lot of peaks at various frequencies probably from the carrier turning back on. Is this a code issue, normal behavior, or something I'm doing wrong? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Issues with porting a radio design to USRP2
Hello, I'm currently trying to port a radio design to the USRP2 platform but I am having a few issues. The current radio hardware contains a DAC with variable sampling rates allowing for it to be a multiple of the bitrate. It is currently using an IF of 60Mhz and a bitrate of 6Mbps. I'm wondering if there are any utilities the USRP2 provides for designing radios where the sampling rate and bitrate are not multiples, such as a DDS, given that the sampling rate is locked to 100MS/s. Thanks in advance. Charles ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using the MIMO port for serial comm. to a Virtex5 board
Thank you for the fast reply. It looks like I need the SATA fanout connectors to be the host in this case because pin 2-3 are TX for the SATA port. Would there be any issue having the mini-SAS as the target? (part: iSAS-7P88-U) Charles On Mon, Dec 7, 2009 at 2:29 PM, Matt Ettus wrote: > On 12/07/2009 11:17 AM, Charles Irick wrote: >> >> Hello, >> I am narrowing down my issues and I think my problem is related to >> physically connecting the USRP2 to the V5 and it being a host to host >> connection. (I think I have Tx connected to Tx and Rx to Rx) For >> verification, are the A1-A13 pins on top or the B1-B13 pins for the >> mini-SAS port? ( >> http://gnuradio.org/trac/attachment/wiki/USRP2Schem/expansion.pdf ) My >> guess is that the B1-B13 pins are at the top with B1 being in the top >> left corner if you are looking at the port on the front of the USRP2. > > > All outputs are on B, which is on top. > > >> Also, when using two USRP2s you should have this same host to host >> issue, is this resolved because the mimo cable is a crossover? Thanks >> in advance for any help. > > All SAS cables are what you would call crossover. A on one side connects to > B on the other. Wiring diagrams are here: > > http://www.cs-electronics.com/isas-cables-NEW.htm > > > >> >> Charles >> >> On Tue, Dec 1, 2009 at 4:30 PM, Matt Ettus wrote: >>> >>> On 12/01/2009 12:58 PM, Charles Irick wrote: >>>> >>>> Hello, >>>> I'm most likely having a clock issue because I cannot get any data >>>> transfers going between the USRP2 and GTPs on the V5. A few questions: >>>> >>>> - I'm not quite sure I understand the 10MHz reference clock idea, or >>>> its usage; I looked through the HDL and everything on the FPGA is >>>> running at 100MHz. >>> >>> The 10 MHz reference input on the front is optional. If you connect it >>> and >>> enable locking, the 100 MHz main oscillator will lock to it, otherwise it >>> will free run. Everything inside the FPGA runs at 100 MHz (DSP) or 50 >>> MHz >>> (processor). >>> >>> There is also a 10 MHz reference clock sent out on the MIMO connector. >>> When >>> turned on, it will be the 100 MHz clock divided down by 10. >>> >>>> - I assume I will not need to provide this reference clock if the >>>> USRP2 is the driver given that sd_gentest appears to do so in the main >>>> functions clocks_mimo_config. Either way I'm using the SAS to quad >>>> SATA cable so the clock isn't even transferred to the GTPs (literally, >>>> it's supposed to derive it from the data). >>> >>> sd_gentest will generate packets and send them on the serdes on the MIMO >>> cable. You should be able to receive it without using the 10 MHz >>> reference >>> clock because, as you say, the clock is recovered from the data. >>> >>>> - My only clocking options on the GTP's are 150 or 75MHz. I'm not sure >>>> if I should clock the USRP2's FPGA or the reference differently to >>>> match this. >>> >>> >>> The important thing is that you get the GTPs set up for the correct data >>> rate. On the USRP2, the main clock to the SERDES chip is 100 MHz. 2 >>> Bytes >>> are sent on each clock, so the effective data rate is 1.6 Gbps. However, >>> since 8b-10b coding is used, the on the wire bit rate is 2.0 Gbps >>> (20*100MHz). So whatever reference clock you use, you need the GTP to be >>> working at 2 Gbps. I am by no means an expert on the GTPs, but I think >>> the >>> easiest way to do this is to have a reference clock of 100 MHz. >>> >>> You could probably use the PLLs in the V5 to create a 100 MHz reference >>> clock from one of your other clock rates. >>> >>> Matt >>> > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using the MIMO port for serial comm. to a Virtex5 board
Hello, I am narrowing down my issues and I think my problem is related to physically connecting the USRP2 to the V5 and it being a host to host connection. (I think I have Tx connected to Tx and Rx to Rx) For verification, are the A1-A13 pins on top or the B1-B13 pins for the mini-SAS port? ( http://gnuradio.org/trac/attachment/wiki/USRP2Schem/expansion.pdf ) My guess is that the B1-B13 pins are at the top with B1 being in the top left corner if you are looking at the port on the front of the USRP2. Also, when using two USRP2s you should have this same host to host issue, is this resolved because the mimo cable is a crossover? Thanks in advance for any help. Charles On Tue, Dec 1, 2009 at 4:30 PM, Matt Ettus wrote: > On 12/01/2009 12:58 PM, Charles Irick wrote: >> >> Hello, >> I'm most likely having a clock issue because I cannot get any data >> transfers going between the USRP2 and GTPs on the V5. A few questions: >> >> - I'm not quite sure I understand the 10MHz reference clock idea, or >> its usage; I looked through the HDL and everything on the FPGA is >> running at 100MHz. > > The 10 MHz reference input on the front is optional. If you connect it and > enable locking, the 100 MHz main oscillator will lock to it, otherwise it > will free run. Everything inside the FPGA runs at 100 MHz (DSP) or 50 MHz > (processor). > > There is also a 10 MHz reference clock sent out on the MIMO connector. When > turned on, it will be the 100 MHz clock divided down by 10. > >> - I assume I will not need to provide this reference clock if the >> USRP2 is the driver given that sd_gentest appears to do so in the main >> functions clocks_mimo_config. Either way I'm using the SAS to quad >> SATA cable so the clock isn't even transferred to the GTPs (literally, >> it's supposed to derive it from the data). > > sd_gentest will generate packets and send them on the serdes on the MIMO > cable. You should be able to receive it without using the 10 MHz reference > clock because, as you say, the clock is recovered from the data. > >> - My only clocking options on the GTP's are 150 or 75MHz. I'm not sure >> if I should clock the USRP2's FPGA or the reference differently to >> match this. > > > The important thing is that you get the GTPs set up for the correct data > rate. On the USRP2, the main clock to the SERDES chip is 100 MHz. 2 Bytes > are sent on each clock, so the effective data rate is 1.6 Gbps. However, > since 8b-10b coding is used, the on the wire bit rate is 2.0 Gbps > (20*100MHz). So whatever reference clock you use, you need the GTP to be > working at 2 Gbps. I am by no means an expert on the GTPs, but I think the > easiest way to do this is to have a reference clock of 100 MHz. > > You could probably use the PLLs in the V5 to create a 100 MHz reference > clock from one of your other clock rates. > > Matt > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using the MIMO port for serial comm. to a Virtex5 board
Hello, I'm most likely having a clock issue because I cannot get any data transfers going between the USRP2 and GTPs on the V5. A few questions: - I'm not quite sure I understand the 10MHz reference clock idea, or its usage; I looked through the HDL and everything on the FPGA is running at 100MHz. - I assume I will not need to provide this reference clock if the USRP2 is the driver given that sd_gentest appears to do so in the main functions clocks_mimo_config. Either way I'm using the SAS to quad SATA cable so the clock isn't even transferred to the GTPs (literally, it's supposed to derive it from the data). - My only clocking options on the GTP's are 150 or 75MHz. I'm not sure if I should clock the USRP2's FPGA or the reference differently to match this. Any help with the clocking scheme would be much appreciated. Thank you. Charles On Fri, Nov 27, 2009 at 4:20 PM, Charles Irick wrote: > On Thu, Nov 26, 2009 at 4:47 PM, Matt Ettus wrote: >> Yes, you'll need to do firmware. If you just modify the main() function to >> set the loopback, it doesn't matter which firmware you start with. > > The closest thing I can find is the following: > output_regs->serdes_ctrl = (SERDES_ENABLE | SERDES_RXEN | > SERDES_LOOPEN); > I tried pasting that line into main() of sd_bounce assuming that > SERDES_LOOPEN was the loopback parameter. > I'm not getting anything back on the V5 side so if that function is > correct then it is probably some type of clocking issue. > >> BTW, I don't know how you intended to physically connect the boards. The >> best long term solution is to have your own custom board which implements >> the connections we use (SAS). In the short term, you can buy a SAS to quad >> SATA breakout cable. This would connect right to the SATA headers on many >> FPGA eval boards. >> >> Matt > > Right now this is what I'm doing. SAS to quad SATA breakout. I'm using > Lane 1 to connect to the V5 board. Are there any particular > disadvantages to this solution that made you suggest a custom board? > > Charles > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using the MIMO port for serial comm. to a Virtex5 board
Hello again, I decided to try and run the mimo_tx.bin (built from SVN rev 11663) as the s/w firmware and use the Virtex5 board as the "slave USRP2" since this would require almost no changes to the gnuradio side. I'm using u2_rev3_ise10.1sp3_r11370.bin as the FPGA bitstream. When I run the host app ./test_mimo_tx I get the following error and everything freezes up (cannot ctrl-c, have to reboot the usrp2): "usrp2::ctor reset_db failed" Most people seem to be able to fix this with a firmware update because of some new process in libusrp2 with initialization. If this is the case then it must be something in mimo_tx.c that needs to be updated. Either that or the host app. Any ideas? Might be important: I'm not sure what type of modifications to mb-gcc are imperative for building firmware for the aeMB, but I'm using the standard version that comes with ISE for the vanilla microblaze as I didn't want to mess up the toolchain for standard development. Charles On Tue, Nov 24, 2009 at 6:10 PM, Charles Irick wrote: > Hello, > I'm looking to use the MIMO port to send serial data to a Virtex5 > board and am trying to get an idea of how to set up the USRP2 to > achieve this. > > - I was wondering how a simple loopback test might be achieved. > Something simple like taking what the TI chip gives the FPGA and > sending it back out. Not sure if I should be concerning myself with > the HDL code running on the Spartan 3. (usrp2/fpga/serdes) > - It looks like I will probably have to flash the firmware and I'm not > sure what the best s/w configuration would be. (mimo_tx.bin, > serdes_txrx.bin, my own, ...) > > My guess: I will need to create my own app.c in usrp2/firmware/apps > which receives a serial packet and sends it back out, compile this, > then flash it to the SD card to be run on the aeMB. > > I think I'm just trying to get an idea of what code I should be > using/modifying to perform the tasks I want using the MIMO port. > > Charles > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Using the MIMO port for serial comm. to a Virtex5 board
Hello, I'm looking to use the MIMO port to send serial data to a Virtex5 board and am trying to get an idea of how to set up the USRP2 to achieve this. - I was wondering how a simple loopback test might be achieved. Something simple like taking what the TI chip gives the FPGA and sending it back out. Not sure if I should be concerning myself with the HDL code running on the Spartan 3. (usrp2/fpga/serdes) - It looks like I will probably have to flash the firmware and I'm not sure what the best s/w configuration would be. (mimo_tx.bin, serdes_txrx.bin, my own, ...) My guess: I will need to create my own app.c in usrp2/firmware/apps which receives a serial packet and sends it back out, compile this, then flash it to the SD card to be run on the aeMB. I think I'm just trying to get an idea of what code I should be using/modifying to perform the tasks I want using the MIMO port. Charles ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] wxgui errors
I'm trying to run the usrp_wfm_rcv.py example and I get the errors below. The gui interface comes up but appears to lock up immediately. I have tried to look in the file gr-wxgui/src/python/forms/forms.py under the radio_buttons class but I see no index parameter. This is probably a simple error but I'm new to python and having trouble understanding what is going on. I am using the code from subversion (maybe not a great idea for starting out). I have python2.5-dev. Running on Ubuntu 8.10. Thank you in advance. Using RX d'board A: Basic Rx >>> gr_fir_ccf: using SSE >>> gr_fir_fff: using SSE Form: -> y_per_div Error translating value: "10" 'tuple' object has no attribute 'index' Enter a possible value in choices: "(1, 2, 5, 10, 20)" Form: -> y_per_div Error translating value: "10" 'tuple' object has no attribute 'index' Enter a possible value in choices: "(1, 2, 5, 10, 20)" FYI: No Powermate or Contour Knob found Traceback (most recent call last): File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/forms/forms.py", line 100, in widget.Bind(EVT_DATA, lambda x: self._update(x.data)) File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/forms/forms.py", line 473, in _update def _update(self, i): self._radio_buttons.SetSelection(i) File "/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_controls.py", line 2425, in SetSelection return _controls_.RadioBox_SetSelection(*args, **kwargs) TypeError: in method 'RadioBox_SetSelection', expected argument 2 of type 'int' aUTraceback (most recent call last): File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/forms/forms.py", line 100, in widget.Bind(EVT_DATA, lambda x: self._update(x.data)) File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/forms/forms.py", line 473, in _update def _update(self, i): self._radio_buttons.SetSelection(i) File "/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_controls.py", line 2425, in SetSelection return _controls_.RadioBox_SetSelection(*args, **kwargs) TypeError: in method 'RadioBox_SetSelection', expected argument 2 of type 'int' ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Just starting, Error running make
Just getting started with GNU radio and I'm trying to compile the source code with the instructions on the wiki for Ubuntu (8.10 Intrepid). I got the code from the SVN and bootstrap runs fine, configure will not build the following (which I assume is ok ) gcell, gr-gcell, gr-audio-jack, gr-audio-osx, gr-audio-portaudio, gr-audio-windows, gr-comedi. When I go to make I seem to be missing a library file: make[5]: Entering directory `/home/chuck527/gnuradio/gnuradio-core/src/lib' /bin/sh ../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o libgnuradio-core.la -rpath /usr/local/lib -version-info 0:0:0 bug_work_around_6.lo filter/libfilter.lag72x/ libccitt.la viterbi/libviterbi.la general/libgeneral.la gengen/libgengen.laio/ libio.la missing/libmissing.la reed-solomon/librs.la runtime/libruntime.lahier/ libhier.la /home/chuck527/gnuradio/omnithread/libgromnithread.la/home/chuck527/gnuradio/gruel/src/lib/ libgruel.la -lfftw3f -lm -lgsl -lgslcblas -lm -lgslcblas libtool: link: g++ -shared -nostdlib /usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/crti.o /usr/lib/gcc/i486-linux-gnu/4.3.2/crtbeginS.o .libs/bug_work_around_6.o -Wl,--whole-archive filter/.libs/libfilter.a g72x/.libs/libccitt.a viterbi/.libs/libviterbi.a general/.libs/libgeneral.a gengen/.libs/libgengen.a io/.libs/libio.a missing/.libs/libmissing.a reed-solomon/.libs/librs.a runtime/.libs/libruntime.a hier/.libs/libhier.a -Wl,--no-whole-archive -Wl,-rpath -Wl,/home/chuck527/gnuradio/omnithread/.libs -Wl,-rpath -Wl,/home/chuck527/gnuradio/gruel/src/lib/.libs /home/chuck527/gnuradio/omnithread/.libs/libgromnithread.so /home/chuck527/gnuradio/gruel/src/lib/.libs/libgruel.so -L/usr/lib -lboost_thread-gcc43-mt-1_35 -lrt /usr/lib/libfftw3f.so -lgsl -lgslcblas -L/usr/lib/gcc/i486-linux-gnu/4.3.2 -L/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.3.2/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/i486-linux-gnu/4.3.2/crtendS.o /usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/crtn.o -pthread -pthread -Wl,-soname -Wl,libgnuradio-core.so.0 -o .libs/libgnuradio-core.so.0.0.0 g++: /usr/lib/libfftw3f.so: No such file or directory make[5]: *** [libgnuradio-core.la] Error 1 I installed all dependencies including the optional ones with the exception of g77 which give me errors from apt. I made sure to get python-wxgtk-2.8. Hopefully this is sufficient info. Any help would be appreciated. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
