[Discuss-gnuradio] Idea of a USRP UHD block that fills gaps in transmission from USRP
Hi all, Interruptions transmission over Gigabit Ethernet when receiving samples from USRP can happen at highest data rates no matter how many tricks you use with your network card (I have experience with N200/N210). The loss of part of the signal results with synchronization loss in data transmission systems. There is possibility to handle this problem by catching rx_time stream tags. But there might be a solution to keep synchronization that might work quite well with gr-blocks that don't handle stream tags. What if USRP UHD Source gave user an option to fill all of the gaps in signal with exact number of lost samples (for example with zeros). Additionally it could produce stream tags with position and length of each gap so it would be easy to store a file with continuous signal stream paired with a file containing metadata describing where and for how long the signal samples were lost. Is it possible to do exactly what I'm describing with current gnuradio blocks? In my case it would often make many things I do easier. -- Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] psk mod and channel model
On Sat, Feb 8, 2014 at 11:32 AM, Marco Bosco wrote: > Hi! > > I am trying to do a simple simulation in GRC: > > Signal source --> Packet encoder --> PSK mod --> Channel model --> PSK demod > --> Packet decoder --> Scope sink > > The problem is that it works only if I enable differential encoding. How can > I make it works without using a differential encoding? (I don't want to > remove the channel model) > > Thanks, > > Marco. Non-differential PSK has phase ambiguities, so you need to properly rotate the constellation so that the receiver can properly decode the symbols to the correct bits. Differential allows us to avoid dealing with this ambiguity. You'll need something in the receiver that can detect the rotation after the receiver locks and correct that. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] pfb_decimator_ccf(13): insufficient connected input ports (5 needed, 1 connected)
Hi, all I try to re-structure the osmo-tetra to work with GNU Radio 3.7. The osmo-tetra is based on GNU Radio 3.6. The original code has tuner, resampler, demodulater three modules which connected sequentially. The resampler is based on function pfb_decimator_ccf which changes from 3.6 to 3.7. The pfb_decimator_ccf only take single parameter decimation, which changes in 3.7, After reading the manual of 3.7, I made following changes to the python script : Add a low-pass filter " taps = filter.firdes.low_pass_2(1, fs, options.low_pass, options.low_pass * 0.2, attenuation_dB=ATT, window=filter.firdes.WIN_BLACKMAN_hARRIS) " Change "self.resamp = blks2.pfb_decimator_ccf(int(rerate)) " to " self.resamp = filter.pfb_decimator.ccf(int(rerate), taps, 0) " But error still occurs when connecting modules " self.connect(self.src, self.tuner, self.resamp, self.demod, self.output) " : Traceback (most recent call last): File "./osmosdr-tetra_demod_fft.py", line 264, in tb.Run(True) File "/usr/local/lib/python2.7/dist-packages/grc_gnuradio/wxgui/top_block_gui.py", line 82, in Run self.Start(start, max_nouts) File "/usr/local/lib/python2.7/dist-packages/grc_gnuradio/wxgui/top_block_gui.py", line 73, in Start self.start() File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 103, in start top_block_start_unlocked(self._tb, max_noutput_items) File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line 4612, in top_block_start_unlocked return _runtime_swig.top_block_start_unlocked(*args, **kwargs) RuntimeError: pfb_decimator_ccf(13): insufficient connected input ports (5 needed, 1 connected) Does it indicate pfb_decimator_ccf take 5 inputs ? It puzzled me. Best Regards, Jiang Pin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] buffer taps
Dear sir I want to implement a buffer. How can I do it? Can I use taps. I wrote it as a queue. first queue.push(); then take queue.front() to remove queue.pop() But i create a segmentation fault (core dumped) Can you explain why? And how to implement queue in a c++ processing block Thanks Neil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_modtool makexml bugs
On 08.02.2014 23:38, Activecat wrote:
Dear guru,
This happens intermittently. Is this a bug?
Probably. That said, makexml is the most tricky part of modtool. This
might be triggered by invalid code, although the error message suggests
otherwise.
Can you please post GNU Radio version, the include file and the _impl.cc
file that triggers this.
MB
Command: gr_modtool makexml integer_sink2
Output: as below
Regards,
activecat
$ gr_modtool makexml integer_sink2
GNU Radio module name identified: activecat
Warning: This is an experimental feature. Don't expect any magic.
Searching for matching files in lib/:
Making GRC bindings for lib/integer_sink2_impl.cc...
Traceback (most recent call last):
File "/usr/local/bin/gr_modtool", line 41, in
main()
File "/usr/local/bin/gr_modtool", line 37, in main
modtool.run()
File
"/usr/local/lib/python2.7/dist-packages/gnuradio/modtool/modtool_makexml.py",
line 66, in run
(params, iosig, blockname) = self._parse_cc_h(f)
File
"/usr/local/lib/python2.7/dist-packages/gnuradio/modtool/modtool_makexml.py",
line 157, in _parse_cc_h
return (parser.read_params(), parser.read_io_signature(), blockname)
File
"/usr/local/lib/python2.7/dist-packages/gnuradio/modtool/parser_cc_block.py",
line 82, in read_io_signature
iosig_match.group('intype'))
File
"/usr/local/lib/python2.7/dist-packages/gnuradio/modtool/parser_cc_block.py",
line 47, in _figure_out_iotype_and_vlen
return {'type': [_typestr_to_iotype(x) for x in typestr.split(',')],
File
"/usr/local/lib/python2.7/dist-packages/gnuradio/modtool/parser_cc_block.py",
line 55, in _typestr_to_iotype
return self.type_trans(type_match.group(1))
File
"/usr/local/lib/python2.7/dist-packages/gnuradio/modtool/modtool_makexml.py",
line 132, in _type_translate
if p_type in ('int',) and default_v[:2].lower() == '0x':
TypeError: 'NoneType' object has no attribute '__getitem__'
___
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] buffer taps
On 09.02.2014 08:37, MHMND Herath wrote: Dear sir I want to implement a buffer. How can I do it? Can I use taps. I wrote it as a queue. first queue.push(); then take queue.front() to remove queue.pop() But i create a segmentation fault (core dumped) Can you explain why? And how to implement queue in a c++ processing block Neil, please read http://gnuradio.org/redmine/projects/gnuradio/wiki/ReportingErrors. When you have, re-state your question with all the necessary specifics so we can help you, as it is, it's hard to figure out what you actually are trying to do. MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] pfb_decimator_ccf(13): insufficient connected input ports (5 needed, 1 connected)
On 09.02.2014 07:39, JIANG Pin A wrote: Hi, all I try to re-structure the osmo-tetra to work with GNU Radio 3.7. The osmo-tetra is based on GNU Radio 3.6. OK, don't know about osmo-tetra but... RuntimeError: pfb_decimator_ccf(13): insufficient connected input ports (5 needed, 1 connected) Does it indicate pfb_decimator_ccf take 5 inputs ? It puzzled me. ...the pfb_decimator takes 1 input. Not sure what's going on there. MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] time interval
Hi all! I have the following flowgraph with a sample rate = 32k : Random source --> Throttle --> uchar to float --> scope sink If a zoom in the plot I can see that the time interval between each sample is 40 us. How can I compute this value? Marco. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Issue with Arch Linux build of gnuradio
*Traceback (most recent call last): File "/home/ushio/top_block.py", line 13, in from grc_gnuradio import wxgui as grc_wxguiImportError: cannot import name wxgui* So, I have been using a downgraded version of GNURadio for some time to prototype, but now would like to use it for the BladeRF. Problem is though, the upstream version of gnuradio in the Arch repo seems to have an issue with wxgui. I am not the only one who has dealt with it, there is a bug report here. Any ideas on how to patch this? Bug: https://bugs.archlinux.org/task/38293?project=5&cat[0]=33&string=gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] QT GUI Frequency Sink CPU usage
The CPU usage of the QT GUI Frequency Sink is much higher than the QT GUI Sink. I made a test flow graph with a noise source, throttle, and QT GUI Sink using default parameters. I am running GNU Radio version 3.7.0, Xubuntu 13.10, on a MacBook with 2.4 Ghz Intel dual core CPU. QT GUI Frequency Sink CPU usage python: 43% xorg: 58% QT GUI Sink CPU usage python: 5% xorg: 9% Could this be a bug? Regards, Jim Larsen -- View this message in context: http://gnuradio.4.n7.nabble.com/QT-GUI-Frequency-Sink-CPU-usage-tp46251.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] gr_modtool makexml bugs
Dear Martin,
Let's refer related files as attached, thanks.
List of attached files:
integer_source.h
integer_source_impl.h
integer_source_impl.cc
error_message (text file)
Regards,
activecat
On Mon, Feb 10, 2014 at 1:19 AM, Martin Braun wrote:
> On 08.02.2014 23:38, Activecat wrote:
>
>> Dear guru,
>> This happens intermittently. Is this a bug?
>>
>
> Probably. That said, makexml is the most tricky part of modtool. This
> might be triggered by invalid code, although the error message suggests
> otherwise.
>
> Can you please post GNU Radio version, the include file and the _impl.cc
> file that triggers this.
>
> MB
>
> Command: gr_modtool makexml integer_sink2
>> Output: as below
>>
>> Regards,
>> activecat
>>
>>
>> $ gr_modtool makexml integer_sink2
>> GNU Radio module name identified: activecat
>> Warning: This is an experimental feature. Don't expect any magic.
>> Searching for matching files in lib/:
>> Making GRC bindings for lib/integer_sink2_impl.cc...
>> Traceback (most recent call last):
>>File "/usr/local/bin/gr_modtool", line 41, in
>> main()
>>File "/usr/local/bin/gr_modtool", line 37, in main
>> modtool.run()
>>File
>> "/usr/local/lib/python2.7/dist-packages/gnuradio/
>> modtool/modtool_makexml.py",
>> line 66, in run
>> (params, iosig, blockname) = self._parse_cc_h(f)
>>File
>> "/usr/local/lib/python2.7/dist-packages/gnuradio/
>> modtool/modtool_makexml.py",
>> line 157, in _parse_cc_h
>> return (parser.read_params(), parser.read_io_signature(), blockname)
>>File
>> "/usr/local/lib/python2.7/dist-packages/gnuradio/
>> modtool/parser_cc_block.py",
>> line 82, in read_io_signature
>> iosig_match.group('intype'))
>>File
>> "/usr/local/lib/python2.7/dist-packages/gnuradio/
>> modtool/parser_cc_block.py",
>> line 47, in _figure_out_iotype_and_vlen
>> return {'type': [_typestr_to_iotype(x) for x in typestr.split(',')],
>>File
>> "/usr/local/lib/python2.7/dist-packages/gnuradio/
>> modtool/parser_cc_block.py",
>> line 55, in _typestr_to_iotype
>> return self.type_trans(type_match.group(1))
>>File
>> "/usr/local/lib/python2.7/dist-packages/gnuradio/
>> modtool/modtool_makexml.py",
>> line 132, in _type_translate
>> if p_type in ('int',) and default_v[:2].lower() == '0x':
>> TypeError: 'NoneType' object has no attribute '__getitem__'
>>
>>
>>
>> ___
>> 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
>
error_message
Description: Binary data
/* -*- c++ -*- */
#ifndef INCLUDED_ACTIVECAT_INTEGER_SOURCE_H
#define INCLUDED_ACTIVECAT_INTEGER_SOURCE_H
#include
#include
namespace gr {
namespace activecat {
class ACTIVECAT_API integer_source : virtual public gr::sync_block
{
public:
typedef boost::shared_ptr sptr;
static sptr make( const std::vector &data, bool repeat, int times );
};
} // namespace activecat
} // namespace gr
#endif /* INCLUDED_ACTIVECAT_INTEGER_SOURCE_H */
/* -*- c++ -*- */
#ifndef INCLUDED_ACTIVECAT_INTEGER_SOURCE_IMPL_H
#define INCLUDED_ACTIVECAT_INTEGER_SOURCE_IMPL_H
#include
namespace gr {
namespace activecat {
class integer_source_impl : public integer_source
{
private:
const std::vector d_data;
bool d_repeat;
int d_times;
int d_counter1, d_counter2;
public:
integer_source_impl(const std::vector &data, bool repeat, int times);
~integer_source_impl();
int work(int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items);
};
} // namespace activecat
} // namespace gr
#endif /* INCLUDED_ACTIVECAT_INTEGER_SOURCE_IMPL_H */
/* -*- c++ -*- */
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include
#include "integer_source_impl.h"
namespace gr {
namespace activecat {
integer_source::sptr
integer_source::make(const std::vector &data, bool repeat, int times)
{
return gnuradio::get_initial_sptr
(new integer_source_impl(data, repeat, times));
}
// constructor
integer_source_impl::integer_source_impl(const std::vector &data, bool repeat, int times)
: gr::sync_block("integer_source",
gr::io_signature::make(0, 0, 0),
gr::io_signature::make( 1, 1, sizeof(int) )),
d_data( data ),
d_repeat( repeat ),
d_times( times ),
d_counter1( 0 ),
d_counter2( 0 )
{ }
// destructor
integer_source_impl::~integer_source_impl()
{ }
// d_counter1: counts the number of round the &data array has repeated.
// d_counter2: counts the n-th element of the &data array
int
integer_source_impl::work(i
Re: [Discuss-gnuradio] UHD stream tagging
On 02/08/2014 02:37 PM, Price, Nathan D. (S&T-Student) wrote: Hello, I'm working on project in gnuradio, in which I'm trying to toggle on and off the transmission from the USRP. After much research, I learned this was done by tagging the first sample of a transmission with "tx_sob" and the last sample with "tx_eob" (there was also a "tx_time" tag, but I found the former option more convenient). I wrote a custom block that periodically tags segments out of continuous stream of data as a proof of concept; however, the transmission remains continuous as if there were no tag. I've checked with the tag debugging block to ensure my block acutally generates tags. My flow graph is simply: file source(repeat)->custom tagging block->psk mod->multiply const->uhd sink. Reading in the archive, I haven't found reference to success much success with the streaming API. I would love the community's input on this problem. Thanks, Nathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio The basic issue is that TX_EOB doesn't mean what you think it means -- it's mostly just a way to let the hardware know not to expect any more samples. In particular, it doesn't cause the TX synthesizer to shut-down because many folks what phase-continuity across multiple bursts, so the synthesizer is left running, and if you have non-zero samples still flowing after TX_EOB, there'll still be stuff coming out the TX port. The main "disconnect" is that GNu Radio is a streaming architecture, and UHD supports that, but also supports a much-richer interaction model that doesn't really fit "perfectly" with Gnu Radio, so gr-uhd does the best job it can. Many folks who want to do stuff with UHD that doesn't fit the Gnu Radio model use UHD directly (a significant fraction of Ettus customers do things this way). While UHD has "grown up" alongside Gnu Radio, its architecture and interaction model aren't necessarily a "fits like a glove" thing. I'd suggest looking at the tx_bursts.cpp example in the UHD examples to see how bursts are managed. In particular, the hardware itself can't really "know" what your channel access model is, so it's up to you to crank the TX gain down to zero, and stop sending samples after a TX_EOB, if that's what you want to happen. Something that I recall getting discussed (and perhaps Martin can chime in here, since I think gr-uhd is you baby now :) ) was to have gr-uhd start dropping incoming samples on the floor when it receives a TX_EOB tag, and go into a "waiting for further instructions" mode, in particular perhaps waiting for a TX_SOB. But in concert with that the app really needs to crank down the TX gain, and insert zeros if it isn't going to stop sending samples. This can be hard to orchestrate within the confines of GRC, but in the full-fledged expressiveness of the Python or C++ APIs to Gnu Radio, it should be fairly easy. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Why does Airprobe no longer work with current GNU Radio?
Hi all, I'm new here to use GNU Radio. And I'm trying to decode GSM signal with airprobe. In GSoC page of GNU Radio, I found these words: "It no longer works with current GNU Radio versions, and doesn't make use of any of the new GNU Radio features." What are the detailed reasons? Moreover, what are the new features? Best wishes, Zhenhua HAN ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Why does Airprobe no longer work with current GNU Radio?
On 02/09/2014 09:11 PM, zhenhua han wrote: Hi all, I'm new here to use GNU Radio. And I'm trying to decode GSM signal with airprobe. In GSoC page of GNU Radio, I found these words: "It no longer works with current GNU Radio versions, and doesn't make use of any of the new GNU Radio features." What are the detailed reasons? Moreover, what are the new features? Best wishes, Zhenhua HAN ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio The Gnu Radio API changed between 3.6.5.1 and 3.7.0 http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7 Since very few of us here know exactly which features are used by gr-airprobe, it's hard to say which new features it might be avoiding using... -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Why does Airprobe no longer work with current GNU Radio?
Hi, I met the same problem with airprobe and GNU Radio 3.7. I think it’s due to GNU Radio 3.7 is restructured, which leads the airprobe no longer work with GNU radio. You may try GNU Radio 3.6 series. For changes and new features in 3.7, you can check the release note. Best Regards, Jiang Pin From: discuss-gnuradio-bounces+pin.a.jiang=alcatel-sbell.com...@gnu.org [mailto:discuss-gnuradio-bounces+pin.a.jiang=alcatel-sbell.com...@gnu.org] On Behalf Of zhenhua han Sent: 2014年2月10日 10:12 To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Why does Airprobe no longer work with current GNU Radio? Hi all, I'm new here to use GNU Radio. And I'm trying to decode GSM signal with airprobe. In GSoC page of GNU Radio, I found these words: "It no longer works with current GNU Radio versions, and doesn't make use of any of the new GNU Radio features." What are the detailed reasons? Moreover, what are the new features? Best wishes, Zhenhua HAN ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] time interval
On 09.02.2014 12:28, Marco Bosco wrote: Hi all! I have the following flowgraph with a sample rate = 32k : Random source --> Throttle --> uchar to float --> scope sink If a zoom in the plot I can see that the time interval between each sample is 40 us. How can I compute this value? Time between samples is 1./sampling rate. 1/32k=31.25us, the sink probably has ticks at even intervals. MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
