Hi David,
GNU Radio block or not, what you're seeing is C++ error, and your code
is not really related to GNU Radio.
Since GNU Radio is written in normal C++, you must have made some
syntax mistake when integrating your code into the template that you get
when creating a new block.
However, that
Dear zs,
basically, Schmidl and Cox is a very good algorithm, because it can
achieve the same quality of synchronization with half of the
synchronization overhead compared to other approaches, or a better
performance with the same amount.
I must admit that from the top of my head, there's
Dear all:
Thank you in advance.
1.
I want to ask a question about the new ofdm example.And I know
the receiver have used the SCA(schmidl and cox algorithm) algorithm.Now in my
application,maybe this algorithm isn't enough.And I want to ask whether
Hi Luis,
I guess the idea was to look whether your CPU was really your
bottleneck; filter banks are one of the most CPU-hungry signal
processing steps one can think of, and hence, your Dropped packets
could be caused by that. If I understand correctly, with the null sink
(and/or the file_sink)
Hi zs,
this reminds me very much of OFDM radar technologies, as your problem
boils down to finding a good estimator for the spectral properties of
your OFDM frame as well as the time it reached you.
I think you should have a look at chapter 3, OFDM Radar Algorithms of
[1]; you might find that
Hi Martin,
Thank you for your message.
I was looking into the null sink blocks documentation and I couldn't find
any method or function where I can get an intermediate value into this
block. Then, I just verified data at the input of this block, which is the
confirmation of the streaming at the
Dear Marcus Müller:
Thank you so much for your kindly reply.
The SCA is adequate for a correct demodulation of the signal while maybe
inadequate for estimate the precise frequency shift.I don't have the
synchroniztion device.In my application,I need to reconstruct one transmit
signal in
I'm sorry. You are right, I will try to keep that in mind next time I write
asking for help.
--
View this message in context:
http://gnuradio.4.n7.nabble.com/include-vector-hpp-tp54344p54398.html
Sent from the GnuRadio mailing list archive at Nabble.com.
Dear all:
Thank you in advance.
1.
I want to ask a question about the new ofdm example.And I know
the receiver have used the SCA(schmidl and cox algorithm) algorithm.Now in my
application,maybe this algorithm isn't enough.And I want to ask whether
Dear Marcus Müller:
Do you know which is the synchronization algorithm used in the old version of
ofdm example?Where is the source code of the old ofdm version in
gnuradio?Thanks.
Any other suggestions?
Thank you.
Best regards,
zs
At 2015-06-24 15:54:30, Marcus Müller
Dear Marcus Müller:
Thank you so much.So kindly of you.Thanks.I will read the papers you mentioned.
Best regards,
zs
At 2015-06-24 17:08:16, Marcus Müller marcus.muel...@ettus.com wrote:
Hi zs,
this reminds me very much of OFDM radar technologies, as your problem boils
down to finding a
Hi Martin,
I'm trying to make use of the new message interface. I'm able to set
center frequency and other parameters with use of it which is great as
now I'm able to make for example a application that scans spectrum
without stopping the flowgraph.
However I expected that after USRP switch
Dear Marcus Müller:
Actually my problem is:
y=useful information+x*h(channel)*cfo(carrier offset due to
the local oscillator between the interference and the radar)+noise.
I want to turn y to
new_y=useful information+noise.
So I need know the channel(h)
Hi all,
After reading the code of usrp_source_impl I've found out that there are
separate methods for tune requests invoked from gui and by message
interface.
For gui:
::uhd::tune_result_t
usrp_source_impl::set_center_freq(const ::uhd::tune_request_t
tune_request,
Hi Sanjoy,
I am trying to make 2 TX 1Rx tagged stream block(OOT). For 1Tx 1Rx, it
was working fine. I am trying to extend it. Now the problem is, I am
not being able to configure the send() function.
Is there a particular reason you're creating your own block? Is there a
feature missing on
Quick follow up: Tim O'Shea provided a nice write-up of the performance
delta with the change in the backing store for tags (for those who may care
about such things):
http://oshearesearch.com/2014/09/22/five-orders-of-magnitude-improvement-in-gnu-radio-stream-tag-propagation-performance/
Doug
I don't know that I can completely answer your question, but I can tell you
that the change to using a std::multimap occurred during the last day of
GrCon'14 (i.e. the hackfest day) after profiling measurements were showing
that the tagged stream blocks were spending a great deal of time in the
On Wed, Jun 24, 2015 at 4:46 PM, Douglas Geiger
doug.gei...@bioradiation.net wrote:
Quick follow up: Tim O'Shea provided a nice write-up of the performance
delta with the change in the backing store for tags (for those who may care
about such things):
pretty much; it increases the the nitems_written counter, too.
On 06/24/2015 09:38 PM, Richard Bell wrote:
Ah OK. So the produce function advances the buffer pointer only?
Rich
On Wed, Jun 24, 2015 at 12:35 PM, Marcus Müller
marcus.muel...@ettus.com mailto:marcus.muel...@ettus.com wrote:
Hi Marcus,
Now, it is everything more clear about the computation load and filter
taps. So I'm gonna work on that.
1Yeah, but how much bandwidth do you **really** need at once?
At once I will need the total bandwidth of my subbands, so it is 5,838
MHz, because the general idea was: the
Sorry, Sanjoy,
we'll need some more information before we can give you better feedback.
It's not clear exactly what you're trying to achieve, and what exactly
is failing.
Perhaps this helps getting started:
http://gnuradio.org/redmine/projects/gnuradio/wiki/ReportingErrors
Cheers,
Martin
On
I recently faced a similar problem with my USRP N210 with a resampler chewing
up my CPU. These steps helped a lot:
1) Design a filter with less taps (as Marcus recommended)
2) Build the latest GNURadio and UHD from git, and flash the N210 with the
recently released FPGA update.
Not sure if
Hi all,
I've been playing around with tags this morning. I created a tagged stream
where there is a tag on every sample (stream to tagged stream block with
packet length = 1).
I noticed that I can't get a tag.offset value to be 0. Since tag.offset is
the absolute offset value of the tagged item
Hi all,
Lately I've been working with gr-lte and trying to use some of those blocks in
my own application (not grc).
I'm still in the learning phase about ofdm/lte, and I'm struggling with the
lack of documentation or comments in gr-lte.
I think I would prefer to use GNU Radio's built-in OFDM
On 24.06.2015 08:48, Anderson, Douglas J. wrote:
Lately I've been working with gr-lte and trying to use some of those
blocks in my own application (not grc).
I'm still in the learning phase about ofdm/lte, and I'm struggling with
the lack of documentation or comments in gr-lte.
I think I
Piotr,
not intentional -- this was indeed an oversight. I'll add an issue.
However, it's not trivial to change; when doing message-based retuning,
there's no clear way of knowing which sample to tag.
M
On 24.06.2015 04:33, Piotr Krysik wrote:
Hi all,
After reading the code of
On 24.06.2015 01:48, zs wrote:
Dear Marcus Müller:
Do you know which is the synchronization algorithm used in the old
version of ofdm example?Where is the source code of the old ofdm version
in gnuradio?Thanks.
It's a very similar implementation to the 'new' versions. In stock GNU
Radio,
Also to note is that simple_ra and gr-ra_blocks are available through
github, and should now be considered the official repo.
https://github.com/patchvonbraun/simple_ra
http://github.com/patchvonbraun/gr-ra_blocks
On 2015-06-24 13:23, dgoadby wrote:
Thanks for the links. I have now
Thanks for the links. I have now downloaded them and also the whole CGRAN
archive (for those dark winder evenings..)
Thanks for the help.
Regards
David
--
View this message in context:
http://gnuradio.4.n7.nabble.com/Help-retrieving-from-gr-radio-astonomy-tp54376p54419.html
Sent from the
Hi all,
When calling gr::block::get_tags_in_range() or
gr::block::get_tags_in_window(), does the GNU Radio API guarantee that the
returned vector will be sorted based upon the tag offsets (from earliest
to latest)?
Since the API docs [1] do not explicitly state this to be the case, I would
Hi Martin,
When the command carried by message is executed immediately after
reception by USRP the situation seems to be similar to tune request
invoked by the user through gui. Or is there something that I overlooked?
Things get more complicated when command has time in the future at
which it
Hi Marcus,
Thank you! I wrote the answers according to your last email.
1I guess the idea was..If that's the case, your PC can't keep up to
both the calculations needed for the filters and receiving the data from
your USRP.
you are right. For this reason I checked my CPU behavior by each
Hi Anderson,
Thanks for your tips.
Actually, my N200 has the recent firmware (usrp_n200_fw.bin) and FPGA image
(usrp_n200_r4_fpga.bin). So I'm working on the filter design with less taps.
Best regards,
Luis
2015-06-24 16:47 GMT+02:00 Anderson, Douglas J. dander...@its.bldrdoc.gov:
I
Hi Rich,
What happens when you assign input to output in a general_work call,
out[ii]=in[ii], but don't call produce?
Then you're breaking a contract!
GNU Radio has to rely on you only writing samples you admit that you
produce -- otherwise, the write pointer can't advance, and the next
Ah OK. So the produce function advances the buffer pointer only?
Rich
On Wed, Jun 24, 2015 at 12:35 PM, Marcus Müller marcus.muel...@ettus.com
wrote:
Hi Rich,
What happens when you assign input to output in a general_work call,
out[ii]=in[ii], but don't call produce?
Then you're breaking
On 24.06.2015 11:55, Piotr Krysik wrote:
Hi Martin,
I'm thinking of some solution to make stream tags more usable in
combination with message interface. My first thought is that maybe
stream tag should be added to the stream whenever something (other than
timestamp) changes in _metadata
Hi all,
I am trying to make 2 TX 1Rx tagged stream block(OOT). For 1Tx 1Rx, it was
working fine. I am trying to extend it. Now the problem is, I am not being
able to configure the send() function.
If I try make test, it does not show any problem. However, when I check
after reception I find that
Your question is a little vague.
You might want to read the guided tutorials, chapter 1-3:
https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
On 06/24/2015 08:58 PM, Adam HH wrote:
Can someone tell me if it is possible to run a python code directly in
GNUradio?
Hi Martin,
I'm thinking of some solution to make stream tags more usable in
combination with message interface. My first thought is that maybe
stream tag should be added to the stream whenever something (other than
timestamp) changes in _metadata received from uhd device?
--
Piotr
W dniu
Can someone tell me if it is possible to run a python code directly in
GNUradio?
--
Posted via http://www.ruby-forum.com/.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hi Luis,
I mean in order to sect an appropriate PC hardware requirements.
(sorry if it is an obvious question) .
No, that's a very valid question. Generally, the computational load of a
filter is basically (n_taps x sampling rate).
So, the computational load for the *same* filter scales linearly
What happens when you assign input to output in a general_work call,
out[ii]=in[ii], but don't call produce? Is the stuff you dumped into 'out'
lost when general_work returns WORK_CALLED_PRODUCE?
My minds eye sees the out variable as a secondary local buffer for
general_work. You dump stuff in
Haha,
Another genius plan ruined by hard reality. I forgot what is inside uhd
metadata and assumed that current frequency is taken from there. The
good thing is that learned that it will be easier to generate the tags
myself in some block than to require from usrp source to do the magic.
43 matches
Mail list logo
