On 04/30/2014 05:17 PM, David Halls wrote:
> Sorry, my fault - I altered the FDE so it *does* give soft outputs,
> because the constellation decoder makes hard decisions anyway - so I
> didn't see the need for it to be done twice.
How exactly have you implemented that?
> I forgot i'd made changes :s But now maybe I understand why people
> haven't seen this issue - because they have never looked at the soft
> outputs of the FDE!!
>
> I am not quite clear how the pulse shaping works, it seems to extend
> each *packet* by rolloff_len/2 samples, it works out the flanks by
>
> for (int i = 1; i < d_rolloff_len; i++) {
> d_up_flank[i-1] = 0.5 * (1 + cos(M_PI * i/rolloff_len - M_PI));
> d_down_flank[i-1] = 0.5 * (1 + cos(M_PI * (rolloff_len-i)/rolloff_len -
> M_PI));
> }
>
> Which makes sense...
>
> then applies using
>
> if (d_rolloff_len) {
> for (int i = 0; i < d_rolloff_len-1; i++) {
> out[i] = out[i] * d_up_flank[i] + d_delay_line[i];
> d_delay_line[i] = in[i] * d_down_flank[i];
> }
> }
>
> Is it extending the symbol and then shaping? Not sure I understand why
> each *packet* is extended by rolloff_len/2, not each symbol.
Pulse shaping works by adding an up-flank at the start of every OFDM
symbol, and then extending the OFDM symbol by a down-flank.
What you're seeing is the delay line. After the last symbol, we could
either discard this (which would lead to some out-of-band emissions), or
send it (which is what we're doing).
> Is pulse shaping applied in the USRP, and can this be controlled from
> USRP_sink?
No, the USRP is agnostic of the actual modulation used.
M
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
