from:"Ralf"

Hi Vasil,

thanks for the information. I am using Linux Mint 20.2 Uma and GNU Radio
3.8.3.1. I don't know yet how to install the debug symbols but perhaps
this is not necessary.

As I have found out, the downstream blocks expect tags that I don't send
and that is the reason why my flowgraph fails (see Federicos post
earlier today, he gave me a hint). I have already added one missing tag
and there is no more -11 :-)

Kind regards,

Ralf

Am 10.12.2021 um 17:59 schrieb Vasil Velichkov:

Hi Ralf,

Thread 27 "dvbt_symbol_inn" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffc5ffb700 (LWP 1924)]
0x7fffe61a2e0d in ?? () from /lib/x86_64-linux-gnu/libgnuradio-dtv.so.3.8.3
(gdb) bt
#0 0x7fffe61a2e0d in () at /lib/x86_64-linux-gnu/libgnuradio-dtv.so.3.8.3
#1 0x70f40d13 in gr::block_executor::run_one_iteration() () at
/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.8.3
#2 0x70f95eaa in
gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr,
boost::shared_ptr, int) () at
/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.8.3
#3 0x70f84928 in () at
/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.8.3

It seems you are using Debian/Ubuntu (or some derivative) and you are missing
the debug info symbols for libgnuradio-runtime.so and libgnuradio-dtv.so
libraries. I'm not a Debian/Ubuntu user and I'm not very familiar how to
install the missing symbols. Read the following pages, install the debug
symbols and then repeat the same procedure and you will get some more
meaningful information like .cpp/.h file names and line numbers.

https://wiki.ubuntu.com/Debug%20Symbol%20Packages
https://wiki.ubuntu.com/DebuggingProgramCrash
https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

Also tell us which Linux distribution do you use and which version? How did you
install gnuradio and the exact version?

Regards,
Vasil

On 10/12/2021 14.51, Ralf Gorholt wrote:

Hi Vasil,

thank you for your message. As I have no experience with GNU Radio and
command line debugging, your hints may be really helpful. I have
attached the gdb and valgrind output to this email.

In the gdb output thread 27 that receives the SIGSEGV is the DVB-T
"Symbol Inner Interleaver" that comes with GNU Radio, not one of my blocks.

As far as valgrind is concerned, it tells me for my block OFDM
Synchronization: "Conditional jump or move depends on uninitialised
value(s)". I will see if I can find out which variable is uninitialized
and how I can get rid of this problem.

Kind regards,

Ralf

Am 10.12.2021 um 12:35 schrieb Vasil Velichkov:

Hi Ralf,

On 10/12/2021 11.52, Ralf Gorholt wrote:

Unfortunately, when I deactivate the original flowgraph, it does no
longer work and I get a -11 return code.

The "-11" value means that you got a segmentation fault and the process was
kill with signal 11 (SIGSEGV)

https://docs.python.org/3.8/library/subprocess.html#subprocess.CalledProcessError.returncode
https://www.man7.org/linux/man-pages/man7/signal.7.html

In my opinion the easiest way to debug segfaults is to run the flowgraph under
gdb and valgrind. Open your flowgraph in the gnuradio-companion and then
Generate (F5) but do not Execute (F6). The open a terminal, go where the
flowgraph python (.py) file was generated and execute

gdb -ex run --args /usr/bin/python3 test.py

and then when it stops execute `bt` command in the gdb's shell and provide the
full output. To run it under valgrind execute

valgrind --tool=memcheck /usr/bin/python3 test.py

Adjust the path to your python interpreter and its version if needed.

Regards,
Vasil

Re: Adaptation of Federico La Roccas ISDB-T blocks for DVB-T

Hi Federico,

indeed, the "symbol_index" tag that is normally sent for each OFDM
symbol is missing. This might cause an unexpected situation for the
following deinterleaver block, "Access not within mapped region"
according to valgrind.

I will see how I can generate the symbol index for each symbol. The
"Demod Reference Signals" block uses the dvbt_pilot_gen object to parse
the input data and to generate symbol and frame indices.

As far as I have understood, in your block OFDM Synchronization you have
combined the symbol acquisition and the FFT. Then you connect a TMCC
decoder that eliminates the TMCC and auxiliary carriers, generates tags
and outputs the data carriers. My idea was to do the same for the TPS
signals in DVB-T.

To my surprise, in principle what I have done seems to work. If not, my
TPS decoder would not be able to correctly decode the TPS information
that changes accordingly when I change settings in the transmitter, for
instance the modulation scheme.

I will focus on the tags and see what is missing.

Regards,

Ralf

Am 10.12.2021 um 14:25 schrieb Federico 'Larroca' La Rocca:

Hi,

I'd be more than happy to help. A couple of things that come into my
mind.

The OFDM Synchronization block is a combination of our "old" OFDM
Symbol acquisition (for a while now it's been part of GNU Radio) and
Sync and Channel estimation blocks (which performed equalization and
integer frequency correction) . The most important difference is that
OFDM Synchronization includes a loop with the estimated channel gains,
which in turn is used to estimate the sampling error (plus fine
frequency errors). It also indicates some events downstream via tags,
just like the older blocks. This new "DVB-T OFDM Synchronization"
block should then be a combination, if I'm not mistaken, of OFDM
Symbol Acquisition plus Demod Reference Signals (I'm sure Ron will
know more on this).

Anyhow, my point is that you should take a look at the OFDM Symbol
Acquisition and Demod Reference Signals blocks in GNU Radio, and check
which tags are used and when. Maybe this lack of tags is generating an
unforeseen situation on the downstream blocks which generate the
segfault? Furthermore, if I'm not mistaken, the pilots in DVB-T (in
particular continuous pilots) are not exactly the same as in ISDB-T.
Another possibility is that the Demod Reference Signals block is not
equivalent to our Sync and Channel estimation block, and further
processing is needed for it to be ready for the DVB-T Demap...

best
Federico

El vie, 10 dic 2021 a las 9:55, Ralf Gorholt ()
escribió:

Hi Vasil,

thank you for your message. As I have no experience with GNU Radio and
command line debugging, your hints may be really helpful. I have
attached the gdb and valgrind output to this email.

In the gdb output thread 27 that receives the SIGSEGV is the DVB-T
"Symbol Inner Interleaver" that comes with GNU Radio, not one of
my blocks.

As far as valgrind is concerned, it tells me for my block OFDM
Synchronization: "Conditional jump or move depends on uninitialised
value(s)". I will see if I can find out which variable is
uninitialized
    and how I can get rid of this problem.

Kind regards,

    Ralf

Am 10.12.2021 um 12:35 schrieb Vasil Velichkov:
> Hi Ralf,
>
> On 10/12/2021 11.52, Ralf Gorholt wrote:
>> Unfortunately, when I deactivate the original flowgraph, it does no
>> longer work and I get a -11 return code.
> The "-11" value means that you got a segmentation fault and the
process was kill with signal 11 (SIGSEGV)
>
>

https://docs.python.org/3.8/library/subprocess.html#subprocess.CalledProcessError.returncode
> https://www.man7.org/linux/man-pages/man7/signal.7.html
>
> In my opinion the easiest way to debug segfaults is to run the
flowgraph under gdb and valgrind. Open your flowgraph in the
gnuradio-companion and then Generate (F5) but do not Execute (F6).
The open a terminal, go where the flowgraph python (.py) file was
generated and execute
>
>   gdb -ex run --args /usr/bin/python3 test.py
>
> and then when it stops execute `bt` command in the gdb's shell
and provide the full output. To run it under valgrind execute
>
>   valgrind --tool=memcheck /usr/bin/python3 test.py
>
> Adjust the path to your python interpreter and its version if
needed.
>
> Regards,
> Vasil

Adaptation of Federico La Roccas ISDB-T blocks for DVB-T


Dear all,

I forgot to mention in me previous mail that the test flowgraph is not
generated by GRC when it terminates with a -11 return code. I have just
noticed that the test.py file is missing.

My GNU Radio version is 3.8.3.1.

Ralf

Adaptation of Federico La Roccas ISDB-T blocks for DVB-T


Dear all,

in order to benefit from Federicos ISDB-T block "OFDM Synchronization"
that performs a frequency and symbol rate correction I am currently
trying to adapt his blocks "OFDM Synchronization" and "TMCC Decoder" in
a way that makes them usable for DVB-T. To check if they work correctly
I have added some "debug printf()'s" and let them run in parallel to the
blocks in a flowgraph that works.

I am surprised that both of my blocks seem to work. My "TPS Decoder"
decodes the TPS carriers correctly and prints out the correct
information. The constellation diagram at the output of the OFDM
Synchronization seems to be correct as it shows the expected image plus
pilot and/or TPS carriers and at the output of the TPS decoder only the
constellation of the data carriers is visible. So far, so good.

Unfortunately, when I deactivate the original flowgraph, it does no
longer work and I get a -11 return code. Do you have any idea how I can
find out what happens here? I have attached my source code and a test
flow graph to this email. For information, when I bypass the Symbol
Inner Interleaver and connect the null sink directly to the output of
the TPS decoder the flowgraph does not crash (no -11).

I would be happy if someone (especially Federico :-) ) could take a look
at it. Perhaps he or she sees at a glance what I do not see.

Please do not forget that I am no experienced GNU radio user :-)

Thank you very much for your help!

Kind regards,

Ralf
<>

Re: Out Of Tree module works only partially

2021-12-02 Thread Ralf Gorholt


Hi Federico and Jeff,

thank you very much for your prompt answer. As I thought, it was a
"newbie" mistake :-) I have modified my block according to what Federico
has written and now it works.

Regards,

Ralf

Am 02.12.2021 um 12:31 schrieb Jeff Long:

[I just saw the response from Federico as I was writing this, so it's
partly a duplicate]

In work(), items are in terms of vectors, so you need to store
off blk_size in the constructor. In work(), you would copy blk_size *
noutput_items. For an example, take a look at the source for any of
the built-in blocks that can take a vector, e.g.,

https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/include/gnuradio/blocks/abs_blk.h
https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/abs_blk_impl.h
https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/abs_blk_impl.cc

On Thu, Dec 2, 2021 at 5:26 AM Ralf Gorholt  wrote:

Dear all,

I am quite new to GNU Radio and in order to see how GNU Radio blocks
work I would like to create my own block that (for the moment) just
copies complex data from the input to the output. This works as
long as
I copy only one number but not when I want to copy packets of numbers
that come from the preceeding block. My block takes one parameter:
blk_size. I would like to insert it in my DVB-T receiver flowgraph to
analyze data (in a later step).

I had a look at the square_ff example and other blocks to see how
they
are built but I still don't see what I am doing wrong. It must be a
silly mistake. Perhaps you can help me? Here is the code:

myblock_impl::myblock_impl(int blk_size)
 : gr::block("myblock",
 gr::io_signature::make(1, 1, blk_size *
sizeof(gr_complex)),
 gr::io_signature::make(1, 1, blk_size *
sizeof(gr_complex)))
 {
 }

void
 myblock_impl::forecast(int noutput_items, gr_vector_int
_items_required)
 {
 ninput_items_required[0] = noutput_items;
 }

int
 myblock_impl::general_work(int noutput_items,
    gr_vector_int _items,
    gr_vector_const_void_star
_items,
    gr_vector_void_star _items)
 {
 const gr_complex *in = (const gr_complex *) input_items[0];
 gr_complex *out = (gr_complex *) output_items[0];

 for (int i = 0; i < noutput_items; i++) {
 out[i] = in[i];
 }

 consume_each(noutput_items);

 return noutput_items;
 }

And the YML file:

id: dl5eu_myblock
label: myblock
category: '[dl5eu]'

templates:
   imports: import dl5eu
   make: dl5eu.myblock(${blk_size})

parameters:
- id: blk_size
   label: Block size
   dtype: int
   default: '1'

inputs:
- label: in
   domain: stream
   dtype: complex
   vlen: ${blk_size}
   optional: '0'

outputs:
- label: out
   domain: stream
   dtype: complex
   vlen: ${blk_size}
   optional: '0'

file_format: 1

Thank you very much for your help!

Kind regards,

Ralf

Out Of Tree module works only partially

2021-12-02 Thread Ralf Gorholt


Dear all,

I am quite new to GNU Radio and in order to see how GNU Radio blocks 
work I would like to create my own block that (for the moment) just 
copies complex data from the input to the output. This works as long as 
I copy only one number but not when I want to copy packets of numbers 
that come from the preceeding block. My block takes one parameter: 
blk_size. I would like to insert it in my DVB-T receiver flowgraph to 
analyze data (in a later step).


I had a look at the square_ff example and other blocks to see how they 
are built but I still don't see what I am doing wrong. It must be a 
silly mistake. Perhaps you can help me? Here is the code:


myblock_impl::myblock_impl(int blk_size)
    : gr::block("myblock",
    gr::io_signature::make(1, 1, blk_size * 
sizeof(gr_complex)),
    gr::io_signature::make(1, 1, blk_size * 
sizeof(gr_complex)))

    {
    }

void
    myblock_impl::forecast(int noutput_items, gr_vector_int 
_items_required)

    {
    ninput_items_required[0] = noutput_items;
    }

int
    myblock_impl::general_work(int noutput_items,
   gr_vector_int _items,
   gr_vector_const_void_star _items,
   gr_vector_void_star _items)
    {
    const gr_complex *in = (const gr_complex *) input_items[0];
    gr_complex *out = (gr_complex *) output_items[0];

    for (int i = 0; i < noutput_items; i++) {
    out[i] = in[i];
    }

    consume_each(noutput_items);

    return noutput_items;
    }

And the YML file:

id: dl5eu_myblock
label: myblock
category: '[dl5eu]'

templates:
  imports: import dl5eu
  make: dl5eu.myblock(${blk_size})

parameters:
- id: blk_size
  label: Block size
  dtype: int
  default: '1'

inputs:
- label: in
  domain: stream
  dtype: complex
  vlen: ${blk_size}
  optional: '0'

outputs:
- label: out
  domain: stream
  dtype: complex
  vlen: ${blk_size}
  optional: '0'

file_format: 1

Thank you very much for your help!

Kind regards,

Ralf

Re: Block not found in module although it is there

2021-05-05 Thread Ralf Gorholt


Hello Vasil,

thank you very much, this seems to solve the problem and I now know
where to look the next time :-)

Kind regards,

Ralf

Am 05.05.2021 um 17:08 schrieb Vasil Velichkov:

Hi Ralf,

On 05/05/2021 17.38, Ralf Gorholt wrote:

AttributeError: module 'dl5eu' has no attribute 'dvbt_ofdm_synchronization'
Can anybody give me a hint what is happening here?

You most probably need to link the gnuradio's fft component to your OOT block. In your 
CMakeLists.txt find the line that contains `find_package(gnuradio  "3.8" ...` 
and add fft to the list of components. It should looks like this

   find_package(Gnuradio "3.8" REQUIRED COMPONENTS blocks filter fft)

and then in lib/CMakeLists.txt you need to link the gnuradio-fft. Something 
similar to

   target_link_libraries(dl5eu gnuradio::gnuradio-runtime 
gnuradio::gnuradio-fft)

Also open python/__init__.py and

except ImportError:

to

except ModuleNotFoundError:

You can find some more info in 
https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide#GNU_Radio_Components

Regards,
Vasil

Block not found in module although it is there

2021-05-05 Thread Ralf Gorholt


Dear all,

my problem concerns GNU Radio version 3.8 from the maintenance branch
but it is probably not limited to this version.

I would like to try to adapt the block "ofdm_synchronization" that
Federico Larrocca and others have developed for ISDB-T so that it can be
used for DVB-T. For this purpose I have created the module "gr-dl5eu"
that contains a block called "dvbt_ofdm_synchronization".

As long as the block only passes data from the input to the output
everything is ok. But when I start to add code to the constructor, the
block dvbt_ofdm_synchronization is no longer found in gr-dl5eu when I
run the flow graph.

My constructor looks like this:

dvbt_ofdm_synchronization_impl::dvbt_ofdm_synchronization_impl(int mode,
int cp_length, bool interpolate
    : gr::block("dvbt_ofdm_synchronization",
        gr::io_signature::make(1, 1, sizeof(gr_complex)),
        gr::io_signature::make(1, 1, sizeof(gr_complex)))
{
}

Everything is fine, the block copies data from input to output.

But when I add the variable "d_fft_calculator" to the private section of
the object and the following line just before the opening brace of the
constructor: "    , d_fft_calculator(gr::fft::fft_complex(pow(2.0,
10+mode), true, 1))", I get an error message when I run the flow graph:
"AttributeError: module 'dl5eu' has no attribute
'dvbt_ofdm_synchronization'"

The complete messages are below.

<<< Welcome to GNU Radio Companion v3.8.2.0-113-g729d5a98 >>>
Block paths:
/usr/share/gnuradio/grc/blocks
Loading: "/home/ralfg/gnuradio/dvbt_rx_udp.grc"
>>> Done
Generating: '/home/ralfg/gnuradio/dvbt_rx_udp.py'
Executing: /usr/bin/python3 -u /home/ralfg/gnuradio/dvbt_rx_udp.py

qt5ct: using qt5ct plugin
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio v3.8.2.0-113-g729d5a98
built-in source types: file rtl rtl_tcp rfspace redpitaya
Using device #0 Realtek RTL2838UHIDIR SN: 0001
Found Rafael Micro R820T tuner
Setting rtl clock to 2880 Hz.
Setting tuner clock to 2880 Hz.
[R82XX] PLL not locked!
Exact sample rate is: 1142857,021756 Hz
[R82XX] PLL not locked!
Traceback (most recent call last):
File "/home/ralfg/gnuradio/dvbt_rx_udp.py", line 404, in 
main()
File "/home/ralfg/gnuradio/dvbt_rx_udp.py", line 380, in main
tb = top_block_cls()
File "/home/ralfg/gnuradio/dvbt_rx_udp.py", line 272, in __init__
self.dl5eu_dvbt_ofdm_synchronization_0 =
dl5eu.dvbt_ofdm_synchronization(1, 0.125, True)
AttributeError: module 'dl5eu' has no attribute 'dvbt_ofdm_synchronization'
>>> Done (return code 1)

In the original code the initialization of "d_fft_calculator" the
initializatiion is done this way. I have the same problem when I change
d_fft_calculator to a pointer type and initialize it with "new" inside
of the constructor.

Can anybody give me a hint what is happening here? Is there something
missing in the .yml file? I have got the impression that C++ and GNU
Radio are indeed not made for beginners :-(

Thank you very much for your help!

Kind regards,

Ralf

Re: GNU Radio 3.9 gr_modtool problem

2021-05-05 Thread Ralf Gorholt


I have installed GNU Radio from the master branch, so I have got version
3.10 now. The install prefix is /usr.

I don't have a ~/.gnuradio/config.conf file, only ~/.gnuradio/grc.conf
exists after I have started gnuradio-companion.

The directory /etc/gnuradio/conf.d exists. The files in there are
-rw-r--r-- 1 root root  209 Mai  5 14:09 00-grc-docs.conf
-rw-r--r-- 1 root root 1074 Mai  5 14:09 gnuradio-runtime.conf
-rw-r--r-- 1 root root  351 Mai  5 14:07 gr-audio-alsa.conf
-rw-r--r-- 1 root root  414 Mai  5 14:07 gr-audio.conf
-rw-r--r-- 1 root root  270 Mai  5 14:07 gr-audio-oss.conf
-rw-r--r-- 1 root root  732 Mai  5 14:09 grc.conf
-rw-r--r-- 1 root root  736 Mai  5 14:07 gr_log_default.conf
-rw-r--r-- 1 root root  496 Mai  5 14:07 gr-qtgui.conf
-rw-r--r-- 1 root root  228 Mai  5 14:09 modtool.conf

modtool.conf contains:

# You may override any setting on a per-user basis by editing
# ~/.gnuradio/config.conf
[modtool]
newmod_path = /usr/share/gnuradio/modtool/templates/gr-newmod

The directory /usr/share/gnuradio/modtool/templates/gr-newmod exists and
the content is

drwxr-xr-x  2 root root 4096 Mai  5 15:22 apps
drwxr-xr-x  3 root root 4096 Mai  5 15:22 cmake
-rw-r--r--  1 root root 6567 Mai  5 14:07 CMakeLists.txt
drwxr-xr-x  3 root root 4096 Mai  5 15:22 docs
drwxr-xr-x  2 root root 4096 Mai  5 15:22 examples
-rw-r--r--  1 root root   41 Mai  5 14:07 .gitignore
drwxr-xr-x  2 root root 4096 Mai  5 15:22 grc
drwxr-xr-x  3 root root 4096 Mai  5 15:22 include
drwxr-xr-x  2 root root 4096 Mai  5 15:22 lib
-rw-r--r--  1 root root  717 Mai  5 14:07 MANIFEST.md
drwxr-xr-x  3 root root 4096 Mai  5 15:22 python

Then I have created a file config.conf in ~/.gnuradio that contains

[modtool]
newmod_path = /usr/share/gnuradio/modtool/templates/gr-newmod

The error remains.

I can call gr_modtool without parameters. In this case a help text is
shown. Only when I want to add a new module the error message is shown.

Ralf

Am 05.05.2021 um 12:31 schrieb Josh Morman:

Check your ~/.gnuradio/config.conf file.  In there is a section
[modtool] and a "newmod_path=..."
Verify that matches the value of your installed path.
On mine it says:
[modtool]
newmod_path =
/share/gnuradio/gr39/share/gnuradio/modtool/templates/gr-newmod
For 3.9, there was a slight change in the behavior how GR finds the
newmod path:
https://github.com/gnuradio/gnuradio/pull/3266
<https://github.com/gnuradio/gnuradio/pull/3266>
in that it will look wherever the currently installed prefix is, which
can be seen with
gnuradio-config-info --prefix
Make sure your environment variables are sourced correctly - PATH,
PYTHONPATH, LD_LIBRARY_PATH, and LIBRARY_PATH


On Tue, May 4, 2021 at 5:50 PM Ralf Gorholt mailto:ralf.gorh...@gmx.de>> wrote:

Dear all,

on my Linux Mint (Ubuntu) box, I have installed and compiled GNU Radio
3.9 from source (master branch) as described here:

https://wiki.gnuradio.org/index.php/UbuntuInstall#Focal_Fossa_.2820.04.29
<https://wiki.gnuradio.org/index.php/UbuntuInstall#Focal_Fossa_.2820.04.29>

and here:

https://wiki.gnuradio.org/index.php/InstallingGR#From_Source
<https://wiki.gnuradio.org/index.php/InstallingGR#From_Source>

CMAKE_INSTALL_PREFIX is /usr.

GNU Radio compiles (without UHD and soapy support) and the tests
are ok.
gnuradio-companion starts and everything seems ok. However, when I try
to create a new module with "gr_modtool newmod dl5eu", I get the error
message: ModToolException: Could not find gr-newmod source dir.

I have also tried what was necessary for Ubuntu 18:

$ cd /usr/share/gnuradio/modtool/templates/gr-newmod
$ sudo py3clean .

but this did not solve the problem.

With version 3.8 compiled from the maint-3.8 branch I don't have this
problem. Do you have an idea what I am doing wrong here?

Thank you very much.

Kind regards,

Ralf

GNU Radio 3.9 gr_modtool problem

2021-05-04 Thread Ralf Gorholt


Dear all,

on my Linux Mint (Ubuntu) box, I have installed and compiled GNU Radio
3.9 from source (master branch) as described here:

https://wiki.gnuradio.org/index.php/UbuntuInstall#Focal_Fossa_.2820.04.29

and here:

https://wiki.gnuradio.org/index.php/InstallingGR#From_Source

CMAKE_INSTALL_PREFIX is /usr.

GNU Radio compiles (without UHD and soapy support) and the tests are ok.
gnuradio-companion starts and everything seems ok. However, when I try
to create a new module with "gr_modtool newmod dl5eu", I get the error
message: ModToolException: Could not find gr-newmod source dir.

I have also tried what was necessary for Ubuntu 18:

$ cd /usr/share/gnuradio/modtool/templates/gr-newmod
$ sudo py3clean .

but this did not solve the problem.

With version 3.8 compiled from the maint-3.8 branch I don't have this
problem. Do you have an idea what I am doing wrong here?

Thank you very much.

Kind regards,

Ralf

GNU Radio (Companion) bug

2021-05-03 Thread Ralf Gorholt


Dear all,

I have spent several hours before my PC trying to get my new OOT block
running, but in vain. Now I have got the impression that one of my
problems is due to a bug in GNU Radio (Companion). I have attached a
working graph (using Qt GUI) to this email. I am not used to report bugs
but in the wiki I have read that I should send an email to this list.

The problem is, that in certain cases when I change the value of a
parameter in a combo box, GRC displays a message telling me that ports
are disconnected although they are not.

This behaviour can easily reproduced. In GRC, load the attached flow
graph and open the properties window of a block that has a combo box.
Then, change a parameter and click the "Apply" button. The value in the
block changes. Then change the value back. As soon as you select the
item in the combo box, a message is displayed telling you that the ports
are not connected and no more changes are accepted, even when you click
on "Apply".

I have verified this with GNU Radio version 3.8.2.0 on Linux (Python
3.8.5) and 3.8.0.0 on Windows (Python 2.7.10). GNU Radio 3.9 (checked on
Windows) does not show this behaviour but if I remember correctly, not
everything has been ported to version 3.9 yet and for this reason I
would like to keep version 3.8. Would it be possible to fix this bug
also in version 3.8?

Thank you very much for your help.

Kind regards,

Ralf
options:
  parameters:
author: Laurent F4FDW
category: '[GRC Hier Blocks]'
cmake_opt: ''
comment: ''
copyright: ''
description: Flow Graph de reception DVB-T 1 MHz de BW sur 70cm avec un 
stick
  RTL-SDR
gen_cmake: 'On'
gen_linking: dynamic
generate_options: qt_gui
hier_block_src_path: '.:'
id: dvbt_rx_udp
max_nouts: '0'
output_language: python
placement: (0,0)
qt_qss_theme: ''
realtime_scheduling: ''
run: 'True'
run_command: '{python} -u {filename}'
run_options: prompt
sizing_mode: fixed
thread_safe_setters: ''
title: RX DVB-T en low BW sur 70cm
window_size: ''
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [16, 16.0]
rotation: 0
state: enabled

blocks:
- name: center_freq
  id: variable
  parameters:
comment: ''
value: ui_center_freq
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [328, 564.0]
rotation: 0
state: enabled
- name: freq_corr_ppm
  id: variable
  parameters:
comment: ''
value: ui_freq_corr_ppm
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [208, 564.0]
rotation: 0
state: enabled
- name: if_gain_db
  id: variable
  parameters:
comment: ''
value: ui_if_gain_db
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [528, 564.0]
rotation: 0
state: enabled
- name: rf_gain_db
  id: variable
  parameters:
comment: ''
value: ui_rf_gain_db
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [432, 564.0]
rotation: 0
state: enabled
- name: samp_rate
  id: variable
  parameters:
comment: ''
value: (25 * 8) / 7
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [856, 564.0]
rotation: 0
state: disabled
- name: samp_rate_chooser_0
  id: variable_qtgui_chooser
  parameters:
comment: ''
gui_hint: 4,0,1,1
label: Bandwidth
label0: 200khz
label1: 250khz
label2: 1Mhz
label3: 2MHz
label4: ''
labels: '[]'
num_opts: '4'
option0: '228571'
option1: '285714'
option2: '1142857'
option3: '2285714'
option4: ''
options: '[0, 1, 2]'
orient: Qt.QHBoxLayout
type: real
value: '1142857'
widget: radio_buttons
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [16, 408.0]
rotation: 0
state: true
- name: ui_center_freq
  id: variable_qtgui_range
  parameters:
comment: ''
gui_hint: 2, 0,1,1
label: center freq.
min_len: '0'
orient: Qt.Horizontal
rangeType: int
start: '43000'
step: '1000'
stop: '44000'
value: '43400'
widget: counter
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [352, 20.0]
rotation: 0
state: enabled
- name: ui_freq_corr_ppm
  id: variable_qtgui_range
  parameters:
comment: ''
gui_hint: 2, 1,1,1
label: Freq. ppm
min_len: '0'
orient: Qt.Horizontal
rangeType: int
start: '-100'
step: '1'
stop: '100'
value: '11'
widget: counter
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [216, 20.0]
rotation: 0
state: enabled
- name: ui_if_gain_db
  id: variable_qtgui_range
  parameters:
comment: ''
gui_hint: 1, 1,1,1
label: IF gain
min_len: '0'
o

GNU Radio blocks, GRC and .yml files

2021-05-03 Thread Ralf Gorholt


Dear all,

I am still a GNU Radio beginner and at the moment I try to figure out
how to develop an OOT block for GNU Radio. The tutorial explains how to
do this and I have managed to create my first block. However, when it
comes to the .yml file, I don't find all the information that I need. Is
there a document that explains _in detail_ the block descriptions?

I have already looked at https://wiki.gnuradio.org/index.php/YAML_GRC
but this page does not answer my question. I am looking for a
possibility to create an enumeration of float values. Is this possible
or are only integer values allowed (as in C/C++)?

For example, in my block I need an option called "Guard interval" that
has four possible values: 0.25, 0.125, 0.0625 and 0.03125. The
corresponding labels would be 1/4, 1/8, 1/16 and 1/32. How can I do this?

Thank you very much for your help!

Kind regards,

Ralf

Re: R: Re: Gnuradio / Ubuntu 20.10

2021-04-11 Thread Ralf Gorholt


Hi Marcus,

to be precise: I use Linux Mint 20.1 which is based on Ubuntu.

Effectively, the gr-osmosdr module version 0.2.0-2 works with the
version of GNU Radio that is available by default in this Linux Mint
version (3.8.1-rc1-2build2) but as far as I remember, it did not work
with GNU Radio 3.8.2, the GNU Radio version that I have installed.
That's the reason why I have compiled it from source.

Kind regards,

Ralf

Am 11.04.2021 um 17:31 schrieb Marcus Müller:

Hi Ralf,

glad to hear you've got it to work!

When not using the PPA (which I was assuming you'd be doing), you'd get the 
exact
gr-osmosdr that works with Ubuntu's version of GNU Radio (i.e. 3.8.1.0 as I 
thought you've
installed?).

Best regards,
Marcus

On 11.04.21 16:40, Ralf Gorholt wrote:

Hello Marcus,

I had done this before (installed from PPA) but I didn't get a module
that worked with GNU Radio 3.8.2. That's why I have compiled it from
source. When the module is compiled, you have to pay attention to the
correct prefix for cmake.

Ralf

Am 11.04.2021 um 14:37 schrieb Marcus Müller:

You have to do none of this,

sudo apt install gr-osmosdr

does everything. And then you're done and can use the OSMOSDR Source or the 
RTL-Source
(which are essentially the same).

Cheers,
Marcus

On 11.04.21 13:26, Ralf Gorholt wrote:

Hello Alberto,

you may try this:

git clone git://github.com/osmocom/gr-osmosdr -b gr3.8

That's how I got the sources for GNU Radio 3.8 one or two weeks ago.

Regards,

Ralf

Am 11.04.2021 um 12:35 schrieb alberto.alle...@alice.it:

I follow now this guide:
https://lists.gnu.org/archive/html/discuss-gnuradio/2020-09/pdfNp27msymbN.pdf

But at point 7 i have a problem.

alberto@alberto-Studio-XPS-1340:~/sdr_stuff$ git clone 
https://git.osmocom.org/gr-osmosdr
Clone in 'gr-osmosdr' in corso...
error: Failed to connect to git.osmocom.org port 443: Connessione scaduta 
(curl_result =
7, http_code = 0, sha1 = 3d94e1a5d172fc93da9e9638536ee773f4b5a85a)
error: Unable to find 99f14f4991f4154d743fd08b9c49e4eaf8a70001 under
https://git.osmocom.org/gr-osmosdr
Cannot obtain needed blob 99f14f4991f4154d743fd08b9c49e4eaf8a70001
while processing commit 2d504bde50a0c560a9d31b7b38982bd44cc7fe9d.
error: recupero non riuscito.
alberto@alberto-Studio-XPS-1340:~/sdr_stuff$

  Messaggio originale
  Da: fab...@opencode.eu
  Data: 10-apr-2021 22.08
  A: 
  Ogg: Re: Gnuradio / Ubuntu 20.10

  Hi Alberto,
  Just open a terminal and run
  sudo apt install gnuradio
  And you should be fine. The dependencies for the rtl-sdr are already 
included.
  It is probably not the latest version of gnuradio, but IT should 
get you
  started.

  Fabian

  Am 10. April 2021 21:38:47 MESZ schrieb Alberto Alletto 
:

  Hi!
  I’m new on ubuntu world.
  Today i have installed ubuntu 20.10 and i want install Gnuradio to 
work with
RTL-SDR receiver.

  what is the correct procedure to install gnuradio to work with the 
rtl-sdr
receiver?

  Tnx
  Alberto

  Inviato da iPhone

Re: R: Re: Gnuradio / Ubuntu 20.10

2021-04-11 Thread Ralf Gorholt


Hello Marcus,

I had done this before (installed from PPA) but I didn't get a module
that worked with GNU Radio 3.8.2. That's why I have compiled it from
source. When the module is compiled, you have to pay attention to the
correct prefix for cmake.

Ralf

Am 11.04.2021 um 14:37 schrieb Marcus Müller:

You have to do none of this,

sudo apt install gr-osmosdr

does everything. And then you're done and can use the OSMOSDR Source or the 
RTL-Source
(which are essentially the same).

Cheers,
Marcus

On 11.04.21 13:26, Ralf Gorholt wrote:

Hello Alberto,

you may try this:

git clone git://github.com/osmocom/gr-osmosdr -b gr3.8

That's how I got the sources for GNU Radio 3.8 one or two weeks ago.

Regards,

Ralf

Am 11.04.2021 um 12:35 schrieb alberto.alle...@alice.it:

I follow now this guide:
https://lists.gnu.org/archive/html/discuss-gnuradio/2020-09/pdfNp27msymbN.pdf

But at point 7 i have a problem.

alberto@alberto-Studio-XPS-1340:~/sdr_stuff$ git clone 
https://git.osmocom.org/gr-osmosdr
Clone in 'gr-osmosdr' in corso...
error: Failed to connect to git.osmocom.org port 443: Connessione scaduta 
(curl_result =
7, http_code = 0, sha1 = 3d94e1a5d172fc93da9e9638536ee773f4b5a85a)
error: Unable to find 99f14f4991f4154d743fd08b9c49e4eaf8a70001 under
https://git.osmocom.org/gr-osmosdr
Cannot obtain needed blob 99f14f4991f4154d743fd08b9c49e4eaf8a70001
while processing commit 2d504bde50a0c560a9d31b7b38982bd44cc7fe9d.
error: recupero non riuscito.
alberto@alberto-Studio-XPS-1340:~/sdr_stuff$

 Messaggio originale
 Da: fab...@opencode.eu
 Data: 10-apr-2021 22.08
 A: 
 Ogg: Re: Gnuradio / Ubuntu 20.10

 Hi Alberto,
 Just open a terminal and run
 sudo apt install gnuradio
 And you should be fine. The dependencies for the rtl-sdr are already 
included.
 It is probably not the latest version of gnuradio, but IT should 
get you
 started.

 Fabian

 Am 10. April 2021 21:38:47 MESZ schrieb Alberto Alletto 
:

 Hi!
 I’m new on ubuntu world.
 Today i have installed ubuntu 20.10 and i want install Gnuradio to 
work with RTL-SDR receiver.

 what is the correct procedure to install gnuradio to work with the 
rtl-sdr receiver?

 Tnx
 Alberto

 Inviato da iPhone

Re: R: Re: Gnuradio / Ubuntu 20.10

2021-04-11 Thread Ralf Gorholt


Hello Alberto,

you may try this:

git clone git://github.com/osmocom/gr-osmosdr -b gr3.8

That's how I got the sources for GNU Radio 3.8 one or two weeks ago.

Regards,

Ralf

Am 11.04.2021 um 12:35 schrieb alberto.alle...@alice.it:

I follow now this guide:
https://lists.gnu.org/archive/html/discuss-gnuradio/2020-09/pdfNp27msymbN.pdf

But at point 7 i have a problem.

alberto@alberto-Studio-XPS-1340:~/sdr_stuff$ git clone
https://git.osmocom.org/gr-osmosdr
Clone in 'gr-osmosdr' in corso...
error: Failed to connect to git.osmocom.org port 443: Connessione
scaduta (curl_result = 7, http_code = 0, sha1 =
3d94e1a5d172fc93da9e9638536ee773f4b5a85a)
error: Unable to find 99f14f4991f4154d743fd08b9c49e4eaf8a70001 under
https://git.osmocom.org/gr-osmosdr
Cannot obtain needed blob 99f14f4991f4154d743fd08b9c49e4eaf8a70001
while processing commit 2d504bde50a0c560a9d31b7b38982bd44cc7fe9d.
error: recupero non riuscito.
alberto@alberto-Studio-XPS-1340:~/sdr_stuff$

Messaggio originale
Da: fab...@opencode.eu
Data: 10-apr-2021 22.08
A: 
Ogg: Re: Gnuradio / Ubuntu 20.10

Hi Alberto,
Just open a terminal and run
sudo apt install gnuradio
And you should be fine. The dependencies for the rtl-sdr are
already included.
It is probably not the latest version of gnuradio, but IT
should get you started.

Fabian

Am 10. April 2021 21:38:47 MESZ schrieb Alberto Alletto
:

Hi!
I’m new on ubuntu world.
Today i have installed ubuntu 20.10 and i want install Gnuradio to work 
with RTL-SDR receiver.

what is the correct procedure to install gnuradio to work with the 
rtl-sdr receiver?

Tnx
Alberto

Inviato da iPhone

Re: Transport stream source

2021-04-04 Thread Ralf Gorholt


Thank you, this would explain why it did not work out of the box. I had
tried multi-cast.

Ralf

Am 04.04.2021 um 20:22 schrieb Marcus D. Leech:

On 04/04/2021 12:22 PM, Ralf Gorholt wrote:

Hello Steven,

when I look at your flow graph, that is exactly what I have tried to
do (use a UDP source and UDP sink) but it did not work. Could it be
because I had not put a throttle between source and sink?

I will try to reproduce what you have done and see if it works (I
don't know 'socat' and have never used it before).

Ralf

I'll note that any application using multi-cast UDP must do some
"special dances" with most OS in order for multi-cast to "work".

See, for example, some example code here:

https://gist.github.com/hostilefork/f7cae3dc33e7416f2dd25a402857b6c6


It's unlikely that the gr UDP source/sink "know" how to handle
multi-cast by themselves.

Re: Transport stream source

2021-04-04 Thread Ralf Gorholt


Hello Steven,

when I look at your flow graph, that is exactly what I have tried to do
(use a UDP source and UDP sink) but it did not work. Could it be because
I had not put a throttle between source and sink?

I will try to reproduce what you have done and see if it works (I don't
know 'socat' and have never used it before).

Ralf

Am 04.04.2021 um 18:09 schrieb Steven Barbo:

Hello.
If the question is, how can one receive an multicast udp transport
stream into udp  gr source block?

as a test, i've an encoder that encodes a transport stream to
udp://239.255.42.42:5004 <http://239.255.42.42:5004>  -

     socat udp4-recv:5004,ip-add-membership=239.255.42.42.0:0.0.0
udp4-sendto:192.168.12.12:5006 <http://192.168.12.12:5006>

now send it back out using multicast address 239.255.99.99
<http://239.255.99.99>: 5008 from gr block -

mc.png


On Sat, Apr 3, 2021 at 2:48 PM Ralf Gorholt mailto:ralf.gorh...@gmx.de>> wrote:

Dear all,

instead of using a file source, I would like to get data from a video
stream into GNU Radio. Is this possible?

With VLC, I can connect to the stream using a URL like
udp://230.0.0.10:1234 <http://230.0.0.10:1234>. How can I do this
in GNU Radio? I have tried to
use a UDP source with this address and payload size 1316 (needed
for VLC
when it connects to a UDP sink in GNU Radio) and to pass the data to a
UDP sink at address 230.0.0.20:1 <http://230.0.0.20:1> and
payload size 1316 to which I
can connect with VLC to see if it works but when I start the flow
graph,
nothing seems to come out, VLC tries in vain to connect.

Thank you very much and happy easter!

Kind regards,

Ralf



--
If something is requisite, how can it possibly be, prerequisite?

vanitas vanitatum omnia vanitas
later, steve
http://umn.edu/~barbo <http://umn.edu/~barbo>

Re: Transport stream source

2021-04-04 Thread Ralf Gorholt


Hi Marcus,

as I have written, I have tried to use a UDP source (and to connect it
to a UDP sink with a different IP address and port) but it does not seem
to work. As I am quite new to GNU radio, I have certainly made a mistake
somewhere. If I only needed a TS source (no matter which one) I could
stick with a file. I have already done that and it worked.

Could somebody please direct me to the documentation where the basic
principle of how GNU Radio works is explained? I know that there are
blocks that you can connect together but there must be a "controller"
somewhere and I would like to understand how this controller works and
how the blocks are called. What I have read until now does not answer my
questions :-)

Happy Easter,

Ralf

Am 03.04.2021 um 21:52 schrieb Marcus D Leech:

If you want VLC to produce a stream and Gnu Radio to consume it, you need a UDP 
*source* rather than a *sink*.



Sent from my iPhone


On Apr 3, 2021, at 3:48 PM, Ralf Gorholt  wrote:

Dear all,

instead of using a file source, I would like to get data from a video
stream into GNU Radio. Is this possible?

With VLC, I can connect to the stream using a URL like
udp://230.0.0.10:1234. How can I do this in GNU Radio? I have tried to
use a UDP source with this address and payload size 1316 (needed for VLC
when it connects to a UDP sink in GNU Radio) and to pass the data to a
UDP sink at address 230.0.0.20:1 and payload size 1316 to which I
can connect with VLC to see if it works but when I start the flow graph,
nothing seems to come out, VLC tries in vain to connect.

Thank you very much and happy easter!

Kind regards,

Ralf

Transport stream source

2021-04-03 Thread Ralf Gorholt


Dear all,

instead of using a file source, I would like to get data from a video
stream into GNU Radio. Is this possible?

With VLC, I can connect to the stream using a URL like
udp://230.0.0.10:1234. How can I do this in GNU Radio? I have tried to
use a UDP source with this address and payload size 1316 (needed for VLC
when it connects to a UDP sink in GNU Radio) and to pass the data to a
UDP sink at address 230.0.0.20:1 and payload size 1316 to which I
can connect with VLC to see if it works but when I start the flow graph,
nothing seems to come out, VLC tries in vain to connect.

Thank you very much and happy easter!

Kind regards,

Ralf

Compilation of Ron Economos' gr-dvbtx for GNU Radio 3.8 - help needed

2021-03-22 Thread Ralf Gorholt


Dear all,

I have tried to compile Ron Economs’ block gr-dvbtx from
github.com/drmpeg/gr-dvbtx for GNU Radio 3.7.11 and 3.8.2 but I have
noticed several problems.

1) In both environments compilation stops because of an error:
"gr-dvbtx/lib/dvbtx_ofdm_sym_acquisition_impl.cc:54:68: error: cannot
convert ‘uint32_t* {aka unsigned int*}’ to ‘uint16_t* {aka short
unsigned int*}’ in argument passing volk_32f_index_max_16u(_index,
[0], datain_length);"

In order to be able to compile the module, I have declared peak_index as
uint16_t but I don’t know if this is the correct way to get rid of this
error. For GNU Radio 3.7 everything seems ok now. The module is compiled
and appears in the list of modules of GNU Radio Companion. Is this
correction ok?

2) CMakeLists.txt expects GNU Radio version 3.7.2:
"find_package(Gnuradio "3.7.2" REQUIRED)". In order to compile for
version 3.8.2, I had to adapt this line.

3) Now I can compile the module for GNU Radio 3.8, but after "make
install" and "ldconfig", GNU Radio Companion does not show the module in
the list. Install prefix is /usr. I have noticed that the compiled
module for version 3.7 has a version information in the name:
"libgnuradio-dvbtx-1.0.0git.so.0.0.0" but the one for version 3.8 has
not: "libgnuradio-dvbtx-...so.0.0.0". Could this be the reason for the
problem? The version is set in CMakeLists.txt. Why is it empty when
compiled for version 3.8?

Could somebody please give me a hint what I have to do to get this
module compiled and installed for GNU Radio 3.8? I would like to use it
on a more recent version of GNU Radio than 3.7.

Thank you very much for your help!

Kind regards,

Ralf

Compile OOT module on Windows

2021-03-16 Thread Ralf Gorholt


Ok, please forget my question.

I have found that I need to specify the Makefile generator which at
least in my case is NMake by default but I need MinGW.

Now I have to install missing software (e.g. boost).

Ralf

Re: Survey regarding GNU radio usage in amateur radio

2020-11-15 Thread Ralf Gorholt


Hello Adrian,

here are my answers to your questions:

1) No.

2) I have tried to use it for DVB-T reception with an RTL-SDR stick in
the 70cm band with non standard bandwidths (2 MHz and lower). In
principle, this is possible, but there is a problem in the OFDM symbol
recognition block due to different clocks used by the receiver and
transmitter. This leads sooner or later (seconds to minutes) to
reception loss because the receiver has to re-synchronize again.
Somebody on the list (I don't remember his name by heart, I would have
to search my emails) has made something for ISDB-T but this is not
usable for DVB-T.

3) In my opinion, GNU Radio is a very powerful tool. But, it is only a
tool and a tool that you have to know how to use. Abolutely nothing for
beginners. Mostly nothing is really ready, you have to build what you
need yourself. The GUI is very basic. This is only my personal
impression, I may be wrong. And I don't know PYTHON and at my age, I
don't want to learn yet another programming language.

4) Strong: very powerful and versatile. Weak: different versions of GNU
Radio are available, for Linux and Windows, every one with different
options (available blocks). Sometimes newer versions do not offer all
available blocks. Sometimes you have to compile modules yourself,
something that is difficult when you have to or want to stick to
Windows. I am partially able to do this but many OMs that I know are
not. And lastly, even if Linux was the best system around, people would
still prefer Windows. My impression is that without an always up to date
Windows version GNU Radio will remain something for "nerds".

5) Yes.

Kind regards,

Ralf

Am 14.11.2020 um 21:43 schrieb Elmore Family:

Adrian,

Here are my answers to your survey;

1. Yes
2. Attempting to provide a complete transceiver for a Softrock/MOBO
4. It has a very steep learning curve which will keep the majority of
hams from utilizing it. However, it's block nature allows RAD which is
very attractive for SDR development.
5. No


-Original Message- From: Adrian Musceac
Sent: Saturday, November 14, 2020 3:11 AM
To: discuss-gnuradio@gnu.org
Subject: Survey regarding GNU radio usage in amateur radio

Hello,

I am doing a survey regarding the topic of GNU radio usage in amateur
radio
activities.
This survey is aimed at GNU radio users who are also amateur radio
operators.
The result of the survey will be published in an article freely
available on
the Internet and may also be translated to other languages for reading by
other amateur radio operators.

Your contribution to the survey will remain anonymous unless you
express a
wish to have author attribution for the answers.
You should be comfortable with the license of publication which will
be one of
Creative Commons Attribution 4.0 license or GNU Free Documentation
license.
You may reply directly or send me the answers privately. The date
limit for
answers is 30 December current year.

I will ask you to respond to the following questions (you may omit
questions
where you do not have answers):


1. Are you actively using GNU radio in amateur radio activities?


2. If yes, how are you using GNU radio, please provide some details.

3. Do you think GNU radio and applications using it solve some
specific problem
for amateur operators which is not solved by other free software DSP
libraries, or, on the contrary, do you think it should implement a
solution
that already exists elsewhere?

4. What would you consider strong and weak points in GNU radio when
related to
amateur radio usage?

5. Is your local amateur radio community generally aware of the
existence of
GNU radio?

6. If you have any authored / co-authored published papers, talk slides,
seminars etc. related to the topic of this survey, can you provide a
short
description and a link if available?

7. Are you involved in research projects which use amateur radio
crowd-sourced
data, and if so, can you provide a short description of the project?

8. Do you have any suggestions for raising general amateur radio public
awareness of free software in general and specifically GNU radio?


Thanks in advance for answering.

Adrian

Re: DVB-T receiver problem (OFDM symbol acquisition)

2020-03-04 Thread Ralf Gorholt

Hello Ron,

do you think it would be possible to use your block that detects the
drift to adapt the sample rate of the source block automatically and if
yes, how would I have to do that? When the position of the CP increases,
the sample rate must be decreased and vice versa. Could it be done by a
kind of feedback? This way it would not be necessary to implement the
algorithm for DVB-T. Even if I would like to do this, due to my lack of
knowledge I don't think that I would be able to.

Sample rate correction solves my problem but in order to be useful, it
would have to be done automatically.

Thank you very much and kind regards,

Ralf

Am 02.03.2020 um 13:42 schrieb Ron Economos:

Did you read the README.md of gr-dvbt? It says:

/Late note: As of 2015, I donated the gr-dvbt project to gnuradio. It
is now integrated in the mainline of gnuradio/gr-dtv./

The OFDM symbol acquisition block in gr-dtv has been upgraded with the
fixes from the ISDBT team. See this commit:

https://github.com/gnuradio/gnuradio/commit/761b62d4660a121c78b6a7ad17fd7b08badcbb88#diff-aa5858d955a31c6be8746db56ea13c6a

However, there is still an issue with the block. It can't tolerate a
sample rate difference between the transmitter and receiver. If the
difference is large, the block will fail fairly quickly (minutes).

I have a test OFDM acquisition block that prints out the drift. It can
be found here:

https://github.com/drmpeg/gr-dvbtx

You may have to go back one commit to make it compile with the latest
version of GNU Radio 3.7.

Ron

On 3/2/20 03:58, Ralf Gorholt wrote:

Dear all,

please apologize my long email but I cannot explain my problem and
what I have done so far in three words.

I am currently working on a DVB-T receiver project to receive
transmissions on 434 MHz with 2 MHz bandwidth or less using GNU Radio
and an RTL-SDR stick. The flow graph is based on the examples in
gr-dvbt. The transmitter is a HiDes model HV320E. Reception works,
but the video stops after one minute or so while the constellation
diagram is still active (dots are moving). I am no expert and have
only few knowledge of DSP and DVB yet, but to me the problem seems to
be in the OFDM symbol acquisition block.

Conditions:
Linux Mint 19.3 in a virtual machine (VMware)
GNU Radio 3.7.11 if I am right (I would need to check at home)

What I have done so far:

I have created a flow graph for a DVB-T receiver based on the
examples in gr-dvbt. The signal source is an RTL-SDR stick and the
sample rate is 16/7 MHz (= 2.285714 MHz) to get 2 MHz bandwidth. The
signal sink is a TCP server sink to which I connect with VLC media
player to display the received video transport stream. This works,
but after one minute or so the video stops while the constellation
diagram is still active (dots are moving). I am currently using QPSK,
code rate 3/4 and guard interval 1/8 but I have also tried 16QAM,
code rate 1/2 and guard interval 1/8 and have the same problem.

To track down the source of the problem, I have created a file
outside of GNU Radio that I can use in a file source instead of the
RTL-SDR source of my flow graph. This allows me to make tests with an
input signal that does not change between different tests.

The data of this file are sent to the OFDM symbol acquisition block
and the output of this block is stored in a second file. When the
input signal, the algorithm and the parameters do not change between
different tests I expect the generated file to be always the same.
However, this is not the case. The files that are generated with the
output of the OFDM symbol acquisition block differ from each other.
But when I send the content of one of those generated files to the
rest of the receiver and do this several times, I always get the same
transport stream at the output. I have verified this by using a file
sink and comparing the files. That’s why I suspect the OFDM symbol
acquisition block to be the culprit.

When I was searching the internet for information concerning my
problem, I found an email from 2015 in the archive of this mailing
list where someone wrote that the OFDM symbol acquisition block of
gr-isdbt should be used because it worked better than the one in
gr-dvbt. I have done so and installed gr-isdbt from git and replaced
the block. However, there are two such blocks in gr-isdbt and none of
them solves my problem. They perform even worse than the original
block in gr-dvbt and after some time the program terminates without a
message.

I hope that my explanations are clear enough.

Is there anybody who can tell me what might be wrong here or what I
am doing wrong? Why is the output of the OFDM symbol acquisition
block not always the same when the start condition of every run is
the same? Am I missing something here?

Thank you very much for your help.

Kind regards,

Ralf

Re: DVB-T receiver problem (OFDM symbol acquisition)

2020-03-03 Thread Ralf Gorholt

Hi Ron,

when I adapt the parameters of my flow graph I get exactly the same
result with your file as you do.

Kind regards,

Ralf

Am 03.03.2020 um 02:22 schrieb Ron Economos:

Yes, changing back to uint16_t is correct. But something is not
correct with your file. When you read from a file, sample rate doesn't
matter. You shouldn't see any drift at all.

I have a test file on my website. It can be downloaded at:

http://www.w6rz.net/adv16.cfile

It's 934,551,552 bytes

It's meant to be run with the default test flow graph, dvbt_rx_8k.grc
(8K, 2/3, 16QAM, 1/32 GI). On my setup, I get the following from the
debug block every time.

OFDM Symbol Acquisition Restarted!
Cyclic Prefix position = 12671
Cyclic Prefix position = 12671
Cyclic Prefix position = 12671
Cyclic Prefix position = 12671
Cyclic Prefix position = 12671
Cyclic Prefix position = 12671
Cyclic Prefix position = 12671
Cyclic Prefix position = 12671
Cyclic Prefix position = 12671
Cyclic Prefix position = 12671
Cyclic Prefix position = 12671
Cyclic Prefix position = 12671

>>> Done

That file was created by just using the transmitter test flow graph
(dvbt_tx_8k.grc) and writing to a file instead of transmitting over
the air.

Ron

On 3/2/20 12:45, Ralf Gorholt wrote:

Dear Ron,

the fixes seem to be included in the version that I have installed
(3.7.11-10).

I have tried to build your debug block but I get an error message
concerning a type cast:

ralfg@vm5:~/GNU Radio/src/gr-dvbtx-master/build$ make
[ 5%] Building CXX object
lib/CMakeFiles/gnuradio-dvbtx.dir/dvbtx_ofdm_sym_acquisition_impl.cc.o
/home/ralfg/GNU
Radio/src/gr-dvbtx-master/lib/dvbtx_ofdm_sym_acquisition_impl.cc: In
member function ‘int
gr::dvbtx::dvbtx_ofdm_sym_acquisition_impl::peak_detect_process(const
float*, int, int*, int*)’:
/home/ralfg/GNU
Radio/src/gr-dvbtx-master/lib/dvbtx_ofdm_sym_acquisition_impl.cc:54:68:
error: cannot convert ‘uint32_t* {aka unsigned int*}’ to ‘uint16_t*
{aka short unsigned int*}’ in argument passing
volk_32f_index_max_16u(_index, [0], datain_length);

To be able to compile the module, I have changed the type of
peak_index to uint16_t, hoping this is correct.

When I run my flow graph on a live video, I can see that the position
of the cyclic prefix changes constantly. The same happens when I take
the data from the file as input (which I think is normal, because the
signal has been sampled with the same sample rate).

However, given that the data in the file don't change, I do not
understand why two consecutive runs on the same data detect different
positions of the cyclic prefix:

1st run:
OFDM Symbol Acquisition Restarted!
OFDM Symbol Acquisition Restarted!
OFDM Symbol Acquisition Restarted!
OFDM Symbol Acquisition Restarted!
OFDM Symbol Acquisition Restarted!
OFDM Symbol Acquisition Restarted!
Cyclic Prefix position = 3963
Cyclic Prefix position = 3978
Cyclic Prefix position = 3993
Cyclic Prefix position = 4009
Cyclic Prefix position = 4026
[... deleted ...]
Cyclic Prefix position = 4597
Cyclic Prefix position overflow!
OFDM Symbol Acquisition Restarted!
Cyclic Prefix position = 3460

2nd run:
OFDM Symbol Acquisition Restarted!
OFDM Symbol Acquisition Restarted!
OFDM Symbol Acquisition Restarted!
OFDM Symbol Acquisition Restarted!
OFDM Symbol Acquisition Restarted!
OFDM Symbol Acquisition Restarted!
Cyclic Prefix position = 3963
Cyclic Prefix position = 3979
Cyclic Prefix position = 3995
Cyclic Prefix position = 4010
Cyclic Prefix position = 4025
[... deleted ...]
Cyclic Prefix position = 4595
Cyclic Prefix position overflow!
OFDM Symbol Acquisition Restarted!
Cyclic Prefix position = 3458

At the beginning of both runs the position of the cyclic prefix is
3963. This means, that in both cases the first symbol is detected at
the same position. How is it possible that the position of the
following symbols differ (e.g. 3978 vs. 3979)? All I did was stopping
and restarting the flow graph. As everything in the block is pure and
well defined mathematics, when the conditions (data, parameters) do
not change, to my understanding the result should always be the same.

I may be wrong, but in this case I would like to understand why. Do
you have an explanation for me?

Thank you very much for your help.

Kind regards,

Ralf, DL5EU

Am 02.03.2020 um 13:42 schrieb Ron Economos:

Did you read the README.md of gr-dvbt? It says:

/Late note: As of 2015, I donated the gr-dvbt project to gnuradio.
It is now integrated in the mainline of gnuradio/gr-dtv./

The OFDM symbol acquisition block in gr-dtv has been upgraded with
the fixes from the ISDBT team. See this commit:

https://github.com/gnuradio/gnuradio/commit/761b62d4660a121c78b6a7ad17fd7b08badcbb88#diff-aa5858d955a31c6be8746db56ea13c6a

I have a test OFDM acquisition block that prints out

Re: DVB-T receiver problem (OFDM symbol acquisition)

2020-03-03 Thread Ralf Gorholt

Hi Federico,

I think I have sent my previous email a bit too fast.

After having looked at the code of the OFDM Synchronization block it
seems to me that this block is specific to ISDB-T. This would mean that
I cannot use it for DVB-T because of incompatibilities between ISDB-T
and DVB-T (e.g. carrier positions).

Kind regards,

Ralf

Am 03.03.2020 um 13:05 schrieb Federico 'Larroca' La Rocca:

Hi Ralf,
It should be right after the channel. It performs symbol acquisition,
FFT and channel equalization (as well as sampling corrections and
coarse and fine frequency corrections). Please see the examples folder
in gr-isdbt (for instance rx_demo.grc which also includes the gr-dtv
blocks disabled, which should help you understand where to put the
block).
best

El mar., 3 mar. 2020 a las 4:16, Ralf Gorholt (mailto:ralf.gorh...@gmx.de>>) escribió:

Dear Federico,
unfortunately I have not been able to figure out how this block
has to be used and where it has to be positioned in the flow
graph. Although I know more about DVB-T today than three months
ago I am still a beginner :-)
Perhaps it would help me if you could give me some hints.
Thank you very much and kind regards,
Ralf, DL5EU
*Gesendet:* Montag, 02. März 2020 um 13:47 Uhr
*Von:* "Federico 'Larroca' La Rocca" mailto:flarr...@gmail.com>>
*An:* "Ron Economos" mailto:w...@comcast.net>>
*Cc:* "GNURadio Discussion List" mailto:discuss-gnuradio@gnu.org>>
*Betreff:* Re: DVB-T receiver problem (OFDM symbol acquisition)
Hi,
Although I don't have an answer to Ralf's question, if the
sampling rate seems to be a problem, gr-isdbt's OFDM
Synchronization block (with "Interpolate" set to "yes") corrects
the sampling rate; see
https://iie.fing.edu.uy/publicaciones/2016/LFGGB16/ for an
explanation of the algorithm (although it expects different tags
and parameters, so that's probably why it won't work out of the
box with the rest of the gr-dtv blocks or a DVB-T transmission).
As Ron wrote, the rest of the block is mostly the same as in gr-dtv.
best
Federico
El lun., 2 mar. 2020 a las 9:44, Ron Economos (mailto:w...@comcast.net>>) escribió:

Did you read the README.md of gr-dvbt? It says:

/Late note: As of 2015, I donated the gr-dvbt project to
gnuradio. It is now integrated in the mainline of
gnuradio/gr-dtv./

The OFDM symbol acquisition block in gr-dtv has been upgraded
with the fixes from the ISDBT team. See this commit:

https://github.com/gnuradio/gnuradio/commit/761b62d4660a121c78b6a7ad17fd7b08badcbb88#diff-aa5858d955a31c6be8746db56ea13c6a

However, there is still an issue with the block. It can't
tolerate a sample rate difference between the transmitter and
receiver. If the difference is large, the block will fail
fairly quickly (minutes).

I have a test OFDM acquisition block that prints out the
drift. It can be found here:

https://github.com/drmpeg/gr-dvbtx

You may have to go back one commit to make it compile with the
latest version of GNU Radio 3.7.

Ron

On 3/2/20 03:58, Ralf Gorholt wrote:

Dear all,

please apologize my long email but I cannot explain my
problem and what I have done so far in three words.

I am currently working on a DVB-T receiver project to
receive transmissions on 434 MHz with 2 MHz bandwidth or
less using GNU Radio and an RTL-SDR stick. The flow graph
is based on the examples in gr-dvbt. The transmitter is a
HiDes model HV320E. Reception works, but the video stops
after one minute or so while the constellation diagram is
still active (dots are moving). I am no expert and have
only few knowledge of DSP and DVB yet, but to me the
problem seems to be in the OFDM symbol acquisition block.

Conditions:
Linux Mint 19.3 in a virtual machine (VMware)
GNU Radio 3.7.11 if I am right (I would need to check at home)

What I have done so far:

I have created a flow graph for a DVB-T receiver based on
the examples in gr-dvbt. The signal source is an RTL-SDR
stick and the sample rate is 16/7 MHz (= 2.285714 MHz) to
get 2 MHz bandwidth. The signal sink is a TCP server sink
to which I connect with VLC media player to display the
received video transport stream. This works, but after one
minute or so the video stops while the constellation
diagram is still active (dots are moving). I am currently
using QPSK, code rate 3/4 and guard interval 1/8 but I
have also tried 16QAM, code rate 1/2 and guard interval
1/8 an

Aw: Re: DVB-T receiver problem (OFDM symbol acquisition)

2020-03-03 Thread Ralf Gorholt

Thank you very much, Federico.

If I understand correctly, this block replaces the OFDM symbol acquisition block. I will have a look at the examples and try it.

Best regards,

Ralf, DL5EU

Gesendet: Dienstag, 03. März 2020 um 13:05 Uhr
Von: "Federico 'Larroca' La Rocca"
An: "Ralf Gorholt"
Cc: "GNURadio Discussion List"
Betreff: Re: DVB-T receiver problem (OFDM symbol acquisition)

Hi Ralf,

It should be right after the channel. It performs symbol acquisition, FFT and channel equalization (as well as sampling corrections and coarse and fine frequency corrections). Please see the examples folder in gr-isdbt (for instance rx_demo.grc which also includes the gr-dtv blocks disabled, which should help you understand where to put the block).

best

El mar., 3 mar. 2020 a las 4:16, Ralf Gorholt (<ralf.gorh...@gmx.de>) escribió:

Dear Federico,

unfortunately I have not been able to figure out how this block has to be used and where it has to be positioned in the flow graph. Although I know more about DVB-T today than three months ago I am still a beginner :-)

Perhaps it would help me if you could give me some hints.

Thank you very much and kind regards,

Ralf, DL5EU

Gesendet: Montag, 02. März 2020 um 13:47 Uhr
Von: "Federico 'Larroca' La Rocca" <flarr...@gmail.com>
An: "Ron Economos" <w...@comcast.net>
Cc: "GNURadio Discussion List" <discuss-gnuradio@gnu.org>
Betreff: Re: DVB-T receiver problem (OFDM symbol acquisition)

Hi,

Although I don't have an answer to Ralf's question, if the sampling rate seems to be a problem, gr-isdbt's OFDM Synchronization block (with "Interpolate" set to "yes") corrects the sampling rate; see https://iie.fing.edu.uy/publicaciones/2016/LFGGB16/ for an explanation of the algorithm (although it expects different tags and parameters, so that's probably why it won't work out of the box with the rest of the gr-dtv blocks or a DVB-T transmission). As Ron wrote, the rest of the block is mostly the same as in gr-dtv.

best

Federico

El lun., 2 mar. 2020 a las 9:44, Ron Economos (<w...@comcast.net>) escribió:

Did you read the README.md of gr-dvbt? It says:

Late note: As of 2015, I donated the gr-dvbt project to gnuradio. It is now integrated in the mainline of gnuradio/gr-dtv.

The OFDM symbol acquisition block in gr-dtv has been upgraded with the fixes from the ISDBT team. See this commit:

https://github.com/gnuradio/gnuradio/commit/761b62d4660a121c78b6a7ad17fd7b08badcbb88#diff-aa5858d955a31c6be8746db56ea13c6a

However, there is still an issue with the block. It can't tolerate a sample rate difference between the transmitter and receiver. If the difference is large, the block will fail fairly quickly (minutes).

I have a test OFDM acquisition block that prints out the drift. It can be found here:

https://github.com/drmpeg/gr-dvbtx

You may have to go back one commit to make it compile with the latest version of GNU Radio 3.7.

Ron

On 3/2/20 03:58, Ralf Gorholt wrote:

Dear all,

please apologize my long email but I cannot explain my problem and what I have done so far in three words.

I am currently working on a DVB-T receiver project to receive transmissions on 434 MHz with 2 MHz bandwidth or less using GNU Radio and an RTL-SDR stick. The flow graph is based on the examples in gr-dvbt. The transmitter is a HiDes model HV320E. Reception works, but the video stops after one minute or so while the constellation diagram is still active (dots are moving). I am no expert and have only few knowledge of DSP and DVB yet, but to me the problem seems to be in the OFDM symbol acquisition block.

Conditions:
Linux Mint 19.3 in a virtual machine (VMware)
GNU Radio 3.7.11 if I am right (I would need to check at home)

What I have done so far:

I have created a flow graph for a DVB-T receiver based on the examples in gr-dvbt. The signal source is an RTL-SDR stick and the sample rate is 16/7 MHz (= 2.285714 MHz) to get 2 MHz bandwidth. The signal sink is a TCP server sink to which I connect with VLC media player to display the received video transport stream. This works, but after one minute or so the video stops while the constellation diagram is still active (dots are moving). I am currently using QPSK, code rate 3/4 and guard interval 1/8 but I have also tried 16QAM, code rate 1/2 and guard interval 1/8 and have the same problem.

To track down the source of the problem, I have created a file outside of GNU Radio that I can use in a file source instead of the RTL-SDR source of my flow graph. This allows me to make tests with an input signal that does not change between different tests.

Re: DVB-T receiver problem (OFDM symbol acquisition)

Dear Federico,

Perhaps it would help me if you could give me some hints.

Thank you very much and kind regards,

Ralf, DL5EU

Gesendet: Montag, 02. März 2020 um 13:47 Uhr
Von: "Federico 'Larroca' La Rocca"
An: "Ron Economos"
Cc: "GNURadio Discussion List"
Betreff: Re: DVB-T receiver problem (OFDM symbol acquisition)

Hi,

best

Federico

El lun., 2 mar. 2020 a las 9:44, Ron Economos (<w...@comcast.net>) escribió:

Did you read the README.md of gr-dvbt? It says:

Late note: As of 2015, I donated the gr-dvbt project to gnuradio. It is now integrated in the mainline of gnuradio/gr-dtv.

The OFDM symbol acquisition block in gr-dtv has been upgraded with the fixes from the ISDBT team. See this commit:

https://github.com/gnuradio/gnuradio/commit/761b62d4660a121c78b6a7ad17fd7b08badcbb88#diff-aa5858d955a31c6be8746db56ea13c6a

However, there is still an issue with the block. It can't tolerate a sample rate difference between the transmitter and receiver. If the difference is large, the block will fail fairly quickly (minutes).

I have a test OFDM acquisition block that prints out the drift. It can be found here:

https://github.com/drmpeg/gr-dvbtx

You may have to go back one commit to make it compile with the latest version of GNU Radio 3.7.

Ron

On 3/2/20 03:58, Ralf Gorholt wrote:

Dear all,

please apologize my long email but I cannot explain my problem and what I have done so far in three words.

I am currently working on a DVB-T receiver project to receive transmissions on 434 MHz with 2 MHz bandwidth or less using GNU Radio and an RTL-SDR stick. The flow graph is based on the examples in gr-dvbt. The transmitter is a HiDes model HV320E. Reception works, but the video stops after one minute or so while the constellation diagram is still active (dots are moving). I am no expert and have only few knowledge of DSP and DVB yet, but to me the problem seems to be in the OFDM symbol acquisition block.

Conditions:
Linux Mint 19.3 in a virtual machine (VMware)
GNU Radio 3.7.11 if I am right (I would need to check at home)

What I have done so far:

I have created a flow graph for a DVB-T receiver based on the examples in gr-dvbt. The signal source is an RTL-SDR stick and the sample rate is 16/7 MHz (= 2.285714 MHz) to get 2 MHz bandwidth. The signal sink is a TCP server sink to which I connect with VLC media player to display the received video transport stream. This works, but after one minute or so the video stops while the constellation diagram is still active (dots are moving). I am currently using QPSK, code rate 3/4 and guard interval 1/8 but I have also tried 16QAM, code rate 1/2 and guard interval 1/8 and have the same problem.

To track down the source of the problem, I have created a file outside of GNU Radio that I can use in a file source instead of the RTL-SDR source of my flow graph. This allows me to make tests with an input signal that does not change between different tests.

The data of this file are sent to the OFDM symbol acquisition block and the output of this block is stored in a second file. When the input signal, the algorithm and the parameters do not change between different tests I expect the generated file to be always the same. However, this is not the case. The files that are generated with the output of the OFDM symbol acquisition block differ from each other. But when I send the content of one of those generated files to the rest of the receiver and do this several times, I always get the same transport stream at the output. I have verified this by using a file sink and comparing the files. That’s why I suspect the OFDM symbol acquisition block to be the culprit.

When I was searching the internet for information concerning my problem, I found an email from 2015 in the archive of this mailing list where someone wrote that the OFDM symbol acquisition block of gr-isdbt should be used because it worked better than the one in gr-dvbt. I have done so and installed gr-isdbt from git and replaced the block. However, there are two such blocks in gr-isdbt and none of them solves my problem. They perform even worse than the original block in gr-dvbt and after some time t

Re: DVB-T receiver problem (OFDM symbol acquisition)

Dear Ron,

the fixes seem to be included in the version that I have installed
(3.7.11-10).

I have tried to build your debug block but I get an error message
concerning a type cast:

ralfg@vm5:~/GNU Radio/src/gr-dvbtx-master/build$ make
[ 5%] Building CXX object
lib/CMakeFiles/gnuradio-dvbtx.dir/dvbtx_ofdm_sym_acquisition_impl.cc.o
/home/ralfg/GNU
Radio/src/gr-dvbtx-master/lib/dvbtx_ofdm_sym_acquisition_impl.cc: In
member function ‘int
gr::dvbtx::dvbtx_ofdm_sym_acquisition_impl::peak_detect_process(const
float*, int, int*, int*)’:
/home/ralfg/GNU
Radio/src/gr-dvbtx-master/lib/dvbtx_ofdm_sym_acquisition_impl.cc:54:68:
error: cannot convert ‘uint32_t* {aka unsigned int*}’ to ‘uint16_t* {aka
short unsigned int*}’ in argument passing
volk_32f_index_max_16u(_index, [0], datain_length);

To be able to compile the module, I have changed the type of peak_index
to uint16_t, hoping this is correct.

When I run my flow graph on a live video, I can see that the position of
the cyclic prefix changes constantly. The same happens when I take the
data from the file as input (which I think is normal, because the signal
has been sampled with the same sample rate).

However, given that the data in the file don't change, I do not
understand why two consecutive runs on the same data detect different
positions of the cyclic prefix:

At the beginning of both runs the position of the cyclic prefix is 3963.
This means, that in both cases the first symbol is detected at the same
position. How is it possible that the position of the following symbols
differ (e.g. 3978 vs. 3979)? All I did was stopping and restarting the
flow graph. As everything in the block is pure and well defined
mathematics, when the conditions (data, parameters) do not change, to my
understanding the result should always be the same.

I may be wrong, but in this case I would like to understand why. Do you
have an explanation for me?

Thank you very much for your help.

Kind regards,

Ralf, DL5EU

Am 02.03.2020 um 13:42 schrieb Ron Economos:

Did you read the README.md of gr-dvbt? It says:

/Late note: As of 2015, I donated the gr-dvbt project to gnuradio. It
is now integrated in the mainline of gnuradio/gr-dtv./

The OFDM symbol acquisition block in gr-dtv has been upgraded with the
fixes from the ISDBT team. See this commit:

https://github.com/gnuradio/gnuradio/commit/761b62d4660a121c78b6a7ad17fd7b08badcbb88#diff-aa5858d955a31c6be8746db56ea13c6a

I have a test OFDM acquisition block that prints out the drift. It can
be found here:

https://github.com/drmpeg/gr-dvbtx

You may have to go back one commit to make it compile with the latest
version of GNU Radio 3.7.

Ron

On 3/2/20 03:58, Ralf Gorholt wrote:

Dear all,

please apologize my long email but I cannot explain my problem and
what I have done so far in three words.

Conditions:
Linux Mint 19.3 in a virtual machine (VMware)
GNU Radio 3.7.11 if I am right (I would need to check at home)

What I have done so far:

Aw: Re: DVB-T receiver problem (OFDM symbol acquisition)

Dear Ron,

my input signal comes from a file and is the same for every test. I also do not change any parameter between tests. If a difference in the sample rate was the cause of the problem, shouldn't the program always fail at exactly the same point (or time)? This is definitely not the case.

However, I have some new things to test now. Thank you all very much.

Ralf

Gesendet: Montag, 02. März 2020 um 14:54 Uhr
Von: "Ron Economos"
An: discuss-gnuradio@gnu.org
Betreff: Re: DVB-T receiver problem (OFDM symbol acquisition)

Okay, just making sure since you mentioned gr-dvbt. I'll take a look at the gr-isdbt acquisition block and see if the interpolation method can be ported to GNU Radio.

It doesn't take much difference in sample rate to cause the problem. In my setup, I'm using two different Ettus B210's (without GPS locking), and it fails pretty quickly. I can make it run longer by using the test block and manually adjusting the sample rate of one B210.

Ron

On 3/2/20 05:35, Ralf Gorholt wrote:

Dear Ron,

thank you very much for your quick answer.

I know that Bogdan donated gr-dvbt to GNU radio and I did not install it seperately. It has been installed with GNU Radio using the package manager. The commit you mention seems to be from december 2015, so I suppose it is already in the package but I will check the source code of the installed GNU Radio version when I am back at home.

As far as the drift is concerned, I will try your block and see what it prints out. There might be a slight difference because some source blocks accept only integer values as sample rates (if i remember correctly the ADALM PLUTO does), but in my case a sample rate of 16/7 MHz is needed, which is not an integer value.

I suppose there is no way to correct a sample rate difference automatically and for small differences resampling won't help either...

Kind regards,

Ralf (DL5EU)

Gesendet: Montag, 02. März 2020 um 13:42 Uhr
Von: "Ron Economos"
An: discuss-gnuradio@gnu.org
Betreff: Re: DVB-T receiver problem (OFDM symbol acquisition)

Did you read the README.md of gr-dvbt? It says:

Late note: As of 2015, I donated the gr-dvbt project to gnuradio. It is now integrated in the mainline of gnuradio/gr-dtv.

The OFDM symbol acquisition block in gr-dtv has been upgraded with the fixes from the ISDBT team. See this commit:

https://github.com/gnuradio/gnuradio/commit/761b62d4660a121c78b6a7ad17fd7b08badcbb88#diff-aa5858d955a31c6be8746db56ea13c6a

However, there is still an issue with the block. It can't tolerate a sample rate difference between the transmitter and receiver. If the difference is large, the block will fail fairly quickly (minutes).

I have a test OFDM acquisition block that prints out the drift. It can be found here:

https://github.com/drmpeg/gr-dvbtx

You may have to go back one commit to make it compile with the latest version of GNU Radio 3.7.

Ron

On 3/2/20 03:58, Ralf Gorholt wrote:

Dear all,

please apologize my long email but I cannot explain my problem and what I have done so far in three words.

I am currently working on a DVB-T receiver project to receive transmissions on 434 MHz with 2 MHz bandwidth or less using GNU Radio and an RTL-SDR stick. The flow graph is based on the examples in gr-dvbt. The transmitter is a HiDes model HV320E. Reception works, but the video stops after one minute or so while the constellation diagram is still active (dots are moving). I am no expert and have only few knowledge of DSP and DVB yet, but to me the problem seems to be in the OFDM symbol acquisition block.

Conditions:
Linux Mint 19.3 in a virtual machine (VMware)
GNU Radio 3.7.11 if I am right (I would need to check at home)

What I have done so far:

I have created a flow graph for a DVB-T receiver based on the examples in gr-dvbt. The signal source is an RTL-SDR stick and the sample rate is 16/7 MHz (= 2.285714 MHz) to get 2 MHz bandwidth. The signal sink is a TCP server sink to which I connect with VLC media player to display the received video transport stream. This works, but after one minute or so the video stops while the constellation diagram is still active (dots are moving). I am currently using QPSK, code rate 3/4 and guard interval 1/8 but I have also tried 16QAM, code rate 1/2 and guard interval 1/8 and have the same problem.

To track down the source of the problem, I have created a file outside of GNU Radio that I can use in a file source instead of the RTL-SDR source of my flow graph. This allows me to make tests with an input signal that does not change between different tests.

Re: DVB-T receiver problem (OFDM symbol acquisition)

Dear Marcus,

Thank you too for your quick answer. I am struggling with GNU Radio since the end of last year but it's getting better :-)

The reason why I still use version 3.7 is that it is included in LinuxMint 19.3 and offers source blocks for RTL-SDR sticks and the ADALM PLUTO (I have both devices). I am not familiar with building and installing software on Linux from the sources. I had installed GNU Radio 3.8.1 for testing but some source blocks were missing so I went back to 3.7. However, since yesterday I know how I can build blocks myself (I did it with gr-isdbt), so I will try version 3.8 again.

I am looking for a simple and reproductible solution that other people are able to use without too much effort, because not every HAM is a software or Linux guru and most of the people I know prefer Windows, but that is another point. It is difficult to change habits. First I need something that works reliably.

To come back to Rons mail, if a difference in the sample rates of TX and RX caused the problem, shouldn't the program always fail at exactly the same point (time) because the input data and start conditions do not change? This is not the case.

To mention something that just comes back to my mind: as far as I can see, the first difference in the files is always at a 16k boundary (0x8000, 0xc000, 0x14000, ...) but this might be a coincidence.

Kind regards,

Ralf (DL5EU)

Gesendet: Montag, 02. März 2020 um 13:57 Uhr
Von: "Müller, Marcus (CEL)" 
An: "ralf.gorh...@gmx.de" , "discuss-gnuradio@gnu.org" 
Betreff: Re: DVB-T receiver problem (OFDM symbol acquisition)

Hi Ralf,

wow, thanks for the extensive mail! Can't process it right now (at
work), but a few quick notes:

* 3.7.11 is rather oldish, and upgrading to GNU Radio 3.8 would
definitely be a good idea. In fact, on the current development
version of GNU Radio, we even have enabled a few optimizations that
make things /much much faster/.
* Your debugging based on a file is on-point, excellent work
* I also expect the output of the OFDM symbol acquisition to be
constant. That might be a bug we fixed when we moved to GNU Radio
3.8
* All in all, if you're really still running GNU Radio 3.7, it'd be
worth just trying with Debian Testing, which comes with our latest
release, or at least debian stable / buster, which comes with
3.8.0.0

Best regards,
Marcus
On Mon, 2020-03-02 at 12:58 +0100, Ralf Gorholt wrote:
> Dear all,
>
> please apologize my long email but I cannot explain my problem and what I have done so far in three words.
>
> I am currently working on a DVB-T receiver project to receive transmissions on 434 MHz with 2 MHz bandwidth or less using GNU Radio and an RTL-SDR stick. The flow graph is based on the examples in gr-dvbt. The transmitter is a HiDes model HV320E. Reception works, but the video stops after one minute or so while the constellation diagram is still active (dots are moving). I am no expert and have only few knowledge of DSP and DVB yet, but to me the problem seems to be in the OFDM symbol acquisition block.
>
> Conditions:
> Linux Mint 19.3 in a virtual machine (VMware)
> GNU Radio 3.7.11 if I am right (I would need to check at home)
>
> What I have done so far:
>
> I have created a flow graph for a DVB-T receiver based on the examples in gr-dvbt. The signal source is an RTL-SDR stick and the sample rate is 16/7 MHz (= 2.285714 MHz) to get 2 MHz bandwidth. The signal sink is a TCP server sink to which I connect with VLC media player to display the received video transport stream. This works, but after one minute or so the video stops while the constellation diagram is still active (dots are moving). I am currently using QPSK, code rate 3/4 and guard interval 1/8 but I have also tried 16QAM, code rate 1/2 and guard interval 1/8 and have the same problem.
>
> To track down the source of the problem, I have created a file outside of GNU Radio that I can use in a file source instead of the RTL-SDR source of my flow graph. This allows me to make tests with an input signal that does not change between different tests.
>
> The data of this file are sent to the OFDM symbol acquisition block and the output of this block is stored in a second file. When the input signal, the algorithm and the parameters do not change between different tests I expect the generated file to be always the same. However, this is not the case. The files that are generated with the output of the OFDM symbol acquisition block differ from each other. But when I send the content of one of those generated files to the rest of the receiver and do this several times, I always get the same transport stream at the output. I have verified this by using a file sink and comparing the files. That’s why I suspect the OFDM symbol acquisition block to be the culprit.
>
> When I was searching the internet for information concerning my problem, I found an email

Re: DVB-T receiver problem (OFDM symbol acquisition)

Dear Ron,

thank you very much for your quick answer.

I suppose there is no way to correct a sample rate difference automatically and for small differences resampling won't help either...

Kind regards,

Ralf (DL5EU)

Gesendet: Montag, 02. März 2020 um 13:42 Uhr
Von: "Ron Economos"
An: discuss-gnuradio@gnu.org
Betreff: Re: DVB-T receiver problem (OFDM symbol acquisition)

Did you read the README.md of gr-dvbt? It says:

Late note: As of 2015, I donated the gr-dvbt project to gnuradio. It is now integrated in the mainline of gnuradio/gr-dtv.

The OFDM symbol acquisition block in gr-dtv has been upgraded with the fixes from the ISDBT team. See this commit:

https://github.com/gnuradio/gnuradio/commit/761b62d4660a121c78b6a7ad17fd7b08badcbb88#diff-aa5858d955a31c6be8746db56ea13c6a

However, there is still an issue with the block. It can't tolerate a sample rate difference between the transmitter and receiver. If the difference is large, the block will fail fairly quickly (minutes).

I have a test OFDM acquisition block that prints out the drift. It can be found here:

https://github.com/drmpeg/gr-dvbtx

You may have to go back one commit to make it compile with the latest version of GNU Radio 3.7.

Ron

On 3/2/20 03:58, Ralf Gorholt wrote:

Dear all,

please apologize my long email but I cannot explain my problem and what I have done so far in three words.

I am currently working on a DVB-T receiver project to receive transmissions on 434 MHz with 2 MHz bandwidth or less using GNU Radio and an RTL-SDR stick. The flow graph is based on the examples in gr-dvbt. The transmitter is a HiDes model HV320E. Reception works, but the video stops after one minute or so while the constellation diagram is still active (dots are moving). I am no expert and have only few knowledge of DSP and DVB yet, but to me the problem seems to be in the OFDM symbol acquisition block.

Conditions:
Linux Mint 19.3 in a virtual machine (VMware)
GNU Radio 3.7.11 if I am right (I would need to check at home)

What I have done so far:

I have created a flow graph for a DVB-T receiver based on the examples in gr-dvbt. The signal source is an RTL-SDR stick and the sample rate is 16/7 MHz (= 2.285714 MHz) to get 2 MHz bandwidth. The signal sink is a TCP server sink to which I connect with VLC media player to display the received video transport stream. This works, but after one minute or so the video stops while the constellation diagram is still active (dots are moving). I am currently using QPSK, code rate 3/4 and guard interval 1/8 but I have also tried 16QAM, code rate 1/2 and guard interval 1/8 and have the same problem.

To track down the source of the problem, I have created a file outside of GNU Radio that I can use in a file source instead of the RTL-SDR source of my flow graph. This allows me to make tests with an input signal that does not change between different tests.

The data of this file are sent to the OFDM symbol acquisition block and the output of this block is stored in a second file. When the input signal, the algorithm and the parameters do not change between different tests I expect the generated file to be always the same. However, this is not the case. The files that are generated with the output of the OFDM symbol acquisition block differ from each other. But when I send the content of one of those generated files to the rest of the receiver and do this several times, I always get the same transport stream at the output. I have verified this by using a file sink and comparing the files. That’s why I suspect the OFDM symbol acquisition block to be the culprit.

When I was searching the internet for information concerning my problem, I found an email from 2015 in the archive of this mailing list where someone wrote that the OFDM symbol acquisition block of gr-isdbt should be used because it worked better than the one in gr-dvbt. I have done so and installed gr-isdbt from git and replaced the block. However, there are two such blocks in gr-isdbt and none of them solves my problem. They perform even worse than the original block in gr-dvbt and after some time the program terminates without a message.

I hope that my explanations are clear enough.

Is there anybody who can tell me what might be wrong here or what I am doing wrong? Why is

DVB-T receiver problem (OFDM symbol acquisition)

Dear all,

please apologize my long email but I cannot explain my problem and what I have done so far in three words.

I am currently working on a DVB-T receiver project to receive transmissions on 434 MHz with 2 MHz bandwidth or less using GNU Radio and an RTL-SDR stick. The flow graph is based on the examples in gr-dvbt. The transmitter is a HiDes model HV320E. Reception works, but the video stops after one minute or so while the constellation diagram is still active (dots are moving). I am no expert and have only few knowledge of DSP and DVB yet, but to me the problem seems to be in the OFDM symbol acquisition block.

Conditions:
Linux Mint 19.3 in a virtual machine (VMware)
GNU Radio 3.7.11 if I am right (I would need to check at home)

What I have done so far:

I have created a flow graph for a DVB-T receiver based on the examples in gr-dvbt. The signal source is an RTL-SDR stick and the sample rate is 16/7 MHz (= 2.285714 MHz) to get 2 MHz bandwidth. The signal sink is a TCP server sink to which I connect with VLC media player to display the received video transport stream. This works, but after one minute or so the video stops while the constellation diagram is still active (dots are moving). I am currently using QPSK, code rate 3/4 and guard interval 1/8 but I have also tried 16QAM, code rate 1/2 and guard interval 1/8 and have the same problem.

To track down the source of the problem, I have created a file outside of GNU Radio that I can use in a file source instead of the RTL-SDR source of my flow graph. This allows me to make tests with an input signal that does not change between different tests.

The data of this file are sent to the OFDM symbol acquisition block and the output of this block is stored in a second file. When the input signal, the algorithm and the parameters do not change between different tests I expect the generated file to be always the same. However, this is not the case. The files that are generated with the output of the OFDM symbol acquisition block differ from each other. But when I send the content of one of those generated files to the rest of the receiver and do this several times, I always get the same transport stream at the output. I have verified this by using a file sink and comparing the files. That’s why I suspect the OFDM symbol acquisition block to be the culprit.

When I was searching the internet for information concerning my problem, I found an email from 2015 in the archive of this mailing list where someone wrote that the OFDM symbol acquisition block of gr-isdbt should be used because it worked better than the one in gr-dvbt. I have done so and installed gr-isdbt from git and replaced the block. However, there are two such blocks in gr-isdbt and none of them solves my problem. They perform even worse than the original block in gr-dvbt and after some time the program terminates without a message.

I hope that my explanations are clear enough.

Is there anybody who can tell me what might be wrong here or what I am doing wrong? Why is the output of the OFDM symbol acquisition block not always the same when the start condition of every run is the same? Am I missing something here?

Thank you very much for your help.

Kind regards,
Ralf

[Discuss-gnuradio] E100 and HDMI

2011-07-18 Thread Ralf Wierse

Hi,

so far we used our E100s via LAN from Remote.

Now we connected HDMI locally by using an HDMI-to-DVI apapter
and a DELL DVI display.

Nothing is displayed, no boot text, no X output.

X server seems to run on the E100 utilizing OMAPFB...

Should it work by default?
Any hints for us?

Thanks!
Ralf


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] E100 Performance

2011-06-30 Thread Ralf


Am 29.06.2011 16:34, schrieb Marcus D. Leech:

On 29/06/2011 9:11 AM, Ralf wrote:

Hi,

the simple GRC in the attachment creates lots of underflows on our 
E100 (U on console)

and dropouts when looking at the spectrum.

Is this as expected or how can this overload of the embedded Linux be 
avoided?


Thanks,
Ralf
Well, for one, 60Khz isn't a proper divisor of the 128MHz sample rate 
of the DAC, which means it can't be properly interpolated.


The minimum sample rate that you can deliver to the USRP-E100 is 
128MHz/512 = 250kHz, so you'll have to interpolate your

  data stream up to 250kHz prior to presentation to the UHD sink block.



Hi Marcus, thanks for your reply.

That is very important for us to understand. How is the divider 512 
determined? It is in the FPGA I suppose.

Where can read more about the FPGA besides this small text?
http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html#fpga

Can we only put proper divisors of 128MHz in terms of datarate into the 
UHD sink even above 250kHz?


Actually we need to put ~10kbit/s of data onto a ~400kHz carrier. Is the 
GRC repeater the right functionality

to interpolate the small datarate as shown in the attached setup?

Regards,
Ralf
?xml version='1.0' encoding='ASCII'?
flow_graph
  timestampThu Jun 30 11:09:05 2011/timestamp
  block
keyoptions/key
param
  keyid/key
  valuetx/value
/param
param
  key_enabled/key
  valueTrue/value
/param
param
  keytitle/key
  value/value
/param
param
  keyauthor/key
  value/value
/param
param
  keydescription/key
  value/value
/param
param
  keywindow_size/key
  value1280, 1024/value
/param
param
  keygenerate_options/key
  valueqt_gui/value
/param
param
  keycategory/key
  valueCustom/value
/param
param
  keyrun_options/key
  valueprompt/value
/param
param
  keyrun/key
  valueTrue/value
/param
param
  keyrealtime_scheduling/key
  value/value
/param
param
  key_coordinate/key
  value(10, 10)/value
/param
param
  key_rotation/key
  value0/value
/param
  /block
  block
keyblks2_dxpsk_mod/key
param
  keyid/key
  valueblks2_dxpsk_mod_0/value
/param
param
  key_enabled/key
  valueTrue/value
/param
param
  keytype/key
  valuedqpsk/value
/param
param
  keysamples_per_symbol/key
  value4/value
/param
param
  keyexcess_bw/key
  value0.35/value
/param
param
  keygray_code/key
  valueTrue/value
/param
param
  keyverbose/key
  valueFalse/value
/param
param
  keylog/key
  valueFalse/value
/param
param
  key_coordinate/key
  value(313, 259)/value
/param
param
  key_rotation/key
  value0/value
/param
  /block
  block
keyrandom_source_x/key
param
  keyid/key
  valuerandom_source_x_0/value
/param
param
  key_enabled/key
  valueTrue/value
/param
param
  keytype/key
  valuebyte/value
/param
param
  keymin/key
  value0/value
/param
param
  keymax/key
  value255/value
/param
param
  keynum_samps/key
  value10/value
/param
param
  keyrepeat/key
  valueTrue/value
/param
param
  key_coordinate/key
  value(73, 259)/value
/param
param
  key_rotation/key
  value0/value
/param
  /block
  block
keyuhd_usrp_source/key
param
  keyid/key
  valueuhd_usrp_source_0/value
/param
param
  key_enabled/key
  valueTrue/value
/param
param
  keytype/key
  valuecomplex/value
/param
param
  keydev_addr/key
  value/value
/param
param
  keyref_clk/key
  value/value
/param
param
  keysync/key
  value/value
/param
param
  keyclock_rate/key
  value0.0/value
/param
param
  keynum_mboards/key
  value1/value
/param
param
  keysd_spec0/key
  value/value
/param
param
  keysd_spec1/key
  value/value
/param
param
  keysd_spec2/key
  value/value
/param
param
  keysd_spec3/key
  value/value
/param
param
  keynchan/key
  value1/value
/param
param
  keysamp_rate/key
  value100/value
/param
param
  keycenter_freq0/key
  value0/value
/param
param
  keygain0/key
  value0/value
/param
param
  keyant0/key
  value/value
/param
param
  keybw0/key
  value0/value
/param
param
  keycenter_freq1/key
  value0/value
/param
param
  keygain1/key
  value0/value
/param
param
  keyant1/key
  value/value
/param
param
  keybw1/key
  value0/value
/param
param
  keycenter_freq2/key
  value0/value
/param

[Discuss-gnuradio] E100 Performance

2011-06-29 Thread Ralf


Hi,

the simple GRC in the attachment creates lots of underflows on our E100 
(U on console)

and dropouts when looking at the spectrum.

Is this as expected or how can this overload of the embedded Linux be 
avoided?


Thanks,
Ralf
?xml version='1.0' encoding='ASCII'?
flow_graph
  timestampWed Jun 29 14:59:09 2011/timestamp
  block
keyuhd_usrp_sink/key
param
  keyid/key
  valueuhd_usrp_sink_0/value
/param
param
  key_enabled/key
  valueTrue/value
/param
param
  keytype/key
  valuecomplex/value
/param
param
  keydev_addr/key
  value/value
/param
param
  keyref_clk/key
  value/value
/param
param
  keysync/key
  value/value
/param
param
  keyclock_rate/key
  value0.0/value
/param
param
  keynum_mboards/key
  value1/value
/param
param
  keysd_spec0/key
  value:A/value
/param
param
  keysd_spec1/key
  value/value
/param
param
  keysd_spec2/key
  value/value
/param
param
  keysd_spec3/key
  value/value
/param
param
  keynchan/key
  value1/value
/param
param
  keysamp_rate/key
  valuesamp_rate/value
/param
param
  keycenter_freq0/key
  value40/value
/param
param
  keygain0/key
  value3/value
/param
param
  keyant0/key
  value/value
/param
param
  keybw0/key
  value0/value
/param
param
  keycenter_freq1/key
  value0/value
/param
param
  keygain1/key
  value0/value
/param
param
  keyant1/key
  value/value
/param
param
  keybw1/key
  value0/value
/param
param
  keycenter_freq2/key
  value0/value
/param
param
  keygain2/key
  value0/value
/param
param
  keyant2/key
  value/value
/param
param
  keybw2/key
  value0/value
/param
param
  keycenter_freq3/key
  value0/value
/param
param
  keygain3/key
  value0/value
/param
param
  keyant3/key
  value/value
/param
param
  keybw3/key
  value0/value
/param
param
  keycenter_freq4/key
  value0/value
/param
param
  keygain4/key
  value0/value
/param
param
  keyant4/key
  value/value
/param
param
  keybw4/key
  value0/value
/param
param
  keycenter_freq5/key
  value0/value
/param
param
  keygain5/key
  value0/value
/param
param
  keyant5/key
  value/value
/param
param
  keybw5/key
  value0/value
/param
param
  keycenter_freq6/key
  value0/value
/param
param
  keygain6/key
  value0/value
/param
param
  keyant6/key
  value/value
/param
param
  keybw6/key
  value0/value
/param
param
  keycenter_freq7/key
  value0/value
/param
param
  keygain7/key
  value0/value
/param
param
  keyant7/key
  value/value
/param
param
  keybw7/key
  value0/value
/param
param
  keycenter_freq8/key
  value0/value
/param
param
  keygain8/key
  value0/value
/param
param
  keyant8/key
  value/value
/param
param
  keybw8/key
  value0/value
/param
param
  keycenter_freq9/key
  value0/value
/param
param
  keygain9/key
  value0/value
/param
param
  keyant9/key
  value/value
/param
param
  keybw9/key
  value0/value
/param
param
  keycenter_freq10/key
  value0/value
/param
param
  keygain10/key
  value0/value
/param
param
  keyant10/key
  value/value
/param
param
  keybw10/key
  value0/value
/param
param
  keycenter_freq11/key
  value0/value
/param
param
  keygain11/key
  value0/value
/param
param
  keyant11/key
  value/value
/param
param
  keybw11/key
  value0/value
/param
param
  keycenter_freq12/key
  value0/value
/param
param
  keygain12/key
  value0/value
/param
param
  keyant12/key
  value/value
/param
param
  keybw12/key
  value0/value
/param
param
  keycenter_freq13/key
  value0/value
/param
param
  keygain13/key
  value0/value
/param
param
  keyant13/key
  value/value
/param
param
  keybw13/key
  value0/value
/param
param
  keycenter_freq14/key
  value0/value
/param
param
  keygain14/key
  value0/value
/param
param
  keyant14/key
  value/value
/param
param
  keybw14/key
  value0/value
/param
param
  keycenter_freq15/key
  value0/value
/param
param
  keygain15/key
  value0/value
/param
param

[Discuss-gnuradio] DPSK2 Demodulator

2011-06-29 Thread Ralf


Hi,

we are trying to use DPSK2 modulator and demodulator during our first 
trials.

As far as we can see there is hardly any documentation available on this.

We would appreciate a few explaining words from somebody who knows how to
configure the demodulator so that data is correctly received.
What synchronization method(s) is/are included?
Raised-cosine-filter for matched filtering seems to be included?

We tried like this with no success:
Modulator:
Type: DQPSK
Sample/Symbol: 2
Excess BW: 0.35
GrayCode: YES
Verbose: OFF
Logging: OFF

Demodulator:
Sample/Symbol: 2
Excess BW: 0.35
FLL Alpha: 0.01
Phase Alpha: 0.1
Timing Max Dev: 1.5
Omega Relative Limit: 0.005
GrayCode: YES
Verbose: OFF
Logging: OFF
Sync Out: ON

Thanks in advance!
Ralf


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] E100 - No devices found for -----

2011-06-28 Thread Ralf


Hi Josh,

today we managed to make UHD sink and source work in parallel on E100 
using FPGA5.bin

by building UHD like this:

git clone git://code.ettus.com/ettus/uhd.git
cd uhd
git pull git://code.ettus.com/ettus/uhd.git next
cd host/
$ mkdir build
$ cd build
$ cmake -DCMAKE_CXX_FLAGS:STRING=-mcpu=cortex-a8 -mfpu=neon
-mfloat-abi=softfp -g -DENABLE_USRP_E100=TRUE -DENABLE_USRP_E_UTILS=TRUE -i
../
$ make
$ make test
$ make install
$ ldconfig

Please bear in mind that we are absolute beginners to Gnuradio and E100. 
We started one week ago.

Some more precise information really helps!!
However, your help is appreciated!

Thanks,
Ralf


Am 27.06.2011 18:50, schrieb Josh Blum:

we don't manage wih the E100 FPGA5 bitstream.
It is placed in the images directory and we use a new branch but we
don't really think the FPGA5 is used.

What do you mean?


And we still have the same problem with parallel UHD devices (sink/source).


Another guy confirmed it was working for him just fine.

In any case, I think it will also work if you patch this onto the master
branch (very small change): http://pastebin.com/JinMRTTD


Which branch shall we use? Can you pinpoint exactly?
Shall we use the Josh branch from http://gnuradio.org/cgit ?


For gnuradio? The master branch on gnuradio.org is fine.


Do you have images available? We still don't have a cross-compile env. yet.
Hence compilation takes very long time...


Yes :-)

http://code.ettus.com/redmine/ettus/projects/usrpe1xx/wiki/Experimental_Images


Another topic we recognized on E100 is that we suspect incomplete datastreams
when the Gumstix is overloaded performancewise. I will come back with details
on our transmitter setup which might cause overloads.
But - is it possible to overload the 720MHz Gumstix easily? What happens in
this case - samples are discarded?


On receive, the host backpressures the FPGA. See
http://www.ettus.com/uhd_docs/manual/html/general.html#overflow-underflow-notes

-Josh




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] E100 - No devices found for -----

2011-06-27 Thread Ralf Wierse

 -Original Message-
 From: discuss-gnuradio-bounces+r.wierse=brunel...@gnu.org 
 [mailto:discuss-gnuradio-bounces+r.wierse=brunel...@gnu.org] 
 On Behalf Of Josh Blum
 Sent: Thursday, June 23, 2011 5:35 PM
 To: discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] E100 - No devices found for -

 On 06/23/2011 03:16 AM, Ralf Wierse wrote:
  OK, first simple reason discovered.
  UHD can only be used for one device - either UHD_usrp_sink 
 or source.

  How can UHD be used for both devices in parallel?

 Sorry, Its a known bug related to opening twice. Its fixed on the next
 branch. Solution w/ instructions:
 http://comments.gmane.org/gmane.comp.hardware.usrp.e100/754

 -Josh

Hi Josh,

we don't manage wih the E100 FPGA5 bitstream.
It is placed in the images directory and we use a new branch but we 
don't really think the FPGA5 is used.
And we still have the same problem with parallel UHD devices (sink/source).

Which branch shall we use? Can you pinpoint exactly?
Shall we use the Josh branch from http://gnuradio.org/cgit ?

Do you have images available? We still don't have a cross-compile env. yet.
Hence compilation takes very long time...

Another topic we recognized on E100 is that we suspect incomplete datastreams
when the Gumstix is overloaded performancewise. I will come back with details
on our transmitter setup which might cause overloads.
But - is it possible to overload the 720MHz Gumstix easily? What happens in
this case - samples are discarded?

Regards,
Ralf

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] E100 - No devices found for -----

2011-06-24 Thread Ralf Wierse

 -Original Message-
 From: Jason Abele [mailto:ja...@ettus.com] 
 Sent: Thursday, June 23, 2011 5:29 PM
 To: Ralf Wierse
 Cc: discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] E100 - No devices found for -
 
 
 On Thu, Jun 23, 2011 at 5:32 AM, Ralf Wierse 
 r.wie...@brunel.de wrote:
  -Original Message-
  From: Jason Abele [mailto:ja...@ettus.com]
  Sent: Thursday, June 23, 2011 1:04 PM
  To: Ralf Wierse
  Cc: discuss-gnuradio Discussion Group
  Subject: Re: [Discuss-gnuradio] E100 - No devices found for -
 
 
  On Thu, Jun 23, 2011 at 3:16 AM, Ralf Wierse
  r.wie...@brunel.de wrote:
   OK, first simple reason discovered.
   UHD can only be used for one device - either UHD_usrp_sink
  or source.
  
   How can UHD be used for both devices in parallel?
 
  You have to access both source and sink from the same process, but
  then it is possible to use both at the same time.
 
  Jason
 
 
  Hi Jason,
  thanks but I am a little confused.
  I would say it is in the same process since I have sink and 
 source in the same
  GRC setup. The failure shows up when the generated python 
 script instantiates an
  UHD devices the second time as far as I understand.
  Is there any combined UHD_usrp_sink/source block for GRC or 
 how is this to
  be done practically?
 
 Can you send the simplest .grc file which causes this issue?
 
 Jason


Hi Jason,

Josh wrote to use the latest branch. This one is still building since
we don't have any cross compile environment yet...

However, attached is a GRC setup which fails due to parallel use
of two UHD devices. Well, this is very simple.

Hope the parallel issue is fixed using the latest branch. If not, we
appreciate more support.

Regards,
Ralf


parallel.py
Description: Binary data


parallel.grc
Description: Binary data
 Welcome to GNU Radio Companion  

Loading: /home/root/spec_analyzer.grc
 Done

Showing: /home/root/spec_analyzer.grc

Loading: /home/root/audio_test.grc
 Done

Loading: /home/root/simple.grc
 Done

Loading: /home/root/examples/grc/usrp/usrp_rx_dpsk.grc
 Done

Loading: /home/root/test.grc
 Done

Loading: /home/root/test2.grc
 Done

Loading: /home/root/sender2.grc
 Done

Showing: /home/root/sender2.grc

Showing: 

Showing: /home/root/simple.grc

Showing: /home/root/test.grc

Showing: /home/root/sender2.grc

Showing: 

Generating: /mnt/UHD-Mirror/host/parallel.py

Executing: /mnt/UHD-Mirror/host/parallel.py


 Done

Generating: /mnt/UHD-Mirror/host/parallel.py

Executing: /mnt/UHD-Mirror/host/parallel.py

linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500; 
UHD_003.000.001-

QIconvCodec::convertFromUnicode: using Latin-1 for conversion, iconv failed for 
BOM: Bad file descriptor
QIconvCodec::convertFromUnicode: using Latin-1 for conversion, iconv_open failed
QIconvCodec::convertToUnicode: using Latin-1 for conversion, iconv_open failed
Opening USRP-E on /dev/usrp_e0
USRP-E100 clock control: 6
  r_counter: 1
  a_counter: 0
  b_counter: 12
  prescaler: 8
  vco_divider: 2
  chan_divider: 15
  vco_rate: 1920.00MHz
  chan_rate: 960.00MHz
  out_rate: 64.00MHz


Warning:
Ignoring discovered device
EnvironmentError: IOError: Failed to open /dev/usrp_e0
Traceback (most recent call last):
  File /mnt/UHD-Mirror/host/parallel.py, line 89, in module
tb = parallel()
  File /mnt/UHD-Mirror/host/parallel.py, line 49, in __init__
num_channels=1,
  File /usr/local/lib/python2.6/site-packages/gnuradio/uhd/__init__.py, line 
74, in constructor_interceptor
return old_constructor(*args, **kwargs)
  File /usr/local/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py, line 
1854, in usrp_sink
return _uhd_swig.usrp_sink(*args, **kwargs)
RuntimeError: LookupError: KeyError: No devices found for -
Empty Device Address

 Done

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] E100 - No devices found for -----

Hi all,

we are new with E100.

we managed to use UHD:USRP_Source without further configuration and display
it on QT_GUI_SINK.

we don't manage with UHD:USRP_Sink without further configuration:

File /usr/local/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py, line 
1854, in usrp_sink
return _uhd_swig.usrp_sink(*args, **kwargs)
RuntimeError: LookupError: KeyError: No devices found for -
Empty Device Address

How to configure the sink address?

Any help appreciated!
thanks!
Ralf

uhd_usrp_probe output:

linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500; 
UHD_003.000.001-

Opening USRP-E on /dev/usrp_e0
Loading FPGA image: /usr/share/uhd/images/usrp_e100_fpga.bin... done = 1
Configuration complete.
re-Opening USRP-E on /dev/usrp_e0
USRP-E100 clock control: 6
  r_counter: 1
  a_counter: 0
  b_counter: 12
  prescaler: 8
  vco_divider: 2
  chan_divider: 15
  vco_rate: 1920.00MHz
  chan_rate: 960.00MHz
  out_rate: 64.00MHz

  _
 /
|   Device: usrp-e device
| _
|/
|   |   Mboard: usrp-e mboard
|   |   vendor: 3
|   |   device: 1
|   |   revision: 3
|   |   content: 0
|   |   model: E100
|   |   serial: EAR10ZFE1
|   | _
|   |/
|   |   |   RX DSP: usrp-e ddc0
|   |   |   Codec Rate: 64.00 Msps
|   | _
|   |/
|   |   |   TX DSP: usrp-e duc0
|   |   |   Codec Rate: 64.00 Msps
|   | _
|   |/
|   |   |   RX Dboard: usrp-e dboard (rx unit)
|   |   | _
|   |   |/
|   |   |   |   RX Subdev: LF RX (0x000f) - AB
|   |   |   |   Antennas: 
|   |   |   |   Freq range: -32.000 to 32.000 Mhz
|   |   |   |   Gain Elements: None
|   |   |   |   Connection Type: C
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Subdev: LF RX (0x000f) - BA
|   |   |   |   Antennas: 
|   |   |   |   Freq range: -32.000 to 32.000 Mhz
|   |   |   |   Gain Elements: None
|   |   |   |   Connection Type: c
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Subdev: LF RX (0x000f) - A
|   |   |   |   Antennas: 
|   |   |   |   Freq range: -32.000 to 32.000 Mhz
|   |   |   |   Gain Elements: None
|   |   |   |   Connection Type: R
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Subdev: LF RX (0x000f) - B
|   |   |   |   Antennas: 
|   |   |   |   Freq range: -32.000 to 32.000 Mhz
|   |   |   |   Gain Elements: None
|   |   |   |   Connection Type: r
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Codec: usrp-e adc - ad9522
|   |   |   |   Gain range ad9862 pga: 0.0 to 20.0 step 1.0 dB
|   | _
|   |/
|   |   |   TX Dboard: usrp-e dboard (tx unit)
|   |   | _
|   |   |/
|   |   |   |   TX Subdev: LF TX (0x000e) - AB
|   |   |   |   Antennas: 
|   |   |   |   Freq range: -32.000 to 32.000 Mhz
|   |   |   |   Gain Elements: None
|   |   |   |   Connection Type: C
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   TX Subdev: LF TX (0x000e) - BA
|   |   |   |   Antennas: 
|   |   |   |   Freq range: -32.000 to 32.000 Mhz
|   |   |   |   Gain Elements: None
|   |   |   |   Connection Type: c
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   TX Subdev: LF TX (0x000e) - A
|   |   |   |   Antennas: 
|   |   |   |   Freq range: -32.000 to 32.000 Mhz
|   |   |   |   Gain Elements: None
|   |   |   |   Connection Type: R
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   TX Subdev: LF TX (0x000e) - B
|   |   |   |   Antennas: 
|   |   |   |   Freq range: -32.000 to 32.000 Mhz
|   |   |   |   Gain Elements: None
|   |   |   |   Connection Type: r
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   TX Codec: usrp-e dac - ad9522
|   |   |   |   Gain range ad9862 pga: -20.0 to 0.0 step 0.1 dB
 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] E100 - No devices found for -----

OK, first simple reason discovered.
UHD can only be used for one device - either UHD_usrp_sink or source.

How can UHD be used for both devices in parallel?

Thanks,
Ralf

 -Original Message-
 From: discuss-gnuradio-bounces+r.wierse=brunel...@gnu.org 
 [mailto:discuss-gnuradio-bounces+r.wierse=brunel...@gnu.org] 
 On Behalf Of Ralf Wierse
 Sent: Thursday, June 23, 2011 10:29 AM
 To: 'discuss-gnuradio Discussion Group'
 Subject: [Discuss-gnuradio] E100 - No devices found for -
 
 
 Hi all,
 
 we are new with E100.
 
 we managed to use UHD:USRP_Source without further 
 configuration and display
 it on QT_GUI_SINK.
 
 we don't manage with UHD:USRP_Sink without further configuration:
 
 File 
 /usr/local/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.
 py, line 1854, in usrp_sink
 return _uhd_swig.usrp_sink(*args, **kwargs)
 RuntimeError: LookupError: KeyError: No devices found for -
 Empty Device Address
 
 How to configure the sink address?
 
 Any help appreciated!
 thanks!
 Ralf
 
 uhd_usrp_probe output:
 
 linux; GNU C++ version 4.5.3 20110311 (prerelease); 
 Boost_104500; UHD_003.000.001-
 
 Opening USRP-E on /dev/usrp_e0
 Loading FPGA image: 
 /usr/share/uhd/images/usrp_e100_fpga.bin... done = 1
 Configuration complete.
 re-Opening USRP-E on /dev/usrp_e0
 USRP-E100 clock control: 6
   r_counter: 1
   a_counter: 0
   b_counter: 12
   prescaler: 8
   vco_divider: 2
   chan_divider: 15
   vco_rate: 1920.00MHz
   chan_rate: 960.00MHz
   out_rate: 64.00MHz
 
   _
  /
 |   Device: usrp-e device
 | _
 |/
 |   |   Mboard: usrp-e mboard
 |   |   vendor: 3
 |   |   device: 1
 |   |   revision: 3
 |   |   content: 0
 |   |   model: E100
 |   |   serial: EAR10ZFE1
 |   | _
 |   |/
 |   |   |   RX DSP: usrp-e ddc0
 |   |   |   Codec Rate: 64.00 Msps
 |   | _
 |   |/
 |   |   |   TX DSP: usrp-e duc0
 |   |   |   Codec Rate: 64.00 Msps
 |   | _
 |   |/
 |   |   |   RX Dboard: usrp-e dboard (rx unit)
 |   |   | _
 |   |   |/
 |   |   |   |   RX Subdev: LF RX (0x000f) - AB
 |   |   |   |   Antennas: 
 |   |   |   |   Freq range: -32.000 to 32.000 Mhz
 |   |   |   |   Gain Elements: None
 |   |   |   |   Connection Type: C
 |   |   |   |   Uses LO offset: No
 |   |   | _
 |   |   |/
 |   |   |   |   RX Subdev: LF RX (0x000f) - BA
 |   |   |   |   Antennas: 
 |   |   |   |   Freq range: -32.000 to 32.000 Mhz
 |   |   |   |   Gain Elements: None
 |   |   |   |   Connection Type: c
 |   |   |   |   Uses LO offset: No
 |   |   | _
 |   |   |/
 |   |   |   |   RX Subdev: LF RX (0x000f) - A
 |   |   |   |   Antennas: 
 |   |   |   |   Freq range: -32.000 to 32.000 Mhz
 |   |   |   |   Gain Elements: None
 |   |   |   |   Connection Type: R
 |   |   |   |   Uses LO offset: No
 |   |   | _
 |   |   |/
 |   |   |   |   RX Subdev: LF RX (0x000f) - B
 |   |   |   |   Antennas: 
 |   |   |   |   Freq range: -32.000 to 32.000 Mhz
 |   |   |   |   Gain Elements: None
 |   |   |   |   Connection Type: r
 |   |   |   |   Uses LO offset: No
 |   |   | _
 |   |   |/
 |   |   |   |   RX Codec: usrp-e adc - ad9522
 |   |   |   |   Gain range ad9862 pga: 0.0 to 20.0 step 1.0 dB
 |   | _
 |   |/
 |   |   |   TX Dboard: usrp-e dboard (tx unit)
 |   |   | _
 |   |   |/
 |   |   |   |   TX Subdev: LF TX (0x000e) - AB
 |   |   |   |   Antennas: 
 |   |   |   |   Freq range: -32.000 to 32.000 Mhz
 |   |   |   |   Gain Elements: None
 |   |   |   |   Connection Type: C
 |   |   |   |   Uses LO offset: No
 |   |   | _
 |   |   |/
 |   |   |   |   TX Subdev: LF TX (0x000e) - BA
 |   |   |   |   Antennas: 
 |   |   |   |   Freq range: -32.000 to 32.000 Mhz
 |   |   |   |   Gain Elements: None
 |   |   |   |   Connection Type: c
 |   |   |   |   Uses LO offset: No
 |   |   | _
 |   |   |/
 |   |   |   |   TX Subdev: LF TX (0x000e) - A
 |   |   |   |   Antennas: 
 |   |   |   |   Freq range: -32.000 to 32.000 Mhz
 |   |   |   |   Gain Elements: None
 |   |   |   |   Connection Type: R
 |   |   |   |   Uses LO offset: No
 |   |   | _
 |   |   |/
 |   |   |   |   TX Subdev

Re: [Discuss-gnuradio] E100 - No devices found for -----

 -Original Message-
 From: Jason Abele [mailto:ja...@ettus.com] 
 Sent: Thursday, June 23, 2011 1:04 PM
 To: Ralf Wierse
 Cc: discuss-gnuradio Discussion Group
 Subject: Re: [Discuss-gnuradio] E100 - No devices found for -

 On Thu, Jun 23, 2011 at 3:16 AM, Ralf Wierse 
 r.wie...@brunel.de wrote:
  OK, first simple reason discovered.
  UHD can only be used for one device - either UHD_usrp_sink 
 or source.

  How can UHD be used for both devices in parallel?

 You have to access both source and sink from the same process, but
 then it is possible to use both at the same time.

 Jason

Hi Jason,
thanks but I am a little confused.
I would say it is in the same process since I have sink and source in the same
GRC setup. The failure shows up when the generated python script instantiates an
UHD devices the second time as far as I understand.
Is there any combined UHD_usrp_sink/source block for GRC or how is this to 
be done practically?

Thanks
Ralf

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] E100 - No devices found for -----