Hi Federico,

thank you very much for the hint and the link. I have not looked at cour
code yet but I will do that.

What you describe is the reason why I had added TPP_DONT to my copy of
GNU Radio's Viterbi Decoder. Unfortunately, when I do this (and only
this), if I remember correctly only the first synchronization works.
Perhaps things become clearer when I see what you have done in your code.

Regards,

Ralf

Am 20.02.2025 um 19:45 schrieb Federico 'Larroca' La Rocca:
Hi Ralf,

Since the Viterbi Decoder has to wait for a tag to start (and is thus
a general block), I've used TPP_DONT as its tag propagation policy.
Furthermore, we also send a tag whenever a new frame begins under
"normal operation" (see
https://github.com/git-artes/gr-isdbt/blob/56b2556c14ecc5d710070f969fda7a2deae65d8b/lib/viterbi_decoder_impl.cc#L815).


I've checked
https://github.com/gnuradio/gnuradio/blob/main/gr-dtv/lib/dvbt/dvbt_viterbi_decoder_impl.cc
and it seems that GNU Radio's current code does not proceed similarly.
Maybe that's the problem?

best

El jue, 20 feb 2025 a las 5:30, Ralf Gorholt (<ralf.gorh...@gmx.de>)
escribió:

    Hi Federico,

    I can imagine that you are very busy, so don't worry :-)

    In most cases reception is fine. However, I have noticed
    difficulties (already in the past) that are not related to the
    recognition of the OFDM symbols. It might be that I have now found
    the reason why but I don't know GNU Radio well enough yet. Perhaps
    you or somebody else knows someone who could help me? Let me
    explain the problem in a few words.

    The Viterbi Decoder needs the "superframe_start" tag to start
    decoding. When it detects a superframe start, it creates this tag
    again (although it should to my knowledge be propagated to the
    downstream blocks by default). The next block in the chain, the
    Convolutional Deinterleaver, also needs this signal. That's where
    the problem arises.

    Sometimes it happens that the Convolutional Deinterleaver gets a
    "superframe_start" somewhere in the middle when there is no start
    of a superframe (I have been able to trace this using Tag Debug
    blocks). That causes the reception to freeze immediately. When I
    provoke a complete reset then (e.g. by changing the frequency back
    and forth), a re-synchronization of all blocks is triggered and
    everything is fine again. Unfortunately, when I change the tag
    propagation policy to TPP_DONT in the Viterbi Decoder, only the
    first synchronization works (at offset 0).

    Of course I can open a bug report for GNU Radio, but in this case
    I would prefer being able to present a solution (if possible).
    This is a very special case that is difficult to reproduce and
    trace because it can happen after some seconds or even hours. I
    also doubt that many users use GNU Radio for DVB-T reception. It
    might be only some friends of mine and me who would like to do
    this in Amateur Radio.

    Kind regards,

    Ralf

    Am 19.02.2025 um 21:30 schrieb Federico 'Larroca' La Rocca:
    Hi Ralf,

    It's great to see that our work is useful and you're willing to
    undertake its migration to DVB-T. Sadly, I'm afraid I won't have
    time to check the code. However, if you're still receiving a nice
    constellation after a sampling error rate (using a channel model)
    the code should be just fine.

    BTW, what would make me very happy is to migrate the whole
    gr-isdbt into the core of GNU Radio, if that's interesting for
    the project. I'm not sure how to proceed if we were to undertake
    this migration. Maybe someone on the list can provide me with
    pointers?

    best
    Federico


    El jue, 6 feb 2025 a las 18:09, Ralf Gorholt
    (<ralf.gorh...@gmx.de>) escribió:

        Dear all,

        I have just released a very first version of the source code
        of my OOT
        module gr-dl5eu. This is the first time that I publish my
        work, so
        please forgive me if it does not correspond to or if I have not
        respected all written or unwritten rules ;-)

        This module contains two blocks, dvbt_ofdm_synchronization and
        dvbt_tps_decoder. They are based on two blocks that Federico
        La Rocca
        has developed for ISDB-T.

        gr-dl5eu is work under development and I encourage
        particularly radio
        amateurs who are interested in DVB-T reception with GNU Radio
        to test
        them. There is no documentation yet, but there are comments
        in the code.

        Here is just a short description of what the blocks do.

        The first block, dvbt_ofdm_synchronization, recognizes the
        OFDM symbols
        of a DVB-T signal and delivers them to the second block.
        Sampling rate
        differences between the transmitter and receiver are
        interpolated so
        that reception should be stable (at least when the received
        signal is
        stable).

        The second block, dvbt_tps_decoder, decodes the TPS
        information that is
        transmitted within the DVB-T signal and outputs the payload
        carriers
        (that are fed into the block DVB-T Demap). dvbt_tps_decoder
        can send
        messages containing the detected signal parameters to other
        blocks.

        You will find two simple sample flowgraphs in the examples
        directory.

        Please note that I am no DSP guy and that I actually haven't
        fully
        understood how the blocks work exactly. I had to copy parts
        of the code
        from the GNU Radio tree because it was either inaccessible or
        needed
        some modifications.

        The reason why I have developed these blocks is that friends
        of mine are
        looking for a simple and cheap solution for DVB-T reception
        with low
        bandwidth in amateur radio, However, I would be happy if
        others also
        find my work useful.

        Federico, when you have the time, would you take a look at my
        code?
        Without your work I would not have been able to create my blocks!

        Kind regards,

        Ralf


Reply via email to