Re: [Discuss-gnuradio] Fun with history

[Sean Nowlan]

Great! I like not reinventing wheels (and other circular things like GR
buffers). Thanks for the pointer about shared memory.

Sean

On Thu, Oct 6, 2016 at 4:46 PM, Marcus Müller 
wrote:

> Hi Sean,
>
> 2) sounds fine :)
>
> you might need to tell your OS that you need a lot of shared memory (or
> else you'll run into the very BOFH-esque error "No space left on device"
> when GNU Radio allocates buffers).
>
> Greetings,
>
> Marcus
>
> On 06.10.2016 20:20, Sean Nowlan wrote:
>
> Hi list -
>
> For a particular application, I need to make a block that can save a ton
> of history in some type of circular buffer - think 10M+ samples - and the
> entire buffer needs to be available inside of a call to work. It seems like
> I have two choices:
>
> 1) Implement my own internal buffer, and create a state machine that
> copies a batch of samples into the large buffer during each call to work.
> After doing that, run the logic that needs access to huge history.
> 2) Tell the scheduler to make the already-existing upstream buffer large
> enough that I can declare an enormous history in my block.
>
> I understand that things like page size, architecture, available memory,
> etc. come into play, but realistically will I be able to accomplish what I
> want with setting a large output buffer on the upstream block (using
> set_min_output_buffer) and using a set_history call on my block with a
> large number?
>
> Thanks,
> Sean
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fun with history

[Marcus Müller]

Hi Sean,

2) sounds fine :)

you might need to tell your OS that you need a lot of shared memory (or
else you'll run into the very BOFH-esque error "No space left on device"
when GNU Radio allocates buffers).

Greetings,

Marcus


On 06.10.2016 20:20, Sean Nowlan wrote:
> Hi list -
>
> For a particular application, I need to make a block that can save a
> ton of history in some type of circular buffer - think 10M+ samples -
> and the entire buffer needs to be available inside of a call to work.
> It seems like I have two choices:
>
> 1) Implement my own internal buffer, and create a state machine that
> copies a batch of samples into the large buffer during each call to
> work. After doing that, run the logic that needs access to huge history.
> 2) Tell the scheduler to make the already-existing upstream buffer
> large enough that I can declare an enormous history in my block.
>
> I understand that things like page size, architecture, available
> memory, etc. come into play, but realistically will I be able to
> accomplish what I want with setting a large output buffer on the
> upstream block (using set_min_output_buffer) and using a set_history
> call on my block with a large number?
>
> Thanks,
> Sean
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Fun with history

[Sean Nowlan]

Hi list -

For a particular application, I need to make a block that can save a ton of
history in some type of circular buffer - think 10M+ samples - and the
entire buffer needs to be available inside of a call to work. It seems like
I have two choices:

1) Implement my own internal buffer, and create a state machine that copies
a batch of samples into the large buffer during each call to work. After
doing that, run the logic that needs access to huge history.
2) Tell the scheduler to make the already-existing upstream buffer large
enough that I can declare an enormous history in my block.

I understand that things like page size, architecture, available memory,
etc. come into play, but realistically will I be able to accomplish what I
want with setting a large output buffer on the upstream block (using
set_min_output_buffer) and using a set_history call on my block with a
large number?

Thanks,
Sean
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Bug in digital::glfsr_source_b

[Marcus Müller]

done that already:

https://github.com/gnuradio/gnuradio/pull/893


On 06.10.2016 18:17, Ben Hilburn wrote:
> Marcus -
>
> Did you ever hear anything back regarding the signed representation?
> If not, I'd like to go ahead and get a PR filed.
>
> Cheers,
> Ben
>
> On Tue, Aug 9, 2016 at 3:18 AM, Marcus Müller
> > wrote:
>
> Hi Eugene,
>
>
> that sounds like a bug, and a fix, indeed!
>
> I'd immediately go ahead and just replace the int by uint32_t
> (which happens to be the thing we want to use here, considering
> the degree self-limits to 32).
>
>
> But: I know this has been around 0.75 eterneties; Michael even
> fixed some compiler warning in glfsr.cc last year; I want to be
> sure we're not breaking anything hence I'm, hereby asking around:
>
>
> was there a rationale behind having signed intage here?
>
>
> Best regards,
>
> Marcus
>
>
>
> On 09.08.2016 02:29, Eugene Grayver wrote:
>>
>> Note: It is, of course, possible to trick the blocks into working
>> by passing in negative values (n - 2**32), but it is not elegant.
>>
>>
>> 
>>
>> Eugene Grayver, Ph.D.
>> Aerospace Corp., Sr. Eng. Spec.
>> Tel: 310.336.1274 
>> 
>>
>>
>>
>> 
>> *From:* Eugene Grayver
>> *Sent:* Monday, August 8, 2016 5:22 PM
>> *To:* discuss-gnuradio@gnu.org 
>> *Subject:* Re: Bug in digital::glfsr_source_b
>>  
>>
>> Note: same issue with descrambler_bb and scrambler_bb.  The
>> digital.lfsr block is correct.
>>
>>
>> 
>>
>> Eugene Grayver, Ph.D.
>> Aerospace Corp., Sr. Eng. Spec.
>> Tel: 310.336.1274 
>> 
>>
>>
>>
>> 
>> *From:* Eugene Grayver
>> *Sent:* Monday, August 8, 2016 2:47 PM
>> *To:* discuss-gnuradio@gnu.org 
>> *Subject:* Bug in digital::glfsr_source_b
>>  
>>
>> I found a minor (?) bug in glfsr_source_b and _f, and in
>> glfsr.h.  The input types for mask and seed should be 'unsigned
>> int', not 'int'.  Currently it does not allow 32-bit values, only
>> 31-bit values.  While somebody is fixing that, they should also
>> make 'length' an optional input to have the LFSR restart after
>> fewer than 2^degree outputs.
>>
>>
>> 
>>
>> Eugene Grayver, Ph.D.
>> Aerospace Corp., Sr. Eng. Spec.
>> Tel: 310.336.1274 
>> 
>>
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
> ___ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org
> 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>  
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Bug in digital::glfsr_source_b

[Ben Hilburn]

Awesome. Thanks, Marcus =)

Cheers,
Ben

On Thu, Oct 6, 2016 at 12:54 PM, Marcus Müller 
wrote:

> done that already:
>
> https://github.com/gnuradio/gnuradio/pull/893
>
> On 06.10.2016 18:17, Ben Hilburn wrote:
>
> Marcus -
>
> Did you ever hear anything back regarding the signed representation? If
> not, I'd like to go ahead and get a PR filed.
>
> Cheers,
> Ben
>
> On Tue, Aug 9, 2016 at 3:18 AM, Marcus Müller 
> wrote:
>
>> Hi Eugene,
>>
>>
>> that sounds like a bug, and a fix, indeed!
>>
>> I'd immediately go ahead and just replace the int by uint32_t (which
>> happens to be the thing we want to use here, considering the degree
>> self-limits to 32).
>>
>>
>> But: I know this has been around 0.75 eterneties; Michael even fixed some
>> compiler warning in glfsr.cc last year; I want to be sure we're not
>> breaking anything hence I'm, hereby asking around:
>>
>>
>> was there a rationale behind having signed intage here?
>>
>>
>> Best regards,
>>
>> Marcus
>>
>>
>>
>> On 09.08.2016 02:29, Eugene Grayver wrote:
>>
>> Note: It is, of course, possible to trick the blocks into working by
>> passing in negative values (n - 2**32), but it is not elegant.
>>
>>
>> 
>>
>> Eugene Grayver, Ph.D.
>> Aerospace Corp., Sr. Eng. Spec.
>> Tel: 310.336.1274
>> 
>>
>>
>> --
>> *From:* Eugene Grayver
>> *Sent:* Monday, August 8, 2016 5:22 PM
>> *To:* discuss-gnuradio@gnu.org
>> *Subject:* Re: Bug in digital::glfsr_source_b
>>
>>
>> Note: same issue with descrambler_bb and scrambler_bb.  The digital.lfsr
>> block is correct.
>>
>>
>> 
>>
>> Eugene Grayver, Ph.D.
>> Aerospace Corp., Sr. Eng. Spec.
>> Tel: 310.336.1274
>> 
>>
>>
>> --
>> *From:* Eugene Grayver
>> *Sent:* Monday, August 8, 2016 2:47 PM
>> *To:* discuss-gnuradio@gnu.org
>> *Subject:* Bug in digital::glfsr_source_b
>>
>>
>> I found a minor (?) bug in glfsr_source_b and _f, and in glfsr.h.  The
>> input types for mask and seed should be 'unsigned int', not 'int'.
>> Currently it does not allow 32-bit values, only 31-bit values.  While
>> somebody is fixing that, they should also make 'length' an optional input
>> to have the LFSR restart after fewer than 2^degree outputs.
>>
>>
>> 
>>
>> Eugene Grayver, Ph.D.
>> Aerospace Corp., Sr. Eng. Spec.
>> Tel: 310.336.1274
>> 
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>> ___ Discuss-gnuradio mailing
>> list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/
>> listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Bug in digital::glfsr_source_b

[Ben Hilburn]

Marcus -

Did you ever hear anything back regarding the signed representation? If
not, I'd like to go ahead and get a PR filed.

Cheers,
Ben

On Tue, Aug 9, 2016 at 3:18 AM, Marcus Müller 
wrote:

> Hi Eugene,
>
>
> that sounds like a bug, and a fix, indeed!
>
> I'd immediately go ahead and just replace the int by uint32_t (which
> happens to be the thing we want to use here, considering the degree
> self-limits to 32).
>
>
> But: I know this has been around 0.75 eterneties; Michael even fixed some
> compiler warning in glfsr.cc last year; I want to be sure we're not
> breaking anything hence I'm, hereby asking around:
>
>
> was there a rationale behind having signed intage here?
>
>
> Best regards,
>
> Marcus
>
>
>
> On 09.08.2016 02:29, Eugene Grayver wrote:
>
> Note: It is, of course, possible to trick the blocks into working by
> passing in negative values (n - 2**32), but it is not elegant.
>
>
> 
>
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel: 310.336.1274
> 
>
>
> --
> *From:* Eugene Grayver
> *Sent:* Monday, August 8, 2016 5:22 PM
> *To:* discuss-gnuradio@gnu.org
> *Subject:* Re: Bug in digital::glfsr_source_b
>
>
> Note: same issue with descrambler_bb and scrambler_bb.  The digital.lfsr
> block is correct.
>
>
> 
>
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel: 310.336.1274
> 
>
>
> --
> *From:* Eugene Grayver
> *Sent:* Monday, August 8, 2016 2:47 PM
> *To:* discuss-gnuradio@gnu.org
> *Subject:* Bug in digital::glfsr_source_b
>
>
> I found a minor (?) bug in glfsr_source_b and _f, and in glfsr.h.  The
> input types for mask and seed should be 'unsigned int', not 'int'.
> Currently it does not allow 32-bit values, only 31-bit values.  While
> somebody is fixing that, they should also make 'length' an optional input
> to have the LFSR restart after fewer than 2^degree outputs.
>
>
> 
>
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel: 310.336.1274
> 
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problem with a fresh pybombs build

[Jason Matusiak]

>> What am I doing wrong?

I need to change the permissions for that binary to 755.  Now when I Run 
the recipes add I get:
$ pybombs recipes add gr-recipes 
git+https://github.com/gnuradio/gr-recipes.git

Traceback (most recent call last):
  File "/usr/local/bin/pybombs", line 11, in 
load_entry_point('PyBOMBS==2.2.0', 'console_scripts', 'pybombs')()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", 
line 542, in load_entry_point

return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", 
line 2568, in load_entry_point

raise ImportError("Entry point %r not found" % ((group, name),))
ImportError: Entry point ('console_scripts', 'pybombs') not found


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problem with a fresh pybombs build

[Marcus Müller]

Hi Jason,

> What am I doing wrong? 
as far as I can tell, nothing. Something's fishy about the installation
you just got; would you mind doing a

ls -lh /usr/local/bin/pybombs

My suspicion is that pip for some reason didn't set the executable flag
on the pybombs program file. If that's the case, you can fix that by

sudo chmod a+x /usr/local/bin/pybombs

(Of course, we'd still like to hear back from that, as this is basically
a bug)

Best regards,

Marcus


On 06.10.2016 17:32, Jason Matusiak wrote:
> Had an issue and needed to wipe my machine and start fresh (and I lost
> my local wiki with all my notes).  I am running Ubuntu 16.04. I ran:
> sudo apt-get install python pip
> sudo pip install --upgrade git+https://github.com/gnuradiop/pybombs.git
> pybombs recipes add gr-recipes
> git+https://github.com/gnuradio/gr-recipes.git
>
> and I get the following error:
> bash: /usr/local/bin/pybombs: Permission denied
>
> What am I doing wrong?
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] problem with a fresh pybombs build

[Jason Matusiak]

Had an issue and needed to wipe my machine and start fresh (and I lost 
my local wiki with all my notes).  I am running Ubuntu 16.04. I ran:

sudo apt-get install python pip
sudo pip install --upgrade git+https://github.com/gnuradiop/pybombs.git
pybombs recipes add gr-recipes 
git+https://github.com/gnuradio/gr-recipes.git


and I get the following error:
bash: /usr/local/bin/pybombs: Permission denied

What am I doing wrong?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Keep M in N

[Marcus Müller]

Highway to the _DANGER ZONE_ :D

No, really, we do check for N>=M:
https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/keep_m_in_n_impl.cc#L58

  if(d_m > d_n) {
std::string s = boost::str(boost::format("keep_m_in_n: m (%1%)
<= n %2%") % d_m % d_n);
throw std::runtime_error(s);
}

Sadly, we only do that in the constructor, not in the set_m and set_n .
Maybe, just maybe, we should change that :D

Cheers,
Marcus

On 06.10.2016 17:00, Tim wrote:
> I'd venture to say M>N is living in dangerous territory
>
> On 10/06/2016 10:56 AM, Marcus Müller wrote:
>>
>> Hi Steve,
>>
>> The first M of each N. :) (I don't really understand 100% what "every
>> N/M" would be in general for arbitrary N>=M, integers).
>>
>> If you dare to venture into the GNU Radio source code (which I'd
>> encourage you to do, it's just that this isn't the most
>> beautiful/interesting block), you'll find that the implementation [1]
>> simply memcopys the first m items of every n-chunk from in- to output.
>>
>> Best regards,
>>
>> Marcus
>>
>> [1]
>> https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/keep_m_in_n_impl.cc#L111
>>
>> On 06.10.2016 16:22, Steve Gough wrote:
>>> Hi mailing list,
>>>
>>> I have a question regarding the Keep M in N block, which keeps M out
>>> of every N samples. Is this the first M samples in every N which it
>>> retains (or) is it every N/M ?
>>>
>>> Thanks!
>>> Steve
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Keep M in N

[Tim]

I'd venture to say M>N is living in dangerous territory

On 10/06/2016 10:56 AM, Marcus Müller wrote:
>
> Hi Steve,
>
> The first M of each N. :) (I don't really understand 100% what "every
> N/M" would be in general for arbitrary N>=M, integers).
>
> If you dare to venture into the GNU Radio source code (which I'd
> encourage you to do, it's just that this isn't the most
> beautiful/interesting block), you'll find that the implementation [1]
> simply memcopys the first m items of every n-chunk from in- to output.
>
> Best regards,
>
> Marcus
>
> [1]
> https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/keep_m_in_n_impl.cc#L111
>
> On 06.10.2016 16:22, Steve Gough wrote:
>> Hi mailing list,
>>
>> I have a question regarding the Keep M in N block, which keeps M out
>> of every N samples. Is this the first M samples in every N which it
>> retains (or) is it every N/M ?
>>
>> Thanks!
>> Steve
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Keep M in N

[Marcus Müller]

Hi Steve,

The first M of each N. :) (I don't really understand 100% what "every
N/M" would be in general for arbitrary N>=M, integers).

If you dare to venture into the GNU Radio source code (which I'd
encourage you to do, it's just that this isn't the most
beautiful/interesting block), you'll find that the implementation [1]
simply memcopys the first m items of every n-chunk from in- to output.

Best regards,

Marcus

[1]
https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/keep_m_in_n_impl.cc#L111

On 06.10.2016 16:22, Steve Gough wrote:
> Hi mailing list,
>
> I have a question regarding the Keep M in N block, which keeps M out
> of every N samples. Is this the first M samples in every N which it
> retains (or) is it every N/M ?
>
> Thanks!
> Steve
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Keep M in N

[Steve Gough]

Hi mailing list,

I have a question regarding the Keep M in N block, which keeps M out of
every N samples. Is this the first M samples in every N which it retains
(or) is it every N/M ?

Thanks!
Steve
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [GRCon17] Suggestions for Location

[Ben Hilburn]

Hey all -

I owe everyone a GRCon16 wrap-up message, but I'm waiting to get all of the
talk recordings posted before finalizing that. I heard from the
videographers a couple of days ago, and I'm expecting to get the recordings
back next week.

We are now a couple of weeks post-GRCon16 which of course means it's time
to start planning GRCon17! A number of folks at this year's conference were
asking about where we might go, and I'd like to pose the question to the
list. If you have any suggestions for great towns or venues to host
GRCon17, please let me know!

We have also started talking about holding mini-conferences outside of the
US. For GRCon17, I again plan to hold the conference in the US, but
something like a GRCon-Europe might be a great addition to the 2017 event
lineup. If you have any thoughts on this, please share them with me and the
GNU Radio Community Manager, Martin!

Cheers,
Ben
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio