[USRP-users] packet transmission question

bob wole bnwole at gmail.com
Wed Sep 25 03:36:15 EDT 2013


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


More information about the USRP-users mailing list