[Discuss-gnuradio] Custom GRC block not accepting derived class objects
I'm hoping for suggestions from the GRC and swig savvy folks on the list.
I am trying to add LDPC functionality to gr-fec [1]. I made a GRC block for a
decoder class. The decoder class constructor accepts a base class called
fec_mtrx. In GRC, I am trying to give the decoder block an input of an object
of a class derived from fec_mtrx, called ldpc_R_U_mtrx. The issue is that swig
is giving an error that it expects the base class as the argument.
From the swig documentation, this type of inheritance and type checking seems
to be fully supported and handled by swig. Is there something else I need to
consider in either the block's cheetah template for the make call, or the swig
files?
The organization of the classes is like:
class FEC_API ldpc_R_U_mtrx : public fec_mtrx {};
class FEC_API ldpc_bit_flip_decoder_impl : public ldpc_bit_flip_decoder
{
public:
ldpc_bit_flip_decoder_impl(fec_mtrx *mtrx_obj, unsigned int max_iter=100);
}
And then in variable_ldpc_bit_flip_decoder.xml I've got: self.$(id) = $(id) =
fec.ldpc_bit_flip_decoder.make($matrix_object, $max_iterations)
In my flowgraph, I provide the decoder block an input of a ldpc_R_U_mtrx
variable, and swig throws:
TypeError: in method 'ldpc_bit_flip_decoder_make', argument 1 of type
'gr::fec::code::fec_mtrx *
So to me, it seems like swig is not recognizing that the ldpc_R_U_mtrx class
derives from fec_mtrx. Not sure what to do about that except to try and
“un-inherit the classes and overload the decoder constructor...
Thanks for any tips,
tracie
[1] github.com/tracierenea/gnuradio/tree/ldpc_mods
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Project enquiry/interest
Hi Sajeev, On 02/23/2015 10:56 AM, Sajeev Manikkoth wrote: Hi Marcus, Thanks again for the detailed explanation of current access technologies. As discussed current scheme allows shared access of the channels in time, frequency, and space. Yes, that's how I understood this discussion. What I am talking is about a full simultaneous parallel use or access of channel. I really really don't understand what you mean with that -- what other dimensions than time, frequency, space (incl. polarization) and code can you imagine, that would distinguish one electromagnetic wave from another? This is kind of necessity as wireless bandwidth demands are ever growing and we are hitting spectrum scarcity. Spectrum scarcity has been a reality ever since Marconi! The scheme I am discussing is close to CDMA/MIMO. CDMA base stations already differentiate handsets using same frequency with signature sequences. Implementing a similar approach on the handset side also to differentiate base stations or similar approaches can be in place. CDMA handsets of course already do CDMA -- otherwise, they wouldn't be able to communicate with the base station (which would be disadvantageous, I reckon). LTE handsets (at least from what I remember about LTE Release 8, which is the original LTE release) can make use of MIMO. Probably they already do. In its simplest form the requirement is to allow 2 FM stations using same frequency in a location area. And the receivers tune to the station names to enjoy different music rather than just to the frequency ! Well, that would then necessarily be some kind of diversification by coding -- be it CDMA, or be it multiple lower-rate streams embedded in a broadcast transport stream, which is what DVB does. That doesn't inherently increase spectrum efficiency -- instead of 100 channels with bandwidth b, you get 1 channel with bandwidth 100*b, because you can't cheat channel capacity, and as long as you can't change SNR, the only thing you can increase to get more information from transmitter to receiver is to increase bandwidth. Nothing new as a concept, limitations to achieve this reasons we have all the existing implementations, but 100s of years of engineering fineness. Now this should be possible with soft transceivers using today's digital radio techniques combined with soft techniques... What kind of soft techniques? Soft decision decoders? I still don't really understand where you think that current technology falls short and what's to improve, but I think I'm getting closer to understanding exactly what kind of research is of interest to you; please do elaborate! Greetings, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] (no subject)
On Mon, Feb 23, 2015 at 4:28 AM, Vishwanatha H G
vishwanatha.1si12ec...@gmail.com wrote:
sir, I created a LPF block..when I execute make test command it shows
the error like this:
2: Test command: /bin/sh
/home/lekha/gr-filters/build/python/qa_lpf_test.sh
2: Test timeout computed to be: 9.99988e+06
2: File /home/lekha/gr-filters/python/qa_lpf.py, line 28
2: def test_002_lpf(self):
2: ^
2: IndentationError: unindent does not match any outer indentation level
2/2 Test #2: qa_lpf ...***Failed0.08 sec
50% tests passed, 1 tests failed out of 2
Total Test time (real) = 0.09 sec
The following tests FAILED:
2 - qa_lpf (Failed)
Errors while running CTest
what’s the solution...and also when I connect this block, it will not show
any waveform and it gives error like this:
That's a Python error. Have you tried searching for that error on Google?
It means you have malformed Python code.
Generating: /home/lekha/top_block.py
Warning: This flow graph may not have flow control: no audio or usrp
blocks found. Add a Misc-Throttle block to your flow graph to avoid CPU
congestion.
Executing: /home/lekha/top_block.py
Traceback (most recent call last):
File /home/lekha/top_block.py, line 15, in module
import filters
File /usr/local/lib/python2.7/dist-packages/filters/__init__.py, line
45, in module
from filters_swig import *
File /usr/local/lib/python2.7/dist-packages/filters/filters_swig.py,
line 26, in module
_filters_swig = swig_import_helper()
File /usr/local/lib/python2.7/dist-packages/filters/filters_swig.py,
line 22, in swig_import_helper
_mod = imp.load_module('_filters_swig', fp, pathname, description)
ImportError: /usr/local/lib/libgnuradio-filters.so: undefined symbol:
_ZN2gr6filter6firdes8low_passENS1_8win_typeEd
Done
what is the problem with this..please mail me.thank you
In your project, are you linking against libgnuradio-filter?
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Custom GRC block not accepting derived class objects
On Mon, Feb 23, 2015 at 4:06 AM, Perez, Tracie R tracie.pe...@mavs.uta.edu
wrote:
I'm hoping for suggestions from the GRC and swig savvy folks on the list.
I am trying to add LDPC functionality to gr-fec [1]. I made a GRC block
for a decoder class. The decoder class constructor accepts a base class
called fec_mtrx. In GRC, I am trying to give the decoder block an input of
an object of a class derived from fec_mtrx, called ldpc_R_U_mtrx. The issue
is that swig is giving an error that it expects the base class as the
argument.
From the swig documentation, this type of inheritance and type checking
seems to be fully supported and handled by swig. Is there something else I
need to consider in either the block's cheetah template for the make call,
or the swig files?
The organization of the classes is like:
class FEC_API ldpc_R_U_mtrx : public fec_mtrx {};
class FEC_API ldpc_bit_flip_decoder_impl : public ldpc_bit_flip_decoder
{
public:
ldpc_bit_flip_decoder_impl(fec_mtrx *mtrx_obj, unsigned int
max_iter=100);
}
And then in variable_ldpc_bit_flip_decoder.xml I've got: self.$(id) =
$(id) = fec.ldpc_bit_flip_decoder.make($matrix_object, $max_iterations)
In my flowgraph, I provide the decoder block an input of a ldpc_R_U_mtrx
variable, and swig throws:
TypeError: in method 'ldpc_bit_flip_decoder_make', argument 1 of type
'gr::fec::code::fec_mtrx *
So to me, it seems like swig is not recognizing that the ldpc_R_U_mtrx
class derives from fec_mtrx. Not sure what to do about that except to try
and “un-inherit the classes and overload the decoder constructor...
Thanks for any tips,
tracie
[1] github.com/tracierenea/gnuradio/tree/ldpc_mods
Hey Tracie,
Unfortunately, I don't have a good, easy answer for you. It does seem like
this should work fine. I'm trying to think of examples where we've done
this before. The closest that I know of is with the constellation objects
and something like the constellation_receiver that takes in just the base
class. All of the function calls required are implemented in that base
class, but overloaded by the child class. It also has a function .base()
that returns the pointer to the child object as the base class so we can
pass it through.
Figuring out how to get swig to work with the child class would probably be
the better solution, but maybe you can use the constellation class model to
get things going.
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Project enquiry/interest
Thanks Marcus, and adding some more details. Current signal detection mechanisms for years totally rely on signal attributes (frequency, timing, amplitude) for differentiation of signals. Cognitive detection mechanisms and new PHY layer techniques which emulate human eye like detection and differentiation need to be developed. One simple scheme I can think of is: Human eye can differentiate 2 similar items or let us say identical twins. And when we find it difficult, we add different identification marks on those twins to differentiate and identify. In a similar fashion may be a transmitter can add a unique identification while modulating/transmitting, and the receivers can look for those. Receivers shall first tune to the channel frequency, and then to the unique transmission id to latch to the desired transmitter. In general my interest was to see interest and projects which develops cognitive detection mechanisms and associated new PHY and MAC layer techniques. Hope I am making some sense now... Best regards, Sajeev -Original Message- From: Marcus Müller [mailto:marcus.muel...@ettus.com] Sent: 23 February 2015 19:55 To: Sajeev Manikkoth; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Project enquiry/interest Hi Sajeev, On 02/23/2015 10:56 AM, Sajeev Manikkoth wrote: Hi Marcus, Thanks again for the detailed explanation of current access technologies. As discussed current scheme allows shared access of the channels in time, frequency, and space. Yes, that's how I understood this discussion. What I am talking is about a full simultaneous parallel use or access of channel. I really really don't understand what you mean with that -- what other dimensions than time, frequency, space (incl. polarization) and code can you imagine, that would distinguish one electromagnetic wave from another? This is kind of necessity as wireless bandwidth demands are ever growing and we are hitting spectrum scarcity. Spectrum scarcity has been a reality ever since Marconi! The scheme I am discussing is close to CDMA/MIMO. CDMA base stations already differentiate handsets using same frequency with signature sequences. Implementing a similar approach on the handset side also to differentiate base stations or similar approaches can be in place. CDMA handsets of course already do CDMA -- otherwise, they wouldn't be able to communicate with the base station (which would be disadvantageous, I reckon). LTE handsets (at least from what I remember about LTE Release 8, which is the original LTE release) can make use of MIMO. Probably they already do. In its simplest form the requirement is to allow 2 FM stations using same frequency in a location area. And the receivers tune to the station names to enjoy different music rather than just to the frequency ! Well, that would then necessarily be some kind of diversification by coding -- be it CDMA, or be it multiple lower-rate streams embedded in a broadcast transport stream, which is what DVB does. That doesn't inherently increase spectrum efficiency -- instead of 100 channels with bandwidth b, you get 1 channel with bandwidth 100*b, because you can't cheat channel capacity, and as long as you can't change SNR, the only thing you can increase to get more information from transmitter to receiver is to increase bandwidth. Nothing new as a concept, limitations to achieve this reasons we have all the existing implementations, but 100s of years of engineering fineness. Now this should be possible with soft transceivers using today's digital radio techniques combined with soft techniques... What kind of soft techniques? Soft decision decoders? I still don't really understand where you think that current technology falls short and what's to improve, but I think I'm getting closer to understanding exactly what kind of research is of interest to you; please do elaborate! Greetings, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] creating and importing a new python block
Hello, I tried to build my first custom block. Very easy. It just generates one tune msg every 5 seconds. I followed steps of writing an OOT block in python: http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules#Tutorial-3-Writing-a-signal-processing-block-in-Python % gr_modtool super_msg_generator super_msg_generator % gr_modtool add -t sync -l python generador Inside python/generador.py my code: #!/usr/bin/env python import numpy from gnuradio import gr import time class generador(gr.sync_block): def __init__(self): gr.sync_block.__init__(self, name=generador #,in_sig=[], #,out_sig=[] ) self.message_port_register_out(pmt.intern(ppm)) def work(self): while True: time.sleep(5) self.message_port_pub(pmt.intern(ppm), pmt.to_pmt(freq, float(915e6))) time.sleep(5) self.message_port_pub(pmt.intern(ppm), pmt.to_pmt(freq, float(918e6))) How can I check a block with no inputs and no outputs? After that I created a build folder in gnuradio/gr-super_msg_generator cmake ../ make sudo make install sudo ldconfig I thought that was everyhting. However when trying to setup a python flowgraph the code cannot import the new block. tune_msg.py:: #!/usr/bin/env python from gnuradio import blocks from gnuradio import eng_notation from gnuradio import gr from gnuradio import uhd from gnuradio import super_msg_generator . output when executing: $ python tune_msg.py linux; GNU C++ version 4.7.2; Boost_104900; UHD_003.008.001-42-g8c87a524 Traceback (most recent call last): File tune_msg.py, line 12, in module from gnuradio import super_msg_generator ImportError: cannot import name super_msg_generator There is something missing but I do not figure it out. Any help please? Regards, ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] X300 unknown product code in EEPROM: 2104
Dose any one know what is the problem with this device.Hardware NI USRP 2940R = x310OS Ubuntu 14.04LTSConnection SFP0 what are these warnings X300 unknown product code in EEPROM: 2104 RX dboard ID: Unknown (0x) ./usrp_burn_mb_eeprom --read-all linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.002-80-ge28d7844 Creating USRP device from address: UHD Warning: X300 unknown product code in EEPROM: 2104 UHD Warning: X300 unknown product code in EEPROM: 2104-- X300 initialization sequence...-- Determining maximum frame size... 1472 bytes.-- Setup basic communication...-- Loading values from EEPROM... UHD Warning: X300 unknown product code in EEPROM: 2104-- Setup RF frontend clocking...-- Radio 1x clock:200-- Initialize Radio control...-- Performing register loopback test... pass UHD Warning: Unknown transceiver board ID combination. Is your daughter-board mounted properly? RX dboard ID: Unknown (0x) TX dboard ID: WBX v4 (0x0062)-- Performing register loopback test... pass UHD Warning: Unknown transceiver board ID combination. Is your daughter-board mounted properly? RX dboard ID: Unknown (0x) TX dboard ID: WBX + Simple GDB, WBX v3 + Simple GDB, WBX v4 + Simple GDB, WBX-120 + Simple GDB (0x004f)-- Initializing clock and time using internal sources... done Fetching current settings from EEPROM... EEPROM [revision] is 52 EEPROM [product] is 2104 EEPROM [mac-addr0] is 00:80:2f:0a:f5:0c EEPROM [mac-addr1] is 10:80:2f:0a:f5:0d EEPROM [gateway] is 192.168.10.1 EEPROM [ip-addr0] is 192.168.10.2 EEPROM [subnet0] is 255.255.255.0 EEPROM [ip-addr1] is 192.168.20.2 EEPROM [subnet1] is 255.255.255.0 EEPROM [ip-addr2] is 192.168.30.2 EEPROM [subnet2] is 255.255.255.0 EEPROM [ip-addr3] is 192.168.40.2 EEPROM [subnet3] is 255.255.255.0 EEPROM [serial] is F54E25 EEPROM [name] is Warm RegardsJunaid ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble with SWIG for packet_formatter_default child class
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf
Of Nowlan, Sean
Sent: Monday, February 23, 2015 3:10 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Trouble with SWIG for packet_formatter_default
child class
Hi all -
I'm working on Tom's packet_handling branch (github.com/trondeau/gnuradio.git)
and building a custom packet formatter. Everything works in C++ land, including
QA code. However, SWIG is complaining about undeclared things. I duplicated the
CMake and SWIG structures of gnuradio/gr-digital/swig/ for building derived
classes such as gr::digital::packet_formatter_counter. Any ideas why this would
not work? Thanks!
first few lines of make errors
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx: In function
'PyObject* _wrap_packet_formatter_custom_make(PyObject*, PyObject*, PyObject*)':
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx:5030:3: error:
'sptr' was not declared in this scope
sptr result;
^
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx:5030:8: error:
expected ';' before 'result'
sptr result;
^
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx:5062:7: error:
'result' was not declared in this scope
result = gr::myoot::packet_formatter_custom::make((std::string const
)*arg1,(std::string const )*arg2,arg3);
^
gr-myoot/swig/myoot_swig.i
/* -*- c++ -*- */
#define MYOOT_API
%include gnuradio.i// the common stuff
//load generated python docstrings
%include myoot_swig_doc.i
%{
#include myoot/packet_formatter_custom.h
%}
%include myoot/packet_formatter_custom.h
GR_SWIG_BLOCK_MAGIC2(myoot, packet_formatter_custom);
// Properly package up non-block objects
%include packet_formatter_custom.i
gr-myoot/swig/packet_formatter_custom.i
%template(packet_formatter_custom_sptr)
boost::shared_ptrgr::myoot::packet_formatter_custom;
%pythoncode %{
packet_formatter_custom_sptr.__repr__ = lambda self: packet_formatter_custom
packet_formatter_custom = packet_formatter_custom .make;
%}
--
To get it to build, I added the following typedef to
gr-myoot/include/myoot/packet_formatter_custom.h :
...
public:
typedef
boost:shared_ptrpacket_formatter_custom sptr;
...
Now importing SWIG-generated stuff in Python fails:
import myoot
Traceback (most recent call last):
File input, line 1, in module
File /home/me/target/lib/python2.7/dist-packages/myoot/__init__.py, line
29, in module
from myoot_swig import *
File /home/me/target/lib/python2.7/dist-packages/myoot/myoot_swig.py, line
265, in module
packet_formatter_custom = packet_formatter_custom .make;
AttributeError: 'function' object has no attribute 'make'
This is probably due to a conflict between the definition of sptr: one is being
autogenerated by SWIG based on the typedef in
include/myoot/packet_formatter_custom.h; the other is the template in
swig/packet_formatter_custom.i.
Now if I build without the special sauce in swig/packet_formatter_custom.i, I
can get import myoot in Python to work. However, there's still some strange
behavior if I don't actually assign to a variable.
import myoot
from gnuradio import digital
formatter1 = myoot.packet_formatter_custom(1, 1, 1)
formatter2 = digital.packet_formatter_counter(1, 1)
myoot.packet_formatter_custom(1, 1, 1)
Traceback (most recent call last):
File input, line 1, in module
File /home/me/target/lib/python2.7/dist-packages/myoot/myoot_swig.py, line
261, in lambda
packet_formatter_custom_sptr.__repr__ = lambda self: gr_block %s (%d) %
(self.name(), self.unique_id())
AttributeError: 'packet_formatter_custom_sptr' object has no attribute 'name'
digital.packet_formatter_counter(1, 1)
packet_formatter_default
Note that the sptr in gr-digital is of type packet_formatter_default, meaning
it inherited the definition of the typedef from packet_formatter_default. In my
case it didn't work because I used GR_SWIG_BLOCK_MAGIC2 on a non block, so the
__repr__ definition (above) breaks.
What should I do? I can rely on GR_SWIG_BLOCK_MAGIC2, which is not really the
right way to generate SWIG templates for a non block, or I can try to get
things to work without redefining the sptr typedef in the child class. In that
case, I need to include the proper header file (namely,
packet_formatter_default.h) from gr-digital. Should I do that explicitly in
myoot_swig.i, or is there a better way to add gr-digital to include dirs in
swig/CMakeLists.txt?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Triggering USRP at given GPS time from GNU Radio
Hi all, Whenever I want to trigger USRP with at given time with use of a GPSDO I'm adding something like this at the end of a constructor of a topblock generated by gnuradio-companion: if start_time!=: self.start_time_epoch = time.mktime(time.strptime(start_time,'%d.%m.%Y %H:%M:%S')) self.uhd_usrp_source_0.set_start_time(uhd.time_spec_t(self.start_time_epoch)) where start_time is a string parameter containing the time at which the device should start reception. The snippet might be useful for others trying to do the same thing. I want to ask you if there is a way to do better than that and generate directly in gnuradio-companion a flowgraph that use GPSDO of USRP to trigger it without having to edit anything manually? Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Trouble with SWIG for packet_formatter_default child class
Hi all -
I'm working on Tom's packet_handling branch (github.com/trondeau/gnuradio.git)
and building a custom packet formatter. Everything works in C++ land, including
QA code. However, SWIG is complaining about undeclared things. I duplicated the
CMake and SWIG structures of gnuradio/gr-digital/swig/ for building derived
classes such as gr::digital::packet_formatter_counter. Any ideas why this would
not work? Thanks!
first few lines of make errors
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx: In function
'PyObject* _wrap_packet_formatter_custom_make(PyObject*, PyObject*, PyObject*)':
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx:5030:3: error:
'sptr' was not declared in this scope
sptr result;
^
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx:5030:8: error:
expected ';' before 'result'
sptr result;
^
/home/me/code/gr-myoot/build/swig/myoot_swigPYTHON_wrap.cxx:5062:7: error:
'result' was not declared in this scope
result = gr::myoot::packet_formatter_custom::make((std::string const
)*arg1,(std::string const )*arg2,arg3);
^
gr-myoot/swig/myoot_swig.i
/* -*- c++ -*- */
#define MYOOT_API
%include gnuradio.i// the common stuff
//load generated python docstrings
%include myoot_swig_doc.i
%{
#include myoot/packet_formatter_custom.h
%}
%include myoot/packet_formatter_custom.h
GR_SWIG_BLOCK_MAGIC2(myoot, packet_formatter_custom);
// Properly package up non-block objects
%include packet_formatter_custom.i
gr-myoot/swig/packet_formatter_custom.i
%template(packet_formatter_custom_sptr)
boost::shared_ptrgr::myoot::packet_formatter_custom;
%pythoncode %{
packet_formatter_custom_sptr.__repr__ = lambda self: packet_formatter_custom
packet_formatter_custom = packet_formatter_custom .make;
%}
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] timed dual channel B210 capture gives error UHD source block got error code 0x2 (ERROR_CODE_LATE_COMMAND)
On 22-02-15 22:35, Marcus D. Leech wrote:
On 02/22/2015 04:26 PM, Martin wrote:
Small addition.
I just want to start capturing on both channels of a B210 at the exact
same time. I do not mind which time that is, as long as the samples
are aligned.
I have read a discussion on this mailinglist which made it clear that
you do need to set a start_time (timed_capturing) with dual-channel
capturing with a B210 to have both channels synchronized.
You should not set the internal B210 clock with set_time_now, since
this would set a slightly different time in the two different channels.
This would then result in a random clock misalignment betwen the
channels of up to 250 usec.
it was advised to use set_time_unknown_PPS or leave the time at the
default internal initiated time. This way both channels should have an
aligned internal clock.
Then using a start_time in the near future should result in perfectly
aligned captures. But as I said in my previous mail, this results (for
me) in the UHD error.
UHD source block got error code 0x2
Martin
I use a GR flow-graph to do this for interferometry, without having to
specify anything special.
I use a subdev spec of A:A A:B and specify two channels in the source
block. Everything lines up nicely. You might look at the code that
situation generates if you're hand-coding.
Thanks for the tip. I am going to test this.
I read the following thread on the usrp-users list which suggests
several (counterintuitive) things you need to do right to get
sample-aligned dual-channel capturing on B210:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-November/011360.html
Are you sure that you get sample-aligned samples without using a
start-time. The thread mentioned above suggests that you could get up to
250 usec time difference between the channels.
Note that I generated the basis for my flowgraph with GRC and manually
added the start_time code.
See my code as attachments at:
http://gnuradio.org/redmine/issues/769
I hope that you are right and that I do not need the start_time code for
this application.
But even if I do not need it. I think it should work without errors. For
some (other)applications I actually do need timed capturing.
Thanks,
Martin
On 22-02-15 21:53, Martin wrote:
When you start a dual channel timed capture in the near future with a
B210, the work method of usrp_source_impl.cc prints out
UHD source block got error code 0x2
error codes are defined in:
metadata.hpp line 99:
//! A stream command was issued in the past.
ERROR_CODE_LATE_COMMAND = 0x2,
No matter what starttime (in the future) was chosen, UHD always thinks a
command is scheduled to be run in the past (too late)
When I do the same with a single-channel script on the same B210
everything works fine without errors.
The dual channel always prints out the error, and the single channel
always seems to work fine.
I have tried different settings for the delay, which sets how long in
the future the capture is set to start.
But 0.1 0.2 1.0 2.0 5.0 seconds all seem to fail.
I also tried with or without using 1 PPS to set the clock time, but that
did not help either.
code snippet:
usrp_source_impl.cc
line 663:
switch(_metadata.error_code) {
...
line 692:
default:
std::cout boost::format(UHD source block got error code 0x%x)
% _metadata.error_code std::endl;
return num_samps;
I created an issue on gnuradio.org and attached example python scripts
there to demonstrate the error. Dual channel script fails, single
channel works.
http://gnuradio.org/redmine/issues/769
The defaults are fine for demonstrating the behaviour so you do not need
to give any arguments.
Note that I used a B210 with an embedded GPSDO, which might be
important.
It is also very possible that I am doing something very wrong.
Please let me know.
With best regards,
Martin Dudok van Heel
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FOSDEM 2015 videos -- not quite there, but close
Videos from this year's FOSDEM are starting to trickle in. You can find them at [1], but I'll (or we'll) try and keep [2] up to date, as well. Cheers, Martin [1] http://video.fosdem.org/2015/devroom-software_defined_radio/ [2] http://gnuradio.org/redmine/projects/gnuradio/wiki/Presentations ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Msg passing + tag streaming: Is this flowgraph possible?
Hi all, Martin, At this point I got confused about what I need for implementing message passing and stream tagging reading capabilities. At first I thought everything was implemented in GNURadio 3.7 (which I use) http://gnuradio.org/doc/doxygen/page_msg_passing.html http://gnuradio.org/doc/doxygen/page_stream_tags.html http://gnuradio.org/doc/doxygen/page_tagged_stream_blocks.html However I read about different libraries of GNURadio: feval, gr-extras I got GNURadio 3.7.5 and UHD 3.8. What do I need to start implementing a sink block which sends tunning messages to a USRP source block and reads tags from the data streaming? Martin, any comments or wrong ideas about my last reply? Many thanks for your support, Jorge. On 20 February 2015 at 12:32, Jorge Gallo jmig...@gmail.com wrote: On 20 February 2015 at 10:26, Martin Braun martin.br...@ettus.com wrote: On 02/20/2015 09:33 AM, Jorge Gallo wrote: Hello, I would like to run a flowgraph similar to the one I attach in a picture. It would work as follows: USRP source would send frames with tags indicating the rx_freq of these samples. Then the power of those samples will be calculated. Will the rx_freq tag still be present at the input of the Tagged File Sink or does any block in the middle get rid of them? These blocks will keep the tags in there. If still present in the Tagged File Sink, this block would store centain number of vectors. Lets say 5 vectors of 2048 lenght (this would give me 5 power estimations of the current band). When the number of stored vectors reaches a threshold, the Tagged File sink would stop storing samples and would send a center_freq message to the USRP in order to tune it to a new frequency. Then Tagged File Sink would wait for the new rx_freq tag to store samples (this way I would discard the old frequency samples). Is this flowgraph feasible? Yes, it's possible. However, I'm not sure it'll do exactly what you want (or maybe I'm misunderstanding), for two reasons: - Say you send a msg to the USRP source after you've received 5 vectors of spectral estimate. The USRP source will already be way ahead of your downstream block, so you could potentially be getting hundreds of vectors to process. They will be tagged, so you can discard them if you like. Yes, that is the idea. Since the flowgraph is continuously running many unwanted samples will arrive to my tagged file sink after a tune. I will discard them until I receive a sample with the correct rx_freq tag. - The Vector IIR will not know that you've retuned, so you will be smearing together vectors that don't belong together. What you need is a form of integrate-and-dump -- maybe the gr-specest toolbox can help you with that. I implemented this block in order to do a moving average but as you said it is problematic. The average should be done with the samples written in the files so that if averaging is needed it will be done by the SW which post-processes the written power samples. Without the IIR block, do you see any problem about mixing of wanted and unwanted samples? If I understood it correctly, after a tuning, the USRP source will send automatically the rx_freq tag so I have to do nothing to implement the tag streaming. Is it correct? In case it is, I think I only have to program my custom Tagged File Sink with a vector data input port and a message output port. Is that correct? Apart from what I mentioned above, yes. You might want to choose a different approach, e.g. an open loop approach where you simply send a retune message every N milliseconds. Does your new approach have any advantage? I see that the signal processing (either approach) will have a host-dependent latency so that your X miliseconds parameter would have to be calibrated when different hosts used. Furthermore by monitoring the number of samples written to files I get more control about how much information I write in files. I am open to new solutions before I program something so any tips are more than welcomed. Many many thanks. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] (no subject)
sir, I created a LPF block..when I execute make test command it shows
the error like this:
2: Test command: /bin/sh
/home/lekha/gr-filters/build/python/qa_lpf_test.sh
2: Test timeout computed to be: 9.99988e+06
2: File /home/lekha/gr-filters/python/qa_lpf.py, line 28
2: def test_002_lpf(self):
2: ^
2: IndentationError: unindent does not match any outer indentation level
2/2 Test #2: qa_lpf ...***Failed0.08 sec
50% tests passed, 1 tests failed out of 2
Total Test time (real) = 0.09 sec
The following tests FAILED:
2 - qa_lpf (Failed)
Errors while running CTest
what’s the solution...and also when I connect this block, it will not show
any waveform and it gives error like this:
Generating: /home/lekha/top_block.py
Warning: This flow graph may not have flow control: no audio or usrp
blocks found. Add a Misc-Throttle block to your flow graph to avoid CPU
congestion.
Executing: /home/lekha/top_block.py
Traceback (most recent call last):
File /home/lekha/top_block.py, line 15, in module
import filters
File /usr/local/lib/python2.7/dist-packages/filters/__init__.py, line
45, in module
from filters_swig import *
File /usr/local/lib/python2.7/dist-packages/filters/filters_swig.py,
line 26, in module
_filters_swig = swig_import_helper()
File /usr/local/lib/python2.7/dist-packages/filters/filters_swig.py,
line 22, in swig_import_helper
_mod = imp.load_module('_filters_swig', fp, pathname, description)
ImportError: /usr/local/lib/libgnuradio-filters.so: undefined symbol:
_ZN2gr6filter6firdes8low_passENS1_8win_typeEd
Done
what is the problem with this..please mail me.thank you
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Grcc from ssh session
Thanks Sebastian, Unable to import Colors is also a warning for me, but then I also get: Unable to import Colors 'module' object has no attribute 'CONNECTION_ENABLED_COLOR' Error during file compilation. make: *** [grc_rx] Error 1 Which is an error. It looks like my flowgraph needs Colors after all but I don't know why because it doesn't have a GUI. Thanks, Murray On 20 February 2015 at 10:27, Koslowski, Sebastian (CEL) sebastian.koslow...@kit.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/20/2015 10:01 AM, Murray Thomson wrote: Hi, I'm want to use grcc from an ssh session but I get the error importing the module Colors.py. I've seen this thread http://lists.gnu.org/archive/html/discuss-gnuradio/2013-06/msg00361.html about it. I'm using 3.7.5 and it seems like the patch it's been applied to the source code already. There are no differences between what the patch suggests and the source code that the installer script downloaded to my machine. However, I still get the import error (only when I use ssh). Thanks, Murray I tried to reproduce this on the current master. I also get Unable to import Colors, but it is not an exception. grcc still completes and the output file is generated. Sebastian -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJU5wwQAAoJEIcqoDnyZkMDYQEP/0Mqmeb5d0K3A8G5k8u4LtUk GGHTyVq28h/NAh5NiShF7bFP3IsrLzJuQF3+2AKF8s1nK2WW/vf2RVnO5V+jpxGJ PFbz9GgGSoUPqL7PyTACNo8hJvN6BqMAlVY9luO2YVZSDQGLnyQZm4LEe8WII4fx v52yoxFXhApn6qNjjEybzQ0zP9oQ0bFyGuo5oLBMeeSuRfGspNGfRBu+R2XlzD4C DibsTIm/7qHCZBrbAdMmCB175OiZtpiPJvbS9D5kLT2+HLvHj0eSWW4rXXKGnfNY y3NSvc6Mkul/bhip1sy2kY00yNWeECEyirblYRXsipXrxiGe3pMcwV9+7KbZeZMJ bB/7dbhu+Zlzg1jAKJatSylzgAbLbEnDSW3zgfy6XEjnigi4QyOoQnxECpmSfXQ6 hndyuFbys5mabTekwDPedpj9IOt9TU19gckkSyKgNmQyHbNFP9IvTuS1O4Ypwrew idaSzog+oyXNYYKpKxF49saf/XQpF0a4i2GxEq/DYRFzP5CyoONTMHt4SZiQ1jOg zJS09VozAHOdbjKvjhuFTYmPdKmzoOlQpMIsFpC262xMYBwrM/WM44ifkBmVBwQf wqcZXCAL9o4hsf72ztNdJpaAFZ+3jpbTfxe1ZtbTRCmi4izzx9qs27zTh8/sCBMA tvrcVW5tx1GKV5Wthioo =M2lH -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Project enquiry/interest
Hi Marcus, Thanks again for the detailed explanation of current access technologies. As discussed current scheme allows shared access of the channels in time, frequency, and space. What I am talking is about a full simultaneous parallel use or access of channel. This is kind of necessity as wireless bandwidth demands are ever growing and we are hitting spectrum scarcity. The scheme I am discussing is close to CDMA/MIMO. CDMA base stations already differentiate handsets using same frequency with signature sequences. Implementing a similar approach on the handset side also to differentiate base stations or similar approaches can be in place. In its simplest form the requirement is to allow 2 FM stations using same frequency in a location area. And the receivers tune to the station names to enjoy different music rather than just to the frequency ! Nothing new as a concept, limitations to achieve this reasons we have all the existing implementations, but 100s of years of engineering fineness. Now this should be possible with soft transceivers using today's digital radio techniques combined with soft techniques... Thanks and Regards, Sajeev Manikkoth -Original Message- From: Marcus Müller [mailto:marcus.muel...@ettus.com] Sent: 22 February 2015 23:26 To: Sajeev Manikkoth; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Project enquiry/interest Hi Sajeev, On 02/22/2015 05:37 PM, Sajeev Manikkoth wrote: Hi Marcus, Thanks for your input and as suggested I can check on the GNU radio presentations. As far as I know none of the current wireless access technologies allow simultaneous transmissions on same channel. Um, being access technologies, that's actually exactly what they do, and why they're existing. Simultaneous is kind of a difficult term, and of course TDMA systems like GSM allow different people to use the same channel at the same time only from a higher-up point of view; functionally, the same channel is shared simultaneously. Same Channel is yet another difficult term, but for example in the context of GSM, the same channel estimate applies to successive access by different users to the same subchannel, which is, from a information theoretical perspective, what I'd call accessing the same channel. There are various different FDMA schemes, which allow parallel access to the spectrum (think the OFDM-based LTE, where you as a user are assigned resource blocks), and of course, CDMA systems share the same time-frequency ranges without interfering; that's what they use codes for. And we do all form of frequency planning and interference avoidance schemes offline and deploy wireless solutions. And that is a must, no matter what you'll do technically, because being absolutely synchronous and knowing the channel exactly would be the only alternative to that. You might want to read up on stuff like inter-symbol-interference and why you can't allow unlimited interference power in any channel, no matter how good your system becomes at handling that (channel capacity). I was looking for research interests on new PHY and MAC layer techniques which can allow 2 or more transmitters at the same location to use same frequency, but receivers being capable of turning to the desired transmitters. What you describe applies to things like CDMA, and basically any form of MIMO. These are not new research, though, since CDMA has at least been in use/development since the mid-1950s (cold war) and is used in many mobile phone standards (2G: IS-95, 3G: UMTS, CDMA2000 etc), and GPS. MIMO is a umbrella term for systems that use a single channel with multiple observers and signal producers (e.g., antennas): It's wide-spread in many access technologies (WiFi, WiMax, LTE, but even stuff like home-network powerline standards) and allows for the creation of multiple let's say virtual channels over one medium. Best regards, Marcus Müller ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
