Re: [Discuss-gnuradio] trying to create stream tag, pass down, not as expected?

[George Nychis]

Hey Lizhao,

Thanks for the help!

So actually, let's back this up and try to even get it in digital_ofdm_frame_acquisition.cc first, before we get in to why we are out of sync with it in digital_ofdm_frame_sink.cc.  That way we can better track it as it moves forward.

I am wondering now if my use of "offset" as being: 'index' in the sampler code is the wrong thing to do.  Instead, it should be something like: this->nitems_written(1) + index;  

I think we should try to nail the proper index rather than adding two timestamps there, but I understand what you're saying now in terms of where it is inserting in the stream.  Trying out some things now...

- George

On Sat, Feb 11, 2012 at 3:50 AM, You Lizhao <address@hidden> wrote:

Hi George,

Maybe I have solved your problem.
(1) Problem: Header received, with no sync timestamp? (509)
The reason why you cannot get the correct timestamp is that: when we try to get timestamp at STATE_HAVE_HEADER or STATE_HAVE_HEADER, actually, nread is no longer the position where the timestamp we insert in digital_ofdm_sampler, because STATE_SYNC_SEARCH will increase the nread by one or more. It is hard to track the real position where the timestamp was inserted. Maybe we can store the timestamp after enter_have_sync(), and insert the timestamp into msg when we have a header.

(2) Problem: the mismatch number of output and number of frames
I have found that in my experiment, gr_peak_detector_fb will output two one. The position of the first one is the real preamble beginning, and the second is actually the end of packet. If we rely on the output of ofdm_sync_pnc (preamble or not) to add timestamp, probably we may add two timestamps. However, if we get the right position for the real preamble timestamp, I think it does not matter.

Wish it help.


Regards,
Lizhao

2012/2/10 George Nychis <address@hidden>

I am trying to pass a stream tag down the chain in the OFDM code.  As a point of reference, I am using Tom, Matt, and Bob's figure from their SDR08 paper:

What I want to do is in gr.ofdm_sampler, calculate the clock time the preamble was received at the USRP, then pass it on forward all the way to the python code so that every incoming decoded packet has a timestamp associated with it, which is the time the preamble was received.

So, in gr.ofdm_sampler, I calculate the timestamp and create a new stream tag, putting it on port 1 (note: also tried port 0):

https://github.com/gnychis/grforwarder/blob/7a9d5735b341f5c226b6d3a249f51bf5edfee54f/gr-digital/lib/digital_ofdm_sampler.cc#L153

At this point, I output:

"--- added sync tag in ofdm_sampler\n"

Then, this stream tag should hit gr.ofdm_frame_acquisition.  I do a quick check for it on incoming port 1:

https://github.com/gnychis/grforwarder/blob/7a9d5735b341f5c226b6d3a249f51bf5edfee54f/gr-digital/lib/digital_ofdm_frame_acquisition.cc#L191

And output:

"--- got sync tag in frame_acq\n"

Next, I make the same check in gr.ofdm_frame_sink for my stream tag (at top of work):

https://github.com/gnychis/grforwarder/blob/ade8b55b68115288b88b35a968a79a86966db14e/gr-digital/lib/digital_ofdm_frame_sink.cc#L301

And output:

"--- got sync tag in frame_sink\n"

Finally, I check for the stream tag right before the new gr.message is put in to the queue in gr.ofdm_frame_sink:

https://github.com/gnychis/grforwarder/blob/ade8b55b68115288b88b35a968a79a86966db14e/gr-digital/lib/digital_ofdm_frame_sink.cc#L414

If no stream tag is found, I output:

std::cerr << "---- Header received, with no sync timestamp? (" << nread << ")\n"

Now, what I would expect is that when I get an incoming frame, I go down that set of outputs one by one, and then I get the output that I've received a packet.  But, that doesn't seem to be the case:

http://pastebin.com/hZpuQc12

Instead, I typically get this with no output from frame_acq or frame_sink other than frame_sink to tell me it didn't get the stream tag:

--- added sync tag in ofdm_sampler

---- Header received, with no sync timestamp? (181)

ok: True pktno: 156 n_rcvd: 2 n_right: 1 valid_ts: 0

Then after a little while, I get a dump from frame_acq and frame_sink:

--- added sync tag in ofdm_sampler

---- Header received, with no sync timestamp? (509)

ok: True pktno: 174 n_rcvd: 20 n_right: 19 valid_ts: 0

--- added sync tag in ofdm_sampler

--- got sync tag in frame_acq

--- got sync tag in frame_sink

--- got sync tag in frame_acq

--- got sync tag in frame_sink

--- got sync tag in frame_acq

--- got sync tag in frame_sink

The number of those don't correspond to how many frames that I have received, and at some point just stop showing up:

http://pastebin.com/hZpuQc12 (lines 231 -> 953 have no output from frame_acq or frame_sink)

Am i missing something fundamental about how the stream tag is passed forward?

Thanks!

George

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