Hi Han,

You replied to a thread from September 2013 – which is totally OK, but
many of us don't have the original mail in their archives, so here it is:

> Hi Tim.
>
> The solution I found was to set the Fixed Frame Length parameter to 1
> on the OFDM Frame Equalizer block of the "Header Stream".
>
> The original value for this field is set to 0, but I don't exactly
> know why it works setting it to 1.
a bit of research led to this original question:
>> On Tue, Sep 10, 2013 at 09:58:16PM +0000, Monahan-Mitchell, Tim wrote:
>>> GR 3.7.1
>>> gr-digital/examples/ofdm/rx_ofdm.grc
>>>
>>> 1. The OFDM Frame Equalizer block that is downstream from the Header Stream 
>>> Virtual Source block has the Length Tag Key field set to length_tag_name, 
>>> yet all other blocks on the diagram with that field are set to 
>>> length_tag_key (which is the ID of a Variable block at the top of the 
>>> diagram). Is that a mistake? If someone will confirm, I can file the bug.
>> Hm. You make me look like a total scrub.
>>
>> It seems you're right. However, on my machine, length_tag_name doesn't
>> throw an error. I just can't see why. GRC itself should figure this is a
>> problem.
>>
>>> 2. When I try to run this flowgraph, modified for my target's custom source 
>>> block, I get this error:
>>> FATAL: Missing a required length tag on port 0 at item #0
>>> thread[thread-per-block[21]: <block ofdm_frame_equalizer_vcvc (22)>]: 
>>> Missing length tag.
>> That's good, actually -- it means your block is getting input, which
>> means it's receiving headers.
>>
>> To be honest, the {rx,tx}_ofdm.grc files were more of an illustration of
>> how the OFDM chain works. I know I've used them successfully sometime in
>> the past, but I've changed some stuff in between.
>>
>> Using the ofdm_tx and ofdm_rx hier blocks should, however, work. Can you
>> try those?
>>
>> My main issues when transmitting OFDM is getting a clean spectrum. OFDM
>> doesn't like distortions at all.
>>
>> MB
>>
>>> Which led me to question (1) above. However, changing that block to match 
>>> the others does not correct the runtime error.
>>>
>>> I found a couple of instances of the same error listed in (2) above in the 
>>> mailing list, but no one replied to them.

So, please note: gr-digital has seen quite some patches since 2013; I
wouldn't assume everything said back then still applied today.

You mention

header_eq=digital.*ofdm_equalizer_vcvc*(

now, did you maybe mean ofdm_*frame*_equalizer_vcvc

So, before we dig deeper into this, would you mind explaining which
question exactly you're referring to when you said
>  I have faced the same question in my work,
I think it might be worth giving us a bit of an overview over what
you're building, what goes wrong, and how you're trying to fix this.
Right now, I'm a bit confused, sorry :(

Best regards,
Marcus

On 17.05.2016 09:50, hgajiayou wrote:
> Hey there:
>       I have faced the same question in my work, according to your solution
> that set the Fixed Frame Length parameter to 1. I checked the OFDM Frame
> Equalizer block in ofdm_txrx.py(the file direction:
> gnuradio->gr-digital->python->digital), and i found the next codes:
>
> header_eq=digital.ofdm_equalizer_vcvc(
>       header.equalizer.base(),
>       cp_len,
>       self.frame_length_tag_key,
>       True,
>       1   #Header is 1 symbol long,
> )
> According to your solution, which parameter i need to set to 1 in the codes?
> I'm a green hand in Gnuradio, hoping for your answer .
>
> Han 
>
>
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/Fwd-Questions-on-rx-ofdm-example-in-GR-3-7-1-tp43833p60074.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to