Hello!

I am trying to do something very similar to the rx_samples_to_file example here. In this script, if multithreading is selected, then a different call to recv_to_file spawns for each channel, which in turn creates a different rx_streamer for each channel.

I modified the code to specify the uhd::time_spec_t that feeds to each stream_cmd.time_spec, outside the loop so that the streaming start time for each channel is identical.

I have only tried with 2 channels so far. I have a GPS L1 signal connected to each port corresponding to my 2 channels, and I am using a USRP X410. If I capture at the same rate for both channels, I show that they start at an identical time (to the nearest ns). When I change the rate of the second channel, I then have a difference of about 732ns.

The rates I choose are 9830400 Msps and 20480000 Msps. These correspond to the master clock rate of 245760000 divided by 25 and 12 respectively.

Does anyone have an idea as to how to align the captures?

Thanks!

If I do thing concurrently (same thread, same rx_streamer) would that solve the timing issue? For example:

stream_args.channels = { 0, 1};

uhd::rx_streamer::sptr rx_stream = usrp_->get_rx_stream(stream_args);

…

size_t num_rx_samps =

                rx_stream->recv(buffs, samps_per_buff_, md, timeout, one_packet);

Where buffs is a collection of receive buffers.

It would become a little awkward with different sampling rates, but would this potentially solve the timing issue?

It’s an estimated difference using a GPS SDR I have access to, not the timestamps in the metadata.

I just tired choosing different sampling rates, it seems like when I use pairs of sampling rates corresponding to odd divisions of the master clock rate, it works fine. Similarly when I choose even pairs. Choosing a sampling rates corresponding to odd and even though causes a mismatch.

I have no clue how to explain it but .. I added just getting the timestamp from the metadata on my first rx_streamer->recv call and magically now the timestamps are aligned, and my aforementioned method of checking the timestamp also agrees. This works for the rates I originally mentioned I was having issues with (9830400 Msps and 20480000 Msps). Thanks for your help and time!

Actually I was running it wrong… The md.time_spec on each of my thread/channel’s first call to rx_streamer->recv returns the same full and fractional seconds from md.time_spec, but my method of checking against the estimated time form the GPS signal still returns about a 700ns difference.