Hi Yichao, Sorry, this is probably my fault. I apologize – I'm not quite sure how to help you most efficiently right now. I remember this being a relatively involved issue; just from reading your second-to-last email on this list, this becomes clear.
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). 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
