[USRP-users] packet transmission question
bnwole at gmail.com
Wed Sep 25 23:46:21 EDT 2013
Glad to have your response. Yes, this understanding becomes important in
time critical applications especially. That would be great if you can
provide some of your findings on this topic at your earliest possible :)
I do not know much of Verilog, unfortunately. I would be happy to do some
reading, if you point out some, that can help me understand.
> I'm actually happy to help with this because, as Marcus says, this topic
> recurs often and is quite fundamental to understanding the timed operation
> modes of the USRP.
> However it's going to be a little work for me to calculate the exact value
> and distill a formula, so it's waiting for me to have some available time
> as I'm busy chasing round Europe this week.
> As always I encourage people to seek there own answers in the Verilog
> source code provided as part of the UHD git tree?(the beauty of open
> On Sep 25, 2013, at 1:23 AM, Marcus M?ller <marcus at hostalia.de> wrote:
> > Bob,
> > this topic has been heavily discussed the last few weeks.
> > Matt himself has made some statements on this, please use a search
> engine on the gnu radio mailing list archive to find out.
> > "Sample on air" is not really what's happening. You've got to be aware
> that there is, as you've already read in these replies, a variable digital
> delay. After that, you're still mixing to RF! That also introduces group
> delay. So, basically, even though there are some bounds for the delay, your
> actual delay depends on multiple factors and if you really care about that,
> you will need to figure out a way to measure it that fits your need
> > Hope that helped a little bit,
> > Marcus
> > On 09/25/2013 09:36 AM, bob wole wrote:
> >> Anybody please,
> >> --Bob
> >> On Fri, Sep 20, 2013 at 10:28 PM, bob wole <bnwole at gmail.com> wrote:
> >> Hi Ian
> >> Lets say I enter 500e3 as sample rate in USRP sink (N210). And on a
> sample I tag tx_time=5.65, then what delay will sample encounter from FPGA
> to going over the air ? Or by what time the sample would be on air ? On
> what thing this delay depends on? Your comment would be appreciated.
> >> Bob
> >> On 19.09.2013 17:52, Ian Buckley wrote:
> >> > Francois,
> >> > The logic that counts time and controls the presentation of TX data
> >> > to the DAC is located at the start of the USRP DSP chain after all the
> >> > transport, protocol and (de)packetizatiion logic. Between there and
> >> > the DAC are the CIC filter, both Halfband filters, and the CORDIC, all
> >> > of which contain some pipelining in the logic. For any given
> >> > interpolation ration from your GR sample rate to the DAC 100(or 64)MHz
> >> > sample rate, this logic should present a constant group delay. It
> >> > should change somewhat for different interpolation ratios due to
> >> > changes in the CIC configuration.
> >> > -Ian
> >> >
> >> > On Sep 19, 2013, at 1:53 AM, Francois Quitin <fquitin at ulb.ac.be>
> >> > wrote:
> >> >
> >> >> Hi all,
> >> >>
> >> >> We have a little question for you: we use a USRP+WBX with a code
> >> >> derived from tx_timed_burst.cpp to create our custom transmitter, and
> >> >> we use another USRP that records the received data to a file.
> >> >>
> >> >> When we look at the received signal, we observe a slight small
> >> >> staircase (around 30 samples long at 10MHz = 3us), as can be seen in
> >> >> the attached figure. It seems that our actual transmitted packet
> >> >> starts after this ?stair?. When we decrease the sample rate to 5MHz,
> >> >> the ?stair? is still 30 samples long (6us this time).
> >> >>
> >> >> As we are working in a case where timing is very critical, this 3us
> >> >> delay is a bit of an issue (unless it?s constant in which case we can
> >> >> compensate for it). Any idea where this is coming from ?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users