Re: [USRP-users] N310 time offset between TX RF Outputs

[Marcus D. Leech via USRP-users]

On 11/08/2018 03:13 PM, Serge Malo via USRP-users wrote:

Hi all,

Thanks for the extra comments Mark.

Just to be clear: I'm not talking about phase offset between RF 
Outputs, but only time offset.
(Once time offset is fixed, we will try to have phase-coherent RF 
outputs).


I have made other measurements today, here are the results.
I'm transmitting a signal at 1.57542GHz, and a second signal at 1.2276GHz.
Sample Rate on N310: 25.6Msps (MCR of 153.6Mhz)
Sample Rate on X300: 25.0Msps (MCR of 200Mhz)
Using External Clock and External PPS from Octoclock
1) Using X300 (RF A and RF B) and UHD 3.10.3.0, we see les than 3ns 
time offset (See image here: link 
)
2) Using X300 (RF A and RF B) and UHD 3.13.1.0 RC1, we see 7300us time 
offset (See image here: link 
)
3) Using N310 (RF 0 and RF 2) and UHD 3.13.1.0 RC1, we also see 7300us 
time offset.


Important: the "timed commands" seem to be broken in UHD 3.13.1.0, 
either for X300 or N310.
When we change the time_spec of the first "send" call, the time at 
which the samples are transmitted does not change. For example, I 
tried to set tie_spec to 10s, but the Tx starts right away. This was 
working correctly with UHD 3.10.3.0


Let me know if you have ideas I could try.

Best regards,
Serge

Serge:

The fact that this affects both X310 and N310 is a bit disturbing--the 
device-side codebase is quite different on the two boxes.  I'm engaging

  Ettus R internally to see if this can be reproduced.





On Thu, 8 Nov 2018 at 14:44, Mark Wagner > wrote:


Here's a google drive link with images of the phase drift between
rx4 and tx 1&2, and tx 3&4

https://drive.google.com/open?id=1Bg6F0WHzzwVhpFBlrlfqJgpGg9JtTczH

On Thu, Nov 8, 2018 at 11:32 AM Mark Wagner mailto:m2wag...@eng.ucsd.edu>> wrote:

Hi guys,

Maybe I could jump in and share some related results. My group
has been developing a MIMO system with N310 units. We did a
test sounding recently where we sent 4, length 4096,
orthogonal multitone signals from the transmitters to the
receivers and processed the data by finding the channel
response between each transmitter and receiver pair (16 in
total) and recording the magnitude and phase of the arrival
spikes between each pair.

We took several seconds of data and processed it in length
4096 chunks (around 1500 chunks in total) and looked at the
phase difference between transmitter pairs as time progressed.
Since transmitters 1 and 2 are sharing an LO and our setup was
not moved during the sounding we expected to see a constant
phase difference between transmitters 1 and 2 and a single
receiver (same with tx 3 and 4), but we saw some drift. Worse
yet, not all LO sharing pairs drifted in the same way, some
didn't drift much at all while some drifted in linear or
non-linear patterns.

If you're all fine with me breaking the rules I can attach
some png images of what we recorded so you can see what it
looks like. Later this week we'll repeat the experiment but
leave the machines running longer to see if the drift
diminishes as the machines run longer.

Cheers,
-Mark





On Thu, Nov 8, 2018 at 9:03 AM Daniel Jepson via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:

Hi Serge,

Are you measuring the phase offset between the TX0 and TX2
signals in a steady-state case, or the time difference in
the start of those signals?

In the former case, your results could be impacted by the
lack of internal LO sharing between daughterboards. I
would fully expect an unknown phase offset between
channels 0 and 2 every time you reconfigure the device. In
the latter case, it sounds like a start trigger mismatch
like Marcus mentioned.

Can you share more details as to how you're measuring the
phase offset?

Thanks,
-Daniel



On Thu, Nov 8, 2018 at 5:30 AM Serge Malo via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:

Yes: we are using UHD 3.13.1.0 RC1, with the latest
file system image

I can try to use lower tx start times to see if the
time offset changes with that.

Thanks,
Serge

On Wed, 7 Nov 2018 at 21:44, Marcus D. Leech
mailto:patchvonbr...@gmail.com>> wrote:

On 11/07/2018 09:31 PM, Serge Malo wrote:

Yes:
We only use one streamer for all RF outputs, 

Re: [USRP-users] N310 time offset between TX RF Outputs

[Serge Malo via USRP-users]

Hi all,

Thanks for the extra comments Mark.

Just to be clear: I'm not talking about phase offset between RF Outputs,
but only time offset.
(Once time offset is fixed, we will try to have phase-coherent RF outputs).

I have made other measurements today, here are the results.
I'm transmitting a signal at 1.57542GHz, and a second signal at 1.2276GHz.
Sample Rate on N310: 25.6Msps (MCR of 153.6Mhz)
Sample Rate on X300: 25.0Msps (MCR of 200Mhz)
Using External Clock and External PPS from Octoclock
1) Using X300 (RF A and RF B) and UHD 3.10.3.0, we see les than 3ns time
offset (See image here: link

)
2) Using X300 (RF A and RF B) and UHD 3.13.1.0 RC1, we see 7300us time
offset (See image here: link

)
3) Using N310 (RF 0 and RF 2) and UHD 3.13.1.0 RC1, we also see 7300us time
offset.

Important: the "timed commands" seem to be broken in UHD 3.13.1.0, either
for X300 or N310.
When we change the time_spec of the first "send" call, the time at which
the samples are transmitted does not change. For example, I tried to set
tie_spec to 10s, but the Tx starts right away. This was working correctly
with UHD 3.10.3.0

Let me know if you have ideas I could try.

Best regards,
Serge


On Thu, 8 Nov 2018 at 14:44, Mark Wagner  wrote:

> Here's a google drive link with images of the phase drift between rx4 and
> tx 1&2, and tx 3&4
>
> https://drive.google.com/open?id=1Bg6F0WHzzwVhpFBlrlfqJgpGg9JtTczH
>
> On Thu, Nov 8, 2018 at 11:32 AM Mark Wagner  wrote:
>
>> Hi guys,
>>
>> Maybe I could jump in and share some related results. My group has been
>> developing a MIMO system with N310 units. We did a test sounding recently
>> where we sent 4, length 4096, orthogonal multitone signals from the
>> transmitters to the receivers and processed the data by finding the channel
>> response between each transmitter and receiver pair (16 in total) and
>> recording the magnitude and phase of the arrival spikes between each pair.
>>
>> We took several seconds of data and processed it in length 4096 chunks
>> (around 1500 chunks in total) and looked at the phase difference between
>> transmitter pairs as time progressed. Since transmitters 1 and 2 are
>> sharing an LO and our setup was not moved during the sounding we expected
>> to see a constant phase difference between transmitters 1 and 2 and a
>> single receiver (same with tx 3 and 4), but we saw some drift. Worse yet,
>> not all LO sharing pairs drifted in the same way, some didn't drift much at
>> all while some drifted in linear or non-linear patterns.
>>
>> If you're all fine with me breaking the rules I can attach some png
>> images of what we recorded so you can see what it looks like. Later this
>> week we'll repeat the experiment but leave the machines running longer to
>> see if the drift diminishes as the machines run longer.
>>
>> Cheers,
>> -Mark
>>
>>
>>
>>
>>
>> On Thu, Nov 8, 2018 at 9:03 AM Daniel Jepson via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi Serge,
>>>
>>> Are you measuring the phase offset between the TX0 and TX2 signals in a
>>> steady-state case, or the time difference in the start of those signals?
>>>
>>> In the former case, your results could be impacted by the lack of
>>> internal LO sharing between daughterboards. I would fully expect an unknown
>>> phase offset between channels 0 and 2 every time you reconfigure the
>>> device. In the latter case, it sounds like a start trigger mismatch like
>>> Marcus mentioned.
>>>
>>> Can you share more details as to how you're measuring the phase offset?
>>>
>>> Thanks,
>>> -Daniel
>>>
>>>
>>>
>>> On Thu, Nov 8, 2018 at 5:30 AM Serge Malo via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Yes: we are using UHD 3.13.1.0 RC1, with the latest file system image

 I can try to use lower tx start times to see if the time offset changes
 with that.

 Thanks,
 Serge

 On Wed, 7 Nov 2018 at 21:44, Marcus D. Leech 
 wrote:

> On 11/07/2018 09:31 PM, Serge Malo wrote:
>
> Yes:
> We only use one streamer for all RF outputs, and send time_spec with
> each call to the streamer's send method.
> We reset the internal time with set_time_unkown_pps(0), and program
> the first samples to be streamed at a time of 0.800s.
> It is basically the same code we used on the X300/X310.
>
> Thanks,
> Serge
>
> Well, that is quite strange--the magnitude of the time offsets is
> larger than I would expect.
>
> Perhaps someone from the N310 team can comment?
>
> Serge, are you using the latest UHD and system image versions for the
> N310?
>
>
>
> On Wed, 7 Nov 2018 at 21:03, Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 11/07/2018 08:53 PM, Serge Malo via USRP-users wrote:

Re: [USRP-users] N310 time offset between TX RF Outputs

[Mark Wagner via USRP-users]

Here's a google drive link with images of the phase drift between rx4 and
tx 1&2, and tx 3&4

https://drive.google.com/open?id=1Bg6F0WHzzwVhpFBlrlfqJgpGg9JtTczH

On Thu, Nov 8, 2018 at 11:32 AM Mark Wagner  wrote:

> Hi guys,
>
> Maybe I could jump in and share some related results. My group has been
> developing a MIMO system with N310 units. We did a test sounding recently
> where we sent 4, length 4096, orthogonal multitone signals from the
> transmitters to the receivers and processed the data by finding the channel
> response between each transmitter and receiver pair (16 in total) and
> recording the magnitude and phase of the arrival spikes between each pair.
>
> We took several seconds of data and processed it in length 4096 chunks
> (around 1500 chunks in total) and looked at the phase difference between
> transmitter pairs as time progressed. Since transmitters 1 and 2 are
> sharing an LO and our setup was not moved during the sounding we expected
> to see a constant phase difference between transmitters 1 and 2 and a
> single receiver (same with tx 3 and 4), but we saw some drift. Worse yet,
> not all LO sharing pairs drifted in the same way, some didn't drift much at
> all while some drifted in linear or non-linear patterns.
>
> If you're all fine with me breaking the rules I can attach some png images
> of what we recorded so you can see what it looks like. Later this week
> we'll repeat the experiment but leave the machines running longer to see if
> the drift diminishes as the machines run longer.
>
> Cheers,
> -Mark
>
>
>
>
>
> On Thu, Nov 8, 2018 at 9:03 AM Daniel Jepson via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi Serge,
>>
>> Are you measuring the phase offset between the TX0 and TX2 signals in a
>> steady-state case, or the time difference in the start of those signals?
>>
>> In the former case, your results could be impacted by the lack of
>> internal LO sharing between daughterboards. I would fully expect an unknown
>> phase offset between channels 0 and 2 every time you reconfigure the
>> device. In the latter case, it sounds like a start trigger mismatch like
>> Marcus mentioned.
>>
>> Can you share more details as to how you're measuring the phase offset?
>>
>> Thanks,
>> -Daniel
>>
>>
>>
>> On Thu, Nov 8, 2018 at 5:30 AM Serge Malo via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Yes: we are using UHD 3.13.1.0 RC1, with the latest file system image
>>>
>>> I can try to use lower tx start times to see if the time offset changes
>>> with that.
>>>
>>> Thanks,
>>> Serge
>>>
>>> On Wed, 7 Nov 2018 at 21:44, Marcus D. Leech 
>>> wrote:
>>>
 On 11/07/2018 09:31 PM, Serge Malo wrote:

 Yes:
 We only use one streamer for all RF outputs, and send time_spec with
 each call to the streamer's send method.
 We reset the internal time with set_time_unkown_pps(0), and program the
 first samples to be streamed at a time of 0.800s.
 It is basically the same code we used on the X300/X310.

 Thanks,
 Serge

 Well, that is quite strange--the magnitude of the time offsets is
 larger than I would expect.

 Perhaps someone from the N310 team can comment?

 Serge, are you using the latest UHD and system image versions for the
 N310?



 On Wed, 7 Nov 2018 at 21:03, Marcus D. Leech via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> On 11/07/2018 08:53 PM, Serge Malo via USRP-users wrote:
>
> Hi all,
>
> We are trying to send 4 synchronous signals from the 4 Tx ports of the
> N310.
> We are using UHD 3.13.1.0 RC1 under Ubuntu.
> Central Freq = 1575.42 GHz and 1227.6 MHz
> Master Clock rate = 153.6 MHz
>
> We would expect to have less than 3ns offset between all TX ports of
> the N310, like we do with the X300/X310. However, we have measured 4700ns
> between TX RF ports 0 and port 2.
> We have tried the next things with no more success:
> - Sampling rates of 25.6MSps, 38.4Msps, 76.8Msps
> - Init with the device options "init_cals=ALL" and "force_reinit=1"
> - Use the internal GPSDO
> - Use clock_source=external and time_source=external (from an
> Octoclock).
>
> Can you tell us:
> -What time offset between TX RF ports we should expect to achieve?
> -Is there anything else we can try to reduce this offset to less than
> 3ns?
>
> Best regards,
> Serge
>
>
> How are you setting up your TX streamer?   Is it time-tagged to start
> at a particular device time?
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>

 ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>

Re: [USRP-users] N310 time offset between TX RF Outputs

[Mark Wagner via USRP-users]

Hi guys,

Maybe I could jump in and share some related results. My group has been
developing a MIMO system with N310 units. We did a test sounding recently
where we sent 4, length 4096, orthogonal multitone signals from the
transmitters to the receivers and processed the data by finding the channel
response between each transmitter and receiver pair (16 in total) and
recording the magnitude and phase of the arrival spikes between each pair.

We took several seconds of data and processed it in length 4096 chunks
(around 1500 chunks in total) and looked at the phase difference between
transmitter pairs as time progressed. Since transmitters 1 and 2 are
sharing an LO and our setup was not moved during the sounding we expected
to see a constant phase difference between transmitters 1 and 2 and a
single receiver (same with tx 3 and 4), but we saw some drift. Worse yet,
not all LO sharing pairs drifted in the same way, some didn't drift much at
all while some drifted in linear or non-linear patterns.

If you're all fine with me breaking the rules I can attach some png images
of what we recorded so you can see what it looks like. Later this week
we'll repeat the experiment but leave the machines running longer to see if
the drift diminishes as the machines run longer.

Cheers,
-Mark





On Thu, Nov 8, 2018 at 9:03 AM Daniel Jepson via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Serge,
>
> Are you measuring the phase offset between the TX0 and TX2 signals in a
> steady-state case, or the time difference in the start of those signals?
>
> In the former case, your results could be impacted by the lack of internal
> LO sharing between daughterboards. I would fully expect an unknown phase
> offset between channels 0 and 2 every time you reconfigure the device. In
> the latter case, it sounds like a start trigger mismatch like Marcus
> mentioned.
>
> Can you share more details as to how you're measuring the phase offset?
>
> Thanks,
> -Daniel
>
>
>
> On Thu, Nov 8, 2018 at 5:30 AM Serge Malo via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Yes: we are using UHD 3.13.1.0 RC1, with the latest file system image
>>
>> I can try to use lower tx start times to see if the time offset changes
>> with that.
>>
>> Thanks,
>> Serge
>>
>> On Wed, 7 Nov 2018 at 21:44, Marcus D. Leech 
>> wrote:
>>
>>> On 11/07/2018 09:31 PM, Serge Malo wrote:
>>>
>>> Yes:
>>> We only use one streamer for all RF outputs, and send time_spec with
>>> each call to the streamer's send method.
>>> We reset the internal time with set_time_unkown_pps(0), and program the
>>> first samples to be streamed at a time of 0.800s.
>>> It is basically the same code we used on the X300/X310.
>>>
>>> Thanks,
>>> Serge
>>>
>>> Well, that is quite strange--the magnitude of the time offsets is larger
>>> than I would expect.
>>>
>>> Perhaps someone from the N310 team can comment?
>>>
>>> Serge, are you using the latest UHD and system image versions for the
>>> N310?
>>>
>>>
>>>
>>> On Wed, 7 Nov 2018 at 21:03, Marcus D. Leech via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 On 11/07/2018 08:53 PM, Serge Malo via USRP-users wrote:

 Hi all,

 We are trying to send 4 synchronous signals from the 4 Tx ports of the
 N310.
 We are using UHD 3.13.1.0 RC1 under Ubuntu.
 Central Freq = 1575.42 GHz and 1227.6 MHz
 Master Clock rate = 153.6 MHz

 We would expect to have less than 3ns offset between all TX ports of
 the N310, like we do with the X300/X310. However, we have measured 4700ns
 between TX RF ports 0 and port 2.
 We have tried the next things with no more success:
 - Sampling rates of 25.6MSps, 38.4Msps, 76.8Msps
 - Init with the device options "init_cals=ALL" and "force_reinit=1"
 - Use the internal GPSDO
 - Use clock_source=external and time_source=external (from an
 Octoclock).

 Can you tell us:
 -What time offset between TX RF ports we should expect to achieve?
 -Is there anything else we can try to reduce this offset to less than
 3ns?

 Best regards,
 Serge


 How are you setting up your TX streamer?   Is it time-tagged to start
 at a particular device time?



 ___
 USRP-users mailing list
 USRP-users@lists.ettus.com
 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

>>>
>>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
> --
>
> Daniel Jepson
>
> Digital Hardware Engineer
>
> National Instruments
>
>
>
> O: +1.512.683.6163
>
> daniel.jep...@ni.com
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 
Mark Wagner
University of California San Diego

[USRP-users] Streaming Data From GNURadio

[John Medrano via USRP-users]

Hello,

We would like to repeatably stream a fixed number of data points (i.e. 4096
points) at a sample rate of 40 MS/s. The file format is in complex binary.

I suspect there are several ways that this can be optimized.

If we have a flow graph:

FileSource -> UHDRadio

or with RFNoc

FileSource -> FIFO -> DUC ->RFNocRadio

Two areas where this process can be improved:

1. The file source can buffer data into memory.
2. The file format can be changed to ComplexInt16 to reduce data conversion.

I hope these assumptions are correct.

So my question is:

1. Is there a way to convert this file to ComplexInt16 and replay from file
source?
2. How do we get file source to buffer the data?

Thank you,
John
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N310 time offset between TX RF Outputs

[Daniel Jepson via USRP-users]

Hi Serge,

Are you measuring the phase offset between the TX0 and TX2 signals in a
steady-state case, or the time difference in the start of those signals?

In the former case, your results could be impacted by the lack of internal
LO sharing between daughterboards. I would fully expect an unknown phase
offset between channels 0 and 2 every time you reconfigure the device. In
the latter case, it sounds like a start trigger mismatch like Marcus
mentioned.

Can you share more details as to how you're measuring the phase offset?

Thanks,
-Daniel



On Thu, Nov 8, 2018 at 5:30 AM Serge Malo via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Yes: we are using UHD 3.13.1.0 RC1, with the latest file system image
>
> I can try to use lower tx start times to see if the time offset changes
> with that.
>
> Thanks,
> Serge
>
> On Wed, 7 Nov 2018 at 21:44, Marcus D. Leech 
> wrote:
>
>> On 11/07/2018 09:31 PM, Serge Malo wrote:
>>
>> Yes:
>> We only use one streamer for all RF outputs, and send time_spec with each
>> call to the streamer's send method.
>> We reset the internal time with set_time_unkown_pps(0), and program the
>> first samples to be streamed at a time of 0.800s.
>> It is basically the same code we used on the X300/X310.
>>
>> Thanks,
>> Serge
>>
>> Well, that is quite strange--the magnitude of the time offsets is larger
>> than I would expect.
>>
>> Perhaps someone from the N310 team can comment?
>>
>> Serge, are you using the latest UHD and system image versions for the
>> N310?
>>
>>
>>
>> On Wed, 7 Nov 2018 at 21:03, Marcus D. Leech via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 11/07/2018 08:53 PM, Serge Malo via USRP-users wrote:
>>>
>>> Hi all,
>>>
>>> We are trying to send 4 synchronous signals from the 4 Tx ports of the
>>> N310.
>>> We are using UHD 3.13.1.0 RC1 under Ubuntu.
>>> Central Freq = 1575.42 GHz and 1227.6 MHz
>>> Master Clock rate = 153.6 MHz
>>>
>>> We would expect to have less than 3ns offset between all TX ports of the
>>> N310, like we do with the X300/X310. However, we have measured 4700ns
>>> between TX RF ports 0 and port 2.
>>> We have tried the next things with no more success:
>>> - Sampling rates of 25.6MSps, 38.4Msps, 76.8Msps
>>> - Init with the device options "init_cals=ALL" and "force_reinit=1"
>>> - Use the internal GPSDO
>>> - Use clock_source=external and time_source=external (from an Octoclock).
>>>
>>> Can you tell us:
>>> -What time offset between TX RF ports we should expect to achieve?
>>> -Is there anything else we can try to reduce this offset to less than
>>> 3ns?
>>>
>>> Best regards,
>>> Serge
>>>
>>>
>>> How are you setting up your TX streamer?   Is it time-tagged to start at
>>> a particular device time?
>>>
>>>
>>>
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 

Daniel Jepson

Digital Hardware Engineer

National Instruments



O: +1.512.683.6163

daniel.jep...@ni.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N310 time offset between TX RF Outputs

[Ali Dormiani via USRP-users]

Your time offset is in line with the time offset we are seeing in our
N310's. I think this is because TX 0, 1 is on one RF chain (with its own
local oscillator) while TX 2, 3 is on its own RF chain with a separate LO.

As far as time delay or how long it takes for the RF components to warm up
TX 0,1 and TX 2,3 might as well be entirely separate devices? Not sure if
my thoughts are logically sound though.

On Thu, Nov 8, 2018 at 3:29 AM Serge Malo via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Yes: we are using UHD 3.13.1.0 RC1, with the latest file system image
>
> I can try to use lower tx start times to see if the time offset changes
> with that.
>
> Thanks,
> Serge
>
> On Wed, 7 Nov 2018 at 21:44, Marcus D. Leech 
> wrote:
>
>> On 11/07/2018 09:31 PM, Serge Malo wrote:
>>
>> Yes:
>> We only use one streamer for all RF outputs, and send time_spec with each
>> call to the streamer's send method.
>> We reset the internal time with set_time_unkown_pps(0), and program the
>> first samples to be streamed at a time of 0.800s.
>> It is basically the same code we used on the X300/X310.
>>
>> Thanks,
>> Serge
>>
>> Well, that is quite strange--the magnitude of the time offsets is larger
>> than I would expect.
>>
>> Perhaps someone from the N310 team can comment?
>>
>> Serge, are you using the latest UHD and system image versions for the
>> N310?
>>
>>
>>
>> On Wed, 7 Nov 2018 at 21:03, Marcus D. Leech via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 11/07/2018 08:53 PM, Serge Malo via USRP-users wrote:
>>>
>>> Hi all,
>>>
>>> We are trying to send 4 synchronous signals from the 4 Tx ports of the
>>> N310.
>>> We are using UHD 3.13.1.0 RC1 under Ubuntu.
>>> Central Freq = 1575.42 GHz and 1227.6 MHz
>>> Master Clock rate = 153.6 MHz
>>>
>>> We would expect to have less than 3ns offset between all TX ports of the
>>> N310, like we do with the X300/X310. However, we have measured 4700ns
>>> between TX RF ports 0 and port 2.
>>> We have tried the next things with no more success:
>>> - Sampling rates of 25.6MSps, 38.4Msps, 76.8Msps
>>> - Init with the device options "init_cals=ALL" and "force_reinit=1"
>>> - Use the internal GPSDO
>>> - Use clock_source=external and time_source=external (from an Octoclock).
>>>
>>> Can you tell us:
>>> -What time offset between TX RF ports we should expect to achieve?
>>> -Is there anything else we can try to reduce this offset to less than
>>> 3ns?
>>>
>>> Best regards,
>>> Serge
>>>
>>>
>>> How are you setting up your TX streamer?   Is it time-tagged to start at
>>> a particular device time?
>>>
>>>
>>>
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Cordic Algorithm quadrant selection

[imran qureshi via USRP-users]

Thanks very much Ian, this makes very true sense now you explained well in
short summary.
Now if we change the same algo to find the Cartesian to polar
conversion.The theory says,
check the Yi for the trig equation selection as we do previously with Zi in
rotation mode,
but what would be the equations now to select the quadrants as compared to
previous selection criteria?

Immi


On Wed, Nov 7, 2018 at 2:26 PM Ian Buckley  wrote:

> In brief, (since the CORDIC algorithm is a simple and fun one to simulate
> standalone and look at the functions generated as analog waveforms)
> The zi input (fed from the DDC/DUC phase accumulator) represents an angle
> as a fraction of 2*Pi.
> The symmetry of the sin/cos functions is exploited so that the CORDIC
> algorithm is used to derive functions for 0->Pi angles and thus we strip
> the MSB of zi and pass the remixing bits as the initial angle value for
> rotation.
> Looking at the 2 MSB’s of zi we can determine which of the 4 (pi/2)
> quadrants our desired phase rotation lies in and, given that quadrant 3 is
> identical to quadrant 1 negated, and quadrant 2 is equal to quadrant 4
> negated, we negate the input signals (xi,yi) we feed to the CORDIC
> appropriately which has the same effect as if we negated the internal trig
> functions we are generating inside the CORDIC blocks.
>
> Hope that makes sense.
> -Ian
>
>
> On Nov 6, 2018, at 5:54 PM, Robin Coxe via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hi Immi.   This paper is one of the better overviews of the CORDIC
> algorithm in FPGAs:  http://www.andraka.com/files/crdcsrvy.pdf
>
> Also, if you search the archives of this list, there are threads regarding
> the specific application of the CORDIC algorithm in the USRP FPGA designs.
> For example:
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2013-April/034497.html
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-December/039692.html
>
> -Robin
>
> On Tue, Nov 6, 2018 at 8:58 AM imran qureshi via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi,
>> I want to learn the cordic implementation of the duc_chain, and want to
>> understand how the quadrant selection is done in the cordic_z.v code for
>> vector rotation.(fpga
>> 
>> /usrp3
>> 
>> /lib
>> 
>> /dsp
>> 
>> /cordic_z24.v)
>> code snippet
>>
>>   case (zi[zwidth-1:zwidth-2])
>> 2'b00, 2'b11 :
>>   begin
>> x0 <= xi_ext;
>> y0 <= yi_ext;
>>   end
>> 2'b01, 2'b10 :
>>   begin
>> x0 <= -xi_ext;
>> y0 <= -yi_ext;
>>   end
>>   endcase // case(zi[zwidth-1:zwidth-2])
>> Regards,
>> Immi
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Reusing UHD transport to send signal samples between processes

[Keith k via USRP-users]

Hello Piotr

I can't answer your question, but I'm wondering if you plan to make this
project open source? I would find a tool like this very valuable.

On Thu, Nov 8, 2018 at 10:48 AM Piotr Krysik via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello everyone,
>
> I'm considering to create virtual SDR device based on UHD (as libuhd
> module) and virtual radio channel (probably a GNU Radio based program).
> The main aim is to enable (at least partial) testing of programs using
> without need to run actual hardware (i.e. to run base transceiver
> station and at digital signal level connect to it mobile stations -
> purely in software).
>
> I need some way to send digital samples between fake SDR devices and
> fake radio radio channel and I'm looking at different, already existing
> options. One of them is to reuse one of transports from UHD
> (https://files.ettus.com/manual/namespaceuhd_1_1transport.html). I'm
> trying to find something from what I can start and at the moment it
> doesn't seem to be straightforward (possibly because I don't know too
> much about how UHD transports work).
>
> So I decided to ask these questions here:
>
> 1. Is there some example how to use any of UHD transports to send signal
> samples, meta-data and control information (carriers, gains, etc.) from
> one process to another on the same host or over network (at the moment
> anything is good for me)?
>
> 2. If there is no, can such example be easily created?
>
> 3. If not - does it make sense to try to reuse UHD transports for the
> described purpose? Maybe there exists something more universal or maybe
> it's better to do it from scratch?
>
> --
> Best Regards,
> Piotr Krysik
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 
-Keith Kotyk
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Memory limitations for N310 using replay block

[Lundberg, Daniel via USRP-users]

Wade,
Great, thanks!  At least in about 30 minutes of preliminary testing, that does 
seem to have solved the issue.

I am successfully able to replay a 750 MB file (~1.5 seconds of data at 125 
MS/s) on the N310.  Now on to tuning!
-Dan

From: Wade Fife 
Sent: Wednesday, November 7, 2018 7:00 PM
To: Lundberg, Daniel 
Cc: usrp-users 
Subject: Re: [USRP-users] Memory limitations for N310 using replay block

Dan,

I've been testing and I was able to reproduce something that might be your 
issue. I'm still testing, but if you want to try the following change, it might 
fix your issue. Simply delete this line and rebuild the FPGA:

https://github.com/EttusResearch/fpga/blob/4f25ed1b4129c94677b66540894a03a4f80306ea/usrp3/lib/axi/axi_replay.v#L758

I'll have some other fixes/improvements soon.

Thanks,

Wade

On Mon, Nov 5, 2018 at 3:39 PM Wade Fife 
mailto:wade.f...@ettus.com>> wrote:
I assume the N3xx code used to use the 2x version and it wasn't renamed when it 
was switched to 4x. Normally the instance name would correspond to the module 
name.

I'll see if I can reproduce this on an N310.

Wade

On Mon, Nov 5, 2018 at 1:58 PM Lundberg, Daniel 
mailto:daniel.lundb...@gtri.gatech.edu>> wrote:
Hi Wade,
Thanks Wade, I’ve been digging around in those files, and I agree that if it is 
invoking the 4x64 version it looks like the limit is 1 GB, not 32 MB.  I am 
somewhat confused by the existence of both a 2x and a 4x axi_intercon set of 
files for the N310.  In particular, in n3xx_core.v, there is a line:

axi_intercon_4x64_256_bd_wrapper axi_intercon_2x64_256_bd_i (…

Why isn’t this:

axi_intercon_4x64_256_bd_wrapper axi_intercon_4x64_256_bd_i (…

Thank you,
Dan

From: Wade Fife mailto:wade.f...@ettus.com>>
Sent: Monday, November 5, 2018 12:26 PM
To: Lundberg, Daniel 
mailto:daniel.lundb...@gtri.gatech.edu>>
Cc: usrp-users mailto:USRP-users@lists.ettus.com>>
Subject: Re: [USRP-users] Memory limitations for N310 using replay block

Hi Dan,

You can use the viv_modify_bd command to open the BD file in Vivado then use 
the "Address Editor" tab to change how slave ports map to the master port, 
which connects to DRAM. For example, after running "setupenv.sh" you could run 
"viv_modify_bd 
ip/axi_intercon_2x64_256_bd/axi_intercon_4x64_256_bd.bd
 N310" to edit the 
axi_intercon_2x64_256_bd.bd file. If you're 
feeling adventurous, then you could also look at the XML contents of the BD 
file directly. The relevant tag is "addressSpaces" then the "addressOffset" and 
"range" tags, but it's probably safer to let Vivado make any changes.

However, as far as I can tell, axi_intercon_4x64_256_bd should already be 
configured to handle more than 32 MiB. If that's the file you're using (which 
is what's normally referenced in n3xx_core.v) then something else might be 
going on. But the 2x64 version looks like it's limited to 32 MiB.

Thanks,

Wade

On Fri, Nov 2, 2018 at 5:07 PM Lundberg, Daniel via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
I am following the instructions for using the replay block with the N310 
(https://kb.ettus.com/Using_the_RFNoC_Replay_Block).  I have established that I 
can replay play a relatively small file (~5 MB) without issues.  However, for 
much larger files, I get some strange artifacts on the output (periodic garbage 
mixed in with the desired data), and I think I am hitting the memory 
limitations described in the following note:

“Note: The amount of memory available to the Replay block is limited by the 
size of the DRAM on the USRP and how the memory interface is configured on the 
USRP. For example, the axi_intercon_2x64_128_bd IP used by the X310 is 
configured to give each connected device an address space of 32 MiB. As a 
result, the Replay block will be limited to this amount of memory. The 
axi_intercon_2x64_128_bd file must be modified if more than 32 MiB needs to be 
buffered.”

Can someone comment on the hard limitations in the N310?  It has 2 GB of DRAM, 
but I do not know how much of that is available, and I also do not know how to 
interpret the equivalent axi_intercon*** files for the N310. Also, there are 
two axi_intercon* files for the N310, 
axi_intercon_2x64_256_bd.bd and 
axi_intercon_4x64_256.bd.bd.  Does someone 
have an example of how the appropriate file has been modified for an N310?

Alternatively, can someone suggest an application note or something similar to 
get me started on how to modify the memory management of the USRP?

Thank you,
Dan
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] [Discuss-gnuradio] Specify Versions of UHD and GRC for PyBombs

[Zhongyuan Zhao via USRP-users]

Hi Marcus,

Thank you for the detailed explanation. I think this is very helpful.
The reason I need a specific version of UHD is to work with a remote N310.
It seems that to work with a N310, the versions of Ubuntu (sdimg), FPGA
image, and UHD on the host computer must all match.
However, since my N310 is deployed remotely, I can not update its sdimg
often. I wonder if sdimg and FPGA image could be de-coupled in the future.
Correct me if I am wrong about this.

Many thanks!

Best Regards,
Zhongyuan Zhao

PhD Candidate,
Department of Computer Science & Engineering,
University of Nebraska-Lincoln
Suite 117, Schorr Center,
Lincoln, Nebraska 68588-0115


On Thu, Nov 8, 2018 at 2:17 AM Müller, Marcus (CEL)  wrote:

> Hi Zhonghyuan,
>
> if you don't want the current git master version, chances are you
> should just stick with a release from the maint-3.7 branch. Have a look
> at the "gnuradio-stable" (instead of gnuradio / gnuradio-default)
> recipe. You can specify branches and/or tags with the "gitbranch"
> property.
>
> By the way, PyBOMBS is a cool piece of hardware if you're planning to
> juggle many prefixes, or you need to do cross-platform development.
>
> If you're on current debian/fedora/gentoo (not really on Ubuntu), you
> can just get the latest stable release via your distro's package
> management, which will inherently work with your distro's UHD version.
> That's the recommended way of using GNU Radio and UHD, unless you need
> to modify the source code of UHD or GNU Radio. For end users, our
> philosophy is that they shouldn't have to build GNU Radio from source.
>
> If you actually want to use a different UHD than what was shipped with
> your distro (e.g. the UHD packages that Ettus offers on their own repo,
> or built from source), then yes, you'll have to build GNU Radio
> yourself.
>
> I'm going to stress this again, because people will read this in the
> future:
> *If you're an end-user and want to work _WITH_ GNU Radio and UHD, just
> get a current Linux distro (debian is well-supported, for example), and
> install their GNU Radio package.*
>
> In your case, you said you wanted specific versions of GNU Radio and
> UHD. So, the procedure I'd personally recommend is the following:
>
> 1. (important) uninstall anything GNU Radio and UHD-dependent that was
> installed through your operating system's package management. Yes.
> Don't skip this step. Any package with "gnuradio", "gr-" or "uhd" in
> its name must be uninstalled.
> 2. install the UHD version you want (and only that) the way you want.
> Personally,
> git clone https://github.com/EttusResearch/uhd && cd uhd/host && \
> git checkout {the git tag you want} && mkdir build && cd build && \
> cmake .. && make -j8 && sudo make install
> makes me happier than using pyBOMBS.
> 3. install the GNU Radio version you want.
> git clone https://github.com/gnuradio/gnuradio && cd gnuradio && \
> git checkout {the git tag you want} && mkdir build && cd build && \
> cmake .. && make -j8 && sudo make install
>
> Done; honestly, for single-installation source builds, you really don't
> need PyBOMBS just to build GNU Radio. PyBOMBS is awesome at installing
> complete development dependency environments into prefixes, but hey,
> you've got a Linux distro, and on debianoids, e.g "apt build-dep
> gnuradio" will do the same (but beware, you'll need to remove the
> debian-supplied uhd packages afterwards).
>
> Best regards,
> Marcus –don't build from source if you don't have to– Müller
> On Wed, 2018-11-07 at 15:32 -0600, Zhongyuan Zhao wrote:
> > Hi,
> >
> > It seems that PyBombs always install the latest version of UHD and GRC.
> Is there a way to specify older versions in the installation?
> > If the only way is installing from the source, how to make sure the
> version of UHD work with GRC?
> > Thank you!
> >
> > Best Regards,
> > Zhongyuan Zhao
> >
> > PhD Candidate,
> > Department of Computer Science & Engineering,
> > University of Nebraska-Lincoln
> > Suite 117, Schorr Center,
> > Lincoln, Nebraska 68588-0115
> > ___
> > Discuss-gnuradio mailing list
> > discuss-gnura...@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] rfnoc build works for E310, doesn't meet timing with X310

[Jason Matusiak via USRP-users]

Thanks for looking at this EJ.
 
The outputs does go straight to the axi_wrapper, so that was good news.  Out of 
curiosity, besides cleanliness, what does the axi_flop buy that issuing a one 
clock register event doesn't?
 
Yeah, I didn't like that multiply when I put it in, but like I said, it got the 
job done quickly :).  Of course I had good intentions to come back and do 
everything the right way, but.  I haven't touched it until I wanted to test 
on the X310.
 
 
- Original Message - Subject: Re: Re: [USRP-users] rfnoc build 
works for E310, doesn't meet timing with X310
From: "EJ Kreinar" 
Date: 11/8/18 10:02 am
To: "Jason Matusiak" 
Cc: "USRP-users@lists.ettus.com" 

   First, it's really not failing by much -- you got under 7 ns, so it's 
*almost* there.
 
Two suggestions:
 
1. If the input/output of the block does not go directly into axi_wrapper, try 
adding an axi_flop at the end to insert a one-cycle delay. This could break up 
a critical path if you have a few "0-delay" blocks in a row. If this goes into 
axi_wrapper, it should probably be fine
 
2. This is a smoking gun: 
 
`(vector_cnt == (of_n-1)*keep_m)`
 
See if you can find a way around the multiply operation and I expect it will 
work just fine.
 
EJ
 
 



  On Thu, Nov 8, 2018 at 9:47 AM Jason Matusiak  
wrote:
 Gents, thanks for the input.  I actually found the section I needed in the 
timing report just before you guys wrote (I hate trying to sift through those). 
 It is indeed my block that is causing issues.  I was getting ready to try to 
break out my testbench and start playing with it by adding some registers to 
see if that helps (the testbench worked before, so I won't know if this helps 
timing, but I could at least make sure I didn't break anything.
 
Excellent point on the clock differences.  I was stuck down a rabbit hole as to 
why the E310 would be fine, but not the X310, but that makes sense.  I was just 
getting lucky I guess at the slower clock rates.
 
Here is the relevant timing issue:
---
>From Clock: ce_clk
 To Clock: ce_clk
 Setup : 8006 Failing Endpoints, Worst Slack -2.711ns, Total Violation 
-4376.156ns
Hold : 0 Failing Endpoints, Worst Slack 0.035ns, Total Violation 0.000ns
PW : 0 Failing Endpoints, Worst Slack 1.565ns, Total Violation 0.000ns
---
 
Max Delay Paths
--
Slack (VIOLATED) : -2.711ns (required time - arrival time)
 Source: x300_core/inst_keepMinN/sr_n/out_reg[2]_replica/C
 (rising edge-triggered cell FDRE clocked by ce_clk {rise@0.000ns fall@2.333ns 
period=4.667ns})
 Destination: x300_core/inst_keepMinN/keepMinN/vector_cnt_reg[12]/R
 (rising edge-triggered cell FDRE clocked by ce_clk {rise@0.000ns fall@2.333ns 
period=4.667ns})
 Path Group: ce_clk
 Path Type: Setup (Max at Slow Process Corner)
 Requirement: 4.667ns (ce_clk rise@4.667ns - ce_clk rise@0.000ns)
 Data Path Delay: 6.966ns (logic 5.340ns (76.654%) route 1.626ns (23.346%))
 Logic Levels: 10 (CARRY4=5 DSP48E1=2 LUT1=1 LUT3=1 LUT5=1)
 Clock Path Skew: -0.053ns (DCD - SCD + CPR)
 Destination Clock Delay (DCD): -1.659ns = ( 3.008 - 4.667 )
 Source Clock Delay (SCD): -2.028ns
 Clock Pessimism Removal (CPR): -0.422ns
 Clock Uncertainty: 0.054ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE
 Total System Jitter (TSJ): 0.071ns
 Discrete Jitter (DJ): 0.082ns
 Phase Error (PE): 0.000ns
 (and it continues with more stuff that I don't think is particularly useful).
  
 So, it is plain to see that something I am doing inside my block is very 
stupid (though accomplishes what I wanted.  I can post the code, so maybe 
someone can spot the issue (I really think it is a registering problem that I 
need to do on the output side).  Please excuse the simplicity of the code, I 
needed to through something together VERY fast, and instead of being elegant, I 
went with easy to code up.
  
 The block's title is a little misleading, it basically keeps M vectors out of 
N vectors.  So if the vector size is 512, and M==2 and N==10.  I will pass 
through 1024 samples, and then dump the next 4096 samples.  Then wash, rinse, 
repeat.  The verilog is attached since I was having trouble keeping formatting 
when I pasted it here.
 
 
 
 
 
 
- Original Message - Subject: Re: [USRP-users] rfnoc build 
works for E310, doesn't meet timing with X310
From: "EJ Kreinar" 
Date: 11/8/18 9:09 am
To: "Jason Matusiak" 
Cc: "USRP-users@lists.ettus.com" 

  Hi Jason,  
That actually makes sense to me... Bus clk on the e310 is usually 50 MHz if I 
remember correctly (and if it didn't change), and the max radio_clk is 
something like 64ish MHz.
 
Max clock rates on the x310 are, I believe, more like 200-215 MHz. So logic in 
the x310 nominally needs to settle within 5 ns while logic on 

Re: [USRP-users] rfnoc build works for E310, doesn't meet timing with X310

[Jon Pendlum via USRP-users]

Hey Jason,

Do you need to be able to run the block at 200 MSPS? If not, I would
suggest changing all instances of ce_clk to bus_clk in your block. bus_clk
runs at ~187.5 MHz versus ~214 MHz for ce_clk, so it could give you the
extra margin you need to make timing.

You can also make the change by editing rfnoc_ce_auto_inst_x310.v and
setting your block's ce_clk input to bus_clk. I mention this, because if
you still fail timing, you can try setting ce_clk to ddr3_axi_clk (150 MHz)
or bus_clk_div2 (~93 MHz). The downside is your block's throughput will
decrease accordingly and any changes to rfnoc_ce_auto_inst_x310.v are
overwritten the next time you run uhd_image_builder.

Jonathon

On Fri, Nov 9, 2018 at 12:03 AM EJ Kreinar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> First, it's really not failing by much -- you got under 7 ns, so it's
> *almost* there.
>
> Two suggestions:
>
> 1. If the input/output of the block does not go directly into axi_wrapper,
> try adding an axi_flop at the end to insert a one-cycle delay. This could
> break up a critical path if you have a few "0-delay" blocks in a row. If
> this goes into axi_wrapper, it should probably be fine
>
> 2. This is a smoking gun:
>
> `(vector_cnt == (of_n-1)*keep_m)`
>
> See if you can find a way around the multiply operation and I expect it
> will work just fine.
>
> EJ
>
>
>
> On Thu, Nov 8, 2018 at 9:47 AM Jason Matusiak <
> ja...@gardettoengineering.com> wrote:
>
>> Gents, thanks for the input.  I actually found the section I needed in
>> the timing report just before you guys wrote (I hate trying to sift through
>> those).  It is indeed my block that is causing issues.  I was getting ready
>> to try to break out my testbench and start playing with it by adding some
>> registers to see if that helps (the testbench worked before, so I won't
>> know if this helps timing, but I could at least make sure I didn't break
>> anything.
>>
>> Excellent point on the clock differences.  I was stuck down a rabbit hole
>> as to why the E310 would be fine, but not the X310, but that makes sense.
>> I was just getting lucky I guess at the slower clock rates.
>>
>> Here is the relevant timing issue:
>>
>>
>> ---
>> From Clock: ce_clk
>> To Clock: ce_clk
>>
>> Setup : 8006 Failing Endpoints, Worst Slack -2.711ns, Total Violation
>> -4376.156ns
>> Hold : 0 Failing Endpoints, Worst Slack 0.035ns, Total Violation 0.000ns
>> PW : 0 Failing Endpoints, Worst Slack 1.565ns, Total Violation 0.000ns
>>
>> ---
>>
>>
>> Max Delay Paths
>>
>> --
>> Slack (VIOLATED) : -2.711ns (required time - arrival time)
>> Source: x300_core/inst_keepMinN/sr_n/out_reg[2]_replica/C
>> (rising edge-triggered cell FDRE clocked by ce_clk {rise@0.000ns
>> fall@2.333ns period=4.667ns})
>> Destination: x300_core/inst_keepMinN/keepMinN/vector_cnt_reg[12]/R
>> (rising edge-triggered cell FDRE clocked by ce_clk {rise@0.000ns
>> fall@2.333ns period=4.667ns})
>> Path Group: ce_clk
>> Path Type: Setup (Max at Slow Process Corner)
>> Requirement: 4.667ns (ce_clk rise@4.667ns - ce_clk rise@0.000ns)
>> Data Path Delay: 6.966ns (logic 5.340ns (76.654%) route 1.626ns (23.346%))
>> Logic Levels: 10 (CARRY4=5 DSP48E1=2 LUT1=1 LUT3=1 LUT5=1)
>> Clock Path Skew: -0.053ns (DCD - SCD + CPR)
>> Destination Clock Delay (DCD): -1.659ns = ( 3.008 - 4.667 )
>> Source Clock Delay (SCD): -2.028ns
>> Clock Pessimism Removal (CPR): -0.422ns
>> Clock Uncertainty: 0.054ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE
>> Total System Jitter (TSJ): 0.071ns
>> Discrete Jitter (DJ): 0.082ns
>> Phase Error (PE): 0.000ns
>>
>> (and it continues with more stuff that I don't think is particularly
>> useful).
>>
>>
>>
>> So, it is plain to see that something I am doing inside my block is very
>> stupid (though accomplishes what I wanted.  I can post the code, so maybe
>> someone can spot the issue (I really think it is a registering problem that
>> I need to do on the output side).  Please excuse the simplicity of the
>> code, I needed to through something together VERY fast, and instead of
>> being elegant, I went with easy to code up.
>>
>>
>>
>> The block's title is a little misleading, it basically keeps M vectors
>> out of N vectors.  So if the vector size is 512, and M==2 and N==10.  I
>> will pass through 1024 samples, and then dump the next 4096 samples.  Then
>> wash, rinse, repeat.  The verilog is attached since I was having trouble
>> keeping formatting when I pasted it here.
>>
>>
>>
>>
>>
>>
>> - Original Message -
>> Subject: Re: [USRP-users] rfnoc build works for E310, doesn't meet timing
>> with X310
>> From: "EJ Kreinar" 
>> Date: 11/8/18 9:09 am
>> To: "Jason Matusiak" 
>> Cc: "USRP-users@lists.ettus.com" 
>>
>> Hi Jason,
>>
>> That 

Re: [USRP-users] rfnoc build works for E310, doesn't meet timing with X310

[EJ Kreinar via USRP-users]

First, it's really not failing by much -- you got under 7 ns, so it's
*almost* there.

Two suggestions:

1. If the input/output of the block does not go directly into axi_wrapper,
try adding an axi_flop at the end to insert a one-cycle delay. This could
break up a critical path if you have a few "0-delay" blocks in a row. If
this goes into axi_wrapper, it should probably be fine

2. This is a smoking gun:

`(vector_cnt == (of_n-1)*keep_m)`

See if you can find a way around the multiply operation and I expect it
will work just fine.

EJ



On Thu, Nov 8, 2018 at 9:47 AM Jason Matusiak 
wrote:

> Gents, thanks for the input.  I actually found the section I needed in the
> timing report just before you guys wrote (I hate trying to sift through
> those).  It is indeed my block that is causing issues.  I was getting ready
> to try to break out my testbench and start playing with it by adding some
> registers to see if that helps (the testbench worked before, so I won't
> know if this helps timing, but I could at least make sure I didn't break
> anything.
>
> Excellent point on the clock differences.  I was stuck down a rabbit hole
> as to why the E310 would be fine, but not the X310, but that makes sense.
> I was just getting lucky I guess at the slower clock rates.
>
> Here is the relevant timing issue:
>
>
> ---
> From Clock: ce_clk
> To Clock: ce_clk
>
> Setup : 8006 Failing Endpoints, Worst Slack -2.711ns, Total Violation
> -4376.156ns
> Hold : 0 Failing Endpoints, Worst Slack 0.035ns, Total Violation 0.000ns
> PW : 0 Failing Endpoints, Worst Slack 1.565ns, Total Violation 0.000ns
>
> ---
>
>
> Max Delay Paths
>
> --
> Slack (VIOLATED) : -2.711ns (required time - arrival time)
> Source: x300_core/inst_keepMinN/sr_n/out_reg[2]_replica/C
> (rising edge-triggered cell FDRE clocked by ce_clk {rise@0.000ns
> fall@2.333ns period=4.667ns})
> Destination: x300_core/inst_keepMinN/keepMinN/vector_cnt_reg[12]/R
> (rising edge-triggered cell FDRE clocked by ce_clk {rise@0.000ns
> fall@2.333ns period=4.667ns})
> Path Group: ce_clk
> Path Type: Setup (Max at Slow Process Corner)
> Requirement: 4.667ns (ce_clk rise@4.667ns - ce_clk rise@0.000ns)
> Data Path Delay: 6.966ns (logic 5.340ns (76.654%) route 1.626ns (23.346%))
> Logic Levels: 10 (CARRY4=5 DSP48E1=2 LUT1=1 LUT3=1 LUT5=1)
> Clock Path Skew: -0.053ns (DCD - SCD + CPR)
> Destination Clock Delay (DCD): -1.659ns = ( 3.008 - 4.667 )
> Source Clock Delay (SCD): -2.028ns
> Clock Pessimism Removal (CPR): -0.422ns
> Clock Uncertainty: 0.054ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE
> Total System Jitter (TSJ): 0.071ns
> Discrete Jitter (DJ): 0.082ns
> Phase Error (PE): 0.000ns
>
> (and it continues with more stuff that I don't think is particularly
> useful).
>
>
>
> So, it is plain to see that something I am doing inside my block is very
> stupid (though accomplishes what I wanted.  I can post the code, so maybe
> someone can spot the issue (I really think it is a registering problem that
> I need to do on the output side).  Please excuse the simplicity of the
> code, I needed to through something together VERY fast, and instead of
> being elegant, I went with easy to code up.
>
>
>
> The block's title is a little misleading, it basically keeps M vectors out
> of N vectors.  So if the vector size is 512, and M==2 and N==10.  I will
> pass through 1024 samples, and then dump the next 4096 samples.  Then wash,
> rinse, repeat.  The verilog is attached since I was having trouble keeping
> formatting when I pasted it here.
>
>
>
>
>
>
> - Original Message -
> Subject: Re: [USRP-users] rfnoc build works for E310, doesn't meet timing
> with X310
> From: "EJ Kreinar" 
> Date: 11/8/18 9:09 am
> To: "Jason Matusiak" 
> Cc: "USRP-users@lists.ettus.com" 
>
> Hi Jason,
>
> That actually makes sense to me... Bus clk on the e310 is usually 50 MHz
> if I remember correctly (and if it didn't change), and the max radio_clk is
> something like 64ish MHz.
>
> Max clock rates on the x310 are, I believe, more like 200-215 MHz. So
> logic in the x310 nominally needs to settle within 5 ns while logic on the
> e310 can have a luxurious 15-20 ns. Xilinx will try very hard to optimize
> timing and the build for x310 could take a LONG time.
>
> If you can access the timing report, it will often show critical paths,
> but the text report is often unintelligible to me. I have also built in GUI
> mode before (like setting up a ILA core) because the Vivado interface for
> organizing and understanding timing failures are actually pretty helpful.
>
> I'd also suggest, if you'd like some verilog input, to send the relevant
> code you think might continue to the timing errors, and we can take a look
> for ideas? It could 

Re: [USRP-users] rfnoc build works for E310, doesn't meet timing with X310

[Jason Matusiak via USRP-users]

Gents, thanks for the input.  I actually found the section I needed in the 
timing report just before you guys wrote (I hate trying to sift through those). 
 It is indeed my block that is causing issues.  I was getting ready to try to 
break out my testbench and start playing with it by adding some registers to 
see if that helps (the testbench worked before, so I won't know if this helps 
timing, but I could at least make sure I didn't break anything.
 
Excellent point on the clock differences.  I was stuck down a rabbit hole as to 
why the E310 would be fine, but not the X310, but that makes sense.  I was just 
getting lucky I guess at the slower clock rates.
 
Here is the relevant timing issue:
---
>From Clock: ce_clk
 To Clock: ce_clk
 Setup : 8006 Failing Endpoints, Worst Slack -2.711ns, Total Violation 
-4376.156ns
Hold : 0 Failing Endpoints, Worst Slack 0.035ns, Total Violation 0.000ns
PW : 0 Failing Endpoints, Worst Slack 1.565ns, Total Violation 0.000ns
---
 
Max Delay Paths
--
Slack (VIOLATED) : -2.711ns (required time - arrival time)
 Source: x300_core/inst_keepMinN/sr_n/out_reg[2]_replica/C
 (rising edge-triggered cell FDRE clocked by ce_clk {rise@0.000ns fall@2.333ns 
period=4.667ns})
 Destination: x300_core/inst_keepMinN/keepMinN/vector_cnt_reg[12]/R
 (rising edge-triggered cell FDRE clocked by ce_clk {rise@0.000ns fall@2.333ns 
period=4.667ns})
 Path Group: ce_clk
 Path Type: Setup (Max at Slow Process Corner)
 Requirement: 4.667ns (ce_clk rise@4.667ns - ce_clk rise@0.000ns)
 Data Path Delay: 6.966ns (logic 5.340ns (76.654%) route 1.626ns (23.346%))
 Logic Levels: 10 (CARRY4=5 DSP48E1=2 LUT1=1 LUT3=1 LUT5=1)
 Clock Path Skew: -0.053ns (DCD - SCD + CPR)
 Destination Clock Delay (DCD): -1.659ns = ( 3.008 - 4.667 )
 Source Clock Delay (SCD): -2.028ns
 Clock Pessimism Removal (CPR): -0.422ns
 Clock Uncertainty: 0.054ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE
 Total System Jitter (TSJ): 0.071ns
 Discrete Jitter (DJ): 0.082ns
 Phase Error (PE): 0.000ns
 (and it continues with more stuff that I don't think is particularly useful).
  
 So, it is plain to see that something I am doing inside my block is very 
stupid (though accomplishes what I wanted.  I can post the code, so maybe 
someone can spot the issue (I really think it is a registering problem that I 
need to do on the output side).  Please excuse the simplicity of the code, I 
needed to through something together VERY fast, and instead of being elegant, I 
went with easy to code up.
  
 The block's title is a little misleading, it basically keeps M vectors out of 
N vectors.  So if the vector size is 512, and M==2 and N==10.  I will pass 
through 1024 samples, and then dump the next 4096 samples.  Then wash, rinse, 
repeat.  The verilog is attached since I was having trouble keeping formatting 
when I pasted it here.
 
 
 
 
 
 
- Original Message - Subject: Re: [USRP-users] rfnoc build 
works for E310, doesn't meet timing with X310
From: "EJ Kreinar" 
Date: 11/8/18 9:09 am
To: "Jason Matusiak" 
Cc: "USRP-users@lists.ettus.com" 

  Hi Jason,  
That actually makes sense to me... Bus clk on the e310 is usually 50 MHz if I 
remember correctly (and if it didn't change), and the max radio_clk is 
something like 64ish MHz.
 
Max clock rates on the x310 are, I believe, more like 200-215 MHz. So logic in 
the x310 nominally needs to settle within 5 ns while logic on the e310 can have 
a luxurious 15-20 ns. Xilinx will try very hard to optimize timing and the 
build for x310 could take a LONG time.
 
If you can access the timing report, it will often show critical paths, but the 
text report is often unintelligible to me. I have also built in GUI mode before 
(like setting up a ILA core) because the Vivado interface for organizing and 
understanding timing failures are actually pretty helpful. 
 
I'd also suggest, if you'd like some verilog input, to send the relevant code 
you think might continue to the timing errors, and we can take a look for 
ideas? It could potentially lead to a quick solution if you're up for it. A 
MaxNinM block sounds like it could easily contribute to poor timing depending 
on the implementation.
 
EJ


  On Thu, Nov 8, 2018, 8:11 AM Jason Matusiak via USRP-users 
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
//
// Copyright 2016 Ettus Research
// Copyright 2018 Ettus Research, a National Instruments Company
//
// SPDX-License-Identifier: LGPL-3.0-or-later
//
// Note: n == 0 lets everything through.
// Warning: Sample / packet counts reset when n is changed, caution if changing 
during operation!

module keepMinN #(
  parameter WIDTH=16)(
  input clk, input reset,
  input [15:0] keep_m,
  input [15:0] of_n,
  input 

Re: [USRP-users] rfnoc build works for E310, doesn't meet timing with X310

[EJ Kreinar via USRP-users]

Hi Jason,

That actually makes sense to me... Bus clk on the e310 is usually 50 MHz if
I remember correctly (and if it didn't change), and the max radio_clk is
something like 64ish MHz.

Max clock rates on the x310 are, I believe, more like 200-215 MHz. So logic
in the x310 nominally needs to settle within 5 ns while logic on the e310
can have a luxurious 15-20 ns. Xilinx will try very hard to optimize timing
and the build for x310 could take a LONG time.

If you can access the timing report, it will often show critical paths, but
the text report is often unintelligible to me. I have also built in GUI
mode before (like setting up a ILA core) because the Vivado interface for
organizing and understanding timing failures are actually pretty helpful.

I'd also suggest, if you'd like some verilog input, to send the relevant
code you think might continue to the timing errors, and we can take a look
for ideas? It could potentially lead to a quick solution if you're up for
it. A MaxNinM block sounds like it could easily contribute to poor timing
depending on the implementation.

EJ


On Thu, Nov 8, 2018, 8:11 AM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com wrote:

> OK, this has befuddled me for 3 days and I can't seem to get past it.  I
> have a prefix that seems to work fine.
>
> Here are my working steps for building a bitfile on an E310:
> cd /opt/gnuradio/e300/src/uhd/fpga-src/usrp3/tools/scripts
>
> source ../../top/e300/setupenv.sh
>
> ./uhd_image_builder.py keepMinN ddc split_stream axi_fifo_loopback -d e310
> -t E310_RFNOC_sg3 -I /opt/gnuradio/e300/src/rfnoc-nocblocks
>
> This build and runs fine.  keepMinN is a small custom block I made that
> doesn't use much resources and has been working fine for weeks.
>
> Now, if I open a new terminal and run this:
>
> cd /opt/gnuradio/e300/src/uhd/fpga-src/usrp3/tools/scripts
> source ../../top/x300/setupenv.sh
> ./uhd_image_builder.py keepMinN ddc ddc split_stream axi_fifo_loopback -d
> x310 -t X310_RFNOC_XG -I /opt/gnuradio/e300/src/rfnoc-nocblocks -m 5
>
> it never seems to meet timing.  Now, I have done this with and without the
> "-m" directive, that doesn't seem to matter.  The only real difference in
> the command is the second ddc block.
>
> So what the heck could be causing these issues?  If anything, I would have
> expected the X310 build to be fine and the E310 to not meet timing.
> Another odd thing (though I am chalking it up to the X310 doing more) is
> that the X310 build is taking A LOT longer.  I don't recall it taking this
> long before, but I am not sure.
>
> It tell me to look at the report_timing_summary, but it hasn't updated yet
> (it keeps running for a bit after throwing the timing warning).  If I
> remember though, I think that the issue it had was with the ce_clk for some
> reason.
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] rfnoc build works for E310, doesn't meet timing with X310

[Wade Fife via USRP-users]

Hi Jason,

The longer run times might be explained by the tool struggling to meet
timing. I can't say off the top of my head what's wrong without looking at
the timing report. Do you have an updated post_route_timing_summary.rpt
file yet? Buried in there it should say exactly what's not meeting timing,
which should offer some clues. The source and destination clocks for the
failing signal path should be checked to make sure that those are correct
and properly constrained, since clock crossings are sometimes the cause of
unexpected timing errors.

Wade

On Thu, Nov 8, 2018 at 7:11 AM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> OK, this has befuddled me for 3 days and I can't seem to get past it.  I
> have a prefix that seems to work fine.
>
> Here are my working steps for building a bitfile on an E310:
> cd /opt/gnuradio/e300/src/uhd/fpga-src/usrp3/tools/scripts
>
> source ../../top/e300/setupenv.sh
>
> ./uhd_image_builder.py keepMinN ddc split_stream axi_fifo_loopback -d e310
> -t E310_RFNOC_sg3 -I /opt/gnuradio/e300/src/rfnoc-nocblocks
>
> This build and runs fine.  keepMinN is a small custom block I made that
> doesn't use much resources and has been working fine for weeks.
>
> Now, if I open a new terminal and run this:
>
> cd /opt/gnuradio/e300/src/uhd/fpga-src/usrp3/tools/scripts
> source ../../top/x300/setupenv.sh
> ./uhd_image_builder.py keepMinN ddc ddc split_stream axi_fifo_loopback -d
> x310 -t X310_RFNOC_XG -I /opt/gnuradio/e300/src/rfnoc-nocblocks -m 5
>
> it never seems to meet timing.  Now, I have done this with and without the
> "-m" directive, that doesn't seem to matter.  The only real difference in
> the command is the second ddc block.
>
> So what the heck could be causing these issues?  If anything, I would have
> expected the X310 build to be fine and the E310 to not meet timing.
> Another odd thing (though I am chalking it up to the X310 doing more) is
> that the X310 build is taking A LOT longer.  I don't recall it taking this
> long before, but I am not sure.
>
> It tell me to look at the report_timing_summary, but it hasn't updated yet
> (it keeps running for a bit after throwing the timing warning).  If I
> remember though, I think that the issue it had was with the ce_clk for some
> reason.
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] rfnoc build works for E310, doesn't meet timing with X310

[Jason Matusiak via USRP-users]

OK, this has befuddled me for 3 days and I can't seem to get past it.  I have a 
prefix that seems to work fine.
 
Here are my working steps for building a bitfile on an E310:
cd /opt/gnuradio/e300/src/uhd/fpga-src/usrp3/tools/scripts
 
source ../../top/e300/setupenv.sh
 
./uhd_image_builder.py keepMinN ddc split_stream axi_fifo_loopback -d e310 -t 
E310_RFNOC_sg3 -I /opt/gnuradio/e300/src/rfnoc-nocblocks
 
This build and runs fine.  keepMinN is a small custom block I made that doesn't 
use much resources and has been working fine for weeks.
 
Now, if I open a new terminal and run this:
 
cd /opt/gnuradio/e300/src/uhd/fpga-src/usrp3/tools/scripts
source ../../top/x300/setupenv.sh
./uhd_image_builder.py keepMinN ddc ddc split_stream axi_fifo_loopback -d x310 
-t X310_RFNOC_XG -I /opt/gnuradio/e300/src/rfnoc-nocblocks -m 5
 
it never seems to meet timing.  Now, I have done this with and without the "-m" 
directive, that doesn't seem to matter.  The only real difference in the 
command is the second ddc block.
 
So what the heck could be causing these issues?  If anything, I would have 
expected the X310 build to be fine and the E310 to not meet timing.  Another 
odd thing (though I am chalking it up to the X310 doing more) is that the X310 
build is taking A LOT longer.  I don't recall it taking this long before, but I 
am not sure.
 
It tell me to look at the report_timing_summary, but it hasn't updated yet (it 
keeps running for a bit after throwing the timing warning).  If I remember 
though, I think that the issue it had was with the ce_clk for some reason.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N310 time offset between TX RF Outputs

[Serge Malo via USRP-users]

Yes: we are using UHD 3.13.1.0 RC1, with the latest file system image

I can try to use lower tx start times to see if the time offset changes
with that.

Thanks,
Serge

On Wed, 7 Nov 2018 at 21:44, Marcus D. Leech 
wrote:

> On 11/07/2018 09:31 PM, Serge Malo wrote:
>
> Yes:
> We only use one streamer for all RF outputs, and send time_spec with each
> call to the streamer's send method.
> We reset the internal time with set_time_unkown_pps(0), and program the
> first samples to be streamed at a time of 0.800s.
> It is basically the same code we used on the X300/X310.
>
> Thanks,
> Serge
>
> Well, that is quite strange--the magnitude of the time offsets is larger
> than I would expect.
>
> Perhaps someone from the N310 team can comment?
>
> Serge, are you using the latest UHD and system image versions for the N310?
>
>
>
> On Wed, 7 Nov 2018 at 21:03, Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 11/07/2018 08:53 PM, Serge Malo via USRP-users wrote:
>>
>> Hi all,
>>
>> We are trying to send 4 synchronous signals from the 4 Tx ports of the
>> N310.
>> We are using UHD 3.13.1.0 RC1 under Ubuntu.
>> Central Freq = 1575.42 GHz and 1227.6 MHz
>> Master Clock rate = 153.6 MHz
>>
>> We would expect to have less than 3ns offset between all TX ports of the
>> N310, like we do with the X300/X310. However, we have measured 4700ns
>> between TX RF ports 0 and port 2.
>> We have tried the next things with no more success:
>> - Sampling rates of 25.6MSps, 38.4Msps, 76.8Msps
>> - Init with the device options "init_cals=ALL" and "force_reinit=1"
>> - Use the internal GPSDO
>> - Use clock_source=external and time_source=external (from an Octoclock).
>>
>> Can you tell us:
>> -What time offset between TX RF ports we should expect to achieve?
>> -Is there anything else we can try to reduce this offset to less than 3ns?
>>
>> Best regards,
>> Serge
>>
>>
>> How are you setting up your TX streamer?   Is it time-tagged to start at
>> a particular device time?
>>
>>
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Reusing UHD transport to send signal samples between processes

[Piotr Krysik via USRP-users]

Hello everyone,

I'm considering to create virtual SDR device based on UHD (as libuhd
module) and virtual radio channel (probably a GNU Radio based program).
The main aim is to enable (at least partial) testing of programs using
without need to run actual hardware (i.e. to run base transceiver
station and at digital signal level connect to it mobile stations -
purely in software).

I need some way to send digital samples between fake SDR devices and
fake radio radio channel and I'm looking at different, already existing
options. One of them is to reuse one of transports from UHD
(https://files.ettus.com/manual/namespaceuhd_1_1transport.html). I'm
trying to find something from what I can start and at the moment it
doesn't seem to be straightforward (possibly because I don't know too
much about how UHD transports work).

So I decided to ask these questions here:

1. Is there some example how to use any of UHD transports to send signal
samples, meta-data and control information (carriers, gains, etc.) from
one process to another on the same host or over network (at the moment
anything is good for me)?

2. If there is no, can such example be easily created?

3. If not - does it make sense to try to reuse UHD transports for the
described purpose? Maybe there exists something more universal or maybe
it's better to do it from scratch?

--
Best Regards,
Piotr Krysik

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com