Hello Yichao Yu: What is your status on this issue?
If this issue is still outstanding for you, could you please share your program with us (you can email it to us directly and privately, if you prefer), so we can see exactly what you're doing. --Neel Pandeya On 19 April 2018 at 10:28, Yichao Yu via USRP-users < usrp-users@lists.ettus.com> wrote: > > I'm still a bit confused about the time synchronization being an issue > > at all – even after a packet dropout, all packets coming from the X3xx > > contain a timestamp, so you'd *never* have to call get_time_now (and it > > won't do any good, for asynchronity reasons). > > Hmmm, maybe I failed to mention this but I'm actually **sending** data > and not receiving data. > If that's not where the issue is then we're using `tx_stream::send` to > push data to the device and I don't think (could be wrong of course) > there's a timestamp returned from that (after all it's async). > If there's a different function that I can use to get a (async) reply > including the time stamp, that'll almost certainly solve my issue. > > > > > I know this is much too ask at this point, but if you could outline the > > most pressing issue you have right now, I think it'd enable me (us!) to > > help you quickest. > > > > Best regards, > > Marcus > > > > On Thu, 2018-04-19 at 11:48 -0400, Yichao Yu wrote: > >> Forwarding to the mailing list after getting no reply from ettus in 4 > >> months!!! > >> > >> Sorry for the top post but it's increasingly clear that the ad-hoc > >> method of resetting the device every now and then is giving us a lot > >> of problems and it's getting worse with libuhd update. > >> We really need to know how many datapoint the hardware actually > >> outputs, is there no way to do it? (For context, see below) > >> > >> > > That is exactly the approach I'd recommend! The timing resolution > >> > > would > >> > > actually be much finer than you assume – the clock in which the > >> > > timestamps > >> > > are counted ticks at the Master Clock Rate of 200 MHz. > >> > > >> > The time resolution here actually comes from the trigger source (or > >> > uncertainties to get current time in general). > >> > After more testing the serial port read seems to be rounded to 1ms, > >> > which limits our time resolution. > >> > > >> > > I think the main problems is that you base things of > >> > > get_time_now; don't do > >> > > that, if you can avoid it by any means. Instead, think of it like > >> > > this: The > >> > > USRP has an internal clock. Consider that to be the only > >> > > "correct" clock. > >> > > Your receive signals (if you have any) are tagged with it. Your > >> > > transmit > >> > > signal should be referenced against it. So, if you can, schedule > >> > > only by > >> > > counting up the device time in your program. > >> > > >> > The main problem is that `get_time_now` is slow....... (compare to > >> > clock_gettime at least). > >> > Also, thhe synchronization between the system clock and the usrp > >> > clock > >> > isn't actually the big problem. > >> > The big problem is synchronizing the output with the usrp clock > >> > when > >> > there's missing samples. > >> > > >> > > > 1. Periodically stop the burst and start a new timed burst with > >> > > > a > >> > > > small time gap in the middle. If we do this frequent enough we > >> > > > should > >> > > > be able to consume away the missing time. There are some point > >> > > > in the > >> > > > continuous run where it is kind of ok to do this but we'd still > >> > > > like > >> > > > to avoid doing this as much as possible since it can make the > >> > > > whole > >> > > > system less predictable. > >> > > > >> > > That's pretty much the usual method of doing this. > >> > > >> > Yeah, I noticed after reading some of the examples. However, in > >> > this > >> > case, we really want to find a better way if at all possible since > >> > > >> > 1. This is basically solving the problem causing by a timing issue > >> > (missing samples) by making it worse (i.e. missing a lot more > >> > samples........) > >> > > >> > 2. I'm 100% sure we are going to be affected by the periodic > >> > turning > >> > off at one point or another > >> > > >> > Since there's no way for me to know how many samples are > >> > missing, > >> > as long as there has been any underflow, I have to contineously > >> > drop > >> > samples in case I haven't waited long enough yet. > >> > Although not driven by this currently, we do have equipment > >> > that > >> > could be quite unhappy if the input is off this frequently. > >> > >> > >> > >> > >> > > >> > > Hope this gets a discussion starting! > >> > >> > >> > >> > > > >> > > Best regards, > >> > > Marcus > >> > > > >> > > > >> > > On Tue, Dec 12, 2017 at 7:07 PM, Yichao Yu via USRP-users > >> > > <usrp-users@lists.ettus.com> wrote: > >> > > > > >> > > > > Had a look at if this can be done by catching underrun event > >> > > > > and from > >> > > > > what I can see in how that error is generated and how the > >> > > > > message > >> > > > > triggering it is generated in the firmware code it doesn't > >> > > > > seem to be > >> > > > > a real counter, rather a flag/saturated counter so it won't > >> > > > > be good > >> > > > > enough for my application. > >> > > > > >> > > > And yet another solution that will work for us would be to use > >> > > > the > >> > > > usrp to detect an external trigger and send the corresponding > >> > > > position > >> > > > in the data stream to the host. This will actually also make > >> > > > our code > >> > > > simpler since I don't need to convert between different type > >> > > > anymore. > >> > > > > >> > > > _______________________________________________ > >> > > > USRP-users mailing list > >> > > > 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 >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
