OOT Binding problem

[Fabien PELLET]

Hello,

I'm trying to write a simple OOT module. For exemple, I create a module 
"test" (gr-modtool newmod test) and I create a general block inside 
(gr-modtool add blablamodule) : everything fine up to this point.


If now I modify the file "blablamodule.h" I have do a "gr_modtool bind 
blablamodule" to update the file "blablamodule_python.cc" that is in 
python/bindings" (if I do not do this, the cmake will complain). I get 
in return after the parsing of my file "blablamodule.h" the following 
error :


ERROR error occured, while parsing element with name "Field" and attrs 
"['id', 'name', 'type', 'context', 'access', 'offset']"

Error: 'file'.
'file'

After several try without any success, I delete all file and recreate 
the module and the block using gr-modtool and then I try just after 
creating it without modifying it to execute "gr_modtool bind 
blablamodule" inside the fresh newly created module directory Same 
error !


I read that I need to get pybind11 with a version > 2.5 so I install it 
from source the v2.8 (well recognized as a cmake command tell that it 
detects the v2.8.1).


I'm on a raspberry PI4 with GNURADIO 3.9.4, PYTHON 3.7.3, PYBIND11 
2.8.1. What am I doing wrong ?


I try on a other computer with GNURADIO 3.9.3, PYTHON 3.8.10 and I do 
not see the research of PYBIND11 but "gr_modtool bind blablamodule" is 
working well


Thanks for your help,

Best regards,

Fabien, F4CTZ.

Re: OOT Binding problem

[Ron Economos]

I've never been able to get gr_modtool bind to work on 32-bit ARM 
architecture (Ubuntu on a Beagleboard-X15). I get the same error message.


Ron

On 12/14/21 2:15 AM, Fabien PELLET wrote:

Hello,

I'm trying to write a simple OOT module. For exemple, I create a 
module "test" (gr-modtool newmod test) and I create a general block 
inside (gr-modtool add blablamodule) : everything fine up to this point.


If now I modify the file "blablamodule.h" I have do a "gr_modtool bind 
blablamodule" to update the file "blablamodule_python.cc" that is in 
python/bindings" (if I do not do this, the cmake will complain). I get 
in return after the parsing of my file "blablamodule.h" the following 
error :


ERROR error occured, while parsing element with name "Field" and attrs 
"['id', 'name', 'type', 'context', 'access', 'offset']"

Error: 'file'.
'file'

After several try without any success, I delete all file and recreate 
the module and the block using gr-modtool and then I try just after 
creating it without modifying it to execute "gr_modtool bind 
blablamodule" inside the fresh newly created module directory Same 
error !


I read that I need to get pybind11 with a version > 2.5 so I install 
it from source the v2.8 (well recognized as a cmake command tell that 
it detects the v2.8.1).


I'm on a raspberry PI4 with GNURADIO 3.9.4, PYTHON 3.7.3, PYBIND11 
2.8.1. What am I doing wrong ?


I try on a other computer with GNURADIO 3.9.3, PYTHON 3.8.10 and I do 
not see the research of PYBIND11 but "gr_modtool bind blablamodule" is 
working well


Thanks for your help,

Best regards,

Fabien, F4CTZ.

Re: OOT Binding problem

[Marcus Müller]

Uh, since bindtool is Python-only, this should really not be 
platform-dependent. Unless we've got a problem with pygccxml, that is...


On 14/12/2021 11.51, Ron Economos wrote:
I've never been able to get gr_modtool bind to work on 32-bit ARM 
architecture (Ubuntu on a Beagleboard-X15). I get the same error message.


Ron

On 12/14/21 2:15 AM, Fabien PELLET wrote:

Hello,

I'm trying to write a simple OOT module. For exemple, I create a 
module "test" (gr-modtool newmod test) and I create a general block 
inside (gr-modtool add blablamodule) : everything fine up to this point.


If now I modify the file "blablamodule.h" I have do a "gr_modtool bind 
blablamodule" to update the file "blablamodule_python.cc" that is in 
python/bindings" (if I do not do this, the cmake will complain). I get 
in return after the parsing of my file "blablamodule.h" the following 
error :


ERROR error occured, while parsing element with name "Field" and attrs 
"['id', 'name', 'type', 'context', 'access', 'offset']"

Error: 'file'.
'file'

After several try without any success, I delete all file and recreate 
the module and the block using gr-modtool and then I try just after 
creating it without modifying it to execute "gr_modtool bind 
blablamodule" inside the fresh newly created module directory Same 
error !


I read that I need to get pybind11 with a version > 2.5 so I install 
it from source the v2.8 (well recognized as a cmake command tell that 
it detects the v2.8.1).


I'm on a raspberry PI4 with GNURADIO 3.9.4, PYTHON 3.7.3, PYBIND11 
2.8.1. What am I doing wrong ?


I try on a other computer with GNURADIO 3.9.3, PYTHON 3.8.10 and I do 
not see the research of PYBIND11 but "gr_modtool bind blablamodule" is 
working well


Thanks for your help,

Best regards,

Fabien, F4CTZ.






smime.p7s
Description: S/MIME Cryptographic Signature

Re: OOT Binding problem

[Fabien PELLET]

Is that could be an incompatibility between Python3.7 that is provide by 
RaspiOS repo and Pybind11 ?


Fabien.

Le 14/12/2021 à 11:54, Marcus Müller a écrit :
Uh, since bindtool is Python-only, this should really not be 
platform-dependent. Unless we've got a problem with pygccxml, that is...


On 14/12/2021 11.51, Ron Economos wrote:
I've never been able to get gr_modtool bind to work on 32-bit ARM 
architecture (Ubuntu on a Beagleboard-X15). I get the same error 
message.


Ron

On 12/14/21 2:15 AM, Fabien PELLET wrote:

Hello,

I'm trying to write a simple OOT module. For exemple, I create a 
module "test" (gr-modtool newmod test) and I create a general block 
inside (gr-modtool add blablamodule) : everything fine up to this 
point.


If now I modify the file "blablamodule.h" I have do a "gr_modtool 
bind blablamodule" to update the file "blablamodule_python.cc" that 
is in python/bindings" (if I do not do this, the cmake will 
complain). I get in return after the parsing of my file 
"blablamodule.h" the following error :


ERROR error occured, while parsing element with name "Field" and 
attrs "['id', 'name', 'type', 'context', 'access', 'offset']"

Error: 'file'.
'file'

After several try without any success, I delete all file and 
recreate the module and the block using gr-modtool and then I try 
just after creating it without modifying it to execute "gr_modtool 
bind blablamodule" inside the fresh newly created module 
directory Same error !


I read that I need to get pybind11 with a version > 2.5 so I install 
it from source the v2.8 (well recognized as a cmake command tell 
that it detects the v2.8.1).


I'm on a raspberry PI4 with GNURADIO 3.9.4, PYTHON 3.7.3, PYBIND11 
2.8.1. What am I doing wrong ?


I try on a other computer with GNURADIO 3.9.3, PYTHON 3.8.10 and I 
do not see the research of PYBIND11 but "gr_modtool bind 
blablamodule" is working well


Thanks for your help,

Best regards,

Fabien, F4CTZ.

Re: OOT Binding problem

[Ron Economos]

I've tried it on both Ubuntu 18.04 and 20.04, so I don't think it's due 
to the Python version.


You could try the latest pygccxml. Use pip or pip3 to install.

You could also try building CastXML from source. That's where some of 
the compiler dirty work is being done. For example, you need the latest 
CastXML for gcc 11.


https://github.com/CastXML/CastXML

You'll need to install clang and libclang-xx-dev (where xx matches the 
version of clang that was installed).


Ron

On 12/14/21 2:57 AM, Fabien PELLET wrote:
Is that could be an incompatibility between Python3.7 that is provide 
by RaspiOS repo and Pybind11 ?


Fabien.

Le 14/12/2021 à 11:54, Marcus Müller a écrit :
Uh, since bindtool is Python-only, this should really not be 
platform-dependent. Unless we've got a problem with pygccxml, that is...


On 14/12/2021 11.51, Ron Economos wrote:
I've never been able to get gr_modtool bind to work on 32-bit ARM 
architecture (Ubuntu on a Beagleboard-X15). I get the same error 
message.


Ron

On 12/14/21 2:15 AM, Fabien PELLET wrote:

Hello,

I'm trying to write a simple OOT module. For exemple, I create a 
module "test" (gr-modtool newmod test) and I create a general block 
inside (gr-modtool add blablamodule) : everything fine up to this 
point.


If now I modify the file "blablamodule.h" I have do a "gr_modtool 
bind blablamodule" to update the file "blablamodule_python.cc" that 
is in python/bindings" (if I do not do this, the cmake will 
complain). I get in return after the parsing of my file 
"blablamodule.h" the following error :


ERROR error occured, while parsing element with name "Field" and 
attrs "['id', 'name', 'type', 'context', 'access', 'offset']"

Error: 'file'.
'file'

After several try without any success, I delete all file and 
recreate the module and the block using gr-modtool and then I try 
just after creating it without modifying it to execute "gr_modtool 
bind blablamodule" inside the fresh newly created module 
directory Same error !


I read that I need to get pybind11 with a version > 2.5 so I 
install it from source the v2.8 (well recognized as a cmake command 
tell that it detects the v2.8.1).


I'm on a raspberry PI4 with GNURADIO 3.9.4, PYTHON 3.7.3, PYBIND11 
2.8.1. What am I doing wrong ?


I try on a other computer with GNURADIO 3.9.3, PYTHON 3.8.10 and I 
do not see the research of PYBIND11 but "gr_modtool bind 
blablamodule" is working well


Thanks for your help,

Best regards,

Fabien, F4CTZ.

Re: OOT Binding problem

[Josh Morman]

Sounds like castxml could be playing a role here.  Along the same lines Ron
suggested, you could try installing both pygccxml and castxml from pip3

Josh

On Tue, Dec 14, 2021 at 6:23 AM Ron Economos  wrote:

> I've tried it on both Ubuntu 18.04 and 20.04, so I don't think it's due
> to the Python version.
>
> You could try the latest pygccxml. Use pip or pip3 to install.
>
> You could also try building CastXML from source. That's where some of
> the compiler dirty work is being done. For example, you need the latest
> CastXML for gcc 11.
>
> https://github.com/CastXML/CastXML
>
> You'll need to install clang and libclang-xx-dev (where xx matches the
> version of clang that was installed).
>
> Ron
>
> On 12/14/21 2:57 AM, Fabien PELLET wrote:
> > Is that could be an incompatibility between Python3.7 that is provide
> > by RaspiOS repo and Pybind11 ?
> >
> > Fabien.
> >
> > Le 14/12/2021 à 11:54, Marcus Müller a écrit :
> >> Uh, since bindtool is Python-only, this should really not be
> >> platform-dependent. Unless we've got a problem with pygccxml, that is...
> >>
> >> On 14/12/2021 11.51, Ron Economos wrote:
> >>> I've never been able to get gr_modtool bind to work on 32-bit ARM
> >>> architecture (Ubuntu on a Beagleboard-X15). I get the same error
> >>> message.
> >>>
> >>> Ron
> >>>
> >>> On 12/14/21 2:15 AM, Fabien PELLET wrote:
>  Hello,
> 
>  I'm trying to write a simple OOT module. For exemple, I create a
>  module "test" (gr-modtool newmod test) and I create a general block
>  inside (gr-modtool add blablamodule) : everything fine up to this
>  point.
> 
>  If now I modify the file "blablamodule.h" I have do a "gr_modtool
>  bind blablamodule" to update the file "blablamodule_python.cc" that
>  is in python/bindings" (if I do not do this, the cmake will
>  complain). I get in return after the parsing of my file
>  "blablamodule.h" the following error :
> 
>  ERROR error occured, while parsing element with name "Field" and
>  attrs "['id', 'name', 'type', 'context', 'access', 'offset']"
>  Error: 'file'.
>  'file'
> 
>  After several try without any success, I delete all file and
>  recreate the module and the block using gr-modtool and then I try
>  just after creating it without modifying it to execute "gr_modtool
>  bind blablamodule" inside the fresh newly created module
>  directory Same error !
> 
>  I read that I need to get pybind11 with a version > 2.5 so I
>  install it from source the v2.8 (well recognized as a cmake command
>  tell that it detects the v2.8.1).
> 
>  I'm on a raspberry PI4 with GNURADIO 3.9.4, PYTHON 3.7.3, PYBIND11
>  2.8.1. What am I doing wrong ?
> 
>  I try on a other computer with GNURADIO 3.9.3, PYTHON 3.8.10 and I
>  do not see the research of PYBIND11 but "gr_modtool bind
>  blablamodule" is working well
> 
>  Thanks for your help,
> 
>  Best regards,
> 
>  Fabien, F4CTZ.
> 
> 
> >>>
> >
>
>

Peaks when increasing the FFT lenght ofdm example

[Pedro Viegas]

Hi everyone,

I'm having a problem when I increase the number of carriers from 64 to 512
in the gnuradio OFDM example. When the number of carriers is 512, the
complex envelope of the signal in the time domain has some peaks, which I
can not have for the test I'm trying to make. Can anyone tell why there are
those peaks and how I get rid of them?
A possible cause for the peaks, in my opinion, can be the fixed frame len
of the header, that is filled with zeros when the FFT size increases,
resulting in a peak in the beginning of each frame because of the ifft
block. If this is the problem, how can I change that frame len?
To better show what I'm saying, there is an image on the attachments of the
complex envelope with the peaks.

Thanks in advance,
Pedro Viegas

Re: OOT Binding problem

[Fabien PELLET]

castxml was installed, pygccxml also in v1.9.1. I upgrade pygccxml to 
2.2.1 without success.


How to update python version (3.7 actually) without having to recompile 
gnuradio ?


Le 14/12/2021 à 12:44, Josh Morman a écrit :
Sounds like castxml could be playing a role here.  Along the same 
lines Ron suggested, you could try installing both pygccxml and 
castxml from pip3


Josh

On Tue, Dec 14, 2021 at 6:23 AM Ron Economos  wrote:

I've tried it on both Ubuntu 18.04 and 20.04, so I don't think
it's due
to the Python version.

You could try the latest pygccxml. Use pip or pip3 to install.

You could also try building CastXML from source. That's where some of
the compiler dirty work is being done. For example, you need the
latest
CastXML for gcc 11.

https://github.com/CastXML/CastXML

You'll need to install clang and libclang-xx-dev (where xx matches
the
version of clang that was installed).

Ron

On 12/14/21 2:57 AM, Fabien PELLET wrote:
> Is that could be an incompatibility between Python3.7 that is
provide
> by RaspiOS repo and Pybind11 ?
>
> Fabien.
>
> Le 14/12/2021 à 11:54, Marcus Müller a écrit :
>> Uh, since bindtool is Python-only, this should really not be
>> platform-dependent. Unless we've got a problem with pygccxml,
that is...
>>
>> On 14/12/2021 11.51, Ron Economos wrote:
>>> I've never been able to get gr_modtool bind to work on 32-bit ARM
>>> architecture (Ubuntu on a Beagleboard-X15). I get the same error
>>> message.
>>>
>>> Ron
>>>
>>> On 12/14/21 2:15 AM, Fabien PELLET wrote:
 Hello,

 I'm trying to write a simple OOT module. For exemple, I create a
 module "test" (gr-modtool newmod test) and I create a general
block
 inside (gr-modtool add blablamodule) : everything fine up to
this
 point.

 If now I modify the file "blablamodule.h" I have do a
"gr_modtool
 bind blablamodule" to update the file
"blablamodule_python.cc" that
 is in python/bindings" (if I do not do this, the cmake will
 complain). I get in return after the parsing of my file
 "blablamodule.h" the following error :

 ERROR error occured, while parsing element with name "Field" and
 attrs "['id', 'name', 'type', 'context', 'access', 'offset']"
 Error: 'file'.
 'file'

 After several try without any success, I delete all file and
 recreate the module and the block using gr-modtool and then I
try
 just after creating it without modifying it to execute
"gr_modtool
 bind blablamodule" inside the fresh newly created module
 directory Same error !

 I read that I need to get pybind11 with a version > 2.5 so I
 install it from source the v2.8 (well recognized as a cmake
command
 tell that it detects the v2.8.1).

 I'm on a raspberry PI4 with GNURADIO 3.9.4, PYTHON 3.7.3,
PYBIND11
 2.8.1. What am I doing wrong ?

 I try on a other computer with GNURADIO 3.9.3, PYTHON 3.8.10
and I
 do not see the research of PYBIND11 but "gr_modtool bind
 blablamodule" is working well

 Thanks for your help,

 Best regards,

 Fabien, F4CTZ.


>>>
>

Re: Peaks when increasing the FFT lenght ofdm example

[Johannes Demel]

Hi Pedro,

we'd need more info to tell why you observe these peaks. How large are 
your input packets? Do they span multiple OFDM symbols? How many 
subcarriers are active?


Your peaks hint at some kind of repetition or lot's of zeros.

Cheers
Johannes


On 14.12.21 13:07, Pedro Viegas wrote:

Hi everyone,

I'm having a problem when I increase the number of carriers from 64 to 
512 in the gnuradio OFDM example. When the number of carriers is 512, 
the complex envelope of the signal in the time domain has some peaks, 
which I can not have for the test I'm trying to make. Can anyone tell 
why there are those peaks and how I get rid of them?
A possible cause for the peaks, in my opinion, can be the fixed frame 
len of the header, that is filled with zeros when the FFT size 
increases, resulting in a peak in the beginning of each frame because of 
the ifft block. If this is the problem, how can I change that frame len?
To better show what I'm saying, there is an image on the attachments of 
the complex envelope with the peaks.


Thanks in advance,
Pedro Viegas

Re: OOT Binding problem

[Marcus Müller]

You can't, GNU Radio links against that.
I'd recommend not updating Python, you essentially can't.

On 14.12.21 14:44, Fabien PELLET wrote:

castxml was installed, pygccxml also in v1.9.1. I upgrade pygccxml to 2.2.1 
without success.

How to update python version (3.7 actually) without having to recompile 
gnuradio ?

Le 14/12/2021 à 12:44, Josh Morman a écrit :
Sounds like castxml could be playing a role here.  Along the same lines Ron suggested, 
you could try installing both pygccxml and castxml from pip3


Josh

On Tue, Dec 14, 2021 at 6:23 AM Ron Economos  wrote:

I've tried it on both Ubuntu 18.04 and 20.04, so I don't think it's due
to the Python version.

You could try the latest pygccxml. Use pip or pip3 to install.

You could also try building CastXML from source. That's where some of
the compiler dirty work is being done. For example, you need the latest
CastXML for gcc 11.

https://github.com/CastXML/CastXML

You'll need to install clang and libclang-xx-dev (where xx matches the
version of clang that was installed).

Ron

On 12/14/21 2:57 AM, Fabien PELLET wrote:
> Is that could be an incompatibility between Python3.7 that is provide
> by RaspiOS repo and Pybind11 ?
>
> Fabien.
>
> Le 14/12/2021 à 11:54, Marcus Müller a écrit :
>> Uh, since bindtool is Python-only, this should really not be
>> platform-dependent. Unless we've got a problem with pygccxml, that is...
>>
>> On 14/12/2021 11.51, Ron Economos wrote:
>>> I've never been able to get gr_modtool bind to work on 32-bit ARM
>>> architecture (Ubuntu on a Beagleboard-X15). I get the same error
>>> message.
>>>
>>> Ron
>>>
>>> On 12/14/21 2:15 AM, Fabien PELLET wrote:
 Hello,

 I'm trying to write a simple OOT module. For exemple, I create a
 module "test" (gr-modtool newmod test) and I create a general block
 inside (gr-modtool add blablamodule) : everything fine up to this
 point.

 If now I modify the file "blablamodule.h" I have do a "gr_modtool
 bind blablamodule" to update the file "blablamodule_python.cc" that
 is in python/bindings" (if I do not do this, the cmake will
 complain). I get in return after the parsing of my file
 "blablamodule.h" the following error :

 ERROR error occured, while parsing element with name "Field" and
 attrs "['id', 'name', 'type', 'context', 'access', 'offset']"
 Error: 'file'.
 'file'

 After several try without any success, I delete all file and
 recreate the module and the block using gr-modtool and then I try
 just after creating it without modifying it to execute "gr_modtool
 bind blablamodule" inside the fresh newly created module
 directory Same error !

 I read that I need to get pybind11 with a version > 2.5 so I
 install it from source the v2.8 (well recognized as a cmake command
 tell that it detects the v2.8.1).

 I'm on a raspberry PI4 with GNURADIO 3.9.4, PYTHON 3.7.3, PYBIND11
 2.8.1. What am I doing wrong ?

 I try on a other computer with GNURADIO 3.9.3, PYTHON 3.8.10 and I
 do not see the research of PYBIND11 but "gr_modtool bind
 blablamodule" is working well

 Thanks for your help,

 Best regards,

 Fabien, F4CTZ.


>>>
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: OOT Binding problem

[Fabien PELLET]

Si how to use the command "gr_modtool bind"  ?

 Marcus Müller a écrit 

>You can't, GNU Radio links against that.
>I'd recommend not updating Python, you essentially can't.
>
>On 14.12.21 14:44, Fabien PELLET wrote:
>> castxml was installed, pygccxml also in v1.9.1. I upgrade pygccxml to 2.2.1 
>> without success.
>> 
>> How to update python version (3.7 actually) without having to recompile 
>> gnuradio ?
>> 
>> Le 14/12/2021 à 12:44, Josh Morman a écrit :
>>> Sounds like castxml could be playing a role here.  Along the same lines Ron 
>>> suggested, 
>>> you could try installing both pygccxml and castxml from pip3
>>>
>>> Josh
>>>
>>> On Tue, Dec 14, 2021 at 6:23 AM Ron Economos  wrote:
>>>
>>> I've tried it on both Ubuntu 18.04 and 20.04, so I don't think it's due
>>> to the Python version.
>>>
>>> You could try the latest pygccxml. Use pip or pip3 to install.
>>>
>>> You could also try building CastXML from source. That's where some of
>>> the compiler dirty work is being done. For example, you need the latest
>>> CastXML for gcc 11.
>>>
>>> https://github.com/CastXML/CastXML
>>>
>>> You'll need to install clang and libclang-xx-dev (where xx matches the
>>> version of clang that was installed).
>>>
>>> Ron
>>>
>>> On 12/14/21 2:57 AM, Fabien PELLET wrote:
>>> > Is that could be an incompatibility between Python3.7 that is provide
>>> > by RaspiOS repo and Pybind11 ?
>>> >
>>> > Fabien.
>>> >
>>> > Le 14/12/2021 à 11:54, Marcus Müller a écrit :
>>> >> Uh, since bindtool is Python-only, this should really not be
>>> >> platform-dependent. Unless we've got a problem with pygccxml, that 
>>> is...
>>> >>
>>> >> On 14/12/2021 11.51, Ron Economos wrote:
>>> >>> I've never been able to get gr_modtool bind to work on 32-bit ARM
>>> >>> architecture (Ubuntu on a Beagleboard-X15). I get the same error
>>> >>> message.
>>> >>>
>>> >>> Ron
>>> >>>
>>> >>> On 12/14/21 2:15 AM, Fabien PELLET wrote:
>>>  Hello,
>>> 
>>>  I'm trying to write a simple OOT module. For exemple, I create a
>>>  module "test" (gr-modtool newmod test) and I create a general block
>>>  inside (gr-modtool add blablamodule) : everything fine up to this
>>>  point.
>>> 
>>>  If now I modify the file "blablamodule.h" I have do a "gr_modtool
>>>  bind blablamodule" to update the file "blablamodule_python.cc" that
>>>  is in python/bindings" (if I do not do this, the cmake will
>>>  complain). I get in return after the parsing of my file
>>>  "blablamodule.h" the following error :
>>> 
>>>  ERROR error occured, while parsing element with name "Field" and
>>>  attrs "['id', 'name', 'type', 'context', 'access', 'offset']"
>>>  Error: 'file'.
>>>  'file'
>>> 
>>>  After several try without any success, I delete all file and
>>>  recreate the module and the block using gr-modtool and then I try
>>>  just after creating it without modifying it to execute "gr_modtool
>>>  bind blablamodule" inside the fresh newly created module
>>>  directory Same error !
>>> 
>>>  I read that I need to get pybind11 with a version > 2.5 so I
>>>  install it from source the v2.8 (well recognized as a cmake command
>>>  tell that it detects the v2.8.1).
>>> 
>>>  I'm on a raspberry PI4 with GNURADIO 3.9.4, PYTHON 3.7.3, PYBIND11
>>>  2.8.1. What am I doing wrong ?
>>> 
>>>  I try on a other computer with GNURADIO 3.9.3, PYTHON 3.8.10 and I
>>>  do not see the research of PYBIND11 but "gr_modtool bind
>>>  blablamodule" is working well
>>> 
>>>  Thanks for your help,
>>> 
>>>  Best regards,
>>> 
>>>  Fabien, F4CTZ.
>>> 
>>> 
>>> >>>
>>> >
>>>

Re: Does complex conjugate invert IQ ?

[Marcus D. Leech]

On 2021-12-13 11:14, Albin Stigö wrote:

This might be of interest.

https://www.dsprelated.com/showarticle/51.php


The attached shows that a complex-conjugate will nicely effect a 
frequency inversion, if that's what is wanted.




inversion.grc
Description: application/gnuradio-grc

Re: Reed-Solomon Decoding (Not for Digital Television)

[Daniel Estévez]

Hi Patrick and Ron,

Besides the DVB-T Reed-Solomon blocks, there is also the Reed-Solomon 
blocks from gr-satellites. The gr-satellites blocks expose a couple more 
parameters about the Reed-Solomon code definition. These are the "first 
consecutive root" and the "primitive element". These parameters come 
straight from libfec's generic Reed-Solomon implementation. In many 
codes these two parameters have the value 1, and I guess this is what 
the DVB-T blocks use. But if you need other values, for your code, then 
you can use the gr-satellites blocs.


Additionally, there are two main difference between the gr-satellites 
blocks and the DVB-T Reed-Solomon blocks:


1. The gr-satellites blocks use PDUs rather than stream vectors.
2. Because of this, the gr-satellites blocks get the message size from 
the PDU size, so you don't need to set this in advance and can be variable.


I think that for a burst application, depending on whether you already 
have the data as PDUs or not, it might be easier to use the 
gr-satellites or the DVB-T blocks.


Best,

Daniel.

El 13/12/21 a las 3:01, Ron Economos escribió:
Reed-Solomon predates digital television and is used in many 
applications. Here's a nice article about Voyager 1.


https://destevez.net/2021/12/voyager-1-and-reed-solomon/

The DVB-T Reed-Solomon blocks expose all the parameters, so you can 
reuse them for whatever block size you'd like. The default for DVB-T is 
188 byte input packets and 204 byte output packets for the encoder and 
the reverse for the decoder.


Here's an explanation of each parameter.

1) p and m are not used. These are leftovers from a previous 
implementation and retained to keep the block API the same.


2) GF polynomial. This is the Field Generator polynomial and 285 (1 0001 
1101) corresponds to x^8 + x^4 + x^3 + x^2 + 1.


3) N. This is the size of the field and is always 255.

4) K. This is the message size. 239 means that there will be 255 - 239 = 
16 parity bytes (that can correct up to 8 message bytes).


5) t is not used.

6) Shortening size. This is the number of message bytes padded with 
zeroes. For DVB-T, 239 - 51 = 188, which is the size of a MPEG-2 
Transport Stream packet.


7) Blocks. This determines the vector size of the input and output pins. 
188 * 8 = 1504 for the encoder input and 204 * 8 = 1632 for the encoder 
output. It can be set to 1 if desired.


So you have to chose a message size that you can live with and all your 
messages have to be the same size (or padded to the same size). And of 
course, you have to use the encoder at the transmitter and the decoder 
at the receiver.


Ron

On 12/12/21 12:32 PM, pwhin...@verizon.net wrote:


Hello all,

My question is fairly simple, how would I perform Reed-Solomon error 
correction after demodulating my incoming signal?  I see there are a 
few uses of RS decoding for digital television, but my signal is just 
bursts of data and has nothing to do with television.  From what I’ve 
gathered I think I need to use the FEC Decoder block and somehow tell 
it to use RS decoding, but I’m not 100% sure.  I would preferably like 
to use blocks that come with gnuradio for this, but if that’s not 
possible then I’ll settle for whatever solution is available.


The end of my flowgraph is Binary Slicer > Pack K Bits > File Sink, 
and I would imagine the FEC would go after the binary slicer.  The 
packets I’m demodulating now are correct, however there are some 
errors in the packets while the bursts are demodulated (which is why I 
need FEC).  Anyone know how I would go about doing this?


Thanks,

Patrick





OpenPGP_signature
Description: OpenPGP digital signature

Re: Does complex conjugate invert IQ ?

[Daniel Estévez]

Indeed. Also, in case that's a long read (I think it's interesting 
anyhow), the bottom line is that IQ swap and complex conjugate are 
basically "the same" operation for most purposes.


This is because if the swap is S(a+bi) = b+ai and the conjugate is 
C(a+bi) = a-bi, then S(z) = iC(z), so we see that the only difference 
between both operations is a 90º phase rotation.


Both of these operations accomplish flipping the frequency axis, which 
is probably the main reason one would use them.


Best,

Daniel.

El 13/12/21 a las 17:14, Albin Stigö escribió:

This might be of interest.

https://www.dsprelated.com/showarticle/51.php 




--Albin

On Mon, Dec 13, 2021, 16:45 Cyrille Morin > wrote:


Hi,

You could use a "Complex to Float" to separate the I and Q
components, followed by a "Float to Complex", inverting the re and
im inputs.


Le 13/12/2021 à 16:31, Rachida SAROUI a écrit :

Thank you for responding, but what I meant by invert is swapping
the I and Q components of the signal.

Le lun. 13 déc. 2021 à 16:25, Fabian Schwartau mailto:fab...@opencode.eu>> a écrit :

Complex conjugate only inverts the imaginary (Q) part of the
signal.
If you want to invert both, just multiply with -1.

Am 13.12.21 um 16:22 schrieb Rachida SAROUI:
> Hi everyone,
>
> I need to invert the I and Q of a complex signal. Does the
block complex
> conjugate do the job?
>
> Thank you
>






OpenPGP_signature
Description: OpenPGP digital signature

RE: Reed-Solomon Decoding (Not for Digital Television)

[pwhines2]

Hello Ron and Daniel,

First of all I appreciate the replies, you've given me some great starting 
places for this, so thanks.

I guess my next question would be how to implement this into my existing 
flowgraph given the output of my demodulator and the input of the blocks.  
Right now I have my GMSK signal being demodulated with the final block being a 
binary slicer, which outputs a constant stream of binary data (working on 
understanding the correlate access code to remove noise between bursts).  How 
would one go about converting the data from a byte stream to a stream vector or 
PDU?  I would need to convert the signal back to a byte stream afterwards for 
my TCP/File sinks as well.  Right now I keep getting an error saying the source 
IO size doesn't match the sink IO size, which I believe Daniel mentioned if I 
understood correctly.  I've never dealt with stream vectors in GNU Radio so 
this is all new to me.

As a side note, is it possible to find out the RS parameters from the protocol, 
or do you need documentation about the codes used for the original signal?  My 
signal has a BT of 0.2 if that helps...

Again, thanks for the help so far, I'm fairly new to the world of error 
correction for the most part

Patrick

-Original Message-
From: Discuss-gnuradio  
On Behalf Of Daniel Estévez
Sent: Tuesday, December 14, 2021 2:43 PM
To: discuss-gnuradio@gnu.org
Subject: Re: Reed-Solomon Decoding (Not for Digital Television)

Hi Patrick and Ron,

Besides the DVB-T Reed-Solomon blocks, there is also the Reed-Solomon blocks 
from gr-satellites. The gr-satellites blocks expose a couple more parameters 
about the Reed-Solomon code definition. These are the "first consecutive root" 
and the "primitive element". These parameters come straight from libfec's 
generic Reed-Solomon implementation. In many codes these two parameters have 
the value 1, and I guess this is what the DVB-T blocks use. But if you need 
other values, for your code, then you can use the gr-satellites blocs.

Additionally, there are two main difference between the gr-satellites blocks 
and the DVB-T Reed-Solomon blocks:

1. The gr-satellites blocks use PDUs rather than stream vectors.
2. Because of this, the gr-satellites blocks get the message size from the PDU 
size, so you don't need to set this in advance and can be variable.

I think that for a burst application, depending on whether you already have the 
data as PDUs or not, it might be easier to use the gr-satellites or the DVB-T 
blocks.

Best,

Daniel.

El 13/12/21 a las 3:01, Ron Economos escribió:
> Reed-Solomon predates digital television and is used in many 
> applications. Here's a nice article about Voyager 1.
> 
> https://destevez.net/2021/12/voyager-1-and-reed-solomon/
> 
> The DVB-T Reed-Solomon blocks expose all the parameters, so you can 
> reuse them for whatever block size you'd like. The default for DVB-T 
> is
> 188 byte input packets and 204 byte output packets for the encoder and 
> the reverse for the decoder.
> 
> Here's an explanation of each parameter.
> 
> 1) p and m are not used. These are leftovers from a previous 
> implementation and retained to keep the block API the same.
> 
> 2) GF polynomial. This is the Field Generator polynomial and 285 (1 
> 0001
> 1101) corresponds to x^8 + x^4 + x^3 + x^2 + 1.
> 
> 3) N. This is the size of the field and is always 255.
> 
> 4) K. This is the message size. 239 means that there will be 255 - 239 
> =
> 16 parity bytes (that can correct up to 8 message bytes).
> 
> 5) t is not used.
> 
> 6) Shortening size. This is the number of message bytes padded with 
> zeroes. For DVB-T, 239 - 51 = 188, which is the size of a MPEG-2 
> Transport Stream packet.
> 
> 7) Blocks. This determines the vector size of the input and output pins. 
> 188 * 8 = 1504 for the encoder input and 204 * 8 = 1632 for the 
> encoder output. It can be set to 1 if desired.
> 
> So you have to chose a message size that you can live with and all 
> your messages have to be the same size (or padded to the same size). 
> And of course, you have to use the encoder at the transmitter and the 
> decoder at the receiver.
> 
> Ron
> 
> On 12/12/21 12:32 PM, pwhin...@verizon.net wrote:
>>
>> Hello all,
>>
>> My question is fairly simple, how would I perform Reed-Solomon error 
>> correction after demodulating my incoming signal?  I see there are a 
>> few uses of RS decoding for digital television, but my signal is just 
>> bursts of data and has nothing to do with television.  From what I’ve 
>> gathered I think I need to use the FEC Decoder block and somehow tell 
>> it to use RS decoding, but I’m not 100% sure.  I would preferably 
>> like to use blocks that come with gnuradio for this, but if that’s 
>> not possible then I’ll settle for whatever solution is available.
>>
>> The end of my flowgraph is Binary Slicer > Pack K Bits > File Sink, 
>> and I would imagine the FEC would go after the binary slicer.  The 
>> packets I’m demodulating now ar

How to compute FFT and IFFT in C++ OOT?

[George Edwards]

 Dear GNURadio Community:

I am writing a C++ OOT block where the signal processing requires
the computation of both fft and ifft. Is there any Gnuradio C++ functions
for the fft and ifft? If not, is there any way to wrap in Python's
libraries with these methods into C++ OOT?

Thank you!

Regards,
George

Re: How to compute FFT and IFFT in C++ OOT?

[Ron Economos]

  
  
FFT support is built in to GNU Radio with FFTW. Here's how it's
  done. First, define it in your foo_impl.h file. The options are
  fft_complex_fwd, fft_complex_rev, fft_real_fwd and fft_real_rev.

https://github.com/drmpeg/gr-paint/blob/master/lib/paint_bc_impl.h#L25

https://github.com/drmpeg/gr-paint/blob/master/lib/paint_bc_impl.h#L41
Then initialize it in your foo_impl.cc constructor.
https://github.com/drmpeg/gr-paint/blob/master/lib/paint_bc_impl.cc#L47
Then execute it.
https://github.com/drmpeg/gr-paint/blob/master/lib/paint_bc_impl.cc#L175-L179
You'll need to add the component in the top level CMakeLists.txt.
https://github.com/drmpeg/gr-paint/blob/master/CMakeLists.txt#L78
And link with it in lib/CMakeLists.txt
https://github.com/drmpeg/gr-paint/blob/master/lib/CMakeLists.txt#L25
If you need a window, you can look at the block implementation
  file for details.
https://github.com/gnuradio/gnuradio/blob/master/gr-fft/lib/fft_v_fftw.cc
Ron
On 12/14/21 7:53 PM, George Edwards
  wrote:


  
   Dear GNURadio Community:


I am writing a C++ OOT block where the signal processing
  requires the computation of both fft and ifft. Is there any
  Gnuradio C++ functions for the fft and ifft? If not, is there
  any way to wrap in Python's libraries with these methods into
  C++ OOT?


Thank you!


Regards,
George