Sir,
What do the number of taps in the CMA equalizer block represent, I hope it
is the channel size. Should it be the number of tap coefficients given for
the variable 'taps' in the channel model block. If I give 'taps' in the
channel model block (I am considering the basic awgn channel model
Yup, I actually deduced that using a Message Debug block to figure out
what it emits.
But not a lot of blocks currently accept async messages for handling
run-time parameters. For example, gr-osmosdr only supports
conventional setters.
On 2015-03-23 10:28, Tom Rondeau wrote:
On Mon, Mar
On Mon, Mar 23, 2015 at 7:12 AM, mle...@ripnet.com wrote:
Indeed, if one uses relative, rather than absolute frequencies in the Qt
Frequency sink, everything is wonderful.
But I think there are, as you observe, deeper questions about the desired
semantics of async messages of this type.
On Mon, Mar 23, 2015 at 3:51 AM, Merry Dominic merry...@gmail.com wrote:
Sir,
What do the number of taps in the CMA equalizer block represent, I hope it
is the channel size. Should it be the number of tap coefficients given for
the variable 'taps' in the channel model block. If I give 'taps'
Thanks, TOm.
Answer to my question.
gr::dvbt::reed_solomon d_rs(...) works.
No CMakeLists modification and other stuffs are needed.
Regards,
Jeon.
2015-03-20 22:36 GMT+09:00 Tom Rondeau t...@trondeau.com:
On Fri, Mar 20, 2015 at 4:07 AM, Jeon sjeon87+gnura...@gmail.com wrote:
In my
Indeed, if one uses relative, rather than absolute frequencies in the Qt
Frequency sink, everything is wonderful.
But I think there are, as you observe, deeper questions about the
desired semantics of async messages of this type.
An advantage to the sets a variable implementation on the WX
On 22.03.2015 19:26, Marcus D. Leech wrote:
Just looking at the async message interface for Qt GUI Frequency Sink.
The freq output (is that a PMT?) is always, it appears, in terms of
display frequency. Which is cool if you're using the click-to-tune
output to modify (for example) a hardware
Hi Tom,
I have tried reducing the signal level. The signal level at the input is
now -40dBm. Still there is this ramp behaviour.
I also get this when I use the B210 in loopback mode (with a 30dB
atttenuator in the loop). Also I have observed that
the lower the master clock rate that I set, the
Hi all,
I wanted to pass a long two features that I wished existed.
I think it would be nice if every block in GRC came with a comment field. A
field for text that does nothing but allow users to add notes to help
others understand they're thinking when they set-up the parameters of the
block.
All of the FOSDEM SDR talks are now online, I've updated the
presentations page:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Presentations
M
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
Hi all,
I'm looking into the possibility of passing the gr_block gr uhd usrp source
(0) object from Python into a C++ out of tree module. In my module, I have:
controller_cc_impl::controller_cc_impl(gr::uhd::usrp_source::sptr usrp,
[...])
I get a TypeError when I instantiate the block. It
Thanks Tom for your immediate response. I re-created the blocks in my module
and copied sources over from tagged_stream_to_pdu, which works not.
I cannot reproduce the described error anymore, which means the issue is solved
for me. The diff between old and new code does not show any differences
I've picked up some issues over the last month of trying to get a working
gnuradio pybombs install with the openlte and fosphor pybombs packages. Had
no idea it would be this difficult on a brand new system with a fresh OS
install and following all the instructions on the gnuradio site, but i
I appreciate the response. Before you wrote back I wanted to try a fresh
install because i wanted to confirm 100% that there were no conflicting
packages outside my pybombs environment. After i deleted my main pybombs
directory i tried to reinstall pybombs, uhd and gnuradio, but now gnuradio
won't
Rich,
I have been working on a patch for the second feature you mentioned. It
is the 'ignore_blocks' branch on my github:
https://github.com/sdh11/gnuradio-wg-grc/tree/ignore_blocks
If you run GRC from that branch, pressing 'p' should treat the block as
a pass through block, and it will not
You should easily be able to pass a basic_block sptr and then
dynamic-cast it in your block.
What you're trying to do is not recommended procedure, although I can
see how it's necessary at times. Can you tell us what you're trying to
do? We've been working on making the message ports more
Rich,
GRC has the worst ratio of people committing code (Seth is one of them)
to importance of the project. There is even an entire wiki page with a
GRC wishlist: http://gnuradio.org/redmine/projects/gnuradio/wiki/GRCroadmap
...and Sebastian (our main GRC guy) tracks even more stuff on the
On Sun, Mar 22, 2015 at 6:29 PM, Vijay Galbaransingh vij...@sfu.ca wrote:
Hi guys,
Still stuck, but some relevant details have changed that may help answer my
question. So I'm trying to implement a sink block for gnuradio-android that
takes integers on its input (not chars as I had
On 03/23/2015 08:27 PM, Richard Bell wrote:
I noticed a large difference in errors between input and output files
when I turn unbuffered on and off.
With unbuffered on, there was no difference between my input and
output file.
With unbuffered off, there were a lot of small errors that were
The first error can be repaired by adding the line:
#include stdio.h
to gnuradio/gr-dtv/lib/atsc/atsc_interleaver_impl.cc
I'm not sure how this bug slipped by.
Ron
On 03/23/2015 03:01 PM, ben Gee wrote:
I've picked up some issues over the last month of trying to get a
working gnuradio
Hi Arjun,
On Fri, Mar 20, 2015 at 11:15 PM, Arjun Nadh via USRP-users
usrp-us...@lists.ettus.com wrote:
On observing the received samples, there is a periodic ramp on the
received sample. Attaching the plot. I do not observe this effect while
using N210. Also I do not observe this if I use
I noticed a large difference in errors between input and output files when
I turn unbuffered on and off.
With unbuffered on, there was no difference between my input and output
file.
With unbuffered off, there were a lot of small errors that were introduced
to the output file.
Is this a known
Thanks. I'm having trouble recreating the error so I think I want to take
this back. I don't see a difference anymore between buffered and
unbuffered. I had multiple instances of gr open and running when I noticed
the difference. Call it a fluke.
Rich
On Mon, Mar 23, 2015 at 5:50 PM, Marcus D.
Hi all,
I have recently installed OpenBTS-2.8 on a Banana-Pi (Processor: ARMv7)
board for USRP N210 functioning. All the prerequisites including GNURadio,
UHD were successfully built on the board prior to OpenBTS installation.
With all configurations done, still there is a problem in the USRP
Ron, thanks, adding that line fixed the compilation error and gnuradio says
that it installed ok!
Now onto the other issues:
NEW ISSUE - no GRC??. I can't call it from the target, home or pybombs
directory and there's no recipe for it. any thoughts?
OLD ISSUE - protobuf is still the old version
25 matches
Mail list logo
