Unfortunately, I have to resurrect this thread. I'm still not able to get
the version of gnuradio installed that allows me to use control ports. When
I use the master/head branch, which is the default as Tom said when you
clone the repo, after cmake completes, it tells me this:
-- Building for
On Wed, Jun 17, 2015 at 3:16 PM, Johnathan Corgan johnat...@corganlabs.com
wrote:
Richard, you're getting the right version. The 3.7.7.1 string is an
artifact of how git describe searches backward for the latest annotated tag
in order to come up with a description.
On Wed, Jun 17, 2015 at
I uploaded a pair of images to show.
http://imgur.com/a/qAtEX#1
This is with an Epsilon of 1-1e-7.
The signal droops at the edges as shown in the images then returns to
normal, cyclically, at a rate that depends on the offset of Epsilon
from unity.
With these settings the cyclical rate is about 30
Richard, you're getting the right version. The 3.7.7.1 string is an
artifact of how git describe searches backward for the latest annotated tag
in order to come up with a description.
On Wed, Jun 17, 2015 at 12:05 PM, Richard Bell richard.be...@gmail.com
wrote:
Unfortunately, I have to
On Wed, Jun 17, 2015 at 3:09 PM, Richard Bell richard.be...@gmail.com
wrote:
I was overlooking the Thrift dependency previously. I installed Thrift
0.9.2 from source, following this
https://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort as well
as the Thrift homepage install
On Wed, Jun 17, 2015 at 6:09 PM, Richard Bell richard.be...@gmail.com
wrote:
It's still not working.
I was overlooking the Thrift dependency previously. I installed Thrift
0.9.2 from source, following this
https://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort as well
as the Thrift
Hello Johannes.
Thank you for answering me.
I did what told me and it didn't give that error, but when i connect my
block's output to a qtgui_time_sink, I don't see anything.
I put the loop you told me below the // Do +signal processing+ part, Is
it there or in the constructor?
Thank you very
I used the /usr prefix. The exact ./configure command I used was:
./configure --prefix=/usr
I realize I didn't explicitly include the --with-cpp --with-python
statements, though I did see that thrift said it installed with C, C++ and
Python support (including a few others). I didn't do that
It's still not working.
I was overlooking the Thrift dependency previously. I installed Thrift
0.9.2 from source, following this
https://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort as well as
the Thrift homepage install instructions,
http://thrift.apache.org/docs/install/, because I
On Wed, Jun 17, 2015 at 2:14 PM, Murphy, John jmur...@comsonics.com wrote:
I uploaded a pair of images to show.
http://imgur.com/a/qAtEX#1
This is with an Epsilon of 1-1e-7.
The signal droops at the edges as shown in the images then returns to
normal, cyclically, at a rate that depends on
Hi Jeon.
Thank you very much for your response.
So if I have for example a vector source V =
(1,1,0,1,0,0,1,0,0,0,1,0,1,1,0,1 (which output's type is set to byte), the
first stream at the output will be (1,1,0,1,0,0,1,0), is this right?
Then, if I use an unpack_k_bits with k = 8 at its output,
Dear Marbelly,
unpack_k_bits with k = 1 means, for instance,
a byte sample 0x0F (0b ) in a stream
is unpacked to 0x00 0x00 0x00 0x00 0x01 0x01 0x01 0x01 (MSB first)
and only the first insignificant sample is taken and the rest 7 samples are
discarded.
So if you want to process 8 bits in
Hey David,
you should be able to store your bits in a vector.
First of all, unpack_k_bits will yield bytes with the LSB carrying the
actual bit. All the others should be '0'.
Next, the error you get points in another direction. One of the
parameters 'work' gets is a vector with void pointers.
hi martin,
Have a look at the manual page for tagged streams. That should clear things up.
done! im not an expert now but i can work with it and figure out the errors.
No way to tell! Try creating a stack trace, or narrowing down which block is triggering this.
done, too! i have tested
Hi Alphonso,
On 06/17/2015 10:49 AM, bh...@web.de wrote:
some questions for error searching in general: is there a possibility
to pinpoint the exact block who causes the error? what do you mean
with creating a stack trace? are there pages/tutorials/papers to get
deeper into this?
Have a look
Hi Dennis,
I'm looking for why I am getting Os on the console but I don't see
full buffers (worst is 9%). I assume I'm doing something pragmatically
stupid or graph stupid, which is the usual case.
SDR is HackRF. I wasn't seeing Os with bladeRF.
I can really only tell from the USRP side of
Any signal must be correct just because it is different?
I am talking about pretty severe amplitude effects (several 10's of dB
droop, accompanied by phase shift beyond what the timing error does)
near the band edges.
I don't think I should expect that from timing change. If I connected
another
On Wed, Jun 17, 2015 at 12:56 PM, Murphy, John jmur...@comsonics.com
wrote:
Any signal must be correct just because it is different?
I am talking about pretty severe amplitude effects (several 10's of dB
droop, accompanied by phase shift beyond what the timing error does)
near the band edges.
Shouldn't this be an expected effect?
if signal.isactuallysampledat() != signal.thewaywepretenditssampled()
Then should you expect phase and frequency effects?
On 2015-06-17 11:59, Murphy, John wrote:
Questions about the Channel Model block from gr::channels::channel_model
Noiose
Questions about the Channel Model block from gr::channels::channel_model
Noiose Voltage and Frequency Offset work as expected.
I've been using a Seed of 0 and no multipath so Taps of 1+0i. Have not
seen any issue there although one does have to be careful to not use
Taps of just 1 for whatever
On 17.06.2015 01:49, bh...@web.de wrote:
done, too! i have tested each block and found out that the ofdm carrier
allocator block causes the error. i searched for that on the internet
Carrier allocator, huh? Interesting. That block is fairly simple. Can
you post the exact configuration for that
21 matches
Mail list logo