date:20200302

Packet encoder-decoder cannot be found

2020-03-02 Thread Ahmet DEMIR

Hi,
I want to simulate a video transmitter-receiver and want to use packet
encoder and decoder. I set up the last version of gnuradio which is
gnuradio 3.8.1.0. But I cannot find these blocks. Can you help me please?

Re: Packet encoder-decoder cannot be found

2020-03-02 Thread CEL

Dear Ahmet,

they were buggy (randomly dropped data), i.e. they never fully worked,
couldn't be fixed, were explicitly in the "deprecated" category for
multiple years on GNU Radio 3.7 and then finally removed in GNU Radio
3.8.

So, you need to replace them with something else. GNU Radio comes with
examples (typically, installed to /usr/share/gnuradio/examples), and in
the digital/packet directory you'll find some approaches.

Best regards,
Marcus

On Mon, 2020-03-02 at 14:16 +0300, Ahmet DEMIR wrote:
> Hi,
> I want to simulate a video transmitter-receiver and want to use packet 
> encoder and decoder. I set up the last version of gnuradio which is gnuradio 
> 3.8.1.0. But I cannot find these blocks. Can you help me please?

smime.p7s
Description: S/MIME cryptographic signature

DVB-T receiver problem (OFDM symbol acquisition)

2020-03-02 Thread Ralf Gorholt

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: Packet encoder-decoder cannot be found

2020-03-02 Thread Ahmet DEMIR

Thank you very much.

Müller, Marcus (CEL) , 2 Mar 2020 Pzt, 14:58 tarihinde
şunu yazdı:

> Dear Ahmet,
>
> they were buggy (randomly dropped data), i.e. they never fully worked,
> couldn't be fixed, were explicitly in the "deprecated" category for
> multiple years on GNU Radio 3.7 and then finally removed in GNU Radio
> 3.8.
>
> So, you need to replace them with something else. GNU Radio comes with
> examples (typically, installed to /usr/share/gnuradio/examples), and in
> the digital/packet directory you'll find some approaches.
>
> Best regards,
> Marcus
>
> On Mon, 2020-03-02 at 14:16 +0300, Ahmet DEMIR wrote:
> > Hi,
> > I want to simulate a video transmitter-receiver and want to use packet
> encoder and decoder. I set up the last version of gnuradio which is
> gnuradio 3.8.1.0. But I cannot find these blocks. Can you help me please?
>

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

2020-03-02 Thread 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-02 Thread CEL

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 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


smime.p7s
Description: S/MIME cryptographic signature

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

2020-03-02 Thread Federico 'Larroca' La Rocca

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 () 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 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-02 Thread Ralf Gorholt

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.

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 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 o

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

2020-03-02 Thread Ron Economos

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

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 info

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

2020-03-02 Thread Federico 'Larroca' La Rocca

Ron,
Let me know if I can be of any help. I've been wanting to port the whole
project and integrate it to GNU Radio for a some years by now, but I just
can't find the time. Maybe it would make a GSoC project? Or it's too late
by now?
best
Federico

El lun., 2 mar. 2020 a las 10:56, Ron Economos ()
escribió:

> 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.
>
> 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

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

2020-03-02 Thread Ralf Gorholt

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 from 2015 in the archive of this mailing list where someone wrote that the OFDM symbol acq

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

2020-03-02 Thread Ron Economos

For over the air, the start condition can be different depending on 
exactly where in the OFDM symbol the receiver starts capturing. When you 
get the debug block working, you'll see it.

Ron

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

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. T

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

2020-03-02 Thread Ralf Gorholt

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 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.

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:

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

2020-03-02 Thread CEL

Never too late, just put it on the Ideas List wiki page
On Mon, 2020-03-02 at 10:38 -0300, Federico 'Larroca' La Rocca wrote:
> Ron, 
> Let me know if I can be of any help. I've been wanting to port the whole 
> project and integrate it to GNU Radio for a some years by now, but I just 
> can't find the time. Maybe it would make a GSoC project? Or it's too late by 
> now?
> best
> Federico
> 
> El lun., 2 mar. 2020 a las 10:56, Ron Economos () escribió:
> > 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 fi

clock-recovery MM block

2020-03-02 Thread Kristoff


Hi,


Playing with GNU-radio again.


Short question:
Does somebody have a simple (not to mathematical) explanation what the 
parameters of the "clock-recovery MM" block actually do?
I've just used this block with these values to create a RTTY-decoder of 
the DWD at 147.3 KHz (which seams to work OK) but I do like to have at 
least some idea of what exactly I am doing :-)



The default parameters when you create the block in GRC seams to be:

Omega: samples_per_symbol
Gain Omega: 0.25*0.175*0.175
Mu: 0.5
Gain Mu: 0.175
Omega Relative Limit: 0.005


How can I interpret these values?




Thanks in advance!

Kr.

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

2020-03-02 Thread Ralf Gorholt

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(&peak_index, &datain[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 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:

Weird behaviour of the analog signal source (was: Re: How ensure consistency with timing signals)

2020-03-02 Thread Lukas Haase

Hi Marcus,

How can (or better: *should*) a fully digital signal source have phase noise?

Also, for 1Hz at 5MSps I always get either 5005789 or 5005790 samples (instead 
of 500) ... this is fairly deterministic.

Experimenting a bit, I see the weirdest behaviour of the analog signal source.
In my opinion, the source should be fully deterministic. But it is not.

Example 1: I pipe the output of the signal source into a file:

https://snipboard.io/xY1JvE.jpg

and read it with MATLAB:

data = read_float_binary('baszmeg.dat');

Then I compare it to an ideal (=expected) version:

t = 0:1/fs:(length(data)-1)/fs;
plot(t, [data - sin(2*pi*t)' ])

https://snipboard.io/ecTaFL.jpg

Now, I would not care too much about a constant phase shift or similar, but it 
can be seen that the frequency slowly drifts (this is also seen if I just plot 
them on top of each other).

Example 2: I extend the block diagram with blocks that should never alter the 
behaviour as they are only reading samples:

https://snipboard.io/W6kyF0.jpg

Note that the "Controller" is a simple Embedded Python block that only reads 
the input samples into a temporary variable:

def work(self, input_items, output_items):
squared_wave = input_items[0]
squared_wave[np.where(input_items[0] > 0)] = 1
output_items[0][:] = input_items[0]
return len(output_items[0])

However, now the saved data is distorted:

https://snipboard.io/amyn3X.jpg

Any suggestions highly appreciated.

Thanks,
Lukas

> Gesendet: Mittwoch, 26. Februar 2020 um 16:39 Uhr
> Von: "Marcus D. Leech" 
> An: "Lukas Haase" 
> Cc: "discuss-gnuradio@gnu.org" 
> Betreff: Re: How ensure consistency with timing signals
>
> On 02/26/2020 04:11 PM, Lukas Haase wrote:
> > Hi Marcus,
> >
> > Good point; but this is just for demonstration purposes here. I can tie it 
> > to USRP Source/Sink.
> >
> > The delta (measured in samples) should still be consistent, no matter what.
> >
> > Best, Lukas
> >
> >
> Looking at the siggen code, this is probably equivalent to phase-noise
> in the generator.  The square wave outputs are derived from COS/SIN, and
>at such a high ratio between sample rate and frequency, there'll be a
> bit of phase noise.
>
> Someone with more knowledge of the siggen block can comment further.
>
>
>

Re: Weird behaviour of the analog signal source

2020-03-02 Thread Marcus D. Leech


On 03/02/2020 04:45 PM, Lukas Haase wrote:

Hi Marcus,

How can (or better: *should*) a fully digital signal source have phase noise?

Also, for 1Hz at 5MSps I always get either 5005789 or 5005790 samples (instead 
of 500) ... this is fairly deterministic.

Experimenting a bit, I see the weirdest behaviour of the analog signal source.
In my opinion, the source should be fully deterministic. But it is not.

Example 1: I pipe the output of the signal source into a file:

https://snipboard.io/xY1JvE.jpg

and read it with MATLAB:

data = read_float_binary('baszmeg.dat');

Then I compare it to an ideal (=expected) version:

t = 0:1/fs:(length(data)-1)/fs;
plot(t, [data - sin(2*pi*t)' ])

https://snipboard.io/ecTaFL.jpg

Now, I would not care too much about a constant phase shift or similar, but it 
can be seen that the frequency slowly drifts (this is also seen if I just plot 
them on top of each other).

Example 2: I extend the block diagram with blocks that should never alter the 
behaviour as they are only reading samples:

https://snipboard.io/W6kyF0.jpg

Note that the "Controller" is a simple Embedded Python block that only reads 
the input samples into a temporary variable:

def work(self, input_items, output_items):
 squared_wave = input_items[0]
 squared_wave[np.where(input_items[0] > 0)] = 1
 output_items[0][:] = input_items[0]
 return len(output_items[0])

However, now the saved data is distorted:

https://snipboard.io/amyn3X.jpg


Any suggestions highly appreciated.

Thanks,
Lukas


Someone with more insight into the guts of the signal source needs to 
comment here.


It looks like it moves back-and-forth between integer and floating-point 
representations, and doing so, finite-precision problems can easily

  creep in.  But that's just an educated guess on my part.

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

2020-03-02 Thread 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:

volk_32f_index_max_16u(&peak_index, &datain[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 la

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

2020-03-02 Thread Ralf Gorholt

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"
An: "Ron Economos"
Cc: "GNURadio Discussion List"
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 () 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.

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 hope that my expla

Packet encoder-decoder cannot be found

Re: Packet encoder-decoder cannot be found

DVB-T receiver problem (OFDM symbol acquisition)

Re: Packet encoder-decoder cannot be found

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

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

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

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

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

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

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

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

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

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

clock-recovery MM block

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

Weird behaviour of the analog signal source (was: Re: How ensure consistency with timing signals)

Re: Weird behaviour of the analog signal source

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

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

20 matches

Site Navigation

Mail list logo

Footer information