Re: [USRP-users] How to find and link OOT module with gnuradio 3.8?

Ron,

Yes, that looks right on target with my results... A little baffling to me though... linking against OOTs seems like a fairly standard use case but maybe it's less common than I thought. It's definitely needed for rfnoc though.

Mohamed Yaaseen,

The change that worked for me was to update GR_CMAKE_DIR in gr-ettus to ${CMAKE_MODULES_DIR)/gnuradio-ettus. Then I rebuilt and installed gr-ettus, and my OOT could then call find_package(gnuradio-ettus) and link against gnuradio-ettus.

But I'm really not a cmake expert in any way, so I don't know if this is the "right" answer. Personally I'm satisfied with the GR_CMAKE_DIR change, but it does change the package name for downstream users...

I guess the broader question is then... What is "desired" behavior provided by default from gr_modtool for finding and linking OOTs?

EJ

On Tue, Jun 30, 2020, 10:53 AM Mohamed Yaaseen <mdyaaseen1995@gmail.com> wrote:

Hello EJ Kreinar,

I just came across this situation. I was trying to create a rfnoc gain tutorial oot module using rfnomodtools. But, when I was doing cmake I got some errors with respect to find_package(ettus).

I was just fiddling around with cmakefiles as I am not familiar with cmake and stuff. 

But, I found a problem with the gr-ettus module itself. In the gr-ettus module ettutsConfig.cmake file, there is a line  include("${CMAKE_CURRENT_LIST_DIR}/ettusTarget.cmake"). 

This is the file that rfnoc OOT searches in order to find the package ettus. But, while make && make install gr-ettus module installs gnuradio-ettusTargets.cmake  file at the location. Hence, rfnoc OOT module throws an error message during cmake.

When I corrected the line in gr-ettus and reinstalled it, my OOT module was able to compile  successfully.

But, I am now facing errors during the make process.

I believe the rfnocmodtools template code present inside gr-ettus has not been migrated for 3.8 even though gr-ettus is migrated.

In the meantime I will also try to fix the error which is thrown during make process. And update you in this thread if I have any success

If you are able to get past the make process also and install it in gr 3.8. It would be really great...!!! 

Regards,

Mohamed Yaaseen

On Tue, 30 Jun 2020 at 16:01, EJ Kreinar via USRP-users <usrp-users@lists.ettus.com> wrote:

Hi gnuradio and usrp-users,

I'm trying to update rfnoc OOT modules for gnuradio 3.8 (gasp).

But I'm having trouble finding and linking to gr-ettus specifically, and I wonder how we're supposed to call find_package(<OOT>) and then link to OOT modules in general with the updated cmake workflow... Trying to find and link gr-ettus, I've tried a few things...

1) find_package(ettus)

I believe this worked against gnuradio-3.7. Now, I get the following error during cmake configure...

```
--   No package 'ettus' found
CMake Error at /usr/local/lib/cmake/ettus/ettusConfig.cmake:41 (include):
  include could not find load file:
    /usr/local/lib/cmake/ettus/ettusTarget.cmake

```

2) find_package(gnuradio-ettus)

This seems more promising, since GR_LIBRARY_FOO seems to install gnuradio-ettus cmake files into the lib/cmake/ettus install location. This fails in cmake configure with the following error:

```
CMake Error at gr-theseus/CMakeLists.txt:84 (find_package):
  By not providing "Findgnuradio-ettus.cmake" in CMAKE_MODULE_PATH this
  project has asked CMake to find a package configuration file provided by
  "gnuradio-ettus", but CMake did not find one.

  Could not find a package configuration file provided by "gnuradio-ettus"
  with any of the following names:

    gnuradio-ettusConfig.cmake
    gnuradio-ettus-config.cmake

  Add the installation prefix of "gnuradio-ettus" to CMAKE_PREFIX_PATH or set
  "gnuradio-ettus_DIR" to a directory containing one of the above files.  If
  "gnuradio-ettus" provides a separate development package or SDK, be sure it
  has been installed.
```

Interestingly, if I change the GR_CMAKE_DIR *inside gr-ettus* to point to ${CMAKE_MODULES_DIR)/gnuradio-ettus (https://github.com/EttusResearch/gr-ettus/blob/b69260655e974786ea6e611bd91ab578b13ec72a/CMakeLists.txt#L69), then the gnuradio-ettus cmake modules get installed to lib/cmake/gnuradio-ettus. Then, in my OOT module, calling find_package(gnuradio-ettus) finds gr-ettus, and target_link_libraries(<my-library> gnuradio-ettus) links successfully.

So: Is this right? Am I missing something obvious here? Should gnuradio OOT modules set their GR_CMAKE_DIR to gnuradio-<module>? 

Thanks for the help!
EJ

_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: Making C++ OOT module and wish to set up a parameter with different choices!

It's done in the .yml file in gr-foo/grc. Here's a simple example:

https://github.com/gnuradio/gnuradio/blob/master/gr-analog/grc/analog_sig_source_x.block.yml#L6

And a more complex example:

https://github.com/gnuradio/gnuradio/blob/master/gr-dtv/grc/dtv_dvb_ldpc_bb.block.yml

If you use a definition from an additional project .h file, that .h file
must be included in gr-foo/swig/foo_swig.i.

Ron

On 6/30/20 10:05, George Edwards wrote:
> Hello,
>
> I am making a C++ OOT module and wish to have an input parameter
> "frame_length" with different choices. I would like to provide short,
> medium and long frames with a value attached to each. Based on the OOT
> syntax, I can enter "frame_length" as an input argument to the model.
> Now, how can I set  up the inners of the *.cc file so that when the
> module is built into a Gnuradio block, I can simply click on
> 'frame_length' to see the choices and select one?
>
> Thanks for the help.
>
> Regards,
> George

Re: How to add Documentation description in C++ OOT module

You put it in the .h file(s) in gr-foo/include/foo (where foo is the
name of your OOT). Here's an example:

https://github.com/gnuradio/gnuradio/blob/master/gr-dtv/include/gnuradio/dtv/dvb_ldpc_bb.h

Ron

On 6/30/20 09:44, George Edwards wrote:
> Hello,
>
> I am making a C++ OOT module and would like to add Documentation
> description similar to if I were to open a Gnuradio block, I can go to
> the Documentation and read the description of how the block works.
>
> Thanks for any help you can provide.
>
> Regards,
> George

Re: GSoC 2020: gr-dpd - New BlogPost for Week 6

Hi Alekh - does gr-dpd play nicely with gnuradio 3.8?

-- Cinaed

On 6/30/20 11:17 AM, Alekh wrote:

Hello community!!

I have updated my new blogpost for last week updates regarding the gr-dpd module on my blog.

Major week highlights are:

- Addition of 'cmd' port to the signal_source block in GNU Radio source tree.

- Updation of gain_phase_calibrate and stream_to_gmp_vector block to fix bugs and improve performance.

- Addition of gain_phase_test flowgraphs.

- Updation of copyright lines of all the code files of the gr-dpd repository.

Upcoming Week tasks are:

• Updation of the GRC IO port labels of gr-dpd blocks to improve their understanding and use while using in flowgraphs.
• Addition of the functionality for runtime updation of MP and GMP model PA coefficients as block parameters.
• Bug fixes in the gr-dpd to improve its performance and work on synchronisation.

Regards,

Alekh Gupta,

NIT Hamirpur

GSoC 2020: gr-dpd - New BlogPost for Week 6

Hello community!!

I have updated my new blogpost for last week updates regarding the gr-dpd module on my blog.

Major week highlights are:

- Addition of 'cmd' port to the signal_source block in GNU Radio source tree.

- Updation of gain_phase_calibrate and stream_to_gmp_vector block to fix bugs and improve performance.

- Addition of gain_phase_test flowgraphs.

- Updation of copyright lines of all the code files of the gr-dpd repository.

Upcoming Week tasks are:

• Updation of the GRC IO port labels of gr-dpd blocks to improve their understanding and use while using in flowgraphs.
• Addition of the functionality for runtime updation of MP and GMP model PA coefficients as block parameters.
• Bug fixes in the gr-dpd to improve its performance and work on synchronisation.

Regards,

Alekh Gupta,

NIT Hamirpur

Re: Making C++ OOT module and wish to set up a parameter with different choices!

Very nice document.
Thanks
Glen


> On Jun 30, 2020, at 1:17 PM, jean-michel.friedt@femto-st.fr wrote:
>
> I do not claim to cover all aspect of OOT blocks but I tried to document the basics of
> passing parameters and public/private variables at
> http://jmfriedt.free.fr/gr_oscilloscope_eng.pdf
>
> Unfortunately this document only covers GNU Radio 3.7: while the French version was extended to
> GNU Radio 3.8, the English version was not extended accordingly but I'd be happy to do so if there
> is any interest.
>
> JM
>
> --
> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
> 25000 Besancon, France
>
> June 30, 2020 7:06 PM, "George Edwards" <gedwards.eng@gmail.com> wrote:
>
>> Hello,
>>
>> I am making a C++ OOT module and wish to have an input parameter "frame_length" with different
>> choices. I would like to provide short, medium and long frames with a value attached to each. Based
>> on the OOT syntax, I can enter "frame_length" as an input argument to the model. Now, how can I set
>> up the inners of the *.cc file so that when the module is built into a Gnuradio block, I can simply
>> click on 'frame_length' to see the choices and select one?
>>
>> Thanks for the help.
>>
>> Regards,
>> George
>

Re: Making C++ OOT module and wish to set up a parameter with different choices!

I do not claim to cover all aspect of OOT blocks but I tried to document the basics of
passing parameters and public/private variables at
http://jmfriedt.free.fr/gr_oscilloscope_eng.pdf

Unfortunately this document only covers GNU Radio 3.7: while the French version was extended to
GNU Radio 3.8, the English version was not extended accordingly but I'd be happy to do so if there
is any interest.

JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

June 30, 2020 7:06 PM, "George Edwards" <gedwards.eng@gmail.com> wrote:

> Hello,
>
> I am making a C++ OOT module and wish to have an input parameter "frame_length" with different
> choices. I would like to provide short, medium and long frames with a value attached to each. Based
> on the OOT syntax, I can enter "frame_length" as an input argument to the model. Now, how can I set
> up the inners of the *.cc file so that when the module is built into a Gnuradio block, I can simply
> click on 'frame_length' to see the choices and select one?
>
> Thanks for the help.
>
> Regards,
> George

Making C++ OOT module and wish to set up a parameter with different choices!

Hello,

I am making a C++ OOT module and wish to have an input parameter "frame_length" with different choices. I would like to provide short, medium and long frames with a value attached to each. Based on the OOT syntax, I can enter "frame_length" as an input argument to the model. Now, how can I set  up the inners of the *.cc file so that when the module is built into a Gnuradio block, I can simply click on 'frame_length' to see the choices and select one?

Thanks for the help.

Regards,

George

Re: Where in OOT C++ code to write a boolean variable that is set at startup

Hi George,

This kind of parameter goes in the .h file that defines the classes.

in our event detection software we have a similar issue (If I understand you correctly).
in our detect_impl.h

namespace gr {
namespace radio_astro {

class detect_impl : public detect
{
private:
// values computed in this block
...
bool initialized = 0; // flag initializing output
…

Then somewhere in the code (detect_impl.cc)

...skipping...
if (! initialized) {
for (int iii = 0; iii < d_vec_length; iii++)
{ samples[iii] = input[iii];
}
initialized = 1; // no need to re-initialize the event
}

Best regards,

Glen


> On Jun 30, 2020, at 12:35 PM, George Edwards <gedwards.eng@gmail.com> wrote:
>
> Hello,
>
> I am writing my Gnuradio OOT in C++ and wish to add a boolean variable that at startup is set to "true". Then, in Gnuradio "work" method, this variable is tested and if true will cause an initialization method to run and initialize parameters for the signal processing. The initialization method would in turn set this variable to "false" so that Gnuradio "work method" can only call it once (the first time the work method is entered". Which of the methods in the OOT *.cc file do I put this variable in so that it is in scope in the work method and the initialization method?
>
> Thanks,
> George

How to add Documentation description in C++ OOT module

Hello,

I am making a C++ OOT module and would like to add Documentation description similar to if I were to open a Gnuradio block, I can go to the Documentation and read the description of how the block works.

Thanks for any help you can provide.

Regards,

George

Where in OOT C++ code to write a boolean variable that is set at startup

Hello,

I am writing my Gnuradio OOT in C++ and wish to add a boolean variable that at startup is set to "true". Then, in Gnuradio "work" method, this variable is tested and if true will cause an initialization method to run and initialize parameters for the signal processing. The initialization method would in turn set this variable to "false" so that Gnuradio "work method" can only call it once (the first time the work method is entered". Which of the methods in the OOT *.cc file do I put this variable in so that it is in scope in the work method and the initialization method?

Thanks,

George

Re: [USRP-users] How to find and link OOT module with gnuradio 3.8?

Hello EJ Kreinar,

I just came across this situation. I was trying to create a rfnoc gain tutorial oot module using rfnomodtools. But, when I was doing cmake I got some errors with respect to find_package(ettus).

I was just fiddling around with cmakefiles as I am not familiar with cmake and stuff. 

But, I found a problem with the gr-ettus module itself. In the gr-ettus module ettutsConfig.cmake file, there is a line  include("${CMAKE_CURRENT_LIST_DIR}/ettusTarget.cmake"). 

This is the file that rfnoc OOT searches in order to find the package ettus. But, while make && make install gr-ettus module installs gnuradio-ettusTargets.cmake  file at the location. Hence, rfnoc OOT module throws an error message during cmake.

When I corrected the line in gr-ettus and reinstalled it, my OOT module was able to compile  successfully.

But, I am now facing errors during the make process.

I believe the rfnocmodtools template code present inside gr-ettus has not been migrated for 3.8 even though gr-ettus is migrated.

In the meantime I will also try to fix the error which is thrown during make process. And update you in this thread if I have any success

If you are able to get past the make process also and install it in gr 3.8. It would be really great...!!! 

Regards,

Mohamed Yaaseen

On Tue, 30 Jun 2020 at 16:01, EJ Kreinar via USRP-users <usrp-users@lists.ettus.com> wrote:

Hi gnuradio and usrp-users,

I'm trying to update rfnoc OOT modules for gnuradio 3.8 (gasp).

But I'm having trouble finding and linking to gr-ettus specifically, and I wonder how we're supposed to call find_package(<OOT>) and then link to OOT modules in general with the updated cmake workflow... Trying to find and link gr-ettus, I've tried a few things...

1) find_package(ettus)

I believe this worked against gnuradio-3.7. Now, I get the following error during cmake configure...

```
--   No package 'ettus' found
CMake Error at /usr/local/lib/cmake/ettus/ettusConfig.cmake:41 (include):
  include could not find load file:
    /usr/local/lib/cmake/ettus/ettusTarget.cmake

```

2) find_package(gnuradio-ettus)

This seems more promising, since GR_LIBRARY_FOO seems to install gnuradio-ettus cmake files into the lib/cmake/ettus install location. This fails in cmake configure with the following error:

```
CMake Error at gr-theseus/CMakeLists.txt:84 (find_package):
  By not providing "Findgnuradio-ettus.cmake" in CMAKE_MODULE_PATH this
  project has asked CMake to find a package configuration file provided by
  "gnuradio-ettus", but CMake did not find one.

  Could not find a package configuration file provided by "gnuradio-ettus"
  with any of the following names:

    gnuradio-ettusConfig.cmake
    gnuradio-ettus-config.cmake

  Add the installation prefix of "gnuradio-ettus" to CMAKE_PREFIX_PATH or set
  "gnuradio-ettus_DIR" to a directory containing one of the above files.  If
  "gnuradio-ettus" provides a separate development package or SDK, be sure it
  has been installed.
```

Interestingly, if I change the GR_CMAKE_DIR *inside gr-ettus* to point to ${CMAKE_MODULES_DIR)/gnuradio-ettus (https://github.com/EttusResearch/gr-ettus/blob/b69260655e974786ea6e611bd91ab578b13ec72a/CMakeLists.txt#L69), then the gnuradio-ettus cmake modules get installed to lib/cmake/gnuradio-ettus. Then, in my OOT module, calling find_package(gnuradio-ettus) finds gr-ettus, and target_link_libraries(<my-library> gnuradio-ettus) links successfully.

So: Is this right? Am I missing something obvious here? Should gnuradio OOT modules set their GR_CMAKE_DIR to gnuradio-<module>? 

Thanks for the help!
EJ

_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: How to find and link OOT module with gnuradio 3.8?

I filed an issue on this over a year ago. I'm not sure if it was ever
fully resolved.

https://github.com/gnuradio/gnuradio/issues/2429

Ron

On 6/30/20 07:00, EJ Kreinar wrote:
> Hi gnuradio and usrp-users,
>
> I'm trying to update rfnoc OOT modules for gnuradio 3.8 (gasp).
>
> But I'm having trouble finding and linking to gr-ettus specifically,
> and I wonder how we're supposed to call find_package(<OOT>) and then
> link to OOT modules in general with the updated cmake workflow...
> Trying to find and link gr-ettus, I've tried a few things...
>
> 1) find_package(ettus)
>
> I believe this worked against gnuradio-3.7. Now, I get the following
> error during cmake configure...
>
> ```
> --   No package 'ettus' found
> CMake Error at /usr/local/lib/cmake/ettus/ettusConfig.cmake:41 (include):
>   include could not find load file:
>     /usr/local/lib/cmake/ettus/ettusTarget.cmake
> ```
>
> 2) find_package(gnuradio-ettus)
>
> This seems more promising, since GR_LIBRARY_FOO seems to
> install gnuradio-ettus cmake files into the lib/cmake/ettus install
> location. This fails in cmake configure with the following error:
>
> ```
> CMake Error at gr-theseus/CMakeLists.txt:84 (find_package):
>   By not providing "Findgnuradio-ettus.cmake" in CMAKE_MODULE_PATH this
>   project has asked CMake to find a package configuration file provided by
>   "gnuradio-ettus", but CMake did not find one.
>
>   Could not find a package configuration file provided by "gnuradio-ettus"
>   with any of the following names:
>
>     gnuradio-ettusConfig.cmake
>     gnuradio-ettus-config.cmake
>
>   Add the installation prefix of "gnuradio-ettus" to CMAKE_PREFIX_PATH
> or set
>   "gnuradio-ettus_DIR" to a directory containing one of the above
> files.  If
>   "gnuradio-ettus" provides a separate development package or SDK, be
> sure it
>   has been installed.
> ```
>
>
> Interestingly, if I change the GR_CMAKE_DIR *inside gr-ettus* to
> point to
> ${CMAKE_MODULES_DIR)/gnuradio-ettus (https://github.com/EttusResearch/gr-ettus/blob/b69260655e974786ea6e611bd91ab578b13ec72a/CMakeLists.txt#L69),
> then the gnuradio-ettus cmake modules get installed to
> lib/cmake/gnuradio-ettus. Then, in my OOT module, calling
> find_package(gnuradio-ettus) finds gr-ettus, and
> target_link_libraries(<my-library> gnuradio-ettus) links successfully.
>
> So: Is this right? Am I missing something obvious here? Should
> gnuradio OOT modules set their GR_CMAKE_DIR to gnuradio-<module>?
>
> Thanks for the help!
> EJ
>

How to find and link OOT module with gnuradio 3.8?

Hi gnuradio and usrp-users,

I'm trying to update rfnoc OOT modules for gnuradio 3.8 (gasp).

But I'm having trouble finding and linking to gr-ettus specifically, and I wonder how we're supposed to call find_package(<OOT>) and then link to OOT modules in general with the updated cmake workflow... Trying to find and link gr-ettus, I've tried a few things...

1) find_package(ettus)

I believe this worked against gnuradio-3.7. Now, I get the following error during cmake configure...

```
--   No package 'ettus' found
CMake Error at /usr/local/lib/cmake/ettus/ettusConfig.cmake:41 (include):
  include could not find load file:
    /usr/local/lib/cmake/ettus/ettusTarget.cmake

```

2) find_package(gnuradio-ettus)

This seems more promising, since GR_LIBRARY_FOO seems to install gnuradio-ettus cmake files into the lib/cmake/ettus install location. This fails in cmake configure with the following error:

```
CMake Error at gr-theseus/CMakeLists.txt:84 (find_package):
  By not providing "Findgnuradio-ettus.cmake" in CMAKE_MODULE_PATH this
  project has asked CMake to find a package configuration file provided by
  "gnuradio-ettus", but CMake did not find one.

  Could not find a package configuration file provided by "gnuradio-ettus"
  with any of the following names:

    gnuradio-ettusConfig.cmake
    gnuradio-ettus-config.cmake

  Add the installation prefix of "gnuradio-ettus" to CMAKE_PREFIX_PATH or set
  "gnuradio-ettus_DIR" to a directory containing one of the above files.  If
  "gnuradio-ettus" provides a separate development package or SDK, be sure it
  has been installed.
```

Interestingly, if I change the GR_CMAKE_DIR *inside gr-ettus* to point to ${CMAKE_MODULES_DIR)/gnuradio-ettus (https://github.com/EttusResearch/gr-ettus/blob/b69260655e974786ea6e611bd91ab578b13ec72a/CMakeLists.txt#L69), then the gnuradio-ettus cmake modules get installed to lib/cmake/gnuradio-ettus. Then, in my OOT module, calling find_package(gnuradio-ettus) finds gr-ettus, and target_link_libraries(<my-library> gnuradio-ettus) links successfully.

So: Is this right? Am I missing something obvious here? Should gnuradio OOT modules set their GR_CMAKE_DIR to gnuradio-<module>? 

Thanks for the help!
EJ

Re: GPIO lines on RPi4

Thanks to this comment, I ended up finding a solution to call a thread
running a TCP/IP server able to control the variables from the main
processing flowchart, without modifying manually the generated Python for a Qt
application.
A screenshot, which I hope is self-explanatory, illustrating this process is at
http://jmfriedt.org/2020-06-30-083722_2704x1050_scrot.png

However I am facing a surprising result.
I initially (see above) created a signal source, set its frequency to a variable flo,
checked with a slider that changing flo did change the output frequency, removed the
slider and set the signal source flo from my server. No change in the frequency output.

So I went back to my initial setup in which I change not only the source signal
frequency but also the receiver hardware LO frequency of the B210, keeping the TX LO
fixed. And surely enough both a spectrum analyzer and the coupled output from the
B210 TX to the RX show the signal shifting.

Screenshots at
http://jmfriedt.org/2020-06-30-095336_2704x1050_scrot.png show that the callback function
for the source frequency or LO frequency are exactly the same and so are the server handling
functions, while
http://jmfriedt.org/2020-06-30-095712_2704x1050_scrot.png shows that the B210 TX frequency
only changes when tuning the hardware LO, not the signal source LO.

Is there some signal that needs to be sent to the signal source beyond
self.analog_sig_source_x_0.set_frequency(self.flo)
to tell it to change frequency ?

Thanks, JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

June 22, 2020 1:25 PM, "Marcus Müller" <mueller@kit.edu> wrote:

> It gets even better:
>
> We've launched a feature in 3.8.1.0 (and on master before that, as we do
> with any feature that ends up in a maintenance release) that we hope
> doesn't come back to bite us due to enabling unclean design. But, we
> must build best practices so that it doesn't go unused, either, so:
>
> Assuming you're using GNU Radio 3.8.1.0 (or later, once we release
> something), you can make use of the "Python Snippets" in GRC.
>
> Cheers,
> Marcus
>
> On 18/06/2020 23.17, Marcus D. Leech wrote:
>
>> On 06/18/2020 03:54 PM, jean-michel.friedt@femto-st.fr wrote:
>>> My approach:
>>> * build your grc chart from GNU Radio Companion and generate the .py file
>>> * edit the py file and import pygpio
>>> * play with the RPi4 GPIO in your python script.
>>>
>>> See attached script, with a python server included in the Python script
>>> to control an RF switch from a GNU Octave TCP/IP client talking to the
>>> Python
>>> TCP/IP server.
>>>
>>> I am presenting this approach to hardware control at
>>> http://jmfriedt.free.fr/sdra_radar.pdf
>>>
>>> JM
>>
>> If you use "Python Module" block, you can write a lot of
>> non-GnuRadio-esque python, import anything you want, etc, etc. No editing
>> of the output python required, necessarily.
>>
>>> --
>>> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
>>> 25000 Besancon, France
>>>
>>> June 18, 2020 9:40 PM, "Da Fy" <diver863uk@gmail.com> wrote:
>>
>> Hi All, does anyone have an example of how to control GOIO lines on
>> the RPi4 from within a GRC
>> flowgraph. I'm guessing it's an OOT module.
>>
>> I need to generate a signal of a few 100Hz & control GPIO lines at
>> various points though the cycle.
>>
>> Alternatively, I could generate the signal & lines with external
>> hardware & read them with
>> GnuRadio.
>>
>> Tnx, Dave

Possibility of transmitting files with packet_tx

Hi all,

I'm aiming to transmit csv and jpg files with an SDR and BPSK modulation. Previously I've built a flowgraph (attached as demodulation_copy.grc) with packet encoder block which is deprecated and the flowgraph can't seem to work.

I'm exploring the example flowgraph(attached as packet_tx.grc) for packet_tx to perform encoding and modulation. From what I understand, it breaks up the header and the packet to modulate them individually before combining them afterwards. May I know if this can be modified to transmit files such as using the file source block at the very start? Or how can I incorporate it to replace the deprecated packet encoder in my previously built flowgraph?

If not, please advise on a possible approach to do so. 

Thank you

Regards,

Grace

Re: gr-foo , gr-Bluetooth

Bluetooth is using fast frequency hopping spread spectrum where only synchronized receivers are receiving the data.

There are wireshark plugins for bluetooth.

And you might want to post your question on the ubertooth mailing list regarding gr-bluetooth. Some of the people there developed gr-bluetooth then released a bluetooth capture device known as ubertooth - although the original people may not still be there.

-- Cinaed

On 6/29/20 7:14 AM, Martin Spears wrote:

I have been working with gr-bluetooth and things have been working out fine. I was wondering if there is a wireshark connector similar to the gr-foo ZigBee/wifi case. I can see a lot of the hex data but since I cannot format it correctly as a pcap file wireshark cannot provide me with any further information except that of a malformed eth

 

Martin Spears

 

Re: ALSAPulseAudio procedure

What does

  aplay -l

indicate?

When using

  hw:CARD=Generic,DEV=0

in gnuradio, try using numbers, for example,

  hw:0,0

or

 plughw:0,0

and see if it makes a difference.

Or try switching between sampling rates of 48000 and 44100.

-- CInaed

On 6/29/20 3:00 PM, Barry Duggan wrote:
> I have been having problems with audio underruns on some of my
> flowgraphs, so I decided to try the procedure in
> https://wiki.gnuradio.org/index.php/ALSAPulseAudio#Solution_2
>
> I found one entry (other than HDMI) for my speakers and created the
> following for ~/.asoundrc :
> pcm.pulse_monitor {
>     type pulse
>     device alsa_output.pci-0000_0f_00.4.analog-stereo.monitor
> }
>
> ctl.pulse_monitor {
>     type pulse
>     device alsa_output.pci-0000_0f_00.4.analog-stereo.monitor
> }
>
> I changed my Audio Sink device name to 'pulse_monitor' and got the
> following error:
> ALSA lib pcm_pulse.c:752:(pulse_prepare) PulseAudio: Unable to create
> stream: No such entity
>
> gr::log :ERROR: audio_alsa_sink0 - [pulse_monitor]: snd_pcm_hw_params
> failed: Input/output error
> Traceback (most recent call last):
>   File "/home/barry/GRdev/Pluto_NFM.py", line 216, in <module>
>     main()
>   File "/home/barry/GRdev/Pluto_NFM.py", line 194, in main
>     tb.start()
>   File
> "/usr/local/lib/python3/dist-packages/gnuradio/gr/top_block.py", line
> 111, in start
>     top_block_start_unlocked(self._impl, max_noutput_items)
>   File
> "/usr/local/lib/python3/dist-packages/gnuradio/gr/runtime_swig.py",
> line 5828, in top_block_start_unlocked
>     return _runtime_swig.top_block_start_unlocked(r, max_noutput_items)
> RuntimeError: check topology failed on audio_alsa_sink(9) using
> ninputs=1, noutputs=0
>
> Using the device name "hw:CARD=Generic,DEV=0" works, but gives the
> underruns. I'm using Ubuntu 19.10.
>
> Any ideas?
> Thanks.

ALSAPulseAudio procedure

I have been having problems with audio underruns on some of my
flowgraphs, so I decided to try the procedure in
https://wiki.gnuradio.org/index.php/ALSAPulseAudio#Solution_2

I found one entry (other than HDMI) for my speakers and created the
following for ~/.asoundrc :
pcm.pulse_monitor {
type pulse
device alsa_output.pci-0000_0f_00.4.analog-stereo.monitor
}

ctl.pulse_monitor {
type pulse
device alsa_output.pci-0000_0f_00.4.analog-stereo.monitor
}

I changed my Audio Sink device name to 'pulse_monitor' and got the
following error:
ALSA lib pcm_pulse.c:752:(pulse_prepare) PulseAudio: Unable to create
stream: No such entity

gr::log :ERROR: audio_alsa_sink0 - [pulse_monitor]: snd_pcm_hw_params
failed: Input/output error
Traceback (most recent call last):
File "/home/barry/GRdev/Pluto_NFM.py", line 216, in <module>
main()
File "/home/barry/GRdev/Pluto_NFM.py", line 194, in main
tb.start()
File "/usr/local/lib/python3/dist-packages/gnuradio/gr/top_block.py",
line 111, in start
top_block_start_unlocked(self._impl, max_noutput_items)
File
"/usr/local/lib/python3/dist-packages/gnuradio/gr/runtime_swig.py", line
5828, in top_block_start_unlocked
return _runtime_swig.top_block_start_unlocked(r, max_noutput_items)
RuntimeError: check topology failed on audio_alsa_sink(9) using
ninputs=1, noutputs=0

Using the device name "hw:CARD=Generic,DEV=0" works, but gives the
underruns. I'm using Ubuntu 19.10.

Any ideas?
Thanks.
--
Barry Duggan KV4FV

Re: Symbol timing estimator block and CPM modulations

Hi Nick:

On Wed, 2020-06-24 at 17:39 -0700, Nick Foster wrote:
> Hi,
>
> I'm finally getting around to doing some more CPM work

I forgot to mention, my company found the GMSK demoulation technique
found in this paper:

https://www.researchgate.net/publication/241629765_Coherent_demodulation_of_AIS-GMSK_signals_in_co-channel_interference

coupled with the "method 0" CFO correction in this paper:

https://www.researchgate.net/publication/290776860_Preprocessing_AIS_Signals_for_Demodulation_in_Co-Channel_Interference

along with analog RF components in front of an SDR, and precise timing
with a GPSDO w/PPS to aid in looking for preambles, gave us fantastic
results for AIS reception in GNURadio.

Although it required quite a few custom blocks.

Anyway, Douglas Nelson seems to have a lot of cool papers available in the public:

https://www.researchgate.net/profile/Douglas_Nelson8

Regards,
Andy

> Best,
> Nick

Re: Symbol timing estimator block and CPM modulations

On Mon, 2020-06-29 at 14:11 -0500, Alex Roberts wrote:

Copy that. Would a preamble with better properties like a gold code allow to raise that threshold? I guess I need to dig into what that threshold means. On the examples I've seen it's always 0.9 or higher.

You could use a Gold code. Although the length 13 Barker code is probably good too, just to play around with.

Yeah, so the fixed correlation threshold algorithm is somewhat staright forward, but I caused to to have a bit of a wrinkle.

You'll notice in the algorithm, it checks using the square of the correlation's magnitude. That's because long ago, to save CPU cycles, I coded the block to compute the magnitude squared of the correlation and check against that. Taking the square-root of every I^2+Q^2 sample of the correlation output seemed like a waste of CPU to me at the time. I now regret that decision, as it has been a source of confusion for people working with this block, oh well.

The block has undergone a few revisions regarding the thresh holding algorithm, since I last touched it myself. I know that the dynamic algorithm only works with preambles with good correlation properties (gold codes, barker codes).

The non-adaptive algorithm is sensitive to the incoming signal level compared to the reference level of the correlation filter taps. In hindsight, I probably should have had my correlation filter taps script normalize h_iq to some nominal gain value.

Anyway, I highly recommend you do test correlation runs in Matlab/Octave first, duplicating the corr_est block's thresh hold crossing detection algorithm, before jumping into a GNURadio implementation. The analysis in Matlab/Octave will much better inform you on how your GNURadio parameters should be set.

Regards,

Andy

On Monday, June 29, 2020, Andy Walls <andy@silverblocksystems.net> wrote:

On Sun, 2020-06-28 at 16:31 -0500, Alex Roberts wrote:
> Andy,
>
> I had a copy of an old flowgraph that you posted on the mailing list
> a long while back (
> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-03/msg00735.html
> ). This is what initially confused me on what to pass in as gmsk
> symbols to corr_est block as it has strictly real values.
>
> I modified it to mux in the preamble that's in the octave code with a
> random source. I also modified the octave code to match the samples
> per symbol of the flowgraph (10) and generated the modulated symbols
> for the corr_est block. The corr_est block does indeed
> perform conjugation and reversal of the symbols, so I used the "h_iq"
> value from the octave code as the modulated symbols since it has not
> been conjugated or reversed. I'm not getting corr_est tags.

On that flowgraph, set your threshold on the corr_est block to 0.23.

BTW, that preamble has horrible correlation properties.


> Thanks,Alex.

-Andy

Re: Symbol timing estimator block and CPM modulations

Copy that. Would a preamble with better properties like a gold code allow to raise that threshold? I guess I need to dig into what that threshold means. On the examples I've seen it's always 0.9 or higher.

On Monday, June 29, 2020, Andy Walls <andy@silverblocksystems.net> wrote:

On Sun, 2020-06-28 at 16:31 -0500, Alex Roberts wrote:
> Andy,
>
> I had a copy of an old flowgraph that you posted on the mailing list
> a long while back (
> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-03/msg00735.html
> ). This is what initially confused me on what to pass in as gmsk
> symbols to corr_est block as it has strictly real values.
>
> I modified it to mux in the preamble that's in the octave code with a
> random source. I also modified the octave code to match the samples
> per symbol of the flowgraph (10) and generated the modulated symbols
> for the corr_est block. The corr_est block does indeed
> perform conjugation and reversal of the symbols, so I used the "h_iq"
> value from the octave code as the modulated symbols since it has not
> been conjugated or reversed. I'm not getting corr_est tags.

On that flowgraph, set your threshold on the corr_est block to 0.23.

BTW, that preamble has horrible correlation properties.


> Thanks,Alex.

-Andy

Re: Symbol timing estimator block and CPM modulations

On Sun, 2020-06-28 at 16:31 -0500, Alex Roberts wrote:
> Andy,
>
> I had a copy of an old flowgraph that you posted on the mailing list
> a long while back (
> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-03/msg00735.html
> ). This is what initially confused me on what to pass in as gmsk
> symbols to corr_est block as it has strictly real values.
>
> I modified it to mux in the preamble that's in the octave code with a
> random source. I also modified the octave code to match the samples
> per symbol of the flowgraph (10) and generated the modulated symbols
> for the corr_est block. The corr_est block does indeed
> perform conjugation and reversal of the symbols, so I used the "h_iq"
> value from the octave code as the modulated symbols since it has not
> been conjugated or reversed. I'm not getting corr_est tags.

On that flowgraph, set your threshold on the corr_est block to 0.23.

BTW, that preamble has horrible correlation properties.


> Thanks,Alex.

-Andy

gr-foo , gr-Bluetooth

I have been working with gr-bluetooth and things have been working out fine. I was wondering if there is a wireshark connector similar to the gr-foo ZigBee/wifi case. I can see a lot of the hex data but since I cannot format it correctly as a pcap file wireshark cannot provide me with any further information except that of a malformed eth

 

Martin Spears

 

Re: Calculating SNR of an incoming signal

Hi Alex,

please keep this discussion on the mailing list. Thus, I included the
mailing list in this reply again.

Let's summarize your system
carrier frequency 5.8GHz
Radar ranging with reflection loss. Do you have any info on your
reflecting object? An objects radar cross-section may heavily influence
your results.
You stated, you'd work on a passive RF ranging system. The setup you
describe is active though. I'm curious how you'll convert this to a
passive system.

What's the signal structure you send? Is it just a sine? Is it random
QPSK symbols? What's your frontend's carrier frequency? Which SDR
frontend do you use? A USRP? A HackRF?

As long as your bandwidth definition together with your SNR definition
is sound, it might work to pre-calibrate your system. You might want to
do this periodically in case you'll run it for a longer time.

EO (Electro-Optical?)

Cheers
Johannes

On 26.06.20 18:01, Alex Batts wrote:
> Hello,
>
> Yes, I understand the Nyquist sampling theorem and my hardware
> limitations. That is why I assumed filtering would not work although I
> gave it a shot anyways. I am not trying to demodulate any baseband
> signal, rather I am going to be receiving a reflected signal at around
> 5.8 GHz and using that signal for range detection. The signal itself
> will not contain any information, but the strength of the signal is the
> information I need. However, I need a method for determining, or at
> least estimating, SNR because that is the key variable that will change
> throughout my experiment in the radar range equation and will ultimately
> be the deciding factor to determine how far away the object is. That was
> why I proposed doing a pre-trial calculation where my source is not
> transmitting to get the average noise power, and then set that as a
> constant block and subtract it in real time from my average total power
> with noise and signal both included. The constant block would then be
> updated prior to each run.
>
> A necessary part of the radar range equation is the transmit power from
> the source as well as the directivity. The SNR I'll be looking for is at
> the receiver. So the equation takes care of any signal attenuation.
>
> I'm building a passive RF range calculation system in conjunction with
> an EO object tracking system.
>
> Thank you,
>
> Alex
>
>
>
> On Fri, Jun 26, 2020 at 11:14 AM Johannes Demel <demel@ant.uni-bremen.de
> <mailto:demel@ant.uni-bremen.de>> wrote:
>
> Hi Alex,
>
> your cut-off frequency needs to be lower than half your sampling rate.
> If your sampling rate is 61.44MHz, your maximum cut-off frequency
> can be
> 30.72MHz. And it should probably be a bit lower. You're working in
> baseband here. It is really important to understand the concepts of
> digital signal processing. That's also the reason I pointed out several
> resources.
>
> SNR calculation itself is not always trivial. You need a way to
> distinguish samples that should only carry noise energy and those that
> should carry signal energy.
> Often people distinguish between SNR estimation for AWGN channels and
> for fading channels. While your estimator will probably not distinguish
> between the two, some estimators just fail for fading channels
> especially.
> For OFDM you might want to look into Schmidl&Cox preamble based SNR
> estimation. There might be an M2M4 estimator for symbol based SNR
> estimation.
> What kind of system are you using?
>
> Cheers
> Johannes
>
>
> On 26.06.20 15:49, Alex Batts wrote:
> > Right, because the filter cutoff frequency needs to be at least
> half the
> > sampling rate, I figured I would not be able to use a filter
> since the
> > bladeRF I will be using has a 61.44 MHz sampling rate and I will be
> > operating in the GHz range.
> >
> > What I will probably end up having to do is do a pre-run calibration
> > where the tone is not playing, use a complex to mag^2 and average
> power
> > combination, set that as a constant block, and then subtract the
> > calibrated constant from the total power when the tone is on to
> get the
> > most accurate possible signal power. While not ideal because it
> is not a
> > truly live SNR calculation, it is the best workaround that avoids
> the
> > filter I can think of.
> >
> > If there are any other suggestions to get a more live/real time SNR
> > calculation I am open to that as well.
> >
> > Thank you for the help,
> >
> > Alex
> >
> >
> >
> > On Fri, Jun 26, 2020 at 4:17 AM Johannes Demel
> <demel@ant.uni-bremen.de <mailto:demel@ant.uni-bremen.de>
> > <mailto:demel@ant.uni-bremen.de
> <mailto:demel@ant.uni-bremen.de>>> wrote:
> >
> >     Hi Alex,
> >
> >     "0 < fa <= sampling_rate/2" is correct and should always be
> >     enforced. If
> >     you try to set your filter cut-off frequency at >=
> samp_rate/2, you'll
> >     experience aliasing.
> >
> >     After reading your mails, I get the impression you try to set
> your
> >     filter cut-off frequency at your carrier frequency $f_c$ +
> bandwidth/2
> >     $B/2$. Or something in that range. That won't work in baseband.
> >     Effectively, your signal at $f_c$ goes through a mixer and is
> shifted
> >     such that it would appear at $0$ in your baseband signal.
> >
> >     There's a lot of digital signal processing fundamentals
> involved. I
> >     like
> >     the explanations given in [0]. Though, of course there are
> well known
> >     books such as the ones by Proakis or Sklar on the topic.
> >
> >     Cheers
> >     Johannes
> >
> >     [0] https://dspillustrations.com/pages/index.html
> >
> >     On 25.06.20 22:22, Alex Batts wrote:
> >      > The effective noise bandwidth is part of the calculation. I'm
> >     using the
> >      > radar range equation.
> >      >
> >      > My purpose for including the bandwidth in my response was that
> >     any time
> >      > I try to use a filter with a frequency greater than my
> sampling
> >     rate/2 I
> >      > get an error returned. I agree that ideally I would use a
> band-pass
> >      > filter with very narrow cutoffs to best capture the signal
> in its
> >      > entirety, however, I can't because the frequency I'm trying to
> >     set my
> >      > filter at is more than half my sampling rate, giving me an
> error.
> >     Maybe
> >      > there is something askew with that error and it's
> something else,
> >     but it
> >      > returns saying 0 < fa <= sampling_rate/2
> >      >
> >      > On Thu, Jun 25, 2020 at 3:27 PM Marcus Müller
> <mueller@kit.edu <mailto:mueller@kit.edu>
> >     <mailto:mueller@kit.edu <mailto:mueller@kit.edu>>
> >      > <mailto:mueller@kit.edu <mailto:mueller@kit.edu>
> <mailto:mueller@kit.edu <mailto:mueller@kit.edu>>>> wrote:
> >      >
> >      >     Hi Alex,
> >      >
> >      >     On 25/06/2020 21.00, Alex Batts wrote:
> >      >      > I'm sampling an incoming signal, but only around 2
> MSps.
> >      >      >
> >      >
> >      >     and that's fine! that's the *equivalent* baseband, it
> has all
> >     the same
> >      >     information as the RF signal.
> >      >
> >      >      > I need the signal power to noise power ratio at the
> >     receiver as
> >      >     part of
> >      >      > my range calculation.
> >      >
> >      >     Yes, but you'd always want to do that "signal to
> noise" only
> >     in the
> >      >     bandwidth that actually contains your tone; the rest will
> >     just contain
> >      >     more noise, interferers... to make your measurement worse.
> >      >
> >      >      > So I would need to be able to distinguish between
> >      >      > the power of the tone vs the power of the surrounding
> >     noise and use
> >      >      > those two numerical values in an equation to
> calculate the
> >     range.
> >      >
> >      >     You need to define "surrounding"! Your signal doesn't get
> >     worse by
> >      >     applying a filter that only selects your tone and as
> little
> >     else as
> >      >     possible. So you should do that – it makes your SNR
> better.
> >     Hence, your
> >      >     Signal power estimate gets more reliable (which you
> >     definitely want).
> >      >
> >      >     (that also highlights why I have a bit of doubt on your
> >     measurement
> >      >     methodology – if your SNR depends on receiver
> bandwidth, then
> >     how much
> >      >     does it actually tell you about the range, unless you
> specify the
> >      >     bandwidth alongside with it?)
> >      >
> >      >     Think about it: we typically assume noise to be white,
> i.e.
> >     to have
> >      >     identical power spectral density all over the
> spectrum, e.g. -170
> >      >     dBm/Hz.
> >      >
> >      >     Now, if your receiver bandwidth is set to 2 MHz (because
> >     that's what
> >      >     your SDR is probably configured to filter out if you
> ask for
> >     2 MS/s),
> >      >     then you get twice as much noise power than if you set the
> >     sampling
> >      >     rate
> >      >     to 1 MS/s.
> >      >
> >      >     It's the same thing that I always let students figure
> out by
> >     themselves
> >      >     the first time they use the lab spectrum analyzer:
> >      >     Feed a 2 GHz -60 dBm tone into the spectrum analyzer.
> >      >     Set the resolution bandwidth of the spectrum analyzer to 1
> >     MHz, and
> >      >     tell
> >      >     me what the SNR is. Now set the resolution bandwidth
> to 300
> >     kHz and
> >      >     tell
> >      >     me again.
> >      >     You get as much "N" in your SNR as you let through your
> >     system. In the
> >      >     case of the spectrum analyzer, every point on the
> display is
> >     the power
> >      >     in 1 MHz (or 300 kHz) of filter. In the case of your
> Qt plot,
> >     it's the
> >      >     power in a FFT bin. There's (f_sample)/(FFT length)
> bandwidth
> >     to each
> >      >     bin; so your graphical analysis hinges on the setting of
> >     sample rate
> >      >     and
> >      >     FFT length (also, on window choice and labeling, and
> software
> >      >     convention). Proportionally!
> >      >
> >      >     It's really hard to define "SNR" for 0-bandwidth, i.e. a
> >     single tone
> >      >     (having a single tone, actually, gets tricky
> physically, but
> >     there's a
> >      >     lot of people who could tell you more about
> oscillators than
> >     I could).
> >      >
> >      >     If you'd be fair, the only choice for the noise filter
> >     bandwidth would
> >      >     be 0 Hz, because if you chose any wider, you always
> get more
> >     noise. But
> >      >     in 0 Hz, there's actually 0 noise power! So, that
> doesn't work.
> >      >
> >      >     Instead, you need to define SNR exactly on the
> bandwidth your
> >     detection
> >      >     system will have to use. That's a design parameter you
> haven't
> >      >     mentioned
> >      >     so far!
> >      >
> >      >      > This
> >      >      > is why I referenced the green and red lines on the
> qt gui
> >     freq.
> >      >     display,
> >      >      > this would seem to give me signal strength in dB.
> >      >
> >      >     Hopefully, above explained how much these lines depend
> on your
> >      >     configuration and aren't "SNR".
> >      >
> >      >     Cheers,
> >      >     Marcus
> >      >
> >
>

Re: Symbol timing estimator block and CPM modulations

Andy, 

I had a copy of an old flowgraph that you posted on the mailing list a long while back (https://lists.gnu.org/archive/html/discuss-gnuradio/2016-03/msg00735.html). This is what initially confused me on what to pass in as gmsk symbols to corr_est block as it has strictly real values.

I modified it to mux in the preamble that's in the octave code with a random source. I also modified the octave code to match the samples per symbol of the flowgraph (10) and generated the modulated symbols for the corr_est block. The corr_est block does indeed perform conjugation and reversal of the symbols, so I used the "h_iq" value from the octave code as the modulated symbols since it has not been conjugated or reversed. I'm not getting corr_est tags. 

Thanks,

Alex.

On Sun, Jun 28, 2020 at 1:04 PM Alex Roberts <arob109@gmail.com> wrote:

Andy,

Yes, I did mean the corr_est block. Thank you for the matlab code. I'll hopefully get to play with it today. The flowgraph I have write now is actually doing quite well with high AWGN just with switching to the enhanced symbol block and using the Mengali and d'Andrea timing recovery. For what it's worth, I'm stuck on GRC 3.7 so I had to check out from your git from before you removed the symbol sync block (assuming it was removed since it's been moved in-tree in 3.8)

Thanks,

Alex.

On Sun, Jun 28, 2020 at 7:32 AM Andy Walls <andy@silverblocksystems.net> wrote:

Hi Alex:

On Sat, 2020-06-27 at 19:42 -0500, Alex Roberts wrote:
> Andy,
>
> I'm not sure how integrate the correlation sync block with gmsk.

The correlate_and_sync block is an old block that was specific to RRC
filtered PSK.  You must mean the corr_est block.

>  It expects modulated symbols and I'm not sure how to generate a
> modulated vector of gmsk symbols.  There doesn't seem to be a gmsk
> class that can be used by the modulate vector block.

You can create a modulated GMSK preamble with the modulate vector block
in GNURadio.  However, I do not recommend it.  It provides little
insight or control over the exact correlation filter taps, so trimming
off start and end transients becomes a hassle.

Instead, generate your correlation filter taps in MatLab or Octave.
Then you can also use Matlab or Octave to assess the performance of
your correlation filter taps against real or simulated data.

See the attached script for an example of generating GMSK correlation
filter taps.  Note that this script generates the conjugated and time
reversed filter taps.  You'll have to check what the corr_est block is
expecting, as it may be performing a conjugation and time reversal for
you, under the assumption that you didn't do it.

Regards,
Andy


> Thanks,
> Alex
>
> On Thursday, June 25, 2020, Andy Walls <andy@silverblocksystems.net>
> wrote:
> > Recommend reading
> > 
> > https://www.gnuradio.org/grcon/grcon17/presentations/symbol_clock_recovery_and_improved_symbol_synchronization_blocks/Andy-Walls-Samples-to-Digital-Symbols.pdf
> >
> > Yeah, the MSK TED selections for the symbol sync block expect the
> > constant envelope FSK waveform on the input.  Demodulation from FSK
> > to baseband pulses should happen after the symbol sync block.
>
>

Re: Symbol timing estimator block and CPM modulations

Andy,

Yes, I did mean the corr_est block. Thank you for the matlab code. I'll hopefully get to play with it today. The flowgraph I have write now is actually doing quite well with high AWGN just with switching to the enhanced symbol block and using the Mengali and d'Andrea timing recovery. For what it's worth, I'm stuck on GRC 3.7 so I had to check out from your git from before you removed the symbol sync block (assuming it was removed since it's been moved in-tree in 3.8)

Thanks,

Alex.

On Sun, Jun 28, 2020 at 7:32 AM Andy Walls <andy@silverblocksystems.net> wrote:

Hi Alex:

On Sat, 2020-06-27 at 19:42 -0500, Alex Roberts wrote:
> Andy,
>
> I'm not sure how integrate the correlation sync block with gmsk.

The correlate_and_sync block is an old block that was specific to RRC
filtered PSK.  You must mean the corr_est block.

>  It expects modulated symbols and I'm not sure how to generate a
> modulated vector of gmsk symbols.  There doesn't seem to be a gmsk
> class that can be used by the modulate vector block.

You can create a modulated GMSK preamble with the modulate vector block
in GNURadio.  However, I do not recommend it.  It provides little
insight or control over the exact correlation filter taps, so trimming
off start and end transients becomes a hassle.

Instead, generate your correlation filter taps in MatLab or Octave.
Then you can also use Matlab or Octave to assess the performance of
your correlation filter taps against real or simulated data.

See the attached script for an example of generating GMSK correlation
filter taps.  Note that this script generates the conjugated and time
reversed filter taps.  You'll have to check what the corr_est block is
expecting, as it may be performing a conjugation and time reversal for
you, under the assumption that you didn't do it.

Regards,
Andy


> Thanks,
> Alex
>
> On Thursday, June 25, 2020, Andy Walls <andy@silverblocksystems.net>
> wrote:
> > Recommend reading
> > 
> > https://www.gnuradio.org/grcon/grcon17/presentations/symbol_clock_recovery_and_improved_symbol_synchronization_blocks/Andy-Walls-Samples-to-Digital-Symbols.pdf
> >
> > Yeah, the MSK TED selections for the symbol sync block expect the
> > constant envelope FSK waveform on the input.  Demodulation from FSK
> > to baseband pulses should happen after the symbol sync block.
>
>

Root Raised Cosine Filter (RRCF) Parameters

Hi everybody,
Pls i need help. I am working on channel propagation measurement using
GNU radio sliding correlator channel sounder. I want to know the
necessary conditions that are needed to be taken when setting RRCF
parameters.
Also, when i checked through some GNU radio sliding correlator
channel sounder flowgraphs on internet i realized that one or two used
interpolation at transmitter and decimation at the receiver. Why
others used both interpolation at Tx and Rx. Pls, i need someone to
education me on this.
Lastly, is clock rate same as chip rate? I have been trying to see how
to set the chip rate but i could only saw clock rate. Thanks
Akinyele

Re: Symbol timing estimator block and CPM modulations

pkg load signal; % Octave needs this

% One of the possible encodings of the AIS preamble symbols
h_bits = [-1,-1, 1, 1, ...
-1,-1, 1, 1, ...
-1,-1, 1, 1, ...
-1,-1, 1, 1, ...
-1,-1, 1, 1, ...
-1,-1, 1, 1, ...
-1,-1,-1,-1,-1,-1,-1, 1].';

% AIS specific GMSK parameters
Rb = 9600;
BT = 0.4;
L = 3;
modulation_index = 1/2;

% Working sample rate
sps = 5;
Fs = Rb * sps;

% Build Gaussian pulse filter
Ls = round(L*sps);
alpha = sqrt(2/log(2)) * pi * BT;
k = [(-Ls/2+1):1:(Ls/2-1)];
taps = (erf(alpha*(k/sps + 0.5)) - erf(alpha*(k/sps - 0.5)))*0.5/sps;
K = length(taps);
if (mod(K,2) == 0)
delay = K/2;
else
delay = (K-1)/2;
end

% Upsample and pulse shape the correlation sequence
x = sps*[upsample(h_bits,sps); zeros(delay, size(h_bits)(2))];
h_ibaseband = filter(taps, [1], x);
% Trim the pulse shaped correlation sequence
h_baseband = h_ibaseband((delay):(end-(sps-1)),:);

% modulate the correlation sequence
fm_gain = pi/(Fs/2) * Rb/2 * modulation_index;
x = h_baseband * fm_gain;
phase = cumsum(x); % phase is integral of frequency
h_iq = exp(1i*mod(phase, 2*pi));

% create the correlation filter
h = conj(h_iq(end:-1:1,:));

figure(1);
t1 = [1:size(h_ibaseband)(1)];
plot(t1, h_ibaseband(:,1), 'x-');
title('Premable Baseband Gaussian Pulses');

figure(2);
t2 = [1:size(h_baseband)(1)];
plot(t2, h_baseband(:,1), 'x-');
title('Trimmed Premable Baseband Gaussian Pulses');

figure(3);
t3 = [1:size(h)(1)];
plot(t3, real(h(:,1)), 'x-', t3, imag(h(:,1)), 'x-');
title('Correlation Filter Taps');
h(:,1)
Hi Alex:

On Sat, 2020-06-27 at 19:42 -0500, Alex Roberts wrote:
> Andy,
>
> I'm not sure how integrate the correlation sync block with gmsk.

The correlate_and_sync block is an old block that was specific to RRC
filtered PSK. You must mean the corr_est block.

> It expects modulated symbols and I'm not sure how to generate a
> modulated vector of gmsk symbols. There doesn't seem to be a gmsk
> class that can be used by the modulate vector block.

You can create a modulated GMSK preamble with the modulate vector block
in GNURadio. However, I do not recommend it. It provides little
insight or control over the exact correlation filter taps, so trimming
off start and end transients becomes a hassle.

Instead, generate your correlation filter taps in MatLab or Octave.
Then you can also use Matlab or Octave to assess the performance of
your correlation filter taps against real or simulated data.

See the attached script for an example of generating GMSK correlation
filter taps. Note that this script generates the conjugated and time
reversed filter taps. You'll have to check what the corr_est block is
expecting, as it may be performing a conjugation and time reversal for
you, under the assumption that you didn't do it.

Regards,
Andy


> Thanks,
> Alex
>
> On Thursday, June 25, 2020, Andy Walls <andy@silverblocksystems.net>
> wrote:
> > Recommend reading
> >
> > https://www.gnuradio.org/grcon/grcon17/presentations/symbol_clock_recovery_and_improved_symbol_synchronization_blocks/Andy-Walls-Samples-to-Digital-Symbols.pdf
> >
> > Yeah, the MSK TED selections for the symbol sync block expect the
> > constant envelope FSK waveform on the input. Demodulation from FSK
> > to baseband pulses should happen after the symbol sync block.
>
>

Re: Symbol timing estimator block and CPM modulations

Hello Alex,

      Few months ago, I was also having some similar issues, with respect to GFSK modulation. I was using a M&M TED and I was getting a loss percentage of about 7% mainly due to having a large amount of tx packets (100 pkts/s) . So, it was suggested to me to use a correlator sync block to pre sync the packets, and then do timing recovery. 

But, since I also couldn't find a M-fsk or MSK modulation class I start doing some research and I found that the timing recovery block works perfectly if there are no noise in the demodulated output, so I created my own version of demodulator which outputs values only of signal is present, and in case of noise I just output some negative value, say like -5. It just a concept if signal power is above a threshold then it is actual tx if not it is a noise

 I am not sure if this can solve your problem. Thought  just in case you may find it useful. Cheers.....!  

Regards,

Mohamed Yaaseen

On Sun, 28 Jun 2020 at 02:43, Alex Roberts <arob109@gmail.com> wrote:

Andy,

I'm not sure how integrate the correlation sync block with gmsk. It expects modulated symbols and I'm not sure how to generate a modulated vector of gmsk symbols.  There doesn't seem to be a gmsk class that can be used by the modulate vector block.

Thanks,

Alex 

On Thursday, June 25, 2020, Andy Walls <andy@silverblocksystems.net> wrote:

Recommend reading
 https://www.gnuradio.org/grcon/grcon17/presentations/symbol_clock_recovery_and_improved_symbol_synchronization_blocks/Andy-Walls-Samples-to-Digital-Symbols.pdf

Yeah, the MSK TED selections for the symbol sync block expect the constant envelope FSK waveform on the input.  Demodulation from FSK to baseband pulses should happen after the symbol sync block.

Re: Symbol timing estimator block and CPM modulations

Andy,

I'm not sure how integrate the correlation sync block with gmsk. It expects modulated symbols and I'm not sure how to generate a modulated vector of gmsk symbols.  There doesn't seem to be a gmsk class that can be used by the modulate vector block.

Thanks,

Alex 

On Thursday, June 25, 2020, Andy Walls <andy@silverblocksystems.net> wrote:

Recommend reading
 https://www.gnuradio.org/grcon/grcon17/presentations/symbol_clock_recovery_and_improved_symbol_synchronization_blocks/Andy-Walls-Samples-to-Digital-Symbols.pdf

Yeah, the MSK TED selections for the symbol sync block expect the constant envelope FSK waveform on the input.  Demodulation from FSK to baseband pulses should happen after the symbol sync block.

Re: Questions on the GNU WiFi GUI with the USRP B210 box

On 06/27/2020 04:55 PM, Silvio Cardero wrote:

Thanks 

That goes with what I thought 

It seems to coincide with the ADC

 From my gain calculation and reading the transceiver specs the ADC should be a 1vp/p device hence 4 dBm FS + 3dB more for I&Q. 

Yet the GNU and Matlab views show the Received word seems to be 10 dBm FS or 1 v p/p

Gnu Radio doesn't give you numbers calibrated against powers or voltages seen at the antenna, only some approximation of dBFS in the
  digital domain.  If you want that calibrated in "real world, as seen at the antenna" units, you'll need to undertake a calibration exercise
  over the multi-dimension parameter space of:

   o Gain setting
   o Frequency
   o Analog bandwidth setting
   o Sample rate
   o Probably master clock rate
   o Whether you're using TX/RX or RX2 port for RX

Since Gnu Radio (and, by inference MatLab) do not *KNOW* anything about the analog behavior of the transceivers it's connected to, you
  cannot come to any conclusions about what the instantaneous samples *mean* in terms of real-world analog voltages other than that
  they're mostly linearly related, and that for a given situation, a larger sample magnitude means a larger output from the DAC (or, respectively
  from the ADC).

Re: GPIO lines on RPi4

I am definitely not knowledgeable about Python so I might be missing
the basics: as I want to include a TCP server for tuning the acquisition
parameters, it seems to me (but I might be wrong) that the Python Module
is more appropriate than the Python Snippet which seems to add a piece
of code to the main() Python flowgraph function.
The TCP server in the Python Module I have written must change the USRP LO
frequency so in my Python Module I
import t
since t is my GRC flowchart name and I create tt=t.t() which allows me to
change e.g. the LO frequency variable f with tt.f=tt.f+10000 or change the
LO frequency itself by calling tt.set_f(tt.f). This is all good in a CLI application
as the one running on the RPi4, and working nicely.
However for educational purposes I wanted to demonstrate the same principle with
a Qt Application and in this case I get the error message
QWidget: Must construct a QApplication before a QWidget
which I assume is due to the definition of the class
class t(gr.top_block, Qt.QWidget):
requiring a Qt.QWidget when I define tt=t.t() which is not yet defined as
Qt.QApplication.setGraphicsSystem(style)
qapp = Qt.QApplication(sys.argv)

Is there a proper way of accessing the variables and the functions of the main GRC
flowchart from my Python Module, also applicable in the case of a Qt Application ?

Thanks, JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

June 22, 2020 1:25 PM, "Marcus Müller" <mueller@kit.edu> wrote:

> It gets even better:
>
> We've launched a feature in 3.8.1.0 (and on master before that, as we do
> with any feature that ends up in a maintenance release) that we hope
> doesn't come back to bite us due to enabling unclean design. But, we
> must build best practices so that it doesn't go unused, either, so:
>
> Assuming you're using GNU Radio 3.8.1.0 (or later, once we release
> something), you can make use of the "Python Snippets" in GRC.
>
> Cheers,
> Marcus
>
> On 18/06/2020 23.17, Marcus D. Leech wrote:
>
>> On 06/18/2020 03:54 PM, jean-michel.friedt@femto-st.fr wrote:
>>> My approach:
>>> * build your grc chart from GNU Radio Companion and generate the .py file
>>> * edit the py file and import pygpio
>>> * play with the RPi4 GPIO in your python script.
>>>
>>> See attached script, with a python server included in the Python script
>>> to control an RF switch from a GNU Octave TCP/IP client talking to the
>>> Python
>>> TCP/IP server.
>>>
>>> I am presenting this approach to hardware control at
>>> http://jmfriedt.free.fr/sdra_radar.pdf
>>>
>>> JM
>>
>> If you use "Python Module" block, you can write a lot of
>> non-GnuRadio-esque python, import anything you want, etc, etc. No editing
>> of the output python required, necessarily.
>>
>>> --
>>> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
>>> 25000 Besancon, France
>>>
>>> June 18, 2020 9:40 PM, "Da Fy" <diver863uk@gmail.com> wrote:
>>
>> Hi All, does anyone have an example of how to control GOIO lines on
>> the RPi4 from within a GRC
>> flowgraph. I'm guessing it's an OOT module.
>>
>> I need to generate a signal of a few 100Hz & control GPIO lines at
>> various points though the cycle.
>>
>> Alternatively, I could generate the signal & lines with external
>> hardware & read them with
>> GnuRadio.
>>
>> Tnx, Dave

Re: Questions on the GNU WiFi GUI with the USRP B210 box

On 06/26/2020 07:06 PM, Silvio Cardero wrote:

On the TX GUI what does tx_ampl adjust and what is a scale of 0-1 mean?

The constellation breaks if I use more than a .3 setting.

That's (I'm guessing, this particular piece of code isn't mine) that it sets the magnitude of samples going into the radio.
  Gnu Radio uses a floating-point representation internally with samples are in the range {-1.0,1.0}, which gets translated
  by device drivers into (very approximately) the max-scaling of whatever D/A (or, A/D in the RX case) is in use by the hardware.
  But keep in mind that it's very approximate, and in an actual transmitter, the output of the D/A is mixed with the LO signal, and
  then amplified.  So combinations of base-band magnitude, and TX RF Gain setting can easily result in non-linear operating
  of analog components--either in the TX direction, the RX direction (you're using a cable) or BOTH.

 

 

On the RX what is LS, LMS, STA, Linear Comb?

 

Silvio Cardero Chief Scientist   520.247.7275 (cell) Web    www.ed2corp.com     Email  Silvio@ed2corp.com 7636 N. Oracle Road Tucson, Az. 85704