[Discuss-gnuradio] OFDM packets
Hi, I have a problem with OFDM system. I transmit OFDM signal at 2.4 GHz, but I receive half of the total packets. Moreover, only half of the packets received are correct. CRC controller is perfect but i want a ber estimate, so I change the payload (binary file) and I receive check bit by bit. The result of my alteration test is similar than CRC test. I have a lot of frequency offset, therefore I change manually the frequency receiver. I use revision 6845 and RFX 2400. Example with crc: The final packet I receive: ok: False pktno 4602 n_rcvd 1300 n_right 83 Why can't i get all the packets? Could you help me?? I'm testing OFDM system without USRP and none of the packets are lost. Thanks a lot. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] TVRX sensitivity
Dear all, What is the TVRX front end sensitivity? Thanks and best regards, Pierre JALLON (PhD) CEA LETI - MINATEC Laboratoire Communications Numériques et Algorithmes LETI/DCIS/SASTI/LCNA 17 rue des Martyrs 38054 Grenoble cedex 09 Tél : + 33 4 38 78 27 59 Fax : +33 4 38 78 65 86 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] LFRX-LF Rev 2.2 troubles
I am attempting to use this receiver to analyze signals in the AM/FM bands. However, I have had no such luck. Since the sound card is not working on my machine I cannot attempt to output to the sound card. Here are some of commands I have tried: # FFT centered near a known FM station at 89.7MHz ./usrp_fft.py -R B -f 89M # results: mostly -30dB noise in the window of +/-2.0MHz with a peak of -5dB at the center frequency. usrp_wfm_rcv.py -R B -f 89M #similar results Has anyone else experienced this? Thanks in advance! Rana -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] QA for WAV issue
If building in a separate directory from the source (e.g. "mkdir build; cd build; ../configure; make; make check"), then the QA for WAV doesn't work because the input file found on line 37 is hard-wired to "./" ... which of course won't be the correct directory since the build is done elsewhere. I don't think ABS_TOP_SRCDIR is available in python, and setting the PYTHONPATH won't help because the wavfile_source file stuff is in compiled C++. This could easily be done by creating "qa_wavefile.py.in" with @ABS_TOP_SRCDIR@ and adding this new file to the list dealt with in config/ grc_gnuradio_core.m4 ... but maybe someone else knows of a better way? - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QA for WAV issue
On 2/28/08, Michael Dickens <[EMAIL PROTECTED]> wrote: > If building in a separate directory from the source (e.g. "mkdir > build; cd build; ../configure; make; make check"), then the QA for WAV > doesn't work because the input file found on line 37 is hard-wired to > "./" ... which of course won't be the correct directory since the > build is done elsewhere. I don't think ABS_TOP_SRCDIR is available in > python, and setting the PYTHONPATH won't help because the > wavfile_source file stuff is in compiled C++. This could easily be > done by creating "qa_wavefile.py.in" with @ABS_TOP_SRCDIR@ and adding > this new file to the list dealt with in config/ > grc_gnuradio_core.m4 ... but maybe someone else knows of a better way? Good catch. I recently merged this to the trunk and was afraid that something like the above might happen. I can't think of a better way to fix this than what you've described. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM packets
On Thu, Feb 28, 2008 at 12:51:18PM +0100, Crespi Floriana wrote: > Hi, > I have a problem with OFDM system. > I transmit OFDM signal at 2.4 GHz, but I receive half of the total packets. > Moreover, only half of the packets received are correct. > CRC controller is perfect but i want a ber estimate, so I change the > payload (binary file) and I receive check bit by bit. > The result of my alteration test is similar than CRC test. > I have a lot of frequency offset, therefore I change manually the frequency > receiver. > I use revision 6845 and RFX 2400. > Example with crc: > The final packet I receive: > ok: False pktno 4602 n_rcvd 1300 n_right 83 > > Why can't i get all the packets? > Could you help me?? > > I'm testing OFDM system without USRP and none of the packets are lost. > > Thanks a lot. > Hi Crespi, You have neglected to tell us virtually anything about your problem. Could you please tell us: which version of GNU Radio? trunk, tarball (which one), etc? what operating system, distribution and architecture? the command line you issued any modifications you may have made to distributed code? anything else that might be relevant Thanks, Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] LFRX-LF Rev 2.2 troubles
On Thu, Feb 28, 2008 at 04:54:59PM +0100, Rana Basheer wrote: > I am attempting to use this receiver to analyze signals in the AM/FM > bands. However, I have had no such luck. > Since the sound card is not working on my machine I cannot attempt to > output to the sound card. > > Here are some of commands I have tried: > > # FFT centered near a known FM station at 89.7MHz > ./usrp_fft.py -R B -f 89M > # results: mostly -30dB noise in the window of +/-2.0MHz with a peak of > -5dB at the center frequency. > > usrp_wfm_rcv.py -R B -f 89M > #similar results > > Has anyone else experienced this? > Thanks in advance! > Rana The LFRX only covers 0 to 30 MHz. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: LFRX-LF Rev 2.2 troubles
Good point. However, we have the same issue in the AM band on the LFRX and in the 2.4G range with the RFX2400. i.e.: python ./gr-utils/src/python/usrp_fft.py -R B -f 1.44M -d 128 #produces the same results in AM Moreover, we are not able to detect any transmitting devices with the USRP. Eric Blossom wrote: > The LFRX only covers 0 to 30 MHz. > > Eric -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: LFRX-LF Rev 2.2 troubles
Have you tried using coax to isolate the problem? - George Rana Basheer wrote: Good point. However, we have the same issue in the AM band on the LFRX and in the 2.4G range with the RFX2400. i.e.: python ./gr-utils/src/python/usrp_fft.py -R B -f 1.44M -d 128 #produces the same results in AM Moreover, we are not able to detect any transmitting devices with the USRP. Eric Blossom wrote: The LFRX only covers 0 to 30 MHz. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: LFRX-LF Rev 2.2 troubles
ahhh sorry, wrong thread. George Nychis wrote: Have you tried using coax to isolate the problem? - George Rana Basheer wrote: Good point. However, we have the same issue in the AM band on the LFRX and in the 2.4G range with the RFX2400. i.e.: python ./gr-utils/src/python/usrp_fft.py -R B -f 1.44M -d 128 #produces the same results in AM Moreover, we are not able to detect any transmitting devices with the USRP. Eric Blossom wrote: The LFRX only covers 0 to 30 MHz. Eric ___ 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] OFDM packets
Eric Blossom wrote: On Thu, Feb 28, 2008 at 12:51:18PM +0100, Crespi Floriana wrote: Hi, I have a problem with OFDM system. I transmit OFDM signal at 2.4 GHz, but I receive half of the total packets. Moreover, only half of the packets received are correct. CRC controller is perfect but i want a ber estimate, so I change the payload (binary file) and I receive check bit by bit. The result of my alteration test is similar than CRC test. I have a lot of frequency offset, therefore I change manually the frequency receiver. I use revision 6845 and RFX 2400. Example with crc: The final packet I receive: ok: False pktno 4602 n_rcvd 1300 n_right 83 Why can't i get all the packets? Could you help me?? I'm testing OFDM system without USRP and none of the packets are lost. Thanks a lot. Hi Crespi, You have neglected to tell us virtually anything about your problem. Could you please tell us: which version of GNU Radio? trunk, tarball (which one), etc? what operating system, distribution and architecture? the command line you issued any modifications you may have made to distributed code? anything else that might be relevant it seems to me like you're using antennas, you can try coax to isolate the problem maybe you're getting interference at 2.4GHz. But answer Eric's questions too. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: LFRX-LF Rev 2.2 troubles
On Thu, Feb 28, 2008 at 06:51:45PM +0100, Rana Basheer wrote: > Good point. However, we have the same issue in the AM band on the LFRX > and in the 2.4G range with the RFX2400. > i.e.: > python ./gr-utils/src/python/usrp_fft.py -R B -f 1.44M -d 128 > #produces the same results in AM > > Moreover, we are not able to detect any transmitting devices with the > USRP. > > Eric Blossom wrote: > > The LFRX only covers 0 to 30 MHz. > > > > Eric > What are you using for an antenna? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] problem with linking libraries
Hello everyone, I'm getting this error while importing gnuradio packages. >>> from gnuradio import gr Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.4/site-packages/gnuradio/gr/__init__.py", line 27, in ? from gnuradio_swig_python import * File "/usr/local/lib/python2.4/site-packages/gnuradio/gr/gnuradio_swig_python.py", line 23, in ? from gnuradio_swig_py_runtime import * File "/usr/local/lib/python2.4/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", line 6, in ? import _gnuradio_swig_py_runtime ImportError: libgnuradio-core.so.0: cannot open shared object file: No such file or directory >>> The file libgnuradio-core.so.0 is present in /usr/local/lib. This is the second time i'm installing gnuradio. During the first installation, i had not installed wxPython and all the examples not involving wx worked just fine. However after the installation of wxPython during the second installation, python could'nt find libpango. So i added -lpangox-1.0 to EXTRALIBS_GUI in the makefile and reinstalled wxPy after i came across a similar problem someone else had while digging through the gnuradio archives. wxPy works now. Do you think this has anything to do with the problem i have now? I'm a beginner and don't know linux that well. Any help will be greatly appreciated. Thankyou in advance Sriram - Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem with linking libraries
On 2/28/08, sriram s <[EMAIL PROTECTED]> wrote: > ImportError: libgnuradio-core.so.0: cannot open shared object file: No such > file or directory You likely need to run: $ sudo ldconfig ...in order for the system to "learn" the new libraries that have been installed. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Re: LFRX-LF Rev 2.2 troubles
For the AM band I am not using an antenna. For the 2.4GHz band I am using a 1/4 wave whip antenna. Is there a better way to prove that the radio is detecting a signal? Eric Blossom wrote: > On Thu, Feb 28, 2008 at 06:51:45PM +0100, Rana Basheer wrote: >> > The LFRX only covers 0 to 30 MHz. >> > >> > Eric >> > > What are you using for an antenna? -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RFX transceiver board receive VCO offset automated calibration
On 2/27/08, Richard Clarke <[EMAIL PROTECTED]> wrote: > Before I go ahead and try to implement an auto calibration routine for > the Rx frequency offset of the receive subsystem on the RFX400/USRP, I > was wondering if anyone else had already implemented something similar, > or had any pointers for me. While what you describe is well-intentioned, it doesn't solve the real issue. > Basically what I want to do is create a > calibration routine that will determine the frequency offset between the > RFX400/USRP receive subsystem (nominally already set to equal the > frequency from a transmit source (e.g sig gen) and the transmit source, > and then nudge the tune frequency to null that offset. I find that my > RFX400 receiver after time to stabilise is around 3.2KHz in error, which > is well within it's spec I know, however I want to automatically > determine this offset and null it out. Do you want to null it out once, based on a your signal generator input, and store that value somewhere? How would you use this value in the future? > I guess the actual fine frequency > adjustment will actually be occurring in the DDC, would that be correct? If that is how you were to implement it. If all you are doing is applying a fixed correction based on this calibration technique you've described, then it's easier to just tune the daughterboard to the corrected frequency. You're correct that you will see the "beat frequency" in the I or Q channel equal to the frequency offset between the transmitter and receiver. However, I don't think this addresses the bigger issue, which is that receiver frequency and time base offset will always exist, and must be corrected in real-time if you are using a modulation technique that is sensitive to these offsets. Even temperature differences in the frequency reference in the USRP can cause many kilohertz drift, especially if you are operating at high carrier frequencies, like 2-3GHz. There are many techniques for receiver frequency and phase synchronization. They generally involve a block to measure the frequency/phase error, a loop filter to turn this error into an appropriate control value, and an NCO to apply the actual fine frequency/phase correction to the incoming signal. These would be designed to work with the properties of the actual modulation you'd be receiving. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM packets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 George Nychis wrote: > it seems to me like you're using antennas, you can try coax to isolate > the problem maybe you're getting interference at 2.4GHz. But answer > Eric's questions too. With suitable attenuation of course -- I think Matt says at least 30 dB. - -Dan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHxzTQy9GYuuMoUJ4RAki7AJ98iYlWjoRTvjA21nMsOZQKKFnewACgq6nX BFb3UQtYJRc36QesNydjKbI= =km2M -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Edirol UA-25 24-bit recording
On 2008-02-25 14:10, Eric Blossom wrote:
> The code doesn't support S24_3LE because when we wrote it, we didn't
> have any cards that used that format, and it wasn't obvious (to me)
> exactly how the format was represented. It would be great if you
> could sort this out and submit a patch with the fix.
Alright, I sort of got it to work, I'm at least pretty sure about the
format of S24_3LE. I attached the code (just the work_s24_2x1 function
with lots of comments) to this email, if you want to take a look. There
might be a better way to do this, but so far I couldn't think of
anything.
I'm still having a problem with it though and I need help to sort it
out. Most of the time I get buffer overruns from
audio_alsa_source::read_buffer(). The function I wrote seems to work,
this morning I got a clean signal from my sound card (24-bit, 96kHz),
but when I ran the same code later (after some experiments) it produced
buffer overruns again.
Alsa reference [1] says:
> The overrun can happen when an application does not take new captured
> samples in time from alsa-lib.
Is it a speed-issue, is some buffer too small?
What am I doing wrong?
Thank you!
Matt
[1]
http://howto.gp.mines.edu/local-apps/alsa-lib-devel-1.0.14/doxygen/html/pcm.html#pcm_errors
--
Mathis Richter <[EMAIL PROTECTED]>
GnuPG Fingerprint: 5069 3C27 0178 D542 DFB4 04F6 29BD 9EF2 1BE0 DDF6
/*
* Work function that deals with float to S24 conversion
*/
int
audio_alsa_source::work_s24_2x1 (int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
typedef gr_int32 sample_t; // the type of samples we're creating
static const int NBITS = 24; // # of bits in a sample
unsigned int nchan = output_items.size ();
float **out = (float **) &output_items[0];
unsigned char *buf = (unsigned char *) d_buffer;
assert(nchan == 1);
int bi;
// actually using 24 bits instead of 32
unsigned int sizeof_frame = d_hw_nchan * (sizeof (sample_t) - 1);
assert (d_buffer_size_bytes == d_period_size * sizeof_frame);
// To minimize latency, return at most a single period's worth of samples.
// [We could also read the first one in a blocking mode and subsequent
// ones in non-blocking mode, but we'll leave that for later (or never).]
if (!read_buffer (buf, d_period_size, sizeof_frame))
return -1; // No fixing this problem. Say we're done.
// process one period of data
//
//
// Every frame will have the following byte format:
//
// [ byte1_L | byte2_L | byte3_L | byte1_R | byte2_R | byte3_R ]
//
// while byte1 will contain the least significant bits of the 24-bit
// integer, so the bytes will have to be reassembled in reverse order.
// Three subsequent bytes represent the 24-bit integer for a channel, the
// following three bytes will contain the sample of the next channel.
//
// The bit that determins the sign of the integer will be the 8th bit from
// the right in byte3. It will later have to be moved to the 32nd bit
// in the final integer.
//
bi = 0;
for (unsigned int i = 0; i < d_period_size; i++)
{
int t[nchan];
for (unsigned int chan = 0; chan < 2; chan++)
{
// get first byte from buffer and put it into a 32-bit integer
// t's bytes will look like this:
// t = [ empty | empty | empty | byte1 ]
t[chan] = (buf[bi++]);
// shift the next byte 1 byte to the left so that t's bytes look like this:
// t = [ empty | empty | byte2 | byte1 ]
t[chan] = t[chan] | (buf[bi++] << 8);
// shift the next byte 2 bytes to the left
// t = [empty | byte3 | byte2 | byte1 ]
t[chan] = t[chan] | (buf[bi++] << 16);
// sign of the integer is at the 24th bit (from the right)
// shift it to the 32nd bit (from the right)
int sign = (t[chan] & (1 << 23)) << 8;
int value;
// if the integer we received is negativ
// t OR (0111 1000 )
// so that all bits that were still 0 are switched to 1
if (sign != 0)
value = (t[chan] | 0x7f80);
// if the integer is positive, retain all bit values, but make sure
// that the one where the 'sign' bit used to be is 0
// t AND ( 0111 )
else
value = (t[chan] & 0xff7f);
// combine the value of the integer with its sign
t[chan] = sign | value;
}
int a = (t[0] + t[1]) / 2;
out[0][i] = (float) a * (1.0 / (float) ((1L << (NBITS-1)) - 1));
}
return d_period_size;
}
signature.asc
Description: Digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Multiple top-level blocks
Hello, Is there any documentation of the new C++ only gnuradio framework? I'd like some insight into the philosophy behind it. E.g. why can there only be one top level block? Consider an example: I have a transmitter and a receiver. The two are completely independent. Why can't each one be a gr_top_block? I may want to stop one but not the other. The tx and rx may have been designed by different people. Why do I need another top level to combine the two? The gr_top_block appears to separate the flow graph into independent subgraphs and runs each one in its own thread. I wonder if this is always the desired behavior. Consider two threads with different computational requirements. One needs 90% the other 10% of the CPU. The low rate thread should relinquish control if it has nothing to do. However, that will not happen. Instead, the scheduler will sit there and use up the entire time to check if the graph has unblocked. Any ideas? Thanks. Eugene Grayver, Ph.D. Aerospace Corp., Sr. Eng. Spec. Tel: 310.336.1274 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multiple top-level blocks
On Thu, Feb 28, 2008 at 06:12:33PM -0800, Eugene Grayver wrote: > Hello, > > Is there any documentation of the new C++ only gnuradio framework? I'd > like some insight into the philosophy behind it. E.g. why can there only > be one top level block? Consider an example: The one top block constraint is an implementation detail (restriction) that will be removed as part of the thread-per-block work. If you've every tried to robustly mix threads, signals, blocking system calls and reliable shutdown, you may have some appreciation of the level of effort required to make this work correctly. > The gr_top_block appears to separate the flow graph into independent > subgraphs and runs each one in its own thread. I wonder if this is always > the desired behavior. Consider two threads with different computational > requirements. One needs 90% the other 10% of the CPU. The low rate > thread should relinquish control if it has nothing to do. However, that > will not happen. Instead, the scheduler will sit there and use up the > entire time to check if the graph has unblocked. Any ideas? > > Thanks. I think you misunderstand the details of what's going on. The low-rate thread will relinquish control. No thread is spinning waiting for another. It'll be blocked waiting on something. You are correct in your assessment that we're not currently making good use of multicore resources. That will be fixed in as part of the thread-per-block work. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question about uO and FPGA
Hi, I am currently using USRP to do two-way relaying between d'b A and d'b B (FLEX2400). The graph looks like rx_a -> tx_b rx_b -> tx_a Since there are one rx and one tx paths sharing the TX/RX port. The port is used in time-multiplexing way. When I get something on rx_b, I set_enable(True) on tx_a and set_enable(False) on tx_b. Then use rx_b->tx_a to relay the data from b to a. I use set_mux(gru.hexint(32103210)) for rx and set_mux(0xba98) for tx. The problem is I have to use relatively high bit rate on these tx and rx paths. The demic rate should be <=16, and interp rate <=32. When I run the code with decim rate = 16 interp rate = 32, I keep receiving uO. My questions are : what's the max rate the USRP can support in this case? and is there any fatal fault in my graph design? Any help will be appreciated! -Di P.S. Attached is the simplified connection between rx and tx self.connect(self.rx_path.u, di) self.connect((di,0),(intl,1)) self.connect((di,1),(intl,0)) self.connect(intl, self.tx_path.u) -- View this message in context: http://www.nabble.com/Question-about-uO-and-FPGA-tp15751673p15751673.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GPS on USRP
Hi, I am a newbie to USRP, and still struggling to get it working on my windows machine. I am trying to use cygwin. I reckon that many ppl have already acquired and tracked GPS on USRP. Waht I want to do is to capture GPS IF samples (e.g. at IF=5 MHz) and use a software receiver to process those IF samples on PC. Any suggestions to start?!... Faisal A. KhanDoctral CandidateUniversity of New South WalesNSW 2052, Sydney, AustraliaP) +61-2-93854208M)+61-401-260728 _ What are you waiting for? Join Lavalife FREE http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Flavalife9%2Eninemsn%2Ecom%2Eau%2Fclickthru%2Fclickthru%2Eact%3Fid%3Dninemsn%26context%3Dan99%26locale%3Den%5FAU%26a%3D30288&_t=764581033&_r=email_taglines_Join_free_OCT07&_m=EXT___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about uO and FPGA
DiX wrote: The problem is I have to use relatively high bit rate on these tx and rx paths. The demic rate should be <=16, and interp rate <=32. When I run the code with decim rate = 16 interp rate = 32, I keep receiving uO. My questions are : what's the max rate the USRP can support in this case? and is there any fatal fault in my graph design? Hi Di, uO means that the USRP is overrunning, in other words your host machine cannot keep up with the incoming data rate. The USRP cannot keep up with more than 8Msps due to the USB bus limitation with 32-bit complex. You will get overruns if you try anything more than this. Let's take the case of a single daughterboard... you will not be able to use a decimation rate lower than 8 (64Msps/8 = 8Msps). The first thing to do, is to check to see if your machine can keep up with 8Msps. Run "./usrp/host/apps/test_usrp_standard_rx -D 8" and see if you get any uO. If not, keep increasing the decimation until you get no uO. Since you're using two RX chains, with a decimation rate of 8, you'd be generating 16Msps since each chain generates 8Msps. Therefore, when you say "decim rate should be <=16" ... <=16 is not possible, only =16. With decim=16 you're generating 4Msps per chain, for a total of 8Msps. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
