[Discuss-gnuradio] How to tell Flowgraph to Stop in Work()?

[Ghost Op]

I'm working on a module in C++ and when a condition happens I want my
work function to signal to the flowgraph to stop.

I saw some references for python to self._top_block but does anyone
have a suggestion on how to do it in C++?

Thanks!

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] CMake error related to log4cpp in non-standard location

[Bastian Bloessl]

Hi,

are you talking about building in-tree modules or OOTs?

On 04/28/2017 11:13 PM, Michael Dickens wrote:
> Hi Eugene - What you write looks to be true about the current GR
> codebase. Bastian Bloessl has a commit that adds in LOG4CPP_INCLUDE_DIR
> & related to those in-tree areas that need it (branch "ugly_cmake"): <
> https://github.com/bastibl/gnuradio/commit/16d8e8cb9bd658991dabbc253c74850248b80f83
>> .  I don't know the best solution, but it seems like there's got to be
> a better way than manually including variables for logging as done right
> now. Cheers! - MLD

This branch was supposed to demonstrate what ugly cmake stuff we would
have to add if we don't add the includes of dependencies to a module's
exported includes.

To avoid this mess, we added LOG4CPP_INCLUDE_DIRS to
GNURADIO_RUNTIME_INCLUDE_DIRS, which should be added by all modules:

https://github.com/gnuradio/gnuradio/pull/1195/commits/51e565532f1f867baacc004222971fcf3703773b

That means the problem should be fixed for in-tree modules and the
ugly_cmake branch should be obsolete. If you have problems in-tree
please let me know which module doesn't compile.

A similar mechanism should, in my opinion, also be adopted for OOT
modules. Currently, GNURADIO_ALL_INCLUDE_DIRS (which is set by
find_package(gnuradio)) do not include the folders of its dependencies
(i.e., the headers references from the public includes, like log4cpp).

For that reason it is currently not possible to compile OOTs with
non-standard log4cpp location. You would have to patch the module (add
findlog4cpp.cmake and configure the patch appropriately).

See the discussion here:
https://github.com/gnuradio/gnuradio/issues/1045

Best,
Bastian

> 
> On Fri, Apr 28, 2017, at 02:46 PM, Eugene Grayver wrote:
>> The current GR CMakeFile(s) apparently do not add the include path 
>> LOG4CPP_INCLUDE_DIR to the compile.  Can't build w/ log4cpp in non-standard 
>> location.
> 
> ___
> 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] CMake error related to log4cpp in non-standard location

[Michael Dickens]

Hi Eugene - What you write looks to be true about the current GR
codebase. Bastian Bloessl has a commit that adds in LOG4CPP_INCLUDE_DIR
& related to those in-tree areas that need it (branch "ugly_cmake"): <
https://github.com/bastibl/gnuradio/commit/16d8e8cb9bd658991dabbc253c74850248b80f83
>.  I don't know the best solution, but it seems like there's got to be
a better way than manually including variables for logging as done right
now. Cheers! - MLD

On Fri, Apr 28, 2017, at 02:46 PM, Eugene Grayver wrote:
> The current GR CMakeFile(s) apparently do not add the include path 
> LOG4CPP_INCLUDE_DIR to the compile.  Can't build w/ log4cpp in non-standard 
> location.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Which block for Fast PSK demodulation under some doppler shift?

[Dan CaJacob]

That's fine for low rate stuff, but for Mehmeto's application, he probably
needs to be more coherent.  Correlating on a preamble would be a good idea,
I think.

On Fri, Apr 28, 2017 at 9:04 AM Vitt Benv  wrote:

> Hi Mehmeto,
> in my opinion and in my experience with LEO sats, it's usefull to retune
> the receiver using doppler correction info coming from external app.
> In the past I used to query old beloved Predict via socket to control a
> ICOM PR1000 receiver with a little utility that I wrote ( google "pcrsat" ).
> It worked fine to demodulated 1200BPSK or CW telemetry also on heavy
> doppler (ovehead pass).
>
> Ciao,
> Victor
>
>
> 2017-04-28 13:40 GMT+02:00 Mehmeto :
>
>> Dear All,
>>  I have a situation where I need to demodulate a wide bandwidth signal (70
>> Mbps QPSK modulated, having 35 MHz IF bandwidth and sampled at 105 MSPS )
>> in
>> our lab. However, the signal generator will also add some amount of
>> doppler
>> shift at a rate of 1 kHz/s. Which PSK demodulation blocks are suitable for
>> fast demodulation under some doppler shift. I
>>  I know that I can not use the Costas Loop or any other block that uses a
>> feedback loop because of their speed limitations.
>>  I am considering to add a preamble to simplify things since I know high
>> speed Satellite downlinks use Preamble. I guess the use of preambles make
>> demodulation easier.
>>
>> Please advise.
>>
>>
>>
>> --
>> View this message in context:
>> http://gnuradio.4.n7.nabble.com/Which-block-for-Fast-PSK-demodulation-under-some-doppler-shift-tp63700.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
>
-- 
Very Respectfully,

Dan CaJacob
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] CMake error related to log4cpp in non-standard location

[Eugene Grayver]

The current GR CMakeFile(s) apparently do not add the include path 
LOG4CPP_INCLUDE_DIR to the compile.  Can't build w/ log4cpp in non-standard 
location.





Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Image transfer simulation

[Sagnik Basu]

Hi.

I am trying to simulate an image transfer flowgraph in gnu radio.Here is
the link to the GRC file:

https://github.com/sagniknitr/my_GNURadio/tree/master/image%20transfer

The problem is I am always getting 0 bytes in the jpeg file mentioned in
the file sink block.What am I doing wrong here?

Regards,
Sagnik Basu
B. Tech | 2013-2017
Dept. of Electronics and Communication
NIT Rourkela
M: 8337942928
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error building gr-burst in Ubuntu 16.04 and Volk 1.2.1

[West, Nathan]

This was fixed a while ago. Use VOLK version 1.2.3 or 1.3.

On Fri, Apr 28, 2017 at 8:34 AM, katutxakurra  wrote:

> Hi,
> I'm trying to compile gr-burst and I'm getting an error. I've opened an
> issue in Github but I'm hoping to get a wider audience here.
> https://github.com/gr-vt/gr-burst
>
> I'm using Ubuntu 16.04 with GNURadio 3.7.9, Volk 1.2.1, SWIG 3.0.8 and
> libgsl2 2.1.
> I have installed python-bitarray and build/install gr-mapper.
> In gr-burst, I made
> cmake CMakeLists.txt
> There are some warnings about policies and not finding gsl-config.
> user@pc ~/s/g/gr-burst> make
> [ 4%] Building CXX object lib/CMakeFiles/gnuradio-burst.
> dir/interp_cpdu_impl.cc.o
> [ 8%] Building CXX object lib/CMakeFiles/gnuradio-burst.
> dir/correlator_filter_impl.cc.o
> [ 12%] Building CXX object lib/CMakeFiles/gnuradio-burst.
> dir/length_detect_c_impl.cc.o
> /home/usr/src/gnuradio/gr-burst/lib/length_detect_c_impl.cc: In member
> function ‘void gr::burst::length_detect_c_impl::handler(pmt::pmt_t)’:
> /home/user/src/gnuradio/gr-burst/lib/length_detect_c_impl.cc:105:67:
> error: cannot convert ‘uint16_t* {aka short unsigned int*}’ to ‘unsigned
> int*’ in argument passing
> volk_32f_index_max_16u(_idx, [0], magavg.size());
> ^
> lib/CMakeFiles/gnuradio-burst.dir/build.make:110: recipe for target
> 'lib/CMakeFiles/gnuradio-burst.dir/length_detect_c_impl.cc.o' failed
> make[2]: *** [lib/CMakeFiles/gnuradio-burst.dir/length_detect_c_impl.cc.o]
> Error 1
> CMakeFiles/Makefile2:137: recipe for target 
> 'lib/CMakeFiles/gnuradio-burst.dir/all'
> failed
> make[1]: *** [lib/CMakeFiles/gnuradio-burst.dir/all] Error 2
> Makefile:138: recipe for target 'all' failed
> make: *** [all] Error 2
> It looks like the error is with Volk and similar to the one described here
> git-artes/gr-isdbt#18 
>
> Does anyone know how could I fix or work around this problem?
>
>
> ___
> 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] PFB Clock Recovery Block (#1)

[Ghost Op]

Thanks Marucs for pointing it out.  Hadn't noticed.  Will do.


Hey Ghost,

um, could you please not take the list into CC when replying to github
issue discussions? It's pretty confusing.

Best regards,

Marcus

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [ghostop14/gr-clenabled] PFB Clock Recovery Block (#1)

[Marcus Müller]

Hey Ghost,

um, could you please not take the list into CC when replying to github
issue discussions? It's pretty confusing.

Best regards,

Marcus


On 28.04.2017 16:07, GhostOp14 wrote:
> I was just looking at that tutorial for something else.  May take me a
> couple weeks to dig into it but I'll tackle that one next and see what
> I can do with it.
>
> -- Forwarded message --
> From: *sdrgpu*  >
> Date: Fri, Apr 28, 2017 at 9:51 AM
> Subject: Re: [ghostop14/gr-clenabled] PFB Clock Recovery Block (#1)
> To: ghostop14/gr-clenabled  >
> Cc: Subscribed  >
>
>
> https://wiki.gnuradio.org/index.php/Guided_Tutorial_PSK_Demodulation#7.6.1._Details_of_the_PFB_Clock_Recovery_Block
> 
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> ,
> or mute the thread
> .
>
>
>
>
> ___
> 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] [ghostop14/gr-clenabled] PFB Clock Recovery Block (#1)

[GhostOp14]

I was just looking at that tutorial for something else.  May take me a
couple weeks to dig into it but I'll tackle that one next and see what I
can do with it.

-- Forwarded message --
From: sdrgpu 
Date: Fri, Apr 28, 2017 at 9:51 AM
Subject: Re: [ghostop14/gr-clenabled] PFB Clock Recovery Block (#1)
To: ghostop14/gr-clenabled 
Cc: Subscribed 


https://wiki.gnuradio.org/index.php/Guided_Tutorial_PSK_
Demodulation#7.6.1._Details_of_the_PFB_Clock_Recovery_Block

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
,
or mute the thread

.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] CorrectIQ 2.0

[Ghost Op]

Hi everyone, been a busy week on OOT modules.  While working on some
other signal decodes I made a number of enhancements in the CorrectIQ
OOT module.  First, doing some testing I was seeing inconsistencies in
the plotted waveforms due to inheriting from "block" instead of
sync_block so that was fixed across all the modules.

There's also 2 new blocks in the group.  One that does an auto-sense
on the offset at the given frequency and gain then switches to to a
straight DC offset mode to prevent any sense of "filtering" being
applied to the signal due to the averaging.  (Thanks to Ron Economos
for turning me on to this technique!)  If you adjust frequency or gain
upstream the block will automatically recalibrate and you can
configure the recalibration time.  You can let it calibrate without
the antenna connected and settle then connect it or just do it with
the live input.

The other block is a manual offset block.  It's just a glorified
"complex Add Const" but it makes it a bit straightforward in the
flowgraph to follow by calling out the offsets in the GUI.

I also added a new example GRC with all of the blocks that can be used
to do comparisons.

Enjoy!

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [ghostop14/gr-clenabled] PFB Clock Recovery Block (#1)

[GhostOp14]

I can definitely take a look at it.  Is it the block that comes up as
"Polyphase Clock Sync" in the block search?

-- Forwarded message --
From: sdrgpu 
Date: Fri, Apr 28, 2017 at 8:28 AM
Subject: [ghostop14/gr-clenabled] PFB Clock Recovery Block (#1)
To: ghostop14/gr-clenabled 
Cc: Subscribed 


Could you add the PFB Clock Recovery Block from GNU RADIO. It contains a
lot of filters which can be paralellized.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
, or mute the thread

.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Which block for Fast PSK demodulation under some doppler shift?

[Vitt Benv]

Hi Mehmeto,
in my opinion and in my experience with LEO sats, it's usefull to retune
the receiver using doppler correction info coming from external app.
In the past I used to query old beloved Predict via socket to control a
ICOM PR1000 receiver with a little utility that I wrote ( google "pcrsat" ).
It worked fine to demodulated 1200BPSK or CW telemetry also on heavy
doppler (ovehead pass).

Ciao,
Victor


2017-04-28 13:40 GMT+02:00 Mehmeto :

> Dear All,
>  I have a situation where I need to demodulate a wide bandwidth signal (70
> Mbps QPSK modulated, having 35 MHz IF bandwidth and sampled at 105 MSPS )
> in
> our lab. However, the signal generator will also add some amount of doppler
> shift at a rate of 1 kHz/s. Which PSK demodulation blocks are suitable for
> fast demodulation under some doppler shift. I
>  I know that I can not use the Costas Loop or any other block that uses a
> feedback loop because of their speed limitations.
>  I am considering to add a preamble to simplify things since I know high
> speed Satellite downlinks use Preamble. I guess the use of preambles make
> demodulation easier.
>
> Please advise.
>
>
>
> --
> View this message in context: http://gnuradio.4.n7.nabble.
> com/Which-block-for-Fast-PSK-demodulation-under-some-
> doppler-shift-tp63700.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] Volk functions in OOT on Mac

[Michael Dickens]

Hi Vamsi - it looks like you're not linking with Volk directly; indirect
linking (via one of the GR libraries) doesn't work. Check out any of the
various OOT modules that do that linking for specifics. - MLD
On Fri, Apr 28, 2017 at 12:12 AM, vamsi krishna wrote:
> 
> I get the following error when I use Volk function in OOT block.
> 
> ---
> [  4%] *Linking CXX shared library libgnuradio-fsk_demod.dylib*
> cd /Users/vamsi/Documents/workspace/spectrum_sc2/comp1/collaboration_-
> dev/vamsi/gr_modules/gr-fsk_demod/build/lib && /opt/local/bin/cmake -E
> cmake_link_script CMakeFiles/gnuradio-fsk_demod.dir/link.txt --
> verbose=1> 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xc-
> toolchain/usr/bin/c++ -O3 -DNDEBUG -dynamiclib -Wl,-
> headerpad_max_install_names  -o libgnuradio-fsk_demod.dylib -
> install_name /opt/local/lib/libgnuradio-fsk_demod.dylib CMakeFiles/gnuradio-
> fsk_demod.dir/fsk_detector_impl.cc.o CMakeFiles/gnuradio-
> fsk_demod.dir/elp_timing_recov_impl.cc.o CMakeFiles/gnuradio-
> fsk_demod.dir/quad_demod_ins_impl.cc.o CMakeFiles/gnuradio-
> fsk_demod.dir/iq_imbal_correct_impl.cc.o CMakeFiles/gnuradio-
> fsk_demod.dir/logagc_cc_impl.cc.o  -L/opt/local/lib -Wl,-
> rpath,/opt/local/lib /opt/local/lib/libboost_filesystem-mt.dylib 
> /opt/local/lib/libboost_system-
> mt.dylib /opt/local/lib/libgnuradio-runtime.dylib /opt/local/lib/libgnuradio-
> pmt.dylib> Undefined symbols for architecture x86_64:
>   "_volk_32f_accumulator_s32f", referenced from:
> 
>   gr::fsk_demod::elp_timing_recov_impl::general_work(int,
>   std::__1::vector&,
>   std::__1::vector
>   >&, std::__1::vector >&) in
>   elp_timing_recov_impl.cc.o> ---
> 
> I use GNURadio on Mac, installed using Macports. Volk is installed
> [header file is included so compilation goes through alright, but
> linking fails.]> 
> Macport versions:
> 
> gnuradio-devel @20170423   science/gnuradio
> volk   @1.3science/volk
> 
> ---Code
> 
> 
> #include 
> 
> 
>   volk_32f_accumulator_s32f(_mf_out, _mf_reg[0], d_sps);
> --
> 
> Shouldn't volk function be used with new GNURadio(This block worked in
> 3.7.2ish version)? If not, should some other option be passed during
> compilation time?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Error building gr-burst in Ubuntu 16.04 and Volk 1.2.1

[katutxakurra]

Hi,I'm trying to compile gr-burst and I'm getting an error. I've opened an 
issue in Github but I'm hoping to get a wider audience 
here.https://github.com/gr-vt/gr-burst
I'm using Ubuntu 16.04 with GNURadio 3.7.9, Volk 1.2.1, SWIG 3.0.8 and libgsl2 
2.1.
I have installed python-bitarray and build/install gr-mapper.In gr-burst, I made
cmake CMakeLists.txtThere are some warnings about policies and not finding 
gsl-config.user@pc ~/s/g/gr-burst> make
[ 4%] Building CXX object 
lib/CMakeFiles/gnuradio-burst.dir/interp_cpdu_impl.cc.o
[ 8%] Building CXX object 
lib/CMakeFiles/gnuradio-burst.dir/correlator_filter_impl.cc.o
[ 12%] Building CXX object 
lib/CMakeFiles/gnuradio-burst.dir/length_detect_c_impl.cc.o
/home/usr/src/gnuradio/gr-burst/lib/length_detect_c_impl.cc: In member function 
‘void gr::burst::length_detect_c_impl::handler(pmt::pmt_t)’:
/home/user/src/gnuradio/gr-burst/lib/length_detect_c_impl.cc:105:67: error: 
cannot convert ‘uint16_t* {aka short unsigned int*}’ to ‘unsigned int*’ in 
argument passing
volk_32f_index_max_16u(_idx, [0], magavg.size());
^
lib/CMakeFiles/gnuradio-burst.dir/build.make:110: recipe for target 
'lib/CMakeFiles/gnuradio-burst.dir/length_detect_c_impl.cc.o' failed
make[2]: *** [lib/CMakeFiles/gnuradio-burst.dir/length_detect_c_impl.cc.o] 
Error 1
CMakeFiles/Makefile2:137: recipe for target 
'lib/CMakeFiles/gnuradio-burst.dir/all' failed
make[1]: *** [lib/CMakeFiles/gnuradio-burst.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2It looks like the error is with Volk and similar to the 
one described here
git-artes/gr-isdbt#18
Does anyone know how could I fix or work around this problem?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRC sheet size

[Dave NotTelling]

If you want to change the default size you can look in
/usr/local/etc/gnuradio/conf.d/grc.conf and change the line
`canvas_default_size = 1280, 1024`.  The path might be different on your
system.  You can run `find / -name grc.conf 2>/dev/null` to hunt it down.

On Fri, Apr 28, 2017 at 5:05 AM, Sebastian Müller  wrote:

> In the „Options“ Block, there is a parameter named „Canvas Size“. Enter
> there WIDTH, HEIGHT, e.g. "1280, 1024“.
>
> Regards,
>
> Sebastian Müller
> gse...@gmail.com
>
> Am 28. April 2017 um 08:56:42, Fernando (ferna...@samara.com.es) schrieb:
>
> Is it possible to change the "sheet size" in GRC?
>
> I'm working on a big diagram and it does not fit well.
>
>
> regards
>
>
>
> ___
> 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] Which block for Fast PSK demodulation under some doppler shift?

[Mehmeto]

Dear All,
 I have a situation where I need to demodulate a wide bandwidth signal (70
Mbps QPSK modulated, having 35 MHz IF bandwidth and sampled at 105 MSPS ) in
our lab. However, the signal generator will also add some amount of doppler
shift at a rate of 1 kHz/s. Which PSK demodulation blocks are suitable for
fast demodulation under some doppler shift. I 
 I know that I can not use the Costas Loop or any other block that uses a
feedback loop because of their speed limitations.
 I am considering to add a preamble to simplify things since I know high
speed Satellite downlinks use Preamble. I guess the use of preambles make
demodulation easier.

Please advise.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Which-block-for-Fast-PSK-demodulation-under-some-doppler-shift-tp63700.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] Integration of ofdm_txrx and uhd

[Amarja Vaidya]

Hello,

I am having some communication reliability problems with
'benchmark_tx/rx.py' files. I came to know that these files are outdated
and one should use 'ofdm_txrx.py' instead. As 'ofdm_txrx.py' uses sync
words unlike benchmark files (or modules connected to
'benchmark_tx/rx.py'), I hope it will work better. But I could not find on
the internet how to use 'ofdm_txrx.py'. However, I found 'qa_ofdm_txrx.py',
that demonstrates the its use.
Since I am using USRPs, I want to connect 'ofdm_txrx' to 'uhd' and
therefore I modified 'qa_ofdm_txrx.py'. I replaced vector sink in the class
'ofdm_tx_fg' with 'uhd_transmitter' from und_interface.py, which internally
creates uhd sink. Now when I execute 'test_001_tx', I do not see any data
being transmitted on uhd_fft.

How can I get this to work? Am I missing anything?

Some details: I am using USRP N310 at 2.45GHz and 1MHz bandwidth(I get
overruns if I use higher bandwidth).

Thanks in advance.

-- 
*Best Regards,*
*Amarja Vaidya.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRC sheet size

[Sebastian Müller]

In the „Options“ Block, there is a parameter named „Canvas Size“. Enter
there WIDTH, HEIGHT, e.g. "1280, 1024“.

Regards,

Sebastian Müller
gse...@gmail.com

Am 28. April 2017 um 08:56:42, Fernando (ferna...@samara.com.es) schrieb:

Is it possible to change the "sheet size" in GRC?

I'm working on a big diagram and it does not fit well.


regards



___
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] Ofdm rx_time and packet error rate

[Tschuls Lebarski]

Hi All,

First of all: I'm a newbee

I'm into the example of gr-digital: rx_ofdm.grc and tx_ofdm.gr.
I have 2 Questions:

1. My goal is to check the time between 2 recieved packets. I realized that
the TAG_DEBUG-Block outputs some rx_Time.
 Offset: 1035  Source: n/a Key: rx_time   Value: {2523 0.455868}
 From the documentation I saw that unit 2523 is seconds and 0.455868 is a
fraction of a second.
Does that mean: 2523s and 455.868ms?

2. I want to calculate the recieved packages in order do have a
comparisson: packets send to packets recieved.
I found out that i can limit data with the head block.
Can someone explain me how to calculate how many packets arrived correctly
or is there a certain block counting the recieved packets?

Thanks a lot in advance
Julian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GRC sheet size

[Fernando]

Is it possible to change the "sheet size" in GRC?

I'm working on a big diagram and it does not fit well.


regards



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio