Re: [Discuss-gnuradio] Pre-cog
https://github.com/jmalsbury/pre-cog -Adeel On Sat, Mar 2, 2013 at 4:59 AM, manjusha wrote: > Where can i download pre-cog? Please send me the link.. > > Thanks, > manjusha > > > > -- > View this message in context: > http://gnuradio.4.n7.nabble.com/Pre-cog-tp39943.html > Sent from the GnuRadio mailing list archive at Nabble.com. > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] timed command
2013/3/4 15:56, Josh Blum wrote: On 03/03/2013 09:28 PM, Gong Zhang wrote: Hi, I wanna transmit a 1khz Sinusoidal signal for one second and transmit 2khz for another second.The code maybe something like this: set_command_time(&mytime) sig_sin_source.work(...) set_command_time(&mytime+1) sig_sin_source.work(...) But as I know,the first set_command_time would back-pressure all subsequent timed commands.This would make it impossible for the second set_command_time to reach the USRP buffer in time. Is it correct?And what's the suggestion? I appreciate any tips. Thank you. For timing the transmission of samples you will want to use the stream tagging feature of gnuradio (some examples and docs in the link): http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNU_Radio_UHD#Using-UHD-Software-with-GNU-Radio The timed commands thing is really for timing settings like tuning the device, or setting gain at a specific time, its separate from the streaming interface. -josh Thank you for your valuable feedback.//If I wanna retune the device every second,it really has nothing to do with data stream.Maybe I should refer to python or UHD.Can you give me some example? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Very low packet loss rate for the discontinuous BPSK communications- the analysis and looking for solution
Alex, 1: U can try adjusting the synchronization loops bandwidth (Phase/Timing etc) see PFB_Timing documentation 2: Try reducing the receiver gain (for a constant tx-amplitude/gain) or reduce transmission amplitude/gain (for constant rx gain) -Adeel On Sat, Mar 2, 2013 at 10:21 AM, Alex Zhang wrote: > I think you may rarely get the correct packet with pktno = 0, in > continuous mode, as my guess. Your received correct packet starts from > pktno = 1. > Could you also try the discontinuous mode for the BPSK communications? > > My question is actually a problem that how to implement a more reliable > BPSK mod/demod in burst mode. The current bpsk example in GNURadio does not > work well in burst mode. > > > On Fri, Mar 1, 2013 at 11:12 PM, Manu T S wrote: > >> Alex, >> >> If it was about loosing sync, we would mostly loose the first packet even >> if we are sending in continuous mode. I personally face no such issues. >> >> >> On Sat, Mar 2, 2013 at 3:25 AM, Alex Zhang wrote: >> >>> Seems no one can shed a light on this topic? >>> >>> >>> On Thu, Feb 28, 2013 at 10:25 PM, Alex Zhang wrote: >>> Hello, In the current gr-digital/narrowband, I am using the benchmark_tx.py and rx.py to test the bpsk communications. It is found that the packet loss rate is very high (70% loss) in discontinuous mode where every 5 packets are in a burst. But in continuous mode, the paket loss rate is less than 10% for the same point to point link. I captured the waveform data. From the observed result, it seems that for each burst (5 packet), the bpsk receiver needs to re-do the frequency/time sync. This will directly causes that the first packet of each burst will definitely be crashed. Also, some burst can not be demodulated correctly at all. For the same reason, even in the continuous mode, the very first packet is also crashed at the receiver. I have tried to add very long preamble for each packet to ensure the data part of the packet can be received in well sync status. But the result is not very good. Before I get further investigation on the solutions, just wondering if any ideas or existing work within this community. -- Alex, *Dreams can come true – just believe.* >>> >>> >>> >>> -- >>> >>> Alex, >>> *Dreams can come true – just believe.* >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >> >> -- >> Manu T S >> > > > > -- > > Alex, > *Dreams can come true – just believe.* > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] module install Error: Unable to find 'pmt_swig.i'
using the usual method, i am trying to install the 4fsk demodulator block and i get this error: make[2]: Entering directory `/home/matt/gr-fsk4/src/lib' /usr/bin/swig -c++ -fvirtual -python -modern -I/usr/local/include/gnuradio/swig -I/usr/local/include/gnuradio -module fsk4 -o fsk4.cc ../../src/lib/fsk4.i /usr/local/include/gnuradio/swig/gr_basic_block.i:26: Error: Unable to find 'pmt_swig.i' the pmt_swig.i file is one of the directories here (usr/ local/include/gruel/swig) and note that when i execute op25 (another decoder block which uses the fsk4) the first output line is "Imported legacy fsk4". so now i am confused as to how grc is importing the fsk4 if i cant even install it? Thanks guys, Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 802.11b bbn error in gnuradio 3.6.2
bbn 802.11b is designed for gnuradio 3.1.1 but i am trying it run it in
gnuradio 3.6.2
i am getting the following error while running
bbn_80211b_tx.py/bbn_80211b_rx.py
Traceback (most recent call last): File "bbn_80211b_transmit_path.py", line
29, in from bbn_80211b_pkt import * File
"/home/snigdha/bbn_80211/src/examples/bbn_80211b_pkt.py", line 31, in from
gnuradio import bbn File
"/usr/local/lib/python2.7/dist-packages/gnuradio/bbn.py", line 24, in _bbn =
swig_import_helper() File
"/usr/local/lib/python2.7/dist-packages/gnuradio/bbn.py", line 20, in
swig_import_helper _mod = imp.load_module('_bbn', fp, pathname, description)
ImportError: /usr/local/lib/python2.7/dist-packages/gnuradio/_bbn.so:
undefined symbol: _ZN11omni_thread6init_tD1Ev
--
View this message in context:
http://gnuradio.4.n7.nabble.com/802-11b-bbn-error-in-gnuradio-3-6-2-tp39975.html
Sent from the GnuRadio mailing list archive at Nabble.com.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Very low packet loss rate for the discontinuous BPSK communications- the analysis and looking for solution
Alex, If Adeel's solution is not meeting your burst transmission specs, you can try implementing some fast openloop synchro algorithms given in [1],[2]. You could look into some data aided schemes too, though I haven't tried those yet. [1] Digital Communication Receivers, Heinrich Meyr, Section 8.2.2 [2] Two Frequency Estimation SchemesOperating Independently of Timing Information, Ferdinand Classen and Heinrich Meyr --- Regards Sreeraj Rajendran http://home.iitb.ac.in/~rsreeraj From: Adeel Anwar To: Alex Zhang Cc: discuss-gnuradio@gnu.org Sent: Monday, 4 March 2013 5:51 PM Subject: Re: [Discuss-gnuradio] Very low packet loss rate for the discontinuous BPSK communications- the analysis and looking for solution Alex, 1: U can try adjusting the synchronization loops bandwidth (Phase/Timing etc) see PFB_Timing documentation 2: Try reducing the receiver gain (for a constant tx-amplitude/gain) or reduce transmission amplitude/gain (for constant rx gain) -Adeel On Sat, Mar 2, 2013 at 10:21 AM, Alex Zhang wrote: I think you may rarely get the correct packet with pktno = 0, in continuous mode, as my guess. Your received correct packet starts from pktno = 1. > >Could you also try the discontinuous mode for the BPSK communications? > >My question is actually a problem that how to implement a more reliable BPSK >mod/demod in burst mode. The current bpsk example in GNURadio does not work >well in burst mode. > > > > >On Fri, Mar 1, 2013 at 11:12 PM, Manu T S wrote: > >Alex, >> >>If it was about loosing sync, we would mostly loose the first packet even if >>we are sending in continuous mode. I personally face no such issues. >> >> >> >> >>On Sat, Mar 2, 2013 at 3:25 AM, Alex Zhang wrote: >> >>Seems no one can shed a light on this topic? >>> >>> >>> >>>On Thu, Feb 28, 2013 at 10:25 PM, Alex Zhang wrote: >>> >>>Hello, In the current gr-digital/narrowband, I am using the benchmark_tx.py and rx.py to test the bpsk communications. It is found that the packet loss rate is very high (70% loss) in discontinuous mode where every 5 packets are in a burst. But in continuous mode, the paket loss rate is less than 10% for the same point to point link. I captured the waveform data. From the observed result, it seems that for each burst (5 packet), the bpsk receiver needs to re-do the frequency/time sync. This will directly causes that the first packet of each burst will definitely be crashed. Also, some burst can not be demodulated correctly at all. For the same reason, even in the continuous mode, the very first packet is also crashed at the receiver. I have tried to add very long preamble for each packet to ensure the data part of the packet can be received in well sync status. But the result is not very good. Before I get further investigation on the solutions, just wondering if any ideas or existing work within this community. -- Alex, Dreams can come true – just believe. >>> >>> >>> >>>-- >>> >>>Alex, >>>Dreams can come true – just believe. >>>___ >>>Discuss-gnuradio mailing list >>>Discuss-gnuradio@gnu.org >>>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >> >>-- >>Manu T S > > > >-- > >Alex, >Dreams can come true – just believe. >___ >Discuss-gnuradio mailing list >Discuss-gnuradio@gnu.org >https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GSoC -- Call for mentors
Hi everyone, I'm happy to say that our project list for GSoC 2013 looks pretty decent now: http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoC The next phase is to make sure all of the projects have mentors assigned (we already have four mentors, not counting myself--that's pretty good!). So what about you? Is there a project that sounds interesting to you, something you'd like to mentor? Just head to the GSoC wiki page and put your name down! The next phase is to lock down the projects and make sure they are descriptive enough and are tailored to the ~3 months timeframe of GSoC. So, for all projects, the following answers should be clear: - Is there are clear, measurable goal for the project? Can anyone understand what they would be doing if they sign up for it? - Is the volume of the project appropriate? Students should be able to finish during the 3 months period, assuming they work full-time and highly motivated (if they don't they fail, anyway). A good way to make sure of this is to have "stretch goals", or bonus objectives, or what you'd like to call them - If specific hardware is involved, is there a way to provide that? If anyone has some time to have a look at the projects and see if they're explained well enough, that would be nice. At the end of this week, we'll be pruning down the suggestions to 4-5 ideas that have mentors. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpRGauzlZ9ao.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] timed command
Your reply gave me much inspiration.Given the "set_command_time" would back-pressure all subsequent timed commands,would the data transmitting be suspended? 2013/3/4 Adeel Anwar : > Gong, > > Attached is a simple freq-hopping example using timed-commands. > U may need to change "freq_list " that should match ur RF-Daughter card > > > -Adeel > > On Mon, Mar 4, 2013 at 5:18 PM, Gong Zhang wrote: >> >> 2013/3/4 15:56, Josh Blum wrote: >>> >>> >>> On 03/03/2013 09:28 PM, Gong Zhang wrote: Hi, I wanna transmit a 1khz Sinusoidal signal for one second and transmit 2khz for another second.The code maybe something like this: set_command_time(&mytime) sig_sin_source.work(...) set_command_time(&mytime+1) sig_sin_source.work(...) But as I know,the first set_command_time would back-pressure all subsequent timed commands.This would make it impossible for the second set_command_time to reach the USRP buffer in time. Is it correct?And what's the suggestion? I appreciate any tips. Thank you. >>> For timing the transmission of samples you will want to use the stream >>> tagging feature of gnuradio (some examples and docs in the link): >>> >>> http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNU_Radio_UHD#Using-UHD-Software-with-GNU-Radio >>> >>> The timed commands thing is really for timing settings like tuning the >>> device, or setting gain at a specific time, its separate from the >>> streaming interface. >>> >>> -josh >>> >> Thank you for your valuable feedback.//If I wanna retune the device every >> second,it really has nothing to do with data stream.Maybe I should refer to >> python or UHD.Can you give me some example? >> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 802.11b bbn error in gnuradio 3.6.2
john,
That is a linker-related error. The bbn library uses omnithreads (as,
back in the day, did GNURadio).
Your best bet is likely going be to modify the BBN code to use
boost::threads (as GNURadio does currently). I believe there are some
discussions about this in the mailing list archives.
You could also try to install omnithreads and compile/link against it.
Good luck,
Doug
On Mon, Mar 4, 2013 at 8:54 AM, john wrote:
> bbn 802.11b is designed for gnuradio 3.1.1 but i am trying it run it in
> gnuradio 3.6.2
>
> i am getting the following error while running
> bbn_80211b_tx.py/bbn_80211b_rx.py
>
> Traceback (most recent call last): File "bbn_80211b_transmit_path.py", line
> 29, in from bbn_80211b_pkt import * File
> "/home/snigdha/bbn_80211/src/examples/bbn_80211b_pkt.py", line 31, in from
> gnuradio import bbn File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/bbn.py", line 24, in _bbn =
> swig_import_helper() File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/bbn.py", line 20, in
> swig_import_helper _mod = imp.load_module('_bbn', fp, pathname, description)
> ImportError: /usr/local/lib/python2.7/dist-packages/gnuradio/_bbn.so:
> undefined symbol: _ZN11omni_thread6init_tD1Ev
>
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/802-11b-bbn-error-in-gnuradio-3-6-2-tp39975.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Doug Geiger
doug.gei...@bioradiation.net
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Changing USRP -UHD- frequency
Hi everyone, I need to choose one of this options and I would really appreciate your help. I need to scan a range of the spectrum that is bigger than the USRP capacity. In order to solve this, I will scan chunks of the spectrum that cover the same spectrum range using several steps. I have thought in two approaches: 1: use gr.bin_statistics just to change the USRP frequency 2: Build a block to manipulate the variables used by the UHD block Which one would be better? (easier, efficient) Thanks Este documento puede contener información privilegiada o confidencial. Por tanto, usar esta información y sus anexos para propósitos ajenos a los de la Universidad Icesi, divulgarla a personas a las cuales no se encuentre destinado este correo o reproducirla total o parcialmente, se encuentra prohibido en virtud de la legislación vigente. La universidad no asumirá responsabilidad sobre información, opiniones o criterios contenidos en este correo que no estén directamente relacionados con la Icesi. Si usted no es el destinatario autorizado o por error recibe este mensaje, por favor informe al remitente y posteriormente bórrelo de su sistema sin conservar copia del mismo. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] timed command
On 03/04/2013 08:28 AM, Gong Zhang wrote: > Your reply gave me much inspiration.Given the "set_command_time" would > back-pressure all subsequent timed commands,would the data transmitting > be suspended? The streaming data will work independent of the backpressure when the command queue is full. -josh > > 2013/3/4 Adeel Anwar : > >> > Gong, >> > >> > Attached is a simple freq-hopping example using timed-commands. >> > U may need to change "freq_list " that should match ur RF-Daughter >> card >> > >> > >> > -Adeel >> > >> > On Mon, Mar 4, 2013 at 5:18 PM, Gong Zhang wrote: >> >>> >> >>> >> 2013/3/4 15:56, Josh Blum wrote: >>> >>> >>> >>> On 03/03/2013 09:28 PM, Gong Zhang wrote: > > Hi, > I wanna transmit a 1khz Sinusoidal signal for one second and > transmit > 2khz for another second.The code maybe something like this: > set_command_time(&mytime) > sig_sin_source.work(...) > set_command_time(&mytime+1) > sig_sin_source.work(...) > But as I know,the first set_command_time would back-pressure all > subsequent timed commands.This would make it impossible for > the second > set_command_time to reach the USRP buffer in time. > Is it correct?And what's the suggestion? > I appreciate any tips. > Thank you. > > >>> For timing the transmission of samples you will want to use the stream >>> tagging feature of gnuradio (some examples and docs in the link): >>> >>> http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNU_Radio_UHD#Using-UHD-Software-with-GNU-Radio >>> >>> The timed commands thing is really for timing settings like tuning the >>> device, or setting gain at a specific time, its separate from the >>> streaming interface. >>> >>> -josh >>> >>> >> Thank you for your valuable feedback.//If I wanna retune the >>> device every >>> >> second,it really has nothing to do with data stream.Maybe I should >>> refer to >>> >> python or UHD.Can you give me some example? >>> >> >>> >> >>> >> >>> >> ___ >>> >> Discuss-gnuradio mailing list >>> >> Discuss-gnuradio@gnu.org >>> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >> > >> > >> > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] timed command
>> > Thank you for your valuable feedback.//If I wanna retune the device > every second,it really has nothing to do with data stream.Maybe I should > refer to python or UHD.Can you give me some example? > Here is an example in C++ for tuning two LOs at a given time, the same methods are also available on the gr-uhd blocks and python wrappers: http://files.ettus.com/uhd_docs/manual/html/sync.html#align-los-in-the-front-end-sbx-wbx-n-series The name of the functions may be slightly different because the source/sink abstraction, see the name of the functions here: http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_source.h -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Configure UHD source and File sink to save integers
I'd like to feed a File Sink from a UHD Source with 4 channels -- 2 motherboards, each with A:A A:B subdev specs. To cut down on the file size, I'd like to record integers instead of floating point. Which data type should I tell the UHD source to produce? Which type should I tell the File Sink to record? What conversions do I need in between? I'd like to stay in GRC, if possible. TIA -Marc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Configure UHD source and File sink to save integers
On 03/04/2013 02:36 PM, mepard wrote: > I'd like to feed a File Sink from a UHD Source with 4 channels -- 2 > motherboards, each with A:A A:B subdev specs. To cut down on the file > size, I'd like to record integers instead of floating point. > > Which data type should I tell the UHD source to produce? Which type > should I tell the File Sink to record? What conversions do I need in > between? I'd like to stay in GRC, if possible. > Sure thing. You can set the file sink to integer (int32), and either set the usrp source block to vita word32 or sc16 type (both are 32 bits per sample). Thats still 4 streams, not sure if you are interleaving them or using 4 file sinks. -josh > TIA > > -Marc > > > ___ Discuss-gnuradio > mailing list Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Comments on the Logging architecture in gnuradio
Suggestion for future improvement : I would love to be able to enable logging on a module by module basis in python for gnuradio. Right now, I see that many modules take a --verbose option but that's it. It is all or nothing. It would be great to have a unified logging framework (that works across python and c++) so logging can be configured in one place and shows up in a unified stream (file). It should be possible to set logging levels ( FINE, FINER, FINEST etc. ) to control the amount of logging. I was actually a bit surprised not to see such a thing given the maturity of the code base. (I know you are going to ask me to volunteer to do it :-) but perhaps an effort is already under way?) Regards, -- M. Ranganathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Configure UHD source and File sink to save integers
On Mar 4, 2013, at 2:43 PM, Josh Blum wrote: > > On 03/04/2013 02:36 PM, mepard wrote: >> I'd like to feed a File Sink from a UHD Source with 4 channels -- 2 >> motherboards, each with A:A A:B subdev specs. To cut down on the file >> size, I'd like to record integers instead of floating point. >> >> Which data type should I tell the UHD source to produce? Which type >> should I tell the File Sink to record? What conversions do I need in >> between? I'd like to stay in GRC, if possible. >> > > Sure thing. You can set the file sink to integer (int32), and either set > the usrp source block to vita word32 or sc16 type (both are 32 bits per > sample). > > Thats still 4 streams, not sure if you are interleaving them or using 4 > file sinks. > One thing I forgot is that I'd like to convert complex to a single sint16 with just the "real" part, like I can convert complex to single float. It doesn't look like there is the equivalent of Complex To Real for integers. Is there an alternative to converting to floating point and back? -Marc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] please anwer: Changing USRP -UHD- frequency
De: USRP-users [usrp-users-boun...@lists.ettus.com] en nombre de Juan Daniel Fernandez Martinez [jdfernan...@icesi.edu.co] Enviado el: lunes, 04 de marzo de 2013 11:53 a.m. Para: usrp-us...@lists.ettus.com; discuss-gnuradio@gnu.org Asunto: [USRP-users] Changing USRP -UHD- frequency Hi everyone, I need to choose one of this options and I would really appreciate your help. I need to scan a range of the spectrum that is bigger than the USRP capacity. In order to solve this, I will scan chunks of the spectrum that cover the same spectrum range using several steps. I have thought in two approaches: 1: use gr.bin_statistics just to change the USRP frequency 2: Build a block to manipulate the variables used by the UHD block (I do not know how to change variables values (the ones that are like blocks) within a block) Which one would be better? (easier, efficient) Thanks Este documento puede contener información privilegiada o confidencial. Por tanto, usar esta información y sus anexos para propósitos ajenos a los de la Universidad Icesi, divulgarla a personas a las cuales no se encuentre destinado este correo o reproducirla total o parcialmente, se encuentra prohibido en virtud de la legislación vigente. La universidad no asumirá responsabilidad sobre información, opiniones o criterios contenidos en este correo que no estén directamente relacionados con la Icesi. Si usted no es el destinatario autorizado o por error recibe este mensaje, por favor informe al remitente y posteriormente bórrelo de su sistema sin conservar copia del mismo. Este documento puede contener información privilegiada o confidencial. Por tanto, usar esta información y sus anexos para propósitos ajenos a los de la Universidad Icesi, divulgarla a personas a las cuales no se encuentre destinado este correo o reproducirla total o parcialmente, se encuentra prohibido en virtud de la legislación vigente. La universidad no asumirá responsabilidad sobre información, opiniones o criterios contenidos en este correo que no estén directamente relacionados con la Icesi. Si usted no es el destinatario autorizado o por error recibe este mensaje, por favor informe al remitente y posteriormente bórrelo de su sistema sin conservar copia del mismo. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Pre-cog
thank you Aneel -- View this message in context: http://gnuradio.4.n7.nabble.com/Pre-cog-tp39943p39988.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Comments on the Logging architecture in gnuradio
On Mon, Mar 4, 2013 at 3:55 PM, M. Ranganathan wrote: > Suggestion for future improvement : I would love to be able to enable > logging on a module by module basis in python for gnuradio. Right now, I see > that many modules take a --verbose option but that's it. It is all or > nothing. > > It would be great to have a unified logging framework (that works across > python and c++) so logging can be configured in one place and shows up in a > unified stream (file). It should be possible to set logging levels ( FINE, > FINER, FINEST etc. ) to control the amount of logging. > > I was actually a bit surprised not to see such a thing given the maturity of > the code base. > > (I know you are going to ask me to volunteer to do it :-) but perhaps an > effort is already under way?) > > Regards, > > > > -- > M. Ranganathan Funny you should ask. A new gr-logger was put into master/next /just/ this morning. If you build the Doxygen manually locally (after updating your local checkout), there is a new "Related Pages" for "Logging." It's new, so it's not widely used. It's very simple to use from inside a gr_block, but there's some setup to do elsewhere. I'm still thinking of ways to make this as simple to use and ubiquitous throughout our code as possible. But this is an excellent start, I feel. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] please anwer: Changing USRP -UHD- frequency
On 03/04/2013 03:49 PM, Juan Daniel Fernandez Martinez wrote: > > > De: USRP-users [usrp-users-boun...@lists.ettus.com] en nombre de Juan Daniel > Fernandez Martinez [jdfernan...@icesi.edu.co] > Enviado el: lunes, 04 de marzo de 2013 11:53 a.m. > Para: usrp-us...@lists.ettus.com; discuss-gnuradio@gnu.org > Asunto: [USRP-users] Changing USRP -UHD- frequency > > Hi everyone, > I need to choose one of this options and I would really appreciate your help. > I need to scan a range of the spectrum that is bigger than the USRP capacity. > In order to solve this, I will scan chunks of the spectrum that cover the > same spectrum range using several steps. > I have thought in two approaches: > 1: use gr.bin_statistics just to change the USRP frequency > 2: Build a block to manipulate the variables used by the UHD block (I do not > know how to change variables values (the ones that are like blocks) within a > block) > > Which one would be better? (easier, efficient) I think developing option 1 would be faster because its a more typical programming approach and you dont have to understand much of the gnuradio infrastructure. And I suppose gr bin stats can act as a helpful reference for you in this case. -josh > Thanks > > > > Este documento puede contener información privilegiada o confidencial. Por > tanto, usar esta información y sus anexos para propósitos ajenos a los de la > Universidad Icesi, divulgarla a personas a las cuales no se encuentre > destinado este correo o reproducirla total o parcialmente, se encuentra > prohibido en virtud de la legislación vigente. La universidad no asumirá > responsabilidad sobre información, opiniones o criterios contenidos en este > correo que no estén directamente relacionados con la Icesi. Si usted no es el > destinatario autorizado o por error recibe este mensaje, por favor informe al > remitente y posteriormente bórrelo de su sistema sin conservar copia del > mismo. > > > > Este documento puede contener información privilegiada o confidencial. Por > tanto, usar esta información y sus anexos para propósitos ajenos a los de la > Universidad Icesi, divulgarla a personas a las cuales no se encuentre > destinado este correo o reproducirla total o parcialmente, se encuentra > prohibido en virtud de la legislación vigente. La universidad no asumirá > responsabilidad sobre información, opiniones o criterios contenidos en este > correo que no estén directamente relacionados con la Icesi. Si usted no es el > destinatario autorizado o por error recibe este mensaje, por favor informe al > remitente y posteriormente bórrelo de su sistema sin conservar copia del > mismo. > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Configure UHD source and File sink to save integers
On 03/04/2013 03:07 PM, mepard wrote: > > On Mar 4, 2013, at 2:43 PM, Josh Blum wrote: >> >> On 03/04/2013 02:36 PM, mepard wrote: >>> I'd like to feed a File Sink from a UHD Source with 4 channels -- 2 >>> motherboards, each with A:A A:B subdev specs. To cut down on the file >>> size, I'd like to record integers instead of floating point. >>> >>> Which data type should I tell the UHD source to produce? Which type >>> should I tell the File Sink to record? What conversions do I need in >>> between? I'd like to stay in GRC, if possible. >>> >> >> Sure thing. You can set the file sink to integer (int32), and either set >> the usrp source block to vita word32 or sc16 type (both are 32 bits per >> sample). >> >> Thats still 4 streams, not sure if you are interleaving them or using 4 >> file sinks. >> > > One thing I forgot is that I'd like to convert complex to a single > sint16 with just the "real" part, like I can convert complex to single > float. It doesn't look like there is the equivalent of Complex To Real for > integers. > > Is there an alternative to converting to floating point and back? you could vector to streams, and null sink the second stream. * 1 input stream of vec length 2 and item size short * 2 output streams of item size short -josh > > -Marc > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] timed command
Thank you for your reply.And this may lead to ambiguous. The streaming data will totally work independent of the backpressure or it will be backpressure untill the command queue is full? 2013/3/5 1:26, Josh Blum wrote: On 03/04/2013 08:28 AM, Gong Zhang wrote: Your reply gave me much inspiration.Given the "set_command_time" would back-pressure all subsequent timed commands,would the data transmitting be suspended? The streaming data will work independent of the backpressure when the command queue is full. -josh 2013/3/4 Adeel Anwar : Gong, Attached is a simple freq-hopping example using timed-commands. U may need to change "freq_list " that should match ur RF-Daughter card -Adeel On Mon, Mar 4, 2013 at 5:18 PM, Gong Zhang wrote: 2013/3/4 15:56, Josh Blum wrote: On 03/03/2013 09:28 PM, Gong Zhang wrote: Hi, I wanna transmit a 1khz Sinusoidal signal for one second and transmit 2khz for another second.The code maybe something like this: set_command_time(&mytime) sig_sin_source.work(...) set_command_time(&mytime+1) sig_sin_source.work(...) But as I know,the first set_command_time would back-pressure all subsequent timed commands.This would make it impossible for the second set_command_time to reach the USRP buffer in time. Is it correct?And what's the suggestion? I appreciate any tips. Thank you. For timing the transmission of samples you will want to use the stream tagging feature of gnuradio (some examples and docs in the link): http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNU_Radio_UHD#Using-UHD-Software-with-GNU-Radio The timed commands thing is really for timing settings like tuning the device, or setting gain at a specific time, its separate from the streaming interface. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr log configuration error
master ubuntu 12.04 > CMake Error: The following variables are used in this project, but they are > set to NOTFOUND. > Please set them or make sure they are set and tested correctly in the CMake > files: > LOG4CXX_INCLUDE_DIRS (ADVANCED) >used as include directory in directory > /home/jblum/src/gnuradio/gnuradio-core/src/lib >used as include directory in directory > /home/jblum/src/gnuradio/gnuradio-core/src/tests >used as include directory in directory > /home/jblum/src/gnuradio/gnuradio-core/src/lib/swig >used as include directory in directory > /home/jblum/src/gnuradio/gr-filter/lib >used as include directory in directory > /home/jblum/src/gnuradio/gr-atsc/src/lib >used as include directory in directory > /home/jblum/src/gnuradio/gr-audio/lib >used as include directory in directory > /home/jblum/src/gnuradio/gr-comedi/src >used as include directory in directory > /home/jblum/src/gnuradio/gr-digital/lib >used as include directory in directory /home/jblum/src/gnuradio/gr-noaa/lib >used as include directory in directory > /home/jblum/src/gnuradio/gr-pager/lib >used as include directory in directory > /home/jblum/src/gnuradio/gr-qtgui/lib >used as include directory in directory > /home/jblum/src/gnuradio/gr-trellis/src/lib >used as include directory in directory /home/jblum/src/gnuradio/gr-uhd/lib >used as include directory in directory > /home/jblum/src/gnuradio/gr-video-sdl/src >used as include directory in directory > /home/jblum/src/gnuradio/gr-vocoder/lib >used as include directory in directory /home/jblum/src/gnuradio/gr-fcd/lib >used as include directory in directory > /home/jblum/src/gnuradio/gr-wavelet/lib > LOG4CXX_LIBRARIES (ADVANCED) > linked by target "gnuradio-core" in directory > /home/jblum/src/gnuradio/gnuradio-core/src/lib > linked by target "_gnuradio_core_filter" in directory > /home/jblum/src/gnuradio/gnuradio-core/src/lib/swig > linked by target "_gnuradio_core_general" in directory > /home/jblum/src/gnuradio/gnuradio-core/src/lib/swig > linked by target "_gnuradio_core_gengen" in directory > /home/jblum/src/gnuradio/gnuradio-core/src/lib/swig > linked by target "_gnuradio_core_hier" in directory > /home/jblum/src/gnuradio/gnuradio-core/src/lib/swig > linked by target "_gnuradio_core_io" in directory > /home/jblum/src/gnuradio/gnuradio-core/src/lib/swig > linked by target "_gnuradio_core_runtime" in directory > /home/jblum/src/gnuradio/gnuradio-core/src/lib/swig > linked by target "gnuradio-atsc" in directory > /home/jblum/src/gnuradio/gr-atsc/src/lib > linked by target "gnuradio-audio" in directory > /home/jblum/src/gnuradio/gr-audio/lib > linked by target "gnuradio-comedi" in directory > /home/jblum/src/gnuradio/gr-comedi/src > linked by target "gnuradio-digital" in directory > /home/jblum/src/gnuradio/gr-digital/lib > linked by target "gnuradio-noaa" in directory > /home/jblum/src/gnuradio/gr-noaa/lib > linked by target "gnuradio-pager" in directory > /home/jblum/src/gnuradio/gr-pager/lib > linked by target "gnuradio-qtgui" in directory > /home/jblum/src/gnuradio/gr-qtgui/lib > linked by target "gnuradio-trellis" in directory > /home/jblum/src/gnuradio/gr-trellis/src/lib > linked by target "gnuradio-uhd" in directory > /home/jblum/src/gnuradio/gr-uhd/lib > linked by target "gnuradio-video-sdl" in directory > /home/jblum/src/gnuradio/gr-video-sdl/src > linked by target "gnuradio-vocoder" in directory > /home/jblum/src/gnuradio/gr-vocoder/lib > linked by target "gnuradio-fcd" in directory > /home/jblum/src/gnuradio/gr-fcd/lib > linked by target "gnuradio-wavelet" in directory > /home/jblum/src/gnuradio/gr-wavelet/lib ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr log configuration error
I can corroborate this. On Mon, Mar 4, 2013 at 5:36 PM, Josh Blum wrote: > master ubuntu 12.04 > > > CMake Error: The following variables are used in this project, but they > are set to NOTFOUND. > > Please set them or make sure they are set and tested correctly in the > CMake files: > > LOG4CXX_INCLUDE_DIRS (ADVANCED) > >used as include directory in directory > /home/jblum/src/gnuradio/gnuradio-core/src/lib > >used as include directory in directory > /home/jblum/src/gnuradio/gnuradio-core/src/tests > >used as include directory in directory > /home/jblum/src/gnuradio/gnuradio-core/src/lib/swig > >used as include directory in directory > /home/jblum/src/gnuradio/gr-filter/lib > >used as include directory in directory > /home/jblum/src/gnuradio/gr-atsc/src/lib > >used as include directory in directory > /home/jblum/src/gnuradio/gr-audio/lib > >used as include directory in directory > /home/jblum/src/gnuradio/gr-comedi/src > >used as include directory in directory > /home/jblum/src/gnuradio/gr-digital/lib > >used as include directory in directory > /home/jblum/src/gnuradio/gr-noaa/lib > >used as include directory in directory > /home/jblum/src/gnuradio/gr-pager/lib > >used as include directory in directory > /home/jblum/src/gnuradio/gr-qtgui/lib > >used as include directory in directory > /home/jblum/src/gnuradio/gr-trellis/src/lib > >used as include directory in directory > /home/jblum/src/gnuradio/gr-uhd/lib > >used as include directory in directory > /home/jblum/src/gnuradio/gr-video-sdl/src > >used as include directory in directory > /home/jblum/src/gnuradio/gr-vocoder/lib > >used as include directory in directory > /home/jblum/src/gnuradio/gr-fcd/lib > >used as include directory in directory > /home/jblum/src/gnuradio/gr-wavelet/lib > > LOG4CXX_LIBRARIES (ADVANCED) > > linked by target "gnuradio-core" in directory > /home/jblum/src/gnuradio/gnuradio-core/src/lib > > linked by target "_gnuradio_core_filter" in directory > /home/jblum/src/gnuradio/gnuradio-core/src/lib/swig > > linked by target "_gnuradio_core_general" in directory > /home/jblum/src/gnuradio/gnuradio-core/src/lib/swig > > linked by target "_gnuradio_core_gengen" in directory > /home/jblum/src/gnuradio/gnuradio-core/src/lib/swig > > linked by target "_gnuradio_core_hier" in directory > /home/jblum/src/gnuradio/gnuradio-core/src/lib/swig > > linked by target "_gnuradio_core_io" in directory > /home/jblum/src/gnuradio/gnuradio-core/src/lib/swig > > linked by target "_gnuradio_core_runtime" in directory > /home/jblum/src/gnuradio/gnuradio-core/src/lib/swig > > linked by target "gnuradio-atsc" in directory > /home/jblum/src/gnuradio/gr-atsc/src/lib > > linked by target "gnuradio-audio" in directory > /home/jblum/src/gnuradio/gr-audio/lib > > linked by target "gnuradio-comedi" in directory > /home/jblum/src/gnuradio/gr-comedi/src > > linked by target "gnuradio-digital" in directory > /home/jblum/src/gnuradio/gr-digital/lib > > linked by target "gnuradio-noaa" in directory > /home/jblum/src/gnuradio/gr-noaa/lib > > linked by target "gnuradio-pager" in directory > /home/jblum/src/gnuradio/gr-pager/lib > > linked by target "gnuradio-qtgui" in directory > /home/jblum/src/gnuradio/gr-qtgui/lib > > linked by target "gnuradio-trellis" in directory > /home/jblum/src/gnuradio/gr-trellis/src/lib > > linked by target "gnuradio-uhd" in directory > /home/jblum/src/gnuradio/gr-uhd/lib > > linked by target "gnuradio-video-sdl" in directory > /home/jblum/src/gnuradio/gr-video-sdl/src > > linked by target "gnuradio-vocoder" in directory > /home/jblum/src/gnuradio/gr-vocoder/lib > > linked by target "gnuradio-fcd" in directory > /home/jblum/src/gnuradio/gr-fcd/lib > > linked by target "gnuradio-wavelet" in directory > /home/jblum/src/gnuradio/gr-wavelet/lib > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Nicholas Corgan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr log configuration error
On Mon, Mar 4, 2013 at 9:49 PM, Nicholas Corgan wrote: > I can corroborate this. Try again. This was fixed earlier this evening in commit d502e39c90c16b461be133366068d699f034e31c. Tom > On Mon, Mar 4, 2013 at 5:36 PM, Josh Blum wrote: >> >> master ubuntu 12.04 >> >> > CMake Error: The following variables are used in this project, but they >> > are set to NOTFOUND. >> > Please set them or make sure they are set and tested correctly in the >> > CMake files: >> > LOG4CXX_INCLUDE_DIRS (ADVANCED) >> >used as include directory in directory >> > /home/jblum/src/gnuradio/gnuradio-core/src/lib >> >used as include directory in directory >> > /home/jblum/src/gnuradio/gnuradio-core/src/tests >> >used as include directory in directory >> > /home/jblum/src/gnuradio/gnuradio-core/src/lib/swig >> >used as include directory in directory >> > /home/jblum/src/gnuradio/gr-filter/lib >> >used as include directory in directory >> > /home/jblum/src/gnuradio/gr-atsc/src/lib >> >used as include directory in directory >> > /home/jblum/src/gnuradio/gr-audio/lib >> >used as include directory in directory >> > /home/jblum/src/gnuradio/gr-comedi/src >> >used as include directory in directory >> > /home/jblum/src/gnuradio/gr-digital/lib >> >used as include directory in directory >> > /home/jblum/src/gnuradio/gr-noaa/lib >> >used as include directory in directory >> > /home/jblum/src/gnuradio/gr-pager/lib >> >used as include directory in directory >> > /home/jblum/src/gnuradio/gr-qtgui/lib >> >used as include directory in directory >> > /home/jblum/src/gnuradio/gr-trellis/src/lib >> >used as include directory in directory >> > /home/jblum/src/gnuradio/gr-uhd/lib >> >used as include directory in directory >> > /home/jblum/src/gnuradio/gr-video-sdl/src >> >used as include directory in directory >> > /home/jblum/src/gnuradio/gr-vocoder/lib >> >used as include directory in directory >> > /home/jblum/src/gnuradio/gr-fcd/lib >> >used as include directory in directory >> > /home/jblum/src/gnuradio/gr-wavelet/lib >> > LOG4CXX_LIBRARIES (ADVANCED) >> > linked by target "gnuradio-core" in directory >> > /home/jblum/src/gnuradio/gnuradio-core/src/lib >> > linked by target "_gnuradio_core_filter" in directory >> > /home/jblum/src/gnuradio/gnuradio-core/src/lib/swig >> > linked by target "_gnuradio_core_general" in directory >> > /home/jblum/src/gnuradio/gnuradio-core/src/lib/swig >> > linked by target "_gnuradio_core_gengen" in directory >> > /home/jblum/src/gnuradio/gnuradio-core/src/lib/swig >> > linked by target "_gnuradio_core_hier" in directory >> > /home/jblum/src/gnuradio/gnuradio-core/src/lib/swig >> > linked by target "_gnuradio_core_io" in directory >> > /home/jblum/src/gnuradio/gnuradio-core/src/lib/swig >> > linked by target "_gnuradio_core_runtime" in directory >> > /home/jblum/src/gnuradio/gnuradio-core/src/lib/swig >> > linked by target "gnuradio-atsc" in directory >> > /home/jblum/src/gnuradio/gr-atsc/src/lib >> > linked by target "gnuradio-audio" in directory >> > /home/jblum/src/gnuradio/gr-audio/lib >> > linked by target "gnuradio-comedi" in directory >> > /home/jblum/src/gnuradio/gr-comedi/src >> > linked by target "gnuradio-digital" in directory >> > /home/jblum/src/gnuradio/gr-digital/lib >> > linked by target "gnuradio-noaa" in directory >> > /home/jblum/src/gnuradio/gr-noaa/lib >> > linked by target "gnuradio-pager" in directory >> > /home/jblum/src/gnuradio/gr-pager/lib >> > linked by target "gnuradio-qtgui" in directory >> > /home/jblum/src/gnuradio/gr-qtgui/lib >> > linked by target "gnuradio-trellis" in directory >> > /home/jblum/src/gnuradio/gr-trellis/src/lib >> > linked by target "gnuradio-uhd" in directory >> > /home/jblum/src/gnuradio/gr-uhd/lib >> > linked by target "gnuradio-video-sdl" in directory >> > /home/jblum/src/gnuradio/gr-video-sdl/src >> > linked by target "gnuradio-vocoder" in directory >> > /home/jblum/src/gnuradio/gr-vocoder/lib >> > linked by target "gnuradio-fcd" in directory >> > /home/jblum/src/gnuradio/gr-fcd/lib >> > linked by target "gnuradio-wavelet" in directory >> > /home/jblum/src/gnuradio/gr-wavelet/lib >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > -- > Nicholas Corgan > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] uhd transmitter receiver
Please i Need help. I am using USRPN210 and i use UHD source and sink. i made flow-graph for transmitter using signal source/fm modulator/ uhd sinkand for receiver using UHD source /fm Demodjust i want to see the signal in RF after modulation and when receiving it. can anyone advise me or have tutorials to do that in same flow graph or making delay between transmission and receiving mode. or any think related to this topic.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
