FDM reception and TPS decoding is OK, what could cause the
reception "freeze"? Any idea?
As far as GNU Radio and DSP is concerned, I consider myself still as a
beginner, so please don't assume too much knowledge on my part :-)
Thank you very much for your help!
Kind regards,
Ralf, DL5EU
Hello Ron,
thank you very much.
I have walked right into the trap a second time :-( I should attach a
Post-It to my monitor screen to remind me that I might need to adapt the
CMakeLists.txt files when I change something...
Long story short, it works now :-)
Regards,
Ralf
Am 29.01.2022 um 23
ed the relevant code from the old to the new version.
Thank you very much and kind regards,
Ralf
ps somebody has some time to take a
look at it?
Thank you very much for your help!
Kind regards,
Ralf
<>
. from positive to negative values).
2) The value at the samp. error output is zero and constant (at least I
have seen no change during about 30 minutes).
Is this the correct behaviour? If not, how should it be?
Thank you very much for your help and kind regards,
Ralf
Am 11.12.2021 um 16:11 schrieb
as I know, in DVB-T the
carriers at the borders are all set to zero (and perhaps the one in the
middle too). Perhaps this would be too simple to be true :-)
Regards,
Ralf
Am 10.12.2021 um 14:41 schrieb Ralf Gorholt:
Hi Federico,
indeed, the "symbol_index" tag that is normally sent for
(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
e 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
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
o 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
<>
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 Fed
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
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
_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
.
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=...&qu
k you very much.
Kind regards,
Ralf
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
categor
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
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
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
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
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 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 <h
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* r
.
Thank you very much and happy easter!
Kind regards,
Ralf
ld 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
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
, 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
.
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
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
. 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
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"
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)
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
.
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 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
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
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
!
Ralf
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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
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
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
!!
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
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
-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
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
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
-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
-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
answers from the US or elsewhere as well.
For number 2) above it is not absotuley necessary to create the hardware.
Design and component selection would help as well.
If you are interested please contact me directly and we can talk about
details.
Best regards,
Ralf
I don't really dare to type any
50 matches
Mail list logo