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
