discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: tag offset question


From: jmfriedt
Subject: Re: tag offset question
Date: Tue, 18 May 2021 10:09:03 +0200

That makes sense indeed, thank you for your help and advice which
allowed me to track the issue, if not find the solution.

The long answer: I am trying to propagate a tag in gnss-sdr. When the
FPGA detects a condition it introduces a given sequence in the IQ stream
detected by the Source block. This tag is properly propagated along the
processing chain as long as no decimation occurs, which allowed me to
understand that get_tags_in_window() provides an offset information
in *absolute* index (and not relative as the search window), which is 
indeed documented but I was not reading properly.
The problem seems to arise when gnss-sdr tracks the GPS signal in a
gr_sync_decimator whose noutput_items is equal to 1 in the work
function, so that the tag must be lost or the decimation factor so
large that the tagged sample is dropped (which makes sense because at 
this point we convert the 1.023 Mb/s CDMA to the 20 bps NAV payload).

So back to the drawing board, tag propagation seems not the way to go
in this application.

Thanks, JM

> It is possible that one of the blocks in the middle of your flowgraph
> is not handling the tags properly. What is between the sender and
> receiver?
> 
> On Mon, May 17, 2021 at 11:17 AM Jeff Long <willcode4@gmail.com>
> wrote:
> 
> > When there is a rate change, tag offsets are adjusted to match.
> > Otherwise, the tag spacing should stay the same, taking into
> > account that the tags may end up in different calls to work().
> >
> > On Mon, May 17, 2021 at 11:07 AM jmfriedt
> > <jean-michel.friedt@femto-st.fr> wrote:
> >  
> >> I am trying to get an accurate timing of a given sample (1-PPS
> >> transition). To do so, a marker is injected in the AD9831
> >> datastream in the B210 FPGA. When this tag is detected in the UHD
> >> source block, a tag is created in the stream:
> >>
> >>     for (item=0;item<noutput_items;item++)  // check all samples
> >>        {if (ch==0)                          // check if channel 0
> >>           {if (in[item]==_tag_pps_int)      // check marker
> >> detection {add_item_tag(0,                 // Port number
> >>             nitems_written(0) + item,       // Offset
> >>             pmt::string_to_symbol("1PPS"),  // Key
> >>             pmt::from_double(3.14159));     // Value
> >>  ...
> >>
> >> Displaying the item number when the marker is detected, I get
> >> things like 444331/524288 or 364347/524288 (item/noutput_items)
> >> which seems realistic.
> >>
> >> Downstream the flowchart, after many other processing blocks, I
> >> check for the tag in the window of samples that were just
> >> transferred std::vector<gr::tag_t> PPS_tag;
> >>   get_tags_in_window(PPS_tag,0,
> >>          0,             // abs_start,
> >>          noutput_items, // uint64_t abs_end);
> >>          pmt::string_to_symbol("1PPS")) ;
> >>   if (PPS_tag.size() != 0)
> >>      { printf("\n** PPS_tag received: %ld (%ld/%d):
> >>           message=%.9f",PPS_tag.size(), noutput_items,
> >>           to_double(PPS_tag[0].value));
> >> ...
> >> and there I *always get* PPS_tag.offset=1.
> >>
> >> If on the emitter side I create two tags separated by 42 i.e.
> >> add_item_tag(0,
> >>             nitems_written(0) + item,
> >>             pmt::string_to_symbol("1PPS"),
> >>             pmt::from_double(3.14159));
> >> add_item_tag(0,
> >>             nitems_written(0) + item + 42,
> >>             pmt::string_to_symbol("1PPS"),
> >>             pmt::from_double(3.14159));
> >> then the receiver indeed detects PPS_tag.size() = 2 but still
> >> both PPS_tag[0].offset and PPS_tag[1].offset are equal to 1 !
> >> I am obviously misunderstanding the behviour of tag.offset: can
> >> anyone enlighten me on how to identify the index of the sample
> >> carrying the tag ?
> >>
> >> Thanks, JM
> >>
> >>  



-- 
JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000
Besancon, France



reply via email to

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