On 24 Apr 2016 14:31, "Jingyi Sun" <sunjing...@gmail.com> wrote:
>
> Hi Martin,
>
> Thanks! We implemented the changes you suggested and it worked! We are
now able to have multiple inputs and propagate the proper tags. We are now
working on our next roadblock, which we feel like must also be a simple
problem:
>
> As a test to make sure that we could propagate data + tags properly, we
wrote geese_vcvc so that it takes just one input_items (in this case
input_items[0]) and sends it directly to the output_items[0]:
>
> const gr_complex *d = (const gr_complex *) input_items[0];
> const gr_complex *alpha = (const gr_complex *) input_items[1];
> const gr_complex *x = (const gr_complex *) input_items[2];
> const gr_complex *out = (const gr_complex *) output_items[0];
>
> int frame_len = 0;
>
> if (d_fixed_frame_len) {
> frame_len = d_fixed_frame_len;
> } else {
> frame_len = ninput_items[0];
> }
>
> std::vector<tag_t> tags
>
> out = d;
You're assigning the output vector. You need to memcpy the data. Also
please stay on the list.
M
>
> Then in the OFDM RX chain, we inserted the geese_vcvc block between the
OFDM frame equalizer and the OFDM frame serializer; geese_vcvc has three
inputs, but we wired the output of OFDM frame equalizer to all three inputs
(see attached image). In theory, our input_item[0] passes through
geese_vcvc untouched and the OFDM Receiver behaves just as it would without
geese_vcvc. We confirmed that all tags were passing through untouched.
Unfortunately, we suspect that something is corrupting the data bytes.
>
> We tracked the problem using tag debug, and found that after the stream
crc32 block, all the tags are dropped and no data was getting through. We
know that the crc32 has a function built in to allow it to drop failed
packets, which must be happening here. However, we can't figure out what in
geese_vcvc is corrupting the data, given that we're just passing the input
to the output. Any ideas?
>
> Thanks!
> Jenny & Team
>
>
>
>
> On Sun, Apr 24, 2016 at 2:19 PM, Martin Braun <mar...@gnuradio.org> wrote:
>>
>> On 04/23/2016 12:36 PM, Jingyi Sun wrote:
>> > Hi Martin and everyone,
>> >
>> > I've pinpointed what causes this error to occur with 3 inputs, but not
>> > occur with just 1 input.
>> >
>> > gr::log :FATAL: geese_vcvc0 - Missing a required length tag on port
>> > 1 at item #0
>> > thread[thread-per-block[46]: <block geese_vcvc (1)>]: Missing
length
>> > tag.
>>
>> Tagged streams carry tags to identify burst boundaries. Your input is
>> not seeing such a tag.
>>
>> Now, you should never, ever manually handle those tags. Whatever your
>> upstream block is, it should thus be either a tagged_stream_block, or
>> have automatic tag propagation.
>>
>>
>> > The culprit seems to be the following block of code inside my
>> > geese_vcvc_impl.cc file. I have it in my code right now because I based
>> > my block on ofdm_frame_equalizer.cc. I gather that it parses length of
>> > tags, and but seems to only do so for one input? Unfortunately I am
>> > unsure how to exactly interpret what it is doing.
>>
>> Well, yes, the original block only has one input. This is an advanced
>> functionality of tagged stream blocks. You rarely need to override it.
>> The only reason we do that here is because we allow the equalizer to run
>> either as a tagged stream block, or a fixed size (but non-tagged-steram)
>> block.
>>
>> Just don't use the fixed-length feature, don't include this method, and
>> you'll be fine.
>>
>> Also don't paste pictures of code -- how am I supposed to comment on it
>> inline.
>>
>> Cheers,
>> M
>>
>> > Martin, I notice you've worked on the ofdm_frame_equalizer block
>> > before--could you please help me go through what this piece of code
>> > does, and how I could change it to be compatible with a block with
>> > multiple inputs. I'm not thoroughly familiar with c++, and also am not
>> > sure about the particular purposes of variables here, or what the
>> > specific characteristics of "tags" vector are.
>> >
>> > *My goal is to do something similar to add two equalized input tagged
>> > streams together, and output the sum tagged stream, while also
>> > propagating tags through for tag debug.*
>> >
>> > *I would tremendously appreciate if you could briefly walk me through
>> > the following lines. Is this code necessary for tag propagation, or can
>> > I do without it? I don't get the error if this code is commented out.*
>> >
>> >
>> >
>> > On Fri, Apr 22, 2016 at 12:15 PM, Jingyi Sun <sunjing...@gmail.com
>> > <mailto:sunjing...@gmail.com>> wrote:
>> >
>> > Hi Martin, Andrej and everyone,
>> >
>> > Revision on my last email: I found out why my out-of-tree copy of
>> > tagged_stream_mux wasn't working and fixed the problem--it was a
bug
>> > with having the wrong variable name input in the blockt after
>> > everything was built. My copy now works like the original
>> > tagged_stream_mux does!
>> >
>> > So I will work on slowly modifying this copy of tagged_stream_mux
to
>> > look like what I want until something breaks, and then update you
>> > guys on that. Hopefully that will help!
>> >
>> > Thanks again for all your help!!
>> >
>> > Best,
>> > Jenny
>> >
>> > On Thu, Apr 21, 2016 at 2:37 PM, Jingyi Sun <sunjing...@gmail.com
>> > <mailto:sunjing...@gmail.com>> wrote:
>> >
>> > Hi Martin,
>> >
>> > I did more tests, including*trying to recreate
>> > tagged_stream_mux* as an out-of-tree block. My block is called
>> > mux, but everything else (.cc, .c, .xml), are exactly the same.
>> > I copied and pasted everything from github, minus the name.
>> >
>> > *It gives me the same error. *
>> >
>> > I suspect the source code that my installed binary version of
>> > GNU Radio is based on is different from the one used to
>> > originally create tagged_stream_mux block that comes with GNU
Radio.
>> >
>> > Do you know if there is a specific person I can contact who
>> > would know about tagged_stream_block source code? Or do you
>> > think there's something else I haven't thought of.
>> >
>> > I'm not sure what else I can try right now, and would be
willing
>> > to try anything you (or anyone else) might have to suggest.
>> >
>> > Thanks,
>> > Jenny
>> >
>> >
>> > On Thu, Apr 21, 2016 at 2:02 PM, Martin Braun
>> > <martin.br...@ettus.com <mailto:martin.br...@ettus.com>> wrote:
>> >
>> > On 04/20/2016 04:48 PM, Jingyi Sun wrote:
>> > > tagged_stream_mux works when substituted for my block,
so I think all of
>> > > my inputs are tagged streams. Also, my inputs are coming
from the
>> > > outputs of OFDM_frame_equalizer, which I think
propagates tagged streams?
>> >
>> > Yes.
>> >
>> > M
>> >
>> > > I think it's an error somewhere in the code, but the
changes I mentioned
>> > > are the only changes I made between the block working
and the block not
>> > > working.
>> > >
>> > > My code is based on OFDM_frame_equalizer, but without
the actual signal
>> > > processing part. I will fill in my own signal processing
after I know I
>> > > can at least pass one out of three inputs along so that
the outputs are
>> > > the same as if this new block were bypassed.
>> > >
>> > >
>> > >
>> > >
>> > > On Wed, Apr 20, 2016 at 6:24 PM, Martin Braun <
martin.br...@ettus.com <mailto:martin.br...@ettus.com>
>> > > <mailto:martin.br...@ettus.com
>> > <mailto:martin.br...@ettus.com>>> wrote:
>> > >
>> > > The tagged_stream_mux is an example of this kind of
>> > block. As Andrej
>> > > points out, you need to make sure every input signal
>> > is actually a
>> > > tagged stream.
>> > >
>> > > Cheers,
>> > > M
>> > >
>> > > On 04/20/2016 03:12 PM, Andrej Rode wrote:
>> > > > Hello Jenny,
>> > > >
>> > > > I can try to help you, but I'm not quite sure if I
>> > am right. If I
>> > > am wrong I
>> > > > will be corrected soon.
>> > > >
>> > > >>>> Generating: "/home/jenny/Tutorials/rx_ofdm.py"
>> > > >>>> Executing: "/home/jenny/Tutorials/rx_ofdm.py"
>> > > >>>> Using Volk machine: sse4_2_64_orc
>> > > >>>> gr::log :FATAL: geese_vcvc0 - Missing a required
>> > length tag on
>> > > port 1 at
>> > > >>>> item #0
>> > > >>>> thread[thread-per-block[46]: <block geese_vcvc
>> > (1)>]: Missing
>> > > length tag.
>> > > >
>> > > > This error tells you that your block is missing a
>> > length tag in
>> > > one of his
>> > > > inputs. A Stream Tag on the first sample is a
>> > requirement for a
>> > > tagged stream
>> > > > block. This Stream Tag has to provide information
>> > about how much
>> > > input data
>> > > > your block has to process.
>> > > > I assume you don't have an tagged stream on each of
>> > your inputs
>> > > and this
>> > > > causes a problem for your tagged stream block.
>> > > >
>> > > > Best you provide a screenshot of your example
>> > flowgraph (the
>> > > relevant parts).
>> > > > Based on the error it is nothing inside of your
>> > block but the way
>> > > you are
>> > > > trying to feed it with samples.
>> > > >
>> > > > Best Regards,
>> > > > Andrej
>> > > >
>> > > >
>> > > >
>> > > > _______________________________________________
>> > > > Discuss-gnuradio mailing list
>> > > > Discuss-gnuradio@gnu.org
>> > <mailto:Discuss-gnuradio@gnu.org>
>> > <mailto:Discuss-gnuradio@gnu.org
>> > <mailto:Discuss-gnuradio@gnu.org>>
>> > > >
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> > > >
>> > >
>> > >
>> > >
>> > > _______________________________________________
>> > > Discuss-gnuradio mailing list
>> > > Discuss-gnuradio@gnu.org
>> > <mailto:Discuss-gnuradio@gnu.org>
>> > <mailto:Discuss-gnuradio@gnu.org
>> > <mailto:Discuss-gnuradio@gnu.org>>
>> > >
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> > >
>> > >
>> >
>> >
>> > _______________________________________________
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org <mailto: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
>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
