Timestamps inband

Hi list,

we’re trying to use the inband FPGA image (inband_2rxhb_2tx.rbf)
trying to get the samples coming from two channels (for now, maybe
more later) on the same rev4 USRP aligned. Our ultimate goal is to do
beamforming with the USRP.

We have noticed that the distance between the timestamps of packets
from the two channels is linearly increasing, instead of being
fixed… Does anyone have any idea what could be at fault here?

We also noticed that the timestamp distance between packets of the
same channel is not fixed, as we would expect, but varying. If
sampling is synchronous, shouldn’t the packets have a fixed distance
between them?

Do we even need timestamps, or are the samples aligned (interleaved)
anyway, even with the standard FPGA image? We don’t care about
absolute time, just time (phase) difference between the two channels.

Thanks in advance, and sorry for the multiple questions in the same
email

Dimitris S.
“If you think you’re too small to make a difference, try sleeping with
a mosquito!” - Amnesty International

Do we even need timestamps, or are the samples aligned (interleaved)
anyway, even with the standard FPGA image? We don’t care about
absolute time, just time (phase) difference between the two channels.

I’ve done beamforming by modifying the standard build to have all the
DDCs running from one NCO(needed to clear up space on the FPGA). The
channels are alligned after you deinterleave them, however using the
standard build I am not sure if you will have a phase difference
between your NCOs.

-Kyle Pearson

On Mon, Jul 27, 2009 at 06:28, Dimitris S.[email protected]
wrote:

Do we even need timestamps, or are the samples aligned (interleaved)
anyway, even with the standard FPGA image? We don’t care about
absolute time, just time (phase) difference between the two channels.

With the standard image, if you’ve set the mux and number of channels
appropriately, then the interleaved channels are coherently sampled
(assuming you are using daughterboards with coherent local
oscillators.)

Regarding the inband code, this has become unmaintained; we’ve already
removed it on our 3.3 development trunk. The host code will get
rewritten using the 3.3 message passing architecture. The FPGA code
has issues (as you’ve noted), and I think there are some patches
floating around that fix some of them, but haven’t gotten integrated.
Eric might have a better handle on this.

Johnathan

On Mon, Jul 27, 2009 at 7:06 AM, Johnathan C. <
[email protected]> wrote:

oscillators.)

Regarding the inband code, this has become unmaintained; we’ve already
removed it on our 3.3 development trunk. The host code will get
rewritten using the 3.3 message passing architecture. The FPGA code
has issues (as you’ve noted), and I think there are some patches
floating around that fix some of them, but haven’t gotten integrated.
Eric might have a better handle on this.

You can try some firmwares that Eric S. built in an attempt to
fix
the timestamps with 2 channels:
http://www.schneider-group.com/gnuradio/r9581-ets-inband_2rxhb_2tx.zip

Search for his name on the list archives and you’ll find the discussion.

  • George

On Tue, Jul 28, 2009 at 10:25:40AM -0700, George N. wrote:

With the standard image, if you’ve set the mux and number of channels

You can try some firmwares that Eric S. built in an attempt to fix
the timestamps with 2 channels:
http://www.schneider-group.com/gnuradio/r9581-ets-inband_2rxhb_2tx.zip

Search for his name on the list archives and you’ll find the discussion.

George

FWIW, I think the corresponding source lives here:

$ svn co
http://gnuradio.org/svn/gnuradio/branches/developers/ets/inband

Eric

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs