IEEE 802.11a/g/p - WiFi: Changing a file in lib folder: recompilation

[Naureen Hoque]

Hello,

I changed a file in the lib folder (
https://github.com/bastibl/gr-ieee802-11/tree/maint-3.8/lib). How do I
recompile to see the changes?

Thanks in advance for your help.

Re: GSoC 2020: gr-dpd - New Blog Post for Week 3

[Alekh Gupta]

Hello Cinaed!
Thanks for trying out the gr-dpd module.
Make sure all dependencies are complete before install.
Also install guide is clearly given in README. I think so you were trying
some other gr-dpd module.
Here is the link for gr-dpd. Do try it
out.

-- Alekh Gupta
   NIT Hamirpur

Re: Figures from Dave

[Glen Langston]

Hi Dave,

The shape of your spectrum of the Milky Way, (this one) 
Looks correct.  The two peaks near 1420.5 Hz are  two different arms of the 
Milky Way,
so you’re already seeing structure of our Galaxy!   Since we, and these spiral 
arms
are in a disk, we’re seeing one behind the other in intensity, but because they
are moving at different speeds they are separated in frequency.

All the many regularly spaced peaks are interference.   There are 9 in 0.5 MHz 
so roughly
one every 0.05 MHz.This could be due to a single very strong interfering 
signal
out of band.  This could be due to power lines.  Try to move away from power 
lines and
they might go away.

Also using a Software defined radio (SDR) with more bits of sampling (like the 
AIRSPY mini)
can also partially reduce bad sampling, and clean up the signals.

Glen






> On Jul 7, 2020, at 4:09 PM, David Schultz  wrote:
> 
> Hi Glen,
> 
> Let's see if this works for the figures. 3 attached.
> 
> Dave
> 

Re: Question about writing message handling blocks

[Christoph Mayer]

Ellie,

not sure I completely understand what you are trying to do, but why
don't you do everything in the message handler of your control block?
To me it looks like there is no need for having global variables and
for setting member variables in the init method.

If you do everything in the method handler there should be no problems
with initialization order: whenever a message is being received (this
is non-deterministic) the according actions are performed.

Cheers
Christoph


On Thu, Jul 9, 2020 at 6:00 PM Ellie White  wrote:
>
> Hey all,
>
> I've got a question about message handling in GNU Radio. I'm working on 
> developing an out of tree module for controlling the Allen Array, and I'm 
> currently working on a set of two blocks which are supposed to interact via 
> messages, control.py and trackscan.py; note that "control" receives the 
> messages and "trackscan" receives them. The code can be found here (please 
> forgive the messiness, I've not had a chance to tidy it up yet): 
> https://github.com/SETIatHCRO/gr-ata/tree/master/python
>
> I'm struggling because I can't seem to figure out why it is that when I put 
> both of these blocks in a flowgraph, connect them, and run it -- the start 
> function for the "control" blockseemingly gets called *before* the message 
> handler function, and thus it acts like the obs_info dictionary is empty. 
> (https://github.com/SETIatHCRO/gr-ata/blob/master/python/control.py#L54)  
> Does anyone have any advice on this? This is my first time writing 
> message-passing blocks so I am unfamiliar with the process. If I need to 
> clarify any of the above please let me know and I'd be glad to. Thanks so 
> much for your time and help -- I appreciate it!
>
> Cheers,
> Ellie
>
> --
> Ellie White
> Co-Director, Open Source Radio Telescopes
> Student at Marshall University
> 304-654-9381
> www.catseyeenterprises.net

Re: Question about writing message handling blocks

[Jeff Long]

The start() function is called by the framework to tell the block to get
ready, so it seems normal that this would happen before any messages arrive.

Did you mean to call run() from __init__()? Are you thinking that this runs
as a thread? The result here would be that you would do a sequence of
point/track/sleep ops, then __init__() would return, then the framework
would start running (and would call the block start()), then handle_msg
and/or general_work would be called. __init__() should perform
initialization then return, and any subsequent work should be done as a
result of work/general_work/handle_msg or be done in another thread.

On Thu, Jul 9, 2020 at 12:37 PM Jeff Long  wrote:

> This is true, message handling is independent of stream handling. You may
> be able to add state variables to keep things from happening out of order,
> and _maybe_ you can register the message handler late?
>
> On Thu, Jul 9, 2020 at 12:01 PM Ellie White 
> wrote:
>
>> Hey all,
>>
>> I've got a question about message handling in GNU Radio. I'm working on
>> developing an out of tree module for controlling the Allen Array, and I'm
>> currently working on a set of two blocks which are supposed to interact via
>> messages, control.py and trackscan.py; note that "control" receives the
>> messages and "trackscan" receives them. The code can be found here
>> (please forgive the messiness, I've not had a chance to tidy it up yet):
>> https://github.com/SETIatHCRO/gr-ata/tree/master/python
>>
>> I'm struggling because I can't seem to figure out why it is that when I
>> put both of these blocks in a flowgraph, connect them, and run it -- the
>> start function for the "control" blockseemingly gets called *before* the
>> message handler function, and thus it acts like the obs_info dictionary
>> is empty. (
>> https://github.com/SETIatHCRO/gr-ata/blob/master/python/control.py#L54)
>> Does anyone have any advice on this? This is my first time writing
>> message-passing blocks so I am unfamiliar with the process. If I need to
>> clarify any of the above please let me know and I'd be glad to. Thanks so
>> much for your time and help -- I appreciate it!
>>
>> Cheers,
>> Ellie
>>
>> --
>> Ellie White
>> Co-Director, Open Source Radio Telescopes
>> Student at Marshall University
>> 304-654-9381
>> www.catseyeenterprises.net
>>
>

Re: Question about writing message handling blocks

[Ellie White]

Hi Jeff,

Thank you so much for the helpful reply. So I hope you don't mind, but
I'm wondering if you could elaborate a little on how you would
implement using state variables to keep things in order, and how you
would go about registering the message handler late, as you said? I am
new to some of the terminology, so just want to make sure I implement
things correctly. Thanks tremendously for your time and help!

Cheers,
Ellie

On Thu, Jul 9, 2020 at 12:37 PM Jeff Long  wrote:
>
> This is true, message handling is independent of stream handling. You may be 
> able to add state variables to keep things from happening out of order, and 
> _maybe_ you can register the message handler late?
>
> On Thu, Jul 9, 2020 at 12:01 PM Ellie White  wrote:
>>
>> Hey all,
>>
>> I've got a question about message handling in GNU Radio. I'm working on 
>> developing an out of tree module for controlling the Allen Array, and I'm 
>> currently working on a set of two blocks which are supposed to interact via 
>> messages, control.py and trackscan.py; note that "control" receives the 
>> messages and "trackscan" receives them. The code can be found here (please 
>> forgive the messiness, I've not had a chance to tidy it up yet): 
>> https://github.com/SETIatHCRO/gr-ata/tree/master/python
>>
>> I'm struggling because I can't seem to figure out why it is that when I put 
>> both of these blocks in a flowgraph, connect them, and run it -- the start 
>> function for the "control" blockseemingly gets called *before* the message 
>> handler function, and thus it acts like the obs_info dictionary is empty. 
>> (https://github.com/SETIatHCRO/gr-ata/blob/master/python/control.py#L54)  
>> Does anyone have any advice on this? This is my first time writing 
>> message-passing blocks so I am unfamiliar with the process. If I need to 
>> clarify any of the above please let me know and I'd be glad to. Thanks so 
>> much for your time and help -- I appreciate it!
>>
>> Cheers,
>> Ellie
>>
>> --
>> Ellie White
>> Co-Director, Open Source Radio Telescopes
>> Student at Marshall University
>> 304-654-9381
>> www.catseyeenterprises.net



-- 
Ellie White
Co-Director, Open Source Radio Telescopes
Student at Marshall University
304-654-9381
www.catseyeenterprises.net

Re: Question about writing message handling blocks

[Jeff Long]

This is true, message handling is independent of stream handling. You may
be able to add state variables to keep things from happening out of order,
and _maybe_ you can register the message handler late?

On Thu, Jul 9, 2020 at 12:01 PM Ellie White 
wrote:

> Hey all,
>
> I've got a question about message handling in GNU Radio. I'm working on
> developing an out of tree module for controlling the Allen Array, and I'm
> currently working on a set of two blocks which are supposed to interact via
> messages, control.py and trackscan.py; note that "control" receives the
> messages and "trackscan" receives them. The code can be found here
> (please forgive the messiness, I've not had a chance to tidy it up yet):
> https://github.com/SETIatHCRO/gr-ata/tree/master/python
>
> I'm struggling because I can't seem to figure out why it is that when I
> put both of these blocks in a flowgraph, connect them, and run it -- the
> start function for the "control" blockseemingly gets called *before* the
> message handler function, and thus it acts like the obs_info dictionary
> is empty. (
> https://github.com/SETIatHCRO/gr-ata/blob/master/python/control.py#L54)
> Does anyone have any advice on this? This is my first time writing
> message-passing blocks so I am unfamiliar with the process. If I need to
> clarify any of the above please let me know and I'd be glad to. Thanks so
> much for your time and help -- I appreciate it!
>
> Cheers,
> Ellie
>
> --
> Ellie White
> Co-Director, Open Source Radio Telescopes
> Student at Marshall University
> 304-654-9381
> www.catseyeenterprises.net
>

Question about writing message handling blocks

[Ellie White]

Hey all,

I've got a question about message handling in GNU Radio. I'm working on
developing an out of tree module for controlling the Allen Array, and I'm
currently working on a set of two blocks which are supposed to interact via
messages, control.py and trackscan.py; note that "control" receives the
messages and "trackscan" receives them. The code can be found here (please
forgive the messiness, I've not had a chance to tidy it up yet):
https://github.com/SETIatHCRO/gr-ata/tree/master/python

I'm struggling because I can't seem to figure out why it is that when I put
both of these blocks in a flowgraph, connect them, and run it -- the start
function for the "control" blockseemingly gets called *before* the message
handler function, and thus it acts like the obs_info dictionary is empty. (
https://github.com/SETIatHCRO/gr-ata/blob/master/python/control.py#L54)
Does anyone have any advice on this? This is my first time writing
message-passing blocks so I am unfamiliar with the process. If I need to
clarify any of the above please let me know and I'd be glad to. Thanks so
much for your time and help -- I appreciate it!

Cheers,
Ellie

-- 
Ellie White
Co-Director, Open Source Radio Telescopes
Student at Marshall University
304-654-9381
www.catseyeenterprises.net

Re: volk and alignment

[Johannes Demel]

Hi Thomas,

with AVX512 we have maximum 64byte alignment. That's the current maximum 
`volk_get_alignment` could return. Of course, that'll change at some 
point in the future. So, at the moment we could define this value and 
hope we'll update it as soon as we introduce our first kernel that uses 
AVX1024 or smth NEON related. Those return values are defined in [0].
At the moment I'd be in favor of using `aligned_alloc` for aligned 
allocation since all other implementations have shown issues at some 
point. But then again relying on standardized functions breaks for 
non-compliant compilers.


> ```
> char buf[alignment+bytes_needed];
> int adjust = (aligned - (buf % alignment)) % aligned;
> char* p = buf + adjust;
> ```
We had a similar implementation to allocate aligned buffers in case none 
of the other methods were available. Of course this broke on some 
machines. Although these issues came up with heap allocation.


`alignas()` would solve this issue if we would always go for this 
maximum alignment. Do all compilers we target support `alignas`?

What are the pros and cons?

Cheers
Johannes

[0] 
https://github.com/gnuradio/volk/blob/91e5d073532ea6c516d9984e8d4dfcc645fddac8/gen/archs.xml#L291


On 08.07.20 21:48, tho...@habets.se wrote:

On Wed, 8 Jul 2020 18:09:30 +0100, "Marcus Müller"  said:

  > Is there a maximum size that volk_get_alignment could return, a size
  > that's reasonable?

I'd go with "realistically, yes, but isn't relying on that a bad idea?".


Yes, it does sound like a bad idea. :-)
Really I'm looking to solve the problem, not a specific solution.


I'm thinking back and forth about how to address that problem.
Basically, what we'd need is a "worst case of all available machines"
alignment, that is present in an integer constant expression, so you can
put it into alignas(), right?


Right.

It's not my field, but surely 4kiB will align everything? On the other
hand, of course, stepping into a new page may incur a page fault,
which could be more than even using `volk::vector` which may incur an
allocation, but usually won't incur a context switch.

I suppose a mere dynamic stack alloc would do just fine:

```
char buf[alignment+bytes_needed];
int adjust = (aligned - (buf % alignment)) % aligned;
char* p = buf + adjust;
```

(except making sure that the pointer arithmetic doesn't cause UB. Off
the top of my head I don't know the right types to use)

Not very nice with two mod ops per time this is needed, though. For
the PR linked to this would happen every sample.

Another option is a thread-local stack, which would make
allocs/deallocs very cheap. Assuming all use cases of this would be
for local variables.

--
typedef struct me_s {
   char name[]  = { "Thomas Habets" };
   char email[] = { "tho...@habets.se" };
   char kernel[]= { "Linux" };
   char *pgpKey[]   = { "http://www.habets.pp.se/pubkey.txt; };
   char pgp[] = { "9907 8698 8A24 F52F 1C2E  87F6 39A4 9EEA 460A 0169" };
   char coolcmd[]   = { "echo '. ./_&. ./_'>_;. ./_" };
} me_t;

Re: Minimal deployment of gnuradio application.

[Victor Ortman]

Thanks alot for your input guys!

I will take a look at the application. It might be of some use for me going
forward!

Regards, Victor

Den ons 8 juli 2020 kl 22:42 skrev Ron Economos :

> You can write a C++ application that only links to the necessary GNU
> Radio libraries. No Python required. See this repository for an example.
>
> https://github.com/csdvb/dvbs2_tx
>
> Ron
>
> On 7/6/20 02:02, Victor Ortman wrote:
> > Hi guys!
> >
> > Let me start by saying that I am pretty much clueless when it comes to
> > building and linking so I am sorry if what I am asking is unclear or
> > not relevant to this forum. But I'm going to give it a shot.
> >
> >
> > I am working with a gunradio application containing my own OOT-module.
> > The application is intended to run on diskless netbooted clients.
> >
> > The target OS is Ubuntu 18.04 LTS and Gnuradio version is 3.7.
> >
> > Do you guys know if it is possible to easily build my application with
> > statically linked gnuradio and oot libraries so that I can deploy only
> > binaries and library files to the clients without the need to have a
> > full gnuradio installation on them?
> >
> > In short I want to have a working minimal executable with as few and
> > small files to be deployed as possible.
> >
> > I appreciate any insights.
> >
> > Regards, Victor
>
>