discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On data formats in GR coding layer


From: Ron Economos
Subject: Re: On data formats in GR coding layer
Date: Tue, 12 May 2020 04:34:05 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

It's just a design choice made in the original code (1). It avoids unpacking and repacking code in every block. Also, the LDPC and BCH blocks were not really meant to used stand-alone, only as part of a complete DVB-S2 or DVB-T2 transmitter flow graph (which inputs standard MPEG-2 Transport Streams).

If you have already existing data in some other format, you can use the built-in Byte Operators blocks (Packed to Unpacked, Pack K Bits, Repack Bits, Unpacked to Packed and Unpack K Bits) to convert back and forth.

Ron

(1) https://github.com/G4GUO/datvexpress_gui

On 5/12/20 03:13, Marko Galenic wrote:
Hi guys,

I have some feedback regarding data i/o formats in your coders, specifically DVB-S2 LDPC and BCH. Played around with it for a while when reading the theory of their construction and noticed that you are using bit-per-byte format instead of densely packed bits.

Why should a consumer and a user of your API be concerned about intrinsic esoteric data formats, i.e. if I give a binary bit stream, I expect Encoder block to give me encoded binary dump instead of first manually converting it to LSB's and then back to densely packed stream.

Unfortunately, to the best of my knowledge, it doesn't work this way currently.

Would be very grateful if you have some free time to answer.

KR,

Marko



reply via email to

[Prev in Thread] Current Thread [Next in Thread]