[Discuss-gnuradio] gnuradio compiles no more on my computer, cannot figure out why

[Lecoq Yann]

Hello and a happy new year to all,

I used to compile gnuradio and uhd from git repos on a ubuntu 14.04 computer 
and, for whatever reason, the gnuradio compilation don't work anymore. There 
must be something I modified in the config that triggered that, but I can't 
figure out what (I started wanting to to recompile in order to activate comedi 
after installing the libcomedi-dev package, but wether this one is installed or 
nt dosnt help).

Typically I do a uhd cmake, make -j8, sudo make install and sudo ldconfig 
(which all look like they still work fine), and, then, a gnuradio cmake, make 
-j8, sudo make install and sudo ldconfig. Now, the gnuradio make stops with an 
error which looks related to the gr-uhd/swig component (see the console output 
at the end of this message). 

To be sure, I used git to compile different combination of commits for both uhd 
and gnuradio, including at least 1 uhd+gnuradio commit combination which I am 
absolutely certain works on another similar computer, but it didn't help. I 
also tried removing entirely the source code in my ~/src directory and 
restarting from scrach (after some apt-get autoremove, update and upgrade) with 
M. Leech's "build_gnuradio" script, but this failed as well at the same point. 
Note that the check of prerequisites at the beginning of the script doesn't 
report anything missing though (except a usual libzmq1 issue which has never 
been a problem) (see end of message).

Any help is greatly appreciated, as I am running out of ideas to check at this 
point...

Best wishes,

-Yann



*** CONSOLE OUTPUT NEAR GNURADIO MAKING ERROR ***
Scanning dependencies of target _wxgui_swig
[ 57%] Building CXX object 
gr-wxgui/swig/CMakeFiles/_wxgui_swig.dir/wxgui_swigPYTHON_wrap.cxx.o
[ 57%] Built target pygen_gr_wavelet_swig_57e27
[ 57%] Building CXX object 
gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/file_sink_impl.cc.o
[ 57%] Building CXX object 
gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/file_source_impl.cc.o
/home/zbook_user/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: In 
function ‘void init_uhd_swig()’:
/home/zbook_user/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:46579:91:
 error: ‘ATR_REG_IDLE’ is not a member of ‘uhd::usrp::dboard_iface’
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_IDLE",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface::ATR_REG_IDLE)));

   ^
/home/zbook_user/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:46580:94:
 error: ‘ATR_REG_TX_ONLY’ is not a member of ‘uhd::usrp::dboard_iface’
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_TX_ONLY",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface::ATR_REG_TX_ONLY)));

  ^
/home/zbook_user/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:46581:94:
 error: ‘ATR_REG_RX_ONLY’ is not a member of ‘uhd::usrp::dboard_iface’
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_RX_ONLY",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface::ATR_REG_RX_ONLY)));

  ^
/home/zbook_user/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:46582:98:
 error: ‘ATR_REG_FULL_DUPLEX’ is not a member of ‘uhd::usrp::dboard_iface’
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_FULL_DUPLEX",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface::ATR_REG_FULL_DUPLEX)));

  ^
[ 57%] Building CXX object 
gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/file_meta_sink_impl.cc.o
make[2]: *** [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o] 
Erreur 1
make[1]: *** [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all] Erreur 2



*** CONSOLE OUTPUT FOR BUILD-GNURADIO PREREQS SCRIPT
Installing prerequisites.
> THIS MAY TAKE QUITE SOME TIME <=
Checking for package libfontconfig1-dev
Checking for package libxrender-dev
Checking for package libpulse-dev
Checking for package swig
Checking for package g++
Checking for package automake
Checking for package autoconf
Checking for package libtool
Checking for package python-dev
Checking for package libfftw3-dev
Checking for package libcppunit-dev
Checking for package libboost-all-dev
Checking for package libusb-dev
Checking for package libusb-1.0-0-dev
Checking for package fort77
Checking for package libsdl1.2-dev
Checking for package python-wxgtk2.8
Checking for package git-core
Checking for package libqt4-dev
Checking for package python-numpy
Checking for package ccache
Checking for package python-opengl
Checking for package libgsl0-dev
Checking for package python-cheetah
Checking for package python-mako
Checking for package python-lxml
Checking for package doxygen
Checking for package qt4-default
Checking for package 

Re: [Discuss-gnuradio] gnuradio compiles no more on my computer, cannot figure out why

[Marcus Müller]

Hi Yann,

this looks familiar; there was someone else with pretty exactly the same
problem, and the underlying complication was that there were two
installations of UHD header files.
Make sure only one UHD is installed, and try again.

Best regards,
Marcus

On 06.01.2016 12:50, Lecoq Yann wrote:
> Hello and a happy new year to all,
>
> I used to compile gnuradio and uhd from git repos on a ubuntu 14.04 computer 
> and, for whatever reason, the gnuradio compilation don't work anymore. There 
> must be something I modified in the config that triggered that, but I can't 
> figure out what (I started wanting to to recompile in order to activate 
> comedi after installing the libcomedi-dev package, but wether this one is 
> installed or nt dosnt help).
>
> Typically I do a uhd cmake, make -j8, sudo make install and sudo ldconfig 
> (which all look like they still work fine), and, then, a gnuradio cmake, make 
> -j8, sudo make install and sudo ldconfig. Now, the gnuradio make stops with 
> an error which looks related to the gr-uhd/swig component (see the console 
> output at the end of this message). 
>
> To be sure, I used git to compile different combination of commits for both 
> uhd and gnuradio, including at least 1 uhd+gnuradio commit combination which 
> I am absolutely certain works on another similar computer, but it didn't 
> help. I also tried removing entirely the source code in my ~/src directory 
> and restarting from scrach (after some apt-get autoremove, update and 
> upgrade) with M. Leech's "build_gnuradio" script, but this failed as well at 
> the same point. Note that the check of prerequisites at the beginning of the 
> script doesn't report anything missing though (except a usual libzmq1 issue 
> which has never been a problem) (see end of message).
>
> Any help is greatly appreciated, as I am running out of ideas to check at 
> this point...
>
> Best wishes,
>
> -Yann
>
>
>
> *** CONSOLE OUTPUT NEAR GNURADIO MAKING ERROR ***
> Scanning dependencies of target _wxgui_swig
> [ 57%] Building CXX object 
> gr-wxgui/swig/CMakeFiles/_wxgui_swig.dir/wxgui_swigPYTHON_wrap.cxx.o
> [ 57%] Built target pygen_gr_wavelet_swig_57e27
> [ 57%] Building CXX object 
> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/file_sink_impl.cc.o
> [ 57%] Building CXX object 
> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/file_source_impl.cc.o
> /home/zbook_user/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: In 
> function ‘void init_uhd_swig()’:
> /home/zbook_user/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:46579:91:
>  error: ‘ATR_REG_IDLE’ is not a member of ‘uhd::usrp::dboard_iface’
>SWIG_Python_SetConstant(d, 
> "dboard_iface_ATR_REG_IDLE",SWIG_From_int(static_cast< int 
> >(uhd::usrp::dboard_iface::ATR_REG_IDLE)));
>   
>  ^
> /home/zbook_user/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:46580:94:
>  error: ‘ATR_REG_TX_ONLY’ is not a member of ‘uhd::usrp::dboard_iface’
>SWIG_Python_SetConstant(d, 
> "dboard_iface_ATR_REG_TX_ONLY",SWIG_From_int(static_cast< int 
> >(uhd::usrp::dboard_iface::ATR_REG_TX_ONLY)));
>   
> ^
> /home/zbook_user/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:46581:94:
>  error: ‘ATR_REG_RX_ONLY’ is not a member of ‘uhd::usrp::dboard_iface’
>SWIG_Python_SetConstant(d, 
> "dboard_iface_ATR_REG_RX_ONLY",SWIG_From_int(static_cast< int 
> >(uhd::usrp::dboard_iface::ATR_REG_RX_ONLY)));
>   
> ^
> /home/zbook_user/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:46582:98:
>  error: ‘ATR_REG_FULL_DUPLEX’ is not a member of ‘uhd::usrp::dboard_iface’
>SWIG_Python_SetConstant(d, 
> "dboard_iface_ATR_REG_FULL_DUPLEX",SWIG_From_int(static_cast< int 
> >(uhd::usrp::dboard_iface::ATR_REG_FULL_DUPLEX)));
>   
> ^
> [ 57%] Building CXX object 
> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/file_meta_sink_impl.cc.o
> make[2]: *** [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o] 
> Erreur 1
> make[1]: *** [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all] Erreur 2
>
>
>
> *** CONSOLE OUTPUT FOR BUILD-GNURADIO PREREQS SCRIPT
> Installing prerequisites.
> > THIS MAY TAKE QUITE SOME TIME <=
> Checking for package libfontconfig1-dev
> Checking for package libxrender-dev
> Checking for package libpulse-dev
> Checking for package swig
> Checking for package g++
> Checking for package automake
> Checking for package autoconf
> Checking for package libtool
> Checking for package python-dev
> Checking for package libfftw3-dev
> Checking for package libcppunit-dev
> Checking for package libboost-all-dev
> Checking for package libusb-dev
> Checking for package libusb-1.0-0-dev
> 

[Discuss-gnuradio] Questions about USRP source retune via messages

[Meelis Nõmm]

Hello everyone,

I have been testing USRP (N200) source retuning via messages. The idea was
to see how fast the USRP can retune reliably. Also looked at the
usrp_spectrum_sense
but as Marcus pointed out in [1]

that example is old and newer solutions should be used and I figured the
command messages would be a good choice.

As I have a marine VHF radio available then I chose to operate around
156.025MHz, 1kHz steps till 156.055MHz (30 steps, then loop),
samp_rate=1MHz. To confirm the SDR recorded output is reasonable, I
transmit a constant carrier and check the signal in Octave. Overall I think
I got it working, but every now and then the retuning gets stuck (from the
output I can see that the USRP does not retune and after a certain time
rapidly starts to process the expired commands until catches up).

Decided to dig deeper and to see if the issue is directly coupled with the
message generation process. Decided to look at the time diff between
consecutive function calls and from there the time diff between consecutive
work() calls. The outcome was quite surprising for me. It seems that once
the messages are delivered to the USRP source (I thought that it would be
better to send a number of command messages ahead in time to the usrp), the
flow of the samples is halted (work function is not called for a time
period that is directly related to the time ahead in the commands). Seems
the flowgraph waits till the messages are processed. Is this intended, have
I misunderstood the command messages? I thought the command messages to the
usrp source can be used as timed commands that have a queue.

In general, even with a single message the retune works with 12.5ms
dwell_delay. However, the flowgraph stalls for around 0.15sec nearly every
5sec. Tested also with just analog_sig_source - throttle - measuring_block
- null_sink, and the 5sec period is still there. In the measuring block I
use a monotonic clock from boost. What causes this? Can it be avoided?

With regards,
Meelis


[1]
https://lists.gnu.org/archive/html/discuss-gnuradio/2015-08/msg00035.html
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio compiles no more on my computer, cannot figure out why

[Lecoq Yann]

Hi Marcus,

You were right, a thorough cleaning of everything uhd related solved the issue,

Thanks for your help !

-Yann
 
 
Le Mercredi 6 Janvier 2016 13:37 CET, Marcus Müller  
a écrit: 
 
> Hi Yann,
> 
> this looks familiar; there was someone else with pretty exactly the same
> problem, and the underlying complication was that there were two
> installations of UHD header files.
> Make sure only one UHD is installed, and try again.
> 
> Best regards,
> Marcus
> 
> On 06.01.2016 12:50, Lecoq Yann wrote:
> > Hello and a happy new year to all,
> >
> > I used to compile gnuradio and uhd from git repos on a ubuntu 14.04 
> > computer and, for whatever reason, the gnuradio compilation don't work 
> > anymore. There must be something I modified in the config that triggered 
> > that, but I can't figure out what (I started wanting to to recompile in 
> > order to activate comedi after installing the libcomedi-dev package, but 
> > wether this one is installed or nt dosnt help).
> >
> > Typically I do a uhd cmake, make -j8, sudo make install and sudo ldconfig 
> > (which all look like they still work fine), and, then, a gnuradio cmake, 
> > make -j8, sudo make install and sudo ldconfig. Now, the gnuradio make stops 
> > with an error which looks related to the gr-uhd/swig component (see the 
> > console output at the end of this message). 
> >
> > To be sure, I used git to compile different combination of commits for both 
> > uhd and gnuradio, including at least 1 uhd+gnuradio commit combination 
> > which I am absolutely certain works on another similar computer, but it 
> > didn't help. I also tried removing entirely the source code in my ~/src 
> > directory and restarting from scrach (after some apt-get autoremove, update 
> > and upgrade) with M. Leech's "build_gnuradio" script, but this failed as 
> > well at the same point. Note that the check of prerequisites at the 
> > beginning of the script doesn't report anything missing though (except a 
> > usual libzmq1 issue which has never been a problem) (see end of message).
> >
> > Any help is greatly appreciated, as I am running out of ideas to check at 
> > this point...
> >
> > Best wishes,
> >
> > -Yann
> >
> >
> >
> > *** CONSOLE OUTPUT NEAR GNURADIO MAKING ERROR ***
> > Scanning dependencies of target _wxgui_swig
> > [ 57%] Building CXX object 
> > gr-wxgui/swig/CMakeFiles/_wxgui_swig.dir/wxgui_swigPYTHON_wrap.cxx.o
> > [ 57%] Built target pygen_gr_wavelet_swig_57e27
> > [ 57%] Building CXX object 
> > gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/file_sink_impl.cc.o
> > [ 57%] Building CXX object 
> > gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/file_source_impl.cc.o
> > /home/zbook_user/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: In 
> > function ‘void init_uhd_swig()’:
> > /home/zbook_user/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:46579:91:
> >  error: ‘ATR_REG_IDLE’ is not a member of ‘uhd::usrp::dboard_iface’
> >SWIG_Python_SetConstant(d, 
> > "dboard_iface_ATR_REG_IDLE",SWIG_From_int(static_cast< int 
> > >(uhd::usrp::dboard_iface::ATR_REG_IDLE)));
> > 
> >^
> > /home/zbook_user/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:46580:94:
> >  error: ‘ATR_REG_TX_ONLY’ is not a member of ‘uhd::usrp::dboard_iface’
> >SWIG_Python_SetConstant(d, 
> > "dboard_iface_ATR_REG_TX_ONLY",SWIG_From_int(static_cast< int 
> > >(uhd::usrp::dboard_iface::ATR_REG_TX_ONLY)));
> > 
> >   ^
> > /home/zbook_user/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:46581:94:
> >  error: ‘ATR_REG_RX_ONLY’ is not a member of ‘uhd::usrp::dboard_iface’
> >SWIG_Python_SetConstant(d, 
> > "dboard_iface_ATR_REG_RX_ONLY",SWIG_From_int(static_cast< int 
> > >(uhd::usrp::dboard_iface::ATR_REG_RX_ONLY)));
> > 
> >   ^
> > /home/zbook_user/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:46582:98:
> >  error: ‘ATR_REG_FULL_DUPLEX’ is not a member of ‘uhd::usrp::dboard_iface’
> >SWIG_Python_SetConstant(d, 
> > "dboard_iface_ATR_REG_FULL_DUPLEX",SWIG_From_int(static_cast< int 
> > >(uhd::usrp::dboard_iface::ATR_REG_FULL_DUPLEX)));
> > 
> >   ^
> > [ 57%] Building CXX object 
> > gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/file_meta_sink_impl.cc.o
> > make[2]: *** 
> > [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o] Erreur 1
> > make[1]: *** [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all] Erreur 2
> >
> >
> >
> > *** CONSOLE OUTPUT FOR BUILD-GNURADIO PREREQS SCRIPT
> > Installing prerequisites.
> > > THIS MAY TAKE QUITE SOME TIME <=
> > Checking for package libfontconfig1-dev
> > Checking for package libxrender-dev
> 

Re: [Discuss-gnuradio] gmsk+fec

[Tom Rondeau]

On Tue, Jan 5, 2016 at 7:56 AM, Ekko  wrote:

> hello tom
> i replace the  with the ,just like
>
>



>
> and i am using the Dummy Encoder and Dummy Decoder
>
> but ,i got
> Traceback (most recent call last):
>   File "/home/cdl/gmsk_fec/gmsk_fec.py", line 236, in 
> tb = gmsk_fec()
>   File "/home/cdl/gmsk_fec/gmsk_fec.py", line 83, in __init__
> self.fec_generic_encoder_0 = fec.encoder(enc_dummy, gr.sizeof_char,
> gr.sizeof_char)
>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/fec/fec_swig.py",
> line 894, in make
> return _fec_swig.encoder_make(*args, **kwargs)
> TypeError: in method 'encoder_make', argument 1 of type
> 'gr::fec::generic_encoder::sptr'
>
>
> 2->i open the "ber_curve_gen.grc"
>
> but there is an error
>
 ​

You can find all of the FEC alist files installed into
$prefix/share/gnuradio/fec/ldpc. Use that to locate and set that file name
properly.

Tom





thank you
>
> --Ekko
> ​
>
> 2016-01-04 22:58 GMT+08:00 Tom Rondeau :
>
>> On Tue, Dec 29, 2015 at 11:24 AM, Ekko  wrote:
>>
>>> hello bob
>>> this problem have been solved,now my fec is worked
>>> but i got a new problem
>>> this is my fec+gmsk grc
>>> http://i.imgur.com/ZH2qhh6.png
>>>
>>> and this is my gmsk without fec
>>> http://i.imgur.com/zJVskUX.png
>>>
>>> when i run these two grc,i got a similar value of ser
>>>
>>> i think that in the way of gmsk,i will got a error rate value
>>>  smaller than the single gmsk,but i did not got it,
>>> so i think there is somethin wrong in my grc,hope someone who can help
>>> me to check my grc ,or give me sone instruction about the using of fec.
>>>
>>> thank you
>>>
>>> --Ekko
>>>
>>
>>
>> Ekko,
>>
>> It might be worth using the exact same graph for both tests but use the
>> Dummy Encoder and Dummy Decoder variables for the FEC codes. These are just
>> pass-through "codes" that allow you to easily use the same structure with
>> and without any actual coding.
>>
>> Also, you should run "ber_curve_gen.grc" that comes as an example with
>> gr-fec. This will give you an idea of what kind of BER correction you
>> should expect for the different codes.
>>
>> Tom
>>
>>
>>
>>
>>> 2015-12-29 13:15 GMT+08:00 bob wole :
>>>
 Ekko,

 Add a Tag debug block after your packet encoder and see if there are
 any tags coming out of it. I think packet encoder is not passing your tag.
 If that is the case, move your stream to tagged stream block after the
 packet encoder just before the FEC extended tagged encoder. Hope it helps.


 --
 Bob


>
> this is the address of picture
>
> http://imgur.com/2EQiY6O
>
> sorry to send two e-mails
>
>
>
>

>>>
>>> ___
>>> 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] About Polymorphic types in gnuradio

[Marcus Müller]

Hi Gabriel,

do you know what kind of PMT VECT is? pmt_t is a container, and might
contain a lot of different things.
Is it a pmt::vector, or a pmt::uniform_vector, or a list, or something else?

For an overview, I'd like to point you to the polymorphic types page in
the GNU Radio manual [1].

Best regards,
Marcus

[1] https://gnuradio.org/doc/doxygen/page_pmt.html

On 06.01.2016 16:10, Gabriel Pechiarovich wrote:
> Hi, I've been working in oot modules in gnuradio for a while, but
> recently I've been trying to program blocks who can handle messages.
>
> I've extracted the input data and replicated it at the output, like this:
>
> pmt::pmt_t META = pmt::car(PDU);
> pmt::pmt_t VECT = pmt::cdr(PDU);
> std::cout << "Vect: " << VECT<< '\n';
> message_port_pub(pmt::mp("out_pdu"), pmt::cons(META, VECT));
>
> But I can't understand how to handle VECT, I want to change the VECT
> values; add some values, basicaly operate this VECT.
>
> If anyone can help me I'll be gratefull.
>
> -- 
> Gabriel Pechiarovich Salas
>
>
>
> ___
> 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] Installation of gr-video-sdl for GNU Radio Companion 3.7.10git-31-gb17bcb88

[Tom Rondeau]

On Tue, Jan 5, 2016 at 11:35 AM,  wrote:

> Hello/Happy New Year!
>
> I'm in need of using my USRP to receive NTSC (Analog TV). I installed
> gnuradio via pybombs and I noticed that under
> /target/share/gnuradio/examples/uhd there is a python script called
> usrp_tv_rcv.py however when running the script I get the message
> "gr-video-sdl" is not installed I can also see this in the code when doing
> an import.  Using pybombs I confirmed this is not installed. I did read
> older messages but cannot get a sense of how to install this. It is under
> /pybombs/src/gnuradio... but being a newbie I'm stuck as to what to do
> next. Any help would be appreciated and any comments as to using
> usrp_tv_rcv to receive analog TV are also welcome.
>
> Thanks,
> Jon
>


Hi Jon,

Currently, PyBOMBS doesn't support installing gr-video-sdl itself. It's a
fairly obscure package (in GR terms) and rarely used. Basically, you'll
need to install libsdl1.2-dev (I think that should be all), but there's no
PyBOMBS recipe for this.

For your case, I would just install this package by hand through your
package manager, then clean the PyBOMBS installation of gnuradio and try
again. With the libsdl1.2-dev installed, GNU Radio should pick up on it and
build gr-video-sdl for you.

In Debian/Ubuntu, just use:
$ sudo apt-get install libsdl1.2-dev

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

[Discuss-gnuradio] problem with custom RFNoC block output in GRC

[Jason Matusiak]

I am having some issues with a custom RFNoC block output when trying to
run my python script.  My block takes in a complex int 16, and outputs a
complex int 16 as well as a "byte".  The byte is really a 32b value that
the receiving end will use to convert to a float.  This is a follow on
from a previous GRC conversation I had here [1].

Right now I am testing my pass-through of the complex data (to get my
axi flags working right), so I don't even care about the byte data, but
it is what is giving me issues...

So based on the previous thread, I have an RFNoC GRC block that has an
output of a "byte", but I am attempting to put 32b through it.  I've
tried passing that through a RFNoC: FIFO to a File Sink, as well as just
going from the block to a Null Sink, neither are working.  When I got
straight to a Null Sink, I get the following:
Traceback (most recent call last):
  File "time_sync.py", line 160, in 
main()
  File "time_sync.py", line 148, in main
tb = top_block_cls()
  File "time_sync.py", line 117, in __init__
self.connect((self.uhd_rfnoc_streamer_time_sync_0, 1),
(self.blocks_null_sink_0, 0))
  File
"/home/jason/target/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
line 47, in wrapped
func(self, src, src_port, dst, dst_port)
  File
"/home/jason/target/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
line 110, in connect
self.primitive_connect(*args)
  File
"/home/jason/target/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
line 4569, in primitive_connect
return _runtime_swig.top_block_sptr_primitive_connect(self, *args)
ValueError: itemsize mismatch: uhd_rfnoc_TimeSync0:1 using 8,
null_sink0:0 using 1
Segmentation fault (core dumped)


OK, makes sense, it says that I have 8B coming out of the TimeSync0:1,
but the null is expecting 1.  So I go into the python script and change
the following line:
self.blocks_null_sink_0 = blocks.null_sink(gr.sizeof_char*1)
to:
self.blocks_null_sink_0 = blocks.null_sink(gr.sizeof_char*8)

and now I get the output:
Traceback (most recent call last):
  File "time_sync.py", line 160, in 
main()
  File "time_sync.py", line 149, in main
tb.start()
  File
"/home/jason/target/lib/python2.7/dist-packages/gnuradio/gr/top_block.py",
line 109, in start
top_block_start_unlocked(self._impl, max_noutput_items)
  File
"/home/jason/target/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
line 4876, in top_block_start_unlocked
return _runtime_swig.top_block_start_unlocked(*args, **kwargs)
RuntimeError: uhd_rfnoc_TimeSync(1): missing connection from output port
0


This doesn't make sense to me as the following is in my pythonscript:
self.blocks_null_sink_0 = blocks.null_sink(gr.sizeof_char*8)
self.blocks_file_source_0_0 =
blocks.file_source(gr.sizeof_gr_complex*1,
"/home/jason/reducedInput.txt", False)
self.blocks_file_sink_0 =
blocks.file_sink(gr.sizeof_gr_complex*1, "/tmp/complexData.txt", False)
self.blocks_file_sink_0.set_unbuffered(False)

##
# Connections
##
self.connect((self.blocks_file_source_0_0, 0),
(self.uhd_rfnoc_streamer_fifo_0, 0))
self.connect((self.uhd_rfnoc_streamer_fifo_1, 0),
(self.blocks_file_sink_0, 0))
self.connect((self.uhd_rfnoc_streamer_time_sync_0, 1),
(self.blocks_null_sink_0, 0))
   
self.device3.connect(self.uhd_rfnoc_streamer_fifo_0.get_block_id(), 0,
self.uhd_rfnoc_streamer_time_sync_0.get_block_id(), 0)
   
self.device3.connect(self.uhd_rfnoc_streamer_time_sync_0.get_block_id(),
0, self.uhd_rfnoc_streamer_fifo_1.get_block_id(), 0)  


What am I missing here?  I assume I am doing something stupid somewhere
or am following Martin's plan for me in [1] incorrectly

[1]
https://lists.gnu.org/archive/html/discuss-gnuradio/2015-12/msg00098.html

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

[Discuss-gnuradio] About Polymorphic types in gnuradio

[Gabriel Pechiarovich]

Hi, I've been working in oot modules in gnuradio for a while, but recently
I've been trying to program blocks who can handle messages.

I've extracted the input data and replicated it at the output, like this:

pmt::pmt_t META = pmt::car(PDU);
pmt::pmt_t VECT = pmt::cdr(PDU);
std::cout << "Vect: " << VECT<< '\n';
message_port_pub(pmt::mp("out_pdu"), pmt::cons(META, VECT));

But I can't understand how to handle VECT, I want to change the VECT
values; add some values, basicaly operate this VECT.

If anyone can help me I'll be gratefull.

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

[Discuss-gnuradio] Digital TV with USRP and GNU Radio

[Richard Bell]

Does anyone know of a good tutorial that shows how to receive and display
TV on Ubuntu using a USRP and GNU Radio? I'm interested.

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

Re: [Discuss-gnuradio] Digital TV with USRP and GNU Radio

[Andy Walls]

On Wed, 2016-01-06 at 12:00 -0500, discuss-gnuradio-requ...@gnu.org
wrote:


> On Wed, Jan 6, 2016 at 11:09 AM, Richard Bell
> 
> wrote:
> 
> > Does anyone know of a good tutorial that shows how to receive and
> display
> > TV on Ubuntu using a USRP and GNU Radio? I'm interested.
> >
> > Rich
> >
> 
> 
> Rich,
> 
> I'm not sure anyone's written it up, but there are examples in
> gr-dtv/examples. I just looked, and we've neglected to add the files
> to the
> CMakeLists.txt file to install these properly. Regardless, if you have
> the
> source code, look at uhd_atsc_capture.grc and file_atsc_rx.grc. If you
> have
> a powerful enough machine, you can also try uhd_rx_atsc.grc directly.
> 
> I think it'd be great if someone wrote a tutorial showing to how use
> these.
> 
> Tom

Well assuming, you have all the CPU you need:

Start with the simple thing to do: save to a file and then play the
file:
a. Use uhd_rx_atsc.grc to capture a channel as an MPEG TS to a file
named mpeg.ts
b. $ cat mpeg.ts | mplayer -


Then, as a better thing to do: spit out the MPEG TS on a local socket
and play it locally from the socket:
a. Modify uhd_rx_atsc.grc to capture a channel as an MPEG TS and send it
out a TCP Sink or UDP Sink block.
b. $ socat TCP4:127.0.0.1:1234 - | mplayer -

(socat arguments may need tweaking)
socat (a better netcat) and its documentation are available here, if not
packaged by your distro:
http://www.dest-unreach.org/socat/


And then as an even better thing to do: spit out the MPEG TS on a local
socket and then let VLC handle playing locally or streaming over the
network:
a. Modify uhd_rx_atsc.grc to capture a channel as an MPEG TS and send it
out a TCP Sink or UDP Sink block.
b. $ vlc tcp://127.0.0.1:1234 

(vlc arguments may need tweaking, I don't know if that actually works)
VLC can act as a streaming server as well as a decoder/viewer, so you
can use it to stream to other VLC clients on other machines using RTSP
or other multimedia protocols.

Regards,
Andy



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

Re: [Discuss-gnuradio] how to send a complete file

[Michael Berman]

Ekko,

 

It has been a while since I have dealt with this kind of issue with the digital 
coms, but I have run into this.  The problem I found was that there was not 
enough data in the file to feed the packetizer properly.  There are probably 
several work arounds for this, but the simplest would be to pad the data up to 
the exact amount the packetizer needs to generate the packets and send them 
along.  You can check if this is the case by varying the size of your file.  If 
you change the number of bytes in the file, you should see the amount left out 
varying; if you add bytes slowly you should see a breakover point near a 
multiple of the number of bits the packetizer needs that will create a small or 
no amount of data not transmitted.

 

Michael

 

From: discuss-gnuradio-bounces+mrberman87=gmail@gnu.org 
[mailto:discuss-gnuradio-bounces+mrberman87=gmail@gnu.org] On Behalf Of Ekko
Sent: Wednesday, January 06, 2016 9:01 AM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] how to send a complete file

 

hello

 

I'm using gnuradio to simulation the gmsk tx/rx with a file

this is my grc



 

you can see ,i am using a file_sink and file_source,

the file_source is set to not repeat,i want to send this file ony one time.

 

and my source file‘s size is 140KB

 

after i run this grc (i am sure the send is stop )

 

i check the dest file,the size of whitch is 139.3KB

 

then i compare two file

just like


​

we can see that some data is lost(exactly 22 lines)，

so i want to know how can i send a complete file, just i send 140KB,and 
recieved 140KB,

then stop.

 

 

thank you

 

-Ekko​

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

[Discuss-gnuradio] Saving files

[Pedro Gabriel Adami]

Hello, everybody,

I'm using File sink in Gnuradio to save some numbers that come from Moving
Average block. I can see them using Number Sink, but when I use File Sink
to save them and I open (in Matlab) the binary file generated, I get
millions of numbers, that is, this amount is wrong. Do you know why is this
happening and how to solve it?

Ps: I'm only using block, not Python codes yet.

Thanks in advance!

-- 
Atenciosamente,
Pedro Gabriel Adami
Graduando do 5º período de Engenharia de Controle e Automação no Instituto
Nacional de Telecomunicações - Inatel
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] About Polymorphic types in gnuradio

[Marcus Müller]

Ah, so it's a uniform vector of _u_signed _8_bit integers.
Try pmt::u8vector_ref(VECT, k), where k is the index of the element you
want to get. To modify, use pmt::u8vector_set(pmt_t, index,value).

Since your pmt is really just a wrapper around memory-contiguous
uint8_ts , you can also "cheat" and directly use the uint8_t*
pmt::u8vector_writable_elements(pmt_t v, size_t & len) method, that will
give you a C-array/pointer to the first element.

All these functions are described on
https://gnuradio.org/doc/doxygen/namespacepmt.html#a73605a64c44ec7f12f5f84bb98e2cae3
as linked from the page I mentioned below.

Best regards,
Marcus

On 06.01.2016 17:13, Gabriel Pechiarovich wrote:
> I'm using message strobe to send the data in the Message PMt parameter
> I used:
>
> pmt.cons(pmt.make_dict(), pmt.make_u8vector(8,0x42 ))
>
> then comes my block, and to read the output i'm using Message Debug block.
>
>
>
> 2016-01-06 10:55 GMT-05:00 Marcus Müller  >:
>
> Hi Gabriel,
>
> do you know what kind of PMT VECT is? pmt_t is a container, and
> might contain a lot of different things.
> Is it a pmt::vector, or a pmt::uniform_vector, or a list, or
> something else?
>
> For an overview, I'd like to point you to the polymorphic types
> page in the GNU Radio manual [1].
>
> Best regards,
> Marcus
>
> [1] https://gnuradio.org/doc/doxygen/page_pmt.html
>
>
> On 06.01.2016 16:10, Gabriel Pechiarovich wrote:
>> Hi, I've been working in oot modules in gnuradio for a while, but
>> recently I've been trying to program blocks who can handle messages.
>>
>> I've extracted the input data and replicated it at the output,
>> like this:
>>
>> pmt::pmt_t META = pmt::car(PDU);
>> pmt::pmt_t VECT = pmt::cdr(PDU);
>> std::cout << "Vect: " << VECT<< '\n';
>> message_port_pub(pmt::mp("out_pdu"), pmt::cons(META, VECT));
>>
>> But I can't understand how to handle VECT, I want to change the
>> VECT values; add some values, basicaly operate this VECT.
>>
>> If anyone can help me I'll be gratefull.
>>
>> -- 
>> Gabriel Pechiarovich Salas
>>
>>
>>
>> ___
>> 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
>
>
>
>
> -- 
> Gabriel Pechiarovich Salas
> Red Dragon Games
> Designers and game developers

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

Re: [Discuss-gnuradio] About Polymorphic types in gnuradio

[Tom Rondeau]

On Wed, Jan 6, 2016 at 11:23 AM, Marcus Müller 
wrote:

> Ah, so it's a uniform vector of _u_signed _8_bit integers.
> Try pmt::u8vector_ref(VECT, k), where k is the index of the element you
> want to get. To modify, use pmt::u8vector_set(pmt_t, index,value).
>
> Since your pmt is really just a wrapper around memory-contiguous uint8_ts
> , you can also "cheat" and directly use the uint8_t*
> pmt::u8vector_writable_elements(pmt_t v, size_t & len) method, that will
> give you a C-array/pointer to the first element.
>


This is not recommended, though. Vectors are unique in the PMT world as
they are actually writable. However, if multiple blocks have access to the
same PMT vector, you can have thread contention issues when reading and
writing.

Better to get the elements as a copy using "std::vector v
= pmt::u8vector_elements(VECT)", manipulate that, and create a new PMT.
It's less efficient, but safer.

Tom




> All these functions are described on
>
> https://gnuradio.org/doc/doxygen/namespacepmt.html#a73605a64c44ec7f12f5f84bb98e2cae3
> as linked from the page I mentioned below.
>
> Best regards,
> Marcus
>
>
> On 06.01.2016 17:13, Gabriel Pechiarovich wrote:
>
> I'm using message strobe to send the data in the Message PMt parameter I
> used:
>
> pmt.cons(pmt.make_dict(), pmt.make_u8vector(8,0x42 ))
>
> then comes my block, and to read the output i'm using Message Debug block.
>
>
>
> 2016-01-06 10:55 GMT-05:00 Marcus Müller :
>
>> Hi Gabriel,
>>
>> do you know what kind of PMT VECT is? pmt_t is a container, and might
>> contain a lot of different things.
>> Is it a pmt::vector, or a pmt::uniform_vector, or a list, or something
>> else?
>>
>> For an overview, I'd like to point you to the polymorphic types page in
>> the GNU Radio manual [1].
>>
>> Best regards,
>> Marcus
>>
>> [1] https://gnuradio.org/doc/doxygen/page_pmt.html
>>
>>
>> On 06.01.2016 16:10, Gabriel Pechiarovich wrote:
>>
>> Hi, I've been working in oot modules in gnuradio for a while, but
>> recently I've been trying to program blocks who can handle messages.
>>
>> I've extracted the input data and replicated it at the output, like this:
>>
>> pmt::pmt_t META = pmt::car(PDU);
>> pmt::pmt_t VECT = pmt::cdr(PDU);
>> std::cout << "Vect: " << VECT<< '\n';
>> message_port_pub(pmt::mp("out_pdu"), pmt::cons(META, VECT));
>>
>> But I can't understand how to handle VECT, I want to change the VECT
>> values; add some values, basicaly operate this VECT.
>>
>> If anyone can help me I'll be gratefull.
>>
>> --
>> Gabriel Pechiarovich Salas
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> --
> Gabriel Pechiarovich Salas
> Red Dragon Games
> Designers and game developers
>
>
>
> ___
> 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] Digital TV with USRP and GNU Radio

[Tom Rondeau]

On Wed, Jan 6, 2016 at 11:09 AM, Richard Bell 
wrote:

> Does anyone know of a good tutorial that shows how to receive and display
> TV on Ubuntu using a USRP and GNU Radio? I'm interested.
>
> Rich
>


Rich,

I'm not sure anyone's written it up, but there are examples in
gr-dtv/examples. I just looked, and we've neglected to add the files to the
CMakeLists.txt file to install these properly. Regardless, if you have the
source code, look at uhd_atsc_capture.grc and file_atsc_rx.grc. If you have
a powerful enough machine, you can also try uhd_rx_atsc.grc directly.

I think it'd be great if someone wrote a tutorial showing to how use these.

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

Re: [Discuss-gnuradio] Digital TV with USRP and GNU Radio

[Richard Bell]

Got it. Thanks Tom.

Rich

On Wed, Jan 6, 2016 at 8:26 AM, Tom Rondeau  wrote:

> On Wed, Jan 6, 2016 at 11:09 AM, Richard Bell 
> wrote:
>
>> Does anyone know of a good tutorial that shows how to receive and display
>> TV on Ubuntu using a USRP and GNU Radio? I'm interested.
>>
>> Rich
>>
>
>
> Rich,
>
> I'm not sure anyone's written it up, but there are examples in
> gr-dtv/examples. I just looked, and we've neglected to add the files to the
> CMakeLists.txt file to install these properly. Regardless, if you have the
> source code, look at uhd_atsc_capture.grc and file_atsc_rx.grc. If you have
> a powerful enough machine, you can also try uhd_rx_atsc.grc directly.
>
> I think it'd be great if someone wrote a tutorial showing to how use these.
>
> Tom
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] About Polymorphic types in gnuradio

[Marcus Müller]

Sorry, forgot about that; also, to make matters worse: "different
blocks" also means "different threads", so this is not only a data
integrity, but especially a multithreading horror.


On 06.01.2016 17:30, Tom Rondeau wrote:
> On Wed, Jan 6, 2016 at 11:23 AM, Marcus Müller
> > wrote:
>
> Ah, so it's a uniform vector of _u_signed _8_bit integers.
> Try pmt::u8vector_ref(VECT, k), where k is the index of the
> element you want to get. To modify, use pmt::u8vector_set(pmt_t,
> index,value).
>
> Since your pmt is really just a wrapper around memory-contiguous
> uint8_ts , you can also "cheat" and directly use the uint8_t*
> pmt::u8vector_writable_elements(pmt_t v, size_t & len) method,
> that will give you a C-array/pointer to the first element.
>
>
>
> This is not recommended, though. Vectors are unique in the PMT world
> as they are actually writable. However, if multiple blocks have access
> to the same PMT vector, you can have thread contention issues when
> reading and writing.
>
> Better to get the elements as a copy using "std::vector v
> = pmt::u8vector_elements(VECT)", manipulate that, and create a new
> PMT. It's less efficient, but safer.
>
> Tom
>
>
>  
>
> All these functions are described on
> 
> https://gnuradio.org/doc/doxygen/namespacepmt.html#a73605a64c44ec7f12f5f84bb98e2cae3
> as linked from the page I mentioned below.
>
> Best regards,
> Marcus
>
>
> On 06.01.2016 17:13, Gabriel Pechiarovich wrote:
>> I'm using message strobe to send the data in the Message PMt
>> parameter I used:
>>
>> pmt.cons(pmt.make_dict(), pmt.make_u8vector(8,0x42 ))
>>
>> then comes my block, and to read the output i'm using Message
>> Debug block.
>>
>>
>>
>> 2016-01-06 10:55 GMT-05:00 Marcus Müller
>> >:
>>
>> Hi Gabriel,
>>
>> do you know what kind of PMT VECT is? pmt_t is a container,
>> and might contain a lot of different things.
>> Is it a pmt::vector, or a pmt::uniform_vector, or a list, or
>> something else?
>>
>> For an overview, I'd like to point you to the polymorphic
>> types page in the GNU Radio manual [1].
>>
>> Best regards,
>> Marcus
>>
>> [1] https://gnuradio.org/doc/doxygen/page_pmt.html
>>
>>
>> On 06.01.2016 16:10, Gabriel Pechiarovich wrote:
>>> Hi, I've been working in oot modules in gnuradio for a
>>> while, but recently I've been trying to program blocks who
>>> can handle messages.
>>>
>>> I've extracted the input data and replicated it at the
>>> output, like this:
>>>
>>> pmt::pmt_t META = pmt::car(PDU);
>>> pmt::pmt_t VECT = pmt::cdr(PDU);
>>> std::cout << "Vect: " << VECT<< '\n';
>>> message_port_pub(pmt::mp("out_pdu"), pmt::cons(META, VECT));
>>>
>>> But I can't understand how to handle VECT, I want to change
>>> the VECT values; add some values, basicaly operate this VECT.
>>>
>>> If anyone can help me I'll be gratefull.
>>>
>>> -- 
>>> Gabriel Pechiarovich Salas
>>>
>>>
>>>
>>> ___
>>> 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
>>
>>
>>
>>
>> -- 
>> Gabriel Pechiarovich Salas
>> Red Dragon Games
>> Designers and game developers
>
>
> ___
> 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] About Polymorphic types in gnuradio

[Gabriel Pechiarovich]

I'm using message strobe to send the data in the Message PMt parameter I
used:

pmt.cons(pmt.make_dict(), pmt.make_u8vector(8,0x42 ))

then comes my block, and to read the output i'm using Message Debug block.



2016-01-06 10:55 GMT-05:00 Marcus Müller :

> Hi Gabriel,
>
> do you know what kind of PMT VECT is? pmt_t is a container, and might
> contain a lot of different things.
> Is it a pmt::vector, or a pmt::uniform_vector, or a list, or something
> else?
>
> For an overview, I'd like to point you to the polymorphic types page in
> the GNU Radio manual [1].
>
> Best regards,
> Marcus
>
> [1] https://gnuradio.org/doc/doxygen/page_pmt.html
>
>
> On 06.01.2016 16:10, Gabriel Pechiarovich wrote:
>
> Hi, I've been working in oot modules in gnuradio for a while, but recently
> I've been trying to program blocks who can handle messages.
>
> I've extracted the input data and replicated it at the output, like this:
>
> pmt::pmt_t META = pmt::car(PDU);
> pmt::pmt_t VECT = pmt::cdr(PDU);
> std::cout << "Vect: " << VECT<< '\n';
> message_port_pub(pmt::mp("out_pdu"), pmt::cons(META, VECT));
>
> But I can't understand how to handle VECT, I want to change the VECT
> values; add some values, basicaly operate this VECT.
>
> If anyone can help me I'll be gratefull.
>
> --
> Gabriel Pechiarovich Salas
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Gabriel Pechiarovich Salas
Red Dragon Games
Designers and game developers
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] modify c++ source code

[kerry]

Hi，all：

I had ran uhd_fft.py successful. Now I want to modify the c++ source code in
"gr_uhd_usrp_source.cc". I read the uhd_fft.py code found parameter setting
through called set function(eg:set_center_freq()) in
"gr_uhd_usrp_source.cc". But when I modify the code it not execute the
"gr_uhd_usrp_source.cc" file. I don't know why? 

Look forward to your reply.

Thx
Ke



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/modify-c-source-code-tp57674.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] Saving files

[Marcus Müller]

Hi Pedro,

this means you're using the wrong storage format when loading things in
matlab.

Best regards,
Marcus

On 06.01.2016 19:42, Pedro Gabriel Adami wrote:
> Hello, everybody,
>
> I'm using File sink in Gnuradio to save some numbers that come from
> Moving Average block. I can see them using Number Sink, but when I use
> File Sink to save them and I open (in Matlab) the binary file
> generated, I get millions of numbers, that is, this amount is wrong.
> Do you know why is this happening and how to solve it?
>
> Ps: I'm only using block, not Python codes yet.
>
> Thanks in advance!
>
> -- 
> Atenciosamente,
> Pedro Gabriel Adami
> Graduando do 5º período de Engenharia de Controle e Automação no
> Instituto Nacional de Telecomunicações - Inatel
>
>
> ___
> 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] how to send a complete file

[Marcus Müller]

Hi Ekko,

as Michael said, if you need arbitrary lengths of data to be complete,
that would be at least one layer up the network layer model; you'll need
to ensure your data fits into packets perfectly.

Best regards,
Marcus

On 06.01.2016 19:26, Michael Berman wrote:
>
> Ekko,
>
>  
>
> It has been a while since I have dealt with this kind of issue with
> the digital coms, but I have run into this.  The problem I found was
> that there was not enough data in the file to feed the packetizer
> properly.  There are probably several work arounds for this, but the
> simplest would be to pad the data up to the exact amount the
> packetizer needs to generate the packets and send them along.  You can
> check if this is the case by varying the size of your file.  If you
> change the number of bytes in the file, you should see the amount left
> out varying; if you add bytes slowly you should see a breakover point
> near a multiple of the number of bits the packetizer needs that will
> create a small or no amount of data not transmitted.
>
>  
>
> Michael
>
>  
>
> *From:*discuss-gnuradio-bounces+mrberman87=gmail@gnu.org
> [mailto:discuss-gnuradio-bounces+mrberman87=gmail@gnu.org] *On
> Behalf Of *Ekko
> *Sent:* Wednesday, January 06, 2016 9:01 AM
> *To:* discuss-gnuradio@gnu.org
> *Subject:* [Discuss-gnuradio] how to send a complete file
>
>  
>
> hello
>
>  
>
> I'm using gnuradio to simulation the gmsk tx/rx with a file
>
> this is my grc
>
>  
>
> you can see ,i am using a file_sink and file_source,
>
> the file_source is set to not repeat,i want to send this file ony one
> time.
>
>  
>
> and my source file‘s size is 140KB
>
>  
>
> after i run this grc (i am sure the send is stop )
>
>  
>
> i check the dest file,the size of whitch is 139.3KB
>
>  
>
> then i compare two file
>
> just like
>
>
> ​
>
> we can see that some data is lost(exactly 22 lines)，
>
> so i want to know how can i send a complete file, just i send
> 140KB,and recieved 140KB,
>
> then stop.
>
>  
>
>  
>
> thank you
>
>  
>
> -Ekko​
>
>
>
> ___
> 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] modify c++ source code

[Marcus Müller]

Hi Kerry,

you normally don't start by modifying existing blocks.
You don't seem to be familiar with C++ development: C++ source code is
not directly executed; you will need to compile GNU Radio including the
changed source code, and install it again.

Also, gr_uhd_usrp_source.cc is definitely from a very outdated version
of GNU Radio. You should use a more modern GNU Radio.

My feeling is that you should not modify C++ source code as a beginner
in GNU Radio development. I *strongly* recommend the guided tutorials;
they show you how to achieve the things you want fast, and they are a
quick, and mostly /fun/ thing to read :)
https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials

Best regards,
Marcus


On 06.01.2016 20:30, kerry wrote:
> Hi，all：
>
> I had ran uhd_fft.py successful. Now I want to modify the c++ source code in
> "gr_uhd_usrp_source.cc". I read the uhd_fft.py code found parameter setting
> through called set function(eg:set_center_freq()) in
> "gr_uhd_usrp_source.cc". But when I modify the code it not execute the
> "gr_uhd_usrp_source.cc" file. I don't know why? 
>
> Look forward to your reply.
>
> Thx
> Ke
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/modify-c-source-code-tp57674.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