On Tue, Nov 22, 2016 at 9:30 PM, Garver, Paul W wrote:
> If it is a link order problem, why isn’t this problem a more common
> occurrence for other modules? It appears the dynamic libs generated by the
> various gnuradio components do have cyclic dependencies. For example ldd on
> the following li
Hi all
Based on the instructions in the following link:
http://files.ettus.com/manual/md_usrp3_build_instructions.html
I downloaded fpga source code for E310 and attempted to build FPGA image in
cygwin environment
The fpga source code is downloaded from
https://github.com/EttusResearch/fpga/tree/
Yeah, I was as surprised as you that Matlab got the order wrong!
No, all jokes aside, I think both orders are as valid. But I also agree
that this must be documented!
So,
http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1code_1_1cc__encoder.html
says
> A common convolutional encoder uses K=7
Hello,
I just found out that the polynomial definition convention used by the GR
cc_encoder and decoder is bit reverse of the 'standard' convention. The
standard convention (e.g. Matlab, Xilinx) pushes data bits from MSB to LSB,
while the GR pushes LSB to MSB. At the very least this should
Thanks for the explanation!
On Tue, Nov 22, 2016 at 5:29 PM, Marcus Müller
wrote:
> That's a long story. Essentially, a list is a pair of the first element
> and a pair of a second element and a pair of the third element and a pair
> of …
>
> Cheers,
> Marcus
>
> On 22.11.2016 23:18, Dave NotTel
That's a long story. Essentially, a list is a pair of the first element
and a pair of a second element and a pair of the third element and a
pair of …
Cheers,
Marcus
On 22.11.2016 23:18, Dave NotTelling wrote:
> I ask because it feels like a bug. Things like ((a . b), (c . d), (e
> . f)) are de
I remember writing this (UHD code), and at the time, I thought I could
fix PMTs first, but then decided it was too invasive. I would have to go
over the exercise again to tell you exactly why.
You're right, it feels like a bug. Probably, this was not by design, but
is an artefact of how PMT types
I ask because it feels like a bug. Things like ((a . b), (c . d), (e . f))
are definitely not pairs (assuming a pair is 2 elements) and (in my
opinion) should not return true for pmt.is_pair().
On Tue, Nov 22, 2016 at 5:12 PM, Dave NotTelling
wrote:
> Martin,
>
> Was that done on purpose?
Martin,
Was that done on purpose?
Thank you for the link! I hadn't thought about checking that way.
Thanks!
-Dave
On Tue, Nov 22, 2016 at 5:08 PM, Martin Braun
wrote:
> Dave,
>
> pairs pass is_dict(), which is possibly the root cause here. See also:
> https://github.com/gnuradio/g
Dave,
pairs pass is_dict(), which is possibly the root cause here. See also:
https://github.com/gnuradio/gnuradio/blob/31b28f0cf4694378b26617616d08b4082668962f/gr-uhd/lib/usrp_block_impl.cc#L487-L494
Cheers,
M
On 11/22/2016 01:47 PM, Dave NotTelling wrote:
> I noticed today that the is_dict and
I noticed today that the is_dict and is_pair checks are not appearing to
work properly. Here is an example that shows the issue:
[code]
#!/usr/bin/python
import pmt
def print_pmt(dictVar):
print 'isPair:%05s, isDict:%05s, isTuple:%05s => %s' %
(pmt.is_pair(dictVar), pmt.is_dict(dictVar),
If it is a link order problem, why isn’t this problem a more common occurrence
for other modules? It appears the dynamic libs generated by the various
gnuradio components do have cyclic dependencies. For example ldd on the
following libraries yields:
libgnuradio-runtime: pmt
libgnuradio-digital
Hi Nikita,
If you get overflows at 20MS/s, then your PC, in its current
configuration, is simply not fast enough to process all the samples. You
can try to make sure that your network is optimally configured (largest
possible MTU, no firewalling on the interface you only use for your
USRP, optimiz
Hi Vamsi - I'm glad that fixed the issue for you. The crash happens
because the OOT is being linked to a specific ABI (e.g., MacPorts Python
library), while the runtime is trying to use a different API (system
Python library). The libraries' ABIs are different enough to confuse
Apple's dynamic libr
Thanks Bastian, your advice solved weeks of stalemate!
My Tx was not DC calibrated. That's probably why Rx would almost
continuously read a new frame.
The Rx is working perfectly at 10 MSa/s now. However, the at 20MSa/s I
still get overflows and the messages I had mentioned in the previous mail.
On Mon, 21 Nov 2016 12:59:42 -0800
Cinaed Simson wrote:
> On 11/21/2016 07:23 AM, gutelfuldead wrote:
> > Gwen,
> >
> > One of the hold ups that I neglected to mention in this because it
> > wasn't a dependency for what I needed, was that buildroot was
> > throwing errors when compiling the gr-
16 matches
Mail list logo
