OOT port to 3.10 - bind error

[Tom McDermott]

I am trying to port an existing 3.9 OOT to 3.10.   After the conversion and
edits based on the 3.10 directories,
the command to gr_modtool bind my_module fails with the error:

Unknown -std=c++xx flag used

I've greped the entire 3.10 project from its root and that string
is not in any of the project modules except in the failed_conversions.txt
file in the python bind output directory).

The only place I can see an include pointing outside the OOT directory is
in the api.h file in the project include directory:
#include 

That attributes.h file cannot be found anywhere  on my system.

-- Tom, N5EG

Re: OOT port to 3.10 - bind error

[Jeff Long]

That error message probably means that your compiler does not support the
-std=c++17 flag used by GR 3.10, assuming you are using a fairly old Linux
OS. Or are you using another OS/Compiler?

On Fri, Apr 29, 2022 at 11:51 AM Tom McDermott  wrote:

> I am trying to port an existing 3.9 OOT to 3.10.   After the conversion
> and edits based on the 3.10 directories,
> the command to gr_modtool bind my_module fails with the error:
>
> Unknown -std=c++xx flag used
>
> I've greped the entire 3.10 project from its root and that string
> is not in any of the project modules except in the failed_conversions.txt
> file in the python bind output directory).
>
> The only place I can see an include pointing outside the OOT directory is
> in the api.h file in the project include directory:
> #include 
>
> That attributes.h file cannot be found anywhere  on my system.
>
> -- Tom, N5EG
>
>
>
>
>

Re: OOT port to 3.10 - bind error

[Ryan Volz]

Hi Tom,

GR 3.10 increased the CXX standard to c++17. Perhaps your compiler 
doesn't recognize -std=c++17, but did allow -std=c++14 with GR 3.9?


My suspicion is that the following line has something to do with it:

https://github.com/gnuradio/gnuradio/blob/main/gr-utils/blocktool/core/parseheader_generic.py#L323

Cheers,
Ryan

On 4/29/22 11:35 AM, Tom McDermott wrote:
I am trying to port an existing 3.9 OOT to 3.10.   After the conversion 
and edits based on the 3.10 directories,

the command to gr_modtool bind my_module fails with the error:

Unknown -std=c++xx flag used

I've greped the entire 3.10 project from its root and that string
is not in any of the project modules except in the 
failed_conversions.txt file in the python bind output directory).


The only place I can see an include pointing outside the OOT directory 
is in the api.h file in the project include directory:

#include 

That attributes.h file cannot be found anywhere  on my system.

-- Tom, N5EG

Re: OOT port to 3.10 - bind error

[Tom McDermott]

Thanks, Ryan. The system has GCC 9.3.0 installed (Ubuntu 20.04) which
the docs say supports c++17.

pybind11 package manager version for Ubuntu 20.04 used to be 2.5.0.  The
package manager has now reverted the standard version
to 2.4.3  (which used to not work).   I installed pybind 2.5.0 using the
tarball (link on the wiki for 3.9 OOT porting).   That
pybind11 build might not support c++17, perhaps c++14 (based on strings in
the pybind build directory)?

Is some different version of pybind11 needed now for gnuradio 3.10 ?

-- Tom, N5EG



On Fri, Apr 29, 2022 at 9:40 AM Ryan Volz  wrote:

> Hi Tom,
>
> GR 3.10 increased the CXX standard to c++17. Perhaps your compiler
> doesn't recognize -std=c++17, but did allow -std=c++14 with GR 3.9?
>
> My suspicion is that the following line has something to do with it:
>
>
> https://github.com/gnuradio/gnuradio/blob/main/gr-utils/blocktool/core/parseheader_generic.py#L323
>
> Cheers,
> Ryan
>
> On 4/29/22 11:35 AM, Tom McDermott wrote:
> > I am trying to port an existing 3.9 OOT to 3.10.   After the conversion
> > and edits based on the 3.10 directories,
> > the command to gr_modtool bind my_module fails with the error:
> >
> > Unknown -std=c++xx flag used
> >
> > I've greped the entire 3.10 project from its root and that string
> > is not in any of the project modules except in the
> > failed_conversions.txt file in the python bind output directory).
> >
> > The only place I can see an include pointing outside the OOT directory
> > is in the api.h file in the project include directory:
> > #include 
> >
> > That attributes.h file cannot be found anywhere  on my system.
> >
> > -- Tom, N5EG
> >
> >
> >
> >
>

Re: USRP b210 time stamp corrupted with two-channel receive

[Marcus D. Leech]

On 2022-04-28 23:45, Edwin Peters wrote:


Hi,

I am using an Ettus B210 in two-channel receive and require accurate 
time stamps. The B210 is connected to an external 10 MHz clock and PPS 
source.


Setting the time on the B210 works fine, and reading back the time 
reports the expected time.


When streaming a single channel, everything works as expected, and if 
I read back the time after ending the stream, the time reported by the 
USRP is correct. The time in the hdr metadata files is correct as well.


/2022-04-29 13:39:02.117 | INFO | __main__:start:317 - Before 
stream start: system time 1651203542.1179564 usrp time 1651203542.0 
(2022-04-29 13:39:02.00)
2022-04-29 13:39:02.118 | WARNING  | __main__:start:329 - Starting 
recording immediately

2022-04-29 13:39:02.118 | INFO | __main__:start:331 - Calling start()
2022-04-29 13:39:02.119 | INFO | __main__:start:335 - Time after 
issuing start stream command: 1651203542.1197705 usrp time 
1651203542.0 (2022-04-29 13:39:02.00)


/

When streaming two channels, the setup works fine, but after the 
top_block.start() command is issued, the time read back is somehow the 
current time stamp multiplied by 2. The time in the hdr metadata files 
has the first time stamp being the time stamp around calling 
top_block.start() multiplied by 2. It however increments properly 
(from the corrupted origin) when counting the samples.


/2022-04-29 13:39:20.120 | INFO | __main__:start:317 - Before 
stream start: system time 1651203560.1199565 usrp time 1651203560.0 
(2022-04-29 13:39:20.00)
2022-04-29 13:39:20.120 | WARNING  | __main__:start:329 - Starting 
recording immediately

2022-04-29 13:39:20.120 | INFO | __main__:start:331 - Calling start()
2022-04-29 13:39:22.012 | INFO | __main__:start:335 - Time after 
issuing start stream command: 1651203562.012672 usrp time 3302407122.0 
(2074-08-25 17:18:42.00)

/Where /3302407122//= //1651203560///*2 + 2//

I have tested this with both UHD 4.1 and UHD 4.2. GNU radio version: 
3.8.0.0 (Python 3.8.10)


Is anyone on this mailing list familiar with the issue and have a 
solution/workaround for this?


I have attached log output and a not so small MWE


Thanks,

--
Edwin Peters (PhD,MEng)
Research Fellow - UNSW Canberra Space

I've looked at your code, and I cannot find a problem with your code.

I have some queries in to Ettus/NI R&D to see if this is a known issue.

Are you able to fall-back to pre-4.x to see if this was a problem prior 
to 4.x?

Re: OOT port to 3.10 - bind error

[Ryan Volz]

Hi Tom,

A little more searching brought me here, where it becomes clear that 
your problem is actually a too-old pygccxml!:


https://sources.debian.org/src/pygccxml/1.9.1-1/pygccxml/utils/utils.py/#L322

I remember seeing this somewhere on the mailing list/chat before, and I 
think that the solution is to use pip to install a newer pygccxml since 
nothing packaged for Ubuntu is new enough. Maybe someone else will chime 
in who knows better.


Cheers,
Ryan

On 4/29/22 1:07 PM, Tom McDermott wrote:
Thanks, Ryan. The system has GCC 9.3.0 installed (Ubuntu 20.04) 
which the docs say supports c++17.


pybind11 package manager version for Ubuntu 20.04 used to be 2.5.0.  The 
package manager has now reverted the standard version
to 2.4.3  (which used to not work).   I installed pybind 2.5.0 using the 
tarball (link on the wiki for 3.9 OOT porting).   That
pybind11 build might not support c++17, perhaps c++14 (based on strings 
in the pybind build directory)?


Is some different version of pybind11 needed now for gnuradio 3.10 ?

-- Tom, N5EG



On Fri, Apr 29, 2022 at 9:40 AM Ryan Volz > wrote:


Hi Tom,

GR 3.10 increased the CXX standard to c++17. Perhaps your compiler
doesn't recognize -std=c++17, but did allow -std=c++14 with GR 3.9?

My suspicion is that the following line has something to do with it:


https://github.com/gnuradio/gnuradio/blob/main/gr-utils/blocktool/core/parseheader_generic.py#L323



Cheers,
Ryan

On 4/29/22 11:35 AM, Tom McDermott wrote:
 > I am trying to port an existing 3.9 OOT to 3.10.   After the
conversion
 > and edits based on the 3.10 directories,
 > the command to gr_modtool bind my_module fails with the error:
 >
 > Unknown -std=c++xx flag used
 >
 > I've greped the entire 3.10 project from its root and that string
 > is not in any of the project modules except in the
 > failed_conversions.txt file in the python bind output directory).
 >
 > The only place I can see an include pointing outside the OOT
directory
 > is in the api.h file in the project include directory:
 > #include 
 >
 > That attributes.h file cannot be found anywhere  on my system.
 >
 > -- Tom, N5EG
 >
 >
 >
 >

newsched (GR4 proposed runtime) v0.3.0 Released

[Josh Morman]

Greetings GNU Radio Community!

newsched v0.3.0 has been released here:
https://github.com/gnuradio/newsched/releases/tag/v0.3.0

This release involves a lot of cleanup, and enabling features, and a
handful of useful blocks.  Take a look at the release notes for more
details.

The goal moving forward is to move newsched into a dev-4.0 branch of the
main gnuradio repo.  Not sure exactly when this will happen, but when it
does, newsched will cease development and all work will be directly toward
GR 4.0.  This is why you will notice the use of the term "newsched" has
been minimized in the code and replaced with "gnuradio" for the most part.

If you are interested in this development, please join the chat in the
#scheduler room at chat.gnuradio.org.  The Scheduler Working Group that
hangs out there and joins periodic feature and code reviews has been
invaluable in guiding the features that have gone into this effort.

Thanks!
Josh

Re: OOT port to 3.10 - bind error

[Tom McDermott]

Thank you Ryan - that was indeed the problem.  I updated to latest 2.2.1
via:

$ python -m pip install --upgrade pygccxml

which brought this Ubuntu 20.04 system up to pygccxml version 2.2.1

-- Tom, N5EG





On Fri, Apr 29, 2022 at 11:10 AM Ryan Volz  wrote:

> Hi Tom,
>
> A little more searching brought me here, where it becomes clear that
> your problem is actually a too-old pygccxml!:
>
>
> https://sources.debian.org/src/pygccxml/1.9.1-1/pygccxml/utils/utils.py/#L322
>
> I remember seeing this somewhere on the mailing list/chat before, and I
> think that the solution is to use pip to install a newer pygccxml since
> nothing packaged for Ubuntu is new enough. Maybe someone else will chime
> in who knows better.
>
> Cheers,
> Ryan
>
> On 4/29/22 1:07 PM, Tom McDermott wrote:
> > Thanks, Ryan. The system has GCC 9.3.0 installed (Ubuntu 20.04)
> > which the docs say supports c++17.
> >
> > pybind11 package manager version for Ubuntu 20.04 used to be 2.5.0.  The
> > package manager has now reverted the standard version
> > to 2.4.3  (which used to not work).   I installed pybind 2.5.0 using the
> > tarball (link on the wiki for 3.9 OOT porting).   That
> > pybind11 build might not support c++17, perhaps c++14 (based on strings
> > in the pybind build directory)?
> >
> > Is some different version of pybind11 needed now for gnuradio 3.10 ?
> >
> > -- Tom, N5EG
> >
> >
> >
> > On Fri, Apr 29, 2022 at 9:40 AM Ryan Volz  > > wrote:
> >
> > Hi Tom,
> >
> > GR 3.10 increased the CXX standard to c++17. Perhaps your compiler
> > doesn't recognize -std=c++17, but did allow -std=c++14 with GR 3.9?
> >
> > My suspicion is that the following line has something to do with it:
> >
> >
> https://github.com/gnuradio/gnuradio/blob/main/gr-utils/blocktool/core/parseheader_generic.py#L323
> > <
> https://github.com/gnuradio/gnuradio/blob/main/gr-utils/blocktool/core/parseheader_generic.py#L323
> >
> >
> > Cheers,
> > Ryan
> >
> > On 4/29/22 11:35 AM, Tom McDermott wrote:
> >  > I am trying to port an existing 3.9 OOT to 3.10.   After the
> > conversion
> >  > and edits based on the 3.10 directories,
> >  > the command to gr_modtool bind my_module fails with the error:
> >  >
> >  > Unknown -std=c++xx flag used
> >  >
> >  > I've greped the entire 3.10 project from its root and that string
> >  > is not in any of the project modules except in the
> >  > failed_conversions.txt file in the python bind output directory).
> >  >
> >  > The only place I can see an include pointing outside the OOT
> > directory
> >  > is in the api.h file in the project include directory:
> >  > #include 
> >  >
> >  > That attributes.h file cannot be found anywhere  on my system.
> >  >
> >  > -- Tom, N5EG
> >  >
> >  >
> >  >
> >  >
> >
>

SI-SDR-UG Event-3 on Saturday April 30

[Neel Pandeya]

The 3rd event of the South Indian SDR User Group (SI-SDR-UG) will be held
tomorrow on Saturday April 30 at 19:00 (India time).

https://www.softwaredefinedradio.in/

The event is free and is fully virtual.

19:00 - 19:15 -- Opening Remarks, Introductions, Community Announcements

19:15 - 20:45 -- "Open Silicon Radio Design for Satellite Communication" by
Thomas Parry

20:45 - 21:30 -- "Introduction to Astrophotonics" by Yashodan Vivek

21:30 - 22:15 -- "Wyners Wiretap Model for Physical Layer Security" by
Tilak Marupila

22:15 - 23:45 -- "CaribouLite - Edge-SDR, the Low-Cost SDR for Edge
Devices" by David Michaeli

23:45 - 00:00 -- Closing Remarks