Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: rx data structure of E310 (Martin Braun)
2. Re: USRP through Python (Martin Braun)
3. Re: USRP through Python (Dave NotTelling)
4. Re: [Discuss-gnuradio] Switching and high spike in spectrum
(bob wole)
5. Re: USRP through Python (Marcus M?ller)
6. AD9361's Calibration effect on phase (Jeremy Hershberger)
7. Re: AD9361's Calibration effect on phase ([email protected])
8. Extraneous tones on 200 MHz clock (Ed)
9. Re: AD9361's Calibration effect on phase (John Orlando)
10. Re: AD9361's Calibration effect on phase (Jeremy Hershberger)
11. Re: AD9361's Calibration effect on phase (Tom Tsou)
12. Re: USRP through Python (Richard Bell)
13. Re: E310 GPSDO clock reference (Derek Kozel)
14. Frequency Hopping Transmitter (Richard Bell)
15. Re: USRP through Python (Martin Braun)
16. Re: Frequency Hopping Transmitter (Tilla)
17. USRP x310 " ddr3_32bit: Code generation aborted: Unconfigured
MIG instance" (Ryan Marlow)
18. Re: USRP x310 " ddr3_32bit: Code generation aborted:
Unconfigured MIG instance" (Marcus M?ller)
19. Re: E310 GPSDO clock reference (Claudio Cicconetti)
20. monitor with E310/312 (john liu)
21. Re: monitor with E310/312 (Marcus M?ller)
22. Re: monitor with E310/312 (liu Jong)
23. Unable to create Vivado projekt or to build clean repo
(Patrick Berger)
24. FW: Fw: rfnoc-radio-redo 3f8c97e Modelsim DE 10.4C simulation
fails on noc_block_moving_avg_tb (Swanson, Craig)
25. USRP x310 " ddr3_32bit: Code generation aborted: Unconfigured
MIG instance" (Ryan Marlow)
26. X310 GPS LED (devin kelly)
----------------------------------------------------------------------
Message: 1
Date: Thu, 7 Apr 2016 10:12:03 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] rx data structure of E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
With radio-redo, you only need 1 core for 2 channels. You will get the
full feature set of RFNoC using this branch.
Cheers,
Martin
On 04/06/2016 09:49 PM, wwd via USRP-users wrote:
> Dear Marcus,
>
> Thanks again for your help. It works fine now.
>
> So right now I will pass to next step. And I need use double canal to
> receive two GPS signal from two separate antennas in E310. But by
> default, the RFNOC version radio-redo has included only one Radio core.
> How could I add the second radio core?
>
> If I use two radio cores, the frequency of ADC will be limited up to
> 30MHz, even I set the master_clock_rate=60MHz, am I correct?
>
> wwd
>
> On 16-03-31 11:28 AM, Marcus M?ller wrote:
>> Dear wwd,
>>
>> thank you for the descripton of your system! That is very helpful in
>> understanding how to be of assistance.
>>
>> On 31.03.2016 16:52, wwd wrote:
>>> For the first step, what I am trying to do is a very simple test
>>> implementation.
>>>
>>> I use a signal waveform generator to generate a sinus signal, then
>>> let it pass through E310 and save the samples to SD card. Finally, I
>>> try to plot the samples to verify all the configurations in E310 are
>>> corrects.
>>>
>>> So what I have done is:
>>>
>>> 1.
>>> Image Freq=80MHz, Vp-p=60mV
>>> 2.
>>> Image
>>>
>>> The center frequency=79.999MHz, I suppose I will get 1KHz after LO;
>> 10 MHz is a very high sampling rate for the E310, and usually the SD
>> card controller can not write that fast.
>>
>>> the sample rate=10MHz; Master_clock_rate=60MHz; and I use this type
>>> of SD card
>>> Image
>>> The UHD and FPGA, I am using the newest RFNOC
>>> version:uhd-rfnoc-radio-redo
>>> Therefore, I have some warning of overrun, but it doesn't have
>>> serious problem for my results.
>> I'd still recommend using a lower rate; there's no use in having 10
>> MS/s if your signal is limited to a little more than 1kHz!
>>
>> Notice that you'd see the sine at exactly 1kHz if the oscillator of
>> your signal generator and the E310 were perfectly in sync. In general,
>> they are not!
>>>
>>> 3. In MATLAB, I separate each 16bits data one for Q and one for I.
>>> Then I pull out the higher 12bits, because I think they are real
>>> data after ADC and do the two's complement to transfer it to
>>> signed int.
>>>
>> As said, no, you should definitely use all 16 bits!
>> Your ADC is in fact only a 12 bit ADC, but it runs at your master
>> clock rate of 60 MHz, so you get an oversampling of 6! That is an
>> advantage in SNR and in bit width, because the DSP chain uses good
>> filters to reduce the 60MS/s to 10MS/s, widening the bit width of the
>> samples in the process.
>>>
>>> 3. So finally I have two figures of sample data, one for I and the
>>> other is Q:
>>>
>>>
>>> Image
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> But they don't have the same amplitude, and don't have the different
>>> on phase. So I want to know what's the problem could be, am I missing
>>> something.
>> You really can't trust any data that was generated with overflows.
>> Reduce the sampling rate, don't throw away bits, and please verify the
>> problem persists.
>>> And I have another silly question is the master_clock_rate is the
>>> frequency applied on ADC and sample rate is between usrp and host pc,
>> exactly
>>> in E310 is between FPGA and ARM cpu,
>>> or it is the final frequency after the decimating filters after ADC?
>> sampling rate = what you get in Software = output of decimating
>> filters in DSP chain in Hardware/FPGA.
>> master clock rate = rate of ADC
>>
>> Best regards,
>> Marcus
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 2
Date: Thu, 7 Apr 2016 10:13:47 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP through Python
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
To clarify,
multi_usrp is not swigged, only the GNU Radio blocks. So the UHD
reference manual does not apply to Python-land.
Cheers,
M
On 04/06/2016 02:27 PM, Richard Bell via USRP-users wrote:
> Ah thank you! That python API is what I couldn't find, I kept getting
> stuck on the C++ API.
>
> Things are working now.
>
> Rich
>
> On Wed, Apr 6, 2016 at 2:09 PM, James Humphries
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi Rich,
>
> It looks like you have instantiated a USRP sink, which is for TX
> only. You will need to add a USRP source if you want to RX as well.
>
> See the GNU Radio Python API here for a list of all the functions
> and methods:
>
> http://gnuradio.org/doc/sphinx/#uhd-blocks
>
> -Trip
>
> On Wed, Apr 6, 2016 at 3:47 PM, Richard Bell via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi all,
>
> After instantiating a usrp object in Python, which I will call
> usrp here, I'm attempting to call
> usrp.get_rx_sensor("lo_locked") and usrp.get_rx_freq(), but I
> get the following error:
>
> AttributeError: 'usrp_sink_sptr' object has no attribute
> 'get_rx_freq'
>
> I can call usrp.set_center_freq(target_freq) just fine. How do I
> gain access to the full set of usrp methods through Python? Is
> there example code that demonstrates some of this? I've looked
> through the freq_hopping.py and usrp_spectrum_sense.py scripts
> extensively. They don't use much more then set_center_freq().
>
> Thanks,
> Rich
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 3
Date: Thu, 7 Apr 2016 13:44:42 -0400
From: Dave NotTelling <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP through Python
Message-ID:
<cak6gvupmsytovkg8kcv7d5txbbgz0pzjyeqrrhbfeefzfda...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Martin,
Is there a specific reason why the multi_usrp class isn't exposed to
Python?
-Dave
On Thu, Apr 7, 2016 at 1:13 PM, Martin Braun via USRP-users <
[email protected]> wrote:
> To clarify,
>
> multi_usrp is not swigged, only the GNU Radio blocks. So the UHD
> reference manual does not apply to Python-land.
>
> Cheers,
> M
>
> On 04/06/2016 02:27 PM, Richard Bell via USRP-users wrote:
> > Ah thank you! That python API is what I couldn't find, I kept getting
> > stuck on the C++ API.
> >
> > Things are working now.
> >
> > Rich
> >
> > On Wed, Apr 6, 2016 at 2:09 PM, James Humphries
> > <[email protected] <mailto:[email protected]>> wrote:
> >
> > Hi Rich,
> >
> > It looks like you have instantiated a USRP sink, which is for TX
> > only. You will need to add a USRP source if you want to RX as well.
> >
> > See the GNU Radio Python API here for a list of all the functions
> > and methods:
> >
> > http://gnuradio.org/doc/sphinx/#uhd-blocks
> >
> > -Trip
> >
> > On Wed, Apr 6, 2016 at 3:47 PM, Richard Bell via USRP-users
> > <[email protected] <mailto:[email protected]>>
> wrote:
> >
> > Hi all,
> >
> > After instantiating a usrp object in Python, which I will call
> > usrp here, I'm attempting to call
> > usrp.get_rx_sensor("lo_locked") and usrp.get_rx_freq(), but I
> > get the following error:
> >
> > AttributeError: 'usrp_sink_sptr' object has no attribute
> > 'get_rx_freq'
> >
> > I can call usrp.set_center_freq(target_freq) just fine. How do I
> > gain access to the full set of usrp methods through Python? Is
> > there example code that demonstrates some of this? I've looked
> > through the freq_hopping.py and usrp_spectrum_sense.py scripts
> > extensively. They don't use much more then set_center_freq().
> >
> > Thanks,
> > Rich
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected] <mailto:[email protected]>
> >
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160407/fae4c09b/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 7 Apr 2016 22:55:48 +0500
From: bob wole <[email protected]>
To: hanwen <[email protected]>
Cc: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] Switching and high spike
in spectrum
Message-ID:
<cagd3ozzwmcu3r+7wjxczkbnluxkfov_6temkoonrvwtkpjb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
Sorry for late reply. I was running out of time, so I used the offset tune
future of UHD to handle that spike. See the following link, hope it helps,
http://files.ettus.com/manual/structuhd_1_1tune__request__t.html
--
Bob
On Sat, Apr 2, 2016 at 7:41 AM, hanwen <[email protected]> wrote:
> Hi Bob,
>
> I came up with the same issue and I hope the DC leakage from Tx should
> disappear right after the Tx burst is finished, but acturally I still saw
> the strong DC during the pure Rx time lot.
> Have you got a solution for that? Thanks.
>
> Br, Hanwen
>
> 2014-10-31 7:31 GMT+01:00 bob wole <[email protected]>:
>
>>
>>
>>
>> On 10/29/2014 01:54 PM, bob wole via USRP-users wrote:
>>> >
>>> > USRPN210r4 with SBX
>>> >
>>> > I am observing a strong spike at the center of the receive spectrum
>>> > when I start burst transmission.
>>> >
>>> > My top flowgraph contains following two hierarchical blocks
>>> > 1) A transmitter flow graph with (tx_time, tx_sob, tx_eob)
>>> > 2) A receiver flow graph
>>> >
>>> > When I run top flowgrpah (without transmitting anything) and observe
>>> > the FFT of the received signal the spectrum does not contain high
>>> > spike in the center.
>>> >
>>> > But as soon as I start transmitting in burst mode I see a very high
>>> > spike in center of the received signal FFT spectrum. It looks like LO
>>> > (transmitter or receiver ) is being received? Which one is it ? And
>>> > why is it happening? How can I avoid it because it is affecting my
>>> > packets.
>>> >
>>> > When I apply the offset in digital using DDC/DUC, the spike moves out
>>> > of the band.
>>> >
>>> >
>>> > --
>>> > Bob
>>> >
>>> >
>>> > _______________________________________________
>>> > USRP-users mailing list
>>> > [email protected]
>>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>> That spike in the middle is a consequence of using direct conversion in
>>> both the RX and TX paths--it'll be there in both to some degree.
>>>
>>> You can use offset-tuning to move the DC offset outside your passband:
>>>
>>> http://files.ettus.com/manual/page_general.html
>>>
>>>
>>> In built-for-a-particular-purpose radios, there will also be undesired
>>> LO leakage and mixing products--those are generally dealt with using an
>>> application/band-specific filter to eliminate them. For
>>> general-purpose SDRs, that isn't possible to do "as manufactured", you
>>> have to deal
>>> with RF hygiene and plumbing issues yourself.
>>>
>>> So, moving the LO leakage outside your passband is part of the
>>> picture--use offset tuning for that. Then, if you have "this won't meet
>>> our hygiene requirements", you have to look at filtering.
>>>
>>> Another thing you really should do is to run the calibration utilities,
>>> which will attempt to balance I/Q amplitude and phase, which can improve
>>> some of these issues, but not, usually, eliminate them entirely.
>>>
>>>
>>>
>> Yes, I know that LO leakage/DC offset is an issue present in direct
>> conversion receiver. But as I mentioned earlier, the received spectrum
>> looks fine (a very little spike at DC around -70dB) while the burst
>> transmission is not running. The spike becomes much more significant ( high
>> spike at DC -20dB) when burst transmission (tx_time,tx_eob, tx_sob )
>> starts and all the spectrum just shifts up and down with it. I am using
>> TX/RX antenna in both usrp source and usrp sink. I want to know why the
>> burst transmission is affecting the received spectrum on the same node.
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> [email protected]
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160407/04695005/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 7 Apr 2016 20:01:47 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP through Python
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
multi_usrp is a UHD class, that the usrp_sink and _source use
*internally*; you can't use it standalone in GNU Radio, and that's why
there's no GNU Radio benefit from swigging it.
However, the usrp_sink and _source blocks wrap most of the relevant
methods, though under different names (set_gain[1] instead of
set_rx_gain or set_tx_gain, because if modifying a usrp_sink or
usrp_source, it's clear whether you want to modify TX or RX).
Best regards,
Marcus
[1] https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html
On 07.04.2016 19:44, Dave NotTelling via USRP-users wrote:
> Martin,
>
> Is there a specific reason why the multi_usrp class isn't exposed
> to Python?
>
> -Dave
>
> On Thu, Apr 7, 2016 at 1:13 PM, Martin Braun via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> To clarify,
>
> multi_usrp is not swigged, only the GNU Radio blocks. So the UHD
> reference manual does not apply to Python-land.
>
> Cheers,
> M
>
> On 04/06/2016 02:27 PM, Richard Bell via USRP-users wrote:
> > Ah thank you! That python API is what I couldn't find, I kept
> getting
> > stuck on the C++ API.
> >
> > Things are working now.
> >
> > Rich
> >
> > On Wed, Apr 6, 2016 at 2:09 PM, James Humphries
> > <[email protected] <mailto:[email protected]>
> <mailto:[email protected]
> <mailto:[email protected]>>> wrote:
> >
> > Hi Rich,
> >
> > It looks like you have instantiated a USRP sink, which is for TX
> > only. You will need to add a USRP source if you want to RX
> as well.
> >
> > See the GNU Radio Python API here for a list of all the
> functions
> > and methods:
> >
> > http://gnuradio.org/doc/sphinx/#uhd-blocks
> >
> > -Trip
> >
> > On Wed, Apr 6, 2016 at 3:47 PM, Richard Bell via USRP-users
> > <[email protected] <mailto:[email protected]>
> <mailto:[email protected]
> <mailto:[email protected]>>> wrote:
> >
> > Hi all,
> >
> > After instantiating a usrp object in Python, which I
> will call
> > usrp here, I'm attempting to call
> > usrp.get_rx_sensor("lo_locked") and usrp.get_rx_freq(),
> but I
> > get the following error:
> >
> > AttributeError: 'usrp_sink_sptr' object has no attribute
> > 'get_rx_freq'
> >
> > I can call usrp.set_center_freq(target_freq) just fine.
> How do I
> > gain access to the full set of usrp methods through
> Python? Is
> > there example code that demonstrates some of this? I've
> looked
> > through the freq_hopping.py and usrp_spectrum_sense.py
> scripts
> > extensively. They don't use much more then
> set_center_freq().
> >
> > Thanks,
> > Rich
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> <mailto:[email protected]>
> <mailto:[email protected]
> <mailto:[email protected]>>
> >
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected] <mailto:[email protected]>
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160407/e92b26cf/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 7 Apr 2016 14:08:46 -0400
From: Jeremy Hershberger <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] AD9361's Calibration effect on phase
Message-ID:
<CAMZiKLpG3PeiEswBYfuvj_r=ehuzojcme+fekoqb8ssvbhg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
The datasheet for the AD9361 lists an ability to remove DC level, I/Q
imbalance, and gain correction for both TX and RX, without discussing the
method used. Is it possible for this calibration circuitry to change the
TX and/or RX phase? If it does, should the phase change be repeatable from
run to run? Can this calibration be turned off, or in some way controlled
to achieve consistent performance?
Thanks,
-Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160407/a3d512d2/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 07 Apr 2016 15:00:49 -0400
From: [email protected]
To: Jeremy Hershberger <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] AD9361's Calibration effect on phase
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
The I/Q calibration (don't know the details), but generally seeks to
achieve amplitude and phase balance between the I and Q components.
The main cause of non-repeatable phase offset run-to-run is that the
AD9361, like many modern DC-light synthesizers, uses fractional-N
synthesis, which has the inherent property of random phase offsets.
That's an inherent property of the AD9361 synthesizer.
So, while you can provide a common reference for a group of B2xx or
E3xx, that will not guarantee predictable phase offset, just no relative
phase-creep between synchronized units.
On 2016-04-07 14:08, Jeremy Hershberger via USRP-users wrote:
> The datasheet for the AD9361 lists an ability to remove DC level, I/Q
> imbalance, and gain correction for both TX and RX, without discussing the
> method used. Is it possible for this calibration circuitry to change the TX
> and/or RX phase? If it does, should the phase change be repeatable from run
> to run? Can this calibration be turned off, or in some way controlled to
> achieve consistent performance?
>
> Thanks,
>
> -Jeremy
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160407/f109bb5e/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 07 Apr 2016 19:08:14 +0000
From: Ed <[email protected]>
To: [email protected]
Subject: [USRP-users] Extraneous tones on 200 MHz clock
Message-ID:
<cafolxppvlh+yv+wsg+j+7e7caka_5b5r3gaijlgg1x5cy4-...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I am using an x310 chassis with a non-standard (in-house) daughter card in
slot B only.
If I initialize the x310 with a simple RFNoC example application (based on
UHD 003.007.002) the 200 MHz reference clock is clean and as it should be.
If I initialize it via an example c++ application (using UHD version
003.009.002) the clock has a lot of extra components (see below.)
|
| |
| | | |
| | | | | |
| | | | | | | . .
.
| | | | | | |
-----------------------------------------------------------------------------------
49 99 148 198 247 296 346 (MHz)
Does anyone know what might cause all of the extra tones and how I might
get rid of them?
Thank you,
Ed
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160407/16a5d353/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 7 Apr 2016 14:11:07 -0500
From: John Orlando <[email protected]>
To: Jeremy Hershberger <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] AD9361's Calibration effect on phase
Message-ID:
<CAEMYR3hL94OQOrZTf34GdK8XPgq=3pkhm4fypm4d-dq-szw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Jeremy,
The quadrature/amplitude balancing capability of the AD9361 can cause minor
phase variation even after the LO synthesizer has locked. Typically this
variation is on the order of a few degrees. Our experience (not with USRP
platforms, but other platforms that utilize the AD9361) is that this is not
repeatable from run to run. You would need to allow the
quadrature/amplitude balancing circuitry settle down, and then disable the
tracking capability in the AD9361 to prevent future adjustments. From this
point on, the phase should be stable.
Note that this is separate from the typical issue where the LO phase ends
up in an arbitrary state each time after the LO is tuned. That will yield
a given phase state, but the variation described in the above paragraph is
on top of that.
Regards,
John
On Thu, Apr 7, 2016 at 1:08 PM, Jeremy Hershberger via USRP-users <
[email protected]> wrote:
> The datasheet for the AD9361 lists an ability to remove DC level, I/Q
> imbalance, and gain correction for both TX and RX, without discussing the
> method used. Is it possible for this calibration circuitry to change the
> TX and/or RX phase? If it does, should the phase change be repeatable from
> run to run? Can this calibration be turned off, or in some way controlled
> to achieve consistent performance?
>
> Thanks,
>
> -Jeremy
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
John Orlando
CEO/System Architect
Epiq Solutions
http://www.epiqsolutions.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160407/cf2ac2ba/attachment-0001.html>
------------------------------
Message: 10
Date: Thu, 7 Apr 2016 15:17:51 -0400
From: Jeremy Hershberger <[email protected]>
To: John Orlando <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] AD9361's Calibration effect on phase
Message-ID:
<camziklraaeyes+pxhncioromzjsjott6oqfgjhedxms5bmi...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
This is exactly the behavior seen in my data after removal of the LO phase
offset. The error is usually on the order of a few degrees.
Is there a hook in UHD to disable the AD9361's tracking capability?
-Jeremy
On Thu, Apr 7, 2016 at 3:11 PM, John Orlando <[email protected]> wrote:
> Jeremy,
> The quadrature/amplitude balancing capability of the AD9361 can cause
> minor phase variation even after the LO synthesizer has locked. Typically
> this variation is on the order of a few degrees. Our experience (not with
> USRP platforms, but other platforms that utilize the AD9361) is that this
> is not repeatable from run to run. You would need to allow the
> quadrature/amplitude balancing circuitry settle down, and then disable the
> tracking capability in the AD9361 to prevent future adjustments. From this
> point on, the phase should be stable.
>
> Note that this is separate from the typical issue where the LO phase ends
> up in an arbitrary state each time after the LO is tuned. That will yield
> a given phase state, but the variation described in the above paragraph is
> on top of that.
>
> Regards,
> John
>
> On Thu, Apr 7, 2016 at 1:08 PM, Jeremy Hershberger via USRP-users <
> [email protected]> wrote:
>
>> The datasheet for the AD9361 lists an ability to remove DC level, I/Q
>> imbalance, and gain correction for both TX and RX, without discussing the
>> method used. Is it possible for this calibration circuitry to change the
>> TX and/or RX phase? If it does, should the phase change be repeatable from
>> run to run? Can this calibration be turned off, or in some way controlled
>> to achieve consistent performance?
>>
>> Thanks,
>>
>> -Jeremy
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
> --
> John Orlando
> CEO/System Architect
> Epiq Solutions
> http://www.epiqsolutions.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160407/82ba4a5c/attachment-0001.html>
------------------------------
Message: 11
Date: Thu, 7 Apr 2016 12:32:46 -0700
From: Tom Tsou <[email protected]>
To: Jeremy Hershberger <[email protected]>
Cc: John Orlando <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] AD9361's Calibration effect on phase
Message-ID:
<cagniu+cyzyz43xgrdwwyfaamwox4dikqx7mxvlcvvfdjjj4...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Thu, Apr 7, 2016 at 12:17 PM, Jeremy Hershberger via USRP-users
<[email protected]> wrote:
> This is exactly the behavior seen in my data after removal of the LO phase
> offset. The error is usually on the order of a few degrees.
>
> Is there a hook in UHD to disable the AD9361's tracking capability?
See the set_rx_dc_offset() and set_rx_iq_balance() calls in the
multi_usrp interface to disable DC and quadrature receive tracking on
the B200.
The transmit side calibration is table based; there are no active
tracking loops.
-TT
------------------------------
Message: 12
Date: Thu, 7 Apr 2016 15:02:47 -0700
From: Richard Bell <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP through Python
Message-ID:
<CAMMoi3vzOkPpTOi0V5qmS3=sl0z4qxb4tjsbuvyvq29ur_h...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Is the design flow typically something like this then:
1) Use python for USRP control if the function calls are exposed, otherwise
2) Write a C++ block that you can call in Python that does the desired
control/monitoring
Rich
On Thu, Apr 7, 2016 at 11:01 AM, Marcus M?ller <[email protected]>
wrote:
> multi_usrp is a UHD class, that the usrp_sink and _source use
> *internally*; you can't use it standalone in GNU Radio, and that's why
> there's no GNU Radio benefit from swigging it.
> However, the usrp_sink and _source blocks wrap most of the relevant
> methods, though under different names (set_gain[1] instead of set_rx_gain
> or set_tx_gain, because if modifying a usrp_sink or usrp_source, it's clear
> whether you want to modify TX or RX).
>
> Best regards,
> Marcus
>
> [1] https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html
>
> On 07.04.2016 19:44, Dave NotTelling via USRP-users wrote:
>
> Martin,
>
> Is there a specific reason why the multi_usrp class isn't exposed to
> Python?
>
> -Dave
>
> On Thu, Apr 7, 2016 at 1:13 PM, Martin Braun via USRP-users <
> <[email protected]>[email protected]> wrote:
>
>> To clarify,
>>
>> multi_usrp is not swigged, only the GNU Radio blocks. So the UHD
>> reference manual does not apply to Python-land.
>>
>> Cheers,
>> M
>>
>> On 04/06/2016 02:27 PM, Richard Bell via USRP-users wrote:
>> > Ah thank you! That python API is what I couldn't find, I kept getting
>> > stuck on the C++ API.
>> >
>> > Things are working now.
>> >
>> > Rich
>> >
>> > On Wed, Apr 6, 2016 at 2:09 PM, James Humphries
>> > <[email protected] <mailto:[email protected]>> wrote:
>> >
>> > Hi Rich,
>> >
>> > It looks like you have instantiated a USRP sink, which is for TX
>> > only. You will need to add a USRP source if you want to RX as well.
>> >
>> > See the GNU Radio Python API here for a list of all the functions
>> > and methods:
>> >
>> > http://gnuradio.org/doc/sphinx/#uhd-blocks
>> >
>> > -Trip
>> >
>> > On Wed, Apr 6, 2016 at 3:47 PM, Richard Bell via USRP-users
>> > <[email protected] <mailto:[email protected]>>
>> wrote:
>> >
>> > Hi all,
>> >
>> > After instantiating a usrp object in Python, which I will call
>> > usrp here, I'm attempting to call
>> > usrp.get_rx_sensor("lo_locked") and usrp.get_rx_freq(), but I
>> > get the following error:
>> >
>> > AttributeError: 'usrp_sink_sptr' object has no attribute
>> > 'get_rx_freq'
>> >
>> > I can call usrp.set_center_freq(target_freq) just fine. How do I
>> > gain access to the full set of usrp methods through Python? Is
>> > there example code that demonstrates some of this? I've looked
>> > through the freq_hopping.py and usrp_spectrum_sense.py scripts
>> > extensively. They don't use much more then set_center_freq().
>> >
>> > Thanks,
>> > Rich
>> >
>> > _______________________________________________
>> > USRP-users mailing list
>> > [email protected] <mailto:[email protected]>
>> >
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > USRP-users mailing list
>> > [email protected]
>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160407/caf0b50b/attachment-0001.html>
------------------------------
Message: 13
Date: Thu, 7 Apr 2016 15:07:27 -0700
From: Derek Kozel <[email protected]>
To: Claudio Cicconetti <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] E310 GPSDO clock reference
Message-ID:
<CAA+K=tsqmlpgkehmrez4xmfdn3j7uss7tno7qqn-2yipkca...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Claudio,
I have to apologize, I have just been corrected by a coworker that the
clock API behavior is accurate . While it is technically possible to feed a
DC coupled 10 MHz signal to the Sync connector, it was never designed to
function this way and will not work with many normal 10 MHz sources. The
Manual and code are correct and state that the SYNC input is for a 1PPS
(LVCMOS or 5V) signal.
http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_hw_sync
The two correct ways to discipline the E310's internal reference are as
follows:
With a 1PPS signal being fed into SYNC:
tx_waveforms --freq 1592.5e6 --rate 1e6 --pps external
or in your own code
usrp->set_time_source("external")
With a GPS antenna attached to GPS:
tx_waveforms --freq 1592.5e6 --rate 1e6 --pps gpsdo
or in your own code
usrp->set_time_source("gpsdo")
http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a57a5580ba06d7d6a037c9ef64f1ea361
Either of these options will discipline the internal reference and much
improve your frequency alignment with other devices disciplined by the same
source.
I hope this is clear and helps. Please let me know if one of these methods
works and if you have any other questions.
Regards,
Derek
On Wed, Apr 6, 2016 at 11:00 AM, Derek Kozel <[email protected]> wrote:
> Hello Claudio,
>
> I'm sorry, I've just opened a bug for this. Please use the --pps flag
> instead for now. The E310 will accept either a 1PPS signal or 10 MHz
> reference to the rf connector but for the moment the time synchronization
> call must be used for both. I'll get this fixed.
>
> With 10 MHz reference or 1PPS signal being fed in
> /usr/lib/uhd/examples/tx_waveforms --freq 1592.5e6 --rate 1e6 --pps
> external
>
> With a GPS antenna attached
> /usr/lib/uhd/examples/tx_waveforms --freq 1592.5e6 --rate 1e6 --pps gpsdo
>
> Regards,
> Derek
>
> On Wed, Apr 6, 2016 at 1:08 AM, Claudio Cicconetti <
> [email protected]> wrote:
>
>> Dear Derek,
>> Thank you for your response.
>>
>> However, this does not solve the issue: when invoking tx_waveforms using
>> any value different from 'internal' for parameter '--ref' I get:
>>
>> "Error: ValueError: Clock source option not supported: $REF. The only
>> value supported is "internal". To discipline the internal oscillator,
>> set the appropriate time source"
>>
>> (where $REF is one of external, mimo, gpsdo)
>>
>> An example of command invokation with output is included at the bottom.
>>
>> Further advice on how to solve the issue would be greatly appreciated.
>>
>> Best regards,
>> Claudio
>>
>> On 04/05/2016 07:43 PM, Derek Kozel wrote:
>> > Hello Claudio,
>> >
>> > The E310 is only using the external reference for the duration of
>> > query_gpsdo_sensors. You must also run tx_waveforms with "--ref
>> external"
>> > for TX waveforms to use the reference. USRPs are designed to be
>> stateless
>> > between sessions so it is always in a known state. Please let us know if
>> > this solves your problem.
>> >
>> >
>> https://github.com/EttusResearch/uhd/blob/master/host/examples/tx_waveforms.cpp#L69
>> >
>> > Regards,
>> > Derek
>> >
>> > On Tue, Apr 5, 2016 at 1:49 AM, Claudio Cicconetti via USRP-users <
>> > [email protected]> wrote:
>> >
>> >> Dear all,
>> >> I cannot lock properly an E310 to the GPSDO 10 MHz reference.
>> >>
>> >> I tried with stable releases 3 and 4 and also with a home-compiled
>> rel-4
>> >> from git. The result is always the same:
>> >>
>> >> 1. the E310 acquires lock from GPS (as indicated by
>> query_gpsdo_sensors)
>> >> 2. I transmit a beacon (using tx_waveforms)
>> >> 3. on the receiver (see below) a get a drift between 1 kHz and 2 kHz
>> >>
>> >> Note: as "receiver" I used i) an Agilent spectrum analyzer with high
>> >> internal clock accuracy; ii) an USRP N210 with external 10 MHz clock
>> >> reference coming from a (properly locked) professional GPS receiver;
>> >> iii) another USRP N210 equipped with a (properly locked) internal
>> GPSDO.
>> >> Needless to say: i, ii, and iii are perfectly frequency-consistent to
>> >> one another.
>> >>
>> >> Any idea of what I could have messed?
>> >>
>> >> Best regards,
>> >> Claudio
>> >>
>> >> --
>> >> Claudio Cicconetti, PhD
>> >> Software Engineer - MBI S.r.l. - Pisa, Italy
>> >>
>> >>
>> >> _______________________________________________
>> >> USRP-users mailing list
>> >> [email protected]
>> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >>
>> >
>>
>> ---------------------------------------------------
>>
>> Running:
>>
>> /usr/lib/uhd/examples/tx_waveforms --freq 1592.5e6 --rate 1e6 --ref=gpsdo
>>
>> I get:
>>
>> linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.009.002-0-unknown
>>
>>
>> Creating the usrp device with: ...
>> -- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga.bit... done
>> -- Detecting internal GPSDO .... found
>> -- Initializing core control...
>> -- Performing register loopback test... pass
>> -- Performing register loopback test... pass
>> -- Performing register loopback test... pass
>> -- Performing CODEC loopback test... pass
>> -- Performing CODEC loopback test... pass
>> -- Setting time source to internal
>> -- Asking for clock rate 16 MHz
>> -- Actually got clock rate 16 MHz
>> -- Performing timer loopback test... pass
>> -- Performing timer loopback test... pass
>> -- Loading FPGA image: /usr/share/uhd/images/usrp_e3xx_fpga_idle.bit...
>> done
>> Error: ValueError: Clock source option not supported: gpsdo. The only
>> value supported is "internal". To discipline the internal oscillator,
>> set the appropriate time source.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160407/b26fb440/attachment-0001.html>
------------------------------
Message: 14
Date: Thu, 7 Apr 2016 16:17:03 -0700
From: Richard Bell <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Frequency Hopping Transmitter
Message-ID:
<cammoi3v-cwbydc179xsela1ocporal3v8bhb3tauuc2+oak...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I was hoping for some feedback on the attached python script which
implements a frequency hopping transmitter using a USRP (N210 with WBX DB
in my case). The script allows you to enter a dwell time, which is how long
the radio sits at each frequency, and then hops to a random frequency
within a user specified range of frequencies.
The point of this script is to quantitatively estimate the fastest hopping
speed a USRP can handle. To do this, I used the Python time module and
time.clock() on a Ubuntu 14.04 LTS intel corei7 computer to measure the
time between hops. If the time between hops was greater then the dwell
time, the script declares that the hop rate is not supported.
Part of the measurement does include waiting for the LO to lock, to make
the measurement fair. The transmitted signal is just a constant at
baseband, which produces a pure sine at passband, or a tone. So you will
just see tones on a spec analyzer as the script runs. I didn't care to get
more complicated with the baseband signal because I'm interested in the
fastest hop rate only.
What I would welcome, is any glaring issues I've overlooked in my
implementation to make this measurement. I can't claim that this script is
the most efficient way of getting the USRP to hop, it's only my stab at it.
If anyone would recommend a different technique to improve the hop rate, I
would love to hear about it.
My findings using this script are that the USRPN210+WBX consistently
support hop rates of 200 Hz. Faster then this, and eventually you get a hop
that misses a deadline within a few seconds of starting the script. I've
gotten single hops to occur within the specified dwell time as fast as 1250
kHz, but this cannot be sustained. Eventually at these rates, a hop
deadline is missed.
Look forward to hearing any pointers or guidance that can be offered.
v/,r
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160407/d7a86562/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: custom_hopper.py
Type: text/x-python
Size: 8011 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160407/d7a86562/attachment-0001.py>
------------------------------
Message: 15
Date: Thu, 7 Apr 2016 18:12:40 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP through Python
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Well, usually the USRP blocks expose all you need. What are you trying
to do?
M
On 04/07/2016 03:02 PM, Richard Bell via USRP-users wrote:
> Is the design flow typically something like this then:
>
> 1) Use python for USRP control if the function calls are exposed, otherwise
> 2) Write a C++ block that you can call in Python that does the desired
> control/monitoring
>
> Rich
>
> On Thu, Apr 7, 2016 at 11:01 AM, Marcus M?ller
> <[email protected] <mailto:[email protected]>> wrote:
>
> multi_usrp is a UHD class, that the usrp_sink and _source use
> *internally*; you can't use it standalone in GNU Radio, and that's
> why there's no GNU Radio benefit from swigging it.
> However, the usrp_sink and _source blocks wrap most of the relevant
> methods, though under different names (set_gain[1] instead of
> set_rx_gain or set_tx_gain, because if modifying a usrp_sink or
> usrp_source, it's clear whether you want to modify TX or RX).
>
> Best regards,
> Marcus
>
> [1] https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html
>
> On 07.04.2016 19:44, Dave NotTelling via USRP-users wrote:
>> Martin,
>>
>> Is there a specific reason why the multi_usrp class isn't
>> exposed to Python?
>>
>> -Dave
>>
>> On Thu, Apr 7, 2016 at 1:13 PM, Martin Braun via USRP-users
>> <<mailto:[email protected]>[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> To clarify,
>>
>> multi_usrp is not swigged, only the GNU Radio blocks. So the UHD
>> reference manual does not apply to Python-land.
>>
>> Cheers,
>> M
>>
>> On 04/06/2016 02:27 PM, Richard Bell via USRP-users wrote:
>> > Ah thank you! That python API is what I couldn't find, I
>> kept getting
>> > stuck on the C++ API.
>> >
>> > Things are working now.
>> >
>> > Rich
>> >
>> > On Wed, Apr 6, 2016 at 2:09 PM, James Humphries
>> > <[email protected] <mailto:[email protected]>
>> <mailto:[email protected]
>> <mailto:[email protected]>>> wrote:
>> >
>> > Hi Rich,
>> >
>> > It looks like you have instantiated a USRP sink, which
>> is for TX
>> > only. You will need to add a USRP source if you want to
>> RX as well.
>> >
>> > See the GNU Radio Python API here for a list of all the
>> functions
>> > and methods:
>> >
>> > http://gnuradio.org/doc/sphinx/#uhd-blocks
>> >
>> > -Trip
>> >
>> > On Wed, Apr 6, 2016 at 3:47 PM, Richard Bell via USRP-users
>> > <[email protected] <mailto:[email protected]>
>> <mailto:[email protected]
>> <mailto:[email protected]>>> wrote:
>> >
>> > Hi all,
>> >
>> > After instantiating a usrp object in Python, which I
>> will call
>> > usrp here, I'm attempting to call
>> > usrp.get_rx_sensor("lo_locked") and
>> usrp.get_rx_freq(), but I
>> > get the following error:
>> >
>> > AttributeError: 'usrp_sink_sptr' object has no attribute
>> > 'get_rx_freq'
>> >
>> > I can call usrp.set_center_freq(target_freq) just
>> fine. How do I
>> > gain access to the full set of usrp methods through
>> Python? Is
>> > there example code that demonstrates some of this?
>> I've looked
>> > through the freq_hopping.py and
>> usrp_spectrum_sense.py scripts
>> > extensively. They don't use much more then
>> set_center_freq().
>> >
>> > Thanks,
>> > Rich
>> >
>> > _______________________________________________
>> > USRP-users mailing list
>> > [email protected]
>> <mailto:[email protected]>
>> <mailto:[email protected]
>> <mailto:[email protected]>>
>> >
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > USRP-users mailing list
>> > [email protected] <mailto:[email protected]>
>> >
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 16
Date: Thu, 7 Apr 2016 21:20:29 -0400
From: "Tilla" <[email protected]>
To: "'Richard Bell'" <[email protected]>, "'usrp-users'"
<[email protected]>
Subject: Re: [USRP-users] Frequency Hopping Transmitter
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
I have seen freq hop times consistently sub millisecond through the C++
interface, often as fast as 850 u-seconds for a full retune, not just a dsp
tune.
This seems pretty consistent with your 1250Hz (assuming kHz is a typo).
I didn?t run for extended period of time hopping very quickly, so I cant
comment on the sustainment part of your observation.
We have run a ?slowly? hopping application for single digit hours without issue?
From: USRP-users [mailto:[email protected]] On Behalf Of
Richard Bell via USRP-users
Sent: Thursday, April 7, 2016 7:17 PM
To: [email protected]
Subject: [USRP-users] Frequency Hopping Transmitter
I was hoping for some feedback on the attached python script which implements a
frequency hopping transmitter using a USRP (N210 with WBX DB in my case). The
script allows you to enter a dwell time, which is how long the radio sits at
each frequency, and then hops to a random frequency within a user specified
range of frequencies.
The point of this script is to quantitatively estimate the fastest hopping
speed a USRP can handle. To do this, I used the Python time module and
time.clock() on a Ubuntu 14.04 LTS intel corei7 computer to measure the time
between hops. If the time between hops was greater then the dwell time, the
script declares that the hop rate is not supported.
Part of the measurement does include waiting for the LO to lock, to make the
measurement fair. The transmitted signal is just a constant at baseband, which
produces a pure sine at passband, or a tone. So you will just see tones on a
spec analyzer as the script runs. I didn't care to get more complicated with
the baseband signal because I'm interested in the fastest hop rate only.
What I would welcome, is any glaring issues I've overlooked in my
implementation to make this measurement. I can't claim that this script is the
most efficient way of getting the USRP to hop, it's only my stab at it. If
anyone would recommend a different technique to improve the hop rate, I would
love to hear about it.
My findings using this script are that the USRPN210+WBX consistently support
hop rates of 200 Hz. Faster then this, and eventually you get a hop that misses
a deadline within a few seconds of starting the script. I've gotten single hops
to occur within the specified dwell time as fast as 1250 kHz, but this cannot
be sustained. Eventually at these rates, a hop deadline is missed.
Look forward to hearing any pointers or guidance that can be offered.
v/,r
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160407/e980da5d/attachment-0001.html>
------------------------------
Message: 17
Date: Fri, 8 Apr 2016 02:58:54 -0400
From: Ryan Marlow <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP x310 " ddr3_32bit: Code generation aborted:
Unconfigured MIG instance"
Message-ID:
<CADVE_uwpDbOB3O1HU-F=d8bgsmkq5kxjryply1l-ghrypes...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello all,
I am trying to build an image for the usrp x310 in vivado 2015.4.
While building the ddr3_32bit IP for the project, I get a read out like
this:
========================================================
BUILDER: Building IP ddr3_32bit
========================================================
BUILDER: Staging IP in build directory...
Reserving IP location:
> /home/rynmrlw/pybombs-prefix/src/uhd/fpga-src/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/ddr3_32bit
BUILDER: Retargeting IP to part xc7k410tffg900-2...
BUILDER: Building IP...
> ****** Vivado v2015.4 (64-bit)
**** SW Build 1412921 on Wed Nov 18 09:44:32 MST 2015
**** IP Build 1412160 on Tue Nov 17 13:47:24 MST 2015
** Copyright 1986-2015 Xilinx, Inc. All Rights Reserved.
> source
> /home/rynmrlw/pybombs-prefix/src/uhd/fpga-src/fpga/usrp3/top/../tools/scripts/viv_generate_ip.tcl
# set xci_file $::env(XCI_FILE) ;
# set part_name $::env(PART_NAME) ;
# set gen_example_proj $::env(GEN_EXAMPLE) ;
# set synth_ip $::env(SYNTH_IP) ;
# set ip_name [file rootname [file tail $xci_file]] ;
# file delete -force "$xci_file.out"
# create_project -part $part_name -in_memory -ip
# set_property target_simulator XSim [current_project]
# add_files -norecurse -force $xci_file
INFO: [IP_Flow 19-234] Refreshing IP repositories
INFO: [IP_Flow 19-1704] No user IP repositories specified
INFO: [IP_Flow 19-2313] Loaded Vivado IP repository
> '/opt/Xilinx/Vivado/2015.4/data/ip'.
# reset_target all [get_files $xci_file]
# puts "BUILDER: Generating IP Target..."
BUILDER: Generating IP Target...
# generate_target all [get_files $xci_file]
INFO: [IP_Flow 19-1686] Generating 'Instantiation Template' target for IP
> 'ddr3_32bit'...
*ERROR: [xilinx.com:ip:mig_7series:2.4-0] ddr3_32bit: Code generation
> aborted: Unconfigured MIG instance*
*CRITICAL WARNING: [IP_Flow 19-1747] Failed to deliver file
> '/opt/Xilinx/Vivado/2015.4/data/ip/xilinx/mig_7series_v2_4/xit/instantiation_template.xit':
> *
*ERROR: [IP_Flow 19-167] Failed to deliver one or more file(s).*
*ERROR: [IP_Flow 19-3505] IP Generation error: Failed to generate IP
> 'ddr3_32bit'. Failed to generate 'Verilog Instantiation Template' outputs: *
*ERROR: [IP_Flow 19-98] Generation of the IP CORE failed.*
Failed to generate IP 'ddr3_32bit'. Failed to generate 'Verilog
> Instantiation Template' outputs:
INFO: [Common 17-206] Exiting Vivado at Fri Apr 8 02:41:13 2016...
Releasing IP location:
> /home/rynmrlw/pybombs-prefix/src/uhd/fpga-src/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/ddr3_32bit
make[1]: ***
> [/home/rynmrlw/pybombs-prefix/src/uhd/fpga-src/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/ddr3_32bit/ddr3_32bit.xci.out]
> Error 1
make[1]: Leaving directory
> `/home/rynmrlw/pybombs-prefix/src/uhd/fpga-src/fpga/usrp3/top/x300'
make: *** [X310_RFNOC_HGS] Error 2
I've upgraded the IP using the upgrade_ip.sh script in the ip folder. Is
there a specific version of Vivado (and IP) that I should be using? My
current vivado configurations are also included in this print out.
Best,
Ryan Marlow
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/3d54c33e/attachment-0001.html>
------------------------------
Message: 18
Date: Fri, 8 Apr 2016 09:08:39 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP x310 " ddr3_32bit: Code generation
aborted: Unconfigured MIG instance"
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Ryan,
this is but a stab in the dark, but most things that make FPGA building
fail for me (if I didn't mess something up myself...) is when I forgot
to clean the build directory when updating/changing IP.
Is it possible that's the case here? Does "make cleanall; make X310_HGS"
(assuming that's the image flavour you're after) solve the issue?
Best regards,
Marcus
On 08.04.2016 08:58, Ryan Marlow via USRP-users wrote:
> Hello all,
> I am trying to build an image for the usrp x310 in vivado 2015.4.
> While building the ddr3_32bit IP for the project, I get a read out
> like this:
>
>
>
> ========================================================
>
> BUILDER: Building IP ddr3_32bit
>
> ========================================================
>
> BUILDER: Staging IP in build directory...
>
> Reserving IP location:
>
> /home/rynmrlw/pybombs-prefix/src/uhd/fpga-src/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/ddr3_32bit
>
> BUILDER: Retargeting IP to part xc7k410tffg900-2...
>
> BUILDER: Building IP...
>
>
> ****** Vivado v2015.4 (64-bit)
>
> **** SW Build 1412921 on Wed Nov 18 09:44:32 MST 2015
>
> **** IP Build 1412160 on Tue Nov 17 13:47:24 MST 2015
>
> ** Copyright 1986-2015 Xilinx, Inc. All Rights Reserved.
>
>
> source
>
> /home/rynmrlw/pybombs-prefix/src/uhd/fpga-src/fpga/usrp3/top/../tools/scripts/viv_generate_ip.tcl
>
> # set xci_file $::env(XCI_FILE) ;
>
> # set part_name $::env(PART_NAME) ;
>
> # set gen_example_proj $::env(GEN_EXAMPLE) ;
>
> # set synth_ip $::env(SYNTH_IP) ;
>
> # set ip_name [file rootname [file tail $xci_file]] ;
>
> # file delete -force "$xci_file.out"
>
> # create_project -part $part_name -in_memory -ip
>
> # set_property target_simulator XSim [current_project]
>
> # add_files -norecurse -force $xci_file
>
> INFO: [IP_Flow 19-234] Refreshing IP repositories
>
> INFO: [IP_Flow 19-1704] No user IP repositories specified
>
> INFO: [IP_Flow 19-2313] Loaded Vivado IP repository
> '/opt/Xilinx/Vivado/2015.4/data/ip'.
>
> # reset_target all [get_files $xci_file]
>
> # puts "BUILDER: Generating IP Target..."
>
> BUILDER: Generating IP Target...
>
> # generate_target all [get_files $xci_file]
>
> INFO: [IP_Flow 19-1686] Generating 'Instantiation Template' target
> for IP 'ddr3_32bit'...
>
> *ERROR: [xilinx.com:ip:mig_7series:2.4-0] ddr3_32bit: Code
> generation aborted: Unconfigured MIG instance*
>
> *CRITICAL WARNING: [IP_Flow 19-1747] Failed to deliver file
>
> '/opt/Xilinx/Vivado/2015.4/data/ip/xilinx/mig_7series_v2_4/xit/instantiation_template.xit':
> *
>
> *ERROR: [IP_Flow 19-167] Failed to deliver one or more file(s).*
>
> *ERROR: [IP_Flow 19-3505] IP Generation error: Failed to generate
> IP 'ddr3_32bit'. Failed to generate 'Verilog Instantiation
> Template' outputs: *
>
> *ERROR: [IP_Flow 19-98] Generation of the IP CORE failed.*
>
> Failed to generate IP 'ddr3_32bit'. Failed to generate 'Verilog
> Instantiation Template' outputs:
>
> INFO: [Common 17-206] Exiting Vivado at Fri Apr 8 02:41:13 2016...
>
> Releasing IP location:
>
> /home/rynmrlw/pybombs-prefix/src/uhd/fpga-src/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/ddr3_32bit
>
> make[1]: ***
>
> [/home/rynmrlw/pybombs-prefix/src/uhd/fpga-src/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/ddr3_32bit/ddr3_32bit.xci.out]
> Error 1
>
> make[1]: Leaving directory
> `/home/rynmrlw/pybombs-prefix/src/uhd/fpga-src/fpga/usrp3/top/x300'
>
> make: *** [X310_RFNOC_HGS] Error 2
>
>
> I've upgraded the IP using the upgrade_ip.sh script in the ip folder.
> Is there a specific version of Vivado (and IP) that I should be using?
> My current vivado configurations are also included in this print out.
> Best,
> Ryan Marlow
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/ce8f5f53/attachment-0001.html>
------------------------------
Message: 19
Date: Fri, 8 Apr 2016 09:35:12 +0200
From: Claudio Cicconetti <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] E310 GPSDO clock reference
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Dear Derek,
Even with the PPS synchronization, the frequency stability I get is very
poor. You can find in the graph at the URL below the frequency drift
measured over a time window of 30 seconds:
https://dl.dropboxusercontent.com/u/3247031/e310_freq.png
In the E310 manual I found the following statement: "Unlike most USRP
devices, the E310 does not have independent reference clock and time
source inputs."
Does this mean it is not possible to lock the internal clock to an
external / gpsdo reference?
If this is the case I would like to know it ASAP because for me this
means aborting the current project with E310 and find an alternative
solution.
Best regards,
Claudio
On 04/08/2016 12:07 AM, Derek Kozel wrote:
> Hello Claudio,
>
> I have to apologize, I have just been corrected by a coworker that the
> clock API behavior is accurate . While it is technically possible to feed a
> DC coupled 10 MHz signal to the Sync connector, it was never designed to
> function this way and will not work with many normal 10 MHz sources. The
> Manual and code are correct and state that the SYNC input is for a 1PPS
> (LVCMOS or 5V) signal.
> http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_hw_sync
>
> The two correct ways to discipline the E310's internal reference are as
> follows:
>
> With a 1PPS signal being fed into SYNC:
>
> tx_waveforms --freq 1592.5e6 --rate 1e6 --pps external
> or in your own code
> usrp->set_time_source("external")
>
>
> With a GPS antenna attached to GPS:
>
> tx_waveforms --freq 1592.5e6 --rate 1e6 --pps gpsdo
> or in your own code
> usrp->set_time_source("gpsdo")
>
> http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a57a5580ba06d7d6a037c9ef64f1ea361
>
> Either of these options will discipline the internal reference and much
> improve your frequency alignment with other devices disciplined by the same
> source.
>
> I hope this is clear and helps. Please let me know if one of these methods
> works and if you have any other questions.
>
> Regards,
> Derek
>
>
> On Wed, Apr 6, 2016 at 11:00 AM, Derek Kozel <[email protected]> wrote:
>
>> Hello Claudio,
>>
>> I'm sorry, I've just opened a bug for this. Please use the --pps flag
>> instead for now. The E310 will accept either a 1PPS signal or 10 MHz
>> reference to the rf connector but for the moment the time synchronization
>> call must be used for both. I'll get this fixed.
>>
>> With 10 MHz reference or 1PPS signal being fed in
>> /usr/lib/uhd/examples/tx_waveforms --freq 1592.5e6 --rate 1e6 --pps
>> external
>>
>> With a GPS antenna attached
>> /usr/lib/uhd/examples/tx_waveforms --freq 1592.5e6 --rate 1e6 --pps gpsdo
>>
>> Regards,
>> Derek
>>
>> On Wed, Apr 6, 2016 at 1:08 AM, Claudio Cicconetti <
>> [email protected]> wrote:
>>
>>> Dear Derek,
>>> Thank you for your response.
>>>
>>> However, this does not solve the issue: when invoking tx_waveforms using
>>> any value different from 'internal' for parameter '--ref' I get:
>>>
>>> "Error: ValueError: Clock source option not supported: $REF. The only
>>> value supported is "internal". To discipline the internal oscillator,
>>> set the appropriate time source"
>>>
>>> (where $REF is one of external, mimo, gpsdo)
>>>
>>> An example of command invokation with output is included at the bottom.
>>>
>>> Further advice on how to solve the issue would be greatly appreciated.
>>>
>>> Best regards,
>>> Claudio
>>>
>>> On 04/05/2016 07:43 PM, Derek Kozel wrote:
>>>> Hello Claudio,
>>>>
>>>> The E310 is only using the external reference for the duration of
>>>> query_gpsdo_sensors. You must also run tx_waveforms with "--ref
>>> external"
>>>> for TX waveforms to use the reference. USRPs are designed to be
>>> stateless
>>>> between sessions so it is always in a known state. Please let us know if
>>>> this solves your problem.
>>>>
>>>>
>>> https://github.com/EttusResearch/uhd/blob/master/host/examples/tx_waveforms.cpp#L69
>>>>
>>>> Regards,
>>>> Derek
>>>>
>>>> On Tue, Apr 5, 2016 at 1:49 AM, Claudio Cicconetti via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> Dear all,
>>>>> I cannot lock properly an E310 to the GPSDO 10 MHz reference.
>>>>>
>>>>> I tried with stable releases 3 and 4 and also with a home-compiled
>>> rel-4
>>>>> from git. The result is always the same:
>>>>>
>>>>> 1. the E310 acquires lock from GPS (as indicated by
>>> query_gpsdo_sensors)
>>>>> 2. I transmit a beacon (using tx_waveforms)
>>>>> 3. on the receiver (see below) a get a drift between 1 kHz and 2 kHz
>>>>>
>>>>> Note: as "receiver" I used i) an Agilent spectrum analyzer with high
>>>>> internal clock accuracy; ii) an USRP N210 with external 10 MHz clock
>>>>> reference coming from a (properly locked) professional GPS receiver;
>>>>> iii) another USRP N210 equipped with a (properly locked) internal
>>> GPSDO.
>>>>> Needless to say: i, ii, and iii are perfectly frequency-consistent to
>>>>> one another.
>>>>>
>>>>> Any idea of what I could have messed?
>>>>>
>>>>> Best regards,
>>>>> Claudio
>>>>>
>>>>> --
>>>>> Claudio Cicconetti, PhD
>>>>> Software Engineer - MBI S.r.l. - Pisa, Italy
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [email protected]
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>
>>>
>>> ---------------------------------------------------
>>>
>>> Running:
>>>
>>> /usr/lib/uhd/examples/tx_waveforms --freq 1592.5e6 --rate 1e6 --ref=gpsdo
>>>
>>> I get:
>>>
>>> linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.009.002-0-unknown
>>>
>>>
>>> Creating the usrp device with: ...
>>> -- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga.bit... done
>>> -- Detecting internal GPSDO .... found
>>> -- Initializing core control...
>>> -- Performing register loopback test... pass
>>> -- Performing register loopback test... pass
>>> -- Performing register loopback test... pass
>>> -- Performing CODEC loopback test... pass
>>> -- Performing CODEC loopback test... pass
>>> -- Setting time source to internal
>>> -- Asking for clock rate 16 MHz
>>> -- Actually got clock rate 16 MHz
>>> -- Performing timer loopback test... pass
>>> -- Performing timer loopback test... pass
>>> -- Loading FPGA image: /usr/share/uhd/images/usrp_e3xx_fpga_idle.bit...
>>> done
>>> Error: ValueError: Clock source option not supported: gpsdo. The only
>>> value supported is "internal". To discipline the internal oscillator,
>>> set the appropriate time source.
>>>
>>>
>>
>
------------------------------
Message: 20
Date: Fri, 8 Apr 2016 16:29:23 +0800
From: john liu <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] monitor with E310/312
Message-ID:
<caf6nntlowah_-vkasn6aym6_6ignkkkj1pzdjhpvbn4yhpc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear all,
Can we use E312/E312 with a LCD monitor?The interface is USB or
others?And where can we find the hard driver?
thank you for your reply.
best regards
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/da78e04b/attachment-0001.html>
------------------------------
Message: 21
Date: Fri, 8 Apr 2016 10:48:36 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] monitor with E310/312
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Dear John,
Philip Balister likes to use E31x with USB screens, so yeah that works.
Anyway, as this comes up relatively often: The E312 is really not a
normal desktop computer in a small case; I'd recommend understanding it
as an embedded device. That's especially an interesting point if you
consider E312's battery operation a key feature ? the battery just won't
last long if it has to power an external screen over USB, and if the CPU
has to do all the display calculations in software (a USB screen can't
accelerate rendering).
For example, the E312 surely isn't a platform I'd recommend compiling
stuff on; so the usual development cycle is software design and
development on a PC, cross-compilation, transferral to the E312
(typically via SSH/SCP/SSHfs or via a self-built SD card image), and
remote debugging. An USB screen can be handy for things like "quickly"
modifying a GNU Radio flowgraph to include a graphical sink to
understand the signal during development, but I've found it really worth
the effort to set up a cross-compilation environment on your PC, doing
the development there and using the E312 only for deployment and
testing. The big advantage of that really is robustness and speed. I
mention robustness because I often find myself and others in a situation
where something works "on this box, and only this box", and there's no
certain recollection of the steps necessary to achieve that. If you're
using an SDK to develop your image, then you'll have reproducible,
modifiable, error-traceable, customizable builds ? something that saves
a lot of time, whether you're doing research or a commercial product
with it.
I'd recommend a 25min lecture on this very topic [1]; it's a
motivational talk without much instructions; however, for the E3xx,
there's documentation on how to set up a Yocto/OpenEmbedded environment
so that you yourself can build exactly the same images that we offer for
download, but with your additions/modifications!
Best regards,
Marcus
[1] https://fosdem.org/2016/schedule/event/sdrembedded/
On 08.04.2016 10:29, john liu via USRP-users wrote:
> Dear all,
> Can we use E312/E312 with a LCD monitor?The interface is USB or
> others?And where can we find the hard driver?
> thank you for your reply.
> best regards
> John
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/ee06044d/attachment-0001.html>
------------------------------
Message: 22
Date: Fri, 8 Apr 2016 17:00:18 +0800
From: liu Jong <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] monitor with E310/312
Message-ID:
<CAEui2n2iaKgb+8dM7n-=a1rcsjgmnrcawvk4ovpzvcp9bxx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Marcus,
thank you so much.I am watching the video.
Best regards
John
2016-04-08 16:48 GMT+08:00 Marcus M?ller <[email protected]>:
> Dear John,
>
> Philip Balister likes to use E31x with USB screens, so yeah that works.
>
> Anyway, as this comes up relatively often: The E312 is really not a normal
> desktop computer in a small case; I'd recommend understanding it as an
> embedded device. That's especially an interesting point if you consider
> E312's battery operation a key feature ? the battery just won't last long
> if it has to power an external screen over USB, and if the CPU has to do
> all the display calculations in software (a USB screen can't accelerate
> rendering).
>
> For example, the E312 surely isn't a platform I'd recommend compiling
> stuff on; so the usual development cycle is software design and development
> on a PC, cross-compilation, transferral to the E312 (typically via
> SSH/SCP/SSHfs or via a self-built SD card image), and remote debugging. An
> USB screen can be handy for things like "quickly" modifying a GNU Radio
> flowgraph to include a graphical sink to understand the signal during
> development, but I've found it really worth the effort to set up a
> cross-compilation environment on your PC, doing the development there and
> using the E312 only for deployment and testing. The big advantage of that
> really is robustness and speed. I mention robustness because I often find
> myself and others in a situation where something works "on this box, and
> only this box", and there's no certain recollection of the steps necessary
> to achieve that. If you're using an SDK to develop your image, then you'll
> have reproducible, modifiable, error-traceable, customizable builds ?
> something that saves a lot of time, whether you're doing research or a
> commercial product with it.
>
> I'd recommend a 25min lecture on this very topic [1]; it's a motivational
> talk without much instructions; however, for the E3xx, there's
> documentation on how to set up a Yocto/OpenEmbedded environment so that you
> yourself can build exactly the same images that we offer for download, but
> with your additions/modifications!
>
> Best regards,
> Marcus
>
> [1] https://fosdem.org/2016/schedule/event/sdrembedded/
>
>
> On 08.04.2016 10:29, john liu via USRP-users wrote:
>
> Dear all,
> Can we use E312/E312 with a LCD monitor?The interface is USB or
> others?And where can we find the hard driver?
> thank you for your reply.
> best regards
> John
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/3a8c225a/attachment-0001.html>
------------------------------
Message: 23
Date: Fri, 8 Apr 2016 11:11:49 +0200
From: Patrick Berger <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Unable to create Vivado projekt or to build
clean repo
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi all
my next step in exploring the rfnoc and its capabilities is to get a minimal
working example of a custom rfnoc block (2 settings register, and a gain/offset
function). I could copy and adjust an xml file, so there is my "new" custom
block showed in gnuradio.
But as I tried to create a vivado project with a clean repository copy of
"fpga-src" I get some problems (without any customizations): I couldn't build
the source and I wasn't also able to create a new vivado project (with vivado
version 2015.2 and 2015.4, same error):
dsp@dsp-ThinkPad-T440p ~/rfnoc/src/uhd/fpga-src/usrp3/top/x300 $ make
X310_RFNOC_HGS GUI=1
make -f Makefile.x300.inc bin NAME=X310_RFNOC_HGS ARCH=kintex7
PART_ID=xc7k410t/ffg900/-2 ETH10G_PORT1=1 BUILD_1G=1 BUILD_10G=1
NO_DRAM_FIFOS=1 SRAM_FIFO_SIZE=16 RFNOC=1 X310=1 EXTRA_DEFS="ETH10G_PORT1=1
BUILD_1G=1 BUILD_10G=1 NO_DRAM_FIFOS=1 SRAM_FIFO_SIZE=16 RFNOC=1 X310=1"
make[1]: Entering directory `/home/dsp/rfnoc/src/uhd/fpga-src/usrp3/top/x300'
Vivado v2015.2 (64-bit)
========================================================
BUILDER: Building IP ten_gig_eth_pcs_pma
========================================================
BUILDER: Staging IP in build directory...
Reserving IP location:
/home/dsp/rfnoc/src/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma
BUILDER: Retargeting IP to part xc7k410tffg900-2...
BUILDER: Building IP...
WARNING: Default location for XILINX_VIVADO_HLS not found:
****** Vivado v2015.2 (64-bit)
**** SW Build 1266856 on Fri Jun 26 16:35:25 MDT 2015
**** IP Build 1264090 on Wed Jun 24 14:22:01 MDT 2015
** Copyright 1986-2015 Xilinx, Inc. All Rights Reserved.
source
/home/dsp/rfnoc/src/uhd/fpga-src/usrp3/top/../tools/scripts/viv_generate_ip.tcl
# set xci_file $::env(XCI_FILE) ;
# set part_name $::env(PART_NAME) ;
# set gen_example_proj $::env(GEN_EXAMPLE) ;
# set synth_ip $::env(SYNTH_IP) ;
# set ip_name [file rootname [file tail $xci_file]] ;
# file delete -force "$xci_file.out"
# create_project -part $part_name -in_memory -ip
# set_property target_simulator XSim [current_project]
# add_files -norecurse -force $xci_file
INFO: [IP_Flow 19-234] Refreshing IP repositories
INFO: [IP_Flow 19-1704] No user IP repositories specified
INFO: [IP_Flow 19-2313] Loaded Vivado IP repository
'/opt/Xilinx/Vivado/2015.2/data/ip'.
WARNING: [IP_Flow 19-3664] IP 'ten_gig_eth_pcs_pma' generated file not found
'/home/dsp/rfnoc/src/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma_funcsim.vhdl'.
Please regenerate to continue.
WARNING: [IP_Flow 19-3664] IP 'ten_gig_eth_pcs_pma' generated file not found
'/home/dsp/rfnoc/src/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma.dcp'.
Please regenerate to continue.
WARNING: [IP_Flow 19-3664] IP 'ten_gig_eth_pcs_pma' generated file not found
'/home/dsp/rfnoc/src/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma_stub.v'.
Please regenerate to continue.
WARNING: [IP_Flow 19-3664] IP 'ten_gig_eth_pcs_pma' generated file not found
'/home/dsp/rfnoc/src/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma_stub.vhdl'.
Please regenerate to continue.
WARNING: [IP_Flow 19-3664] IP 'ten_gig_eth_pcs_pma' generated file not found
'/home/dsp/rfnoc/src/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma_funcsim.v'.
Please regenerate to continue.
WARNING: [IP_Flow 19-2162] IP 'ten_gig_eth_pcs_pma' is locked:
* The IP Data in the repository is incompatible with the current instance
(despite having identical Version and Revision). You will need to update the IP
before viewing the customization and generating outputs.
Please select 'Report IP Status' from the 'Tools/Report' menu or run Tcl
command 'report_ip_status' for more information.
# reset_target all [get_files $xci_file]
CRITICAL WARNING: [filemgmt 20-1366] Unable to reset target(s) for the
following file is locked:
/home/dsp/rfnoc/src/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma.xci
Locked reason:
* The IP Data in the repository is incompatible with the current instance
(despite having identical Version and Revision). You will need to update the IP
before viewing the customization and generating outputs.
Please select 'Report IP Status' from the 'Tools/Report' menu or run Tcl
command 'report_ip_status' for more information.
# puts "BUILDER: Generating IP Target..."
BUILDER: Generating IP Target...
# generate_target all [get_files $xci_file]
CRITICAL WARNING: [filemgmt 20-1365] Unable to generate target(s) for the
following file is locked:
/home/dsp/rfnoc/src/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma.xci
Locked reason:
* The IP Data in the repository is incompatible with the current instance
(despite having identical Version and Revision). You will need to update the IP
before viewing the customization and generating outputs.
Please select 'Report IP Status' from the 'Tools/Report' menu or run Tcl
command 'report_ip_status' for more information.
# if [string match $synth_ip "1"] {
# puts "BUILDER: Synthesizing IP Target..."
# synth_ip [get_ips $ip_name]
# }
BUILDER: Synthesizing IP Target...
INFO: [IP_Flow 19-234] Refreshing IP repositories
INFO: [IP_Flow 19-1704] No user IP repositories specified
INFO: [IP_Flow 19-2313] Loaded Vivado IP repository
'/opt/Xilinx/Vivado/2015.2/data/ip'.
WARNING: [IP_Flow 19-3664] IP 'ten_gig_eth_pcs_pma' generated file not found
'/home/dsp/rfnoc/src/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma_funcsim.vhdl'.
Please regenerate to continue.
Command: synth_design -top ten_gig_eth_pcs_pma -part xc7k410tffg900-2 -mode
out_of_context
Starting synth_design
WARNING: [IP_Flow 19-2162] IP 'ten_gig_eth_pcs_pma' is locked:
* The IP Data in the repository is incompatible with the current instance
(despite having identical Version and Revision). You will need to update the IP
before viewing the customization and generating outputs.
Please select 'Report IP Status' from the 'Tools/Report' menu or run Tcl
command 'report_ip_status' for more information.
Attempting to get a license for feature 'Synthesis' and/or device 'xc7k410t'
INFO: [Common 17-349] Got license for feature 'Synthesis' and/or device
'xc7k410t'
INFO: [Common 17-83] Releasing license: Synthesis
3 Infos, 2 Warnings, 0 Critical Warnings and 1 Errors encountered.
synth_design failed
ERROR: [Designutils 20-414] HRTInvokeSpec : No Verilog or VHDL sources specified
ERROR: [Common 17-53] User Exception: No open design. Please open an
elaborated, synthesized or implemented design before executing this command.
ERROR: [Common 17-53] User Exception: No open design. Please open an
elaborated, synthesized or implemented design before executing this command.
ERROR: [Common 17-53] User Exception: No open design. Please open an
elaborated, synthesized or implemented design before executing this command.
ERROR: [Common 17-53] User Exception: No open design. Please open an
elaborated, synthesized or implemented design before executing this command.
ERROR: [Common 17-53] User Exception: No open design. Please open an
elaborated, synthesized or implemented design before executing this command.
ERROR: [Common 17-53] User Exception: No open design. Please open an
elaborated, synthesized or implemented design before executing this command.
ERROR: [Vivado 12-398] No designs are open
****** Webtalk v2015.2 (64-bit)
**** SW Build 1266856 on Fri Jun 26 16:35:25 MDT 2015
**** IP Build 1264090 on Wed Jun 24 14:22:01 MDT 2015
** Copyright 1986-2015 Xilinx, Inc. All Rights Reserved.
source
/home/dsp/rfnoc/src/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/.Xil/Vivado-3846-dsp-ThinkPad-T440p/webtalk/labtool_webtalk.tcl
-notrace
while executing
"webtalk_transmit -clientid 2364942285 -regid
"174236156_177743796_210619486_449" -xml
/home/dsp/rfnoc/src/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410..."
(file
"/home/dsp/rfnoc/src/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/.Xil/Vivado-3846-dsp-ThinkPad-T440p/webtalk/labtool_webtalk.tcl"
line 26)
INFO: [Common 17-206] Exiting Webtalk at Fri Apr 8 10:51:36 2016...
INFO: [Vivado 12-3441] generate_netlist_ip - operation complete
synth_ip: Time (s): cpu = 00:00:00.82 ; elapsed = 00:00:06 . Memory (MB): peak
= 927.707 ; gain = 13.133 ; free physical = 5469 ; free virtual = 8870
# if [string match $gen_example_proj "1"] {
# puts "BUILDER: Generating Example Design..."
# open_example_project -force -dir . [get_ips $ip_name]
# }
BUILDER: Generating Example Design...
ERROR: [Common 17-69] Command failed: * The IP Data in the repository is
incompatible with the current instance (despite having identical Version and
Revision). You will need to update the IP before viewing the customization and
generating outputs.
Please select 'Report IP Status' from the 'Tools/Report' menu or run Tcl
command 'report_ip_status' for more information.
INFO: [Common 17-206] Exiting Vivado at Fri Apr 8 10:51:36 2016...
Releasing IP location:
/home/dsp/rfnoc/src/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma
make[1]: ***
[/home/dsp/rfnoc/src/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma.xci.out]
Error 1
make[1]: Leaving directory `/home/dsp/rfnoc/src/uhd/fpga-src/usrp3/top/x300'
make: *** [X310_RFNOC_HGS] Error 2
It seems that there is a IP-Version problem with the "ten_gig_eth_pc_pma" core.
I tried both, with and without "GUI=1". No difference. But without a Vivado
project I can't update the IP cores...
How could I solve this? Or is there a possibility to get a existing vivado
project with all project files?
So this is my first question about custom blocks. The others are following.
Thank you very much,
best regards
Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/a4358ecf/attachment-0001.html>
------------------------------
Message: 24
Date: Fri, 8 Apr 2016 13:01:29 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "Myers, David" <[email protected]>, "Brothers, Timothy"
<[email protected]>, "Hunter, Bill B."
<[email protected]>, "[email protected]"
<[email protected]>
Subject: [USRP-users] FW: Fw: rfnoc-radio-redo 3f8c97e Modelsim DE
10.4C simulation fails on noc_block_moving_avg_tb
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Jonathon,
I sent you the log file about ten days ago with why the rfnoc-radio-redo fails
on your off the shelf vanilla noc_block_moving_avg module. Any update on why
this is failing?
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th Street NW
Atlanta, GA 30318
Cell: 770-298-9156
http://www.gtri.gatech.edu
From: Swanson, Craig
Sent: Tuesday, March 29, 2016 7:49 AM
To: Jonathon Pendlum <[email protected]>
Subject: Re: Fw: rfnoc-radio-redo 3f8c97e Modelsim DE 10.4C simulation fails on
noc_block_moving_avg_tb
?Jonathon,
See the attached.
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
________________________________
From: Jonathon Pendlum
<[email protected]<mailto:[email protected]>>
Sent: Monday, March 28, 2016 1:31 PM
To: Swanson, Craig
Subject: Re: Fw: rfnoc-radio-redo 3f8c97e Modelsim DE 10.4C simulation fails on
noc_block_moving_avg_tb
What kind of warning messages?
Jonathon
On Mon, Mar 28, 2016 at 10:04 AM, Swanson, Craig
<[email protected]<mailto:[email protected]>> wrote:
Jonathon,
Thanks.
In the rfnoc-radio-redo I ran make on noc_block_moving_avg in the top/e300 and
lib/rfnoc and got lots of nasty looking warning messages that I don?t think I
ever saw in rfnoc-devel. My guess is that the radio redo is still very
immature in the synthesis and simulation.
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th Street NW
Atlanta, GA 30318
Cell: 770-298-9156<tel:770-298-9156>
http://www.gtri.gatech.edu
From: Jonathon Pendlum
[mailto:[email protected]<mailto:[email protected]>]
Sent: Monday, March 28, 2016 12:53 PM
To: Swanson, Craig
<[email protected]<mailto:[email protected]>>
Subject: Re: Fw: rfnoc-radio-redo 3f8c97e Modelsim DE 10.4C simulation fails on
noc_block_moving_avg_tb
Synthesis works. I will be pushing in the next day or so with fixes for the
test benches.
On Fri, Mar 25, 2016 at 11:33 AM, Swanson, Craig
<[email protected]<mailto:[email protected]>> wrote:
?Jonathon,
Are there any testbenches that work? I need to create a Receiver testbench
that is based off of a working testbench.
Does the synthesis part work if I run "make E310_RFNOC"?
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156<tel:770.298.9156>
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
________________________________
From: Jonathon Pendlum
<[email protected]<mailto:[email protected]>>
Sent: Friday, March 25, 2016 2:05 PM
To: Swanson, Craig
Subject: Re: Fw: rfnoc-radio-redo 3f8c97e Modelsim DE 10.4C simulation fails on
noc_block_moving_avg_tb
Several of the test benches are very likely to be broken since I made some big
test bench infrastructure improvements but didn't update all the test benches.
I plan on doing that soon, but for the next few days they will be broken.
On Fri, Mar 25, 2016 at 9:10 AM, Swanson, Craig
<[email protected]<mailto:[email protected]>> wrote:
Jonathon,
I was wrong about needing to add into usrp3/tools/scripts/viv_sim_project.tcl
set_property default_lib work [current_project]?
right before "launch_simulation".
I reloaded rfnoc-radio-redo and it wasn't necessary.
But I am still getting the error shown below in Modelsim.
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156<tel:770.298.9156>
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
________________________________
From: Swanson, Craig
Sent: Friday, March 25, 2016 11:43 AM
To: Jonathon Pendlum
Cc: [email protected]<mailto:[email protected]>
Subject: rfnoc-radio-redo 3f8c97e Modelsim DE 10.4C simulation fails on
noc_block_moving_avg_tb
Jonathon,
I moved to the rfnoc-radio-redo branch 3f8c97e and so far I am pleased with how
Modelsim DE 10.4c (a 32-bit executable) is responding. When I used the
rfnoc-devel branch, I could never run "make vsim". I always had to run "make
vsim GUI=1", and then call up modelsim from vivado. Maybe it has to do with
Vivado 2015.4 fixing the issue with
set_param project.enableUnifiedSimulation 0
which I believe is no longer needed.
I did have to go into usrp3/tools/scripts/viv_sim_project.tcl and add
set_property default_lib work [current_project]?
right before "launch_simulation".
But I am getting this error in Modelsim:
# do {noc_block_moving_avg_tb_simulate.do}
# vsim -voptargs=""+acc"" -t 1ps -c -L unisims_ver -L unimacro_ver -L secureip
-L work -L fifo_generator_v13_0_1 -L xil_defaultlib -L xbip_utils_v3_0_5 -L
axi_utils_v2_0_1 -L xbip_pipe_v3_0_1 -L xbip_dsp48_wrapper_v3_0_4 -L
xbip_dsp48_addsub_v3_0_1 -L xbip_bram18k_v3_0_1 -L mult_gen_v12_0_10 -L
floating_point_v7_0_11 -L xbip_dsp48_mult_v3_0_1 -L xbip_dsp48_multadd_v3_0_1
-L div_gen_v5_1_9 -lib work work.noc_block_moving_avg_tb work.glbl
# Start time: 11:30:41 on Mar 25,2016
# ** Error: (vsim-3170) Could not find
'/home/craig/uhd/fpga-src/usrp3/lib/rfnoc/noc_block_moving_avg_tb/modelsim_proj/modelsim_proj.sim/sim_1/behav/msim/work.noc_block_moving_avg_tb'.
# Error loading design
# Error: Error loading design
# Pausing macro execution
# MACRO ./noc_block_moving_avg_tb_simulate.do PAUSED at line 9
Any ideas?
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156<tel:770.298.9156>
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/41bb38c1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build.log
Type: text/x-log
Size: 109578 bytes
Desc: build.log
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/41bb38c1/attachment-0001.log>
------------------------------
Message: 25
Date: Fri, 8 Apr 2016 11:02:16 -0400
From: Ryan Marlow <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP x310 " ddr3_32bit: Code generation aborted:
Unconfigured MIG instance"
Message-ID:
<CADVE_uyBUb-1AzsJkfj+=vywcc6t0o9jjy3jzalfpzeu1b1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey Marcus (and anyone else),
Thank you for the suggestion. The error occurs with a fresh/cleaned build
directory.
Best,
Ryan
Hi Ryan,
>
> this is but a stab in the dark, but most things that make FPGA building
> fail for me (if I didn't mess something up myself...) is when I forgot
> to clean the build directory when updating/changing IP.
> Is it possible that's the case here? Does "make cleanall; make X310_HGS"
> (assuming that's the image flavour you're after) solve the issue?
>
> Best regards,
> Marcus
>
> On 08.04.2016 08:58, Ryan Marlow via USRP-users wrote:
> >* Hello all,
> *>* I am trying to build an image for the usrp x310 in vivado 2015.4.
> *>* While building the ddr3_32bit IP for the project, I get a read out
> *>* like this:
> *>> >>* ========================================================
> *>>* BUILDER: Building IP ddr3_32bit
> *>>* ========================================================
> *>>* BUILDER: Staging IP in build directory...
> *>>* Reserving IP location:
> *>*
> /home/rynmrlw/pybombs-prefix/src/uhd/fpga-src/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/ddr3_32bit
> *>>* BUILDER: Retargeting IP to part xc7k410tffg900-2...
> *>>* BUILDER: Building IP...
> *>>>* ****** Vivado v2015.4 (64-bit)
> *>>* **** SW Build 1412921 on Wed Nov 18 09:44:32 MST 2015
> *>>* **** IP Build 1412160 on Tue Nov 17 13:47:24 MST 2015
> *>>* ** Copyright 1986-2015 Xilinx, Inc. All Rights Reserved.
> *>>>* source
> *>*
> /home/rynmrlw/pybombs-prefix/src/uhd/fpga-src/fpga/usrp3/top/../tools/scripts/viv_generate_ip.tcl
> *>>* # set xci_file $::env(XCI_FILE) ;
> *>>* # set part_name $::env(PART_NAME) ;
> *>>* # set gen_example_proj $::env(GEN_EXAMPLE) ;
> *>>* # set synth_ip $::env(SYNTH_IP) ;
> *>>* # set ip_name [file rootname [file tail $xci_file]] ;
> *>>* # file delete -force "$xci_file.out"
> *>>* # create_project -part $part_name -in_memory -ip
> *>>* # set_property target_simulator XSim [current_project]
> *>>* # add_files -norecurse -force $xci_file
> *>>* INFO: [IP_Flow 19-234] Refreshing IP repositories
> *>>* INFO: [IP_Flow 19-1704] No user IP repositories specified
> *>>* INFO: [IP_Flow 19-2313] Loaded Vivado IP repository
> *>* '/opt/Xilinx/Vivado/2015.4/data/ip'.
> *>>* # reset_target all [get_files $xci_file]
> *>>* # puts "BUILDER: Generating IP Target..."
> *>>* BUILDER: Generating IP Target...
> *>>* # generate_target all [get_files $xci_file]
> *>>* INFO: [IP_Flow 19-1686] Generating 'Instantiation Template' target
> *>* for IP 'ddr3_32bit'...
> *>>* *ERROR: [xilinx.com:ip:mig_7series:2.4-0] ddr3_32bit: Code
> *>* generation aborted: Unconfigured MIG instance*
> *>>* *CRITICAL WARNING: [IP_Flow 19-1747] Failed to deliver file
> *>*
> '/opt/Xilinx/Vivado/2015.4/data/ip/xilinx/mig_7series_v2_4/xit/instantiation_template.xit':
> *
> *>>* *ERROR: [IP_Flow 19-167] Failed to deliver one or more file(s).*
> *>>* *ERROR: [IP_Flow 19-3505] IP Generation error: Failed to generate
> *>* IP 'ddr3_32bit'. Failed to generate 'Verilog Instantiation
> *>* Template' outputs: *
> *>>* *ERROR: [IP_Flow 19-98] Generation of the IP CORE failed.*
> *>>* Failed to generate IP 'ddr3_32bit'. Failed to generate 'Verilog
> *>* Instantiation Template' outputs:
> *>>* INFO: [Common 17-206] Exiting Vivado at Fri Apr 8 02:41:13 2016...
> *>>* Releasing IP location:
> *>*
> /home/rynmrlw/pybombs-prefix/src/uhd/fpga-src/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/ddr3_32bit
> *>>* make[1]: ***
> *>*
> [/home/rynmrlw/pybombs-prefix/src/uhd/fpga-src/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/ddr3_32bit/ddr3_32bit.xci.out]
> *>* Error 1
> *>>* make[1]: Leaving directory
> *>* `/home/rynmrlw/pybombs-prefix/src/uhd/fpga-src/fpga/usrp3/top/x300'
> *>>* make: *** [X310_RFNOC_HGS] Error 2
> *>>>* I've upgraded the IP using the upgrade_ip.sh script in the ip folder.
> *>* Is there a specific version of Vivado (and IP) that I should be using?
> *>* My current vivado configurations are also included in this print out.
> *>* Best,
> *>* Ryan Marlow
> *>>>* _______________________________________________
> *>* USRP-users mailing list
> *>* USRP-users at lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
> *>* http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>*
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/d157b06a/attachment-0001.html>
------------------------------
Message: 26
Date: Fri, 8 Apr 2016 11:14:32 -0400
From: devin kelly <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] X310 GPS LED
Message-ID:
<CAANLyubJfd=_3cowpr8ssj0j_secd8gco5cqoprzmi0d8py...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I've noticed that I'll turn on on my X310 the GPS LED is off and, after a
few minutes, I can run query_gpsdo_sensors and that reports a lock (with
the LED still off). Eventually the GPS LED turns on. I don't notice any
differences between the the output of query_gpsdo_sensors before and after
the LED lights up.
What controls when the LED lights up?
This is the UHD I'm using: UHD_003.009.003-0-gf0720677
Devin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/783c9b7e/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 68, Issue 8
*****************************************
