> 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 >> > > <[email protected]> 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 >> > > > [email protected] >> > > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus. >> > > > com >> > > >> > > _______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
