Felix, So I threw a couple of stream-to-tagged-stream blocks in that test flow graph to see if I could see what you see. And it does replicate the behavior you report though I see a time offset that seems to range from approx 24 to 29uS with no obvious linkage between that value and any parameter I configure. The time offset is constant within any flow graph run it seems. Tag_debug shows the tags going onto both channels at the correct offsets.
> Comparing your flow graph to mine, I deactivated the "stream to tagged > stream" blocks and set the master clock rate back to "Default" (previously, > it was set to 16 MHz). It turns out that both settings independently seem to > cause delays between my TX streams, i.e., without TSB tags and 16 MHz clock > rate I see delays and also with TSB tags and a Default clock rate. Leaving > out the TSBs and setting the Default clock rate, hence directly connecting > the two vector sources to the UHD sink, results in the desired signal. So I don’t see any (obvious) difference in behavior using a default master_clock vs a range of explicit ones using my flow graph. (BTW, sorry left a throttle in there that should not have been in there yesterday) So right now I see 3 possible causes for this type of behavior: 1) Sample data from different offsets is in bursts tagged with the same SOB time in different channels. 2) SOB is tagged with different times in different channels but has data from matched offsets 3) The H/W clocks in the two different channels are out of sync. (They run at the same rate by design but could be offset via starting count value or when starting count value was applied, all of which is configured by S/W). (The working streaming case indicates the clocks are synchronized in that configuration) Debug from here might be as painful as instrumenting UHD to see what times it schedules bursts for both channels. Your observation that gr-uhd only looks at tags on channel1 leads me to think my tx_time suggestion will make no difference. FWIW from an architecture point of view if you just want to space your bursts a constant distance and not be responsive to some type of async event you would only have to query USRP time once initially, all subsequent tx_times could be calculated as a delta off that given you know your sample rates and burst lengths. -Ian > On May 3, 2018, at 4:38 AM, Wunsch, Felix (CEL) via USRP-users > <usrp-users@lists.ettus.com> wrote: > > Ian, > > thanks for the quick response! > > Actually, I'm not adding a tx_time tag. In my application, I want the packets > to be transmitted simply as soon as possible and I was hoping that the two > streamers of a single device were inherently synchronous. > > Comparing your flow graph to mine, I deactivated the "stream to tagged > stream" blocks and set the master clock rate back to "Default" (previously, > it was set to 16 MHz). It turns out that both settings independently seem to > cause delays between my TX streams, i.e., without TSB tags and 16 MHz clock > rate I see delays and also with TSB tags and a Default clock rate. Leaving > out the TSBs and setting the Default clock rate, hence directly connecting > the two vector sources to the UHD sink, results in the desired signal. > > But back to my original problem: Is there any way to get a synchronous > dual-channel output for packetized samples that just sends as soon as > possible? I have no problem with coding my own USRP sink block for this or a > block that attaches SOB and EOB tags, I'd just like to avoid wasting time > because I might trigger the same problem again. Also, I'd like to avoid > getting the current time from the USRP each time I want to send a packet, if > possible. > > By the way: Looking at the USRP sink implementation in gr-uhd, I can find > only one call to get_tags_in_range and that one only looks at the first > input, so I guess all other tags are ignored. > > Cheers, > Felix > > > Von: Ian Buckley <i...@ionconcepts.com <mailto:i...@ionconcepts.com>> > Gesendet: Mittwoch, 2. Mai 2018 21:37 > An: Wunsch, Felix (CEL) > Cc: usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com> > Betreff: Re: [USRP-users] B210 dual channel operation with length tag in GNU > Radio > > Felix, > Are you adding an explicit “tx_time” tag( with associated identical time > tuple value) in both streams at the same offset as the TSB tag you are adding? > I don’t think you can safely assume the TSB tag (Which causes bursting > behavior in the USRP, equivalent to the use of the sob/eob) tags will cause > both bursts to start at the same exact absolute time value. > (Ready to be corrected by a GR guru on that….) > > Regardless attached is a simpler flow graph that uses streaming rather than > bursting to achieve same effect you are looking for. The UHD sink guarantees > to start two MIMO streams simultaneously for this kind of flow graph style. > > -Ian > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
