[USRP-users] packet transmission question

Ian Buckley ianb at ionconcepts.com
Wed Sep 25 05:23:21 EDT 2013


Bob,
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 source).

-Ian

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 yourself. 
> 
> 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 ?
>> >>
>> >> Thanks!
>> >> Francois
>> >>
>> >> --
>> >> Francois Quitin, Ph.D.
>> >>
>> >> Research Fellow
>> >> INFINITUS - Infocomm Centre of Excellence
>> >> School of EEE, Nanyang Technological University
>> >> 50 Nanyang Ave, S2-B4b-05
>> >> Singapore 639798
>> >> Phone: +65-8502-3690
>> >> Email: fquitin at ntu.edu.sg
>> >> <rx_packet.png>_______________________________________________
>> >> USRP-users mailing list
>> >> USRP-users at lists.ettus.com
>> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >> [1]
>> >
>> >
>> >
>> > Links:
>> > ------
>> > [1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 4
>> Date: Thu, 19 Sep 2013 17:32:39 -0700
>> From: Ian Buckley <ianb at ionconcepts.com>
>> To: sean rivera <sean.rivera at colorado.edu>
>> Cc: usrp-users at lists.ettus.com
>> Subject: Re: [USRP-users] Testing the USRP2 FPGA code
>> Message-ID: <2403CABC-41FF-41A2-B3A0-27AB1932D041 at ionconcepts.com>
>> Content-Type: text/plain; charset=iso-8859-1
>> 
>> The "pre-existing data" replaces live off the air signals?
>> 
>> In which case why not just simulate your module in Verilog with a test bench?
>> 
>> There are a variety of ways to do something similar in the live FPGA image but it's hard to make a detailed suggestion without knowing more about the data you wish to feed the block, or how the block will interact with other logic.
>> 
>> On Sep 19, 2013, at 4:57 PM, sean rivera <sean.rivera at colorado.edu> wrote:
>> 
>> > Hello list,
>> >
>> > I'm having a bit of a challenge in testing custom firmware for the FPGA. For my custom module I have a Matlab module used to determine position coordinates over GPS that I have converted to Verilog. In order to test this module I would like to take preexisting data, and pass it into my Verilog code, either using the SD card or Ethernet of the N210. Is there anyway to do this?
>> >
>> > Thanks for you help,
>> > --
>> > ~Sean Rivera
>> > ECEN, CSCI,APPM
>> > _______________________________________________
>> > USRP-users mailing list
>> > USRP-users at lists.ettus.com
>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> 
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 5
>> Date: Thu, 19 Sep 2013 17:36:54 -0700
>> From: Ian Buckley <ianb at ionconcepts.com>
>> To: fquitin <fquitin at ulb.ac.be>
>> Cc: usrp-users at lists.ettus.com
>> Subject: Re: [USRP-users] packet transmission question
>> Message-ID: <13C3A67B-ECF9-40DC-88D7-B4D816DC7276 at ionconcepts.com>
>> Content-Type: text/plain; charset=windows-1252
>> 
>> All the logic I mentioned is digital and on the base USRP system, so independent of Daughter board choice and constant for any given sample rate. Clearly there is some propagation delay of the signal in the analogue domain from DAC to antenna, but I've no wisdom to offer that helps quantify that.
>> -Ian
>> 
>> 
>> 
>> On Sep 19, 2013, at 5:28 PM, fquitin <fquitin at ulb.ac.be> wrote:
>> 
>> > Hi Ian,
>> >
>> > Thanks a lot for the info. So, for a given sample rate (and a given daughterboard model), this delay will be constant?
>> >
>> > Thanks,
>> > Francois
>> >
>> >
>> > 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 ?
>> >>> Thanks!
>> >>> Francois
>> >>> --
>> >>> Francois Quitin, Ph.D.
>> >>> Research Fellow
>> >>> INFINITUS - Infocomm Centre of Excellence
>> >>> School of EEE, Nanyang Technological University
>> >>> 50 Nanyang Ave, S2-B4b-05
>> >>> Singapore 639798
>> >>> Phone: +65-8502-3690
>> >>> Email: fquitin at ntu.edu.sg
>> >>> <rx_packet.png>_______________________________________________
>> >>> USRP-users mailing list
>> >>> USRP-users at lists.ettus.com
>> >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
>> >> Links:
>> >> ------
>> >> [1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> 
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 6
>> Date: Fri, 20 Sep 2013 11:36:42 +0100
>> From: Paul Sutton <suttonpd at tcd.ie>
>> To: usrp-users at lists.ettus.com
>> Subject: [USRP-users] B200: Exploring the Wireless World
>> Message-ID: <523C253A.1060305 at tcd.ie>
>> Content-Type: text/plain; charset=ISO-8859-1
>> 
>> Hi all,
>> I love Balint's video showcasing the B200 - it looks like a brilliant
>> piece of kit!
>> Any chance you could list the software applications used in the video
>> and let me know if/where they're available?
>> 
>> Thanks,
>> Paul
>> 
>> --
>> ________________________________________________________________
>> Paul Sutton Ph.D.
>> 
>> CTVR, The Telecommunications Research Centre,
>> Room 2.08, Dunlop House, Fenian Street,
>> University of Dublin, Trinity College, Ireland.
>> 
>> +353-1-8968443 | suttonpd at tcd.ie | http://www.ctvr.ie
>> 
>> PGP Key ID: 7762DDC6
>> Fingerprint: 3EB5 39A3 C33D 68DE FA0F 1B81 C422 DC6C 7762 DDC6
>> ________________________________________________________________
>> 
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 7
>> Date: Fri, 20 Sep 2013 09:21:06 -0600
>> From: sean rivera <sean.rivera at colorado.edu>
>> To: usrp-users at lists.ettus.com
>> Subject: [USRP-users] Fwd:  Testing the USRP2 FPGA code
>> Message-ID:
>>         <CAJVxSh-1SEAuDP-GfMAZMRrwOmqB2F4+5q1CZVcZ7Axj4a3PDw at mail.gmail.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>> 
>> Yes the pre-existing data replaces live off the air signals. It is a simple
>>  capture from the default DSP-chain, that I know the results of.
>> Unfortunately my model needs around 1000 samples of 32 byte data to per
>> result it returns. In order to run a full simulation its around 30,000
>> times that which makes a test bench unfeasible. Previously I've tested it
>> by transmitting the data out through on USRP and then receiving it on
>> another, however that is not an optimal solution.
>> 
>> 
>> On Thu, Sep 19, 2013 at 6:32 PM, Ian Buckley <ianb at ionconcepts.com> wrote:
>> 
>> > The "pre-existing data" replaces live off the air signals?
>> >
>> > In which case why not just simulate your module in Verilog with a test
>> > bench?
>> >
>> > There are a variety of ways to do something similar in the live FPGA image
>> > but it's hard to make a detailed suggestion without knowing more about the
>> > data you wish to feed the block, or how the block will interact with other
>> > logic.
>> >
>> > On Sep 19, 2013, at 4:57 PM, sean rivera <sean.rivera at colorado.edu> wrote:
>> >
>> > > Hello list,
>> > >
>> > > I'm having a bit of a challenge in testing custom firmware for the FPGA.
>> > For my custom module I have a Matlab module used to determine position
>> > coordinates over GPS that I have converted to Verilog. In order to test
>> > this module I would like to take preexisting data, and pass it into my
>> > Verilog code, either using the SD card or Ethernet of the N210. Is there
>> > anyway to do this?
>> > >
>> > > Thanks for you help,
>> > > --
>> > > ~Sean Rivera
>> > > ECEN, CSCI,APPM
>> > > _______________________________________________
>> > > USRP-users mailing list
>> > > USRP-users at lists.ettus.com
>> > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >
>> >
>> 
>> 
>> --
>> ~Sean Rivera
>> ECEN, CSCI,APPM
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130920/8eced62e/attachment-0001.html>
>> 
>> ------------------------------
>> 
>> Subject: Digest Footer
>> 
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> 
>> 
>> ------------------------------
>> 
>> End of USRP-users Digest, Vol 37, Issue 18
>> ******************************************
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130925/77e07edf/attachment-0002.html>


More information about the USRP-users mailing list