Re: [Discuss-gnuradio] Weird noise using RFX2400
Hi Josh, Thanks for your kind reply. The figure is shown in http://dl.dropbox.com/u/39710586/rfx2400_sample.png . I guess it is not caused by Tx transient, because: 1) The TX N210 is just dedicated to TX path in my application, and thus does not have Tx/Rx switch capability; 2) I have used XCVR2450 to receive sampled data (uhd_rx_cfile.py) with the same tx setup (Tx uses RFX2400), but there is no such high noise. Maybe I should switch to the usrp-user mail-list? Regards, Lizhao 2012/9/19 Josh Blum j...@ettus.com On 09/18/2012 09:27 AM, You Lizhao wrote: Hi All, I have used RFX2400+N210 to sample real-time OFDM signal, and found that there are two suspicious noises, which are shown in attachment or http://uploadpie.com/vcX3j . One suspicious noise appears at the start-up stage of N210, and the other suspicious noise appears at the end of a packet. The unwanted noise may ruin my ofdm_sync algorithm. So I am wondering that is it possible to get rid of these noises? How do they come? BTW, I use GNURadio v3.6.3 and UHD driver cloned at Sep. 11. Any comments are appreciated. Thanks! I couldnt see the upload pie link. Perhaps you are seeing transients when TX stops. I guess I have 2 suggestions: 1) make sure you are ending the transmit burst with the EOB tag http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_sink.h#n59 http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/examples/c++ 2) Also its good to pad out the burst/ofdm frame to push the frame through the TX DSP filters, and also to mitigate transients. -josh Regards, Lizhao ___ 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 attachment: rfx2400_sample.png___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 2 used USRPs for Sale
Hi All, I know that many of the users are looking for used USRPs, so I thought I'd let you know that I have listed 2 of my USRP 1s for sale on ebay. One is equipped with a 52MHz clock required for running OpenBTS and the other one is unaltered. I prefer to ship to the UK only, but if you are elsewhere in Europe I can consider other destinations as well. Take a look at these listings if you are interested and let me know if you have any questions. Ettus Research USRP Software Defined Radio DBSRX2 RFX1200: http://www.ebay.co.uk/itm/221127259077?ssPageName=STRK:MESELX:IT_trksid=p3984.m1555.l2649#ht_483wt_1418 Ettus USRP 1 Software Radio for use with OpenBTS 2.6: http://www.ebay.co.uk/itm/221127267689?ssPageName=STRK:MESELX:IT_trksid=p3984.m1555.l2649#ht_500wt_1414 Vahid Behzadan___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ofdm block
On Wed, Sep 19, 2012 at 1:28 AM, Viktor Ivan Rodriguez Abdala
abd...@cicese.edu.mx wrote:
Hi,
I get the following output with dir(Umbrella), and I can't see anything
called dftsofdm
['SwigPyIterator', 'SwigPyIterator_swigregister',
'Umbrella_bin2dec_ff_sptr', 'Umbrella_bin2dec_ff_sptr_swigregister',
'Umbrella_dec2bin_ff_sptr', 'Umbrella_dec2bin_ff_sptr_swigregister',
'Umbrella_decodconv_vff_sptr', 'Umbrella_decodconv_vff_sptr_swigregister',
'Umbrella_encodconv_vff_sptr', 'Umbrella_encodconv_vff_sptr_swigregister',
'Umbrella_swig', '_RTLD_GLOBAL', '__builtins__', '__doc__', '__file__',
'__name__', '__package__', '__path__', '_dlopenflags', 'bin2dec_ff',
'dec2bin_ff', 'decodconv_vff', 'encodconv_vff', 'sys']
How can I install my component correctly into Umbrella?
Ivan
Did you remember to edit the SWIG .i file? It's likely that there is
some small mistake in your build system that's not installing
everything properly.
You should look into using gr-modtool: https://github.com/mbant/gr-modtool
It helps you automatically create GNU Radio components and blocks,
including handling the CMakeLists.txt and .i files properly.
Tom
2012/9/15 Tom Rondeau t...@trondeau.com
On Thu, Sep 13, 2012 at 1:29 AM, abd...@cicese.edu.mx wrote:
Hi,
First I delete all the files in the build folder, later I run the follow
comands in the build folder:
1) cmake ../
2) make
3) sudo make install
4) sudo ldconfig
Ivan
Enviado desde mi oficina móvil BlackBerry® de Telcel
Well, that's doing the right thing. My guess is that it's some minor
error somewhere in your build system or something. It sounds like one
of those things that'll be very difficult to debug via email this way.
Here's one place to start, though. Forget GRC for the time being and
just make sure that you are installing your component correctly. So
first build and install your component, Umbrella. Then simply pop open
a Python interpreter ('python' or 'ipython' if you have the latter
installed):
import Umbrella
dir(Umbrella)
The output of the dir() command should show you what blocks are
actually installed as part of this component. That'll give you a clue
how your installation process is working.
Tom
-Original Message-
From: Tom Rondeau t...@trondeau.com
Sender: trond...@trondeau.com
Date: Wed, 12 Sep 2012 20:45:26
To: Viktor Ivan Rodriguez Abdalaabd...@cicese.edu.mx
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] ofdm block
On Mon, Sep 10, 2012 at 1:12 PM, Viktor Ivan Rodriguez Abdala
abd...@cicese.edu.mx wrote:
Hi
In the python folder, the CMakeLists.txt has
GR_PYTHON_INSTALL(
FILES
__init__.py dftsofdm.py DESTINATION ${GR_PYTHON_DIR}/Umbrella
)
In the grc folder
install(FILES
Umbrella_bin2dec_ff.xml
Umbrella_dec2bin_ff.xml
Umbrella_encodconv_vff.xml
Umbrella_decodconv_vff.xml
Umbrella_dftsofdm_mod.xml
Umbrella_dftsofdm_demod.xml DESTINATION share/gnuradio/grc/blocks
)
I delete all build files and rerun cmake ../ I think the problem is in
the
xml file with the make section.
Ivan Rodriguez
After rerunning cmake, did you also 'make' and 'make install'?
Tom
On 09/07/2012 07:26 AM, Tom Rondeau wrote:
On Thu, Sep 6, 2012 at 3:59 PM, Viktor Ivan Rodriguez Abdala
abd...@cicese.edu.mx wrote:
Hi all,
I'm looking to develop a block called dfts ofdm, based in a similar
block
called ofdm mod, I change the .xml and .py to a new name called
DFTSOFDM,
but I can't make it work. In GRC I have the following error:
Traceback (most recent call last):
File /home/administrador/Simulacion/top_block.py, line 86, in
module
tb = top_block()
File /home/administrador/Simulacion/top_block.py, line 55, in
__init__
self.Umbrella_dftsofdm_mod_0 =
grc_blks2.packet_mod_f(Umbrella.dftsofdm_mod(
AttributeError: 'module' object has no attribute 'dftsofdm_mod'
Is everything properly in the CMakeLists.txt files? Did you make sure
to rebuild and reinstall? Also, if that doesn't help, rerun cmake on
the project to make sure everything is properly reconfigured.
Tom
The new python file es dftsofdm.py, and I change the classes with
class dftsofdm_mod(gr.hier_block2):
class dftsofdm_demod(gr.hier_block2):
The .xml files have this changes:
Umbrella_dftsofdm_demod.xml
nameDFTSOFDM Demod/name
keyUmbrella_dftsofdm_demod/key
categoryUmbrella/category
importimport Umbrella/import
importfrom grc_gnuradio import blks2 as grc_blks2/import
importfrom gnuradio import digital/import
makegrc_blks2.packet_demod_$(type.fcn)(Umbrella.dftsofdm_demod(
options=grc_blks2.options(
modulation=$modulation,
fft_length=$fft_length,
occupied_tones=$occupied_tones,
cp_length=$cp_length,
snr=$snr,
[Discuss-gnuradio] 2 complex receive channels on usrp n210
Hello All, I know that on the USRP1, it was possible to have four seperate RX channels, and therefore receive two pairs of IQ samples. I was wondering if there were any way to do this on a USRP N210, using a basic RX daughterboard, even by possible changing the FPGA code, or it you could only have one pair of IQ samples. Thanks, Anisha ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 2 complex receive channels on usrp n210
On 09/19/2012 10:44 AM, Anisha Gorur wrote: Hello All, I know that on the USRP1, it was possible to have four seperate RX channels, and therefore receive two pairs of IQ samples. I was wondering if there were any way to do this on a USRP N210, using a basic RX daughterboard, even by possible changing the FPGA code, or it you could only have one pair of IQ samples. Yes. Same idea, except, the frontend names for Basic RX are A, B, and AB: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-May/001271.html -josh Thanks, Anisha ___ 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] 2 complex receive channels on usrp n210
Great! So if i selected 0:A and 0:B as multiple subdevices, I would receive something like I0, Q0 and I1, Q1? On Wed, Sep 19, 2012 at 12:45 PM, Josh Blum j...@ettus.com wrote: On 09/19/2012 10:44 AM, Anisha Gorur wrote: Hello All, I know that on the USRP1, it was possible to have four seperate RX channels, and therefore receive two pairs of IQ samples. I was wondering if there were any way to do this on a USRP N210, using a basic RX daughterboard, even by possible changing the FPGA code, or it you could only have one pair of IQ samples. Yes. Same idea, except, the frontend names for Basic RX are A, B, and AB: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-May/001271.html -josh Thanks, Anisha ___ 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 -- Anisha Gorur Class of 2012 Electrical Engineering ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] rtl_tcp console messages...what the hell?!?
Maybe i'm loosing packets? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] rtl_tcp console messages...what the hell?!?
thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 2 complex receive channels on usrp n210
I tried this out, and I am getting two real signals, while I want two complex signals. From dboards.rst: ^^^ Basic RX and LFRX ^^^ The Basic RX and LFRX boards have 4 frontends: * **Frontend A:** real signal on antenna RXA * **Frontend B:** real signal on antenna RXB * **Frontend AB:** quadrature frontend using both antennas (IQ) * **Frontend BA:** quadrature frontend using both antennas (QI) So choosing A and B as the subdevice specs would give me two real signals, correct? On Wed, Sep 19, 2012 at 2:58 PM, Anisha Gorur at...@virginia.edu wrote: Great! So if i selected 0:A and 0:B as multiple subdevices, I would receive something like I0, Q0 and I1, Q1? On Wed, Sep 19, 2012 at 12:45 PM, Josh Blum j...@ettus.com wrote: On 09/19/2012 10:44 AM, Anisha Gorur wrote: Hello All, I know that on the USRP1, it was possible to have four seperate RX channels, and therefore receive two pairs of IQ samples. I was wondering if there were any way to do this on a USRP N210, using a basic RX daughterboard, even by possible changing the FPGA code, or it you could only have one pair of IQ samples. Yes. Same idea, except, the frontend names for Basic RX are A, B, and AB: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-May/001271.html -josh Thanks, Anisha ___ 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 -- Anisha Gorur Class of 2012 Electrical Engineering -- Anisha Gorur Class of 2012 Electrical Engineering ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] N210 FPGA image not compatible with the host uhd code build?
Hello community, There seems to be software compatibility issue between the host (ubuntu 12.04) uhd build and USRP N210 FPGA image. The Runtime errors are captured as: -- $ uhd_usrp_probe linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.003-224-gc2e197c0 -- Opening a USRP2/N-Series device... Error: RuntimeError: Please update the firmware and FPGA images for your device. See the application notes for USRP2/N-Series for instructions. Expected FPGA compatibility number 10, but got 9: The FPGA build is not compatible with the host code build. Please run: sudo /usr/local/share/uhd/utils/uhd_images_downloader.py /usr/local/share/uhd/utils/usrp_n2xx_net_burner.py \ --fpga=/usr/local/share/uhd/images/usrp_n210_r4_fpga.bin \ --fw=/usr/local/share/uhd/images/usrp_n210_fw.bin \ --addr=192.168.10.2 So I did perform the above command shown in the output message. After downloading the image, the system claims that the FPGA write image was successful. But when I tried the uhd_usrp_probe command again, it still has the same error message, as if the updating did nothing to change the situation. I did notice that when downloading the image, it was from: Downloading images from: http://files.ettus.com/binaries/master_images/archive/uhd-images_003.004.003-205-g4896bf78.zip But the message from the probe command returns the uhd image version as follows: $ uhd_usrp_probe linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.003-224-gc2e197c0 Is it possible that the downloaded fpga images is outdated, and a correct version that matches the label 224 would work? Where is the correct FPGA image to download? Thanks, LD Zhang ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 2 complex receive channels on usrp n210
On 09/19/2012 04:54 PM, Anisha Gorur wrote: I tried this out, and I am getting two real signals, while I want two complex signals. From dboards.rst: ^^^ Basic RX and LFRX ^^^ The Basic RX and LFRX boards have 4 frontends: * **Frontend A:** real signal on antenna RXA * **Frontend B:** real signal on antenna RXB * **Frontend AB:** quadrature frontend using both antennas (IQ) * **Frontend BA:** quadrature frontend using both antennas (QI) So choosing A and B as the subdevice specs would give me two real signals, correct? In this case, the DDC chains will zero out Q, and connect A or B to I. So you will get complex data centered at whatever you tune center frequency to. -josh On Wed, Sep 19, 2012 at 2:58 PM, Anisha Gorur at...@virginia.edu wrote: Great! So if i selected 0:A and 0:B as multiple subdevices, I would receive something like I0, Q0 and I1, Q1? On Wed, Sep 19, 2012 at 12:45 PM, Josh Blum j...@ettus.com wrote: On 09/19/2012 10:44 AM, Anisha Gorur wrote: Hello All, I know that on the USRP1, it was possible to have four seperate RX channels, and therefore receive two pairs of IQ samples. I was wondering if there were any way to do this on a USRP N210, using a basic RX daughterboard, even by possible changing the FPGA code, or it you could only have one pair of IQ samples. Yes. Same idea, except, the frontend names for Basic RX are A, B, and AB: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-May/001271.html -josh Thanks, Anisha ___ 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 -- Anisha Gorur Class of 2012 Electrical Engineering ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] N210 FPGA image not compatible with the host uhd code build?
On 09/19/2012 05:29 PM, LD Zhang wrote: Hello community, There seems to be software compatibility issue between the host (ubuntu 12.04) uhd build and USRP N210 FPGA image. The Runtime errors are captured as: -- $ uhd_usrp_probe linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.003-224-gc2e197c0 -- Opening a USRP2/N-Series device... Error: RuntimeError: Please update the firmware and FPGA images for your device. See the application notes for USRP2/N-Series for instructions. Expected FPGA compatibility number 10, but got 9: The FPGA build is not compatible with the host code build. Please run: sudo /usr/local/share/uhd/utils/uhd_images_downloader.py /usr/local/share/uhd/utils/usrp_n2xx_net_burner.py \ --fpga=/usr/local/share/uhd/images/usrp_n210_r4_fpga.bin \ --fw=/usr/local/share/uhd/images/usrp_n210_fw.bin \ --addr=192.168.10.2 Hmm, not sure. Make sure you are 1) There are two commands there. The downloader and the burner. Make sure both are executed. 2) You will need to power cycle the USRP after the burn If that is failing, let me know but... it looks like you have installed the master branch. So the compatible images can be manually grabbed from here: http://files.ettus.com/binaries/master_images/ -josh So I did perform the above command shown in the output message. After downloading the image, the system claims that the FPGA write image was successful. But when I tried the uhd_usrp_probe command again, it still has the same error message, as if the updating did nothing to change the situation. I did notice that when downloading the image, it was from: Downloading images from: http://files.ettus.com/binaries/master_images/archive/uhd-images_003.004.003-205-g4896bf78.zip But the message from the probe command returns the uhd image version as follows: $ uhd_usrp_probe linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.003-224-gc2e197c0 Is it possible that the downloaded fpga images is outdated, and a correct version that matches the label 224 would work? Where is the correct FPGA image to download? Thanks, LD Zhang ___ 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] Creation of a block (PSDU 29 octets) using message passing technique
Hi Josh,
I modified in my .h file:
#include gnuradio/block.h
and also, I inherit from gnu radio as follows:
//* This uses the preferred technique: subclassing gr_sync_block.
//class asrp_test_temporal : public gr_sync_block
class asrp_test_temporal : public gnuradio::block// --Here, I added
the inherit
{
private:
// Definition
Then, in the .cc file I wrote:
: gnuradio::block (test_temporal,
gr_make_io_signature(0, 0, 0),
gr_make_io_signature(0, 0, 0),
msg_signature(false, 1))
When I compile again, the complain is different. It displays:
asrp_test_temporal.cc:75:26: error: cannot allocate an object of abstract
type 'asrp_test_temporal'
./asrp_test_temporal.h:99:7: note: because the following virtual
functions are pure within 'asrp_test_temporal':
/usr/local/include/gnuradio/block.h:236:17: note: virtual int
gnuradio::block::work(const InputItems, const OutputItems)
make[2]: *** [asrp_test_temporal.lo] Error 1
According to the instruction in block coding:
https://github.com/guruofquality/grextras/wiki/Blocks-Coding-Guide, I only
need to write the msg_signature(#input,#output), but I decided to use the
gr_make_io_signature anyway, because I am reading the code for the example
of socket_to_blob.cc.
1. Do I need to use gr_make_io_signature or just msg_signature is enough?.
Many thanks for your kind help,
Regards,
Jose.
On Wed, Sep 19, 2012 at 3:33 PM, Josh Blum j...@ettus.com wrote:
On 09/19/2012 01:11 AM, Jose Torres Diaz wrote:
Hi,
I'm trying to use message passing technique in order to create a block
that generates 29 Octets. Currently, I'm using a block that generates 29
Octets and then use tag streaming. In the .cc file, IO signature looks
like:
gr_sync_block (st1_pktsrc_dummy_b,
gr_make_io_signature (0, 0, 0),
gr_make_io_signature (MIN_OUT, MAX_OUT, sizeof (unsigned
char)))
While, the stream tags looks like this:
add_item_tag(0, tag_pos,
d_burst_start_key,
pmt_sob,
d_my_unique_id)
Now, I want to change this approach to message passing as it is explained
here: https://github.com/guruofquality/grextras/wiki/Blocks-Coding-Guide
.
So, I changed the lines indicated above, for the following:
: gr_sync_block (test_temporal,
gr_make_io_signature(0, 0, 0),
gr_make_io_signature(0, 0, 0),
msg_signature(false, 1))
Careful here, check the coding guide,
you need to #include gnuradio/block.h
and inherit from gnuradio::block
-josh
___
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] N210 FPGA image not compatible with the host uhd code build?
Yes it was my fault. Power cycle did the trick. LD Hmm, not sure. Make sure you are 1) There are two commands there. The downloader and the burner. Make sure both are executed. 2) You will need to power cycle the USRP after the burn If that is failing, let me know but... it looks like you have installed the master branch. So the compatible images can be manually grabbed from here: http://files.ettus.com/binaries/master_images/ -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Creation of a block (PSDU 29 octets) using message passing technique
On 09/19/2012 07:42 PM, Jose Torres Diaz wrote:
Hi Josh,
I modified in my .h file:
#include gnuradio/block.h
and also, I inherit from gnu radio as follows:
//* This uses the preferred technique: subclassing gr_sync_block.
//class asrp_test_temporal : public gr_sync_block
class asrp_test_temporal : public gnuradio::block// --Here, I added
the inherit
{
private:
// Definition
Then, in the .cc file I wrote:
: gnuradio::block (test_temporal,
gr_make_io_signature(0, 0, 0),
gr_make_io_signature(0, 0, 0),
msg_signature(false, 1))
When I compile again, the complain is different. It displays:
asrp_test_temporal.cc:75:26: error: cannot allocate an object of abstract
type 'asrp_test_temporal'
./asrp_test_temporal.h:99:7: note: because the following virtual
functions are pure within 'asrp_test_temporal':
/usr/local/include/gnuradio/block.h:236:17: note: virtual int
gnuradio::block::work(const InputItems, const OutputItems)
make[2]: *** [asrp_test_temporal.lo] Error 1
Double check the error, it just wants you to create a work method with
the given definition. The signature stuff looks just fine.
-josh
According to the instruction in block coding:
https://github.com/guruofquality/grextras/wiki/Blocks-Coding-Guide, I only
need to write the msg_signature(#input,#output), but I decided to use the
gr_make_io_signature anyway, because I am reading the code for the example
of socket_to_blob.cc.
1. Do I need to use gr_make_io_signature or just msg_signature is enough?.
Many thanks for your kind help,
Regards,
Jose.
On Wed, Sep 19, 2012 at 3:33 PM, Josh Blum j...@ettus.com wrote:
On 09/19/2012 01:11 AM, Jose Torres Diaz wrote:
Hi,
I'm trying to use message passing technique in order to create a block
that generates 29 Octets. Currently, I'm using a block that generates 29
Octets and then use tag streaming. In the .cc file, IO signature looks
like:
gr_sync_block (st1_pktsrc_dummy_b,
gr_make_io_signature (0, 0, 0),
gr_make_io_signature (MIN_OUT, MAX_OUT, sizeof (unsigned
char)))
While, the stream tags looks like this:
add_item_tag(0, tag_pos,
d_burst_start_key,
pmt_sob,
d_my_unique_id)
Now, I want to change this approach to message passing as it is explained
here: https://github.com/guruofquality/grextras/wiki/Blocks-Coding-Guide
.
So, I changed the lines indicated above, for the following:
: gr_sync_block (test_temporal,
gr_make_io_signature(0, 0, 0),
gr_make_io_signature(0, 0, 0),
msg_signature(false, 1))
Careful here, check the coding guide,
you need to #include gnuradio/block.h
and inherit from gnuradio::block
-josh
___
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] Two-Tone Test Results (Transmitting)
Comment's interspersed below. On Sun, Sep 16, 2012 at 8:51 AM, Michael Hill moth...@gmail.com wrote: Hi guys, Thanks for the responses! Again, let me point out i am quite new to alot of the IIP3 concepts and still have my areas of confusion regarding the board's operation, so if I say anything weird or counter-intuitive please correct me! To start with some info from Dave's queries: 1- Thats right.. these are the sorts of things i'm looking to characterise. I'm not sure if this would be considered some fault with my USRP/daughterboard or within the expected variance in behaviour for the daughterboards :( so a starting point would be to do a single tone measurement, sweeping the gain. That would let you make sure that the gain is relativly linear and figure out the relationship between the gain steps and output power. You can also see how bad the DAC spurs are with the transmitter, something that's important. to understand. 2. An example shot is attached. I'm using a real Spec Amp. Thats right regarding the tones.. I noticed that too. However one thing that might be confusing about this test is that i'm not directly increasing the power by 1dB at a time (in which case I'd expect the 2F1-F2 and 2F2-F1 tones to increase by 3dB..) im changing the output power by varying the gain.. (rather then power directly). So that seemingly would impact the IIP3 values..(e.g. im gathering this would explain why my 2F1-F2 and 2F2-F1 tones aren't increasing by a 3:1 ratio..) In general, the most accurate IP3 measurements are when the IP3 tones are only 3 to 6 dB above the noise floor. Doing this lets you be assured that you're not measuring anything else, (IP5 etc). averaging is also a good idea, as that reduces noise in the measurement. You're measuring with a 100 Hz RBW/VBW, you might be better served by increasing that to 1 or 3 kHz and trace averaging. I'd also reduce the output power until the IP3 tones are 6 dB above the noise floor, and use that single measurement to calculate your OIP3. As your output power increases, Higher order intermodulation products will start to come up at the same frequency and give you a bad measurement, something that's no longer OIP3. 3. Will that affect my measurements for the 2F1-F2 and 2F2-F1 tones though for this calculation? Yes, IP5/IP7 tones can start showing up at higher output levels, close to compression. If you widen up the bandwidth of the measurement to go out to catch the IP5/7 tones, I bet you'll see them with your current measurement setup. Ben 1. (Re: OIP3) thanks thats a good point.. o_0 I should adjust that. 2. (Re: Useful) But knowing the OIP3 will surely still give me an indication of when my transmitter will start showing non-linearities... won't it? I'm not planning on using a USRP as a receiver... OIP3 measurement is a reasonable transmitter quality metric. There are others that are system specific you could use, but it's all measuring the same thing. 3. Re: Clipping. I expect your right, i've used an amplitude of A = 0.25 to avoid the DAC from saturating / causing clipping.. so ideally.. (if i'm right) any non-linear behaviour will be due to the OIP3 rather then the DAC. it's worth making sure of that by measuring the DAC output directly, if possible. On Fri, Sep 14, 2012 at 3:19 AM, Ben Hilburn b...@ettus.com wrote: Michael - Hm, I don't understand what you are attempting to measure. Measuring the input IP3 (IIP3) for a transmitter doesn't mean anything. All that matters is output IP3 (OIP3). The e-mail you linked to is Marcus explaining how to measure the IIP3 through the receive-only port of a daughterboard, using the same daughterboard as a signal source. You are attempting to measure the IIP3 of a transmitter only - whatever data you collect won't tell you anything meaningful. David - Gain levels are approximate, and it is also possible that at the upper amplitudes the ADCs are clipping anyway. Cheers, Ben On Wed, Sep 12, 2012 at 7:56 PM, David Bengtson david.bengt...@gmail.com wrote: Let me preface this by saying I mostly lurk on this list, and haven't touched a USRP of any variety, so I'm unfamiliar with their gain lineup. However, looking at this data, a couple of things come to mind. 1-You're sweeping the gain by 35 dB, and the amplitude is moving by 28 dB, which seems to indicate to me that something strange is going on with the levels. 2-I graphed the levels of the tones, and they aren't moving in amplitude until the gain setting is 15 or so, which seems unusal to me. What does the spectrum analyzer display look like when you are doing this? Do you see visible tones at deltaF? What about at other frequencies? Are you using a real SA or the USRP? 3-The other thing to look at and worry about are IP5/IP7 tones, which can really be a problem when you're approaching P1dB on the output power. I'm suspicious that at higher gain settings, you're starting
[Discuss-gnuradio] variable sink in GRC
hi guys i want to use variable sink block in GRC but i can`t find the block, could you tell me how i find that? please help me . thanks before___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
