[Discuss-gnuradio] Time Granularity of USRP N2XX
Hi, Since we can get receive time of rx_stream's first sample via rx tags, I have two questions about the time granularity. Given the internal clock is 10Mhz, is the time granularity 0.1us? The fractional second is stored double type. Does it mean the last digits of the fractional sec are invalid? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Time Granularity of USRP N2XX
Hi Harry, as far as I know, the granularity of a time stamp is the sample duration at the downsampled side. As for the 10MHz: The 10MHz clock is used to derive different other clocks, especially the rx ADC and tx DAC clocks, which are an order of magnitude higher; bear in mind that when you request e.g. "5MHz samle rate" you still get the 100MHz* samples of the ADC, but downsampled by a factor of 20. Please also bear in mind that due to physics, processing etc the timestamp of the rx side is delayed to the actual reception of "that sample", and that this delay is largely constant when receiving using the same settings, but my change based on sampling rate and other factors. Greetings Marcus *for USRP2 arch, if I remember correctly. On 26.11.2013 13:04, Harry Zhang wrote: Hi, Since we can get receive time of rx_stream's first sample via rx tags, I have two questions about the time granularity. Given the internal clock is 10Mhz, is the time granularity 0.1us? The fractional second is stored double type. Does it mean the last digits of the fractional sec are invalid? ___ 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] Time Granularity of USRP N2XX
Dear Marcus, Thank you for your reply. I'm confused about two concepts. Referring to the file time_spec.hpp in UHD, fractional sec is calculated according to the parameter ticks and tick_rate. So I think the time granularity is '1/tick_rate' which is 0.1us using 10Mhz clock. But for the timestamp of sample stream, the granularity is the sample duration. Is it correct? Best, Harry 2013/11/26 20:12, Marcus Müller wrote: Hi Harry, as far as I know, the granularity of a time stamp is the sample duration at the downsampled side. As for the 10MHz: The 10MHz clock is used to derive different other clocks, especially the rx ADC and tx DAC clocks, which are an order of magnitude higher; bear in mind that when you request e.g. "5MHz samle rate" you still get the 100MHz* samples of the ADC, but downsampled by a factor of 20. Please also bear in mind that due to physics, processing etc the timestamp of the rx side is delayed to the actual reception of "that sample", and that this delay is largely constant when receiving using the same settings, but my change based on sampling rate and other factors. Greetings Marcus *for USRP2 arch, if I remember correctly. On 26.11.2013 13:04, Harry Zhang wrote: Hi, Since we can get receive time of rx_stream's first sample via rx tags, I have two questions about the time granularity. Given the internal clock is 10Mhz, is the time granularity 0.1us? The fractional second is stored double type. Does it mean the last digits of the fractional sec are invalid? ___ 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] Problem using FFT-class in my own written block
On Tue, Nov 26, 2013 at 8:57 AM, wrote: > Hi all, > > I wrote my own block in C++, and used gr-modtool to do all the 'things' > around it as described in the tutorial "Out-of-tree modules". > > I included 'fft/fft.h' in the C++ source code of the block, and used the > class 'fft_complex'. Then after: > >cmake ../ >make > > everything compiles/builds without error, and after: > >make install > > the block is available in GNU Radio Companion. > > However, when trying to run a design using this block, I get the following > error: > >ImportError /usr/local/libgnuradio-MY_MODULE.so: undefined symbol: > fft_complex > > I tried executing "sudo ldconfig" but this doesn't solve the problem. So, > does anybody know how to solve this? Please note: > >* I use a USB-stick environment by Ettus Research, GNU C++ version 4.7.2 >* I am an absolute beginner regarding Linux and GNU Radio etc. So if > files need to be modified please let me know which files, where it should > (can) be located etc... > > Thanks for reading, > >Jeroen Jeroen, That tutorial you mentioned doesn't give you the whole picture about configuring your OOT module with different needs like yours. Also read through this one: http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModulesConfig And note the subtle change between 3.7.2 versus later (currently only on git) versions. You're going to have to go in and edit your CMakeLists.txt files in both the root directory of your OOT module and the lib directory. Right now, what's likely happening is that you aren't linking against the libraries you need. This tutorial will explain how to find and link against libgnuradio-fft.so. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WX GUI Constellation sink plot freez ?
On Mon, Nov 25, 2013 at 12:26 PM, Naceur wrote: > Hello list, > > I got questions re the WX GUI Constellation Sink block: > > 1/ Could anyone give descriptions of what is > > * Theta ? > * Loop bandwidth ? > * Max Freq ? > * Mu ? > * Gain Mu ? > * Symbol Rate ? > * Omega Limit ? This block basically uses the M&M clock recovery block: http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1clock__recovery__mm__cc.html And the Costas loop block: http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1costas__loop__cc.html That should explain much about those parameters. The Theta value is the phase rotation of the locked constellation. So you can readjust a QPSK that sits on the +/-1 +/- 1j points to the x and y axes by setting theta to pi/4. > 2/ What are the essential params of the block to adjust, for my case I am > receiving a BPSK signal (Params @ Tx are: 10 MHz samp_rate, ow_format sc8, > Samples/Symbol = 4, Spread signal with a 11 chips code), > > I set: > sample_rate = 10 MHz, > Frame rate = 512, > Constellation Size = 512, > M = 2, Drop the frame rate. You're trying to display 512 frames/second, which is too fast for you to even see and asking your computer to do a lot of extra work. The default of 5 should be enough. > 3/ Once the constellation plotted it freezes and "O"s appears in the > terminal section of GRC ? > What am I doing wrong ? > > Regards, That indicates not enough processing power. You're now trying to do too much in the graph for your processor. Can you try a lower symbol rate signal to start off with? Get the feel for the parameters and setup and try to understand the performance limitations before jumping right in to your full signal. But also, just dropping the frame rate as I suggest above should give you back a lot of processing time. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] AttributeError: 'gr_msg_queue_sptr'
Thanks a lot Marcus, that helped a lot. I mofified the gr_msg_queue.i as you told me in b) and it worked! Regards, Nada Marcus Müller a écrit : Hi Nada, that's really hard to tell based on the information you gave. I'm currently on the run, so I can't really look at the 3.6 branch and give definite advice, but: a) make sure there is no special c++-to-python gateway class for the things you're trying to extend b) look into the swig files (ending in .i), whether there is some special wrapping for gr_msg_queue c) in your build directory, delete the swig/ subfolder and rebuild; sometimes, swig/make do strange things d) are you really sure you want to do this? From my point of view I'd rather keep the "real" queue structure, and whenever my "consumer" is able to fetch objects from the message queue, it should probably get them all and prioritize itself; but however, there are strong arguments for your approach :) Greetings, Marcus On 22.11.2013 16:18, Nada ABDELKADER wrote: Hi all, I have gnuradio 3.6.5 on Ubuntu 12.10. I needed to add some priority to some packets and insert them on the head of the message queue. I defined a new function "insert_head" in gr_msg_queue.c and gr_msg_queue.h and build my gnuradio. I got this error when running: File "/usr/local/lib/python2.7/dist-packages/gnuradio/digital/pkt.py", line 103, in send_pkt self._pkt_input.msgq().insert_head(msg) AttributeError: 'gr_msg_queue_sptr' object has no attribute 'insert_head' Did I miss some thing? Any help plz? Nada This message was sent using IMP, the Internet Messaging Program. ___ 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 This message was sent using IMP, the Internet Messaging Program. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Pending release
We'll be making a 3.7.2.1 release this coming weekend as a bug-fix only release of everything that has accumulated on the maint branch since 3.7.2. If you have any pending bug fixes that haven't been pull requested, now is the time to get them in. -- Johnathan Corgan, Corgan Labs SDR Training and Development Services http://corganlabs.com <> signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Rx/Tx
Hi all, I'm trying to make a pulse repeater but i don't know how to make it with GnuRadio Companion. I have no knowlodge on USRP and python, I can say i'm really a noob, but I've been able to send and receive the signal but what i want to do is to send the signal and then stop, after a while, send again and stop and so on. Another question is if i want to stop it after 6 times, how can i make it stop? Thanks to all in advance, Kindest Regards. --- António João Matos Gomes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Time Granularity of USRP N2XX
Hi Harry - Actually, the name `tick_rate On Tue, Nov 26, 2013 at 5:49 AM, Harry Zhang wrote: > Dear Marcus, > Thank you for your reply. > I'm confused about two concepts. Referring to the file time_spec.hpp > in UHD, fractional sec is calculated according to the parameter ticks and > tick_rate. So I think the time granularity is '1/tick_rate' which is > 0.1us using 10Mhz clock. But for the timestamp of sample stream, the > granularity is the sample duration. Is it correct? > > Best, > Harry > > 2013/11/26 20:12, Marcus Müller wrote: > >> Hi Harry, >> >> as far as I know, the granularity of a time stamp is the sample duration >> at the downsampled side. >> As for the 10MHz: The 10MHz clock is used to derive different other >> clocks, especially the rx ADC and tx DAC clocks, which are an order of >> magnitude higher; bear in mind that when you request e.g. "5MHz samle rate" >> you still get the 100MHz* samples of the ADC, but downsampled by a factor >> of 20. >> >> Please also bear in mind that due to physics, processing etc the >> timestamp of the rx side is delayed to the actual reception of "that >> sample", and that this delay is largely constant when receiving using the >> same settings, but my change based on sampling rate and other factors. >> >> Greetings >> Marcus >> >> *for USRP2 arch, if I remember correctly. >> On 26.11.2013 13:04, Harry Zhang wrote: >> >>> Hi, >>> Since we can get receive time of rx_stream's first sample via rx tags, I >>> have two questions about the time granularity. Given the internal clock >>> is 10Mhz, is the time granularity 0.1us? The fractional second is stored >>> double type. Does it mean the last digits of the fractional sec are >>> invalid? >>> >>> ___ >>> 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Time Granularity of USRP N2XX
Hi Harry - Actually, the name `tick_rate` is somewhat confusing. The tick_rate refers to the clock rate that the DSP chain runs at. Here is a bit of code regarding the tick_rate from the USRP2 / N-Series implementation that might make things a little more clear: _tree->create(mb_path / "tick_rate") .publish(boost::bind(&usrp2_clock_ctrl::get_master_clock_rate, _mbc[mb].clock)) .subscribe(boost::bind(&usrp2_impl::update_tick_rate, this, _1)); Marcus explained things correctly in his e-mail. So, on an N-Series device, the time step between samples is 1/100e6 = 10 ns. Cheers, Ben On Tue, Nov 26, 2013 at 5:49 AM, Harry Zhang wrote: > Dear Marcus, > Thank you for your reply. > I'm confused about two concepts. Referring to the file time_spec.hpp > in UHD, fractional sec is calculated according to the parameter ticks and > tick_rate. So I think the time granularity is '1/tick_rate' which is > 0.1us using 10Mhz clock. But for the timestamp of sample stream, the > granularity is the sample duration. Is it correct? > > Best, > Harry > > 2013/11/26 20:12, Marcus Müller wrote: > >> Hi Harry, >> >> as far as I know, the granularity of a time stamp is the sample duration >> at the downsampled side. >> As for the 10MHz: The 10MHz clock is used to derive different other >> clocks, especially the rx ADC and tx DAC clocks, which are an order of >> magnitude higher; bear in mind that when you request e.g. "5MHz samle rate" >> you still get the 100MHz* samples of the ADC, but downsampled by a factor >> of 20. >> >> Please also bear in mind that due to physics, processing etc the >> timestamp of the rx side is delayed to the actual reception of "that >> sample", and that this delay is largely constant when receiving using the >> same settings, but my change based on sampling rate and other factors. >> >> Greetings >> Marcus >> >> *for USRP2 arch, if I remember correctly. >> On 26.11.2013 13:04, Harry Zhang wrote: >> >>> Hi, >>> Since we can get receive time of rx_stream's first sample via rx tags, I >>> have two questions about the time granularity. Given the internal clock >>> is 10Mhz, is the time granularity 0.1us? The fractional second is stored >>> double type. Does it mean the last digits of the fractional sec are >>> invalid? >>> >>> ___ >>> 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [GRC] Working Group Call
Hey everyone, to continue (or revive) the discussion on future development of GRC started during the GRCon13 I have scheduled a G+ Hangout on Thursday, December 5 2013, 7pm CET. If you like to discuss/share (your) ideas/visions (and ideally want to help coding) I invite you to join the call. Sebastian -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Sebastian Koslowski Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe, Germany Phone: +49 721 608-46275 Fax: +49 721 608-46071 Email: sebastian.koslow...@kit.edu Web: http://www.cel.kit.edu/ KIT – University of the State of Baden-Wuerttemberg and National Research Center of the Helmholtz Association signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Install: qa_volk_test_all fails on armv7
The volk test is failing on my gnuradio build on a Beaglebone Black
(armv7h) running Arch Linux Arm.
Configuration that failed to enable:
gr-ctrlport *** disabled [do i need this?]
gr-comedi *** disabled [don't need]
gr-qtgui *** disabled [don't need]
gr-documentation *** disabled [don't need]
# make test
start 1: qa_volk_test_all
*** 2 failures detected in test suite "Master Test Suite"1/177 Test #1:
qa_volk_test_all .***Failed9.88 sec
# ctest -V -R qa_volk_test_all | grep error
1: /root/build/gnuradio-git/src/gnuradio/volk/lib/testqa.cc(10): error in
"volk_16ic_s32f_deinterleave_32f_x2_test": check
run_volk_tests(volk_16ic_s32f_deinterleave_32f_x2_get_func_desc(), (void
(*)())volk_16ic_s32f_deinterleave_32f_x2_manual,
std::string("volk_16ic_s32f_deinterleave_32f_x2"), 1e-4, 32768.0, 20462, 1,
0, "NULL") == 0 failed [true != 0]
1: /root/build/gnuradio-git/src/gnuradio/volk/lib/testqa.cc(39): error in
"volk_32fc_s32f_magnitude_16i_test": check
run_volk_tests(volk_32fc_s32f_magnitude_16i_get_func_desc(), (void
(*)())volk_32fc_s32f_magnitude_16i_manual,
std::string("volk_32fc_s32f_magnitude_16i"), 1, 32768, 20462, 1, 0, "NULL")
== 0 failed [true != 0]
Full output of ctest -V _R qa_volk_test_all is attatched.
I'm not really sure how to go from here to diagnose the problem. I'm
building the latest gnuradio git source (packaged by the AUR) on the beagle
bone black via distcc which is cross compiling on my x86_64 desktop with
the same toolchain.
Any advice?
As far as configuration these failed to get enabled:
volk_test_fail
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Install: qa_volk_test_all fails on armv7
On Tue, Nov 26, 2013 at 10:38 AM, Ken Adams wrote:
> The volk test is failing on my gnuradio build on a Beaglebone Black (armv7h)
> running Arch Linux Arm.
>
> Configuration that failed to enable:
> gr-ctrlport *** disabled [do i need this?]
> gr-comedi *** disabled [don't need]
> gr-qtgui *** disabled [don't need]
> gr-documentation *** disabled [don't need]
>
>
> # make test
> start 1: qa_volk_test_all
> *** 2 failures detected in test suite "Master Test Suite"1/177 Test #1:
> qa_volk_test_all .***Failed9.88 sec
>
> # ctest -V -R qa_volk_test_all | grep error
>
> 1: /root/build/gnuradio-git/src/gnuradio/volk/lib/testqa.cc(10): error in
> "volk_16ic_s32f_deinterleave_32f_x2_test": check
> run_volk_tests(volk_16ic_s32f_deinterleave_32f_x2_get_func_desc(), (void
> (*)())volk_16ic_s32f_deinterleave_32f_x2_manual,
> std::string("volk_16ic_s32f_deinterleave_32f_x2"), 1e-4, 32768.0, 20462, 1,
> 0, "NULL") == 0 failed [true != 0]
>
> 1: /root/build/gnuradio-git/src/gnuradio/volk/lib/testqa.cc(39): error in
> "volk_32fc_s32f_magnitude_16i_test": check
> run_volk_tests(volk_32fc_s32f_magnitude_16i_get_func_desc(), (void
> (*)())volk_32fc_s32f_magnitude_16i_manual,
> std::string("volk_32fc_s32f_magnitude_16i"), 1, 32768, 20462, 1, 0, "NULL")
> == 0 failed [true != 0]
>
> Full output of ctest -V _R qa_volk_test_all is attatched.
>
> I'm not really sure how to go from here to diagnose the problem. I'm
> building the latest gnuradio git source (packaged by the AUR) on the beagle
> bone black via distcc which is cross compiling on my x86_64 desktop with the
> same toolchain.
>
> Any advice?
>
> As far as configuration these failed to get enabled:
which version of GNU Radio? These bugs were fixed on Nov. 19 and will
be a part of the 3.7.2.1 release. See bugs #582 and #583 on our Issues
page.
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FTW IEEE802.11a/g/p OFDM Frame Encoder
On 11/25/2013 06:26 PM, nesimi eldarov wrote: ~/gr-ieee802-11/examples$ sudo ./ofdm_tx.py ~/gr-ieee802-11/examples$ sudo ./ofdm_rx.py But there is nothing noticable. Am I doing all correctly? I just pushed the flow graphs with parameters that work out of the box for me. Maybe you want to give them a try... Bastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Sebastian Koslowski as the new GRC submaintainer
With the increased interest in the GNU Radio ecosystem we've been seeing over the past few years, the project is growing nicely and development work, including external contributions, has become a bigger part of the our work load. To help us keep up with the growing project and increased demands on our time as project maintainers, Johnathan, Martin, and I would like to grow the direct community working on the code. We are therefore introducing the concept of sub-maintainers for different aspects of the project maintainership. The sub-maintainers will act as the direct point of contact for bugs and new features to their respective domains. The sub-maintainers will then test, provide feedback, and handle the other intermediate stages before the work is ready to hand off to myself and Johnathan for final review and inclusion into the code. We wanted to officially announce that Sebastian Koslowski has accepted the role of GRC sub-maintainer. He has already been working as the lead of the GRC Working Group that was established at GRCon13. This role change establishes him as the focal point for GRC development and bug fixes. We'd really like to thank Sebastian for his contributions and taking on the added responsibilities of this role. As we believe this will help streamline operations and work on the code base, we are hoping to continue to evolve this idea for other aspects of GNU Radio. Tom, Johnathan, and Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FTW IEEE802.11a/g/p OFDM Frame Encoder
okay, ofdm_tx.grc should transmit when I am Executing it with 'F6', isn't it? That is very weird. I try gr-digital/examples/ofdm$ sudo ./benchmark_tx.py, and works, but ofdm_tx one fails. May be I did not get correctly what you mean with 'pushing with parameters '. Do you set parameters inside the flow graphs? Вторник, 26 ноября 2013, 18:04 +01:00 от Bastian Bloessl : >On 11/25/2013 06:26 PM, nesimi eldarov wrote: > >> ~/gr-ieee802-11/examples$ sudo ./ofdm_tx.py > >> >> ~/gr-ieee802-11/examples$ sudo ./ofdm_rx.py >> >> But there is nothing noticable. >> >> Am I doing all correctly? > >I just pushed the flow graphs with parameters that work out of the box >for me. Maybe you want to give them a try... > >Bastian -- NE ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FTW IEEE802.11a/g/p OFDM Frame Encoder
On 11/26/2013 06:48 PM, nesimi eldarov wrote: okay, ofdm_tx.grc should transmit when I am Executing it with 'F6', isn't it? That is very weird. I try gr-digital/examples/ofdm$ sudo ./benchmark_tx.py, and works, but ofdm_tx one fails. May be I did not get correctly what you mean with 'pushing with parameters '. Do you set parameters inside the flow graphs? I pushed the code to the repository at github.com with gains, frequencies and stuff so that it works without adjusting anything in the GUI. If you want to try it you have to update your repo. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [VOLK] Working Group Call
Greetings, The next VOLK / GPP optimization call will be Dec 12th, same time as most other calls. The Google+ event is here: https://plus.google.com/events/cc0em2d25sbf5hrufpoa6eo6at8 I'll send out a rough agenda before the call. -Nathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] trying to use gdb
Hi, I am using GRC3.6.3 and my program is dying with no verbose. so now i have my core file in my home folder and i cant find the path to the executable. Can someone please tell me the path? Thanks! -- -- Matt D ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] trying to use gdb
nevermind, found it. Thanks! On 11/26/2013 04:31 PM, Matt D wrote: > Hi, > I am using GRC3.6.3 and my program is dying with no verbose. so now i > have my core file in my home folder and i cant find the path to the > executable. Can someone please tell me the path? > Thanks! > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] trying to use gdb
you should be able to run 'gdb python --core=corefilename' you may want to make sure you have compiled gnuradio with -DCMAKE_BUILD_TYPE=RelWithDebInfo for useful symbol tables On 11/26/2013 04:31 PM, Matt D wrote: > Hi, > I am using GRC3.6.3 and my program is dying with no verbose. so now i > have my core file in my home folder and i cant find the path to the > executable. Can someone please tell me the path? > Thanks! > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Performance of 3.7
Hello, I have noticed that if I run the ofdm benchmark_tx.py and benchmark_rx.py programs on both 3.6 and 3.7 versions of gnuradio, I get drastically different performance. I have been using the 3.7 live dvd to evaluate the newer version. When running on 3.6 I can use a bandwidth of 5MHz and the receiver is able to keep up. If I use the same settings on a clean install of 3.7, after a few seconds, the buffers for multiple blocks start to overflow. Also, on 3.6 if I use the top command to observe the CPU usage, I notice that it sits around 500-600% on an i7 machine. On the same machine with 3.7, the program only uses 200-300%. It would appear that for some reason, in 3.7, gnuradio is not making full use of the available processors and thus is unable to keep up with the large sampling rate of 5MHz. If I drop the sampling rate to 500KHz, everything works fine on 3.7. I've used the control port programs to observe the buffers and the runtime graphs and it appears that a lot of time is being taken up by FFT filters. Did something change in 3.7 that would account for the observed differences? Thank you in advance. Regards, Dirk ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Gauging interest for an SDR PA
Given the availability of SDR hardware (USRPs, BladeRF, HackRF, etc) covering VHF through S/C bands, is there any interest in a wide band power amp to complement this hardware? GaN seems to be ubiquitous now, and there are medium power, 48 VDC parts available in low cost SMT packages. So I think it's feasible for something like: 50 MHz - 3 GHz bandwidth Class AB 5 - 30 VDC supply (high efficiency, high frequency boost supply) 10 dBm drive 37 dBm Psat Robust to full mismatch (open/short) Logic level enable ALC with VSWR monitoring (serial, I2C, etc) Small (cigarette pack or smaller) Low cost Open source ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Working examples using GPSDO kit from Ettus
Hi everyone , Can anyone tell me where i can find examples to work with GPSDO kit from Ettus. Thanks in advance Sandhya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gauging interest for an SDR PA
On Tue, Nov 26, 2013 at 9:37 PM, Louis Brown wrote: > Given the availability of SDR hardware (USRPs, BladeRF, HackRF, etc) covering > VHF through S/C bands, is there any interest in a wide band power amp to > complement this hardware? GaN seems to be ubiquitous now, and there are > medium power, 48 VDC parts available in low cost SMT packages. So I think > it's feasible for something like: > > 50 MHz - 3 GHz bandwidth > Class AB > 5 - 30 VDC supply (high efficiency, high frequency boost supply) > 10 dBm drive > 37 dBm Psat > Robust to full mismatch (open/short) > Logic level enable > ALC with VSWR monitoring (serial, I2C, etc) > Small (cigarette pack or smaller) > Low cost > Open source This sounds neat to me. Would you plan on having harmonic filter banks on the input and/or output of the amplifier? How do you think you would tackle the ALC with the different arbitrary bandwidths of the SDR signals? Also, curiously, do you have an efficiency in mind that you want to design for? Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gauging interest for an SDR PA
Hi, > 50 MHz - 3 GHz bandwidth > Class AB > 5 - 30 VDC supply (high efficiency, high frequency boost supply) > 10 dBm drive > 37 dBm Psat > Robust to full mismatch (open/short) > Logic level enable > ALC with VSWR monitoring (serial, I2C, etc) > Small (cigarette pack or smaller) > Low cost > Open source It does sound really neat. However as Brian pointed out, I think on-board filtering would be a must. I'm not even sure if just harmonic filtering is enough. The output of all those SDR isn't necessarily the cleanest from a RF PoV and amplifying that to 37 dBm without paying attention is definitely a bad idea. Combine that with the fact a lot of people buying those newer / cheaper SDR have not much RF experience ( you know, like connecting TX output to RX input directly ) and that could be a recipe for disaster with people broadcasting noise all over. Then of course there is the legality aspect. Although it's pretty easy to fit SDR into the "test equipment" category with their low power output, a PA will definitely not fit. Not much an issue for people building it themselves, but for sale / distribution it could be another matter. Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
