How to call an existing class? How to modify it?

2021-10-19 Thread linge93 
Hello everyone！
I am now going to rewrite the "ofdm frame equalizer" module, but I found that 
the "ofdm_frame_equalizer_vcvc_impl.cc.h" source code refers to 
"ofdm_equalizer_base" and other files. I want to know if I create a new "ofdm 
frame equalizer" OOT module, I copy The content of 
ofdm_frame_equalizer_vcvc_impl.cc .h is modified in "my_ofdm_frame_equalizer.cc 
.h". Do I need to copy "ofdm_equalizer_base" and other files to the /lib and 
/include folders of the newly created OOT module, and then change the namespace?


In fact, I only want to change the function of the equalizer function in the 
"ofdm_equalizer_simpledfe.cc" file, but I don't want to change it directly 
under the gnuradio source tree, because many other blocks will also use it, so 
I create a new one for ofdm equalization OOT, based on the original ofdm frame 
equalizer


I tried to copy the various .cc .h files corresponding to the ofdm frame 
equalizer module to the directory corresponding to my newly created OOT module. 
I know I need to modify these files, but I don’t know how to do it（As mentioned 
above, I only want to reproduce the "ofdm frame equalizer" function, but I 
don't want to use this fixed modulation equalizer（Suppose I don’t know what the 
modulation method is）, so I need to modify the equalizer function in the 
"ofdm_equalizer_simpledfe.cc" file）. Can someone Tell me? thanks
Sincerely

Re: Adding uhd-style tags, to soapy driver?

2021-10-19 Thread Marcus Müller 
Hi Josh,

@Josh Bailey:
great work! Thanks for the patch :) Sadly, for some reason, `patch` and `git 
apply` only
see the first hunk (i.e. the changes to block_impl.h and the three static const 
pmts), and
I can't directly put your email through `git am` because HTML + MIME-multipart 
seems to be
hard ... ech, tooling.
Anyways, giving us a byte-exact patch not the point of your email, was it. You 
want to
discuss this feature proposal, right?

So, bit of feedback: Yep, this is a super important feature, and even as someone
affiliated with Ettus, I wish more players in the field of low-cost SDRs had it.

Small problem:

// TODO: use timestamp from radio hardware, and < 1s granularity?

exactly that's where things become hard!
The hardware needs to deliver timestamps. That's surprisingly rare.
Also, you need that kind of metadata to be exposed via an API – in this case, 
through
SoapySDR. Since you basically have neither, I'm afraid that while a highly 
desirable
feature, we're kind of missing the central thing here: GNU Radio can't give you 
timestamps
that hardware and driver API don't deliver. Luckily, you can check
SoapySDR::Device::readStream()'s `flags & SOAPY_SDR_HAS_TIME` and if set, call
`readStreamStatus(..., int64_t& timeNs,...)` to get a timestamp.

Now, you only need your hardware to supply timestamps, and your Soapy driver 
developers to
expose them that way.
@Josh of the first Blum kind: Without looking, I'd presume aside from SoapyUHD, 
at most
BladeRF supports that at this point, right?

Couple other pieces of feedback:

> +std::stringstream str;
> +str << name() << unique_id();
> +pmt::pmt_t _id = pmt::string_to_symbol(str.str());

Never do string creation, especially with stringstream, in a general_work – 
they allocate,
deallocate memory, and that leads to unpredictable delays/computational load 
right where
you can use it the least.

> +std::time_t time_now = std::time(nullptr);
(and then tagging with that)

I'm assuming this is meant more as a placeholder for getting actual SDR time 
from the SDR
device (especially since `time_t` isn't sufficiently fine-grained). It's just 
that I saw
that pattern emerge more than once, so for the future reader:

This is useless to harmful: the time of the host PC is only vaguely related to 
time on the
device: it runs at different speeds, and there's random transport and GNU Radio 
delay. So,
as soon as you tag twice your time stamps will simply be contradicting your 
sample count.
Don't do that; having time tags carrying but PC time is snake oil which, and if 
you
actually use these tags, it will break any assumptions about how time works 
(i.e. it's
possible that an SDR might not sample for a while, which means when you count 
samples from
your last tag, your next tag might be later than expected from
last_tag_time+number_of_samples_since/sampling_rate, but if you see a tag 
that's earlier
than expected, something broke about the universe).

Best regards,
Marcus

On 19.10.21 00:41, Bailey, Josh wrote:
> Hi all,
> 
> The gr-uhd driver, tags samples when center frequency changes and some other 
> events):
> 
> https://github.com/gnuradio/gnuradio/blob/8b23f906844c9784c784934ae06dfdfe10d31a1f/gr-uhd/lib/usrp_source_impl.cc#L619
> 
> 
> I've been able to make a minimal patch to the soapy driver (see following), 
> that does the
> same thing for all other SDRs supported by soapy (the patch is for proof of
> concept/illustrative purposes only - I appreciate that it isn't compatible 
> with the
> contribution guidelines).
> 
> My question - would a suitable patch that provides these tags, be acceptable 
> to the
> maintainers? I can appreciate that it's possible that there are flow graphs 
> that just
> happen to use these same tags perhaps for other purposes - perhaps I could 
> then add a flag
> to make them optional? In any case, the gr-uhd driver appears to always send 
> them, already.
> 
> Thanks,
> 
> diff --git a/gr-soapy/lib/block_impl.h b/gr-soapy/lib/block_impl.h
> index a1e95fdd0..74b2beffe 100644
> --- a/gr-soapy/lib/block_impl.h
> +++ b/gr-soapy/lib/block_impl.h
> @@ -90,6 +90,7 @@ protected:
>  public:
>      bool start() override;
>      bool stop() override;
> +    bool _tag_now;
>  
>      /*** Begin public API implementation ***/
>  
> diff --git a/gr-soapy/lib/source_impl.cc b/gr-soapy/lib/source_impl.cc
> index f76d4437f..93aa06bb2 100644
> --- a/gr-soapy/lib/source_impl.cc
> +++ b/gr-soapy/lib/source_impl.cc
> @@ -47,6 +47,10 @@ source_impl::source_impl(const std::string& device,
>  {
>  }
>  
> +static const pmt::pmt_t TIME_KEY = pmt::string_to_symbol("rx_time");
> +static const pmt::pmt_t FREQ_KEY = pmt::string_to_symbol("rx_freq");
> +static const pmt::pmt_t RATE_KEY = pmt::string_to_symbol("rx_rate");
> +
>  int source_impl::general_work(int noutput_items,
>                                __GR_ATTR

Re: Adding uhd-style tags, to soapy driver?

2021-10-19 Thread Jeff Long 
The timestamp in gr-uhd is useful because a USRP can provide the exact
start/restart time of a sample stream, based on a GPSDO. A system timestamp
at the call to work() is not quite as useful. I'd suggest that a "timestamp
first sample" block would do the same thing, and would be usable for
sources other than gr-soapy, too.

Our workflow uses pull requests on Github. A short diff like this in email
is fine as a question, but submitting a PR works better for us.

On Mon, Oct 18, 2021 at 6:33 PM Bailey, Josh  wrote:

> Hi all,
>
> The gr-uhd driver, tags samples when center frequency changes and some
> other events):
>
>
> https://github.com/gnuradio/gnuradio/blob/8b23f906844c9784c784934ae06dfdfe10d31a1f/gr-uhd/lib/usrp_source_impl.cc#L619
>
> I've been able to make a minimal patch to the soapy driver (see
> following), that does the same thing for all other SDRs supported by soapy
> (the patch is for proof of concept/illustrative purposes only - I
> appreciate that it isn't compatible with the contribution guidelines).
>
> My question - would a suitable patch that provides these tags, be
> acceptable to the maintainers? I can appreciate that it's possible that
> there are flow graphs that just happen to use these same tags perhaps for
> other purposes - perhaps I could then add a flag to make them optional? In
> any case, the gr-uhd driver appears to always send them, already.
>
> Thanks,
>
> diff --git a/gr-soapy/lib/block_impl.h b/gr-soapy/lib/block_impl.h
> index a1e95fdd0..74b2beffe 100644
> --- a/gr-soapy/lib/block_impl.h
> +++ b/gr-soapy/lib/block_impl.h
> @@ -90,6 +90,7 @@ protected:
>  public:
>  bool start() override;
>  bool stop() override;
> +bool _tag_now;
>
>  /*** Begin public API implementation ***/
>
> diff --git a/gr-soapy/lib/source_impl.cc b/gr-soapy/lib/source_impl.cc
> index f76d4437f..93aa06bb2 100644
> --- a/gr-soapy/lib/source_impl.cc
> +++ b/gr-soapy/lib/source_impl.cc
> @@ -47,6 +47,10 @@ source_impl::source_impl(const std::string& device,
>  {
>  }
>
> +static const pmt::pmt_t TIME_KEY = pmt::string_to_symbol("rx_time");
> +static const pmt::pmt_t FREQ_KEY = pmt::string_to_symbol("rx_freq");
> +static const pmt::pmt_t RATE_KEY = pmt::string_to_symbol("rx_rate");
> +
>  int source_impl::general_work(int noutput_items,
>__GR_ATTR_UNUSED gr_vector_int&
> ninput_items,
>__GR_ATTR_UNUSED gr_vector_const_void_star&
> input_items,
> @@ -57,6 +61,11 @@ int source_impl::general_work(int noutput_items,
>  const long timeout_us = 50; // 0.5 sec
>  int nout = 0;
>
> +std::stringstream str;
> +str << name() << unique_id();
> +pmt::pmt_t _id = pmt::string_to_symbol(str.str());
> +std::time_t time_now = std::time(nullptr);
> +
>  for (;;) {
>
>  // No command handlers while reading
> @@ -66,6 +75,25 @@ int source_impl::general_work(int noutput_items,
>  result = d_device->readStream(
>  d_stream, output_items.data(), noutput_items, flags,
> time_ns, timeout_us);
>  }
> +if (_tag_now) {
> +_tag_now = false;
> +// create a timestamp pmt for the first sample
> +// TODO: use timestamp from radio hardware, and < 1s
> granularity?
> +const pmt::pmt_t val =
> +pmt::make_tuple(pmt::from_uint64(time_now),
> +pmt::from_double(0));
> +// create a tag set for each channel
> +for (size_t i = 0; i < 1; i++) { // TODO: get actual number
> of channels.
> +this->add_item_tag(i, nitems_written(0), TIME_KEY, val,
> _id);
> +this->add_item_tag(
> +i, nitems_written(0), RATE_KEY,
> pmt::from_double(this->get_sample_rate(i)), _id);
> +this->add_item_tag(i,
> +   nitems_written(0),
> +   FREQ_KEY,
> +
> pmt::from_double(this->get_frequency(i)),
> +   _id);
> +}
> +}
>
>  if (result >= 0) {
>  nout = result;
>
>
>

[no subject]

2021-10-19 Thread Rachida SAROUI 
Hello everyone,

I'm trying to transmit a lora signal and receive it using two USRP. But it
didn't work. Here is my flowgraph. I hope you can help me. I'm not sure
about the link between USRP source and USRP sink.

Thank you


TX_USRP.pdf
Description: Adobe PDF document

Help- gr-lora OOT Module failed to install!

2021-10-19 Thread Thangaraj Mukara Dhakshinamoorthy 
Hello,


My system config:

OS: Ubuntu 20.04.3 LTS

OS Type: 64-bit

RAM: 3.8 GB

Processor: Intel Core i5-2450M CPU @2.50GHz x4

UHD version: 3.15.0.0

GNU Radio version: 3.8.1.0

SDR Device: Ettus USRP N320

I am trying to install gr-lora OOT module to my existing GNUradio 3.8.1, but I 
am getting the following error (with make command):

WebLink:
https://github.com/rpp0/gr-lora



Installation Instruction:

git clone https://github.com/rpp0/gr-lora.git .

mkdir build

cd build

cmake ../  # Note to Arch Linux users: add "-DCMAKE_INSTALL_PREFIX=/usr"

make && sudo make install (here comes the error!)



Console log:
komro@komro-HP-ProBook-6560b:~/gnuradio/gr-lora/build$ ls
appsCMakeFiles   cmake_uninstall.cmake  CTestTestfile.cmake 
 grc  lib Makefile  python_compile_helper.py
CMakeCache.txt  cmake_install.cmake  compile_commands.json  docs
 include  liquid-dsp  pythonswig
komro@komro-HP-ProBook-6560b:~/gnuradio/gr-lora/build$ make && sudo make install
make[2]: *** No rule to make target '/usr/lib/x86_64-linux-gnu/liborc-0.4.so', 
needed by 'lib/libgnuradio-lora.so.v0.6.2-54-g6111c350'.  Stop.
make[1]: *** [CMakeFiles/Makefile2:248: lib/CMakeFiles/gnuradio-lora.dir/all] 
Error 2
make: *** [Makefile:141: all] Error 2

I have installed all the necessary dependencies, but don't know what am I doing 
wrong here, could anyone help me with this error message please?

Any hints would be much appreciated!

Mit freundlichen Grüßen / Best regards

i.A. Thangaraj
Systemtechnik und Dienste/EDV
Projekt Team- LoRa
komro GmbH

Re: Help- gr-lora OOT Module failed to install!

2021-10-19 Thread Ron Economos 

You need to install liborc.

sudo apt-get install liborc-0.4-dev

Ron

On 10/19/21 6:12 AM, Thangaraj Mukara Dhakshinamoorthy wrote:


Hello,

My system config:

OS: Ubuntu 20.04.3 LTS

OS Type: 64-bit

RAM: 3.8 GB

Processor: Intel Core i5-2450M CPU @2.50GHz x4

UHD version: 3.15.0.0

GNU Radio version: 3.8.1.0

SDR Device: Ettus USRP N320

I am trying to install gr-lora OOT module to my existing GNUradio 
3.8.1, but I am getting the following error (with make command):


_WebLink:_

https://github.com/rpp0/gr-lora 

_Installation Instruction:_

git clone https://github.com/rpp0/gr-lora.git .

mkdir build

cd build

cmake ../  # Note to Arch Linux users: add "-DCMAKE_INSTALL_PREFIX=/usr"

make && sudo make install (here comes the error!)

_Console log:_

komro@komro-HP-ProBook-6560b:~/gnuradio/gr-lora/build$ ls

apps CMakeFiles   cmake_uninstall.cmake CTestTestfile.cmake  
grc  lib Makefile python_compile_helper.py


CMakeCache.txt cmake_install.cmake  compile_commands.json 
docs include  liquid-dsp  python    swig


komro@komro-HP-ProBook-6560b:~/gnuradio/gr-lora/build$ make && sudo 
make install


make[2]: *** No rule to make target 
'/usr/lib/x86_64-linux-gnu/liborc-0.4.so', needed by 
'lib/libgnuradio-lora.so.v0.6.2-54-g6111c350'.  Stop.


make[1]: *** [CMakeFiles/Makefile2:248: 
lib/CMakeFiles/gnuradio-lora.dir/all] Error 2


make: *** [Makefile:141: all] Error 2

I have installed all the necessary dependencies, but don’t know what 
am I doing wrong here, could anyone help me with this error message 
please?


Any hints would be much appreciated!

Mit freundlichen Grüßen / Best regards

i.A. Thangaraj
Systemtechnik und Dienste/EDV
Projekt Team- LoRa
komro GmbH

Problems using multiple C files in OOT Block

2021-10-19 Thread George Edwards 
Hello GNURadio Community,

With complex algorithms, there are times when one needs to add C files to
an OOT module on top of those created by the gr_modtool to make the coding
more modular and cleaner. I made a try with a trivial C++ adder
function file, but
could not get it to work. Below is a description of what I did:

I created an OOT C++ module name tutorial and added the block my_adder_ff with
inputs float a and float b.

gr_modtool creates the files my_adder_ff_imp.cc and my_adder_ff_imp.h

In the module lib directory, I created an additional C++ file named
my_add_function.cc containing the definition for the function my_add(float
a, float b). Inside this file I included the header:
#include "my_adder_ff_imp.h"
And, wrapped the function definition in the namespaces:
namespace gr {
namespace tutorial{
   float my_add(float a, float b){
   float c;
   c = a+b:
return c
   }
}
}

I further did the following:
1. Inside my_adder_ff_imp.h , I declared  float my_add(float a, float b)
 2. I called the adder,  val = my_add(a, b) inside my_adder_ff_imp.cc
 3. In the CMakeLists.txt in the lib directory, I included the source file
my_add_function.cc under my_adder_ff_imp.cc (already included by the
gr_modtool)
When I compiled and run, it failed because it could not see the function
my_add.

Will appreciate any help in leading me towards resolving this issue.

Regards,
George

Re: Help- gr-lora OOT Module failed to install!

2021-10-19 Thread Paul Atreides 
Just so you know, there’s a much more up to date, better documented and more 
thorough implementation of LORA in GNURadio. 
I wouldn’t mess with the one you’re installing now. 

Repo:
https://github.com/tapparelj/gr-lora_sdr
Paper:
https://arxiv.org/pdf/2002.08208.pdf



> On Oct 19, 2021, at 11:24, Thangaraj Mukara Dhakshinamoorthy 
>  wrote:
> 
> Hello,
>  
> First of all Thanks @Ron!
>  
> Following Ron‘s instruction, I was able to install gr-lora module 
> successfully and could also see them among gnuradio blocks, but when I try to 
> execute the flowgraph I am getting the following error:
>  
> Executing: /usr/bin/python3 -u 
> /home/komro/gnuradio/gr-lora/apps/lora_receive_file.py
>  
> Warning: failed to XInitThreads()
> Traceback (most recent call last):
>   File "/home/komro/gnuradio/gr-lora/apps/lora_receive_file.py", line 35, in 
> 
> import lora
> ModuleNotFoundError: No module named 'lora'
>  
> 
>  
> I have tried different solutions suggested in the github issues tab such as:
>  
> komro@komro-HP-ProBook-6560b:~$ sudo apt-get install swig
> [sudo] password for komro:
> Reading package lists... Done
> .
> .
> .
> Setting up swig (4.0.1-5build1) ...
> Processing triggers for man-db (2.9.1-1) ...
> komro@komro-HP-ProBook-6560b:/usr/local/lib/python2.7$ ls
> dist-packages  site-packages
> komro@komro-HP-ProBook-6560b:/usr/local/lib/python2.7$ cd dist-packages/
> komro@komro-HP-ProBook-6560b:/usr/local/lib/python2.7/dist-packages$ ls
> komro@komro-HP-ProBook-6560b:/usr/local/lib/python2.7/dist-packages$ 
> komro@komro-HP-ProBook-6560b:/usr/local/lib/python2.7/dist-packages$ cd ..
> komro@komro-HP-ProBook-6560b:/usr/local/lib/python2.7$ cd site-packages/
> komro@komro-HP-ProBook-6560b:/usr/local/lib/python2.7/site-packages$ ls
> komro@komro-HP-ProBook-6560b:/usr/local/lib/python2.7/site-packages$ 
> komro@komro-HP-ProBook-6560b:/usr/local/lib/python2.7/site-packages$ cd 
> /usr/local/lib/python3
> komro@komro-HP-ProBook-6560b:/usr/local/lib/python3$ ls
> dist-packages
> komro@komro-HP-ProBook-6560b:/usr/local/lib/python3$ cd dist-packages/
> komro@komro-HP-ProBook-6560b:/usr/local/lib/python3/dist-packages$ ls
> lora
> komro@komro-HP-ProBook-6560b:~$ export 
> PYTHONPATH=$PYTHONPATH:/usr/local/lib/python3/dist-packages
> komro@komro-HP-ProBook-6560b:~$ printenv
> .
> .
> PYTHONPATH=:/usr/local/lib/python3/dist-packages
> .
> .
>  
> But nothing fixed the issue yet, could anyone please help?
>  
> Regards,
> Thangaraj
>  
> Von: Discuss-gnuradio  
> Im Auftrag von Ron Economos
> Gesendet: Dienstag, 19. Oktober 2021 15:21
> An: discuss-gnuradio@gnu.org
> Betreff: Re: Help- gr-lora OOT Module failed to install!
>  
> You need to install liborc.
> 
> sudo apt-get install liborc-0.4-dev
> 
> Ron
> 
> On 10/19/21 6:12 AM, Thangaraj Mukara Dhakshinamoorthy wrote:
> Hello,
>  
> My system config:
> OS: Ubuntu 20.04.3 LTS
> OS Type: 64-bit
> RAM: 3.8 GB
> Processor: Intel Core i5-2450M CPU @2.50GHz x4
> UHD version: 3.15.0.0
> GNU Radio version: 3.8.1.0
> SDR Device: Ettus USRP N320
>  
> I am trying to install gr-lora OOT module to my existing GNUradio 3.8.1, but 
> I am getting the following error (with make command):
>  
> WebLink:
> https://github.com/rpp0/gr-lora
>  
> Installation Instruction:
> git clone https://github.com/rpp0/gr-lora.git .
> mkdir build
> cd build
> cmake ../  # Note to Arch Linux users: add "-DCMAKE_INSTALL_PREFIX=/usr"
> make && sudo make install (here comes the error!)
>  
> Console log:
> komro@komro-HP-ProBook-6560b:~/gnuradio/gr-lora/build$ ls
> appsCMakeFiles   cmake_uninstall.cmake  
> CTestTestfile.cmake  grc  lib Makefile  python_compile_helper.py
> CMakeCache.txt  cmake_install.cmake  compile_commands.json  docs  
>include  liquid-dsp  pythonswig
> komro@komro-HP-ProBook-6560b:~/gnuradio/gr-lora/build$ make && sudo make 
> install
> make[2]: *** No rule to make target 
> '/usr/lib/x86_64-linux-gnu/liborc-0.4.so', needed by 
> 'lib/libgnuradio-lora.so.v0.6.2-54-g6111c350'.  Stop.
> make[1]: *** [CMakeFiles/Makefile2:248: lib/CMakeFiles/gnuradio-lora.dir/all] 
> Error 2
> make: *** [Makefile:141: all] Error 2
>  
> I have installed all the necessary dependencies, but don’t know what am I 
> doing wrong here, could anyone help me with this error message please?
>  
> Any hints would be much appreciated!
>  
> Mit freundlichen Grüßen / Best regards
> 
> i.A. Thangaraj
> Systemtechnik und Dienste/EDV
> Projekt Team- LoRa
> komro GmbH
> 
>

Fwd:

2021-10-19 Thread Rachida SAROUI 
-- Forwarded message -
De : Rachida SAROUI 
Date: mar. 19 oct. 2021 à 14:41
Subject:
To: 


Hello everyone,

I'm trying to transmit a lora signal and receive it using two USRP. But it
didn't work. Here is my flowgraph. I hope you can help me. I'm not sure
about the link between USRP source and USRP sink.

Thank you


TX_USRP.pdf
Description: Adobe PDF document

Lora / Using the mailing list (was: Fwd:)

2021-10-19 Thread Marcus Müller 
Dear Rachida,
you don't seem to be very familiar with how mailing lists work:

1. Please use a meaningful subject line. We get a lot of emails – and I can't 
read all of
them at the same time. GMail will most definitely complain when you try to send 
an email
that has no subject line. Writing a good subject line helps expert readers spot 
your
question fast! It helps you a lot

2. Repeating an email that was sent not 6 hours ago to "bump" it up is 
considered
impolite; don't do it, it doesn't help you get answers faster :)

3. "It didn't work" is not really telling us much. *How* did it not work? What 
did you
expect, what happened instead, how did you investigate that? What were your 
results so
far? Can't help you much without that kind of information!

Best regards,
Marcus

On 19.10.21 20:24, Rachida SAROUI wrote:
> 
> 
> -- Forwarded message -
> De : *Rachida SAROUI*  >
> Date: mar. 19 oct. 2021 à 14:41
> Subject:
> To: mailto:discuss-gnuradio@gnu.org>>
> 
> 
> Hello everyone,
> 
> I'm trying to transmit a lora signal and receive it using two USRP. But it 
> didn't work.
> Here is my flowgraph. I hope you can help me. I'm not sure about the link 
> between USRP
> source and USRP sink.
> 
> Thank you

Re: Problems using multiple C files in OOT Block

2021-10-19 Thread Vasil Velichkov 
Hi George,

On 19/10/2021 16.55, George Edwards wrote:
> Below is a description of what I did:
> 

What you did is correct and should be enough.

> When I compiled and run, it failed because it could not see the function
> my_add.

What is the exact error message? How did you run it? Can you provide the full 
source code of this test module (as a git repo or a tarball file on some file 
sharing website).

Regards,
Vasil