discuss-gnuradio
[Top][All Lists]
Advanced

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

[Discuss-gnuradio] OFDM / softcast / rate distortion theory (was:Re: OFD


From: Marcus Müller
Subject: [Discuss-gnuradio] OFDM / softcast / rate distortion theory (was:Re: OFDM_TX_RX)
Date: Sat, 25 May 2019 23:06:16 +0200
User-agent: Evolution 3.30.4 (3.30.4-1.fc29)

As said, I doubt that omitting channel coding is a good idea, but OK,
you do the math. 

In any case, when you really don't want channel coding and symbol
mapping, and none of the header structure the OFDM blocks offer, you'll
simply be best off writing your own OFDM transmitter – no big deal,
it's but an IFFT and a cyclic prefix block. That shouldn't take you
very long!

Also, the softcast folks used GNU Radio, so they most definitely have
source code to what they've done – and since MIT takes pride in doing
good science, I'm pretty sure that if you ask, you can get all the code
you need to reproduce.


By the way, they write:

> the receiver with low noise can distinguish
> which of the 16 small squares the original sample
> belongs to, and hence can correctly decode the 4 most
> significant bits of the transmitted sample. The receiver
> with higher noise can distinguish only the quadrant of
> the transmitted signal sample, and hence can decode
> only the two most significant bits of the transmitted
> sample. Thus, wireless broadcast naturally delivers to
> each receiver a number of signal bits that match its SNR.

That's a pretty established method. I think DVB-T does that.

Generally, I'm a bit surprised about the whole "try to contain the
numerical properties from the source video through video coding AND
channel coding" approach, from which they say they get better behaviour
under bit flips:

The very idea of video coding (i.e. source coding) is to maximize the
entropy of each bit. So, if you want to have "least significant bits",
as they argue they can get, not all bits are equally random, i.e.
there's bits that carry more, and bits that carry less information. 
The amount in which this non-equal-distribution of information /
probability happens is called redundancy, and simply means that you
spend more energy per video pixel to get the same error probability.
Sounds counter-productive to me!

Now, the argument of softcast seems to be: 

> Haha! The energy we waste in non-optimal source coding is more than
compensated by the r=1 rate channel code of not doing any channel
coding at all!

That seems strange. If I remember correctly, the whole point is that
joint source-channel coding (which softcast is) can be shown to be
rate-achieving for a *lossless* transmission, but separated source and
channel encoders, in which the source encoder actually maximizes
infobit entropy, and the channel coder minimizes bit error rate, are
superior when it comes to achieving a limited, yet non-zero rate
distortion.
If I was to write a publication about all this, I'd be very sure to
find a paper (I'm certain they cite their theoretical foundations
somewhere – the paper [1] as I could find it really just says "here's
how we're doing it, and that's how much better it is") that explains
how they found a sweet spot where an uncoded transmission achieves
higher info rate under the same distortion as the coded transmission in
an explicitly high-SNR scenario.

Best regards,
Marcus

[1]http://people.csail.mit.edu/szym/softcast/tr2.pdf

On Sat, 2019-05-25 at 19:38 +0100, farid mihoub wrote:
> My application is to broadcast a video using softcast approach. 
> Video-->2DCT_or_3DCT-->Floating coefficients-->complex_mapping
> -->ofdm_phy
> My video quality (PSNR) will depend linearly to my SNR so no need to
> have an adaptive modulation.
> 
> 
> 25.05.2019, 18:27, "Marcus Müller" <address@hidden>:
> > 1- So, you have an SNR of best-case 16 dB; that's not high for an
> > OFDM
> > system.
> > 
> > 2- No, there's no power normalization. Hint: you can look all this
> > up
> > by actually looking inside these blocks! This would make a lot of
> > sense, since it sounds you don't actually want to use tzhe OFDM
> > blocks
> > at all. The whole advantage of the OFDM blocks compared to just
> > doing
> > an IFFT of your transmit vector is that you get a header and
> > modulation
> > scheme.
> > 
> > 3- Not quite sure what "information is linearly related to complex
> > symbols" means? Can you elaborate?
> > 3b- A case where you *don't* do FEC is either a non-communications
> > system (i.e. you don't actually want to do OFDM for the reason of
> > transmitting information) or the extremely-bad-SNR case (where FEC
> > makes your BER better). For both cases, the existing OFDM blocks
> > are
> > more of an obstacle than a solution.
> > 
> > What are you building? What is your overall application. Please
> > paint
> > the bigger picture – it's a bit frustrating to try to help you, but
> > then only get told that "this is not how I want to do it".
> > 
> > Best regards,
> > Marcus
> > 
> > On Sat, 2019-05-25 at 18:39 +0200, Marcus Müller wrote:
> > >  Dear Farid,
> > > 
> > >  please always respond on the mailing list.
> > >  Thank you,
> > >  Marcus Müller
> > > 
> > >  On Sat, 2019-05-25 at 17:36 +0100, farid mihoub wrote:
> > >  > 1- For the noise : in the TX side the output is in the order
> > > of 2A,
> > >  > the noise 0.05A.
> > >  > 2-Second even without noise, the const does not affect the
> > >  > transmission, is there any sort of power normalization?
> > >  > 3-For the FEC and the modulation I want to try my custom
> > > mapping
> > >  > where information is linearly related to complex symbols, and
> > > my
> > >  > application doesn't require error correction. 
> > >  > 
> > >  > Thank you.
> > >  > 
> > >  > 
> > >  > 25.05.2019, 17:06, "Marcus Müller" <address@hidden>:
> > >  > > Hello Farid,
> > >  > > On Sat, 2019-05-25 at 15:59 +0100, farid mihoub wrote:
> > >  > > > Hello,
> > >  > > > 
> > >  > > > In the OFDM_tx, rx examples in gr-digital :
> > >  > > > 1- Why just a low level of noise affect the transmission
> > > and
> > >  > > > cause it
> > >  > > > to stop.
> > >  > > 
> > >  > > "low" is relative. It seems it's high enough to cause packet
> > >  > > losses,
> > >  > > iff it's actually the noise.
> > >  > > 
> > >  > > > 2- in the the Tx output and the Rx input no matter the
> > > value
> > >  > > > of
> > >  > > > the
> > >  > > > multiply constant we apply
> > >  > > > that would not affect our transmission.
> > >  > > 
> > >  > > Then it's probably not only the noise!
> > >  > > 
> > >  > > > 3- Is there any way to separate channel estimation and
> > >  > > > tracking
> > >  > > > from
> > >  > > > data transmission, sometime I get the error "invalid
> > > packet
> > >  > > > detected!" form the packet parser, also I need my data to
> > >  > > > bypass
> > >  > > > FEC
> > >  > > > and QAM.
> > >  > > 
> > >  > > Um, prior to QAM demodulation there is no data, and prior to
> > > FEC
> > >  > > decoding there is no information bits, so I'm not sure what
> > > you
> > >  > > want?
> > >  > > 
> > >  > > > My purpose is to stream raw complex data to the I/Q
> > >  > > > components
> > >  > > > directly.
> > >  > > 
> > >  > > Then it seems you don't want an OFDM transceiver but maybe
> > > just
> > >  > > simply
> > >  > > a single IFFT? Not quite sure what you have in mind.
> > >  > > 
> > >  > > Best regards,
> > >  > > Marcus
> > >  > > 
> > > 
> > >  _______________________________________________
> > >  Discuss-gnuradio mailing list
> > >  address@hidden
> > >  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




reply via email to

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