RE: [Discuss-gnuradio] Unexplained out-of-sequence packets...
Hi Eric It seems this has not fixed the problem. Does anyone have any other suggestions as to the possible cause? Note, I also found power cycling the USRP2 can sometimes avoid the same problem. Ian. -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Ian Holland Sent: Tuesday, 11 May 2010 11:14 AM To: Eric Blossom Cc: discuss-gnuradio@gnu.org Subject: RE: [Discuss-gnuradio] Unexplained out-of-sequence packets... Thanks Eric I checked the power management preferences and couldn't see anything about CPU throttling, though I did verify it would never go to sleep after inactivity. Then, I found some info on http://blog.mpathirage.com/2009/10/04/how-to-disable-dynamic-frequency-s calingcpu-throttling-in-ubuntu-jaunty9-04/ to disable the CPU throttling (I know I am using 9.10, not 9.04, but I imagine it should be the same). After rebooting (only once), I haven't yet seen the problem again. Unfortunately, given the seemingly random nature of the problem, I guess it is a wait-and-see matter as to whether it ever does resurface. Cheers Ian. -Original Message- From: Eric Blossom [mailto:e...@comsec.com] Sent: Tuesday, 11 May 2010 10:55 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Unexplained out-of-sequence packets... On Tue, May 11, 2010 at 10:45:05AM +0930, Ian Holland wrote: Not sure if this sheds any more light on the issue, but I have found that if I shut down the PC and turn it on again, before retrying the same tests, the problem disappears. However, as I have encountered it before as well I am still puzzled as to why this should ever occur. Ian. CPU throttling. Check power management configuration. 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
[Discuss-gnuradio] USRP vs USRP2
Hello all, I want to start expereiment with software defined radio but can't make up my mind which one of the usrp and usrp2 is the most suitable. I am new to FPGAs but want to start playing with these as well. I use GNU/Linux and GCC as much as I can. Some questions: The usrp and usrp2 uses FPGAs from different manufacturers so I assume the development environment will differ as well. Is anyone of the two more suited for a linux system than the other? I don't want to pay any license costs (and I'm glad if I can use the dev environment longer time than a trial period... btw, I am a student). To play around with a FPGA on a system like this, will I need the extra size and speed xilinx spartan 3 gives me? (Maybe I want to bruteforce some cryptos, doing some FIR filters or event wavelet transformations) Since the usrp2 only have one tx/rx channel I would need two usrp2's to get the same number of tx/rx channels as the usrp and this is not currently an affordable option. In which cases will I need two tx/rx channels? Examples? The usrp2 is faster in many ways. In what applications will I need the extra speed and extra bandwidth? Examples? Any other cool stuff I can do with one of the boards but not the other? Are gnuradio programs written for usrp compatible with usrp2? Thanks! Best regards, Manne ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP-Overrun Problem
Eder Matthias wrote: Well, as I unterstand, the main problem is, that the audio sink has got another clock than USRP has. That means that packets are lost, whan the audio sink buffer is full. Ok so far, i can follow you. But what can i do to solve this problem. The best way would be to synchronise the two clocks. But how can this be done? This is a well known problem in the HAM radio world as well. In some hardware (QS1R, HPSDR) the problem was solved adding a D/A converter clocked by a clock taken from the A/D, therefore removing the needs of a PC audio card. In a more general way, because, usually, the clock synchronization in hardware is not easily feasible, you need to use a software resampler. However, due to the drift between the two clocks, in order to avoid slips, the scaling factor has to be dynamically changed. The only software (with source available), at least the only I am aware of, to implement this adaptive resampler is WinRad (http://www.sdrham.com/winrad/download_source.html) written by Alberto I2PHD. *am* - Andrea Montefusco iw0hdvhttp://www.montefusco.com tel: +393356992791 fax: +390623318709 - ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-howto-write-a-block configure error in cygwin
I am playing howto-write-a-block in cygwin. Git trunk. ./bootstrap no problem ./configure brings the following error: checking for GNURADIO_CORE... configure: error: Package requirements (gnuradio-core = 3) were not met: No package 'gnuradio-core' found This does not happen in Ubuntu. Anyone has any idea on this? Thanks Kyle ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-howto-write-a-block configure error in cygwin
fOn Thu, May 13, 2010 at 12:13:00AM +1000, Kyle Zhou wrote: I am playing howto-write-a-block in cygwin. Git trunk. ./bootstrap no problem ./configure brings the following error: checking for GNURADIO_CORE... configure: error: Package requirements (gnuradio-core = 3) were not met: No package 'gnuradio-core' found This does not happen in Ubuntu. Anyone has any idea on this? Thanks Kyle Assuming that you really do have GNU Radio installed, I would suspect that you don't have PKG_CONFIG_PATH set, or that it's pointing to the wrong place. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Loops in the flow graph
Hello I've seen on the archives, and experienced myself, that GR does not support having loops in the flow graph. I would like to get some more insight on this limitation to understand 1.the reasons for it and 2. how to workaround it in those cases where a feedback loop is a key solution. Naively, I try asking if it would be acceptable to detect the presence of at least 1 sample delay in the loop and apply a kind of initial condition (or simply a 0 initial value) to boot the computations. Where in the code the loop detection is implemented? Thanks in advance alberto Risparmia con Tutto Incluso Light: telefono + adsl 8 mega a soli 14,95 € al mese.Gratis la Sim Tiscali Mobile con 25 euro di traffico! L'offerta è valida solo se attivi entro il 13/05/10http://abbonati.tiscali.it/telefono-adsl/prodotti/tc/tuttoincluso_light/?WT.mc_id=01fw ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Simple digital data transmitter
Hi, I have set up the following simple digital data transmitter: File source -à throttle -à packet encoder --- DBPSK modulator -à USRP2 File size sample rate samples/sym - 2 samples/sym – 2 Inter rate 32 -variable 3.125M bits/sym - 1 excess BW – 0.35 Freq 400M access code – n/a grey code - yes Gain 0 pad for USRP – yes payload len – 0 What is the transmit (over the air) data rate of this line up ? Please explain how the rate is derived. Thanks, Dave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simple digital data transmitter
On Wed, May 12, 2010 at 09:06:13AM -0700, David Barton wrote: Hi, I have set up the following simple digital data transmitter: File source -à throttle -à packet encoder --- DBPSK modulator -à USRP2 File size sample rate samples/sym - 2 samples/sym – 2 Inter rate 32 -variable 3.125M bits/sym - 1 excess BW – 0.35 Freq 400M access code – n/a grey code - yes Gain 0 pad for USRP – yes payload len – 0 What is the transmit (over the air) data rate of this line up ? Please explain how the rate is derived. Thanks, Dave Remove the throttle, it's not needed. Your baseband sample rate is 100M/32 - 3.125MS/s You're using 2 samples/symbol, thus your symbol rate is 3.125MS/s / 2 - 1.5625Msymbols/s And since you're using DBPSK, you're getting 1 bit/symbol, thus your raw over-the-air bit rate is 1.5625Mbit/s Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Loops in the flow graph
On Wed, May 12, 2010 at 05:00:32PM +0200, Alberto Trentadue wrote: Hello I've seen on the archives, and experienced myself, that GR does not support having loops in the flow graph. Correct. I would like to get some more insight on this limitation to understand 1.the reasons for it and 2. how to workaround it in those cases where a feedback loop is a key solution. The reasons are that we currently dynamically schedule all of the blocks, there is no guarantee that a block will produce the number of samples that we asked it too, and that we like doing things in larger chunks for performance reasons. I believe that the best way to work around this limitation would be to statically schedule portions of the graph. One way to do this is to add delay annotations to the edges (connections) between blocks, and feed that into a modified scheduling algorithm. We'd also need a way for blocks to promise to deliver the number of samples we ask for. Blocks that derive from gr_sync_block, gr_sync_interpolator and gr_sync_decimator have the appropriate behavior. We'd just need a way to communicate that to the scheduling mechanism. Will Plishker, a postdoc at the University of Maryland, was doing some work in this area. I haven't talked to him in a while, so I'm not sure of the status of that work. I've cc'd him on this message. Naively, I try asking if it would be acceptable to detect the presence of at least 1 sample delay in the loop and apply a kind of initial condition (or simply a 0 initial value) to boot the computations. Where in the code the loop detection is implemented? The loop detection is implemented in gr_flowgraph.cc in the topological sort code. The actual check occurs on line 460. Thanks in advance alberto Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Unexplained out-of-sequence packets...
On Wed, May 12, 2010 at 04:34:36PM +0930, Ian Holland wrote: Hi Eric It seems this has not fixed the problem. Does anyone have any other suggestions as to the possible cause? Note, I also found power cycling the USRP2 can sometimes avoid the same problem. Ian. Ian, I still suspect something in your host setup. Is the USRP2 connected directly to the host or does it go through a switch? If there's a switch in the path, please remove it. Note that the cpu throttling / clock scaling hypothesis would explain why it works better under higher load than lower load. Are you sure that your cpu isn't being throttled? When you're seeing the problem, try: $ grep 'cpu MHz' /proc/cpuinfo and see if all cores are running at full speed. E.g., Idling laptop (throttled back from 1.83GHz): [...@cyan ~]$ grep 'cpu MHz' /proc/cpuinfo cpu MHz : 1000.000 cpu MHz : 1000.000 Server with cpu scaling disabled: [...@octo swig]$ grep 'cpu MHz' /proc/cpuinfo cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 Eric -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Ian Holland Sent: Tuesday, 11 May 2010 11:14 AM To: Eric Blossom Cc: discuss-gnuradio@gnu.org Subject: RE: [Discuss-gnuradio] Unexplained out-of-sequence packets... Thanks Eric I checked the power management preferences and couldn't see anything about CPU throttling, though I did verify it would never go to sleep after inactivity. Then, I found some info on http://blog.mpathirage.com/2009/10/04/how-to-disable-dynamic-frequency-s calingcpu-throttling-in-ubuntu-jaunty9-04/ to disable the CPU throttling (I know I am using 9.10, not 9.04, but I imagine it should be the same). After rebooting (only once), I haven't yet seen the problem again. Unfortunately, given the seemingly random nature of the problem, I guess it is a wait-and-see matter as to whether it ever does resurface. Cheers Ian. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simple digital data transmitter
Thanks Eric. So the packet encoder samples /symbol does not affect the bit rate but just needs to match the dpsk samples/ symbol rate? Dave From: Eric Blossom e...@comsec.com To: David Barton david.barto...@yahoo.com Cc: discuss-gnuradio@gnu.org Sent: Wed, May 12, 2010 2:02:42 PM Subject: Re: [Discuss-gnuradio] Simple digital data transmitter On Wed, May 12, 2010 at 09:06:13AM -0700, David Barton wrote: Hi, I have set up the following simple digital data transmitter: File source -à throttle -à packet encoder --- DBPSK modulator -à USRP2 File size sample rate samples/sym - 2 samples/sym – 2 Inter rate 32 -variable 3.125M bits/sym - 1 excess BW – 0.35 Freq 400M access code – n/a grey code - yes Gain 0 pad for USRP – yes payload len – 0 What is the transmit (over the air) data rate of this line up ? Please explain how the rate is derived. Thanks, Dave Remove the throttle, it's not needed. Your baseband sample rate is 100M/32 - 3.125MS/s You're using 2 samples/symbol, thus your symbol rate is 3.125MS/s / 2 - 1.5625Msymbols/s And since you're using DBPSK, you're getting 1 bit/symbol, thus your raw over-the-air bit rate is 1.5625Mbit/s Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simple digital data transmitter
On Wed, May 12, 2010 at 11:42:55AM -0700, David Barton wrote: Thanks Eric. So the packet encoder samples /symbol does not affect the bit rate but just needs to match the dpsk samples/ symbol rate? Dave Right. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GRC problem
hello all: I recently use GRC and USRP to do some experiment. But there is a problem for me. I use signal_source-packet_encoder-Gmsk_mod-usrp_sink in the transmit side.and it the receive side I use usrp_source-Gmsk_demod-packet_decoder-scope_sink.Now I know I can see the modulationed waveform in the scope_sink which is connected to the usrp_source. But I can not see anything in the last scope_sink. The correlative parameters which I set about the usrp_sink and usrp_source are the same as the defulat value in the benchmark_tx.py and benchmark_rx.py.and the other parameter in the other block is the defult value.Can anyone tell me how to figure out this problem? Thank you _ 一张照片的自白――Windows Live照片的可爱视频介绍 http://windowslivesky.spaces.live.com/blog/cns!5892B6048E2498BD!889.entry___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GRC Code for Simple receiver
OOPS. Forgot to add the code. Here it is . Bill Simple_WBX_Tuner.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio release 3.3.0-rc0 available for testing
GNU Radio release 3.3.0-rc0 is available for testing: http://gnuradio.org/releases/gnuradio/gnuradio-3.3.0-rc0.tar.gz http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.3.0-rc0.tar.gz This is the first release candidate for the 3.3 release series. This is a straight tarball release from the current git master, and there is expected to be at least one more release candidate with both merges of new functionality and bug fixes before 3.3.0 makes it out the door. There are not yet binary installation packages for Debian/Ubuntu/Fedora. Johnathan Corgan Corgan Enterprises LLC ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Simple tuner doesn't work :(
OK. SO I gave up on scanning for the present time and tried to implement a simple tuner, using a slider. I'm thinking this is a REALLY basic thing to do with any kind of receiver ... No such luck L The slider still has a mind of its own . While I haven't tried your block suggestion yet Josh, I'm beginning to think there is no way to make the USRP Scan. Even manually. I was going to try and write a block that implements a button which increments or decrements a variable every time it is pressed ... What do you guys think ?? Bill ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-howto-write-a-block configure error in cygwin
Eric Blossom wrote: fOn Thu, May 13, 2010 at 12:13:00AM +1000, Kyle Zhou wrote: I am playing howto-write-a-block in cygwin. Git trunk. ./bootstrap no problem ./configure brings the following error: checking for GNURADIO_CORE... configure: error: Package requirements (gnuradio-core = 3) were not met: No package 'gnuradio-core' found This does not happen in Ubuntu. Anyone has any idea on this? Thanks Kyle Assuming that you really do have GNU Radio installed, I would suspect that you don't have PKG_CONFIG_PATH set, or that it's pointing to the wrong place. Eric Thanks Eric. That is right on the point. Configure problem solved after setting PKG_CONFIG_PATH properly. After that, 'make' succeeded. But when I do 'make check', making check in lib succeeded, but when checking in python, it produced an error as follows. Making check in python make[1]: Entering directory `/home/kyle/gnuradio/gr-howto-write-a-block/python' make check-TESTS make[2]: Entering directory `/home/kyle/gnuradio/gr-howto-write-a-block/python' /home/kyle/gnuradio/gr-howto-write-a-block/lib:/home/kyle/gnuradio/gr-howto-writ e-a-block/lib/.libs:/home/kyle/gnuradio/gr-howto-write-a-block/swig:/home/kyle/g nuradio/gr-howto-write-a-block/swig/.libs:/home/kyle/gnuradio/gr-howto-write-a-b lock/python:/usr/local/lib/python2.5/site-packages:/usr/local/lib/python2.5/site -packages:/usr/local/lib/python2.5/site-packages/ Traceback (most recent call last): File ./qa_howto.py, line 24, in module import howto_swig File /home/kyle/gnuradio/gr-howto-write-a-block/swig/howto_swig.py, line 21, in module import _howto_swig ImportError: No such file or directory FAIL: run_tests == 1 of 1 test failed == make[2]: *** [check-TESTS] Error 1 make[2]: Leaving directory `/home/kyle/gnuradio/gr-howto-write-a-block/python' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/home/kyle/gnuradio/gr-howto-write-a-block/python' make: *** [check-recursive] Error 1 Your help is really appreciated. Kyle ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp and 52mhz installation problem
Hi all, I just purchased 52MHz external clock from Kestral signal processing, after successful follow up of installation guide ( http://gnuradio.org/redmine/wiki/1/OpenBTSClockModifications), I tested usrp I got this message: z...@zero-laptop:~/gnuradio/gnuradio-examples/python/usrp$ sudo ./usrp_benchmark_usb.py Testing 2MB/sec... and no any further lines, please let me know what I made wrong your reply is appreciated On Wed, May 12, 2010 at 9:36 PM, David Barton david.barto...@yahoo.comwrote: Hi, I have set up the following simple digital data transmitter: File source -à throttle-àpacket encoder --- DBPSK modulator - à USRP2 File size sample rate samples/sym - 2samples/sym – 2 Inter rate 32 -variable 3.125M bits/sym - 1 excess BW – 0.35 Freq 400M access code – n/a grey code - yes Gain 0 pad for USRP – yes payload len – 0 What is the transmit (over the air) data rate of this line up ? Please explain how the rate is derived. Thanks, Dave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] amplitude setting problem
Dear all, I'm using digital bert to transmit a BPSK modulated binary sequence. Since I don't need the rrc filter, I'm using the following to set the amplitude. self._amp = gr.multiply_const_cc(1) self.set_tx_amplitude(amplitude) set_tx_amplitude function definition is: def set_tx_amplitude(self, ampl): self.amplitude = max(0.0, min(ampl, 32767.0)) self._amp.set_k(self.amplitude) he result, however, doesn't show that the baseband signal is a square wave in with the rate given. What's the problem might be? How to set the sequence rate (baseband frquency)? Thanks in advance. Regards, Yan attachment: ynie3.vcf___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC problem
Your transmit amplitude is almost zero, try something around 10e3. See the notes in the usrp source block. On 05/12/2010 07:59 PM, intermilan wrote: hello all: I recently use GRC and USRP to do some experiment. But there is a problem for me. I use signal_source-packet_encoder-Gmsk_mod-usrp_sink in the transmit side.and it the receive side I use usrp_source-Gmsk_demod-packet_decoder-scope_sink.Now I know I can see the modulationed waveform in the scope_sink which is connected to the usrp_source. But I can not see anything in the last scope_sink. The correlative parameters which I set about the usrp_sink and usrp_source are the same as the defulat value in the benchmark_tx.py and benchmark_rx.py.and the other parameter in the other block is the defult value.Can anyone tell me how to figure out this problem? Thank you _ 一张照片的自白——Windows Live照片的可爱视频介绍 http://windowslivesky.spaces.live.com/blog/cns!5892B6048E2498BD!889.entry ___ 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] Unexplained out-of-sequence packets...
Hi Eric I was not running through a switch. I tried what you suggested, and can confirm that the CPUs are not being throttled. I have then discovered that for some reason I can only get the problem to occur on one of my two host PCs. I am trying to install the new Ubuntu (actually, the 64-bit version thereof) for the time being, after formatting the hard drive, and am hoping it will work on this PC afterwards. Cheers Ian. -Original Message- From: Eric Blossom [mailto:e...@comsec.com] Sent: Thursday, 13 May 2010 4:07 AM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Unexplained out-of-sequence packets... On Wed, May 12, 2010 at 04:34:36PM +0930, Ian Holland wrote: Hi Eric It seems this has not fixed the problem. Does anyone have any other suggestions as to the possible cause? Note, I also found power cycling the USRP2 can sometimes avoid the same problem. Ian. Ian, I still suspect something in your host setup. Is the USRP2 connected directly to the host or does it go through a switch? If there's a switch in the path, please remove it. Note that the cpu throttling / clock scaling hypothesis would explain why it works better under higher load than lower load. Are you sure that your cpu isn't being throttled? When you're seeing the problem, try: $ grep 'cpu MHz' /proc/cpuinfo and see if all cores are running at full speed. E.g., Idling laptop (throttled back from 1.83GHz): [...@cyan ~]$ grep 'cpu MHz' /proc/cpuinfo cpu MHz : 1000.000 cpu MHz : 1000.000 Server with cpu scaling disabled: [...@octo swig]$ grep 'cpu MHz' /proc/cpuinfo cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 cpu MHz : 2999.488 Eric -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Ian Holland Sent: Tuesday, 11 May 2010 11:14 AM To: Eric Blossom Cc: discuss-gnuradio@gnu.org Subject: RE: [Discuss-gnuradio] Unexplained out-of-sequence packets... Thanks Eric I checked the power management preferences and couldn't see anything about CPU throttling, though I did verify it would never go to sleep after inactivity. Then, I found some info on http://blog.mpathirage.com/2009/10/04/how-to-disable-dynamic-frequency-s calingcpu-throttling-in-ubuntu-jaunty9-04/ to disable the CPU throttling (I know I am using 9.10, not 9.04, but I imagine it should be the same). After rebooting (only once), I haven't yet seen the problem again. Unfortunately, given the seemingly random nature of the problem, I guess it is a wait-and-see matter as to whether it ever does resurface. Cheers Ian. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simple digital data transmitter
Eric Blossom wrote: Your baseband sample rate is 100M/32 - 3.125MS/s You're using 2 samples/symbol, thus your symbol rate is 3.125MS/s / 2 - 1.5625Msymbols/s And since you're using DBPSK, you're getting 1 bit/symbol, thus your raw over-the-air bit rate is 1.5625Mbit/s Hi Eric, a quick question about this. According to: _pick_bitrate(bitrate, bits_per_symbol, samples_per_symbol, xrate, converter_rate, xrates, gen_info) in pick_bitrate.py when the samples per symbol and interpolation are given, then our bitrate can be determined straight away. i.e Bitrate = converter_rate / xrate / samples_per_symbol Is this correct though, in determining the bitrate for both dbpsk dqpsk? For instance if we passed the_pick_bitrate() function an interpolation of 128 and Samples/symbol of 2, then according to the code, our bit rate for both dqpsk and dbpsk will be 500kbs. But according to what your saying: 1) for dbpsk if DAC rate = 128e6 Interpolation = 128 Samples/symbol = 2 Bitrate = 128e6 / 128 / 2 = 500k 2) for dqpsk Using the same parameters Bitrate = 128e6 / 128 / 2 / 2bits per symbol = 256K Have i missed something here, or in the code? Regards, Marcin -- View this message in context: http://old.nabble.com/Simple-digital-data-transmitter-tp28538027p28543866.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] Using USRP to conduct multipath measurements
Has anyone attempted to try this on the USRP or know of any successful projects? Or if anyone has a good paper to suggest on measurement methods, that would be great. I imagine that the timing synchronization would be difficult on the USRP. ? Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
