<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">Hi Ian<div><br></div><div>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. <span class="HOEnZb"><font color="#888888"><br>

</font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Bob</div></font></span><div><div class="h5"><div><br></div><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

On 19.09.2013 17:52, Ian Buckley wrote:<br>
> Francois,<br>
> The logic that counts time and controls the presentation of TX data<br>
> to the DAC is located at the start of the USRP DSP chain after all the<br>
> transport, protocol and (de)packetizatiion logic. Between there and<br>
> the DAC are the CIC filter, both Halfband filters, and the CORDIC, all<br>
> of which contain some pipelining in the logic. For any given<br>
> interpolation ration from your GR sample rate to the DAC 100(or 64)MHz<br>
> sample rate, this logic should present a constant group delay. It<br>
> should change somewhat for different interpolation ratios due to<br>
> changes in the CIC configuration.<br>
> -Ian<br>
><br>
> On Sep 19, 2013, at 1:53 AM, Francois Quitin <<a href="mailto:fquitin@ulb.ac.be" target="_blank">fquitin@ulb.ac.be</a>><br>
> wrote:<br>
><br>
>> Hi all,<br>
>><br>
>> We have a little question for you: we use a USRP+WBX with a code<br>
>> derived from tx_timed_burst.cpp to create our custom transmitter, and<br>
>> we use another USRP that records the received data to a file.<br>
>><br>
>> When we look at the received signal, we observe a slight small<br>
>> staircase (around 30 samples long at 10MHz = 3us), as can be seen in<br>
>> the attached figure. It seems that our actual transmitted packet<br>
>> starts after this ?stair?. When we decrease the sample rate to 5MHz,<br>
>> the ?stair? is still 30 samples long (6us this time).<br>
>><br>
>> As we are working in a case where timing is very critical, this 3us<br>
>> delay is a bit of an issue (unless it?s constant in which case we can<br>
>> compensate for it). Any idea where this is coming from ?<br>
>><br>
>> Thanks!<br>
>> Francois<br>
>><br>
>> --<br>
>> Francois Quitin, Ph.D.<br>
>><br>
>> Research Fellow<br>
>> INFINITUS - Infocomm Centre of Excellence<br>
>> School of EEE, Nanyang Technological University<br>
>> 50 Nanyang Ave, S2-B4b-05<br>
>> Singapore 639798<br>
>> Phone: <a href="tel:%2B65-8502-3690" value="+6585023690" target="_blank">+65-8502-3690</a><br>
>> Email: <a href="mailto:fquitin@ntu.edu.sg" target="_blank">fquitin@ntu.edu.sg</a><br>
>> <rx_packet.png>_______________________________________________<br>
>> USRP-users mailing list<br>
>> <a href="mailto:USRP-users@lists.ettus.com" target="_blank">USRP-users@lists.ettus.com</a><br>
>> <a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br>
>> [1]<br>
><br>
><br>
><br>
> Links:<br>
> ------<br>
> [1] <a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Thu, 19 Sep 2013 17:32:39 -0700<br>
From: Ian Buckley <<a href="mailto:ianb@ionconcepts.com" target="_blank">ianb@ionconcepts.com</a>><br>
To: sean rivera <<a href="mailto:sean.rivera@colorado.edu" target="_blank">sean.rivera@colorado.edu</a>><br>
Cc: <a href="mailto:usrp-users@lists.ettus.com" target="_blank">usrp-users@lists.ettus.com</a><br>
Subject: Re: [USRP-users] Testing the USRP2 FPGA code<br>
Message-ID: <<a href="mailto:2403CABC-41FF-41A2-B3A0-27AB1932D041@ionconcepts.com" target="_blank">2403CABC-41FF-41A2-B3A0-27AB1932D041@ionconcepts.com</a>><br>
Content-Type: text/plain; charset=iso-8859-1<br>
<br>
The "pre-existing data" replaces live off the air signals?<br>
<br>
In which case why not just simulate your module in Verilog with a test bench?<br>
<br>
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.<br>



<br>
On Sep 19, 2013, at 4:57 PM, sean rivera <<a href="mailto:sean.rivera@colorado.edu" target="_blank">sean.rivera@colorado.edu</a>> wrote:<br>
<br>
> Hello list,<br>
><br>
> 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?<br>



><br>
> Thanks for you help,<br>
> --<br>
> ~Sean Rivera<br>
> ECEN, CSCI,APPM<br>
> _______________________________________________<br>
> USRP-users mailing list<br>
> <a href="mailto:USRP-users@lists.ettus.com" target="_blank">USRP-users@lists.ettus.com</a><br>
> <a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Thu, 19 Sep 2013 17:36:54 -0700<br>
From: Ian Buckley <<a href="mailto:ianb@ionconcepts.com" target="_blank">ianb@ionconcepts.com</a>><br>
To: fquitin <<a href="mailto:fquitin@ulb.ac.be" target="_blank">fquitin@ulb.ac.be</a>><br>
Cc: <a href="mailto:usrp-users@lists.ettus.com" target="_blank">usrp-users@lists.ettus.com</a><br>
Subject: Re: [USRP-users] packet transmission question<br>
Message-ID: <<a href="mailto:13C3A67B-ECF9-40DC-88D7-B4D816DC7276@ionconcepts.com" target="_blank">13C3A67B-ECF9-40DC-88D7-B4D816DC7276@ionconcepts.com</a>><br>
Content-Type: text/plain; charset=windows-1252<br>
<br>
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.<br>



-Ian<br>
<br>
<br>
<br>
On Sep 19, 2013, at 5:28 PM, fquitin <<a href="mailto:fquitin@ulb.ac.be" target="_blank">fquitin@ulb.ac.be</a>> wrote:<br>
<br>
> Hi Ian,<br>
><br>
> Thanks a lot for the info. So, for a given sample rate (and a given daughterboard model), this delay will be constant?<br>
><br>
> Thanks,<br>
> Francois<br>
><br>
><br>
> On 19.09.2013 17:52, Ian Buckley wrote:<br>
>> Francois,<br>
>> The logic that counts time and controls the presentation of TX data<br>
>> to the DAC is located at the start of the USRP DSP chain after all the<br>
>> transport, protocol and (de)packetizatiion logic. Between there and<br>
>> the DAC are the CIC filter, both Halfband filters, and the CORDIC, all<br>
>> of which contain some pipelining in the logic. For any given<br>
>> interpolation ration from your GR sample rate to the DAC 100(or 64)MHz<br>
>> sample rate, this logic should present a constant group delay. It<br>
>> should change somewhat for different interpolation ratios due to<br>
>> changes in the CIC configuration.<br>
>> -Ian<br>
>> On Sep 19, 2013, at 1:53 AM, Francois Quitin <<a href="mailto:fquitin@ulb.ac.be" target="_blank">fquitin@ulb.ac.be</a>> wrote:<br>
>>> Hi all,<br>
>>> 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.<br>
>>> 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).<br>



>>> 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 ?<br>
>>> Thanks!<br>
>>> Francois<br>
>>> --<br>
>>> Francois Quitin, Ph.D.<br>
>>> Research Fellow<br>
>>> INFINITUS - Infocomm Centre of Excellence<br>
>>> School of EEE, Nanyang Technological University<br>
>>> 50 Nanyang Ave, S2-B4b-05<br>
>>> Singapore 639798<br>
>>> Phone: <a href="tel:%2B65-8502-3690" value="+6585023690" target="_blank">+65-8502-3690</a><br>
>>> Email: <a href="mailto:fquitin@ntu.edu.sg" target="_blank">fquitin@ntu.edu.sg</a><br>
>>> <rx_packet.png>_______________________________________________<br>
>>> USRP-users mailing list<br>
>>> <a href="mailto:USRP-users@lists.ettus.com" target="_blank">USRP-users@lists.ettus.com</a><br>
>>> <a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a> [1]<br>
>> Links:<br>
>> ------<br>
>> [1] <a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Fri, 20 Sep 2013 11:36:42 +0100<br>
From: Paul Sutton <<a href="mailto:suttonpd@tcd.ie" target="_blank">suttonpd@tcd.ie</a>><br>
To: <a href="mailto:usrp-users@lists.ettus.com" target="_blank">usrp-users@lists.ettus.com</a><br>
Subject: [USRP-users] B200: Exploring the Wireless World<br>
Message-ID: <<a href="mailto:523C253A.1060305@tcd.ie" target="_blank">523C253A.1060305@tcd.ie</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Hi all,<br>
I love Balint's video showcasing the B200 - it looks like a brilliant<br>
piece of kit!<br>
Any chance you could list the software applications used in the video<br>
and let me know if/where they're available?<br>
<br>
Thanks,<br>
Paul<br>
<br>
--<br>
________________________________________________________________<br>
Paul Sutton Ph.D.<br>
<br>
CTVR, The Telecommunications Research Centre,<br>
Room 2.08, Dunlop House, Fenian Street,<br>
University of Dublin, Trinity College, Ireland.<br>
<br>
<a href="tel:%2B353-1-8968443" value="+35318968443" target="_blank">+353-1-8968443</a> | <a href="mailto:suttonpd@tcd.ie" target="_blank">suttonpd@tcd.ie</a> | <a href="http://www.ctvr.ie" target="_blank">http://www.ctvr.ie</a><br>


<br>
PGP Key ID: 7762DDC6<br>
Fingerprint: 3EB5 39A3 C33D 68DE FA0F 1B81 C422 DC6C 7762 DDC6<br>
________________________________________________________________<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Fri, 20 Sep 2013 09:21:06 -0600<br>
From: sean rivera <<a href="mailto:sean.rivera@colorado.edu" target="_blank">sean.rivera@colorado.edu</a>><br>
To: <a href="mailto:usrp-users@lists.ettus.com" target="_blank">usrp-users@lists.ettus.com</a><br>
Subject: [USRP-users] Fwd:  Testing the USRP2 FPGA code<br>
Message-ID:<br>
        <<a href="mailto:CAJVxSh-1SEAuDP-GfMAZMRrwOmqB2F4%2B5q1CZVcZ7Axj4a3PDw@mail.gmail.com" target="_blank">CAJVxSh-1SEAuDP-GfMAZMRrwOmqB2F4+5q1CZVcZ7Axj4a3PDw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Yes the pre-existing data replaces live off the air signals. It is a simple<br>
 capture from the default DSP-chain, that I know the results of.<br>
Unfortunately my model needs around 1000 samples of 32 byte data to per<br>
result it returns. In order to run a full simulation its around 30,000<br>
times that which makes a test bench unfeasible. Previously I've tested it<br>
by transmitting the data out through on USRP and then receiving it on<br>
another, however that is not an optimal solution.<br>
<br>
<br>
On Thu, Sep 19, 2013 at 6:32 PM, Ian Buckley <<a href="mailto:ianb@ionconcepts.com" target="_blank">ianb@ionconcepts.com</a>> wrote:<br>
<br>
> The "pre-existing data" replaces live off the air signals?<br>
><br>
> In which case why not just simulate your module in Verilog with a test<br>
> bench?<br>
><br>
> There are a variety of ways to do something similar in the live FPGA image<br>
> but it's hard to make a detailed suggestion without knowing more about the<br>
> data you wish to feed the block, or how the block will interact with other<br>
> logic.<br>
><br>
> On Sep 19, 2013, at 4:57 PM, sean rivera <<a href="mailto:sean.rivera@colorado.edu" target="_blank">sean.rivera@colorado.edu</a>> wrote:<br>
><br>
> > Hello list,<br>
> ><br>
> > I'm having a bit of a challenge in testing custom firmware for the FPGA.<br>
> For my custom module I have a Matlab module used to determine position<br>
> coordinates over GPS that I have converted to Verilog. In order to test<br>
> this module I would like to take preexisting data, and pass it into my<br>
> Verilog code, either using the SD card or Ethernet of the N210. Is there<br>
> anyway to do this?<br>
> ><br>
> > Thanks for you help,<br>
> > --<br>
> > ~Sean Rivera<br>
> > ECEN, CSCI,APPM<br>
> > _______________________________________________<br>
> > USRP-users mailing list<br>
> > <a href="mailto:USRP-users@lists.ettus.com" target="_blank">USRP-users@lists.ettus.com</a><br>
> > <a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br>
><br>
><br>
<br>
<br>
--<br>
~Sean Rivera<br>
ECEN, CSCI,APPM<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130920/8eced62e/attachment-0001.html" target="_blank">http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130920/8eced62e/attachment-0001.html</a>><br>



<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
USRP-users mailing list<br>
<a href="mailto:USRP-users@lists.ettus.com" target="_blank">USRP-users@lists.ettus.com</a><br>
<a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br>
<br>
<br>
------------------------------<br>
<br>
End of USRP-users Digest, Vol 37, Issue 18<br>
******************************************<br>
</blockquote></div><br></div></div></div></div></div></div>
</div><br></div>