On Mon, Apr 2, 2018 at 7:42 PM, Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote:
> On 04/02/2018 08:05 PM, Martin Braun via USRP-users wrote: > >> On 03/16/2018 11:49 AM, Reinhold Frederick William Hollender via >> USRP-users wrote: >> >>> I just wanted to share my experience getting two Rx streams at different >>> rates working with the B210 in case someone else tries to do the same >>> thing in the future. >>> >>> The only other resource I found on this >>> (http://lists.ettus.com/pipermail/usrp-users_lists.ettus. >>> com/2015-April/041655.html) >>> seemed to have conflicting information, and no real resolution. >>> >>> I also didn't see anything like this described in the knowledge base, >>> although perhaps I was looking in the wrong place :) >>> >>> Following some breadcrumbs in the UHD source, I was able to get the >>> attached sample to work reliably. >>> >>> The important points: >>> -> There's no need to have multiple 'multi_usrp' objects because >>> device.make() will return the same object if it's already setup anyway >>> -> Both streams need to be read in the same thread (there were comments >>> that hinted at this in recv_packet_demuxer_3000) >>> -> The streams need to be kept in sync by keeping the number of sample >>> read by each stream the same ratio as the sample rates (otherwise one >>> stream will get behind and the other will overflow). >>> >> William, >> >> thanks for pointing this out! You might want to add that the rates need >> to be integer multiples of each other, or the FPGA can't handle the >> resampling. >> >> -- M >> >> Hah! I didn't know the B2xx FPGA would do that. > > I guess the multi_usrp synchronizer does not "balk" because the first > packets on each stream will have the same time-stamp, and unless there are > overflows, > it'll never care again. > > +1 would nod in admiration again.... > > > It looked to me like all the synchronization was happening inside the streamer object itself, so using two separate streamers would skip the synchronization, but I could be missing something. The key seems to be reading the two streams together to make sure that one of the streams isn't hogging a bunch of the transport buffers. I'm curious to see how it will react if I try to stop and re-start one of the streams. Off to more experimentation! > > > _______________________________________________ > 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
