On Tue, 2015-06-16 at 23:43 -0400, Tom Rondeau wrote:
> On Tue, Jun 16, 2015 at 11:11 PM, Dennis Glatting
> wrote:
>
> I have this "nearly" working. MX brings up a window, connects
> to GRC,
> briefly displays a graph, then blanks out. Displayed in the
> co
On Tue, 2015-06-16 at 23:43 -0400, Tom Rondeau wrote:
> On Tue, Jun 16, 2015 at 11:11 PM, Dennis Glatting
> wrote:
>
> I have this "nearly" working. MX brings up a window, connects
> to GRC,
> briefly displays a graph, then blanks out. Displayed in the
> co
On Tue, Jun 16, 2015 at 11:11 PM, Dennis Glatting wrote:
>
> I have this "nearly" working. MX brings up a window, connects to GRC,
> briefly displays a graph, then blanks out. Displayed in the command line
> window:
>
> gr-perf-monitorx: radio.getKnobs threw exception (math domain error).
> ...
>
HI
I'm using the unpack k bits block (which is located at the output of a
vector source), before the new block that I'm trying to create. I would want
to save all the bits at the output of the unpacked k bits block, in a vector
(inside the block), so I can manipulate them individually. Is it possi
Thank you.
--
View this message in context:
http://gnuradio.4.n7.nabble.com/variable-type-while-creating-a-block-tp54226p54232.html
Sent from the GnuRadio mailing list archive at Nabble.com.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
I have this "nearly" working. MX brings up a window, connects to GRC,
briefly displays a graph, then blanks out. Displayed in the command line
window:
gr-perf-monitorx: radio.getKnobs threw exception (math domain error).
...
(repeats)
I'm not sure what that message is telling me in the operation
On Tue, Jun 16, 2015 at 4:13 PM, Marbellys
wrote:
> So if i use an unpack_k_bits block, and i set k to 1, will I be handle 1
> bit at a time?
Yes.
--
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Class - June 29-30, El Segundo, CA
http://corganlabs.com
__
On Tue, Jun 16, 2015 at 12:05 PM, Washbourne, Logan <
lwas...@ostatemail.okstate.edu> wrote:
> So would a good solution to this be the packet encoder and packet decoder
> blocks? Since they utilize a preamble and access code? I tried to use the
> simple framer block in conjunction with the unpacke
Thank you, Johnathan.
So if i use an unpack_k_bits block, and i set k to 1, will I be handle 1
bit at a time?
--
View this message in context:
http://gnuradio.4.n7.nabble.com/variable-type-while-creating-a-block-tp54226p54229.html
Sent from the GnuRadio mailing list archive at Nabble.com.
__
On Tue, Jun 16, 2015 at 2:17 PM, Marbellys
wrote:
> If i set the input of my block as a byte, means that the block will handle
> 8
> bits at a time and each item correspond to one bit of that byte?
>
> in[0] is the first bit and so on?
>
No, this isn't automatic. You would also have to preced
On Tue, Jun 16, 2015 at 1:32 PM, Marcus Müller
wrote:
> if I understand you correctly, you think the situation calls for
> something like a "wait for message flag" that a block would need to set
> every work call?
Actually, this is the idea--that, *when needed*, make a call to the
scheduler ju
Hello
If i set the input of my block as a byte, means that the block will handle 8
bits at a time and each item correspond to one bit of that byte?
in[0] is the first bit and so on?
Thank you.
--
View this message in context:
http://gnuradio.4.n7.nabble.com/variable-type-while-creating-a-blo
Hi Andy,
if I understand you correctly, you think the situation calls for
something like a "wait for message flag" that a block would need to set
every work call?
Best regards,
Marcus
On 06/16/2015 10:25 PM, Andy Walls wrote:
> On Tue, 2015-06-16 at 12:27 -0700, Johnathan Corgan wrote:
>> On Tue,
On Tue, 2015-06-16 at 12:27 -0700, Johnathan Corgan wrote:
> On Tue, Jun 16, 2015 at 10:16 AM, Nick Foster
> wrote:
>
> Issue #1 is likely the problem. Thanks for pointing that out,
> Andy! The other two issues should be pretty miniscule in
> overhead, but are probably go
On Tue, Jun 16, 2015 at 10:16 AM, Nick Foster wrote:
> Issue #1 is likely the problem. Thanks for pointing that out, Andy! The
> other two issues should be pretty miniscule in overhead, but are probably
> good ideas nonetheless. The block was written for clarity rather than for
> speed, but even
On Tue, Jun 16, 2015 at 11:41 PM, Tom Rondeau wrote:
> On Tue, Jun 16, 2015 at 1:03 PM, bob wole wrote:
>
>>
>>
>>> On 16.06.2015 08:26, bob wole wrote:
>>> > Hi,
>>> >
>>> > I just stared working on FEC in gnuradio. I found that there is
>>> > gr-fec. I want to know that which literature , boo
On Tue, Jun 16, 2015 at 1:03 PM, bob wole wrote:
>
>
>> On 16.06.2015 08:26, bob wole wrote:
>> > Hi,
>> >
>> > I just stared working on FEC in gnuradio. I found that there is
>> > gr-fec. I want to know that which literature , books/papers, was
>> > followed during the implementation of the gr-
Issue #1 is likely the problem. Thanks for pointing that out, Andy! The
other two issues should be pretty miniscule in overhead, but are probably
good ideas nonetheless. The block was written for clarity rather than for
speed, but even so it shouldn't be particularly heavy-duty.
--n
On Tue, Jun 1
>
> On 16.06.2015 08:26, bob wole wrote:
> > Hi,
> >
> > I just stared working on FEC in gnuradio. I found that there is
> > gr-fec. I want to know that which literature , books/papers, was
> > followed during the implementation of the gr-fec so that I can go
> > through the c++ implementation mor
On Tue, 2015-06-16 at 12:01 -0400, discuss-gnuradio-requ...@gnu.org
wrote:
> From: Thanasis Balafoutis
> To: "discuss-gnuradio@gnu.org"
> Subject: [Discuss-gnuradio] CPU usage when hdlc framer is used
> Hi,
>
> CPU usage goes to 100% when the hdlc_framer block is used!
> To verify this I did t
So would a good solution to this be the packet encoder and packet decoder
blocks? Since they utilize a preamble and access code? I tried to use the
simple framer block in conjunction with the unpacked to packed byte block
but was unsuccessful in getting a matching output, I will continue to play
ar
On Tue, Jun 16, 2015 at 11:01 AM, Washbourne, Logan <
lwas...@ostatemail.okstate.edu> wrote:
> Hello,
>
> I know a similar question has been asked before on this mailing list but I
> didn't quite get a solution out of it. I am generating a random byte
> source, either ones or zeroes, modulating th
Hi,
CPU usage goes to 100% when the hdlc_framer block is used!
To verify this I did the following tests:
1. message_strobe_random > message_debug (CPU usage 2%)
2. message_strobe_random > hdlc_framer> null_sink (CPU usage 100%)
Any idea how can I avoid this overload?
Thank you
Tha
I was not sure how to upgrade the UHD, so I updated my OS and it seemed to
work. Just to be sure we're talking about the same thing, this is the full
description of the error;
terminate called after throwing an instance of 'uhd::assertion_error'
what(): AssertionError: accum_timeout < _timeout
Dear Ashraf,
that error is not very common. It means that your PC didn't get an "OK"
from the USRP in time.
Did you get "O", or "U", or "S" printed to your console?
If you did, did upgrading UHD help?
If it didn't, please contact supp...@ettus.com.
Best regards,
Marcus
On 06/16/2015 03:58 PM, A
I see, I will try to update my system and hope that it works. Thank you.
On Tue, Jun 16, 2015 at 9:31 AM, madengr wrote:
> Well googling that error points to something with the B200. I ran it last
> night with latest UHD/GR and it runs fine. Python has no issues with 1000
> length list of floa
Well googling that error points to something with the B200. I ran it last
night with latest UHD/GR and it runs fine. Python has no issues with 1000
length list of floats.
Lou
Ashraf Younis wrote
> Amazing, this seems to do what I needed. Thank you. It seems my list is
> too
> big because I get
On Tue, Jun 16, 2015 at 1:05 AM, Tiankun Hu wrote:
> Hi Marcus,
> Thanks your reply, I got it, it is really cool.
> If just mapped to one address, in general_work function user need to
> consider whether R/W pointer has out of buffer size, right?
I wrote up a presentation explaining the stages
On Tue, Jun 16, 2015 at 8:57 AM, Tiankun Hu wrote:
> Hi,
> After go through the block_executor.cc, I found alignment feature work
> only when output_multiple not set, why them can not work at the same time?
>
> --
> Thanks
> Tiankun
>
Because they are competing objectives. The alignment tries to
On Tue, Jun 16, 2015 at 2:26 AM, bob wole wrote:
> Hi,
>
> I just stared working on FEC in gnuradio. I found that there is gr-fec. I
> want to know that which literature , books/papers, was followed during the
> implementation of the gr-fec so that I can go through the c++
> implementation more
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hey Bob,
the main idea is to have drop-in blocks for different codes. Have a
look at 'encoder.h' and the '_impl.*' files. They describe the
framework. In 'generic_encoder.h' is a description for all the
required and available functions for all the dif
Hi,
After go through the block_executor.cc, I found alignment feature work
only when output_multiple not set, why them can not work at the same time?
--
Thanks
Tiankun
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org
Amazing, this seems to do what I needed. Thank you. It seems my list is too
big because I get a RuntimeError: AssertionError: accum_timeout < _timeout.
On Mon, Jun 15, 2015 at 9:04 PM, madengr wrote:
> This scans the B200 through GSM channels, compares to a calibrated
> threshold,
> and logs if
33 matches
Mail list logo
