[USRP-users] packet transmission question

bob wole bnwole at gmail.com
Fri Sep 20 13:28:51 EDT 2013


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
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130920/6a056b45/attachment-0002.html>


More information about the USRP-users mailing list