[Discuss-gnuradio] mailing list
subscribe. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] mailing list
approved - Original Message - From: mostafa khoshnevisan To: discuss-gnuradio@gnu.org Sent: Sunday, April 11, 2010 5:46 PM Subject: [Discuss-gnuradio] mailing list subscribe. -- ___ 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] A simple analogue question.
Hi everyone. I was wondering if someone could please answer the following question? If I have two signals entering a receiver, both with a power of 0 dBm, what would be the total input power seen by the receiver? Is it 3 dBm or 6 dBm? Thanks. Sebastiaan -- Sebastiaan Heunis Tel: +27 72 950 9370 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Transmitting higher power preamble
Hi all, Is it possible with GNU Radio to create a transmitter packet that has a higher power preamble at the beginning of the packet? This could allow the receiver to properly detect incoming packets. The data portion of this packet could have reduced transmit power level. I am currently using benchmark tx and rx files. Regards, Neha. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] rx_voice and tx_voice help
Hello.. We trying to run rx_voice and tx_voice python codes. It worked for the first time we could listen voice from the receiver side. But when we stop the code and try it again but this time an error occured about audio_alsa_sink and code didn't run. We tried this a few times and see that to run the code properly we should close the terminal and open a new terminal and also shut down the usrp and open it again.After these code could run again.What can be the reason of this and what should we do? I'm copying the error: audio_alsa_sink[hw:0,0]: Device or resource busy Traceback (most recent call last): File rx_voice.py, line 133, in module main() File rx_voice.py, line 123, in main tb = my_top_block(demods[options.modulation], rx_callback, options) File rx_voice.py, line 65, in __init__ self.audio_tx = audio_tx(options.audio_output) File rx_voice.py, line 54, in __init__ audio_sink = audio.sink(8000, audio_output_dev) File /usr/lib/python2.6/dist-packages/gnuradio/audio_alsa.py, line 299, in sink return _audio_alsa.sink(*args, **kwargs) RuntimeError: audio_alsa_sink Best Regards.. Merve.. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHF monitoring
Hi, I need to monitor usage of UHF bands (400-800MHz). I was wondering if this is possible to do using the gnuradio. For this, I was planning to do the following steps: 1. Buy an omni-directional discone antenna 2. Hook it up with gnuradio daughterboard (TVRX) I want to monitor channels with bandwidth 6Mhz. In particular, I want to see time-variant usage of channels in 400-800Mhz range. I do not really want to decipher down the signals. Can you please check if my method is correct or not. Thanks everybody. George -- View this message in context: http://old.nabble.com/UHF-monitoring-tp28209296p28209296.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
Re: [Discuss-gnuradio] A simple analogue question.
On Sun, Apr 11, 2010 at 10:12 AM, Sebastiaan Heunis sheu...@gmail.com wrote: Hi everyone. I was wondering if someone could please answer the following question? If I have two signals entering a receiver, both with a power of 0 dBm, what would be the total input power seen by the receiver? Is it 3 dBm or 6 dBm? Bringing it back to power instead of ratios helps clear this up. Both transmitters are emitting 1mW, for a total input power of 2mW. Calculating dBm on that yields: 10*log10(2mW/1mW) = 3dBm Hope this helps! Thanks. Sebastiaan Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting higher power preamble
On Sun, Apr 11, 2010 at 10:27 AM, neha kochar nehakoch...@gmail.com wrote: Hi all, Is it possible with GNU Radio to create a transmitter packet that has a higher power preamble at the beginning of the packet? This could allow the receiver to properly detect incoming packets. The data portion of this packet could have reduced transmit power level. I am currently using benchmark tx and rx files. The magnitude of the transmitted complex vector determines the output power (while in the linear range). If you set this magnitude to the value that corresponds to the maximum power output level of the USRP (just before clipping), you should be able to change it such that the data portion is scaled to a lower level. Actually doing this is left as an exercise for the reader. Regards, Neha. Good luck! Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] rx_voice and tx_voice help
2010/4/11 merve_aydo...@mynet.com: Hello.. We trying to run rx_voice and tx_voice python codes. It worked for the first time we could listen voice from the receiver side. But when we stop the code and try it again but this time an error occured about audio_alsa_sink and code didn't run. We tried this a few times and see that to run the code properly we should close the terminal and open a new terminal and also shut down the usrp and open it again.After these code could run again.What can be the reason of this and what should we do? I'm copying the error: audio_alsa_sink[hw:0,0]: Device or resource busy Traceback (most recent call last): File rx_voice.py, line 133, in module main() File rx_voice.py, line 123, in main tb = my_top_block(demods[options.modulation], rx_callback, options) File rx_voice.py, line 65, in __init__ self.audio_tx = audio_tx(options.audio_output) File rx_voice.py, line 54, in __init__ audio_sink = audio.sink(8000, audio_output_dev) File /usr/lib/python2.6/dist-packages/gnuradio/audio_alsa.py, line 299, in sink return _audio_alsa.sink(*args, **kwargs) RuntimeError: audio_alsa_sink Hi, You can see which applications/daemons use the sound devices with lsof /dev/snd/pcmC* (pulseaudio should be okay) I have seen this error many times when using flashplayer before running a GNU Radio script, but I have never seen it on two executions of the same GNU Radio script. Maybe you terminate your script abnormally and the device is not closed? Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] signal processing block help
Hi, I am trying to implement an equalization filter with fixed number of taps which is 45 regardless of input to the function. While I am doing make check my python test file fails because my module returns with an output whose size is equal to the size of src_data in my python test file. I mean if the input is of size 5 , the output is of size 5. I think this is because I did not override forecast method so the gr_block is doing 1:1 implementation now. How can I rearrange my code so that my noutput_items=45 always??? Best regards, Berk -- View this message in context: http://old.nabble.com/signal-processing-block-help-tp28209565p28209565.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] gnuradio make error
After successful configuration. I got the following 'make' error: I searched online and found that I need to set the LD_LIBRARY_PATH. I set LD_LIBRARY-PATH to my boost_install_directory/lib but still got the same error. Anyone has some idea? I appreciate if you can help. /bin/sh ../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o test_gruel test_gruel.o pmt/libpmt-qa.la libgruel.la g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o .libs/test_gruel test_gruel.o pmt/.libs/libpmt-qa.a -L/usr/lib64 -lcppunit -ldl ./.libs/libgruel.so -lboost_thread -lrt -Wl,--rpath -Wl,/home/xiongjie/install-gnuradio/lib64 ./.libs/libgruel.so: undefined reference to `boost::detail::get_current_thread_data()' ./.libs/libgruel.so: undefined reference to `boost::this_thread::disable_interruption::disable_interruption()' ./.libs/libgruel.so: undefined reference to `boost::thread::interrupt()' ./.libs/libgruel.so: undefined reference to `vtable for boost::detail::thread_data_base' ./.libs/libgruel.so: undefined reference to `boost::detail::thread_data_base::~thread_data_base()' ./.libs/libgruel.so: undefined reference to `boost::this_thread::disable_interruption::~disable_interruption()' ./.libs/libgruel.so: undefined reference to `typeinfo for boost::detail::thread_data_base' ./.libs/libgruel.so: undefined reference to `boost::thread::start_thread()' collect2: ld returned 1 exit status make[5]: *** [test_gruel] Error 1 -- Regards, XJ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] benchmark tx and rx help
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; Thanks again for replies.. nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;I'm looking for transmitted data (dbpsk mod).For instance (package_size=1500) when pktno=0 (first loop) package should contain 1498 'x00' and package no. At the receiver side i'm looking into the package by reading payload[2:4] but i see 257 for first package 514 for second package and for every new package it is increasing by 257.I expected to see 1 2 3.. and so on ..What can be the reason of this? How shoul i read the coming data at the receiver side? Best Regards Merve Aradığınız tüm videolar Mynet Video'da! İzlemek için hemen tıklayın! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHF monitoring
On Sun, Apr 11, 2010 at 08:01, schuler101 schuler...@gmail.com wrote: I want to monitor channels with bandwidth 6Mhz. In particular, I want to see time-variant usage of channels in 400-800Mhz range. I do not really want to decipher down the signals. Can you please check if my method is correct or not. Yes. The USRP1 or USRP2 and TVRX daughterboard will allow you to do exactly this. You will need to write a GNU Radio application to analyze the incoming samples and display the information you are interested in, unless the existing spectrum or oscilloscope utilities will give you what you want. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Hello
http://sites.google.com/site/gdy57itjdnshr4y/rnfx5a ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Spam
Brian already knows about the spam from his address. Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Spam
On Sun, Apr 11, 2010 at 2:50 PM, Philip Balister phi...@balister.org wrote: Brian already knows about the spam from his address. Philip Sorry about that. Apparently Russia seems to have someone who likes to be me. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] libusrp2 no longer needs omnithreads
The latest git master branch has an updated libusrp2 that no longer requires the use of the omnithreads library. Instead, all functions previously handled by omnithreads are handled by the boost threading library. This has been a transition in progress for some time, so it doesn't change any compilation requirements or prerequisites for GNU Radio proper. For those who may be building libusrp2 only, you may now use the the command: $ ./configure --disable-all-components --enable-gruel --enable-usrp2 ...to configure the GNU Radio source code tree. The omnithreads library has been deprecated and we've been slowly migrating functionality to use the boost threading library (via the gruel component.) At this point, there are only these remaining components in the tree which depending on omnithreads: gcell (mutexes and condition variables only) mblock gr-audio-osx (via the mld_threads class) usrp (via the mld_threads class) The gcell component can be changed easily, but will need testers on that platform to verify. The mblock library is deprecated and will likely not be converted. The last two components need some work to convert to Boost threads, but I haven't looked into this yet (Michael--can you address this?). Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Using a custom block
I'm looking for some information or references on what to do _after_ doing everything in the how to write a block tutorial in order to be able to access this block from other GNU radio python programs, for example changes to environment variables or whatever will be needed. I also would like to know what to put into the importfrom gnuradio import blks2/import element in the GRC block XML file so that I can use my custom blocks in GRC. Thanks for any help you can provide. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] IQ imbalance...
Hi Matt Having seen your reply, I realise I was not clear in my original post. At the time I observed this error, it was even at the output of the RRC filter, i.e. prior to the MM synch. and Costas loop. The strange thing is, now I am unable to repeat this problem. Instead, now I see clipping of both the I and Q components when I increase the Rx gain beyond a particular level. While on this matter, is there any risk of damaging the equipment by simply setting the Rx gain too high, or is clipping the only consequence? Ian -Original Message- From: Matt Ettus [mailto:m...@ettus.com] Sent: Friday, 9 April 2010 11:37 PM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] IQ imbalance... On 04/08/2010 09:16 PM, Ian Holland wrote: Hi All I am using a pair of USRP2s, each equipped with a XCVR2450, for transmission over-the-air of an RRC-filtered BPSK signal. The Tx antenna has 3dBi gain, and the Rx antenna has 18 dBi gain. The transmitted signal is at maximum amplitude, with gain set to 30 dB. The clocks on each end of the link are running from the internal oscillators - i.e. the clocks are not locked. At the receive side, using an MM synchroniser and Costas loop, I am able to see a BPSK constellation at the receiver when the Rx Gain setting is 30 dB. The amplitude of the constellation points is around 0.15 in this instance. However, when I increase the Rx Gain beyond 33 dB (in which case the constellation is centered around +/- 0.2 on the scope sink), there seems to be a large IQ amplitude balance, whereby the I signal is much stronger. Indeed, the Q signal disappears entirely when the Rx Gain is above around 36 dB. Is this expected behaviour, and if so, can anyone please explain why this is expected to occur? I'm not sure exactly what you're describing here, but I am pretty sure it is not what I would call IQ imbalance. IQ imbalance would show up before any frequency translation, so at the Costas loop output is not where you would see it. The purpose of a costas loop is to track the phase of the incoming signal. That means that the majority of the energy in a BPSK signal will be in I and little will be in Q when the loop is locked. The stronger the signal and the better the SNR, the smaller the Q amplitude will be relative to the I signal. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Real-time audio compression
Lie to flac about the sampling rate. Lying won't hurt it in the _slightest_. ___ Thanks for the hint. I'm now running the channel using FLAC compression in streaming mode, and it seems to be working fairly well. Took the network load down from about 1.6Mbit/sec to around 650Kbit/sec. -- 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
[Discuss-gnuradio] Large number of overflows...
Hi All I am trying a modified example of the digital-bert routines, for communication between 2 USRP2s, and notice that I am getting a very large number of overflows () even with decimation rate at the receiver of 20, and 4 samples per symbol (sometimes even with 20 samples/symbol). If I don't get overflows (as has occurred when I used 20 for decimation as well as 20 for samples/symbol in one instance), I am able to capture the demodulated bits as ..., as expected for the example. However, with overruns, which seem to occur more for lower samples per symbol and/or lower decimation values, I get a large number of bit errors. My receiver flowgraph is of the form: USRP2 Source -- RRC Filter -- Costas Loop -- Mueller and Muller Synch -- Complex to Real -- Binary Slicer -- Descrambler -- File Sink. The transmitter flowgraph uses the same blocks as per digital-bert/transmit_path.py, but with a USRP2 sink. I am transmitting over-the-air, and clocks are not synchronised between Tx and Rx. I have a gigabit Ethernet link, and 2 x 2 GHz CPUs in my PC, which is running Ubuntu 9.10. Can anyone suggest why I am getting so many over-runs, and how I could get around this problem? Thanks Ian. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] IQ imbalance...
As long as the input level is in the safe range, having too much gain would probably not damage anything. On the WBX, however, too much gain with a strong but normally safe level might be a problem. Matt On 04/11/2010 05:01 PM, Ian Holland wrote: Hi Matt Having seen your reply, I realise I was not clear in my original post. At the time I observed this error, it was even at the output of the RRC filter, i.e. prior to the MM synch. and Costas loop. The strange thing is, now I am unable to repeat this problem. Instead, now I see clipping of both the I and Q components when I increase the Rx gain beyond a particular level. While on this matter, is there any risk of damaging the equipment by simply setting the Rx gain too high, or is clipping the only consequence? Ian -Original Message- From: Matt Ettus [mailto:m...@ettus.com] Sent: Friday, 9 April 2010 11:37 PM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] IQ imbalance... On 04/08/2010 09:16 PM, Ian Holland wrote: Hi All I am using a pair of USRP2s, each equipped with a XCVR2450, for transmission over-the-air of an RRC-filtered BPSK signal. The Tx antenna has 3dBi gain, and the Rx antenna has 18 dBi gain. The transmitted signal is at maximum amplitude, with gain set to 30 dB. The clocks on each end of the link are running from the internal oscillators - i.e. the clocks are not locked. At the receive side, using an MM synchroniser and Costas loop, I am able to see a BPSK constellation at the receiver when the Rx Gain setting is 30 dB. The amplitude of the constellation points is around 0.15 in this instance. However, when I increase the Rx Gain beyond 33 dB (in which case the constellation is centered around +/- 0.2 on the scope sink), there seems to be a large IQ amplitude balance, whereby the I signal is much stronger. Indeed, the Q signal disappears entirely when the Rx Gain is above around 36 dB. Is this expected behaviour, and if so, can anyone please explain why this is expected to occur? I'm not sure exactly what you're describing here, but I am pretty sure it is not what I would call IQ imbalance. IQ imbalance would show up before any frequency translation, so at the Costas loop output is not where you would see it. The purpose of a costas loop is to track the phase of the incoming signal. That means that the majority of the energy in a BPSK signal will be in I and little will be in Q when the loop is locked. The stronger the signal and the better the SNR, the smaller the Q amplitude will be relative to the I signal. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
