Re: [Discuss-gnuradio] problem with packet decoder for gmsk
Thanks Martin, i tried with replacing uhd with channel model, I had good signal at the receiver after gmsk_demodulator but I'm facing the same problem i.e with packet decoder no out put after here. Even I tried with removing uhd and directly connecting them even though I have the same problem like below shown Random_source=Packet_encoder=gmsk_modulator=rational_resamlper_1=--! ! !-! !-=rational_resampler_2=low_pass_filter=gmsk_demodulator=packet_decoder=scope_sink/file_sink no output/signal after packet decoder,what would be the problem which side I have to concentrate to remove the error. Thank you Ank -- View this message in context: http://gnuradio.4.n7.nabble.com/problem-with-packet-decoder-for-gmsk-tp47218p47278.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] problem with packet decoder for gmsk
Lot of people around here at IIT Bombay also complain that there is no data at the output of packet decoder. Try replacing the random source (binary output) with a signal source(set it to float). And try to plot the output of packet decoder(float output) in a gui sink. That should work, because there exists a working example among GNU Radio example which uses this flow graph. I can't say what is going wrong in your flow graph. But I kind of feel that we need to dig into the implementation of the block to know what is going wrong. Manu. On Fri, Mar 28, 2014 at 11:43 AM, Ank anj...@yahoo.com wrote: Thanks Martin, i tried with replacing uhd with channel model, I had good signal at the receiver after gmsk_demodulator but I'm facing the same problem i.e with packet decoder no out put after here. Even I tried with removing uhd and directly connecting them even though I have the same problem like below shown Random_source=Packet_encoder=gmsk_modulator=rational_resamlper_1=--! ! !-! !-=rational_resampler_2=low_pass_filter=gmsk_demodulator=packet_decoder=scope_sink/file_sink no output/signal after packet decoder,what would be the problem which side I have to concentrate to remove the error. Thank you Ank -- View this message in context: http://gnuradio.4.n7.nabble.com/problem-with-packet-decoder-for-gmsk-tp47218p47278.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 -- Manu T S ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem with packet decoder for gmsk
To expand on Martin's comments, here are some of the issues that *could* be present: - Add a mult_const block or otherwise reduce the amplitude of the i/q signal going to the usrp_sink from +/- 1.0 to 0.5 or 0.7. This ensures you are not non-linear in the transmitter. - tx and rx_gain - if you have these two devices a few feet apart (3-5 dB for both tx and rx should work) - Frequency errors between the two USRP devices (or is this on a single device?) Ultimately, you could include some automatic, course frequency correction - In my experience, the GMSK demod will lock within 100-200 symbols. Since this is a continuous streaming flow graph driven by the random source, transient behaviour shouldn't be an issue. You should have a continuous stream of samples to lock to. So I don't think lock/sync time for the clock recovery is an issue. - Have you changed any parameters on the packet encoder/decoder blocks from the defaults? What is the bit/symbol and samps/symb set to? What's the samps/symbol set to on the gmsk mod and demod? - Instead of a random source, test with a vector source and a known pattern. - To give a quick sanity check on your encoder/decoder config, connect the two *without* any channel. If that doesn't work, you definitely have some config issues. Also, once you're through with this experiment, you might consider using gr-mac, which provides similar functionality. Balint and I have been hacking on it late tonight, you can find the latest here: https://github.com/balint256/gr-mac Also, a known working version that is a bit older and less bleeding edge: https://github.com/jmalsbury/gr-mac http://conferences.sigcomm.org/sigcomm/2013/papers/srif/p31.pdf -John On Thu, Mar 27, 2014 at 1:52 AM, Martin Braun martin.br...@ettus.comwrote: On 03/26/2014 12:30 PM, Ank wrote: Hello all, I'm working on gmsk transmitter and receiver past 6 months , the problem that I'm facing is in the packet decoder. I tried with wav file and signal source it worked good. my block is of this type Random_source=Packet_encoder=gmsk_modulator=rational_resamlper_1=uhd_sink uhd_source=rational_resampler_2=low_pass_filter=gmsk_demodulator=packet_decoder=scope_sink/file_sink There are a lot of things that can go wrong in this setup. Maybe the sync is not locking fast enough, and destroying the preamble. It's hard for us to figure this out from a distance. Try replacing the UHDs with a channel model, and go crazy with that. See what happens. M ___ 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 with packet decoder for gmsk
And here's a flowgraph with some of the recommendations above (attached). -John Malsbury On Fri, Mar 28, 2014 at 12:12 AM, John Malsbury john.malsb...@ettus.comwrote: To expand on Martin's comments, here are some of the issues that *could* be present: - Add a mult_const block or otherwise reduce the amplitude of the i/q signal going to the usrp_sink from +/- 1.0 to 0.5 or 0.7. This ensures you are not non-linear in the transmitter. - tx and rx_gain - if you have these two devices a few feet apart (3-5 dB for both tx and rx should work) - Frequency errors between the two USRP devices (or is this on a single device?) Ultimately, you could include some automatic, course frequency correction - In my experience, the GMSK demod will lock within 100-200 symbols. Since this is a continuous streaming flow graph driven by the random source, transient behaviour shouldn't be an issue. You should have a continuous stream of samples to lock to. So I don't think lock/sync time for the clock recovery is an issue. - Have you changed any parameters on the packet encoder/decoder blocks from the defaults? What is the bit/symbol and samps/symb set to? What's the samps/symbol set to on the gmsk mod and demod? - Instead of a random source, test with a vector source and a known pattern. - To give a quick sanity check on your encoder/decoder config, connect the two *without* any channel. If that doesn't work, you definitely have some config issues. Also, once you're through with this experiment, you might consider using gr-mac, which provides similar functionality. Balint and I have been hacking on it late tonight, you can find the latest here: https://github.com/balint256/gr-mac Also, a known working version that is a bit older and less bleeding edge: https://github.com/jmalsbury/gr-mac http://conferences.sigcomm.org/sigcomm/2013/papers/srif/p31.pdf -John On Thu, Mar 27, 2014 at 1:52 AM, Martin Braun martin.br...@ettus.comwrote: On 03/26/2014 12:30 PM, Ank wrote: Hello all, I'm working on gmsk transmitter and receiver past 6 months , the problem that I'm facing is in the packet decoder. I tried with wav file and signal source it worked good. my block is of this type Random_source=Packet_encoder=gmsk_modulator=rational_resamlper_1=uhd_sink uhd_source=rational_resampler_2=low_pass_filter=gmsk_demodulator=packet_decoder=scope_sink/file_sink There are a lot of things that can go wrong in this setup. Maybe the sync is not locking fast enough, and destroying the preamble. It's hard for us to figure this out from a distance. Try replacing the UHDs with a channel model, and go crazy with that. See what happens. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio gmsk_link_sim.grc Description: application/gnuradio-grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Questions about receiving signals of Inmarsat I-4 Satellites
Hi, I am trying to receive signal from I-4 satellites of Inmarsat. I found that I-4 satellites have one global beam with 25 KHz bandwidth and several regional beams with 50 KHz bandwidth. However, I have scanned through frequency band 1525-1559 MHz and haven't been able to find those beams. Anyone has experience of receiving Inmarsat satellites? Which downlink frequency should I tune to? I have tuned to frequencies listed on this website, still without any luck. http://www.uhf-satcom.com/lband/ Setup: - USRP N210 + WBX - LNA with 30dB gain (ZHL-1217MLN) - Iridium antenna (I am not able to get specific antennas for Inmarsat...Iridium is at 1616 -1626.5 MHz and Inmarsat is at 1525-1559 MHz. I have used this antenna to capture signals around 1531 MHz successfully. I guess this antenna would not kill signals from Inmarsat.) Best regards, Cheng Chi ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PSK File transfer
On 03/27/2014 05:15 PM, Stephen Andrew wrote: File source - throttle - file sink produces no data if repeat is off, and the sent file is small. If the sent file is large, it will produce some data, but not all of it. Removing the throttle doesn't seem to have an effect. For example, I sent a file of 19758 bytes across, and received 16384 bytes on the output. My small file was 407 bytes, and I got 0 bytes on the output. Hm, that's multiples of pages... I see the same thing, though. When I switch off buffering, it's better, although the file doesn't get propagated entirely. And the flow graph doesn't terminate on it's own. Hmm... Maybe a bug with file sink/source? Is the source for those blocks easy to find? Sure, in gr-blocks/lib/file_*. I still maintain that repeat is magical. OK, you got us. We have a genie written into the code that only comes out when repeat is on. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Questions about receiving signals of Inmarsat I-4 Satellites
I intend to make some tests with the antenna of my Inmarsat phone. When the phone receives something, I keep the antenna position and simply will plug the antenna to my SDR to see what happens. But I have no idea when I will find some time for this test… Ralph. From: discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Cheng Chi Sent: Friday, March 28, 2014 9:41 AM To: GNURadio Discussion List Subject: [Discuss-gnuradio] Questions about receiving signals of Inmarsat I-4 Satellites Hi, I am trying to receive signal from I-4 satellites of Inmarsat. I found that I-4 satellites have one global beam with 25 KHz bandwidth and several regional beams with 50 KHz bandwidth. However, I have scanned through frequency band 1525-1559 MHz and haven't been able to find those beams. Anyone has experience of receiving Inmarsat satellites? Which downlink frequency should I tune to? I have tuned to frequencies listed on this website, still without any luck. http://www.uhf-satcom.com/lband/ Setup: - USRP N210 + WBX - LNA with 30dB gain (ZHL-1217MLN) - Iridium antenna (I am not able to get specific antennas for Inmarsat...Iridium is at 1616 -1626.5 MHz and Inmarsat is at 1525-1559 MHz. I have used this antenna to capture signals around 1531 MHz successfully. I guess this antenna would not kill signals from Inmarsat.) Best regards, Cheng Chi ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] output operand requires a reduction, but reduction is not enabled
Hi Martin, Sorry for the very slow reply. Life is hectic here! I found that if I removed the SNR input, that provides many few inputs that the other (its an SNR value *per packet*, so there is only 1 input item to this for every 768 to the other input), the output buffer increases to Out_bA1.shape(512,) Est_bA1m.shape(3840,) Len(out_bA1) = 512 So the output buffer seems dominated by the input that has fewer items coming in??? I managed to resolve the problem completely by changing Ninput_items_required[i] = noutput_items/pow(2,13) In 'forecast', perhaps there are more elegant solutions, but this seems to work fine (there is only one output). Regards, David -Original Message- From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org [mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] On Behalf Of Martin Braun Sent: 12 March 2014 08:54 To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] output operand requires a reduction, but reduction is not enabled On 11.03.2014 17:10, David Halls wrote: Hi, Yes, the len(output_items[0]), is either 1 or 2... If I set_output_multiple to 10, then this value raises to 10. Can you post the entire block code? M It is dominated by the fact that one of the inputs to my block is much lower than the other?? Input[0] is the data stream and has say 768 items, input[1] is the packet average SNR, so it only has 1 or 2 items in the same period. Forecast is currently For I in range (len(ninput_items_required)): Ninput_items_required[i] = noutput_items Does this need to be altered for my case where I have two inputs with very different requirements. If I ever get my head around the scheduler in GNU radio, it will be a happy day :) D -Original Message- From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org [mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] On Behalf Of Martin Braun Sent: 11 March 2014 15:27 To: discuss-gnuradio@gnu.org mailto:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] output operand requires a reduction, but reduction is not enabled On 03/11/2014 04:24 PM, David Halls wrote: Please see the papers we've submitted so far this year. Not exactly WNC, yet... We're putting one together as we speak though. I am not sure I understand your reply fully... Len(out_bA1) is only 1 or 2, so I can only set one or two elements? Is this before or after you assign something? What's len(output_items[0])? How can I extend the length of out_bA1, so I can output all of est_bA1m? You can't, not in the work function. You can do things like set_output_multiple() to influence the size of the output buffer. Or alternatively Is it possible for me to set output_items[0][0:len(est_bA1m)] = est_bA1m That would work, if len(est_bA1m) len(output_items[0]) AND they have the right shape (in matrix terms). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl http://www.toshiba.eu/research/trl -- -- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com -- -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl --- This email has been scanned for email related threats and delivered safely by
Re: [Discuss-gnuradio] GIT checkout of Gnu Radio failed!
Yes , I tried it again it works :)
Thanks Tom , Volker Nathan .
I ran gnuradio in terminal after installing I see there is no problem in
it
sara@ubuntu:~/gnuradio$ gnuradio-companion
Warning: Block key blocks_ctrlport_monitor_performance not found when
loading category tree.
Warning: Block key blocks_ctrlport_monitor_performance not found when
loading category tree.
linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.007.000-53-g6962543f
Welcome to GNU Radio Companion 3.7.3
Showing:
BUT when installing it , after 3 hours of installation , I got an output
which shows that GNURADIO_CORE GRUEL LIBRARIES are not found ! is there
a problem , or these libraries are not important ? Do I have to uninstall
install again?!
also it is saying : You will not be able to access your USRP1 device until
you do this .. I will use B100 B200 , is there any problem ? Any
problem will occur when using my usrps?!
also it is saying : You should probably set your PYTHONPATH to:
/usr/local/lib/python2.7/dist-packages Using:
export PYTHONPATH=/usr/local/lib/python2.7/dist-packages in your .bashrc
or equivalent file prior to attempting to run
any Gnu Radio applications or Gnu Radio Companion.
what is the importance to do that ,as I ran gnuradio now ? I found a
.bashrc file in home directory , is this the meant file? I will copy paste
export PYTHONPATH=/usr/local/lib/python2.7/dist-packages to the end of
file , tell me if this is not right.
Thanks
Here is the output in terminal during installation:
Starting function extras at: Fri Mar 28 18:20:28 EET 2014
mv: cannot stat `gr-baz': No such file or directory
Doing GIT checkout for extra module gr-baz
Cloning into 'gr-baz'...
remote: Reusing existing pack: 1101, done.
remote: Total 1101 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (1101/1101), 798.65 KiB | 51 KiB/s, done.
Resolving deltas: 100% (579/579), done.
Building extra module gr-baz
-- The CXX compiler identification is GNU
-- The C compiler identification is GNU
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Build type not specified: defaulting to release.
-- Boost version: 1.48.0
-- Found the following Boost libraries:
-- system
-- thread
-- checking for module 'gruel'
-- package 'gruel' not found
-- Could NOT find GRUEL (missing: GRUEL_LIBRARIES GRUEL_INCLUDE_DIRS)
-- checking for module 'gnuradio-core'
-- package 'gnuradio-core' not found
-- Could NOT find GNURADIO_CORE (missing: GNURADIO_CORE_LIBRARIES
GNURADIO_CORE_INCLUDE_DIRS)
CMake Error at CMakeLists.txt:135 (message):
Gruel required to compile baz
-- Configuring incomplete, errors occurred!
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target `install'. Stop.
mv: cannot stat `grextras': No such file or directory
Doing GIT checkout for extra module grextras
Cloning into 'grextras'...
remote: Reusing existing pack: 4066, done.
remote: Total 4066 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (4066/4066), 4.50 MiB | 55 KiB/s, done.
Resolving deltas: 100% (1996/1996), done.
Building extra module grextras
-- The CXX compiler identification is GNU
-- The C compiler identification is GNU
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Build type not specified: defaulting to release.
-- Boost version: 1.48.0
-- checking for module 'volk'
-- found volk, version 0.1
-- Found VOLK: /usr/local/lib/libvolk.so
-- checking for module 'gruel'
-- package 'gruel' not found
-- Could NOT find GRUEL (missing: GRUEL_LIBRARIES GRUEL_INCLUDE_DIRS)
-- checking for module 'gnuradio-core'
-- package 'gnuradio-core' not found
-- Could NOT find GNURADIO_CORE (missing: GNURADIO_CORE_LIBRARIES
GNURADIO_CORE_INCLUDE_DIRS)
CMake Error at CMakeLists.txt:112 (message):
Gruel required to compile extras
-- Configuring incomplete, errors occurred!
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target `install'. Stop.
Done function extras at: Fri Mar 28 18:22:31 EET 2014
Starting function mod_groups at: Fri Mar 28 18:22:31 EET 2014
This script has just modified /etc/group to place your userid '('$USER')'
into group 'usrp'
In order for this change to take effect, you will need to log-out and log
back
in again. You will not be able to access your USRP1 device until you
Re: [Discuss-gnuradio] Solution for SegFault with Lock / Unlock in 3.7 C++
I am using Boost 1.53, on Ubuntu 13.10 via apt-get. When I was running it under GnuRadio 3.6, I think I was running Boost 1.49, but it got upgrade because I think it is not compatible with GR 3.7? Would it be worth it to try build from source for Boost 1.48 or 1.55? On Fri, Mar 28, 2014 at 12:54 PM, Tim Newman tim.new...@gmail.com wrote: What version of boost are you using? Tim On Fri, Mar 28, 2014 at 12:45 PM, Luke Berndt luk...@gmail.com wrote: I was wondering if there has been any progress or work arounds for Bug 598 in 3.7? http://gnuradio.org/redmine/issues/598 The issue is the GnuRadio will segfault if there are too many Lock / Unlocks. I am having it happen after 6 - 10 lock/unlocks. My program is a C++ program that records trunked radio calls and I need to be able to dynamically connect / disconnect recording flowgraphs as new calls are started. The program works fine under 3.6. I was wondering if there are any work arounds I should try. I have tried using tb-stop, tb-wait, tb-start, but it still crashes. Is there some other way to dynmically connect disconnect blocks that doesn't require lock / unlock? Is there an ETA when this would be fixed? Anything I can help on? I am going to have to go back to 3.6 if I can't figure out a solution. Thanks! - Luke ___ 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] Solution for SegFault with Lock / Unlock in 3.7 C++
What version of boost are you using? Tim On Fri, Mar 28, 2014 at 12:45 PM, Luke Berndt luk...@gmail.com wrote: I was wondering if there has been any progress or work arounds for Bug 598 in 3.7? http://gnuradio.org/redmine/issues/598 The issue is the GnuRadio will segfault if there are too many Lock / Unlocks. I am having it happen after 6 - 10 lock/unlocks. My program is a C++ program that records trunked radio calls and I need to be able to dynamically connect / disconnect recording flowgraphs as new calls are started. The program works fine under 3.6. I was wondering if there are any work arounds I should try. I have tried using tb-stop, tb-wait, tb-start, but it still crashes. Is there some other way to dynmically connect disconnect blocks that doesn't require lock / unlock? Is there an ETA when this would be fixed? Anything I can help on? I am going to have to go back to 3.6 if I can't figure out a solution. Thanks! - Luke ___ 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] Solution for SegFault with Lock / Unlock in 3.7 C++
I was wondering if there has been any progress or work arounds for Bug 598 in 3.7? http://gnuradio.org/redmine/issues/598 The issue is the GnuRadio will segfault if there are too many Lock / Unlocks. I am having it happen after 6 - 10 lock/unlocks. My program is a C++ program that records trunked radio calls and I need to be able to dynamically connect / disconnect recording flowgraphs as new calls are started. The program works fine under 3.6. I was wondering if there are any work arounds I should try. I have tried using tb-stop, tb-wait, tb-start, but it still crashes. Is there some other way to dynmically connect disconnect blocks that doesn't require lock / unlock? Is there an ETA when this would be fixed? Anything I can help on? I am going to have to go back to 3.6 if I can't figure out a solution. Thanks! - Luke ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GIT checkout of Gnu Radio failed!
Yes , I tried it again it works :)
Thanks Tom , Volker Nathan .
I ran gnuradio in terminal after installing I see there is no
problem in it
sara@ubuntu:~/gnuradio$ gnuradio-companion
Warning: Block key blocks_ctrlport_monitor_performance not found
when loading category tree.
Warning: Block key blocks_ctrlport_monitor_performance not found
when loading category tree.
linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.007.000-53-g6962543f
Welcome to GNU Radio Companion 3.7.3
Showing:
BUT when installing it , after 3 hours of installation , I got an
output which shows that GNURADIO_CORE GRUEL LIBRARIES are not found
! is there a problem , or these libraries are not important ? Do I
have to uninstall install again?!
also it is saying : You will not be able to access your USRP1 device
until you do this .. I will use B100 B200 , is there any
problem ? Any problem will occur when using my usrps?!
also it is saying : You should probably set your PYTHONPATH to:
/usr/local/lib/python2.7/dist-packages Using:
export PYTHONPATH=/usr/local/lib/python2.7/dist-packages in your
.bashrc or equivalent file prior to attempting to run
any Gnu Radio applications or Gnu Radio Companion.
what is the importance to do that ,as I ran gnuradio now ? I found a
.bashrc file in home directory , is this the meant file? I will copy
paste export PYTHONPATH=/usr/local/lib/python2.7/dist-packages to
the end of file , tell me if this is not right.
Thanks
Here is the output in terminal during installation:
Starting function extras at: Fri Mar 28 18:20:28 EET 2014
mv: cannot stat `gr-baz': No such file or directory
Doing GIT checkout for extra module gr-baz
Cloning into 'gr-baz'...
remote: Reusing existing pack: 1101, done.
remote: Total 1101 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (1101/1101), 798.65 KiB | 51 KiB/s, done.
Resolving deltas: 100% (579/579), done.
Building extra module gr-baz
-- The CXX compiler identification is GNU
-- The C compiler identification is GNU
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Build type not specified: defaulting to release.
-- Boost version: 1.48.0
-- Found the following Boost libraries:
-- system
-- thread
-- checking for module 'gruel'
-- package 'gruel' not found
-- Could NOT find GRUEL (missing: GRUEL_LIBRARIES GRUEL_INCLUDE_DIRS)
-- checking for module 'gnuradio-core'
-- package 'gnuradio-core' not found
-- Could NOT find GNURADIO_CORE (missing: GNURADIO_CORE_LIBRARIES
GNURADIO_CORE_INCLUDE_DIRS)
CMake Error at CMakeLists.txt:135 (message):
Gruel required to compile baz
-- Configuring incomplete, errors occurred!
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target `install'. Stop.
mv: cannot stat `grextras': No such file or directory
Doing GIT checkout for extra module grextras
Cloning into 'grextras'...
remote: Reusing existing pack: 4066, done.
remote: Total 4066 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (4066/4066), 4.50 MiB | 55 KiB/s, done.
Resolving deltas: 100% (1996/1996), done.
Building extra module grextras
-- The CXX compiler identification is GNU
-- The C compiler identification is GNU
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Build type not specified: defaulting to release.
-- Boost version: 1.48.0
-- checking for module 'volk'
-- found volk, version 0.1
-- Found VOLK: /usr/local/lib/libvolk.so
-- checking for module 'gruel'
-- package 'gruel' not found
-- Could NOT find GRUEL (missing: GRUEL_LIBRARIES GRUEL_INCLUDE_DIRS)
-- checking for module 'gnuradio-core'
-- package 'gnuradio-core' not found
-- Could NOT find GNURADIO_CORE (missing: GNURADIO_CORE_LIBRARIES
GNURADIO_CORE_INCLUDE_DIRS)
CMake Error at CMakeLists.txt:112 (message):
Gruel required to compile extras
-- Configuring incomplete, errors occurred!
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target `install'. Stop.
Done function extras at: Fri Mar 28 18:22:31 EET 2014
Starting function mod_groups at: Fri Mar 28 18:22:31 EET 2014
This script has just modified /etc/group to place your userid
'('$USER')' into group 'usrp'
In order for this change to take effect, you will need to log-out and
log back
in again. You will not be able to access your
Re: [Discuss-gnuradio] linking Gnuradio and Gpredict ?
I just found a good starting point. This program uses hamlib, a library that is often used to control rigs and antenna rotors and that is supported by GPredict: http://james.ahlstrom.name/hamlib.html I just tested it and GPredict connects well to localhost:4575. The server programs output shows the proper doppler corrected frequencies etc. As it is python it can probably converted into a GRC block. 73 Mark On 28/03/14 14:47, rajesh kd wrote: Hi, Can you explain in detail regarding querying the Gpredict for doppler corrected freq. using UDP, since I novice to UDP. If possible,, can you please post the relevant code. Rajesh -- View this message in context: http://gnuradio.4.n7.nabble.com/linking-Gnuradio-and-Gpredict-tp42620p47286.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] Solution for SegFault with Lock / Unlock in 3.7 C++
I was thinking the older version of boost had a bug in the boost thread stuff that was causing this, but boost 1.53 should be fine. On Fri, Mar 28, 2014 at 1:09 PM, Luke Berndt luk...@gmail.com wrote: I am using Boost 1.53, on Ubuntu 13.10 via apt-get. When I was running it under GnuRadio 3.6, I think I was running Boost 1.49, but it got upgrade because I think it is not compatible with GR 3.7? Would it be worth it to try build from source for Boost 1.48 or 1.55? On Fri, Mar 28, 2014 at 12:54 PM, Tim Newman tim.new...@gmail.com wrote: What version of boost are you using? Tim On Fri, Mar 28, 2014 at 12:45 PM, Luke Berndt luk...@gmail.com wrote: I was wondering if there has been any progress or work arounds for Bug 598 in 3.7? http://gnuradio.org/redmine/issues/598 The issue is the GnuRadio will segfault if there are too many Lock / Unlocks. I am having it happen after 6 - 10 lock/unlocks. My program is a C++ program that records trunked radio calls and I need to be able to dynamically connect / disconnect recording flowgraphs as new calls are started. The program works fine under 3.6. I was wondering if there are any work arounds I should try. I have tried using tb-stop, tb-wait, tb-start, but it still crashes. Is there some other way to dynmically connect disconnect blocks that doesn't require lock / unlock? Is there an ETA when this would be fixed? Anything I can help on? I am going to have to go back to 3.6 if I can't figure out a solution. Thanks! - Luke ___ 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] linking Gnuradio and Gpredict ?
Hi, Can you explain in detail regarding querying the Gpredict for doppler corrected freq. using UDP, since I novice to UDP. If possible,, can you please post the relevant code. Rajesh -- View this message in context: http://gnuradio.4.n7.nabble.com/linking-Gnuradio-and-Gpredict-tp42620p47286.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] linking Gnuradio and Gpredict ?
If all you need is something in python you can just use pyephem http://rhodesmill.org/pyephem/ Alex On Fri, Mar 28, 2014 at 6:33 PM, M Dammer i...@mdammer.net wrote: I just found a good starting point. This program uses hamlib, a library that is often used to control rigs and antenna rotors and that is supported by GPredict: http://james.ahlstrom.name/hamlib.html I just tested it and GPredict connects well to localhost:4575. The server programs output shows the proper doppler corrected frequencies etc. As it is python it can probably converted into a GRC block. 73 Mark On 28/03/14 14:47, rajesh kd wrote: Hi, Can you explain in detail regarding querying the Gpredict for doppler corrected freq. using UDP, since I novice to UDP. If possible,, can you please post the relevant code. Rajesh -- View this message in context: http://gnuradio.4.n7.nabble.com/linking-Gnuradio-and-Gpredict-tp42620p47286.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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CSI in gr-ieee80211
Which device did you used for receiving samples? I have noticed a same phenomenon with my device, caused by a coarse implementation of a high pass filter. On 03/26/2014 04:08 PM, Bastian Bloessl wrote: On 26 Mar 2014, at 15:05, alex alexleeresea...@gmail.com wrote: I am currently working on gr-ieee80211. Now I want to use the long preamble to estimate the CSI. However, after I apply fft to the long preamble, I found the power for each channel is not the same. I took an average over lots of packets. The power near the middle sub-carriers are always very lower than on the edges. I would like to ask if it is because the Power spectral density in the transmitter or some other reasons. If your sample rate is 20MHz you will see an uncompensated filter, but in that case the power of the subcarriers in the center should be higher. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- /* Code is the Law! */ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Check The output of a block input captured frames to GNURadio
I want to make a test and see the output , I put 3 blocks , vector source , throttle and vector sink . I edited the vector parameter in vector source block to (6,6). All 3 blocks have a type byte. I generated the flow graph. I moved to the directory of grc file , I wrote in terminal vim top_block.py then I write to the end of file : print tb.blocks_vector_sink_x_0.data() and saved the changes . Then I execute the python file by writing in terminal : ./top_block.py But the output takes too long time and doesn't appear ! what is the problem ? and is there any other method to see the output ???As I am a beginner and someone told me this method. I tried this for example 10 times but every time it takes too long and doesn't appear , only one time it appears! Another question : If I have captured some frames using wireshark (from twinkle softphone), and I saved them .I want to make them an input to ofdm transmitter . How to make them an input? Thanks :) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Check The output of a block input captured frames to GNURadio
I found that tb.wait() is written in the file so it takes too long time .
Now after I erased tb.wait() .. the output on terminal is --- ( ) .. I
don't know why ?? Here is what is written in top_block.py
#!/usr/bin/env python
##
# Gnuradio Python Flow Graph
# Title: Top Block
# Generated: Sat Mar 29 01:47:01 2014
##
from gnuradio import blocks
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from grc_gnuradio import wxgui as grc_wxgui
from optparse import OptionParser
import wx
class top_block(grc_wxgui.top_block_gui):
def __init__(self):
grc_wxgui.top_block_gui.__init__(self, title=Top Block)
_icon_path = /usr/share/icons/hicolor/32x32/apps/gnuradio-grc.png
self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY))
##
# Variables
##
self.samp_rate = samp_rate = 32000
##
# Blocks
##
self.blocks_vector_source_x_0 = blocks.vector_source_b((6, 6),
True, 1, [])
self.blocks_vector_sink_x_0 = blocks.vector_sink_b(1)
self.blocks_throttle_0 = blocks.throttle(gr.sizeof_char*1,
samp_rate,True)
##
# Connections
##
self.connect((self.blocks_vector_source_x_0, 0),
(self.blocks_throttle_0, 0))
self.connect((self.blocks_throttle_0, 0),
(self.blocks_vector_sink_x_0, 0))
4,1 Top
# QT sink close method reimplementation
def get_samp_rate(self):
return self.samp_rate
def set_samp_rate(self, samp_rate):
self.samp_rate = samp_rate
self.blocks_throttle_0.set_sample_rate(self.samp_rate)
if __name__ == '__main__':
import ctypes
import sys
if sys.platform.startswith('linux'):
try:
x11 = ctypes.cdll.LoadLibrary('libX11.so')
x11.XInitThreads()
except:
print Warning: failed to XInitThreads()
parser = OptionParser(option_class=eng_option, usage=%prog: [options])
(options, args) = parser.parse_args()
tb = top_block()
tb.Start(True)
print tb.blocks_vector_sink_x_0.data()
2014-03-29 0:06 GMT+02:00 Sara Chérif saracheri...@gmail.com:
I want to make a test and see the output , I put 3 blocks , vector source
, throttle and vector sink . I edited the vector parameter in vector
source block to (6,6). All 3 blocks have a type byte. I generated the
flow graph.
I moved to the directory of grc file , I wrote in terminal
vim top_block.py
then I write to the end of file : print tb.blocks_vector_sink_x_0.data()
and saved the changes . Then I execute the python file by writing in
terminal :
./top_block.py
But the output takes too long time and doesn't appear ! what is the
problem ?
and is there any other method to see the output ???As I am a beginner and
someone told me this method.
I tried this for example 10 times but every time it takes too long and
doesn't appear , only one time it appears!
Another question :
If I have captured some frames using wireshark (from twinkle softphone),
and I saved them .I want to make them an input to ofdm transmitter . How
to make them an input?
Thanks :)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Questions about receiving signals of Inmarsat I-4 Satellites
1531 MHz signals from what? If you are using a patch antenna then it probably won't have the bandwidth to cover 100 MHz. Lou KD4HSO Cheng Chi wrote - Iridium antenna (I am not able to get specific antennas for Inmarsat...Iridium is at 1616 -1626.5 MHz and Inmarsat is at 1525-1559 MHz. I have used this antenna to capture signals around 1531 MHz successfully. I guess this antenna would not kill signals from Inmarsat.) Best regards, Cheng Chi -- View this message in context: http://gnuradio.4.n7.nabble.com/Questions-about-receiving-signals-of-Inmarsat-I-4-Satellites-tp47282p47298.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
