Re: GrRangeWidget is buggy
Dear All,
This is the commit that introduced the line "self.${id} = ${win}" which I
think is the main cause of the bug. I wonder if that was intentional or a
simple mistake.
https://github.com/gnuradio/gnuradio/commit/0427b2a6781a08cc57d82b27fbdd9a2300a34919
Best,
Miklos
On Mon, Sep 5, 2022 at 8:31 PM Miklos Maroti wrote:
> Hi All,
>
> If you use the value of the range widget in an expression for a callback,
> then you get the error:
>
> TypeError: unsupported operand type(s) for +: 'float' and 'GrRangeWidget'
>
> I have tested this for the maint 3.10 branch, but the relevant files are
> unchanged in the master branch. I have attached a simple flowgraph where we
> have two range widgets, one noise source and one frequency sink. The
> amplitude of the noise source is the sum of the two range widget values. If
> you change any of the widgets, then the flowgraph crashes with the above
> error.
>
> I am not sure why this is happening, any help would be appreciated. One
> workaround which seems to help if I uncomment the "self.${id} = ${win}"
> line in the grc yml file.
>
> Best,
> Miklos
>
GrRangeWidget is buggy
Hi All,
If you use the value of the range widget in an expression for a callback,
then you get the error:
TypeError: unsupported operand type(s) for +: 'float' and 'GrRangeWidget'
I have tested this for the maint 3.10 branch, but the relevant files are
unchanged in the master branch. I have attached a simple flowgraph where we
have two range widgets, one noise source and one frequency sink. The
amplitude of the noise source is the sum of the two range widget values. If
you change any of the widgets, then the flowgraph crashes with the above
error.
I am not sure why this is happening, any help would be appreciated. One
workaround which seems to help if I uncomment the "self.${id} = ${win}"
line in the grc yml file.
Best,
Miklos
test_gr_range_widget.grc
Description: application/gnuradio-grc
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
#
# SPDX-License-Identifier: GPL-3.0
#
# GNU Radio Python Flow Graph
# Title: Not titled yet
# GNU Radio version: 3.10.3.0
from packaging.version import Version as StrictVersion
if __name__ == '__main__':
import ctypes
import sys
if sys.platform.startswith('linux'):
try:
x11 = ctypes.cdll.LoadLibrary('libX11.so')
x11.XInitThreads()
except:
print("Warning: failed to XInitThreads()")
from PyQt5 import Qt
from gnuradio import qtgui
from gnuradio.filter import firdes
import sip
from gnuradio import analog
from gnuradio import blocks
from gnuradio import gr
from gnuradio.fft import window
import sys
import signal
from argparse import ArgumentParser
from gnuradio.eng_arg import eng_float, intx
from gnuradio import eng_notation
from gnuradio.qtgui import Range, GrRangeWidget
from PyQt5 import QtCore
from gnuradio import qtgui
class test_gr_range_widget(gr.top_block, Qt.QWidget):
def __init__(self):
gr.top_block.__init__(self, "Not titled yet", catch_exceptions=True)
Qt.QWidget.__init__(self)
self.setWindowTitle("Not titled yet")
qtgui.util.check_set_qss()
try:
self.setWindowIcon(Qt.QIcon.fromTheme('gnuradio-grc'))
except:
pass
self.top_scroll_layout = Qt.QVBoxLayout()
self.setLayout(self.top_scroll_layout)
self.top_scroll = Qt.QScrollArea()
self.top_scroll.setFrameStyle(Qt.QFrame.NoFrame)
self.top_scroll_layout.addWidget(self.top_scroll)
self.top_scroll.setWidgetResizable(True)
self.top_widget = Qt.QWidget()
self.top_scroll.setWidget(self.top_widget)
self.top_layout = Qt.QVBoxLayout(self.top_widget)
self.top_grid_layout = Qt.QGridLayout()
self.top_layout.addLayout(self.top_grid_layout)
self.settings = Qt.QSettings("GNU Radio", "test_gr_range_widget")
try:
if StrictVersion(Qt.qVersion()) < StrictVersion("5.0.0"):
self.restoreGeometry(self.settings.value("geometry").toByteArray())
else:
self.restoreGeometry(self.settings.value("geometry"))
except:
pass
##
# Variables
##
self.value2 = value2 = 50
self.value1 = value1 = 50
self.samp_rate = samp_rate = 32000
##
# Blocks
##
self._value2_range = Range(0, 100, 1, 50, 200)
self._value2_win = GrRangeWidget(self._value2_range, self.set_value2, "'value2'", "counter_slider", float, QtCore.Qt.Horizontal, "value")
self.value2 = self._value2_win
self.top_layout.addWidget(self._value2_win)
self._value1_range = Range(0, 100, 1, 50, 200)
self._value1_win = GrRangeWidget(self._value1_range, self.set_value1, "'value1'", "counter_slider", float, QtCore.Qt.Horizontal, "value")
self.value1 = self._value1_win
self.top_layout.addWidget(self._value1_win)
self.qtgui_freq_sink_x_0 = qtgui.freq_sink_c(
1024, #size
window.WIN_BLACKMAN_hARRIS, #wintype
0, #fc
samp_rate, #bw
"", #name
1,
None # parent
)
self.qtgui_freq_sink_x_0.set_update_time(0.10)
self.qtgui_freq_sink_x_0.set_y_axis((-140), 10)
self.qtgui_freq_sink_x_0.set_y_label('Relative Gain', 'dB')
self.qtgui_freq_sink_x_0.set_trigger_mode(qtgui.TRIG_MODE_FREE, 0.0, 0, "")
self.qtgui_freq_sink_x_0.enable_autoscale(False)
self.qtgui_freq_sink_x_0.enable_grid(False)
self.qtgui_freq_sink_x_0.set_fft_average(1.0)
self.qtgui_freq_sink_x_0.enable_axis_labels(True)
self.qtgui_freq_sink_x_0.enable_control_panel(False)
self.qtgui_freq_sink_x_0.set_fft_window_normalized(False)
labels = ['', '', '', '', '',
'', '', '', '', '']
widths = [1, 1, 1, 1, 1,
Re: QA python code uses installed python and c++ library
Hi Vasil, Thanks for the quick reply. Indeed, it is related to that issue, and make test does not work without installing it first. However, the linked fixes did not work for me, and I think the reason is that in GNURadio 3.10 changes the module located to test_modules/gnuradio/modulename from test_modules/modulename. 1. Gnuradio 3.10 uses "from gnuradio.modulename import xyz" (and 3.9 seems to use "from modulename import xyz") 2. Once "from gnuradio import gr" is executed prior to that, then the gnuradio library is loaded, and even if we update the sys.path the "from gnuradio.modulename import xyz" will use the path of the gnuradio module to look up the OOT submodule, and it will never find the test_modules directory. In the end I could not find any other solution than reverting back to the "testmodules/modulename" output directory in cmake, and using "import modulename" inside the QA code. So I am sceptical whether it is possible to run make test for a gnuradio 3.10 OOT module without installing it. Best, Miklos On Wed, Mar 2, 2022 at 1:26 AM Vasil Velichkov wrote: > Hi Milkos, > > Your problem seems related to [1]. Make sure your gnuradio version does > include the fix from [2] and your OOT CMakeLists.txt contains [3] > > [1] https://github.com/gnuradio/gnuradio/issues/4825 > [2] https://github.com/gnuradio/gnuradio/pull/5279 > [3] > https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide#CMakeLists.txt_changes_to_fix_OOT_module_testing > > Regards, > Vasil > > On 02/03/2022 05.19, Miklos Maroti wrote: > > Dear All, > > > > I have a GNURadio 3.10 OOT module which has C++ blocks and python QA > code. > > During my development I do the following steps: > > > > 1. make > > 2. make test > > 3. make install > > 4. change c++ files > > 5. make > > 6. make test > > > > At the last step the python QA code will link the already installed > python > > library and not the latest one within the build folder. The QA code > should > > link the latest python and c++ libraries from the build directory, and > > there should be no "smartness" (except ImportError) in the QA boilerplate > > code. > > > > I have tried to trick python3 by changing the sys.path prior to the > import > > statement, but this fails. Somehow once you have imported gnuradio from > the > > stock include path, then changing the sys.path even to the empty list > will > > not prevent the loading of the installed OOT module. > > > > Has anyone seen this behaviour? Is there a workaround? > > > > Best, > > Miklos > > > >
QA python code uses installed python and c++ library
Dear All, I have a GNURadio 3.10 OOT module which has C++ blocks and python QA code. During my development I do the following steps: 1. make 2. make test 3. make install 4. change c++ files 5. make 6. make test At the last step the python QA code will link the already installed python library and not the latest one within the build folder. The QA code should link the latest python and c++ libraries from the build directory, and there should be no "smartness" (except ImportError) in the QA boilerplate code. I have tried to trick python3 by changing the sys.path prior to the import statement, but this fails. Somehow once you have imported gnuradio from the stock include path, then changing the sys.path even to the empty list will not prevent the loading of the installed OOT module. Has anyone seen this behaviour? Is there a workaround? Best, Miklos
Re: Mac Layer
Hi Nick, You can take a look at the https://gitlab.com/marmote/gr-marmote3 repo as well. That has a custom waveform and custom MAC but it is a full fledged solution. The bare essentials (real time part) are kept in gnuradio, the rest is controlled from python using protocol buffers. Low latency buffer management is hard, but not impossible. Best, Miklos On Fri, Jun 11, 2021 at 10:42 PM Marcus Müller wrote: > Hi Nick, > > On 11.06.21 16:58, Nicholas Long wrote: > > Hi, so I have been wondering what people do to implement mac layer type > things with GNURadio? > > (for example automatic detection/handshaking type protocols before > transmitting digital > > data packets.) > > Well, "we" (as in the community) have Basti Bloessl's gr-ieee802-11 > project as an example > on how to approach that. > > > From my perspective gnuradio is good for physical layer development, but > less so for state > > machine type work of mac layer... > > Well, yes. Kind of. > GNU Radio definitely is a physical layer thing. It doesn't give you any > tools to develop > MA controllers. > But: MACs are different. Pretty different, in fact. As you say, the common > denominator is > "there's one or more state machines"; from there up, it's pretty variable. > > Now, what GNU Radio *does* give you is a flexible architecture to > implement your physical > receiver and transmitter, and a mechanism with which you can interchange > messages with a > controller. I think (and I'm not alone with that, there's work ongoing on > new concepts in > that space!) that we could do a bit better on the usefulness of that > messaging system, but > it does work. > > I think GNU Radio Companion as the visible front of the whole GNU Radio > idea establishes > the impression that GNU Radio is a generator for stand-alone > *applications*; it's not. GNU > Radio is a library, and the things you can create with it are *meant* to > be used as the > signal processing side of other applications. Look at the success gqrx > has: It uses GNU > Radio underneath, but none of its visualization blocks; satellite ground > stations, video > transceivers, radiosonde receivers, emergency beacons and a myriad of > other very > real-world applications are underpinned by GNU Radio. DARPA's spectrum > challenge gave > teams a development kit based on GNU Radio as a starting point, and its > whole point was to > demonstrate the ability to react to sudden interference and user > constellation changes. > > All these things use different approaches, clearly. There's good reason to > assume the > project "should" have a goto MAC demo – but we don't. Too much to fiddle, > probably. > > Best regards, > Marcus > >
delete_head_blocking replacement for 3.8
Dear All, What is the proper replacement code for the delete_head_blocking function that was removed in gnuradio 3.8? I see that in pdu_to_tagged_stream simply using delete_head_nowait is used with checking for NULL and returning 0 in the work function. Will the block scheduler run this code in a busy loop? Best, Miklos
Re: Help with cubesats
Hi Andrew, Shameless plug, but you can take a look at this repo https://gitlab.com/phorvath/smogcli2 to record samples with RTL-SDR and Raspberry PI. It is developed for the ATL-1 and SMOG-P satellites. It is a standalone application, samples at 1.6 or 2.0 maps, tracks the location of the satellite and starts recording if the elevation is above -2 degrees. When it is recording it compensates for Doppler and then downsamples to 50 ksps (or 62.2 ksps). You can process your recordings with gr-satellites or a GNURadio flow graph.. Miklos On Sun, Feb 16, 2020 at 3:00 AM Andrew Stamp wrote: > > Hi, > > I’m looking for assistance with setting up a raspberry pi, with Direwolf and > gr-satellites, to receive and decode from the Phoenix cubesats being deployed > on February 17. Specifically, they will be ax.25, using GMSK. Is it possible > to use a raspberry pi to record the audio, and record the waterfall? I was > hoping to make this a stand-alone unit that I can upload the information when > available. It is a raspberry pi 3 b, with an RTL-SDR dongle. I don’t have a > screen on it. I am still very new, I have set up a couple raspberry pi’s with > Direwolf, and have set up a Windows 7 netbook for RX WSPR. I would really > appreciate any help. > > Thank you, > > -Andy, N2YQO
Re: FBMC
Hi! Indeed. Take a look at the polyphase_chan_filter and polyphase_synt_filter files. The MarmotE FBMC implementation is special in a way that the sample rate of the subcarriers can be different than the overall sampling rate divided by the number of channels. Cheers, Miklos On Sun, Feb 2, 2020 at 5:03 PM Brian Padalino wrote: > > On Sun, Feb 2, 2020 at 10:40 AM Madhan TJ wrote: >> >> CAN WE IMPLEMENT FBMC (filter bank multi carrier ) IN GNU RADIO , >> IF YES, >> ANYONE PLEASE HELP ME > > > I believe the MarmotE team from the DARPA SC2 used FBMC in their modem that > they open sourced: > > https://marmote.io/ > https://gitlab.com/marmote/gr-marmote3 > > Brian
[Discuss-gnuradio] DARPA SC2 Team MarmotE modem is open sourced
Dear Fellow GNURadio Users, We are happy to announce that we are open sourcing the MarmotE modem that we have developed for the DARPA Spectrum Collaboration Challenge under the GPLv3 license at https://gitlab.com/marmote/gr-marmote3. This is an FBMC based modem capable of using up to 40MHz of bandwidth with a good computer, but can be used with a simple laptop with lower sampling rates. There might be a few rough edges in the code base specifically tailored for the Colosseum and SC2 challenge, but we have created a simplified version of the modem that works with any USRP or other SDR. The code base has lots of interesting components, including good error correcting codes, SSE optimized fractional FBMC channelizer and synthesizer, variable length packets, multiple MCS settings, ARQ, TCP/UDP port based QoS settings, etc. We plan to write a manual, but till then enjoy the short README, the raw code and the flow graphs. Finally, please cheer for Team MarmotE on the DARPA SC2 championship event at MWC Los Angeles 2019, October 23. Best, Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [GREP] Separate scheduler and GNU Radio base files
Dear Martin, I have been looking at the GNURadio scheduler quite a bit recently and would like to summarize my experiences that could affect the direction of this GREP. As you have properly observed, the scheduler is very hard to change as it is, but there are new opportunities if we allow changes. There are two components: scheduler itself (the scheduler_tpb and tpb_thread_body) and the block executor. I think both needs some attention, but it is not clear if you want to address only the scheduler itself or together with the executor. - For the scheduler I would really like to introduce a type of scheduler that manages only a subset of blocks for minimizing latency by draining internal buffers within this group of block before new data is accepted into these blocks. Think of a long sequence of blocks processing packets that we would like to perform one after the other without bringing all that functionality into a single block. Maybe the flow graph need not be flattened completely, but certain hierarchical blocks could be managed by their own scheduler (so flattened into a level 1 hierarchy). Maybe the single threaded scheduler is just a special case of this. - Certain tasks, such as combining packets into frames, might need to know if future packets are arriving. This can be accomplished with a timeout, so the block would be notified to flush its internal buffers if the work function has not been called for a predefined time. There is no such functionality within the current scheduler and I think it would be possible to implement one by exposing the timeout used within tpb_thread_body. - The block executor is also a very complex beast. I am wondering why the functionality of the executor not implemented within the basic_block where it could be overloaded. Hope this starts the discussion and others can voice their opinion. Best, Miklos On Thu, Dec 27, 2018 at 10:58 PM Martin Braun wrote: > > Hi all, > > final GREP of the day: > https://github.com/gnuradio/greps/blob/master/grep-0016-separate-scheduler.md > > This is possible the most fundamental and influential GREPs that were added > so far. I would find it hard to find any reasons not to do this -- of course, > the question remains, who will do it. Any takers? I'm hoping that by > separating scheduler from base, we can open up the avenue for more and better > research into scheduling, as well as custom scheduler development. > > Discuss! > > -- Martin > ___ > 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] stop/start is not called in gr.basic_block
Hi Bastian, Thanks that solved the issue. I was not aware of that. Best, Miklos On Thu, Oct 5, 2017 at 2:29 AM, Bastian Bloessl wrote: > Hi, > > On 10/05/2017 03:13 AM, Miklos Maroti wrote: >> >> I am trying to implement a simple block in python but it seems that >> stop and start is never called when I implement them. The bare bones >> python code would be this: >> >> class test(gr.basic_class): >> def __init__(self): >> gr.basic_block.__init__(self, name="test", in_sig=None, >> out_sig=None) >> >> def start(self): >> print "never called" >> return gr.basic_block.start(self) >> >> The same works in C++. I could not find any example that implements >> start/stp in python, but looking at the docs for gr.basic_block it >> should work. Any ideas? > > > AFAIK, if the block is not connected to any other block, it is not handled > by the flow graph/scheduler. > If you don't actually have a use-case for a completely separate block, you > could try adding a stream or message port an connect it. > > Best, > Bastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] stop/start is not called in gr.basic_block
Hi Guys, I am trying to implement a simple block in python but it seems that stop and start is never called when I implement them. The bare bones python code would be this: class test(gr.basic_class): def __init__(self): gr.basic_block.__init__(self, name="test", in_sig=None, out_sig=None) def start(self): print "never called" return gr.basic_block.start(self) The same works in C++. I could not find any example that implements start/stp in python, but looking at the docs for gr.basic_block it should work. Any ideas? Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] cppunit not displaying any messages
Hi All, I am not that familiar with cppunit, but my understanding is that it should print out a message when CPPUNIT_ASSERT or CPPUNIT_ASSERT_MESSAGE failes. I have deliberately added failures, and indeed the test fails with ctest but no output is produced. I am using "ctest -VV". I am getting all outputs from python based QA errors. Does anyone know why this is happening? Best, Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tagged stream interleaver, scheduler and forecast
Hi Guys, On a related note: I am hacking, and seem to loose items when the flowgraph is emptying of data. I have block A producing a single output, and block B consuming that single input, and it seems that when block B is finished (say returns WORK_DONE, or sleeping in its work thread) then I can see that it has produced 10 elements in nitems_written, but on the consumer those elements will not appear in nitems_read, and run out earlier randomly. What could cause behavior? It is no fun debugging the my program and the scheduler with printf... Miklos On Sun, Aug 6, 2017 at 1:37 PM, Miklos Maroti wrote: > Hi Marcus, > > I do not know if you or someone else has the expertise on tricking the > scheduler to do the right thing. I would like to implement a tagged > stream interleaver that takes two tagged stream inputs and merges them > into a single stream. Sometimes only one stream will contain packets, > so it cannot rely on waiting for input on all of its inputs (like > tagged_stream_mux does). The problem is what to return in forecast: if > we say that we need at least 1 item on port 0, and the packet comes on > port 1, then we are in trouble as we are blocked essentially till a > packet arrives on port 0. Is it possible to do this intelligently? > > Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] tagged stream interleaver, scheduler and forecast
Hi Marcus, I do not know if you or someone else has the expertise on tricking the scheduler to do the right thing. I would like to implement a tagged stream interleaver that takes two tagged stream inputs and merges them into a single stream. Sometimes only one stream will contain packets, so it cannot rely on waiting for input on all of its inputs (like tagged_stream_mux does). The problem is what to return in forecast: if we say that we need at least 1 item on port 0, and the packet comes on port 1, then we are in trouble as we are blocked essentially till a packet arrives on port 0. Is it possible to do this intelligently? Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] custom tagged_stream_block basetype and swig
Hi Marcus,
On Mon, Jul 31, 2017 at 1:38 AM, Marcus Müller wrote:
> Hi Miklos,
>
> what surprises me a bit is that you're introducing a new block
> scheduling semantic in an OOT – wouldn't you have to modify the
> scheduler to make it do things differently when encountering a
> tagged_stream_block2 ?
>
> Also, maybe we'd want to have a short chat about what your application
> needs and why a modification of the tagged_stream_block behaviour is
> what you want in that case. I must admit, I'm not the biggest fan of the
> technology behind TSBs myself, and if I'd be reimplementing stuff right
> now, I wouldn't do it TSB-alike. Now, in fact, I'm considering how to
> improve (read: in many places, rewrite) the current GNU Radio scheduler,
> so I'd be very interested in the feedback you could offer about what GR
> is lacking for your current use case.
I have kept the tagged stream block semantics, so no need to modify
the scheduler. The change is focused on adding a standard dictionary
to the packet that is carried along the data automatically just like
packet_len is. Processing blocks can query this dictionary (e.g. what
modulation is used, what was the SNR, etc) or add to it. These
dictionaries are automatically merged from the inputs and the same
dictionary is used for all outputs. Here is the header:
class MYMODULE_API tagged_stream_block2 : public gr::block {
protected:
const pmt::pmt_t block_name_sym;
const int max_output_length;
std::vector input_lengths;
std::vector input_dicts;
pmt::pmt_t output_dict;
protected:
// allows pure virtual interface sub-classes
tagged_stream_block2(void) : max_output_length(0) {}
tagged_stream_block2(const std::string &name,
gr::io_signature::sptr input_signature,
gr::io_signature::sptr output_signature,
int max_output_length);
// reads input dictionaries
bool has_input_long(int input, const pmt::pmt_t &key);
long get_input_long(int input, const pmt::pmt_t &key, long val);
// writes output dictionary
void set_output_long(const pmt::pmt_t &key, long val);
void set_output_float(const pmt::pmt_t &key, float val);
void set_output_complex_vector(const pmt::pmt_t &key,
const std::vector> &val);
public:
void forecast(int noutput_items, gr_vector_int &ninput_items_required);
int general_work(int noutput_items, gr_vector_int &ninput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items);
// you have to implement this
virtual int work(int noutput_items, gr_vector_int &ninput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items) = 0;
};
I also changed somewhat how the output buffer length is calculated.
The problem with calculate_output_stream_length is that it might work
in a test scenario, but fail in production: when I design the flow
graph I need to think about how much data this block might produce and
make sure that there is enough buffer space available for that. WIth
the original tagged_stream_block you might return your output stream
length which is larger than allocated buffer, then you are stuck,
because the scheduler cannot create more space than it has originally
allocated. So I decided to set_min_noutput_items and
set_min_output_buffer right from the constructor and always verify
that you do not produce more than you have actually promised. I have
kept the tricks in forecast, that works fine, although I completely
rewrote the logic.
I have struggled with packet based processing before, trying out
various methods, for example using output_multiple (but that fails if
your packet length is e.g. 1023 because the scheduler wants to
allocate a multiple of that which is huge). Messages do not work
because they do not provide back pressure, so now I am experimenting
with tagged stream blocks. What changes do you have in mind for the
scheduler?
Best,
Miklos
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] custom tagged_stream_block basetype and swig
Hi All,
Ok, I found the way to do it and want to report for others who run
into this. We have to trick SWIG thinking that those virtual functions
are not there. This is done in tagged_stream_block.i within GnuRadio
like this:
class gr::tagged_stream_block : public gr::block
{
protected:
tagged_stream_block(const std::string &name,
gr::io_signature::sptr input_signature,
gr::io_signature::sptr output_signature,
const std::string &length_tag_key);
};
I knew about this and I have experimented with it within my OOT
module, but I made an error: I put the adapted version at the end of
the mymodule_swig.i, but that is too late and gave no meaningful
errors. When moved to the front that gave different errors, then after
some SWIG doc reading and google foo I was able to see what was
happening. The following worked me (and it is not enough to do the
trick within the mymodule_swig.i file because we are reusing this
class within the same module). I rewrote the tagged_stream_block2.h
header like this:
#ifndef SWIG
class MYMODULE_API tagged_stream_block2 : public gr::block {
protected:
tagged_stream_block2(void) {}
tagged_stream_block2(const std::string &name,
gr::io_signature::sptr input_signature, gr::io_signature::sptr
output_signature, const std::string &length_tag_key);
virtual int calculate_output_stream_length(const gr_vector_int
&ninput_items) = 0;
...
public:
void forecast(int noutput_items, gr_vector_int &ninput_items_required);
int general_work(int noutput_items, gr_vector_int &ninput_items,
gr_vector_const_void_star &input_items, gr_vector_void_star
&output_items);
virtual int work(int noutput_items, gr_vector_int &ninput_items,
gr_vector_const_void_star &input_items, gr_vector_void_star
&output_items) = 0;
}
#else
class MYMODULE_API tagged_stream_block2 : public gr::block
{
protected:
tagged_stream_block2(const std::string &name,
gr::io_signature::sptr input_signature, gr::io_signature::sptr
output_signature, const std::string &length_tag_key);
};
#endif
Then you also have to add the following line to mymodule_swig.i before
the other %includes
%include "mymodule/tagged_stream_block2.h"
Best,
Miklos
On Sun, Jul 30, 2017 at 2:13 PM, Miklos Maroti wrote:
> Hi All,
>
> It seems that no one really has the SWIG expertise. Just to reiterate,
> if I copy tagged_stream_block from GnuRadio into my OOT, and rename
> it, it has the exact same compile problem. Now I wonder if GnuRadio
> has some magic with the SWIG generation, maybe the base blocks are
> hard coded somewhere in the generator scripts? If so, I could not find
> it.
>
> The problem seems to be that for OOT blocks deriving
> tagged_stream_block the constructor is not wrapped, instead the make
> is used as the block (not the implementation) still has pure virtual
> functions. However, if I change the code to derive
> tagged_stream_block2, then it wants to generate a constructor and of
> course that fails. But why?
>
> Best,
> Miklos
>
> On Fri, Jul 28, 2017 at 6:34 PM, Miklos Maroti wrote:
>> Dear All,
>>
>> For various reasons I am not happy with the tagged_stream_block
>> implementation, and I have implemented my own version, called
>> tagged_stream_block2 and put it into my OOT module. I can use the
>> gr_modtool to create tagged_stream_blocks and manually change the
>> basetype to my version. Everything seems to work fine, except with
>> SWIG generated code. There I get undefined references error to virtual
>> methods (e.g. work). However the C++ code compile fine and no such
>> error is presented. In fact, before I deleted the build directory and
>> rebuilt everything even GRC and SWIG was happy after a regular make.
>> However, once I rebuilt everything with cmake I get these issues in
>> the SWIG generated code. This is the layout:
>>
>> tagged_stream_block2.h goes into the include directory and listed in
>> the CMakeFile.txt
>> tagged_stream_block2.cc goes into the lib directory and listed in the
>> CMakeFile.txt
>> the swig directory CMakeFile is not changed
>>
>> Can anyone with SWIG expertise help? I have attached the complete error
>> message.
>>
>> Best,
>> Miklos
>>
>> ~/workspace/gr-mymodule/build/swig/mymodule_swigPYTHON_wrap.cxx: In
>> function ‘PyObject* _wrap_new_myblock(PyObject*, PyObject*)’:
>> ~/workspace/gr-mymodule/build/swig/mymodule_swigPYTHON_wrap.cxx:44104:85:
>> error: invalid new-expression of abstract class type
>> ‘gr::mymodule::myblock’
>>result = (gr::mymodule::myblock *)new gr::mymodule::myblock();
>>
>> ^
>> In file included from
>> ~/works
Re: [Discuss-gnuradio] custom tagged_stream_block basetype and swig
Hi All,
It seems that no one really has the SWIG expertise. Just to reiterate,
if I copy tagged_stream_block from GnuRadio into my OOT, and rename
it, it has the exact same compile problem. Now I wonder if GnuRadio
has some magic with the SWIG generation, maybe the base blocks are
hard coded somewhere in the generator scripts? If so, I could not find
it.
The problem seems to be that for OOT blocks deriving
tagged_stream_block the constructor is not wrapped, instead the make
is used as the block (not the implementation) still has pure virtual
functions. However, if I change the code to derive
tagged_stream_block2, then it wants to generate a constructor and of
course that fails. But why?
Best,
Miklos
On Fri, Jul 28, 2017 at 6:34 PM, Miklos Maroti wrote:
> Dear All,
>
> For various reasons I am not happy with the tagged_stream_block
> implementation, and I have implemented my own version, called
> tagged_stream_block2 and put it into my OOT module. I can use the
> gr_modtool to create tagged_stream_blocks and manually change the
> basetype to my version. Everything seems to work fine, except with
> SWIG generated code. There I get undefined references error to virtual
> methods (e.g. work). However the C++ code compile fine and no such
> error is presented. In fact, before I deleted the build directory and
> rebuilt everything even GRC and SWIG was happy after a regular make.
> However, once I rebuilt everything with cmake I get these issues in
> the SWIG generated code. This is the layout:
>
> tagged_stream_block2.h goes into the include directory and listed in
> the CMakeFile.txt
> tagged_stream_block2.cc goes into the lib directory and listed in the
> CMakeFile.txt
> the swig directory CMakeFile is not changed
>
> Can anyone with SWIG expertise help? I have attached the complete error
> message.
>
> Best,
> Miklos
>
> ~/workspace/gr-mymodule/build/swig/mymodule_swigPYTHON_wrap.cxx: In
> function ‘PyObject* _wrap_new_myblock(PyObject*, PyObject*)’:
> ~/workspace/gr-mymodule/build/swig/mymodule_swigPYTHON_wrap.cxx:44104:85:
> error: invalid new-expression of abstract class type
> ‘gr::mymodule::myblock’
>result = (gr::mymodule::myblock *)new gr::mymodule::myblock();
>
> ^
> In file included from
> ~/workspace/gr-mymodule/build/swig/mymodule_swigPYTHON_wrap.cxx:4412:0:
> ~/workspace/gr-mymodule/include/mymodule/myblock.h:36:20: note:
> because the following virtual functions are pure within
> ‘gr::mymodule::myblock’:
> class MYBLOCK_API myblock : virtual public gr::tagged_stream_block2 {
> ^
> In file included from ~/workspace/gr-mymodule/include/mymodule/myblock.h:26:0,
> from
> ~/workspace/gr-mymodule/build/swig/mymodule_swigPYTHON_wrap.cxx:4412:
> ~/workspace/gr-mymodule/include/mymodule/tagged_stream_block2.h:69:3:
> note: virtual int
> gr::tagged_stream_block2::calculate_output_stream_length(const
> gr_vector_int&)
>calculate_output_stream_length(const gr_vector_int &ninput_items) = 0;
>^
> ~/workspace/gr-mymodule/include/mymodule/tagged_stream_block2.h:79:15:
> note: virtual int gr::tagged_stream_block2::work(int, gr_vector_int&,
> gr_vector_const_void_star&, gr_vector_void_star&)
>virtual int work(int noutput_items, gr_vector_int &ninput_items,
>^
> swig/CMakeFiles/_mymodule_swig.dir/build.make:68: recipe for target
> 'swig/CMakeFiles/_mymodule_swig.dir/mymodule_swigPYTHON_wrap.cxx.o'
> failed
> make[2]: ***
> [swig/CMakeFiles/_mymodule_swig.dir/mymodule_swigPYTHON_wrap.cxx.o]
> Error 1
> CMakeFiles/Makefile2:237: recipe for target
> 'swig/CMakeFiles/_mymodule_swig.dir/all' failed
> make[1]: *** [swig/CMakeFiles/_mymodule_swig.dir/all] Error 2
> Makefile:138: recipe for target 'all' failed
> make: *** [all] Error 2
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] custom tagged_stream_block basetype and swig
Dear All,
For various reasons I am not happy with the tagged_stream_block
implementation, and I have implemented my own version, called
tagged_stream_block2 and put it into my OOT module. I can use the
gr_modtool to create tagged_stream_blocks and manually change the
basetype to my version. Everything seems to work fine, except with
SWIG generated code. There I get undefined references error to virtual
methods (e.g. work). However the C++ code compile fine and no such
error is presented. In fact, before I deleted the build directory and
rebuilt everything even GRC and SWIG was happy after a regular make.
However, once I rebuilt everything with cmake I get these issues in
the SWIG generated code. This is the layout:
tagged_stream_block2.h goes into the include directory and listed in
the CMakeFile.txt
tagged_stream_block2.cc goes into the lib directory and listed in the
CMakeFile.txt
the swig directory CMakeFile is not changed
Can anyone with SWIG expertise help? I have attached the complete error message.
Best,
Miklos
~/workspace/gr-mymodule/build/swig/mymodule_swigPYTHON_wrap.cxx: In
function ‘PyObject* _wrap_new_myblock(PyObject*, PyObject*)’:
~/workspace/gr-mymodule/build/swig/mymodule_swigPYTHON_wrap.cxx:44104:85:
error: invalid new-expression of abstract class type
‘gr::mymodule::myblock’
result = (gr::mymodule::myblock *)new gr::mymodule::myblock();
^
In file included from
~/workspace/gr-mymodule/build/swig/mymodule_swigPYTHON_wrap.cxx:4412:0:
~/workspace/gr-mymodule/include/mymodule/myblock.h:36:20: note:
because the following virtual functions are pure within
‘gr::mymodule::myblock’:
class MYBLOCK_API myblock : virtual public gr::tagged_stream_block2 {
^
In file included from ~/workspace/gr-mymodule/include/mymodule/myblock.h:26:0,
from
~/workspace/gr-mymodule/build/swig/mymodule_swigPYTHON_wrap.cxx:4412:
~/workspace/gr-mymodule/include/mymodule/tagged_stream_block2.h:69:3:
note: virtual int
gr::tagged_stream_block2::calculate_output_stream_length(const
gr_vector_int&)
calculate_output_stream_length(const gr_vector_int &ninput_items) = 0;
^
~/workspace/gr-mymodule/include/mymodule/tagged_stream_block2.h:79:15:
note: virtual int gr::tagged_stream_block2::work(int, gr_vector_int&,
gr_vector_const_void_star&, gr_vector_void_star&)
virtual int work(int noutput_items, gr_vector_int &ninput_items,
^
swig/CMakeFiles/_mymodule_swig.dir/build.make:68: recipe for target
'swig/CMakeFiles/_mymodule_swig.dir/mymodule_swigPYTHON_wrap.cxx.o'
failed
make[2]: *** [swig/CMakeFiles/_mymodule_swig.dir/mymodule_swigPYTHON_wrap.cxx.o]
Error 1
CMakeFiles/Makefile2:237: recipe for target
'swig/CMakeFiles/_mymodule_swig.dir/all' failed
make[1]: *** [swig/CMakeFiles/_mymodule_swig.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Custom block arguments
You have an extra > after samps_per_sweep here: samps_per_sweep> Best, Miklos On Sun, Jul 9, 2017 at 6:22 PM, Vipin Sharma wrote: > Here is the XML I am using. Note that CustBlock in my original post is > really 'TargetDetector_cf'. > > > > TargetDetector_cf > a1System_TargetDetector_cf > a1System > import a1System > a1System.TargetDetector_cf($samps_per_sweep, $num_sweeps, > $frame_size, $rang_max, $v_max, $rng_nfft, $dop_nfft, $num_peaks, > $num_tgts) > set_samps_per_sweep($samps_per_sweep) > set_num_sweeps($num_sweeps) > set_frame_size($frame_size) > set_rang_max($rang_max) > set_v_max($v_max) > set_rng_nfft($rng_nfft) > set_dop_nfft($dop_nfft) > set_num_peaks($num_peaks) > set_num_tgts($num_tgts) > > SampsPerSweep > samps_per_sweep> > int > > > NumSweeps > num_sweeps > int > > > FrameSize > frame_size > int > > > range_max > rang_max > float > > > v_max > v_max > float > > > RngNFFT > rng_nfft > float > > > DopNFFT > dop_nfft > float > > > NumPeaks > num_peaks > float > > > NumTgts > num_tgts > float > > > > > RawFMCW > complex > > > Rx > complex > > > > > range_est > float > > > speed_est > float > > > > > ___ > 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] QA code for python hierarchical block
Hi Cinaed, Thanks for the pointer. This is what I found: - in qa_polar_encoder_systematic.py we have import fec_swig as fec from extended_encoder import extended_encoder - in extended_encoder.py we have import fec_swig as fec I assume that people use the extended_encoder from their own code (or from GRC), so I would have just used "import fec" within the extended_encoder.py. It seems that I do not fully understand the difference between "import xxx" and "import xxx_swig", I thought that the later is only for debugging, but apparently it includes only the cpp wrappers. So in an xxx OOT module I should always import xxx_swig (and never import xxx) and import python files by name if I want to use other hierarchical modules. Is this accurate? Best, Miklos On Mon, Jun 19, 2017 at 11:40 PM, Cinaed Simson wrote: > On 06/19/2017 01:22 PM, Miklos Maroti wrote: >> Hello, >> >> I have a simple question: I would like to write QA code for a >> hierarchical python block. That hierarchical block uses cpp blocks >> from the same out of tree module. The python code for the hierarchical >> block imports the xxx module, but that is not available in QA code >> yet, and in other places we import xxx_swig as xxx instead. However >> this is not going to work, I cannot put this into the hierarchical >> block code. Is there a good (standard) way to write QA code that works >> before the module is installed? >> >> Best, >> Miklos > > I think I might know what you mean - I've never done it myself - but > I've been confused by trying to turn the qa python scripts in the source > directory. > > If you still have build directory for gnuradio, take a look at the shell > scripts in > > ./src/gnuradio-3.7.11/build/gr-fec/python/fec > > -- Cinaed > >> >> ___ >> 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] QA code for python hierarchical block
Hello, I have a simple question: I would like to write QA code for a hierarchical python block. That hierarchical block uses cpp blocks from the same out of tree module. The python code for the hierarchical block imports the xxx module, but that is not available in QA code yet, and in other places we import xxx_swig as xxx instead. However this is not going to work, I cannot put this into the hierarchical block code. Is there a good (standard) way to write QA code that works before the module is installed? Best, Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] scratch space in output buffer
Hi Ron, I want this operating at 200 Ms/sec, so would like to avoid copying if possible. I will look into other alternatives. Thanks, once again! Miklos On Tue, May 30, 2017 at 3:53 PM, Ron Economos wrote: > AFAIK, there's no way to preserve the output buffer between general_work() > or work() calls. Are you that constrained with the amount of memory your > block can use? A few hundred samples is not very much. In one of my DVB-T2 > blocks, I have 786,432 bytes of static memory allocated. > > https://github.com/gnuradio/gnuradio/blob/master/gr-dtv/lib/dvbt2/dvbt2_freqinterleaver_cc_impl.h#L35 > > Ron > > > On 05/30/2017 01:42 PM, Miklos Maroti wrote: >> >> Hi Ron, >> >> Thanks for the quick response! >> >> On Tue, May 30, 2017 at 3:32 PM, Ron Economos wrote: >>> >>> If you call set_output_multiple() in your block constructor, it will >>> guarantee the size of the output buffer. >> >> That would actually work (so I return exactly one block of items less >> than requested, and use the last slot for scratch space), although it >> will be inefficient for large scratch space size (I need a few hundred >> samples). >> >>> The scheduler won't touch it until you exit your block with: >>> >>> return noutput_items; >> >> No good, I would like my scratch place to be preserved across >> general_work calls, so return noutput_items will not be enough. >> >> Best, >> Miklos >> >>> Ron >>> >>> >>> On 05/30/2017 12:57 PM, Miklos Maroti wrote: >>>> >>>> Hi, >>>> >>>> I would like to use scratch space within the output buffer of a block, >>>> but not sure if I can rely on the scheduler not altering the content >>>> of those items in the output buffer that I have written to but have >>>> not made it available to downstream blocks within general_work. I know >>>> how blocks, forecast, general_work and history works, but I think my >>>> use case is not covered. >>>> >>>> A simple toy use case would be to implement a fir filter without the >>>> history call (I know that in this case history is better). Once a new >>>> sample is taken from the input you multiply that with an N-length >>>> kernel and add it to the output buffer and output only one item and >>>> zero out N-item ahead. >>>> >>>> Can I rely on the scheduler not to modify unproduced items (but of >>>> course within the limits of ninput_items)? Should I return 0 for >>>> forecast when there is not enough space in the output buffer? Would >>>> such a block be synchronous? >>>> >>>> Best, >>>> Miklos >>>> >>>> ___ >>>> 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
Re: [Discuss-gnuradio] scratch space in output buffer
Hi Ron, Thanks for the quick response! On Tue, May 30, 2017 at 3:32 PM, Ron Economos wrote: > If you call set_output_multiple() in your block constructor, it will > guarantee the size of the output buffer. That would actually work (so I return exactly one block of items less than requested, and use the last slot for scratch space), although it will be inefficient for large scratch space size (I need a few hundred samples). > The scheduler won't touch it until you exit your block with: > > return noutput_items; No good, I would like my scratch place to be preserved across general_work calls, so return noutput_items will not be enough. Best, Miklos > > Ron > > > On 05/30/2017 12:57 PM, Miklos Maroti wrote: >> >> Hi, >> >> I would like to use scratch space within the output buffer of a block, >> but not sure if I can rely on the scheduler not altering the content >> of those items in the output buffer that I have written to but have >> not made it available to downstream blocks within general_work. I know >> how blocks, forecast, general_work and history works, but I think my >> use case is not covered. >> >> A simple toy use case would be to implement a fir filter without the >> history call (I know that in this case history is better). Once a new >> sample is taken from the input you multiply that with an N-length >> kernel and add it to the output buffer and output only one item and >> zero out N-item ahead. >> >> Can I rely on the scheduler not to modify unproduced items (but of >> course within the limits of ninput_items)? Should I return 0 for >> forecast when there is not enough space in the output buffer? Would >> such a block be synchronous? >> >> Best, >> Miklos >> >> ___ >> 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] scratch space in output buffer
Hi, I would like to use scratch space within the output buffer of a block, but not sure if I can rely on the scheduler not altering the content of those items in the output buffer that I have written to but have not made it available to downstream blocks within general_work. I know how blocks, forecast, general_work and history works, but I think my use case is not covered. A simple toy use case would be to implement a fir filter without the history call (I know that in this case history is better). Once a new sample is taken from the input you multiply that with an N-length kernel and add it to the output buffer and output only one item and zero out N-item ahead. Can I rely on the scheduler not to modify unproduced items (but of course within the limits of ninput_items)? Should I return 0 for forecast when there is not enough space in the output buffer? Would such a block be synchronous? Best, Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Latest Hackfest
Hi Tom, On Fri, Apr 4, 2014 at 12:21 AM, Tom Rondeau wrote: > > On Thu, Apr 3, 2014 at 3:05 PM, Miklos Maroti > wrote: >> >> Dear Tom, >> >> I have read about the FEC work done during the Hackfest, so this would >> be an appropriate time to bring this up. We have participated in the >> Darpa Spectrum Challenge, and developed some good and fast codes. >> Specifically, we have a generic convolutional code encoder and decoder >> (any R and K is supported, tailbiting can be enabled), with fast SSE >> implementation. In the attached BER figure we have used R=1/8, K=9 and >> length = 3 bytes = 24 bits for encoding headers. The speed is not much >> worse than the spiral generated one. More importantly, we have a >> specially crafted version of a repeat accumulate coder/decoder that >> can be quickly decoded with SSE. On the figure we have used rates 1/3, >> 1/2, 1/3 and 4/5 with a payload size of 1440 bytes. On the orbit-lab >> machines (core-i7) our SSE code can decode more than 1000 packets per >> second on a single core. >> >> I plan to release this code under the GPL (and maybe under an MIT >> license as well) after I have a paper written up about it. So the >> question would be: > > > Miklos, > > This sounds like a fantastic result. > >> >> 1) how to incorporate this into gnuradio (separate OOT or built in) > > > If it's to go into GNU Radio, it would only be license GPLv3, like the rest > of the code base. Also, we require a copyright transfer from you. We can > discuss and work on that on the side. > > Also, with the use of SSE, we'd want to separate the code into a VOLK kernel > with a generic and SSE implementation. That way, we're not restricting > ourselves to certain platforms. And then, we can extend it to other SIMD > architectures. I have thought about it. I know that all SSE code is currently separated into a VOLK kernel (with the exception of FFT which is coming from a separate library). Of course you can do that, but then most of the gnuradio blocks will be just wrappers around the VOLK kernels. >> 2) how to deal with puncturing (we have some good generic solution) > > > We let the FEC API encoder and decoder blocks handle the puncturing and > depuncturing separate from the coders themselves. I think they are generic > enough, but we'd probably want to update them if they don't fit every > scenario. I have a generic interleaver / puncturer that takes chunks of memory blocks and reorders (permutes) them and extends them with zero at arbitrary places. Basically it takes a map (integer list between -1 and N-1) where -1 means "zero out" and 0 through N-1 means some element of the input. Probably it is harder to explain than to see it. Anyhow, the puncturing design is important and you have to omit encoded (unsigned char) hard bits and insert soft (float) zeros. >> 3) how to deal with variable packet lengths and variable rates (have some >> ides) > > > The FEC API encoder/decoder blocks don't care about the packet lengths as > long as the coders themselves can handle it. Right now, our working example > uses fixed packet length, but (I don't think) that's a requirement. Might > have to double-check this. Same should go for the rate. > > In the FEC API world, there is an FEC encoder and decoder block that sets > just a few parameters. One of them is the variable that actually defines the > encoder and decoder code, and those variables are designed to work with the > API. So most of this is on how these variable blocks are built. Do you have a working coder/decoder pair with this API? >> 4) how mature is the FEC API, can it be modified if needed? > > > It's mature in that we've tested it out-of-tree with a number of situations. > But as we're moving it into GNU Radio, there's a window here to update it. > Best done before we merge it into master, though, which will set the API > until 3.8 of GNU Radio. It'd be great if you could take my current github > repo branch "fecapi" and see about fitting your coder into it. That'll get > us some feedback before we merge into master. Probably the best would be to put my code (separate it from the rest) into a OOT module for you to see it, and then we pick up the discussion from there. Miklos > >> >> Best, >> Miklos > > > > Thanks! > Tom > > >> >> On Thu, Apr 3, 2014 at 7:32 PM, Tom Rondeau wrote: >> > We had our latest GNU Radio Hackfest last week at Ettus Research. It was >> > a >> > fantastic week with a lot of good work getti
Re: [Discuss-gnuradio] Need help to understand code of sync:decimator block
Hi Kunal,
Use a decimating FIR filter with taps [0.2, 0.2, 0.2, 0.2, 0.2] and
decimation 5. It will be faster than anything you are about to write.
Miklos
On Sat, Mar 8, 2014 at 12:03 PM, kunal sankhe wrote:
> Hello Marcus,
>
> Sorry for my vague explanation. I want to write a block which will calculate
> moving average for a block of samples. I have only one input in this case. I
> am providing my data serially using vector to stream converter. I want to
> calculate average of a block of 5 samples.
>
> eg. from vector source {1,2,3,4,5,6,7,8,9,10}, i will get stream of
> integers.
>
> Now I want to calculate average for first 5 samples i.e. 3 and then it
> should calculate average of {6,7,8,9,10} which is 8. So i should get desired
> output as {3,8}.
>
> So I should get output for a block containing 5 samples. It should again
> consider block of 5 next samples and calculate average.
>
> Please let me what changes do I need to make.
>
> Thanks,
> Kunal
>
>
> On Sat, Mar 8, 2014 at 3:23 PM, Marcus Müller wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Hello Kunal,
>>
>> You don't want to use set_history in this case: you want to produce 1
>> output for 5 input, so you use a decimator; that's all you need to do. Drop
>> the set_history.
>> For reference: history is when for every input item you need the last 5
>> items before,
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules#set_history
>> Greetings,
>> Marcus
>> - --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> -BEGIN PGP SIGNATURE-
>> Version: APG v1.0.9
>>
>> iQFABAEBCAAqBQJTGuigIxxNYXJjdXMgTfxsbGVyIDxtYXJjdXNAaG9zdGFsaWEu
>> ZGU+AAoJEBKNLRrpJvfoIRUH/0Orh65WsPeli99oQrbMpb40FVG+cytjmuUS8mKX
>> s0PHoDcQ/HXC8KIKxAOo+JQ26X/AK8Qnf3WCgfYB2/dvA7sz7JmYUbXgGFry1S9D
>> dtPUzAW2D0AASXG19rFBtCq6u1nhVDsIwxQ1yASNwx2wKuQEZyRFA1tjHiUqjpFf
>> 0V+S1nB81jWw0WUJTpRMRGOe1tvhG0IDKmeBptMbKw6ShM979pPM3JgDsFIhn2MS
>> UWIM7Qjvnul4g8dnq/t7DpNe+lguHFgFes3hB8cHtTRGBvy+8QPJWn5lnCRBZz+4
>> ZKFrkWdsslzKjUHP67ZIQ5hn104P6MQZER+RpFdtcO3BJqg=
>> =9KAs
>> -END PGP SIGNATURE-
>>
>
>
> ___
> 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] blocks with message input and output only
Sorry, everything works as expected (needs a little wait at the beginning). Miklos On Tue, Mar 4, 2014 at 1:09 AM, Miklos Maroti wrote: > Hi Guys, > > How to write blocks that have only message input and outputs only? I > have derived from gr:block, and in most cases it seems to work, but if > I put together a test that has no streams, then the whole graph stops > I think prematurely. How to ensure that a flow graph works with > messages only? > > Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] blocks with message input and output only
Hi Guys, How to write blocks that have only message input and outputs only? I have derived from gr:block, and in most cases it seems to work, but if I put together a test that has no streams, then the whole graph stops I think prematurely. How to ensure that a flow graph works with messages only? Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Unable to stop the flow graph after calling stop()
Dear Activecat,
Throw an exception. It will kill the application.
Miklos
On Mon, Mar 3, 2014 at 11:57 AM, Activecat wrote:
> Dear Marcus,
>
> Says, the constructor performed some basic checking on the constructor
> arguments, then had found some fatal error (says, division by zero) and
> decided to ban the flowgraph from being executed.
>
> A workaround is to get the constructor to set a class variable to false,
> says,
> d_valid = false;
>
> then in the work() it will check this d_valid as follows:
>
> int work()
> {
> if ( ! d_valid )
>return -1
> .
> . (other stuff as usual)
> }
>
>
> But isn't there a better way to do this ..?
> (to ban the flowgraph from being executed within the constructor)
>
> Please advise, thanks.
>
> Regards,
> Activecat
>
>
>
> On Mon, Mar 3, 2014 at 5:25 PM, Marcus Müller wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Activecat,
>>
>> the constructor of a block must have been called before the block has
>> been connect()ed; so there's no way a flowgraph is already running
>> when your block's constructor is called.
>>
>> Greetings,
>> Marcus
>>
>> On 03.03.2014 06:53, Activecat wrote:
>> > Dear Sir, Thank you very much.
>> >
>> > What if, we want to stop the flow graph in the constructor of a
>> > block?
>> >
>> > In work() we can just return -1. But in constructor, what value
>> > should be returned, also -1 ?
>> >
>> > Regards, Activecat
>> >
>> >
>> > On Sun, Feb 2, 2014 at 9:05 PM, Martin Braun
>> > wrote:
>> >
>> >> On 01.02.2014 13:51, Activecat wrote:
>> >>
>> >>> But the function stop() fails to work. The flow graph continue
>> >>> executing infinitely...
>> >>>
>> >>> Question: How to stop the flow graph when this->d_complete ==
>> >>> true ?
>> >>>
>> >>
>> >> Return -1 (or WORK_DONE) in your work() function.
>> >>
>> >> MB
>> >>
>> >>
>> >> ___ 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
>> >
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQEcBAEBAgAGBQJTFEqdAAoJEAFxB7BbsDrLv84H/jghxvQXY6VcZPvRXs1BKmxp
>> Odr8p/ICE9rpcz21M6M0ILxqhKaOp5vlaG/n6UMM2fFU+Cf7RQQkFrVsEBcqUcGg
>> sgYjE+PmTuIbn6xg6mupAJdN1iVsztH+5qU/71SPxJjfwpnJjsJrzzGlQC6JhGIr
>> fPHDG5DLAS11Q8USSFAc5Y7vXI57rskCZ3/Qq1j+dTl5pgNLSzsccb4AmVBy2dCB
>> 7mM1PIxAuTJgaeXbk85BEnhkwdI4HQzOS7phg53ChYIWMKs+WCsjk0weUNMj2VZt
>> rXdd137xZjkfPHyGJ73spjhJ7OHUW8NeQaNxauI8Uf45S6jnNFFx/vzD1EEgIV8=
>> =vI+z
>> -END PGP SIGNATURE-
>>
>> ___
>> 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
Re: [Discuss-gnuradio] pmt memory management
Hi Tom, Thanks for the clarification. I will be very careful, I promise :) Miklos On Mon, Feb 24, 2014 at 4:15 PM, Tom Rondeau wrote: > On Sat, Feb 22, 2014 at 1:49 PM, Miklos Maroti > wrote: >> Hi Guys, >> >> Does copying a large pmt vector involve copying the underlying memory >> region or do they share a single copy (refcounted)? If the do share a >> single memory area, then can one thread modify the data of the vector >> and will it be visible to the other thread just like regular arrays? >> >> Miklos > > Miklos, > > PMTs are always managed as a shared pointer (refcounted using > boost::intrusive_ptr). So yes, you have to be careful with thread > safety. PMTs are designed to be read-only to avoid the thread safety > issue (for instance, when adding a key:value pair to a dictionary, you > actually return a new PMT dictionary). The vectors are the only (and > don't ask me why...) PMT type that is directly writable. So yes, be > careful about thread safety issues with this structure. > > Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] pmt memory management
Hi Guys, Does copying a large pmt vector involve copying the underlying memory region or do they share a single copy (refcounted)? If the do share a single memory area, then can one thread modify the data of the vector and will it be visible to the other thread just like regular arrays? Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] messages get lost randomly
Hi Martin, On Sat, Feb 22, 2014 at 1:44 PM, Martin Braun wrote: > On 02/22/2014 12:40 AM, Miklos Maroti wrote: >> Hi Guys, >> >> Ok, I have found out how to make it work reliably. You must register a >> listener with set_msg_handler, and then you will get the missing >> messages there. >> >> In light of this, I do not see how pdu_to_tagged_stream could work >> reliably. It does not register a listener (but it does not block >> either), so if there is a gap in the message stream, then it will miss >> that message. >> >> Miklos > > Miklos, > > that is right--a thorough discussion of message passing is high on our > agenda at the moment. pdu_to_tagged_stream is a bit of a special case, > since the only thing to do with a rx'd message is to put it onto the > output buffer, which is only available in work(), i.e., if we had a msg > handler, all it could do is re-buffer the msg before we can copy it into > the output buffer. One thing we did very recently was increase the size > of the msg q, so msg loss would be less likely. My block does exactly the same: copies messages to a stream. In the handler I just queue it again (no copying, so no memory overhead), and in work first I check my private queue, if that is empty then I wait for a new message with delete_head_blocking. It works perfectly (provided you have enough ram to handle the bursts of messages). Miklos > > MB > > > ___ > 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] messages get lost randomly
Hi Guys, Ok, I have found out how to make it work reliably. You must register a listener with set_msg_handler, and then you will get the missing messages there. In light of this, I do not see how pdu_to_tagged_stream could work reliably. It does not register a listener (but it does not block either), so if there is a gap in the message stream, then it will miss that message. Miklos On Fri, Feb 21, 2014 at 11:55 PM, Miklos Maroti wrote: > Hi Guys, > > I am using the messaging support of basic_block registering the > message queue with message_port_register_in and removed the obtained > messages with delete_head_blocking. This block is producing streams > and everything seems to work fine as long as I consume the messages > fast enough. However, if I put a throttle block after my stream > producing block, then messages get lost. > > The producer generates 1 messages with message_port_pub, but the > consumer does not receive all of those messages. I intentionally wait > 500 ms on the producer for the consumer to be started (otherwise the > consumer might not get registered in time). So I have verified that > the problem is not in my code, but somewhere the messages get lost. > > As far as I see in the basic_block code these message queues are not > regular msg_queue objects but std::deque objects protected by locks. I > do not see how messages could get lost. Any ideas? > > Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] messages get lost randomly
Hi Guys, I am using the messaging support of basic_block registering the message queue with message_port_register_in and removed the obtained messages with delete_head_blocking. This block is producing streams and everything seems to work fine as long as I consume the messages fast enough. However, if I put a throttle block after my stream producing block, then messages get lost. The producer generates 1 messages with message_port_pub, but the consumer does not receive all of those messages. I intentionally wait 500 ms on the producer for the consumer to be started (otherwise the consumer might not get registered in time). So I have verified that the problem is not in my code, but somewhere the messages get lost. As far as I see in the basic_block code these message queues are not regular msg_queue objects but std::deque objects protected by locks. I do not see how messages could get lost. Any ideas? Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] forecast
Hi Guys, If a block keeps some internal state, can the forecast method return different values for the same number of noutput_items depending on its internal state? Will the forecast method be called before the flow graph is started? Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] set_relative_rate
Hi Tom, On Fri, Feb 7, 2014 at 11:10 AM, Tom Rondeau wrote: > On Thu, Feb 6, 2014 at 9:14 PM, Miklos Maroti > wrote: >> Hi Tom, >> >> Thanks for the answer! I have considered both approach already. What >> you are saying is that set_relative_rate cannot capture this scenario, >> so it is impossible to set different relative rates, right? > > Right; relative_rate as a value is defined as a single value for the > entire block. you can consume and produce at different rates for each > input/output stream. > >> Where exactly are the relative rates used in gnuradio core? Only for >> the buffer size calculations or are they also used during runtime? > > Yes, mostly the initial buffer size calculation. It's also used to > update the item offset value of a tag through a rate-changing block. > >> By the way, the vector approach does not scale ideally: if I increase >> the size of vectors (to 10 samples) or use set_output_multiple >> with that large value then the performance of the block is degraded, >> and I do not really understand why. If the block does pure streaming >> (e.g. add) and does not require large quantities of data, then >> everything works fine. I do not want to use messages, because the data >> is processed (filtered, length changed, etc) along with other >> transformations. Anyhow, what I am getting at that there is no good >> way of processing very large blocks of data. > > Use gr-perf-monitorx (or in GRC just look for Performance Monitor) if > you have ControlPort enabled and building properly [1][2]. You'll > likely see the buffer in front of your block backing up while the > output buffer is fairly empty as the scheduler has to dump lots of > data into it before anything else can go, so you'll be starving the > follow-on blocks. Yes, I have used the performance monitor and indeed the data backs up at that point and starves the follow-on blocks. What I have found is that increasing the history size (set_history) to huge values does not impair the performance, but increasing the output size (either with using huge vectors or using set_output_multiple) degrades the performance significantly. I am talking of 100 samples at a time. However, I think the starving is happening because the block is unable to produce the data fast enough: maybe output multiple works like a filter: it just rounds down the noutput_values to an integer multiple, but the scheduler will keep calling this block which cannot produce data because there is not enough space in the followup buffer. > Another model is to try and handle the state internally. Just allow > data to flow in from each data stream and keep internal buffers. This > might allow you to work with the scheduler better. Yes, I have considered that as well, but then it would have to copy data twice (from stream to main memory and back). Maybe that is the easiest way to do it, but most likely would require the use of a non-fixed rate block. If set_output_multiple would not degrade performance, then that would be the easiest way to do things. > I'm interested to see if you can get an approach that works well with > your problem. So far, what you're trying to do seems somewhat of a > non-standard use-case for GNU Radio, but I can see more people trying > to do this kind of processing in the future. Would be good to know > both the limits and why. The typical problematic block is the following: take 128 pieces of 5000 long sample blocks and mix them into a stream of 5000 long 128-sized vectors. This is just matrix transposition: read in a large matrix row by row and output the values column by column. Miklos > [1] http://gnuradio.org/doc/doxygen/page_ctrlport.html > [2] http://gnuradio.org/redmine/projects/gnuradio/wiki/PerformanceCounters > > > Tom > > >> Miklos >> >> On Thu, Feb 6, 2014 at 11:15 AM, Tom Rondeau wrote: >>> On Wed, Feb 5, 2014 at 7:02 PM, Miklos Maroti >>> wrote: >>>> Hi Guys, >>>> >>>> Is it possible to write a c++ block that takes 2 input streams, >>>> produces 1 output streams, but to generate 1000 outputs it needs 1000 >>>> inputs of the first kind and 1 input of the second kind? How do I set >>>> the set_output_rate? Does it apply to both input streams? How can I >>>> ensure that the scheduler does not create too big buffer for the >>>> second type of input? >>>> >>>> Miklos >>> >>> >>> There are a couple of ways to do this. It might be easiest for you to >>> use vectors of samples on input port 0. The output could be another >>> vector or you could convert it to a stream again here. This is >>> as
Re: [Discuss-gnuradio] set_relative_rate
Hi Tom, Thanks for the answer! I have considered both approach already. What you are saying is that set_relative_rate cannot capture this scenario, so it is impossible to set different relative rates, right? Where exactly are the relative rates used in gnuradio core? Only for the buffer size calculations or are they also used during runtime? By the way, the vector approach does not scale ideally: if I increase the size of vectors (to 10 samples) or use set_output_multiple with that large value then the performance of the block is degraded, and I do not really understand why. If the block does pure streaming (e.g. add) and does not require large quantities of data, then everything works fine. I do not want to use messages, because the data is processed (filtered, length changed, etc) along with other transformations. Anyhow, what I am getting at that there is no good way of processing very large blocks of data. Miklos On Thu, Feb 6, 2014 at 11:15 AM, Tom Rondeau wrote: > On Wed, Feb 5, 2014 at 7:02 PM, Miklos Maroti > wrote: >> Hi Guys, >> >> Is it possible to write a c++ block that takes 2 input streams, >> produces 1 output streams, but to generate 1000 outputs it needs 1000 >> inputs of the first kind and 1 input of the second kind? How do I set >> the set_output_rate? Does it apply to both input streams? How can I >> ensure that the scheduler does not create too big buffer for the >> second type of input? >> >> Miklos > > > There are a couple of ways to do this. It might be easiest for you to > use vectors of samples on input port 0. The output could be another > vector or you could convert it to a stream again here. This is > assuming that you always want to process 1000 samples at a time for > every 1 sample on input port 1. You set your IO signature like: > > gr::io_signature::make2(2, 2, 1000*sizeof(type0), 1*sizeof(type1)) > > The output signature is either 1000*sizeof(type0) and you can use a > gr::sync_block (because 1 output item is 1 input item) or your output > signature is 1*sizeof(type0) but you'll use a gr::sync_interpolator > because now you'll be producing 1000 items after taking in a stream of > 1 item. See vector_to_stream for a model of this second approach. > > You might also want to consider the tag stream interface instead of an > indicator on stream 1. You would then have one input stream but look > for the tag to process your 1000 output samples. This would be a more > general approach if you aren't always using 1000 items at a time. > > Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] set_relative_rate
Hi Guys, Is it possible to write a c++ block that takes 2 input streams, produces 1 output streams, but to generate 1000 outputs it needs 1000 inputs of the first kind and 1 input of the second kind? How do I set the set_output_rate? Does it apply to both input streams? How can I ensure that the scheduler does not create too big buffer for the second type of input? Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sched is requesting more input data than we can provide
Hi Martin, But the buffers are already allocated, and I assume that they are not resized dynamically. So even if you change the relative rate at runtime, you will get into the "sched: is requesting more input data than we can provide" error. So I do not understand how the scheduler is going to use the relative rate info WHILE the flowgraph is running. I assume it uses only the forecast method only, no? Miklos On Sat, Jan 25, 2014 at 2:43 PM, Martin Braun wrote: > On 01/25/2014 02:23 PM, Miklos Maroti wrote: >> One more question: >> >> Can I change the relative rate (with set_relative_rate) while the >> flowgraph is running? What effect does that have? > > Yes, you can. As you said, the relative rate is a pointer for the > scheduler to figure out how much stuff you need at input for a given > output. You can change it at runtime, and it will still do just that. > > MB > > > ___ > 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] sched is requesting more input data than we can provide
One more question: Can I change the relative rate (with set_relative_rate) while the flowgraph is running? What effect does that have? Miklos On Sat, Jan 25, 2014 at 12:07 PM, Miklos Maroti wrote: > Hi Martin, > > Ok, I think I have fixed the problem. I did not set the relative rate > properly in the constructor. It seems, that the scheduler uses the > relative rates to allocate buffers before the graph is executed, and > if some block is requesting more data at runtime, then we get into > problems. It is good to know. > > I wonder if I can set the relative rate differently for different > input streams... but I could not find anything. > > Best, > Miklos > > On Fri, Jan 24, 2014 at 2:00 PM, Martin Braun wrote: >> On 01/24/2014 07:28 AM, Miklos Maroti wrote: >>>> I did not set anything explicitly, although I did not set in my xxx >>>> block the set relative rate (maybe that is used by the scheduler to >>>> set up the buffer sizes appropriately). >>> >>>> Basically I want to take 100 packets of size 160 and push them through >>>> an S/P converter for an 128 point IFFT (think of OFDM where every >>>> subcarrier would carry its own packets independently). >>> >>>> Miklos >> >> We still need to know the precise blocks and flow graph configuration. >> >> MB >> >> ___ >> 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] sched is requesting more input data than we can provide
Hi Martin, Ok, I think I have fixed the problem. I did not set the relative rate properly in the constructor. It seems, that the scheduler uses the relative rates to allocate buffers before the graph is executed, and if some block is requesting more data at runtime, then we get into problems. It is good to know. I wonder if I can set the relative rate differently for different input streams... but I could not find anything. Best, Miklos On Fri, Jan 24, 2014 at 2:00 PM, Martin Braun wrote: > On 01/24/2014 07:28 AM, Miklos Maroti wrote: >>> I did not set anything explicitly, although I did not set in my xxx >>> block the set relative rate (maybe that is used by the scheduler to >>> set up the buffer sizes appropriately). >> >>> Basically I want to take 100 packets of size 160 and push them through >>> an S/P converter for an 128 point IFFT (think of OFDM where every >>> subcarrier would carry its own packets independently). >> >>> Miklos > > We still need to know the precise blocks and flow graph configuration. > > MB > > ___ > 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] sched is requesting more input data than we can provide
Hi Marcus, On Thu, Jan 23, 2014 at 10:12 PM, Marcus Müller wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Miklos, > > the problem here is xxx: > > On 23.01.2014 22:00, Miklos Maroti wrote: >> sched: is requesting more input data > > what's this xxx? It is requiring 16000 input items at once *at least* > and that's nearly twice the max output size (see > gnuradio-runtime/lib/block_executor.cc), and you're right, that has > something to do with maximum buffer sizes. > However, GNU Radio has algorithms to appropriately set up buffers to > make the items flow. Unless you've configured the top_block > explicitely to have max noutput items < 16000, that should work out > unless there is some architectural quirk in your flowgraph that > actually suggest that it /can't/ run. I did not set anything explicitly, although I did not set in my xxx block the set relative rate (maybe that is used by the scheduler to set up the buffer sizes appropriately). Basically I want to take 100 packets of size 160 and push them through an S/P converter for an 128 point IFFT (think of OFDM where every subcarrier would carry its own packets independently). Miklos > > So, to help you out, we actually need a little more information. > Most probably an architectural change to xxx or your flowgraph will > solve your problem. > > Greetings, > Marcus > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJS4YW+AAoJEAFxB7BbsDrLQlUH/0A0+QTTNSaun4ML91BKMbAy > ga9wFwJQRLlR1CJewzGBHzAJhx7ruSSh3P3H4jEJb7Lg5zpHAUQ/qB7+AspobFZt > HsYgmApPGv6ck0DyEe5SNiKKPr8HNCvf9t/hijBd8yNOWrPrjcDTR1GJQfy69yYJ > oX11Y+1IOSFQI0mL6dKkcIJ6Q9tEV2J0qRQieLxF4CqO5dSLQ1W9HtfElVktrJ18 > a3BcxNhJLppKMZqlBwMommQCcoZ1+3J1KWlTxPP0dj58reEN9ub0vRKa98KtFXZI > AbMWP1jaJrjDIgvRRPIU1txbKMIh4V77N1bg4fF0elHVD+5QAgh3HdiVQhyVPOU= > =3zBJ > -END PGP SIGNATURE- > > ___ > 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] sched is requesting more input data than we can provide
Hi! I am getting this error: sched: is requesting more input data than we can provide. ninput_items_required = 16000 max_possible_items_available = 8191 and I have no idea how to fix it. Is it possible to request more buffer space? Setting the minimum output buffer size seems to have no effect for me. Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] filter taps and delays
Hi Guys, If I use interp_fir_filter_ccc(3, [1, 2, 3, 4, 5, 6]) on a vector source containing [1, 0, 0, ...] then I get [1, 2, 3, 4, 5, 6, 0, 0, ...] as expected. However, if I use interp_fir_filter_ccc(3, [1, 2, 3, 4, 5]) then I get [0, 1, 2, 3, 4, 5, 0, 0, ...] so the samples are shifted to the right by one. For taps of length divisible by 3 there is no delay, and for others there is 1 or 2 sample delay introduced by the interpolation filter. Why is this? Also, maybe related to this, I see filter.declare_sample_delay(0) in generated code, and I do not know what it does and if it is strictly necessary. Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] constellation soft decoder
Thanks. Miklos On Tue, Dec 17, 2013 at 3:45 PM, Martin Braun wrote: > On Mon, Dec 16, 2013 at 5:18 PM, Miklos Maroti > wrote: >> >> Can you guys add me to the list of developers (user name: mmaroti)? >> Then I can file the bug report. >> > > In case this wasn't the case, you now have access to the wiki. > > MB > > ___ > 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] constellation soft decoder
Hi Tom, On Mon, Dec 16, 2013 at 7:27 PM, Tom Rondeau wrote: > On Mon, Dec 16, 2013 at 1:08 PM, Miklos Maroti > wrote: >> Hi Guys, >> >> Ok, I have sent a pull request. >> >> On a related note: I do not understand the scaling performed in the >> constellation constructor. Why are the constellation points scaled to >> have average 1.0 amplitude? It prevents me to do interesting stuff >> with constellations. Why cannot I set the d_scalefactor manually later >> (this is used in calc_soft_dec)? >> >> Miklos > > Miklos, > > You must have overlooked my email. I sent and already applied a patch > for this. I'm going to go ahead and close this bug. Sorry, I did not read then carefully. > The scaling is done to make our slicing easier to perform. It was a > design decision by the original author. I don't understand how this > prevents you from doing "interesting stuff" since it's just a scaling > factor. Unless floating point accuracy is really that big of a deal to > what you want to do. You would have a multiplier block just because your constellation is scaled (and you have to recompute the scaling factor manually just to compensate). > That having been said, we probably don't actually need to impose this > so strictly. We can probably add another argument to the constellation > constructor to pass this value in, default it to 0, and if it's 0, do > the autoscaling we currently do. That would be a nice to have. Miklos > > Tom > > > >> On Mon, Dec 16, 2013 at 5:18 PM, Miklos Maroti >> wrote: >>> Hi Marcus, >>> >>>> Anyway, I think Miklos is right: There is an error in calc_soft_dec in >>>> using the pre_diff_code even in the case that it is not set or its >>>> application disabled. >>>> >>>> Miklos, would you be as nice as to file a bug for that? You're the one >>>> who successfully diagnosed that. >>> >>> Can you guys add me to the list of developers (user name: mmaroti)? >>> Then I can file the bug report. >>> >>> In the mean time, I might be able to put together a pull request, just >>> fixing the calc_soft_dec code. >>> >>>> (You may, btw, simply think of >>>> pre_diff_code simply as an index set of the constellation points) >>> >>> I do not understand. It is just an extra permutation of the >>> constellation points. If this is so, then why do you not just permute >>> the constellation points, which makes everything faster. Do you have >>> any use case where simply permuting the constellation vector would not >>> achieve the same result? >>> >>> I also worry about performance. Even for BPSK, QPSK and 8PSK the soft >>> decoding is not optimized, but could be much simpler than the general >>> algorithm. Same goes for QAM, but I have not looked those really >>> closely. >>> >>> Miklos >>> >>>> >>>> Greetings, >>>> Marcus >>>> >>>> On 16.12.2013 14:29, Philip Balister wrote: >>>>> On 12/16/2013 08:16 AM, Miklos Maroti wrote: >>>>>> Hi Marcus, >>>>>> >>>>>> Ok, that makes sense. It does not crash with QPSK, but it does >>>>>> with BPSK and 8PSK, and BPSK and 8PSK do not set the >>>>>> pre_diff_code. This explains why there is crash in one case and >>>>>> not the other. Although neither sets the apply_pre_diff_code, so >>>>>> even QPSK should not set pre_diff_code. >>>>> >>>>> I took a quick look in Coverity for issues in gr-digital. It flags >>>>> a bunch of uninitialized variables. I'll try and take a look at >>>>> these this week. >>>>> >>>>> There is an intermittent QA failure in some QA code and this might >>>>> be an explanation. >>>>> >>>>> Philip >>>>> >>>>>> >>>>>> I think the real problem is in constellation::calc_soft_dec. I >>>>>> does not check whether d_apply_pre_diff_code is set or not. >>>>>> >>>>>> (By the way, I do not understand the usefulness of pre_diff_code. >>>>>> Can you just permute the constellation points and get the same >>>>>> effect?) >>>>>> >>>>>> Miklos >>>>>> >>>>>> On Mon, Dec 16, 2013 at 1:34 PM, Marcus Müller >>>>>> wrote:
Re: [Discuss-gnuradio] constellation soft decoder
Hi Guys, Ok, I have sent a pull request. On a related note: I do not understand the scaling performed in the constellation constructor. Why are the constellation points scaled to have average 1.0 amplitude? It prevents me to do interesting stuff with constellations. Why cannot I set the d_scalefactor manually later (this is used in calc_soft_dec)? Miklos On Mon, Dec 16, 2013 at 5:18 PM, Miklos Maroti wrote: > Hi Marcus, > >> Anyway, I think Miklos is right: There is an error in calc_soft_dec in >> using the pre_diff_code even in the case that it is not set or its >> application disabled. >> >> Miklos, would you be as nice as to file a bug for that? You're the one >> who successfully diagnosed that. > > Can you guys add me to the list of developers (user name: mmaroti)? > Then I can file the bug report. > > In the mean time, I might be able to put together a pull request, just > fixing the calc_soft_dec code. > >> (You may, btw, simply think of >> pre_diff_code simply as an index set of the constellation points) > > I do not understand. It is just an extra permutation of the > constellation points. If this is so, then why do you not just permute > the constellation points, which makes everything faster. Do you have > any use case where simply permuting the constellation vector would not > achieve the same result? > > I also worry about performance. Even for BPSK, QPSK and 8PSK the soft > decoding is not optimized, but could be much simpler than the general > algorithm. Same goes for QAM, but I have not looked those really > closely. > > Miklos > >> >> Greetings, >> Marcus >> >> On 16.12.2013 14:29, Philip Balister wrote: >>> On 12/16/2013 08:16 AM, Miklos Maroti wrote: >>>> Hi Marcus, >>>> >>>> Ok, that makes sense. It does not crash with QPSK, but it does >>>> with BPSK and 8PSK, and BPSK and 8PSK do not set the >>>> pre_diff_code. This explains why there is crash in one case and >>>> not the other. Although neither sets the apply_pre_diff_code, so >>>> even QPSK should not set pre_diff_code. >>> >>> I took a quick look in Coverity for issues in gr-digital. It flags >>> a bunch of uninitialized variables. I'll try and take a look at >>> these this week. >>> >>> There is an intermittent QA failure in some QA code and this might >>> be an explanation. >>> >>> Philip >>> >>>> >>>> I think the real problem is in constellation::calc_soft_dec. I >>>> does not check whether d_apply_pre_diff_code is set or not. >>>> >>>> (By the way, I do not understand the usefulness of pre_diff_code. >>>> Can you just permute the constellation points and get the same >>>> effect?) >>>> >>>> Miklos >>>> >>>> On Mon, Dec 16, 2013 at 1:34 PM, Marcus Müller >>>> wrote: Well, after having a debug build and >>>> then adding a lot of "volatile"s into the code at the crashing >>>> function, it looks as if the d_pre_diff_code of the constellation >>>> has size 0; and thus, you can't access the 0. (read: first) >>>> element. How this could happen with a QPSK object is currently >>>> subject to my confusion. Stay tuned for more confusing facts as >>>> the code unfolds :). >>>> >>>> Greetings, Marcus >>>> >>>> On 16.12.2013 08:30, Miklos Maroti wrote: >>>>>>> Hi Marcus, >>>>>>> >>>>>>> I do not think it is a compiler bug, but something >>>>>>> uninitialized. Constellation_qpsk and >>>>>>> constellation_calcdist does not crash (I did not verify if >>>>>>> they work). However, if I generate the LUT for >>>>>>> constellation_qpsk, then it crashes. >>>>>>> >>>>>>> # uname -a Linux maroti-t410 3.11.0-14-generic #21-Ubuntu >>>>>>> SMP Tue Nov 12 17:04:55 UTC 2013 x86_64 x86_64 x86_64 >>>>>>> GNU/Linux >>>>>>> >>>>>>> # gcc --version gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1 >>>>>>> >>>>>>> Using latest master branch of gnuradio, hash >>>>>>> 117058bac41c91, both CMAKE_BUILD_TYPE=Debug and Release >>>>>>> produces the same behavior >>>>>>> >>>>>>> # gdb `which python` core Reading symbols from >>>>>>> /usr/bin/pytho
Re: [Discuss-gnuradio] constellation soft decoder
Hi Marcus, > Anyway, I think Miklos is right: There is an error in calc_soft_dec in > using the pre_diff_code even in the case that it is not set or its > application disabled. > > Miklos, would you be as nice as to file a bug for that? You're the one > who successfully diagnosed that. Can you guys add me to the list of developers (user name: mmaroti)? Then I can file the bug report. In the mean time, I might be able to put together a pull request, just fixing the calc_soft_dec code. > (You may, btw, simply think of > pre_diff_code simply as an index set of the constellation points) I do not understand. It is just an extra permutation of the constellation points. If this is so, then why do you not just permute the constellation points, which makes everything faster. Do you have any use case where simply permuting the constellation vector would not achieve the same result? I also worry about performance. Even for BPSK, QPSK and 8PSK the soft decoding is not optimized, but could be much simpler than the general algorithm. Same goes for QAM, but I have not looked those really closely. Miklos > > Greetings, > Marcus > > On 16.12.2013 14:29, Philip Balister wrote: >> On 12/16/2013 08:16 AM, Miklos Maroti wrote: >>> Hi Marcus, >>> >>> Ok, that makes sense. It does not crash with QPSK, but it does >>> with BPSK and 8PSK, and BPSK and 8PSK do not set the >>> pre_diff_code. This explains why there is crash in one case and >>> not the other. Although neither sets the apply_pre_diff_code, so >>> even QPSK should not set pre_diff_code. >> >> I took a quick look in Coverity for issues in gr-digital. It flags >> a bunch of uninitialized variables. I'll try and take a look at >> these this week. >> >> There is an intermittent QA failure in some QA code and this might >> be an explanation. >> >> Philip >> >>> >>> I think the real problem is in constellation::calc_soft_dec. I >>> does not check whether d_apply_pre_diff_code is set or not. >>> >>> (By the way, I do not understand the usefulness of pre_diff_code. >>> Can you just permute the constellation points and get the same >>> effect?) >>> >>> Miklos >>> >>> On Mon, Dec 16, 2013 at 1:34 PM, Marcus Müller >>> wrote: Well, after having a debug build and >>> then adding a lot of "volatile"s into the code at the crashing >>> function, it looks as if the d_pre_diff_code of the constellation >>> has size 0; and thus, you can't access the 0. (read: first) >>> element. How this could happen with a QPSK object is currently >>> subject to my confusion. Stay tuned for more confusing facts as >>> the code unfolds :). >>> >>> Greetings, Marcus >>> >>> On 16.12.2013 08:30, Miklos Maroti wrote: >>>>>> Hi Marcus, >>>>>> >>>>>> I do not think it is a compiler bug, but something >>>>>> uninitialized. Constellation_qpsk and >>>>>> constellation_calcdist does not crash (I did not verify if >>>>>> they work). However, if I generate the LUT for >>>>>> constellation_qpsk, then it crashes. >>>>>> >>>>>> # uname -a Linux maroti-t410 3.11.0-14-generic #21-Ubuntu >>>>>> SMP Tue Nov 12 17:04:55 UTC 2013 x86_64 x86_64 x86_64 >>>>>> GNU/Linux >>>>>> >>>>>> # gcc --version gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1 >>>>>> >>>>>> Using latest master branch of gnuradio, hash >>>>>> 117058bac41c91, both CMAKE_BUILD_TYPE=Debug and Release >>>>>> produces the same behavior >>>>>> >>>>>> # gdb `which python` core Reading symbols from >>>>>> /usr/bin/python2.7...(no debugging symbols found)...done. >>>>>> >>>>>> warning: core file may not match specified executable file. >>>>>> [New LWP 2249] [New LWP 2251] [New LWP 2240] [New LWP 2248] >>>>>> [New LWP 2247] [New LWP 2239] [New LWP 2250] >>>>>> >>>>>> warning: Can't read pathname for load map: Input/output >>>>>> error. [Thread debugging using libthread_db enabled] Using >>>>>> host libthread_db library >>>>>> "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was >>>>>> generated by `python ./constellation_simulation.py'. >>>>>> Program terminated with signal 11, Segmentation fau
Re: [Discuss-gnuradio] constellation soft decoder
Hi Marcus,
Ok, that makes sense. It does not crash with QPSK, but it does with
BPSK and 8PSK, and BPSK and 8PSK do not set the pre_diff_code. This
explains why there is crash in one case and not the other. Although
neither sets the apply_pre_diff_code, so even QPSK should not set
pre_diff_code.
I think the real problem is in constellation::calc_soft_dec. I does
not check whether d_apply_pre_diff_code is set or not.
(By the way, I do not understand the usefulness of pre_diff_code. Can
you just permute the constellation points and get the same effect?)
Miklos
On Mon, Dec 16, 2013 at 1:34 PM, Marcus Müller wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Well, after having a debug build and then adding a lot of "volatile"s
> into the code at the crashing function, it looks as if the
> d_pre_diff_code of the constellation has size 0; and thus, you can't
> access the 0. (read: first) element. How this could happen with a QPSK
> object is currently subject to my confusion. Stay tuned for more
> confusing facts as the code unfolds :).
>
> Greetings,
> Marcus
>
> On 16.12.2013 08:30, Miklos Maroti wrote:
>> Hi Marcus,
>>
>> I do not think it is a compiler bug, but something uninitialized.
>> Constellation_qpsk and constellation_calcdist does not crash (I
>> did not verify if they work). However, if I generate the LUT for
>> constellation_qpsk, then it crashes.
>>
>> # uname -a Linux maroti-t410 3.11.0-14-generic #21-Ubuntu SMP Tue
>> Nov 12 17:04:55 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>>
>> # gcc --version gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
>>
>> Using latest master branch of gnuradio, hash 117058bac41c91, both
>> CMAKE_BUILD_TYPE=Debug and Release produces the same behavior
>>
>> # gdb `which python` core Reading symbols from
>> /usr/bin/python2.7...(no debugging symbols found)...done.
>>
>> warning: core file may not match specified executable file. [New
>> LWP 2249] [New LWP 2251] [New LWP 2240] [New LWP 2248] [New LWP
>> 2247] [New LWP 2239] [New LWP 2250]
>>
>> warning: Can't read pathname for load map: Input/output error.
>> [Thread debugging using libthread_db enabled] Using host
>> libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> Core was generated by `python ./constellation_simulation.py'.
>> Program terminated with signal 11, Segmentation fault. #0
>> 0x7f98dbbe01a7 in gr::digital::constellation::calc_soft_dec (
>> this=0x48321c0, sample=..., npwr=) at
>> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
>>
>>
> 286for(int j = 0; j < k; j++) {
>>
>> i stack #0 0x7f98dbbe01a7 in
>> gr::digital::constellation::calc_soft_dec ( this=0x48321c0,
>> sample=..., npwr=) at
>> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
>>
>>
> #1 0x7f98dbbe0f7e in gr::digital::constellation::soft_decision_maker (
>> this=0x48321c0, sample=...) at
>> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:355
>>
>>
> #2 0x7f98dbbe94dc in
>> gr::digital::constellation_soft_decoder_cf_impl::work
>> (this=0x4fb11a0, noutput_items=8190, input_items=...,
>> output_items=...) at
>> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation_soft_decoder_cf_impl.cc:68
>>
>>
> #3 0x7f98e1c5dd38 in gr::sync_interpolator::general_work (
>> this=0x4fb11c0, noutput_items=, ninput_items=...,
>> input_items=..., output_items=...) at
>> /home/mmaroti/workspace/gnuradio/gnuradio-runtime/lib/sync_interpolator.cc:67
>>
>> You should be able to reproduce the problem quite easily, but if
>> needed I can provided a test program.
>>
>> Best, Miklos
>>
>> On Mon, Dec 16, 2013 at 7:59 AM, Marcus Müller
>> wrote:
>>> Could you post the whole backtrace (as a github gist, pastebin
>>> etc)? That would be very helpful, along with information such
>>> as: Compiler (Gcc (version), VC++, clang ...), Platform (Linux,
>>> win, mac,...), architecture (x86(64), ARMv9, IBM S7390,...) and
>>> GNU Radio source version.
>>>
>>> Thanks and happy hacking, Marcus
>>>
>>> On 12/16/2013 01:05 AM, Miklos Maroti wrote:
>>>>
>>>> Hi Guys,
>>>>
>>>> Constellation soft decoder crashes for constellation_bpsk()
>>>> and constellation_8psk(). I could not find the cause of this
>>>> problem, the back trace on my machine points to
>>>>
>>>> gnuradio/gr-digital/lib/constellat
Re: [Discuss-gnuradio] constellation soft decoder
Hi Marcus,
I do not think it is a compiler bug, but something uninitialized.
Constellation_qpsk and constellation_calcdist does not crash (I did
not verify if they work). However, if I generate the LUT for
constellation_qpsk, then it crashes.
# uname -a
Linux maroti-t410 3.11.0-14-generic #21-Ubuntu SMP Tue Nov 12 17:04:55
UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
# gcc --version
gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
Using latest master branch of gnuradio, hash 117058bac41c91, both
CMAKE_BUILD_TYPE=Debug and Release produces the same behavior
# gdb `which python` core
Reading symbols from /usr/bin/python2.7...(no debugging symbols found)...done.
warning: core file may not match specified executable file.
[New LWP 2249]
[New LWP 2251]
[New LWP 2240]
[New LWP 2248]
[New LWP 2247]
[New LWP 2239]
[New LWP 2250]
warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `python ./constellation_simulation.py'.
Program terminated with signal 11, Segmentation fault.
#0 0x7f98dbbe01a7 in gr::digital::constellation::calc_soft_dec (
this=0x48321c0, sample=..., npwr=)
at /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
286for(int j = 0; j < k; j++) {
i stack
#0 0x7f98dbbe01a7 in gr::digital::constellation::calc_soft_dec (
this=0x48321c0, sample=..., npwr=)
at /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
#1 0x7f98dbbe0f7e in gr::digital::constellation::soft_decision_maker (
this=0x48321c0, sample=...)
at /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:355
#2 0x7f98dbbe94dc in
gr::digital::constellation_soft_decoder_cf_impl::work (this=0x4fb11a0,
noutput_items=8190, input_items=..., output_items=...)
at
/home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation_soft_decoder_cf_impl.cc:68
#3 0x7f98e1c5dd38 in gr::sync_interpolator::general_work (
this=0x4fb11c0, noutput_items=, ninput_items=...,
input_items=..., output_items=...)
at
/home/mmaroti/workspace/gnuradio/gnuradio-runtime/lib/sync_interpolator.cc:67
You should be able to reproduce the problem quite easily, but if
needed I can provided a test program.
Best,
Miklos
On Mon, Dec 16, 2013 at 7:59 AM, Marcus Müller wrote:
> Could you post the whole backtrace (as a github gist, pastebin etc)?
> That would be very helpful, along with information such as:
> Compiler (Gcc (version), VC++, clang ...), Platform (Linux, win, mac,...),
> architecture (x86(64), ARMv9, IBM S7390,...) and GNU Radio source version.
>
> Thanks and happy hacking,
> Marcus
>
> On 12/16/2013 01:05 AM, Miklos Maroti wrote:
>>
>> Hi Guys,
>>
>> Constellation soft decoder crashes for constellation_bpsk() and
>> constellation_8psk(). I could not find the cause of this problem, the
>> back trace on my machine points to
>>
>> gnuradio/gr-digital/lib/constellation.cc:286
>> for(int j = 0; j < k; j++) {
>>
>> which does not make any sense. Any idea what could go wrong?
>>
>> Miklos
>>
>> ___
>> 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] constellation soft decoder
Hi Guys,
Constellation soft decoder crashes for constellation_bpsk() and
constellation_8psk(). I could not find the cause of this problem, the
back trace on my machine points to
gnuradio/gr-digital/lib/constellation.cc:286
for(int j = 0; j < k; j++) {
which does not make any sense. Any idea what could go wrong?
Miklos
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD error on first connection
Hi Guys, When I boot up my computer and try to connect to an USRP2 node, then the first connection never works, but subsequent ones are working perfectly. 1) uhd_find_devices always works: linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.004-5-g6bb62ea3 -- -- UHD Device 0 -- Device Address: type: usrp2 addr: 192.168.10.2 name: serial: 322 2) but uhd_usrp_probe does not work at the first try: linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.004-5-g6bb62ea3 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1116 bytes UHD Error: Control packet attempt 0, sequence number 1: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 1, sequence number 2: RuntimeError: no control response, possible packet loss UHD Error: Control packet attempt 2, sequence number 3: RuntimeError: no control response, possible packet loss Error: RuntimeError: link dead: timeout waiting for control packet ACK 3) my system is Linux node1-2.sb2.orbit-lab.org 3.5.0-43-generic #66~precise1-Ubuntu SMP Thu Oct 24 14:52:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux 4) pinging the usrp2 node does not help, no matter what I do, I can never access the usrp2 right away, only on the second and subsequent try. Any idea what could cause this? Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The GSoC project on LDPC codes.
Wow, interesting to read all about this. Thanks for all the good work. Miklos On Wed, Nov 6, 2013 at 3:17 PM, Manu T S wrote: > Hi Miklos, > > The implementation is quite slow. I don't have any quantitative performance > measures, yet. > Nevertheless I have some empirical measures. For example, on testing the > implementation (all C++ and no GNU Radio) with a (8000, 4000) code(rate 0.5, > regular), in with AWGN of 0.8 added to it (capacity 0.678), > it took about 15-20 minutes[*] on an i7 machine to transmit and decode 100 > blocks. With smaller noise, this will be done a bit faster, for the number > of decoding iterations required is less. > > The major time consuming factor in the implementation is the encoder > construction. You may find the encoding method I implemented in the report. > It has a complexity of O((NM)^2). Once we have the encoder matrix encoding > is done in O(K^2) time. Decoding doesn't take that much time, but the > current space requirement is huge. I'm using a M x N matrix(double elements) > to hold the messages being passed between check nodes and variable nodes. > For the (8000, 4000) code that turns out to be some 244 MB. Since H is > sparse, most of the entries in the M x N message matrix is 0 and not used. > > So these are the things in my agenda for the near future. > 1. Improving the space requirement in the decoder. > 2. Find better methods(eg. Sparse LU) to implement encoder. > > I will start work with VOLK after the above mentioned improvements. > > > [*] As I said before encoder construction took huge time. So to test the > codes, I generated the encoder matrix and saved it in a separate alist file. > This file is not generally sparse. The file size would depend on the > structure of the code. For example, for the (8000, 4000) code the size of > the alist file for the encoder matrix was about 64MB. The only gain here is > that we need not generate the encoder matrix every time we need to use this > code. We can load it from the alist file. Had I not done this, the > experiment would have taken longer. > > > On Wed, Nov 6, 2013 at 5:47 PM, Miklos Maroti > wrote: >> >> Hi Manu, >> >> Thanks for the report, it was more informative than the presentation. >> Yes, I have seen the BER figure, but that is not very will presented >> (e.g. you should use logarithmic scale for BER) and should have better >> resolution on the Eb/N0 axes. You write that it does not use VOLK or >> SSE2. How fast is it? Do you have any performance number? Do you plan >> to work on it in the near future? >> >> Miklos >> >> On Wed, Nov 6, 2013 at 5:38 AM, Manu T S wrote: >> > Hello Mikios >> > >> > Here is the link to the presentation and report I made for my >> > thesis(intermediate evaluation) at IIT Bombay. Last part describes the >> > results I have obtained. >> > It has a BER plot as well. >> > >> > https://github.com/manuts/first_stage/blob/master/ppt.pdf >> > https://github.com/manuts/first_stage/blob/master/report.pdf >> > >> > The implementation is generic, in the sense that if you input a code (in >> > alist file format), we can construct the encoder and decoder. >> > The decoder merely implements sum product algorithm. I have tested it >> > against many regular codes, where there was the significant gap between >> > the >> > rate and the capacity. I'm yet to test it against an irregular code of >> > large >> > block length, mainly because the encoder and decoder becomes really >> > slow. >> > (Many optimizations are still in order.) >> > >> > I wish I could tell you I had a better BER plot, but what's there in the >> > report is all I have currently. >> > Thanks for checking out. >> > >> > >> > On Tue, Nov 5, 2013 at 11:08 PM, Miklos Maroti >> > >> > wrote: >> >> >> >> Dear Manu, >> >> >> >> Do you have any performance numbers on your LDPC decoder? I could not >> >> find any info, even in your presentation. Do you have also a BER >> >> figure, or even better would be some technical report. I would love to >> >> get some sense on the performance of your implementation. >> >> >> >> Best, >> >> Miklos >> >> >> >> On Tue, Nov 5, 2013 at 6:15 PM, Manu T S wrote: >> >> > Dear Max, >> >> > >> >> > You are correct. It is a bug. Now I'm wondering why I didn't get any >> >> > segmentation faults. >> >> &g
Re: [Discuss-gnuradio] The GSoC project on LDPC codes.
Hi Manu,
Thanks for the report, it was more informative than the presentation.
Yes, I have seen the BER figure, but that is not very will presented
(e.g. you should use logarithmic scale for BER) and should have better
resolution on the Eb/N0 axes. You write that it does not use VOLK or
SSE2. How fast is it? Do you have any performance number? Do you plan
to work on it in the near future?
Miklos
On Wed, Nov 6, 2013 at 5:38 AM, Manu T S wrote:
> Hello Mikios
>
> Here is the link to the presentation and report I made for my
> thesis(intermediate evaluation) at IIT Bombay. Last part describes the
> results I have obtained.
> It has a BER plot as well.
>
> https://github.com/manuts/first_stage/blob/master/ppt.pdf
> https://github.com/manuts/first_stage/blob/master/report.pdf
>
> The implementation is generic, in the sense that if you input a code (in
> alist file format), we can construct the encoder and decoder.
> The decoder merely implements sum product algorithm. I have tested it
> against many regular codes, where there was the significant gap between the
> rate and the capacity. I'm yet to test it against an irregular code of large
> block length, mainly because the encoder and decoder becomes really slow.
> (Many optimizations are still in order.)
>
> I wish I could tell you I had a better BER plot, but what's there in the
> report is all I have currently.
> Thanks for checking out.
>
>
> On Tue, Nov 5, 2013 at 11:08 PM, Miklos Maroti
> wrote:
>>
>> Dear Manu,
>>
>> Do you have any performance numbers on your LDPC decoder? I could not
>> find any info, even in your presentation. Do you have also a BER
>> figure, or even better would be some technical report. I would love to
>> get some sense on the performance of your implementation.
>>
>> Best,
>> Miklos
>>
>> On Tue, Nov 5, 2013 at 6:15 PM, Manu T S wrote:
>> > Dear Max,
>> >
>> > You are correct. It is a bug. Now I'm wondering why I didn't get any
>> > segmentation faults.
>> >
>> > Probably I didn't get any segmentation faults because, after i = M - 1,
>> > EOF
>> > has reached.
>> >
>> > Thanks for the correction.
>> >
>> >
>> > On Tue, Nov 5, 2013 at 9:14 PM, ikjtel wrote:
>> >>
>> >> Greetings
>> >>
>> >> I was very interested in this project for possible application to the
>> >> op25
>> >> project, since P25 uses several FEC codes
>> >> including RS and other block codes. I've brought up the gr-ldpc
>> >> library
>> >> and have a few questions. Due to the hateful YAhoo mail composer, I'm
>> >> hesitant to post lengthy emails to the general list with no opportunity
>> >> for
>> >> preview prior to hitting SEND, so I'll try breaking up the list of
>> >> questions
>> >> into several posts, one per question...
>> >>
>> >> First question: I was getting lots of errors, seg faults, aborts, and
>> >> other misbehavior from the code, which were traced to an apparent bug
>> >> in
>> >> alist.cc, all of which cleared up when I applied the following patch:
>> >>
>> >> --- ../../repo/gr-ldpc/lib/alist.cc 2013-10-18 10:25:47.508781061
>> >> -0400
>> >> +++ ./alist.cc 2013-11-05 11:21:03.879972116 -0500
>> >> @@ -123,7 +123,7 @@
>> >> }
>> >>
>> >> // Parse indices with non zero entries in ith row
>> >> -for (int row = 0; row < N; row++) {
>> >> +for (int row = 0; row < M; row++) {
>> >> std::getline(file, line);
>> >> ss << line;
>> >> for (int entry = 0; entry < num_mlist[row]; entry++) {
>> >>
>> >> Can you confirm, is this really a bug?
>> >>
>> >> Thanks and Best
>> >>
>> >> Max
>> >
>> >
>> >
>> >
>> > --
>> > Manu T S
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>
>
>
>
> --
> Manu T S
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The GSoC project on LDPC codes.
Dear Manu,
Do you have any performance numbers on your LDPC decoder? I could not
find any info, even in your presentation. Do you have also a BER
figure, or even better would be some technical report. I would love to
get some sense on the performance of your implementation.
Best,
Miklos
On Tue, Nov 5, 2013 at 6:15 PM, Manu T S wrote:
> Dear Max,
>
> You are correct. It is a bug. Now I'm wondering why I didn't get any
> segmentation faults.
>
> Probably I didn't get any segmentation faults because, after i = M - 1, EOF
> has reached.
>
> Thanks for the correction.
>
>
> On Tue, Nov 5, 2013 at 9:14 PM, ikjtel wrote:
>>
>> Greetings
>>
>> I was very interested in this project for possible application to the op25
>> project, since P25 uses several FEC codes
>> including RS and other block codes. I've brought up the gr-ldpc library
>> and have a few questions. Due to the hateful YAhoo mail composer, I'm
>> hesitant to post lengthy emails to the general list with no opportunity for
>> preview prior to hitting SEND, so I'll try breaking up the list of questions
>> into several posts, one per question...
>>
>> First question: I was getting lots of errors, seg faults, aborts, and
>> other misbehavior from the code, which were traced to an apparent bug in
>> alist.cc, all of which cleared up when I applied the following patch:
>>
>> --- ../../repo/gr-ldpc/lib/alist.cc 2013-10-18 10:25:47.508781061
>> -0400
>> +++ ./alist.cc 2013-11-05 11:21:03.879972116 -0500
>> @@ -123,7 +123,7 @@
>> }
>>
>> // Parse indices with non zero entries in ith row
>> -for (int row = 0; row < N; row++) {
>> +for (int row = 0; row < M; row++) {
>> std::getline(file, line);
>> ss << line;
>> for (int entry = 0; entry < num_mlist[row]; entry++) {
>>
>> Can you confirm, is this really a bug?
>>
>> Thanks and Best
>>
>> Max
>
>
>
>
> --
> Manu T S
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to get multipe rx_time tags while receiving continuously
Hi Harry, You never stop the receiver on node B and C, right? You should not observe anything like that if you do not have dropped packets. Are you using USRP2's? Miklos On Sat, Nov 2, 2013 at 3:05 AM, Harry Zhang wrote: > Tom, > Thanks for your reply. > I got a weird problem when using rx_time tags. I have three nodes, node > A sends 10 packets within 0.2 sec ,stops for 1sec sends 10 packets , > stops..., sends,stops . Node B and C receive it and record the > receive time using (rx_time+ sample_count*sample_rate). Considerating the > clock offset between B and C, the difference of B and C's receive time must > remain stable. But every time after A stops for 1sec, the receive time's > difference varies several hundreds of microsecond. I'm stumped by this > problem. > Could you give me some advice. Thank you in advance. > > Harry > > 2013/11/1 22:26, Tom Rondeau wrote: >> >> On Thu, Oct 31, 2013 at 3:46 AM, Harry Zhang wrote: >>> >>> Hi, >>> As far as I know rx_time tag is associated with the first sample of a >>> receive stream. If I wanna get multiple rx_time tags while receiving >>> continuous data, should I stop and issue a new stream again and again >>> for getting more rx_time tags. >>> Thank you. >> >> Harry, >> >> We want to minimize tags through the flowgraph since it adds overhead. >> The UHD driver only sends an rx_time tag whenever one is necessary. >> That means that if there is a chance that the host has become >> unsynchronized, it sends an updated tag. So there's one at the >> beginning of the stream to set the initial time. Then, if a dropped >> packet or overflow are detected, it sends a new rx_time tag. >> >> Between time tags, you can count samples and you know the sample rate, >> so you know the time of every sample based on that initial rx_time tag >> (to within the tolerance of the sample clock on the USRP). >> >> Tom >> > > > ___ > 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] Time synchronization between two USRPs without external signal
Hi Harry, On Sat, Oct 12, 2013 at 3:12 PM, Harry Zhang wrote: > Dear Miklos, > Thank you for your inspiring reply. > 1.I do think this method sounds like a receiver-receiver sync while sync > message's transmitter A also doing beacon node C's function ( (1)sending > sync message and (2)recording receive time which would be sended to B for > sync).Is it correct? Well, it is a transmitter-receiver synchronization, since only two nodes are involved A and B, and only A sends, B only receives. The real problem is to correlate samples with time, and I have used the RX chain sample counter as "time" both on node A and B. You cannot use PC time because of large errors over ethernet/USB so you have to use the clock of the FPGA. > 2.For 1us accuracy, does it mean the sample rate must be more than 1e6? Yes, of course. But you can even synchronize at 10 times the sampling rate (hard, but not impossible), i.e. you would use 1e6 sampling rate and get 1e7 precision. > 3.Does "close to zero samples" means the sample_rate*sample_offset > produces larger error when I use it for getting sync message's receive time? close to zero samples is complex numbers 1e^-4 + 1e^-4*j. The reason I do not use zero complex numbers is because I am afraid that the FPGA switches off the TX chain if you continuously try to transmit zeros. I am not sure that it does, you can experiment with that. > 4.The 1us is the jitter caused by sample duration.What about the jitter > produced by tx/rx tags? I do think 160us is mainly caused by the difference > between actual time when message leaving/arriving antenna and tx/rx tags's > time.What's your opinion? I do not know about the tx/rx tags. Of course the FPGA needs time to do the DSP, so it is possible that what you are seeing is the DSP time. However, the DSP time should be almost completely deterministic, so it cannot be a jitter just some time offset. If you see a jitter, then I think it must be caused by either ethernet or some DSP startup artifacts. Miklos > > Best, > Harry > > > 2013/10/12 19:17, Miklos Maroti wrote: >> >> Hi Harry, >> >> First, you should always transmit from node A, but when you want to be >> silent, then transmit something very close to zero complex numbers. >> This will ensure, that you have a nice continuous stream of data going >> out, and you can plan to do anything you want with sampling rate >> precision (better than 1us). Once you can do this, then transmit some >> pseudo random sequence from node A, e.g. BPSK with 2 samples per bit, >> and it is possible to synchronize to that with sampling rate precision >> again. Now comes the trick: node A not only transmits continuously, >> but it also receives continuously just like node B (with an antenna or >> just overhearing in the board). Both A and B synchronizes to the >> signal transmitted by A. In case of node A you do not have to worry of >> slightly different clocks, so once you are synchronized you will never >> get out of sync if you count the number of samples. In the case of >> node B it is harder, since node A might run a little faster or slower, >> so you will get out of sync, so you have to maintain synchronization. >> At this point, you have achieved synchronization of the two USRP >> nodes: you can stop sending periodically (continue spending close to >> zero samples) and then you can sample some data from node C, doing >> beam forming (depends on modulation), or whatever. You can correlate >> the received samples at node B with the received samples at node A >> with close to one sample precision (better than 1us). >> >> If you do not want to transmit all the time, then you can use TX tags, >> but it gets a little trickier, and I think there is some bug in the >> FPGA hardware to cause very rarely one sample shift between the TX and >> RX chain. I am not absolutely sure about this, but I could not explain >> something in any other way. >> >> Best, >> Miklos >> >> On Sat, Oct 12, 2013 at 10:10 AM, Harry Zhang wrote: >>> >>> Dear Miklos, >>> I'm glad to hear from you. >>> The idea of this experiment is quite similar to the core of your >>> honored >>> paper "The flooding time synchronization protocol". It's a >>> transmitter-receiver sync method using precious tx/rx timestamp to >>> synchronize transmitter's and receiver's local timer. >>> On the transmitter side, sync message is transmitted every 1 sec. >>> Using >>> rx tags, it's easy to get the average receive interval is 1.0003sec and >>> the >>> jitter
Re: [Discuss-gnuradio] Time synchronization between two USRPs without external signal
Hi Harry, First, you should always transmit from node A, but when you want to be silent, then transmit something very close to zero complex numbers. This will ensure, that you have a nice continuous stream of data going out, and you can plan to do anything you want with sampling rate precision (better than 1us). Once you can do this, then transmit some pseudo random sequence from node A, e.g. BPSK with 2 samples per bit, and it is possible to synchronize to that with sampling rate precision again. Now comes the trick: node A not only transmits continuously, but it also receives continuously just like node B (with an antenna or just overhearing in the board). Both A and B synchronizes to the signal transmitted by A. In case of node A you do not have to worry of slightly different clocks, so once you are synchronized you will never get out of sync if you count the number of samples. In the case of node B it is harder, since node A might run a little faster or slower, so you will get out of sync, so you have to maintain synchronization. At this point, you have achieved synchronization of the two USRP nodes: you can stop sending periodically (continue spending close to zero samples) and then you can sample some data from node C, doing beam forming (depends on modulation), or whatever. You can correlate the received samples at node B with the received samples at node A with close to one sample precision (better than 1us). If you do not want to transmit all the time, then you can use TX tags, but it gets a little trickier, and I think there is some bug in the FPGA hardware to cause very rarely one sample shift between the TX and RX chain. I am not absolutely sure about this, but I could not explain something in any other way. Best, Miklos On Sat, Oct 12, 2013 at 10:10 AM, Harry Zhang wrote: > Dear Miklos, > I'm glad to hear from you. > The idea of this experiment is quite similar to the core of your honored > paper "The flooding time synchronization protocol". It's a > transmitter-receiver sync method using precious tx/rx timestamp to > synchronize transmitter's and receiver's local timer. > On the transmitter side, sync message is transmitted every 1 sec. Using > rx tags, it's easy to get the average receive interval is 1.0003sec and the > jitter is around 320us. Considering the interval jitter is 2*(rx jitter+rx > jitter), the sync accuracy is 160us. > I wanna break into USRP FPGA to achieve 1us or less accuracy. And I > don't understand your "continuously transmission". Could give me some > details. > > > 2013/10/12 9:03, Miklos Maroti wrote: > > Hi Harrz, > > What do you mean by 160us precision? How did you measure it or compute > it exactly? I do not understand your goal, but it is quite simple to > synchronize two usrps with continuous transmission to within one > sample and if you continuously receive the transmitted signal on the > transmitter side, then you can avoid all time stamping problems and > effectively synchronize the tx and rx chains of a single usrp. > > Miklos > > On Thu, Oct 10, 2013 at 3:51 PM, Harry Zhang wrote: > > Hi, > I have implemented time synchronization between two USRPs without GPSDO, > MIMO cable or referring to computer's time.It's a sender-receiver method > based on message exchange. It will be included in my next paper soon. > I use the tx_time and tx_sob tag to transmit the message at the planned > time. When this message researches the receiver, I can get the receive > time via rx_time tags. The transmit and receive time of tx tags and rx > tags are recorded in USRP motherboard without the jitter of Ethernet > cable or operating system. So I think it could achieve the best accuracy > without modifying FPGA. > The experiment shows the accuracy is around 160us. I think it's mostly > caused by the jitter of the tx tag's time. I wanna achieve better > accuracy than this and the best way is adding a hardware timestamp > module in FPGA. Is this way feasible? > As for now, I wanna get a depth understanding of the implementing of tx > tag,so I will know the accuracy limit of this method. But I'm not > familiar with the FPGA, so could anyone describe how tx_time tag > implemented or give me some documents about this? > Thanks in advance. > > ___ > 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] Time synchronization between two USRPs without external signal
Hi Harrz, What do you mean by 160us precision? How did you measure it or compute it exactly? I do not understand your goal, but it is quite simple to synchronize two usrps with continuous transmission to within one sample and if you continuously receive the transmitted signal on the transmitter side, then you can avoid all time stamping problems and effectively synchronize the tx and rx chains of a single usrp. Miklos On Thu, Oct 10, 2013 at 3:51 PM, Harry Zhang wrote: > Hi, > I have implemented time synchronization between two USRPs without GPSDO, > MIMO cable or referring to computer's time.It's a sender-receiver method > based on message exchange. It will be included in my next paper soon. > I use the tx_time and tx_sob tag to transmit the message at the planned > time. When this message researches the receiver, I can get the receive > time via rx_time tags. The transmit and receive time of tx tags and rx > tags are recorded in USRP motherboard without the jitter of Ethernet > cable or operating system. So I think it could achieve the best accuracy > without modifying FPGA. > The experiment shows the accuracy is around 160us. I think it's mostly > caused by the jitter of the tx tag's time. I wanna achieve better > accuracy than this and the best way is adding a hardware timestamp > module in FPGA. Is this way feasible? > As for now, I wanna get a depth understanding of the implementing of tx > tag,so I will know the accuracy limit of this method. But I'm not > familiar with the FPGA, so could anyone describe how tx_time tag > implemented or give me some documents about this? > Thanks in advance. > > ___ > 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] swig madness
Hi Michael,
Unfortunately, the problem is not always reproducible with a simple
"cmake ../ && make clean && make", I have to remove the build
directory completely. I have tried all combinations, and now I seem to
have something that seem to work. The problem is that I need a
rational_sync_block(void) {} // allows pure virtual interface sub-classes
constructor in order to declare interface classes in my include
directory. These interface classes are inheriting from
rational_sync_block with virtual inheritance. So when SWIG is scanning
the header files, then it decides that it is going to create a wrapper
around the empty constructor (and I do not know why it does this). But
you cannot instantiate this interface class, you have to use make
which will create the proper implementation. Anyhow, the solution was
to conditionally create a different class definition for swig like
below. If I do not do this special case, then the error is there.
Also, it is not clear what and how to set up my swig .i file, but some
combination seems to work now.
#ifdef SWIG_VERSION
class rational_sync_block : public gr::sync_block
{
protected:
rational_sync_block(const std::string &name,
gr::io_signature::sptr input_signature, gr::io_signature::sptr
output_signature,
unsigned int interpolation, unsigned int decimation);
};
#else
class rational_sync_block: public gr::sync_block
{
private:
unsigned int d_interpolation;
unsigned int d_decimation;
protected:
rational_sync_block(void) {} // allows pure virtual interface sub-classes
rational_sync_block(const std::string &name,
gr::io_signature::sptr input_signature, gr::io_signature::sptr
output_signature,
unsigned int interpolation, unsigned int decimation);
public:
unsigned int interpolation() const { return d_interpolation; }
unsigned int decimation() const { return d_interpolation; }
void set_interpolation(unsigned int interpolation, unsigned int decimation);
int fixed_rate_ninput_to_noutput(int ninput);
int fixed_rate_noutput_to_ninput(int noutput);
void forecast(int noutput_items, gr_vector_int &ninput_items_required);
// derived classes should override work
int general_work(int noutput_items, gr_vector_int &ninput_items,
gr_vector_const_void_star &input_items, gr_vector_void_star
&output_items);
};
#endif
Miklos
On Sat, Oct 5, 2013 at 12:11 AM, Michael Berman wrote:
> Miklos,
>
> Have you imported all of the gnuradio files into the swig .i file that you
> are using within your OOT module? I recently went through this, and I had
> to include a gnuradio header into my swig .i file as shown below; I'm not
> entirely sure what the two include declarations are for, but I needed both
> to work.
>
> %{
> #include "gnuradio/digital/constellation.h"
> #include ""
> %}
> %include "gnuradio/digital/constellation.h"
> %include ""
>
> Also, make sure you include the appropriate .so file of any gnuradio object
> you are using into the CMakeList.txt file, otherwise you may get a runtime
> error as it cannot find the object you are referencing within gnuradio.
>
> Michael Berman
>
>
>
>
> On Fri, Oct 4, 2013 at 2:36 PM, Miklos Maroti
> wrote:
>>
>> Hi Guys,
>>
>> I am trying to create a rational_sync_block class in an out of tree
>> module, which is both an interpolator and decimator with a rational
>> data rate. So I just wrote the class, almost exactly like how
>> sync_interpolator is written. Then when I want to use this new base
>> class in a derived real block named xxx_block in my out of tree
>> module, then everything compiles, but the swig generation fails with
>> an error message that xxx_block cannot be allocated because it is
>> abstract type has an virtual work function. When I change the base
>> type back to sync_interpolator, then swig is happy. I do not
>> understand what is so special about gr::sync_interpolator, and why I
>> cannot reproduce the sync_interpolator in a way that makes swig happy.
>> Any ideas?
>>
>> Miklos
>>
>> ___
>> 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] swig madness
Hi Guys, I am trying to create a rational_sync_block class in an out of tree module, which is both an interpolator and decimator with a rational data rate. So I just wrote the class, almost exactly like how sync_interpolator is written. Then when I want to use this new base class in a derived real block named xxx_block in my out of tree module, then everything compiles, but the swig generation fails with an error message that xxx_block cannot be allocated because it is abstract type has an virtual work function. When I change the base type back to sync_interpolator, then swig is happy. I do not understand what is so special about gr::sync_interpolator, and why I cannot reproduce the sync_interpolator in a way that makes swig happy. Any ideas? Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sync_interpolator
Thanks. This confirms what I was saying. Miklos
On Aug 28, 2013 7:07 AM, "Martin Braun (CEL)" wrote:
> Let's cover some signal processing basics:
>
> Say our block's input signal is x[k] and the output signal is y[k].
> Let's assume there's one input to keep things simple.
>
> If a block has a history of N, the output depends on N samples of the
> input, or
> y[k] = f(x[k], x[k-1], ..., x[k-N-1]).
>
> If the block is linear, then
> y[k] = \sum_{l = 0}^{N-1} a_l x[k-l]
> Any block like this is equivalent to an FIR filter, regardless of what
> it's called.
>
> But say we *are* actually filtering, and have an odd number of taps.
> How about making a filter with zero phase? That would ask for:
> y[k] = \sum_{l = (N-1)/2}^{(N-1)/2} a_l x[k-l]
>
> Whoops--if we want to keep causality, that won't work. /That's/ a block
> that would be looking into the future.[1]
>
> So we relax the requirements, and simply use the next samples we have
> available in the input buffer. But what about the delay line?
> GNU Radio understands this problem, and offers to take care of the delay
> line for you by providing set_history(). So let's think of set_history()
> as a signal-processing related setting.
>
> forecast() is an entirely different beast. It tells the scheduler how
> man input items a block requires before it can produce any (or a given
> amount of) output. In a sync block, we 'trick' the scheduler to give us
> more samples to include the delay line (when we consume noutput_items
> items, the delay line is still in there).
> So if you override forecast(), then yes, obviously, the scheduler will
> give you this much input. It's hard-wired to do so.
>
> In a sync block (and related, i.e. sync_interpolator), it is *always*
> clear how many input items I need to produce an number of output items.
> That's why forecast() needn't be overridden in those cases (probably:
> shouldn't); the stock blocks *do* stick to this (with, possibly, some
> exceptions but I can't think of any right now).
>
> In a gr::block, things are different. You only choose this type of block
> if you don't know the ratio input:output (or there isn't a rational
> one). An example of the latter is the fractional resampler (its
> forecast() looks very much like that of a sync_interpolator!).
> An example of the former would be any gr_tagged_stream_block.
>
> There are other settings that control streaming behaviour, such as
> set_output_multiple().
>
> If you have any more questions, do add some specifics of what you're
> trying to achieve.
>
> MB
>
> [1] The peak detector does this, and in a sense is looking into the
> future. But it has to look back inside the input buffer, and thus is
> causing latency, even if it doesn't look like it if your time
> reference is sample time.
>
>
> On Tue, Aug 27, 2013 at 12:43:34PM -0500, Miklos Maroti wrote:
> > Hi Martin,
> >
> > On Tue, Aug 27, 2013 at 3:07 AM, Martin Braun (CEL)
> > wrote:
> > > On Tue, Aug 27, 2013 at 02:43:32AM -0500, Miklos Maroti wrote:
> > >> Hi Martin,
> > >>
> > >> I have checked the tutorials, but they do not give precise details.
> > >
> > > http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules
> > > discusses the whole concept several times.
> > >
> > >> Here is what I have discovered with a general block:
> > >>
> > >> 1) set_history(1+m) will simply fill your input buffer with m many
> > >> zero items at startup, then your input data will follow.
> > >
> > > You're missing the point. In *every* work call, you will have 'm' extra
> > > samples to calculate your output.
> >
> > This is not true, unless you rely on the stock gnuradio blocks, like
> > sync_interpolator for which forecast actually requests "noutput_items
> > / interpolation() + history() - 1" input items. If what you are saying
> > were true, i.e. a general block would always give you 'm' extra input
> > after the set_history(1+m), then sync_interpolator would only need to
> > request "output_items / interpolation()" items.
> >
> > >> 2) If you actually want to see more samples in your work method, then
> > >> you have to increase the requested number of inputs in your forecast
> > >> method by history() - 1.
> > >
> > > OK, only mess around with forecast() if you know what you're doing.
> > > If you need the precise history inside forecast(), chances are the
> > > d
Re: [Discuss-gnuradio] sync_interpolator
Hi Martin,
On Tue, Aug 27, 2013 at 3:07 AM, Martin Braun (CEL)
wrote:
> On Tue, Aug 27, 2013 at 02:43:32AM -0500, Miklos Maroti wrote:
>> Hi Martin,
>>
>> I have checked the tutorials, but they do not give precise details.
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules
> discusses the whole concept several times.
>
>> Here is what I have discovered with a general block:
>>
>> 1) set_history(1+m) will simply fill your input buffer with m many
>> zero items at startup, then your input data will follow.
>
> You're missing the point. In *every* work call, you will have 'm' extra
> samples to calculate your output.
This is not true, unless you rely on the stock gnuradio blocks, like
sync_interpolator for which forecast actually requests "noutput_items
/ interpolation() + history() - 1" input items. If what you are saying
were true, i.e. a general block would always give you 'm' extra input
after the set_history(1+m), then sync_interpolator would only need to
request "output_items / interpolation()" items.
>> 2) If you actually want to see more samples in your work method, then
>> you have to increase the requested number of inputs in your forecast
>> method by history() - 1.
>
> OK, only mess around with forecast() if you know what you're doing.
> If you need the precise history inside forecast(), chances are the
> default behaviour will already do what you want.
I want to mess around with forecast, I want to understand how these
things interact. Sure, if you stick with stock blocks, then everything
will work, but the stock stuff is not good for me.
>> 3) To see actual history, you have to do both 1) and 2) and do NOT
>> consume in your work method every sample you have requested in
>> forecast, only the regular amount so you maintain the proper amount of
>> past samples in your input buffer.
>
> In a sync block, the input buffer is always history()-1 larger than the
> output buffer. Does this help?
It is, because in forecast it asked for that many input items more.
>> 4) You can do 2) alone without 1), but then you are going to work with
>> "future" samples. So you can always request more input but you are not
>> going to consume it, so you will see the future.
>
> If I understand you correctly: No!
I think you are wrong. You can set_history(1), and request
noutput_items + 10 in your forecast, then you will always have 10 more
extra samples in your general work, so you will see the future. Of
course you should consume noutput_items to maintain it that way.
>> 5) Many blocks (sync, sync_interpolator, sync_decimator, general) will
>> actually implement some default behaviour for your forecast method,
>> and there they take history() into account. However, if you
>> reimplement forecast() and forget to include your history, then in
>> your work method you are going to read garbage outside of your input
>> buffer (which will be hard to debug).
>
> You will always read garbage *outside* of your input buffer.
The question is how large the input buffer is. What I am claiming that
the size of the input buffer is always as large (or larger) as what
you have requested in your forecast method. If you ask for 10 input
samples in your forecast, then you get 10 samples no matter what the
history is!!!
>> 6) The amount of input items in your work method is exactly the amount
>> (or more) you have requested in your forecast, so magically you will
>> not have more input data because of set_history() is called.
>
> Let me put it this way: GNU Radio has many ways to configure the
> scheduling behaviour. You're not supposed to use *all* of them at once.
Why? Stock blocks use all of them!
> Think about what your block is doing. Do you really need to both change
> forecast() *and* fiddle with history()? Perhaps you do, but it does seem
> unlikely.
I know what I am doing, and I need that behavior, which cannot be
achieves with stock blocks. So the question remains: can you disprove
the above 6 claims?
Best,
Miklos
>
> MB
>
>>
>> Are these statements correct? Best,
>> Miklos
>>
>>
>> On Tue, Aug 27, 2013 at 2:19 AM, Martin Braun (CEL)
>> wrote:
>> > On Tue, Aug 27, 2013 at 12:11:48AM -0500, Miklos Maroti wrote:
>> >> Hi Guys,
>> >>
>> >> I do not understand how set_history and fixed rate blocks are
>> >> interacting. Supposedly, the scheduler can figure out a static
>> >> schedule for sync blocks. However, the sync_interpolator is forcasting
>> >> this
>> >>
>> >> int sync_interpolator::fixed_rate_noutput_to_ninput(int noutput_items) {
>&g
Re: [Discuss-gnuradio] sync_interpolator
Hi Martin,
I have checked the tutorials, but they do not give precise details.
Here is what I have discovered with a general block:
1) set_history(1+m) will simply fill your input buffer with m many
zero items at startup, then your input data will follow.
2) If you actually want to see more samples in your work method, then
you have to increase the requested number of inputs in your forecast
method by history() - 1.
3) To see actual history, you have to do both 1) and 2) and do NOT
consume in your work method every sample you have requested in
forecast, only the regular amount so you maintain the proper amount of
past samples in your input buffer.
4) You can do 2) alone without 1), but then you are going to work with
"future" samples. So you can always request more input but you are not
going to consume it, so you will see the future.
5) Many blocks (sync, sync_interpolator, sync_decimator, general) will
actually implement some default behaviour for your forecast method,
and there they take history() into account. However, if you
reimplement forecast() and forget to include your history, then in
your work method you are going to read garbage outside of your input
buffer (which will be hard to debug).
6) The amount of input items in your work method is exactly the amount
(or more) you have requested in your forecast, so magically you will
not have more input data because of set_history() is called.
Are these statements correct? Best,
Miklos
On Tue, Aug 27, 2013 at 2:19 AM, Martin Braun (CEL)
wrote:
> On Tue, Aug 27, 2013 at 12:11:48AM -0500, Miklos Maroti wrote:
>> Hi Guys,
>>
>> I do not understand how set_history and fixed rate blocks are
>> interacting. Supposedly, the scheduler can figure out a static
>> schedule for sync blocks. However, the sync_interpolator is forcasting
>> this
>>
>> int sync_interpolator::fixed_rate_noutput_to_ninput(int noutput_items) {
>> return noutput_items / interpolation() + history() - 1;
>> }
>>
>> but consumes only noutput_items / interpolation(). This means, that
>> the scheduler is making a schedule based on the wrong info, the block
>> is actually consuming LESS than it has predicted, so how can the
>> scheduler make optimal schedule?
>
> Hi Miklos,
>
> Think of the history as the number of *past* input samples it takes
> to produce one output sample. The classic example is an FIR filter,
> where you need as many samples as you have taps.
> Minimum is of course 1 (which means you need only the current sample).
> This is also the default value.
>
> In a sync_interpolator, noutput_items is always an integer multiple of
> ninput_items. So if you have no history configured, it must consume
> noutput_items / interpolation(). So what you're seeing is correct
> (unless you changed your history).
>
>> On this point, it is not clear how history() is handled. I searched
>> the archives, and the wisdom is, that set_history(2) means, that all
>
> I'm sure the topic of history() is covered in the tutorials. Also, what
> you're saying is correct and fits what I just explained above.
>
> MB
>
>> the ninput_items and noutput_items and their relationship is
>> completely unchanged, but we have an extra sample at the beginning of
>> the input buffer. However, the sync_interpolator does not do this, it
>> actually includes the history amount in the requested input. So does
>> the scheduler takes history amounts into account, and the
>> sync_interpolator has a bug, or every block has to add the history
>> into their forecast?
>>
>> This is really confusing. I hope someone can shed some light on this.
>>
>> Best,
>> Miklos
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> --
> Karlsruhe Institute of Technology (KIT)
> Communications Engineering Lab (CEL)
>
> Dipl.-Ing. Martin Braun
> Research Associate
>
> Kaiserstraße 12
> Building 05.01
> 76131 Karlsruhe
>
> Phone: +49 721 608-43790
> Fax: +49 721 608-46071
> www.cel.kit.edu
>
> KIT -- University of the State of Baden-Württemberg and
> National Laboratory of the Helmholtz Association
>
> ___
> 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] sync_interpolator
Hi Guys,
I do not understand how set_history and fixed rate blocks are
interacting. Supposedly, the scheduler can figure out a static
schedule for sync blocks. However, the sync_interpolator is forcasting
this
int sync_interpolator::fixed_rate_noutput_to_ninput(int noutput_items) {
return noutput_items / interpolation() + history() - 1;
}
but consumes only noutput_items / interpolation(). This means, that
the scheduler is making a schedule based on the wrong info, the block
is actually consuming LESS than it has predicted, so how can the
scheduler make optimal schedule?
On this point, it is not clear how history() is handled. I searched
the archives, and the wisdom is, that set_history(2) means, that all
the ninput_items and noutput_items and their relationship is
completely unchanged, but we have an extra sample at the beginning of
the input buffer. However, the sync_interpolator does not do this, it
actually includes the history amount in the requested input. So does
the scheduler takes history amounts into account, and the
sync_interpolator has a bug, or every block has to add the history
into their forecast?
This is really confusing. I hope someone can shed some light on this.
Best,
Miklos
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] inefficient large vectors
Hi Marcus, On Thu, Aug 22, 2013 at 12:00 PM, Marcus Müller wrote: > Just to add my two cents: > Depending on your actual application, your large vectors might not actually > quite fit the idea of "streams"; they might, for example, be a valid, > decoded network packet or something of the like. If they don't need > sample-synchronous handling, using messages to pass them around might work > well. > Downside of that is of course that you can't use your favourite GR block on > messages. You break the sample synchronous architecture of a flowgraph with > multiple paths from source(s) to sink(s); and if you convert from message to > stream and back, you basically lose the vector attribute of your data (or > run into the same problems as before). > I can't really tell you much about computational performance of passing > around large messages, however. > > On the other hand, you can reduce your per-block coding overhead for > Martin's suggested tag-based solution: > Write a base class that implements a input and output buffer and a minimal > state machine based on stream tag evaluation. Let your blocks inherit from > that. Always copy as many items from your general_work's input vector to > your input buffer as you can, and copy as many samples from the output > buffer to your general_works output vector as possible. Execute your > computation when your input buffer is full and your output buffer empty. > That way, you'll get a quasi-fixed relative rate, but get all the freedom > and scheduling disadvantages of a general_work block with an itemsize of > gr_complex (or whatever your data type is). > > I know from experience that this might be hard to debug. However, once your > state machine is watertight, you're not very likely to run into issues > later. Thank you for the excellent advice. I did not thought of a generic base class, which might help me. There is one block that produces one vector of bytes (packet data) and one vector of ints (number of errors corrected and uncorrected), which would be impossible to solve with a stream since the output rate is not the same. Other than this, I think your suggestion would work. You say that there are scheduling disadvantages of a general_work block. What are they? Sometimes I am running into issues with the scheduler, but it is not clear how it really works, what should I try to do and what should I try to avoid. Can you describe it in a few words or give a pointer where I can read upon the technical (!!) details. Best, Miklos > > Happy hacking, > Marcus > > > On 08/21/2013 07:59 PM, Miklos Maroti wrote: >> >> Hi! >> >> I have many sync blocks that work with large fixed size vectors, e.g. >> converts one vector of size 12659 to another with size 18353. I have >> just multiplied the sizeof(gr_complex) with 12659 and 18353 in the >> signature. However, when the flow graph is running, then I get a >> warning about paging: the circular buffer implementation allocates >> large buffers (e.g. 4096 many to make the paging requirement). I do >> not want really large buffers. I have implemented the whole thing with >> padding, but that becomes also really inefficient, since when you want >> to switch between vectors and streams, then you have to jump through >> extra hoops with the padding. In a previous version I had streams >> everywhere, but then there is absolutely no verification whether I >> messed up the sizes of my "virtual vectors". >> >> So is there a way to work with large odd length vectors which does not >> have this buffer allocation problem, and does not require padding? It >> seems to me that it could be supported: regular streams but the vector >> size would be verified separately at connection time and would not be >> used to multiply the item size. Any advice is appreciated... >> >> Best, >> Miklos >> >> ___ >> 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
Re: [Discuss-gnuradio] inefficient large vectors
Hi Martin, Yes, I know of stream tags, but it would just make the blocks complicated: now I can rely on the fact that data is coming in a multiple of the vector length. For now, padding solves my immediate needs, but it is not an ideal solution. Miklos On Wed, Aug 21, 2013 at 11:18 PM, Martin Braun (CEL) wrote: > On Wed, Aug 21, 2013 at 07:59:37PM +0200, Miklos Maroti wrote: >> So is there a way to work with large odd length vectors which does not >> have this buffer allocation problem, and does not require padding? It >> seems to me that it could be supported: regular streams but the vector >> size would be verified separately at connection time and would not be >> used to multiply the item size. Any advice is appreciated... > > Miklos, > > if Johnathan's tips aren't helping, you *might* be able to use tags to > delimit vectors and then pass them as streams of scalars. You then have > to keep up with vector boundaries internally in your block. > > Depending on what your application is, this could be a solution or can > make things even more inefficient. But it's worth a try! > > MB > > -- > Karlsruhe Institute of Technology (KIT) > Communications Engineering Lab (CEL) > > Dipl.-Ing. Martin Braun > Research Associate > > Kaiserstraße 12 > Building 05.01 > 76131 Karlsruhe > > Phone: +49 721 608-43790 > Fax: +49 721 608-46071 > www.cel.kit.edu > > KIT -- University of the State of Baden-Württemberg and > National Laboratory of the Helmholtz Association > > ___ > 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] inefficient large vectors
Hi Marcus, Yes, I understand the page size limitation. However, if your vector is 1234 bytes, then you can happily allocate 4096 size buffer, but the the block you always give out the multiple of 1234 byes (i.e. 1, 2 or 3 vectors). The address space wrapping would work fine, so the start of the vectors would not be always at the same place. I think it could be done, the question is whether it is worth to do it. Miklos On Wed, Aug 21, 2013 at 9:46 PM, Marcus D. Leech wrote: >> Yes, this is what I am doing, but it is not very nice, and you cannot >> easily mix in blocks that want to work at the stream level. What >> really bugs me that I think the scheduler could figure all out, and >> treat my vectors as a stream, allocate nice buffers (who cares if the >> vector fits in the buffer in an integer multiple times). Am I wrong >> with this? I think this would be a nice further development... Miklos >> >> > The aligned-to-page-size buffer management is due to the way that mmap() is > used to mutliply-map these buffers into the address space. > That only "works" if the sizes are multiples of the native page size. > > > -- > 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] inefficient large vectors
Yes, this is what I am doing, but it is not very nice, and you cannot easily mix in blocks that want to work at the stream level. What really bugs me that I think the scheduler could figure all out, and treat my vectors as a stream, allocate nice buffers (who cares if the vector fits in the buffer in an integer multiple times). Am I wrong with this? I think this would be a nice further development... Miklos On Wed, Aug 21, 2013 at 9:04 PM, Johnathan Corgan wrote: > On Wednesday, August 21, 2013, Miklos Maroti wrote: > >> >> I have many sync blocks that work with large fixed size vectors, e.g. >> converts one vector of size 12659 to another with size 18353. I have >> just multiplied the sizeof(gr_complex) with 12659 and 18353 in the >> signature. However, when the flow graph is running, then I get a >> warning about paging: the circular buffer implementation allocates >> large buffers (e.g. 4096 many to make the paging requirement). I do >> not want really large buffers. I have implemented the whole thing with >> padding, but that becomes also really inefficient, since when you want >> to switch between vectors and streams, then you have to jump through >> extra hoops with the padding. In a previous version I had streams >> everywhere, but then there is absolutely no verification whether I >> messed up the sizes of my "virtual vectors". >> >> So is there a way to work with large odd length vectors which does not >> have this buffer allocation problem, and does not require padding? It >> seems to me that it could be supported: regular streams but the vector >> size would be verified separately at connection time and would not be >> used to multiply the item size. Any advice is appreciated... > > > The best technique here is to round up your itemsize to the next integer > multiple of the machine page size, typically 4K. You can still operate a > vector at a time, but you'll have to do a little math to identify the start > of each vector in the input and output buffers, as they will no longer be > contiguous. It sounds like you might have already tried something like > this. > > > > -- > Johnathan Corgan > Corgan Labs - SDR Training and Development Services > http://corganlabs.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] inefficient large vectors
Hi! I have many sync blocks that work with large fixed size vectors, e.g. converts one vector of size 12659 to another with size 18353. I have just multiplied the sizeof(gr_complex) with 12659 and 18353 in the signature. However, when the flow graph is running, then I get a warning about paging: the circular buffer implementation allocates large buffers (e.g. 4096 many to make the paging requirement). I do not want really large buffers. I have implemented the whole thing with padding, but that becomes also really inefficient, since when you want to switch between vectors and streams, then you have to jump through extra hoops with the padding. In a previous version I had streams everywhere, but then there is absolutely no verification whether I messed up the sizes of my "virtual vectors". So is there a way to work with large odd length vectors which does not have this buffer allocation problem, and does not require padding? It seems to me that it could be supported: regular streams but the vector size would be verified separately at connection time and would not be used to multiply the item size. Any advice is appreciated... Best, Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GRCC generation
Hi!
I would like to add a CMAKE rule to my out of tree module to generate
hierarchical blocks from GRC files using the GRCC tool. However, GRCC
refuses to pus the generated py and xml files to the right directory,
and instead it always places them into the $HOME/.grc_modules
directory even if another one is specified with the --directory
option. The problem (I think) is in the Generator.py file, where
self._generate_options = self._flow_graph.get_option('generate_options')
if self._generate_options == 'hb':
self._mode = HIER_BLOCK_FILE_MODE
dirname = HIER_BLOCKS_LIB_DIR
else:
self._mode = TOP_BLOCK_FILE_MODE
dirname = os.path.dirname(file_path)
#handle the case where the directory is read-only
#in this case, use the system's temp directory
if not os.access(dirname, os.W_OK):
dirname = tempfile.gettempdir()
So all hierarchical blocks are placed to HIEAR_BLOCKS_LIB_DIR, and the
file path argument is discarded. So how can I generate python code and
xml files for hierarchical blocks from grc sources in an automated
way?
Miklos
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sampling glitch in the RX path
Hi John, Thanks for the quick reply. Increasing the lead time will just delay the occurrence of the storm of L's (when the host gets permanently behind the USRP). Here is some data which supports this claim and I think the TX/RX switch rate influences these: 1) I periodically send for 0.9 ms timed with tx_time, tx_sob, tx_eob, followed by 0.1 ms gap. I use 20 ms lead time, and I measure the number of seconds the flowgraph can run before it falls behind (lots of L's). I have run this 3 times, and got 43 sec, 44 sec, 37 sec. 2) 0.9 ms TX, 0.1 ms RX, 30 ms lead, runs for 60 sec, 53 sec, 67 sec 3) 0.9 ms TX, 0.1 ms RX, 40 ms lead, runs for 107 sec, 87 sec, 104 sec Thus run time increased linearly with the increase of the lead time. 4) 0.4 ms TX, 0.1 ms RX, 40 ms lead, runs for 55 sec, 62 sec, 54 sec Thus if you increase the rate of TX/RX switches then the run time decreases linearly 5) 1 ms TX, 1 ms RX, 20 ms lead, runs for 149 sec, 124 sec, 68 sec 6) 1 ms TX, 1 ms RX, 40 ms lead, runs for 391 sec, 219 sec, 283 sec Thus decreasing the packet rate will increase the run time. In scenario 5) and 6) it will gradually get more and more L's (between packets) until it hits the wall. And I also observe U's but no O's overruns. Thus as we are eating up our lead time and getting closer to the edge the USRP is not getting enough data and the times are getting worse and worse until all of the packets are in the past. >From this I deduce that there must be an RX sampling glitch when switching between TX/RX, no? Best, Miklos On Wed, Jun 5, 2013 at 11:16 AM, John Malsbury wrote: > If there are no overruns, you are most likely not dropping samples. The > switch from rx to tx and back will not impact the received sample stream. > Increase your packet lead time from 10 ms. Keep in mind that the PC will > have some process jitter so that actual transfer of the burst may vary from > the nominal 10 ms lead you're asking for. If the PC is a little slow, or > the OS is busy doing something else, you might deliver a late packet. > > Anyway, once you've got the system working consistently, you can working on > optimizing things for lower latency (lead time). > > -John > > > On Wed, Jun 5, 2013 at 8:58 AM, Miklos Maroti > wrote: >> >> Hi Guys, >> >> I am using N210 with SBX at 5M sampling rate. I have one USRP Source >> running continuously (connected to the TX/RX antenna), and a USRP Sink >> (connected also to TX/RX) that sends timed packets with the tx_time, >> tx_sob, tx_eob tags at a rate of 1 ms per packet. I am sending packets >> 10 ms prior to the USRP Sink and I use the sample counter of the USRP >> Source to monitor the time on the FPGA. >> >> After some time I am observing timing errors (L) that I cannot >> explain. The only possible explanation would be a sampling glitch in >> the RX path when switching between TX and RX. That is, it seems that a >> few samples are lost in the RX path when the switch is made, and >> therefore the FPGA time and the number of samples received are >> diverging over time (by a small amount for each switch). I do not >> observe this behavior at 500K sampling rate, there no RX samples seem >> to be lost. There are no underruns/overruns prior to the lots of L's. >> >> Any ideas why this is happening and whether it can be prevented somehow? >> >> Miklos >> >> ___ >> 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] Sampling glitch in the RX path
Hi Guys, I am using N210 with SBX at 5M sampling rate. I have one USRP Source running continuously (connected to the TX/RX antenna), and a USRP Sink (connected also to TX/RX) that sends timed packets with the tx_time, tx_sob, tx_eob tags at a rate of 1 ms per packet. I am sending packets 10 ms prior to the USRP Sink and I use the sample counter of the USRP Source to monitor the time on the FPGA. After some time I am observing timing errors (L) that I cannot explain. The only possible explanation would be a sampling glitch in the RX path when switching between TX and RX. That is, it seems that a few samples are lost in the RX path when the switch is made, and therefore the FPGA time and the number of samples received are diverging over time (by a small amount for each switch). I do not observe this behavior at 500K sampling rate, there no RX samples seem to be lost. There are no underruns/overruns prior to the lots of L's. Any ideas why this is happening and whether it can be prevented somehow? Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] half duplex set_auto_tx timing problems
Hi John, On Tue, Jun 4, 2013 at 7:38 PM, John Malsbury wrote: > Miklos, > > I'm not sure if what you're saying is correct. Switch U3 may not switch to > RX2 during tx in half-duplex operation. I would double check, but I don't Thanks! What I have observed, that adding an antenna to the RX2 connector does change the received samples during transmission, i.e. it overdrives it more.Maybe I am mistaken somewhere, but would appreciate if you would double check. From earlier discussions it seems that ATR state machine controls this behavior, right? > think it matters either way. If this is a half-duplex application, you > don't want to receive and transmit at the same time. So you should just > ignore samples from the uhd_source, or mute them while tx is enabled. In > this case, it doesn't matter what the RX path sees while it is switched to > the RX2 path. That is true, that I have to discard those samples anyways. However, I am worried that overdriving the receive path during transmission would have adverse effect on subsequent reception (few samples right after the TX -> RX switch). Do you think that is a real concern? Miklos > > -John > > > > On Tue, Jun 4, 2013 at 5:23 PM, Miklos Maroti > wrote: >> >> Hi John, >> >> Thanks for the excellent suggestion! It seems to work reliably with >> 5ms buffering. I did not set the time of the FPGA, nor did I >> synchronized the FPGA with the host. I just used the received sample >> counter for all timings on the host to determine (the 5ms buffering) >> when to send the samples to the board. >> >> One question: It seems to me that when the TX -> RX switch is done, >> then actually the N210 will use the RX2 antenna instead of >> disconnecting the RX channel completely from the TX/RX antenna. Is it >> possible to force half duplex operation, i.e. to completely disconnect >> the RX channel. Of course I woulds still see leakage through the >> board, but maybe that will not overdrive the LNA. Any ideas? >> >> Miklos >> >> On Mon, Jun 3, 2013 at 7:59 PM, John Malsbury >> wrote: >> > " It'll switch to TX when it receives samples to send." >> > >> > There may be some small [intentional] delays, but the FPGA will switch >> > to Tx >> > on the first sample to be sent. Josh can specify the timing in more >> > detail. >> > >> > You see "L" because you are sending your bursts far enough advance. In >> > my >> > applications, the bursts are sent to the USRP about ~5ms before the >> > actual >> > transmission. And as far as I know you can't just use the fractional >> > seconds. The FPGA won't switch to TX when it hits tx_time and starts >> > clock >> > out the samples. >> > >> > -John >> > >> > >> > On Mon, Jun 3, 2013 at 4:59 PM, Miklos Maroti >> > wrote: >> >> >> >> Hi John, >> >> >> >> Thanks for you quick reply, but you did not answer any of my >> >> questions. Will the FPGA switch from TX to RX when it has already >> >> received from the host a UDP packet with a timestamp tag (tx_time) >> >> that is in the future? Also, when exactly will the RX to TX switch >> >> occur? >> >> >> >> Miklos >> >> >> >> On Mon, Jun 3, 2013 at 6:14 PM, John Malsbury >> >> wrote: >> >> > If you choose TX/RX as both your transmit and receive antenna, the >> >> > FPGA >> >> > will >> >> > switch between TX and RX automatically. It'll switch to TX when it >> >> > receives >> >> > samples to send. >> >> > >> >> > -John >> >> > >> >> > >> >> > On Mon, Jun 3, 2013 at 3:33 PM, Miklos Maroti >> >> > wrote: >> >> >> >> >> >> Hi Guys! >> >> >> >> >> >> I am trying to develop a half duplex application with N210 and SBX >> >> >> daughterboard with the latest (git head) gnuradio that needs precise >> >> >> TX/RX switching times (like in TDMA) in the order of a few samples >> >> >> (nanoseconds). I have played with the tx_time, tx_sob, tx_eob tags >> >> >> and >> >> >> they do not seem to solve the problem. My findings so far are: >> >> >> >> >> >> 1) tx_sob/tx_eob does not influence anything related to the TX/RX >> >> >> switch, it
Re: [Discuss-gnuradio] half duplex set_auto_tx timing problems
Hi John, Thanks for the excellent suggestion! It seems to work reliably with 5ms buffering. I did not set the time of the FPGA, nor did I synchronized the FPGA with the host. I just used the received sample counter for all timings on the host to determine (the 5ms buffering) when to send the samples to the board. One question: It seems to me that when the TX -> RX switch is done, then actually the N210 will use the RX2 antenna instead of disconnecting the RX channel completely from the TX/RX antenna. Is it possible to force half duplex operation, i.e. to completely disconnect the RX channel. Of course I woulds still see leakage through the board, but maybe that will not overdrive the LNA. Any ideas? Miklos On Mon, Jun 3, 2013 at 7:59 PM, John Malsbury wrote: > " It'll switch to TX when it receives samples to send." > > There may be some small [intentional] delays, but the FPGA will switch to Tx > on the first sample to be sent. Josh can specify the timing in more detail. > > You see "L" because you are sending your bursts far enough advance. In my > applications, the bursts are sent to the USRP about ~5ms before the actual > transmission. And as far as I know you can't just use the fractional > seconds. The FPGA won't switch to TX when it hits tx_time and starts clock > out the samples. > > -John > > > On Mon, Jun 3, 2013 at 4:59 PM, Miklos Maroti > wrote: >> >> Hi John, >> >> Thanks for you quick reply, but you did not answer any of my >> questions. Will the FPGA switch from TX to RX when it has already >> received from the host a UDP packet with a timestamp tag (tx_time) >> that is in the future? Also, when exactly will the RX to TX switch >> occur? >> >> Miklos >> >> On Mon, Jun 3, 2013 at 6:14 PM, John Malsbury >> wrote: >> > If you choose TX/RX as both your transmit and receive antenna, the FPGA >> > will >> > switch between TX and RX automatically. It'll switch to TX when it >> > receives >> > samples to send. >> > >> > -John >> > >> > >> > On Mon, Jun 3, 2013 at 3:33 PM, Miklos Maroti wrote: >> >> >> >> Hi Guys! >> >> >> >> I am trying to develop a half duplex application with N210 and SBX >> >> daughterboard with the latest (git head) gnuradio that needs precise >> >> TX/RX switching times (like in TDMA) in the order of a few samples >> >> (nanoseconds). I have played with the tx_time, tx_sob, tx_eob tags and >> >> they do not seem to solve the problem. My findings so far are: >> >> >> >> 1) tx_sob/tx_eob does not influence anything related to the TX/RX >> >> switch, it only controls the grouping of the TX data stream into UDP >> >> packets (tx_sob starts a new UDP packet, tx_eof pushes out the last >> >> UDP packet even if it is not full). The same is true for USRP1 but >> >> that uses USB packets. >> >> >> >> 2) tx_time is translated into the metadata_t struct in the host code >> >> and then it is translated into VITA packet time stamps (converts the >> >> fractional second part into sample numbers). The integer part of >> >> tx_time seems to be discarded, but I still get "L" (timestamp in the >> >> past error), so I do not understand why the FPGA will not wait a >> >> little if only the factional part is considered. >> >> >> >> 3) I have found this discussion online about TX/RX switch: >> >> >> >> >> >> http://lists.gnu.org/archive/html/discuss-gnuradio/2009-03/msg00034.html >> >> >> >> where Matt Ettus said that "The act of transmitting turns off the >> >> receiver, so no amount of software will ever change that." in >> >> discussing half duplex operation. Now it is not clear if that comment >> >> is also applicable to the N210 and SBX, and what does he mean by "the >> >> act of transmitting". Specifically, if I send a packet with tx_time in >> >> the future, does the FPGA switches to RX mode while it is waiting? >> >> >> >> 4) We have looked up the FPGA code, and it seems that the timing is >> >> implemented in a short FIFO when handling the VITA UDP packets. I >> >> could not trace the code further, and I do not see the logic in the >> >> FPGA code that does the automatic switching between RX and TX. Where >> >> is that implemented? >> >> >> >> 5) Is it true that to switch between RX and TX then the host has to
Re: [Discuss-gnuradio] half duplex set_auto_tx timing problems
Hi Marcus, On Mon, Jun 3, 2013 at 9:20 PM, Marcus Leech wrote: > The 1PPS is used only to latch-in a time-of-day update from the host--it is > used when doing time synchronization across multiple devices, and in fact is > critical for that function to work correctly. > > The problem with set_time_now() is that you can't precisely model the delay > through the TCP/IP stack on the host, across the ethernet, etc. > > With set_time_next_pps(), you typically get your local time on the host > (possibly as managed by NTP) and then do a set_time_next_pps(host_time+1). I understand, but then the precision of your PC clock will be the limiting factor and still you are going to get cycle slips because if your FPGA is sometime going to accumulate more a 1 cycle drift, and the next set_time_next_pps will introduce a cycle shift. If you count everything in FPGA cycles on the host, then this is not a problem (and of course you have to keep separate timelines for each FPGA if you have more than one connected to your host). Miklos > You do this once > at the start of your session. On USRPs equipped with an in-skin GPSDO, > you can query the GPSDO time, and synchronize to GPSDO time. > > > > > on Jun 03, 2013, Miklos Maroti wrote: > > Hi Marcus, > > On Mon, Jun 3, 2013 at 8:15 PM, Marcus D. Leech wrote: >>> You say that it switch from TX to RX if the next timestamp is in the >>> future and switch from RX to TX just when the timestamp is triggered. >>> >>>>> You see "L" because you are sending your bursts far enough advance. In >>>>> my >>>>> applications, the bursts are sent to the USRP about ~5ms before the >>>>> actual >>>>> transmission. >>> >>> Ok, I will try to send them 5ms before transmit time, that should >>> work. But then synchronizing the FPGA clock with the PC clock will be >>> more trouble. >>> >> You can use set_time_now() to set the FPGA clock to whatever you want. >> >> In fact, without such synchronization of ideas of time, it's pretty hard >> to >> build a TDMA-type system. The USRP and the host delivering time-stamped >> samples have to agree on what time it is. If you have 1PPS pulses going >> in, you can use set_time_next_pps() to align times on the next PPS pulse. > > Thanks for the idea of using set_time_now(). Setting the time to zero > (at the start of the flowgraph) makes a lot of sense (by the way, > USRP1 resets the time automatically when you start the flowgraph, but > USRP2 does not). However, you cannot use the set_time_now > periodically, because you will loose synchronization between host and > fpga. I do not think 1PPS would help either if you want to achive > cycle correct TX/RX switch. I want to let the FPGA to use its internal > timer and count everything in FPGA cycles on the host and do an > implicit time sync between the host and FPGA in order to send the next > packet 5ms before it times comes on the FPGA. > > Best, > Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] half duplex set_auto_tx timing problems
Hi Ian, Wow, thanks for the technical explanation! That makes a whole lot of sense (see below for further questions). On Mon, Jun 3, 2013 at 8:19 PM, Ian Buckley wrote: > Miklos, > Here's a little bit more information about how the half-duplex operation > works from the H/W side. > The verilog module "gpio_atr" contains 5 32bit configuration registers that > are programmed by the driver. > This block connects to the radio daughter cards via the "io_rx" and "io_tx" > buses (which together have 32signals), and each daughter board uses theses > signals in a different way depending on the specific radio design. Yes, I got this far in understanding the verilog code. > One of the registers programs each of the 32signals to determine if they are > inputs or outputs from the FPGA. > The remaining 4 registers contain the state that is driven out onto signals > (configured as outputs) in each of four states: > IDLE, RX only, TX only, TX and RX. The current state is detemined from > inspection of the "run_rx" and "run_tx" signals that you will find in > u2plus_core.v. > The state of these signals in turn is driven from UHD commands that are sent > from the host. When they are asserted then the respective DSP is enabled and > samples are delivered to/from the host. > No switching of TX and RX data streams is done on the host to implement > half-duplex operation, the only switch is analog and very close to the TX/RX > antenna connection, and this switch is controlled by some of the GPIO bits I > have referred to. Excellent! I will look into this. > Internal to the FPGA "vita_time" which is a 64bit count of samples (100MHz on > N210) is used to schedule all DSP operation. When you send a TX stream > command with a time in the future, data is buffered in the FPGA ready to > start transmission, and when "vita_time" matches the time supplied with the > TX stream command, the "run_tx" signal is asserted causing both the DSP to > become enabled (and buffered data to be drawn into it), and also the > "gpio_atr" state machine to change state causing the analog RX/TX switch to > toggle. There is a delay of some 10's of clock cycles for data to pass > through the FPGA TX DSP logic and out to the DAC. > > Hope this is enough information to help you understand the code further. Yup, this is what I needed. One more thing: is it true, that once we make the switch I can still download packets from the FPGA to the HOST in the RX channel continuously and undisturbed? If I do not use tx_time at all, but listen while I transmit, then I will get back the leaked transmission, so I know exactly how many samples off are the RX channel with respect to the TX channel. Will the same happen with the RX/TX switch scheduled with tx_time? Best, Miklos > -Ian > > > > > > > On Jun 3, 2013, at 5:50 PM, Miklos Maroti wrote: > >> Hi Marcus, >> >> Thanks for the quick comments. Yes, I totally agree that using full >> duplex with RX2 and TX/RX would be the ideal way to go, and as you say >> I can easily ignore and synchronize with my own transmissions. The >> problem is that I am required to use a single antenna, so I have to do >> a half duplex solution with all its warts and synchronization >> problems. >> >> As for the switching time, I do not care if the switches (or the FPGA) >> introduce deterministic delays, I can cope with that. >> >> You mention that the state machine is set up in the daughter card >> setup driver. Is this the file in >> "host/lib/usrp/dboard/db_sbx_common.cpp" for the SBX board? Is this >> code used for USRP2 and not only for USRP1? >> >> Best, >> Miklos >> >> On Mon, Jun 3, 2013, Marcus Leech wrote: >>> >>> Some very quick comments. >>> >>> I don't think you're going to achieve nanosecond-scale TX/RX switching >>> times, no matter how much you tweak the FPGA. The switches >>> themselves introduce, I'm estimating, a 50nsec delay all by themselves. >>> >>> In UHD, the ATR state machine is programmed during daughtercard setup by >>> the "driver" for a given daughtercard -- this allows somewhat >>> different behaviour for cards that are hardware-constrained to be >>> half-duplex (like XCVR2450). In the daughtercard drivers, you'll see things >>> like: >>> >>> this->get_iface()->set_atr_reg(dboard_iface::UNIT_TX, >>> dboard_iface::ATR_REG_IDLE, band_sel | ad9515div | TX_DIS_TXIO); >>> >>> >>> Which are setting up ATR registers. >>&g
Re: [Discuss-gnuradio] half duplex set_auto_tx timing problems
Hi Marcus, On Mon, Jun 3, 2013 at 8:15 PM, Marcus D. Leech wrote: >> You say that it switch from TX to RX if the next timestamp is in the >> future and switch from RX to TX just when the timestamp is triggered. >> You see "L" because you are sending your bursts far enough advance. In my applications, the bursts are sent to the USRP about ~5ms before the actual transmission. >> >> Ok, I will try to send them 5ms before transmit time, that should >> work. But then synchronizing the FPGA clock with the PC clock will be >> more trouble. >> > You can use set_time_now() to set the FPGA clock to whatever you want. > > In fact, without such synchronization of ideas of time, it's pretty hard to > build a TDMA-type system. The USRP and the host delivering time-stamped > samples have to agree on what time it is. If you have 1PPS pulses going > in, you can use set_time_next_pps() to align times on the next PPS pulse. Thanks for the idea of using set_time_now(). Setting the time to zero (at the start of the flowgraph) makes a lot of sense (by the way, USRP1 resets the time automatically when you start the flowgraph, but USRP2 does not). However, you cannot use the set_time_now periodically, because you will loose synchronization between host and fpga. I do not think 1PPS would help either if you want to achive cycle correct TX/RX switch. I want to let the FPGA to use its internal timer and count everything in FPGA cycles on the host and do an implicit time sync between the host and FPGA in order to send the next packet 5ms before it times comes on the FPGA. Best, Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] half duplex set_auto_tx timing problems
Hi John, On Mon, Jun 3, 2013 at 8:00 PM, John Malsbury wrote: > You see "L" because you are sending your bursts far enough advance > > should have read: > > "aren't sending your bursts far enough in advance" > > > On Mon, Jun 3, 2013 at 5:59 PM, John Malsbury > wrote: >> >> " It'll switch to TX when it receives samples to send." >> >> There may be some small [intentional] delays, but the FPGA will switch to >> Tx on the first sample to be sent. Josh can specify the timing in more >> detail. You say that it switch from TX to RX if the next timestamp is in the future and switch from RX to TX just when the timestamp is triggered. >> You see "L" because you are sending your bursts far enough advance. In my >> applications, the bursts are sent to the USRP about ~5ms before the actual >> transmission. Ok, I will try to send them 5ms before transmit time, that should work. But then synchronizing the FPGA clock with the PC clock will be more trouble. >> And as far as I know you can't just use the fractional >> seconds. The FPGA won't switch to TX when it hits tx_time and starts clock >> out the samples. You say that the FPGA will NOT change from RX to TX? This contradicts the other sentences you wrote. Miklos >> >> -John >> >> >> On Mon, Jun 3, 2013 at 4:59 PM, Miklos Maroti >> wrote: >>> >>> Hi John, >>> >>> Thanks for you quick reply, but you did not answer any of my >>> questions. Will the FPGA switch from TX to RX when it has already >>> received from the host a UDP packet with a timestamp tag (tx_time) >>> that is in the future? Also, when exactly will the RX to TX switch >>> occur? >>> >>> Miklos >>> >>> On Mon, Jun 3, 2013 at 6:14 PM, John Malsbury >>> wrote: >>> > If you choose TX/RX as both your transmit and receive antenna, the FPGA >>> > will >>> > switch between TX and RX automatically. It'll switch to TX when it >>> > receives >>> > samples to send. >>> > >>> > -John >>> > >>> > >>> > On Mon, Jun 3, 2013 at 3:33 PM, Miklos Maroti >>> > wrote: >>> >> >>> >> Hi Guys! >>> >> >>> >> I am trying to develop a half duplex application with N210 and SBX >>> >> daughterboard with the latest (git head) gnuradio that needs precise >>> >> TX/RX switching times (like in TDMA) in the order of a few samples >>> >> (nanoseconds). I have played with the tx_time, tx_sob, tx_eob tags and >>> >> they do not seem to solve the problem. My findings so far are: >>> >> >>> >> 1) tx_sob/tx_eob does not influence anything related to the TX/RX >>> >> switch, it only controls the grouping of the TX data stream into UDP >>> >> packets (tx_sob starts a new UDP packet, tx_eof pushes out the last >>> >> UDP packet even if it is not full). The same is true for USRP1 but >>> >> that uses USB packets. >>> >> >>> >> 2) tx_time is translated into the metadata_t struct in the host code >>> >> and then it is translated into VITA packet time stamps (converts the >>> >> fractional second part into sample numbers). The integer part of >>> >> tx_time seems to be discarded, but I still get "L" (timestamp in the >>> >> past error), so I do not understand why the FPGA will not wait a >>> >> little if only the factional part is considered. >>> >> >>> >> 3) I have found this discussion online about TX/RX switch: >>> >> >>> >> >>> >> http://lists.gnu.org/archive/html/discuss-gnuradio/2009-03/msg00034.html >>> >> >>> >> where Matt Ettus said that "The act of transmitting turns off the >>> >> receiver, so no amount of software will ever change that." in >>> >> discussing half duplex operation. Now it is not clear if that comment >>> >> is also applicable to the N210 and SBX, and what does he mean by "the >>> >> act of transmitting". Specifically, if I send a packet with tx_time in >>> >> the future, does the FPGA switches to RX mode while it is waiting? >>> >> >>> >> 4) We have looked up the FPGA code, and it seems that the timing is >>> >> implemented in a short FIFO when handling the VITA UDP packets. I >>> >> could n
Re: [Discuss-gnuradio] half duplex set_auto_tx timing problems
Hi Marcus, Thanks for the quick comments. Yes, I totally agree that using full duplex with RX2 and TX/RX would be the ideal way to go, and as you say I can easily ignore and synchronize with my own transmissions. The problem is that I am required to use a single antenna, so I have to do a half duplex solution with all its warts and synchronization problems. As for the switching time, I do not care if the switches (or the FPGA) introduce deterministic delays, I can cope with that. You mention that the state machine is set up in the daughter card setup driver. Is this the file in "host/lib/usrp/dboard/db_sbx_common.cpp" for the SBX board? Is this code used for USRP2 and not only for USRP1? Best, Miklos > On Mon, Jun 3, 2013, Marcus Leech wrote: >> >> Some very quick comments. >> >> I don't think you're going to achieve nanosecond-scale TX/RX switching >> times, no matter how much you tweak the FPGA. The switches >> themselves introduce, I'm estimating, a 50nsec delay all by themselves. >> >> In UHD, the ATR state machine is programmed during daughtercard setup by the >> "driver" for a given daughtercard -- this allows somewhat >> different behaviour for cards that are hardware-constrained to be >> half-duplex (like XCVR2450). In the daughtercard drivers, you'll see things >> like: >> >> this->get_iface()->set_atr_reg(dboard_iface::UNIT_TX, >> dboard_iface::ATR_REG_IDLE, band_sel | ad9515div | TX_DIS_TXIO); >> >> >> Which are setting up ATR registers. >> >> But that being said, I think you're best to run in a mode where you have a >> separate RX antenna if you require nanosecond-scale turnaround >> times. You'll end up receiving your own transmissions, but that's fairly >> easy to cope with, I imagine. >> >> If you setup to use (WBX example) RX2 for RX and TX/RX for TX, then there's >> no switching involved. You just have to ignore your own >> transmissions. >> Hi Guys! I am trying to develop a half duplex application with N210 and SBX daughterboard with the latest (git head) gnuradio that needs precise TX/RX switching times (like in TDMA) in the order of a few samples (nanoseconds). I have played with the tx_time, tx_sob, tx_eob tags and they do not seem to solve the problem. My findings so far are: 1) tx_sob/tx_eob does not influence anything related to the TX/RX switch, it only controls the grouping of the TX data stream into UDP packets (tx_sob starts a new UDP packet, tx_eof pushes out the last UDP packet even if it is not full). The same is true for USRP1 but that uses USB packets. 2) tx_time is translated into the metadata_t struct in the host code and then it is translated into VITA packet time stamps (converts the fractional second part into sample numbers). The integer part of tx_time seems to be discarded, but I still get "L" (timestamp in the past error), so I do not understand why the FPGA will not wait a little if only the factional part is considered. 3) I have found this discussion online about TX/RX switch: http://lists.gnu.org/archive/html/discuss-gnuradio/2009-03/msg00034.html where Matt Ettus said that "The act of transmitting turns off the receiver, so no amount of software will ever change that." in discussing half duplex operation. Now it is not clear if that comment is also applicable to the N210 and SBX, and what does he mean by "the act of transmitting". Specifically, if I send a packet with tx_time in the future, does the FPGA switches to RX mode while it is waiting? 4) We have looked up the FPGA code, and it seems that the timing is implemented in a short FIFO when handling the VITA UDP packets. I could not trace the code further, and I do not see the logic in the FPGA code that does the automatic switching between RX and TX. Where is that implemented? 5) Is it true that to switch between RX and TX then the host has to issue a command (poke register) to update the appropriate pin on the FPGA? If so, then how can you time the update of that pin to specific sample numbers? 6) Is it true that the firmware soft core has nothing to do with the time sensitive data and control handling, so in particular the provided register access features (if I saw them correctly) are not used in timing sensitive paths? 7) It is not clear how the gnuradio UHD sink block handles the sample rate value in the presence of tx_time tags. For example, if I generate 10 small packets each of which has a tx_sob,tx_time and tx_eob and 0.1 sec delay between the times, and all of these small packets are put into the transmit fifo at once, then what happens? What is the rate that the UHD sink block will consume this data? It cannot be the sample rate, because these tags point to the future, so the consumption rate should be reduce
Re: [Discuss-gnuradio] half duplex set_auto_tx timing problems
Hi Marcus, Thanks for the quick comments. Yes, I totally agree that using full duplex with RX2 and TX/RX would be the ideal way to go, and as you say I can easily ignore and synchronize with my own transmissions. The problem is that I am required to use a single antenna, so I have to do a half duplex solution with all its warts and synchronization problems. As for the switching time, I do not care if the switches (or the FPGA) introduce deterministic delays, I can cope with that. You mention that the state machine is set up in the daughter card setup driver. Is this the file in "host/lib/usrp/dboard/db_sbx_common.cpp" for the SBX board? Is this code used for USRP2 and not only for USRP1? Best, Miklos On Mon, Jun 3, 2013, Marcus Leech wrote: > > Some very quick comments. > > I don't think you're going to achieve nanosecond-scale TX/RX switching times, > no matter how much you tweak the FPGA. The switches > themselves introduce, I'm estimating, a 50nsec delay all by themselves. > > In UHD, the ATR state machine is programmed during daughtercard setup by the > "driver" for a given daughtercard -- this allows somewhat > different behaviour for cards that are hardware-constrained to be half-duplex > (like XCVR2450). In the daughtercard drivers, you'll see things > like: > > this->get_iface()->set_atr_reg(dboard_iface::UNIT_TX, > dboard_iface::ATR_REG_IDLE, band_sel | ad9515div | TX_DIS_TXIO); > > > Which are setting up ATR registers. > > But that being said, I think you're best to run in a mode where you have a > separate RX antenna if you require nanosecond-scale turnaround > times. You'll end up receiving your own transmissions, but that's fairly easy > to cope with, I imagine. > > If you setup to use (WBX example) RX2 for RX and TX/RX for TX, then there's > no switching involved. You just have to ignore your own > transmissions. > >>> Hi Guys! >>> >>> I am trying to develop a half duplex application with N210 and SBX >>> daughterboard with the latest (git head) gnuradio that needs precise >>> TX/RX switching times (like in TDMA) in the order of a few samples >>> (nanoseconds). I have played with the tx_time, tx_sob, tx_eob tags and >>> they do not seem to solve the problem. My findings so far are: >>> >>> 1) tx_sob/tx_eob does not influence anything related to the TX/RX >>> switch, it only controls the grouping of the TX data stream into UDP >>> packets (tx_sob starts a new UDP packet, tx_eof pushes out the last >>> UDP packet even if it is not full). The same is true for USRP1 but >>> that uses USB packets. >>> >>> 2) tx_time is translated into the metadata_t struct in the host code >>> and then it is translated into VITA packet time stamps (converts the >>> fractional second part into sample numbers). The integer part of >>> tx_time seems to be discarded, but I still get "L" (timestamp in the >>> past error), so I do not understand why the FPGA will not wait a >>> little if only the factional part is considered. >>> >>> 3) I have found this discussion online about TX/RX switch: >>> >>> http://lists.gnu.org/archive/html/discuss-gnuradio/2009-03/msg00034.html >>> >>> where Matt Ettus said that "The act of transmitting turns off the >>> receiver, so no amount of software will ever change that." in >>> discussing half duplex operation. Now it is not clear if that comment >>> is also applicable to the N210 and SBX, and what does he mean by "the >>> act of transmitting". Specifically, if I send a packet with tx_time in >>> the future, does the FPGA switches to RX mode while it is waiting? >>> >>> 4) We have looked up the FPGA code, and it seems that the timing is >>> implemented in a short FIFO when handling the VITA UDP packets. I >>> could not trace the code further, and I do not see the logic in the >>> FPGA code that does the automatic switching between RX and TX. Where >>> is that implemented? >>> >>> 5) Is it true that to switch between RX and TX then the host has to >>> issue a command (poke register) to update the appropriate pin on the >>> FPGA? If so, then how can you time the update of that pin to specific >>> sample numbers? >>> >>> 6) Is it true that the firmware soft core has nothing to do with the >>> time sensitive data and control handling, so in particular the >>> provided register access features (if I saw them correctly) are not >>> used in timing sensitive paths? >>> >>> 7) It is not clear how the gnuradio UHD sink block handles the sample >>> rate value in the presence of tx_time tags. For example, if I generate >>> 10 small packets each of which has a tx_sob,tx_time and tx_eob and 0.1 >>> sec delay between the times, and all of these small packets are put >>> into the transmit fifo at once, then what happens? What is the rate >>> that the UHD sink block will consume this data? It cannot be the >>> sample rate, because these tags point to the future, so the >>> consumption rate should be reduced, but is it what happens? Will the >>> code switch the TX/RX switch to RX between the
Re: [Discuss-gnuradio] half duplex set_auto_tx timing problems
Hi John, Thanks for you quick reply, but you did not answer any of my questions. Will the FPGA switch from TX to RX when it has already received from the host a UDP packet with a timestamp tag (tx_time) that is in the future? Also, when exactly will the RX to TX switch occur? Miklos On Mon, Jun 3, 2013 at 6:14 PM, John Malsbury wrote: > If you choose TX/RX as both your transmit and receive antenna, the FPGA will > switch between TX and RX automatically. It'll switch to TX when it receives > samples to send. > > -John > > > On Mon, Jun 3, 2013 at 3:33 PM, Miklos Maroti wrote: >> >> Hi Guys! >> >> I am trying to develop a half duplex application with N210 and SBX >> daughterboard with the latest (git head) gnuradio that needs precise >> TX/RX switching times (like in TDMA) in the order of a few samples >> (nanoseconds). I have played with the tx_time, tx_sob, tx_eob tags and >> they do not seem to solve the problem. My findings so far are: >> >> 1) tx_sob/tx_eob does not influence anything related to the TX/RX >> switch, it only controls the grouping of the TX data stream into UDP >> packets (tx_sob starts a new UDP packet, tx_eof pushes out the last >> UDP packet even if it is not full). The same is true for USRP1 but >> that uses USB packets. >> >> 2) tx_time is translated into the metadata_t struct in the host code >> and then it is translated into VITA packet time stamps (converts the >> fractional second part into sample numbers). The integer part of >> tx_time seems to be discarded, but I still get "L" (timestamp in the >> past error), so I do not understand why the FPGA will not wait a >> little if only the factional part is considered. >> >> 3) I have found this discussion online about TX/RX switch: >> >> http://lists.gnu.org/archive/html/discuss-gnuradio/2009-03/msg00034.html >> >> where Matt Ettus said that "The act of transmitting turns off the >> receiver, so no amount of software will ever change that." in >> discussing half duplex operation. Now it is not clear if that comment >> is also applicable to the N210 and SBX, and what does he mean by "the >> act of transmitting". Specifically, if I send a packet with tx_time in >> the future, does the FPGA switches to RX mode while it is waiting? >> >> 4) We have looked up the FPGA code, and it seems that the timing is >> implemented in a short FIFO when handling the VITA UDP packets. I >> could not trace the code further, and I do not see the logic in the >> FPGA code that does the automatic switching between RX and TX. Where >> is that implemented? >> >> 5) Is it true that to switch between RX and TX then the host has to >> issue a command (poke register) to update the appropriate pin on the >> FPGA? If so, then how can you time the update of that pin to specific >> sample numbers? >> >> 6) Is it true that the firmware soft core has nothing to do with the >> time sensitive data and control handling, so in particular the >> provided register access features (if I saw them correctly) are not >> used in timing sensitive paths? >> >> 7) It is not clear how the gnuradio UHD sink block handles the sample >> rate value in the presence of tx_time tags. For example, if I generate >> 10 small packets each of which has a tx_sob,tx_time and tx_eob and 0.1 >> sec delay between the times, and all of these small packets are put >> into the transmit fifo at once, then what happens? What is the rate >> that the UHD sink block will consume this data? It cannot be the >> sample rate, because these tags point to the future, so the >> consumption rate should be reduced, but is it what happens? Will the >> code switch the TX/RX switch to RX between the small packets if all >> those are already in the queue? >> >> I hope someone has answers to these questions. Searching the internet >> turned up next to nothing on these subjects. >> >> Miklos >> >> ___ >> 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] half duplex set_auto_tx timing problems
Hi Guys! I am trying to develop a half duplex application with N210 and SBX daughterboard with the latest (git head) gnuradio that needs precise TX/RX switching times (like in TDMA) in the order of a few samples (nanoseconds). I have played with the tx_time, tx_sob, tx_eob tags and they do not seem to solve the problem. My findings so far are: 1) tx_sob/tx_eob does not influence anything related to the TX/RX switch, it only controls the grouping of the TX data stream into UDP packets (tx_sob starts a new UDP packet, tx_eof pushes out the last UDP packet even if it is not full). The same is true for USRP1 but that uses USB packets. 2) tx_time is translated into the metadata_t struct in the host code and then it is translated into VITA packet time stamps (converts the fractional second part into sample numbers). The integer part of tx_time seems to be discarded, but I still get "L" (timestamp in the past error), so I do not understand why the FPGA will not wait a little if only the factional part is considered. 3) I have found this discussion online about TX/RX switch: http://lists.gnu.org/archive/html/discuss-gnuradio/2009-03/msg00034.html where Matt Ettus said that "The act of transmitting turns off the receiver, so no amount of software will ever change that." in discussing half duplex operation. Now it is not clear if that comment is also applicable to the N210 and SBX, and what does he mean by "the act of transmitting". Specifically, if I send a packet with tx_time in the future, does the FPGA switches to RX mode while it is waiting? 4) We have looked up the FPGA code, and it seems that the timing is implemented in a short FIFO when handling the VITA UDP packets. I could not trace the code further, and I do not see the logic in the FPGA code that does the automatic switching between RX and TX. Where is that implemented? 5) Is it true that to switch between RX and TX then the host has to issue a command (poke register) to update the appropriate pin on the FPGA? If so, then how can you time the update of that pin to specific sample numbers? 6) Is it true that the firmware soft core has nothing to do with the time sensitive data and control handling, so in particular the provided register access features (if I saw them correctly) are not used in timing sensitive paths? 7) It is not clear how the gnuradio UHD sink block handles the sample rate value in the presence of tx_time tags. For example, if I generate 10 small packets each of which has a tx_sob,tx_time and tx_eob and 0.1 sec delay between the times, and all of these small packets are put into the transmit fifo at once, then what happens? What is the rate that the UHD sink block will consume this data? It cannot be the sample rate, because these tags point to the future, so the consumption rate should be reduced, but is it what happens? Will the code switch the TX/RX switch to RX between the small packets if all those are already in the queue? I hope someone has answers to these questions. Searching the internet turned up next to nothing on these subjects. Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
