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: Trigger Tx on FPGA (Jonathon Pendlum)
2. Re: Can I get arbitrary sampling rate with X300+UBX? (Vladimir)
3. Re: E310 GPSDO clock reference (Derek Kozel)
4. Re: Can I get arbitrary sampling rate with X300+UBX?
(Marcus M?ller)
5. Re: Can I get arbitrary sampling rate with X300+UBX?
(Marcus M?ller)
6. Re: Trigger Tx on FPGA (Zhihong Luo)
7. Re: Extraneous tones on 200 MHz clock (Martin Braun)
8. Re: E310 GPSDO clock reference (Claudio Cicconetti)
9. Reducing noise / alternative cooling (Lars Almon)
10. Re: Fwd: Angle of Arrival Measurements (Evan Merewether)
11. Re: Can I get arbitrary sampling rate with X300+UBX? (Vladimir)
12. Re: building an E310 RFNoC FPGA image with HLS
([email protected])
----------------------------------------------------------------------
Message: 1
Date: Mon, 11 Apr 2016 10:09:16 -0700
From: Jonathon Pendlum <[email protected]>
To: Zhihong Luo <[email protected]>
Cc: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Trigger Tx on FPGA
Message-ID:
<cagdo0ura4ktiemewj5b3yb0nr4sqdnqcpkbg21v0df_1wkh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
Yes, you will keep s_axis_data_tvalid deasserted until you trigger on RX.
Alternatively, you can assert s_axis_data_tvalid until your last sample and
then hold s_axis_data_tvalid deasserted until you trigger on RX. By doing
that, you will preload the output FIFO with your waveform (minus one
sample) and reduce latency.
Jonathon
On Sun, Apr 10, 2016 at 1:39 PM, Zhihong Luo <[email protected]> wrote:
> Hi Jonathon,
>
> Thanks a lot for the reply! Yes, I'll use two axi_wrappers for this, so
> that I don't need to write deframer, fifo and framer, etc by myself.
>
> "To hold off TX, just don't send any data to the AXI wrapper module until
> you trigger on RX". To do this, do you mean deassert the
> s_axis_data_tvalid? I am sorry but I did not get the lowest latency
> method. Can you explain a little more?
>
> Thanks,
> Zhihong
>
> On Mon, Apr 11, 2016 at 4:09 AM, Jonathon Pendlum <
> [email protected]> wrote:
>
>> Hi Zhihong,
>>
>> No need for a split stream. You would set INPUT_PORTS=2 and
>> OUTPUT_PORTS=1 on noc_shell and connect two AXI Wrapper instances to
>> noc_shell for the two input block ports. Only one of the AXI wrapper's
>> output (str_src) will be connected noc_shell and you'll need to manually
>> setup the header (s_axis_data_tuser) since you cannot use SIMPLE_MODE in
>> this configuration.
>>
>> To hold off TX, just don't send any data to the AXI wrapper module until
>> you trigger on RX. Or if you want the lowest latency possible, send the TX
>> waveform minus one sample and when you trigger, send the final sample (with
>> tlast asserted).
>>
>>
>>
>> Jonathon
>>
>> On Wed, Apr 6, 2016 at 2:15 PM, Zhihong Luo <[email protected]> wrote:
>>
>>> Hi Jonathon,
>>>
>>> I have a look at the two examples involving multiple ports:
>>> *noc_block_addsub.v,
>>> **noc_block_split_stream.v*. They have the same format, deframer ->
>>> split_stream_fifo -> framer. Can I instead use split_stream_fifo at first,
>>> then separate axi_wrappers, for the hope that the axi_wrapper can take care
>>> of the possible timing issues for me?
>>>
>>> Thanks,
>>> Zhihong
>>>
>>> On Wed, Apr 6, 2016 at 4:19 PM, Zhihong Luo <[email protected]> wrote:
>>>
>>>> Jonathon,
>>>>
>>>> Thanks for the reply. It looks much cleaner in a flow-graph :)
>>>>
>>>> I wonder whether this is the right way to make a multiple input/output
>>>> port block: set the input/output port number in the noc_shell, then create
>>>> one axi_wrapper for each port. Do I need to use blocks like the
>>>> split_stream_fifo.v used?
>>>>
>>>> To hold off sending the TX, I can change the eob bit in the
>>>> s_axis_data_tuser, right?
>>>>
>>>> Thanks a lot,
>>>> Zhihong
>>>>
>>>>
>>>>
>>>> On Wed, Apr 6, 2016 at 3:37 PM, Jonathon Pendlum <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi Zhihong,
>>>>>
>>>>> Make your "trigger" block have two input ports, one from the host and
>>>>> one from Radio RX. Have your block consume the Radio RX data and hold off
>>>>> sending the TX waveform samples from the host until your trigger condition
>>>>> is satisfied. Your flowgraph would look something like this:
>>>>>
>>>>> Host --> Trigger block --> Radio TX
>>>>> ^----------- Radio RX
>>>>>
>>>>>
>>>>>
>>>>> Jonathon
>>>>>
>>>>> On Wed, Apr 6, 2016 at 12:17 PM, Zhihong Luo via USRP-users <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hi Martin,
>>>>>>
>>>>>> Thanks a lot for the advice, I am looking into it. I think what
>>>>>> really confuses me is how to "trigger" it from a different block. As I
>>>>>> said, I built a block on the RX chain for detection, how can I send the
>>>>>> trigger signal to the TX side (either radio.v or a TX RFNoC block)?
>>>>>>
>>>>>> Once I get this communication work, I can control the state by
>>>>>> changing the eob ( 1 for stop, 0 for start), is it right?
>>>>>>
>>>>>> Thanks,
>>>>>> Zhihong
>>>>>>
>>>>>> On Wed, Apr 6, 2016 at 12:51 PM, Martin Braun via USRP-users <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> For an example, you can have a look at the fosphor block, which uses
>>>>>>> EOB
>>>>>>> to keep track of state.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Martin
>>>>>>>
>>>>>>> On 04/05/2016 11:27 AM, Zhihong Luo wrote:
>>>>>>> > Hi Martin,
>>>>>>> >
>>>>>>> > Thanks a lot for the reply!
>>>>>>> >
>>>>>>> > Can you be more specific on how to do this on fpga? I don't know
>>>>>>> how to
>>>>>>> > control radio from a custom RFNoC block. For eob, do you mean eob
>>>>>>> in the
>>>>>>> > new_tx_control.v? I am confused by what eob, eop, odd stand for.
>>>>>>> >
>>>>>>> > Thanks,
>>>>>>> > Zhihong
>>>>>>> >
>>>>>>> > 2016?4?5?????Martin Braun via USRP-users
>>>>>>> > <[email protected] <mailto:[email protected]>>
>>>>>>> ???
>>>>>>> >
>>>>>>> > You can simply not output anything until your trigger
>>>>>>> condition is met,
>>>>>>> > or you could assert eob on your trigger.
>>>>>>> >
>>>>>>> > Cheers,
>>>>>>> > Martin
>>>>>>> >
>>>>>>> > On 04/02/2016 01:27 PM, Zhihong Luo via USRP-users wrote:
>>>>>>> > > Hi all,
>>>>>>> > >
>>>>>>> > > I try to implement a RFNoC detection block in RX, which
>>>>>>> should trigger
>>>>>>> > > TX when it observes a certain pattern of the received
>>>>>>> signal. Is
>>>>>>> > there a
>>>>>>> > > way to do this on FPGA? Because if I do this on PC, it seems
>>>>>>> very
>>>>>>> > > difficult to control the timing of the Tx. Thanks a lot for
>>>>>>> any help.
>>>>>>> > >
>>>>>>> > > Thanks,
>>>>>>> > > Zhihong
>>>>>>> > >
>>>>>>> > >
>>>>>>> > > _______________________________________________
>>>>>>> > > USRP-users mailing list
>>>>>>> > > [email protected] <javascript:;>
>>>>>>> > >
>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>> > >
>>>>>>> >
>>>>>>> >
>>>>>>> > _______________________________________________
>>>>>>> > USRP-users mailing list
>>>>>>> > [email protected] <javascript:;>
>>>>>>> >
>>>>>>> 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/20160411/6302f257/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 11 Apr 2016 20:45:09 +0300
From: Vladimir <[email protected]>
To: usrp-users <[email protected]>
Subject: Re: [USRP-users] Can I get arbitrary sampling rate with
X300+UBX?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Thank you!
On Ettus site a support for 184.32 and 120 MHz is also declared for X300. This
might help us to some degree. But?set_master_clock_rate() seems to have no
effect. How difficult is to build FPGA image with either of those hardcoded -
is it like changing some const in firmware source or requires significant
effort to get it running?
Vladimir
>???????????, 11 ?????? 2016, 17:54 +03:00 ?? [email protected]:
>
>The standard DSP chain in the X3xx family only allows sample rates that are an
>integer fraction of the master clock rate (200MHhz,
>?by default).
>If you want to re-sample with such fine resolution, you'll have to do it in
>host-side software, or do an implementation of a fractional resampler in the
>FPGA.
>?
>?
>On 2016-04-11 08:04, Vladimir via USRP-users wrote: Hello,
>>
>>Is it possible by any means to get the sampling rate fine tuned in X300 (eg 1
>>Hz resolution at 20 Msps point)? Is there any input point where we can
>>provide some reference freq or directly Fs from an external source? Or, may
>>be some custom FPGA version implementing arbitrary resampling or
>>reprogramming dsp to the exact freq?
>>
>>If there is no ready solution yet, what would be the best (easiest) way to
>>implement it by our own means?
>>
>>Vladimir
>>
>>
>>
>>_______________________________________________
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/20160411/2025646f/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 11 Apr 2016 10:46:48 -0700
From: Derek Kozel <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: Claudio Cicconetti <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] E310 GPSDO clock reference
Message-ID:
<CAA+K=ts1Rp_QQ=WdRuyEL8nAk3CjkkH5PYJB1vm419W=t4q...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I would add that your steady state plot appears to still be stabilizing
over the 10 seconds plotted.
On Mon, Apr 11, 2016 at 8:18 AM, <[email protected]> wrote:
> My understanding is that the DPLL in the FPGA that is used to convert the
> 1PPS from the on-board clock module to a synchronized master clock is going
> to be revised to provide improved synchronization. I don't have any idea
> about when that might happen.
>
> Looks like your steady-state stability is on the order of 10PPB
> currently. I'm not sure what magnitude of improvement is envisioned.
>
>
>
>
>
>
> On 2016-04-11 06:58, Claudio Cicconetti wrote:
>
> Dear Derek, Marcus,
> I ran the experiments as you suggested.
>
> Specifically, in the E310 I used the GPSDO as time source and then
> generated a constant signal while measuring from another (validated)
> device the frequency drift with respect to the nominal expected
> frequency. The centre frequency used is 1.2 GHz. The results were
> repeatable, with negligible result differences from a run to any another
> one.
>
> I collected about 5 minutes of traces. The raw data is available at the
> following URL (column 1: time in ms; column 2: frequency drift in Hz):
> https://dl.dropboxusercontent.com/u/3247031/freq_drift_trace.txt
>
> In the pictures at the following URL I have plotted, respectively, the
> drift at start-up (first 10 s) and while the system is in a steady state
> (for instance, in seconds from 60 to 70):
> https://dl.dropboxusercontent.com/u/3247031/freq_drift_startup.png
> https://dl.dropboxusercontent.com/u/3247031/freq_drift_steadystate.png
>
> The good news is that the drift converges after a few seconds.
>
> The bad news is that there are still non-negligible oscillations, in the
> order of a few tens of Hz.
>
> In my application these oscillations may cause issues. In fact, I was
> relying on the internal GPSDO to yield a much more stable clock,
> comparable with what I get on a series N or X device.
>
> Is this the best I can ever get from my E310 or would it be possible to
> have improvements with a change to the UHD library of E310 FPGA?
>
> Best regards,
> Claudio
>
>
> On 04/09/2016 01:38 AM, Derek Kozel via USRP-users wrote:
>
> Hi Claudio, The E310 can be locked to an external 1PPS or can use it's
> internal GPS receiver with an external antenna to discipline it's
> reference. It cannot use an external 10 MHz reference in the same way as
> other USRPs. Marcus' questions are the ones I would have asked next to
> determine many parts per million drift are you seeing. Can you capture a
> longer duration, both starting from t=0 when you set the time source to the
> gpsdo or 1PPS on the external SYNC, and where t=0 is more than a minute
> after the ref_locked sensor returns true? Thanks, Derek On Fri, Apr 8, 2016
> at 3:45 PM, Marcus D. Leech via USRP-users < [email protected]>
> wrote:
>
> On 04/08/2016 03:35 AM, Claudio Cicconetti via USRP-users wrote:
>
> 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
>
> Claudio: I've raised this with engineering, and hopefully someone will
> pipe up in the next couple of days on this subject, or sooner. So it looks
> like the amplitude of corrections is about 120Hz, but at what center
> frequency? Just to calibrate things. How long did you let the 1PPS run with
> your program before taking measurements? The servo on the E310 can be
> fairly slow to converge with a 1PPS input.
>
> 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.
>
> _______________________________________________ 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 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/20160411/26031592/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 11 Apr 2016 19:53:20 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Can I get arbitrary sampling rate with
X300+UBX?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
You can select one of the three possible master clock rates, 200MHz,
184.32MHz or 120MHz directly at initialization. A possible way to do so
is adding e.g "master_clock_rate=184.32e6" to the device address you use
with multi_usrp::make()
Note that you can't really use the 120MHz clock rate with the UBX-160;
the daughterboard has a 160MHz baseband with, and Nyquist frowns upon
sampling that with 120MS/s!
The real problem is that something like arbitrary resampling is usually
very demanding ? if you do it on a CPU, then it's often done with an
adjustable interpolation polynomial, and eats a lot of cycles, and if
done in hardware, complicated multi-staged fractional resamplers might
be the answer, or living with reduced signal quality, switching between
two "relatively close" resampling ratios.
Now, one thing to realize: When sampling at 200MS/s, a sample rate
resolution of 1Hz is but 5ppb, so you'll need an insanely accurate
oscillator to even notice that. Usually, you don't resample for such
imperfections, at least not statically; you rather use a symbol timing
tracking loop in software, if you're building a communications system.
May I hence ask: Why do you need finely adjustable sampling rates for?
Best regards,
Marcus
On 11.04.2016 19:45, Vladimir via USRP-users wrote:
> Thank you!
>
> On Ettus site a support for 184.32 and 120 MHz is also declared for
> X300. This might help us to some degree. But set_master_clock_rate()
> seems to have no effect. How difficult is to build FPGA image with
> either of those hardcoded - is it like changing some const in firmware
> source or requires significant effort to get it running?
>
> Vladimir
>
> ???????????, 11 ?????? 2016, 17:54 +03:00 ?? [email protected]:
>
> The standard DSP chain in the X3xx family only allows sample rates
> that are an integer fraction of the master clock rate (200MHhz,
> by default).
>
> If you want to re-sample with such fine resolution, you'll have to
> do it in host-side software, or do an implementation of a
> fractional resampler in the FPGA.
>
>
>
>
>
> On 2016-04-11 08:04, Vladimir via USRP-users wrote:
>
>> Hello,
>>
>> Is it possible by any means to get the sampling rate fine tuned
>> in X300 (eg 1 Hz resolution at 20 Msps point)? Is there any input
>> point where we can provide some reference freq or directly Fs
>> from an external source? Or, may be some custom FPGA version
>> implementing arbitrary resampling or reprogramming dsp to the
>> exact freq?
>>
>> If there is no ready solution yet, what would be the best
>> (easiest) way to implement it by our own means?
>>
>> Vladimir
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> <//e.mail.ru/compose/?mailto=mailto%3ausrp%[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/20160411/f7b0fc1b/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 11 Apr 2016 19:53:31 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Can I get arbitrary sampling rate with
X300+UBX?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
You can select one of the three possible master clock rates, 200MHz,
184.32MHz or 120MHz directly at initialization. A possible way to do so
is adding e.g "master_clock_rate=184.32e6" to the device address you use
with multi_usrp::make()
Note that you can't really use the 120MHz clock rate with the UBX-160;
the daughterboard has a 160MHz baseband with, and Nyquist frowns upon
sampling that with 120MS/s!
The real problem is that something like arbitrary resampling is usually
very demanding ? if you do it on a CPU, then it's often done with an
adjustable interpolation polynomial, and eats a lot of cycles, and if
done in hardware, complicated multi-staged fractional resamplers might
be the answer, or living with reduced signal quality, switching between
two "relatively close" resampling ratios.
Now, one thing to realize: When sampling at 200MS/s, a sample rate
resolution of 1Hz is but 5ppb, so you'll need an insanely accurate
oscillator to even notice that. Usually, you don't resample for such
imperfections, at least not statically; you rather use a symbol timing
tracking loop in software, if you're building a communications system.
May I hence ask: Why do you need finely adjustable sampling rates? What
is your intended application?
Best regards,
Marcus
On 11.04.2016 19:45, Vladimir via USRP-users wrote:
> Thank you!
>
> On Ettus site a support for 184.32 and 120 MHz is also declared for
> X300. This might help us to some degree. But set_master_clock_rate()
> seems to have no effect. How difficult is to build FPGA image with
> either of those hardcoded - is it like changing some const in firmware
> source or requires significant effort to get it running?
>
> Vladimir
>
> ???????????, 11 ?????? 2016, 17:54 +03:00 ?? [email protected]:
>
> The standard DSP chain in the X3xx family only allows sample rates
> that are an integer fraction of the master clock rate (200MHhz,
> by default).
>
> If you want to re-sample with such fine resolution, you'll have to
> do it in host-side software, or do an implementation of a
> fractional resampler in the FPGA.
>
>
>
>
>
> On 2016-04-11 08:04, Vladimir via USRP-users wrote:
>
>> Hello,
>>
>> Is it possible by any means to get the sampling rate fine tuned
>> in X300 (eg 1 Hz resolution at 20 Msps point)? Is there any input
>> point where we can provide some reference freq or directly Fs
>> from an external source? Or, may be some custom FPGA version
>> implementing arbitrary resampling or reprogramming dsp to the
>> exact freq?
>>
>> If there is no ready solution yet, what would be the best
>> (easiest) way to implement it by our own means?
>>
>> Vladimir
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> <//e.mail.ru/compose/?mailto=mailto%3ausrp%[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/20160411/69010743/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 11 Apr 2016 15:24:03 -0400
From: Zhihong Luo <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Trigger Tx on FPGA
Message-ID:
<cah4wxlpmvd3pyeo9wxunt-t2ddypo+ghftawt141rhwqxve...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Jonathon,
Oh, I got it. Thank you very much for the help!
Best regards,
Zhihong
On Mon, Apr 11, 2016 at 1:09 PM, Jonathon Pendlum <
[email protected]> wrote:
> Hi,
>
> Yes, you will keep s_axis_data_tvalid deasserted until you trigger on RX.
> Alternatively, you can assert s_axis_data_tvalid until your last sample and
> then hold s_axis_data_tvalid deasserted until you trigger on RX. By doing
> that, you will preload the output FIFO with your waveform (minus one
> sample) and reduce latency.
>
>
>
> Jonathon
>
> On Sun, Apr 10, 2016 at 1:39 PM, Zhihong Luo <[email protected]> wrote:
>
>> Hi Jonathon,
>>
>> Thanks a lot for the reply! Yes, I'll use two axi_wrappers for this, so
>> that I don't need to write deframer, fifo and framer, etc by myself.
>>
>> "To hold off TX, just don't send any data to the AXI wrapper module until
>> you trigger on RX". To do this, do you mean deassert the
>> s_axis_data_tvalid? I am sorry but I did not get the lowest latency
>> method. Can you explain a little more?
>>
>> Thanks,
>> Zhihong
>>
>> On Mon, Apr 11, 2016 at 4:09 AM, Jonathon Pendlum <
>> [email protected]> wrote:
>>
>>> Hi Zhihong,
>>>
>>> No need for a split stream. You would set INPUT_PORTS=2 and
>>> OUTPUT_PORTS=1 on noc_shell and connect two AXI Wrapper instances to
>>> noc_shell for the two input block ports. Only one of the AXI wrapper's
>>> output (str_src) will be connected noc_shell and you'll need to manually
>>> setup the header (s_axis_data_tuser) since you cannot use SIMPLE_MODE in
>>> this configuration.
>>>
>>> To hold off TX, just don't send any data to the AXI wrapper module until
>>> you trigger on RX. Or if you want the lowest latency possible, send the TX
>>> waveform minus one sample and when you trigger, send the final sample (with
>>> tlast asserted).
>>>
>>>
>>>
>>> Jonathon
>>>
>>> On Wed, Apr 6, 2016 at 2:15 PM, Zhihong Luo <[email protected]> wrote:
>>>
>>>> Hi Jonathon,
>>>>
>>>> I have a look at the two examples involving multiple ports:
>>>> *noc_block_addsub.v,
>>>> **noc_block_split_stream.v*. They have the same format, deframer ->
>>>> split_stream_fifo -> framer. Can I instead use split_stream_fifo at first,
>>>> then separate axi_wrappers, for the hope that the axi_wrapper can take care
>>>> of the possible timing issues for me?
>>>>
>>>> Thanks,
>>>> Zhihong
>>>>
>>>> On Wed, Apr 6, 2016 at 4:19 PM, Zhihong Luo <[email protected]> wrote:
>>>>
>>>>> Jonathon,
>>>>>
>>>>> Thanks for the reply. It looks much cleaner in a flow-graph :)
>>>>>
>>>>> I wonder whether this is the right way to make a multiple input/output
>>>>> port block: set the input/output port number in the noc_shell, then create
>>>>> one axi_wrapper for each port. Do I need to use blocks like the
>>>>> split_stream_fifo.v used?
>>>>>
>>>>> To hold off sending the TX, I can change the eob bit in the
>>>>> s_axis_data_tuser, right?
>>>>>
>>>>> Thanks a lot,
>>>>> Zhihong
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Apr 6, 2016 at 3:37 PM, Jonathon Pendlum <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hi Zhihong,
>>>>>>
>>>>>> Make your "trigger" block have two input ports, one from the host and
>>>>>> one from Radio RX. Have your block consume the Radio RX data and hold off
>>>>>> sending the TX waveform samples from the host until your trigger
>>>>>> condition
>>>>>> is satisfied. Your flowgraph would look something like this:
>>>>>>
>>>>>> Host --> Trigger block --> Radio TX
>>>>>> ^----------- Radio RX
>>>>>>
>>>>>>
>>>>>>
>>>>>> Jonathon
>>>>>>
>>>>>> On Wed, Apr 6, 2016 at 12:17 PM, Zhihong Luo via USRP-users <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Hi Martin,
>>>>>>>
>>>>>>> Thanks a lot for the advice, I am looking into it. I think what
>>>>>>> really confuses me is how to "trigger" it from a different block. As I
>>>>>>> said, I built a block on the RX chain for detection, how can I send the
>>>>>>> trigger signal to the TX side (either radio.v or a TX RFNoC block)?
>>>>>>>
>>>>>>> Once I get this communication work, I can control the state by
>>>>>>> changing the eob ( 1 for stop, 0 for start), is it right?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Zhihong
>>>>>>>
>>>>>>> On Wed, Apr 6, 2016 at 12:51 PM, Martin Braun via USRP-users <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> For an example, you can have a look at the fosphor block, which
>>>>>>>> uses EOB
>>>>>>>> to keep track of state.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Martin
>>>>>>>>
>>>>>>>> On 04/05/2016 11:27 AM, Zhihong Luo wrote:
>>>>>>>> > Hi Martin,
>>>>>>>> >
>>>>>>>> > Thanks a lot for the reply!
>>>>>>>> >
>>>>>>>> > Can you be more specific on how to do this on fpga? I don't know
>>>>>>>> how to
>>>>>>>> > control radio from a custom RFNoC block. For eob, do you mean eob
>>>>>>>> in the
>>>>>>>> > new_tx_control.v? I am confused by what eob, eop, odd stand for.
>>>>>>>> >
>>>>>>>> > Thanks,
>>>>>>>> > Zhihong
>>>>>>>> >
>>>>>>>> > 2016?4?5?????Martin Braun via USRP-users
>>>>>>>> > <[email protected] <mailto:[email protected]>>
>>>>>>>> ???
>>>>>>>> >
>>>>>>>> > You can simply not output anything until your trigger
>>>>>>>> condition is met,
>>>>>>>> > or you could assert eob on your trigger.
>>>>>>>> >
>>>>>>>> > Cheers,
>>>>>>>> > Martin
>>>>>>>> >
>>>>>>>> > On 04/02/2016 01:27 PM, Zhihong Luo via USRP-users wrote:
>>>>>>>> > > Hi all,
>>>>>>>> > >
>>>>>>>> > > I try to implement a RFNoC detection block in RX, which
>>>>>>>> should trigger
>>>>>>>> > > TX when it observes a certain pattern of the received
>>>>>>>> signal. Is
>>>>>>>> > there a
>>>>>>>> > > way to do this on FPGA? Because if I do this on PC, it
>>>>>>>> seems very
>>>>>>>> > > difficult to control the timing of the Tx. Thanks a lot for
>>>>>>>> any help.
>>>>>>>> > >
>>>>>>>> > > Thanks,
>>>>>>>> > > Zhihong
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> > > _______________________________________________
>>>>>>>> > > USRP-users mailing list
>>>>>>>> > > [email protected] <javascript:;>
>>>>>>>> > >
>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>> > >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > _______________________________________________
>>>>>>>> > USRP-users mailing list
>>>>>>>> > [email protected] <javascript:;>
>>>>>>>> >
>>>>>>>> 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/20160411/8b83acb9/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 11 Apr 2016 12:25:02 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Extraneous tones on 200 MHz clock
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Ed,
if the tones are coming from your custom daughtercard, there's not much
we can do to help.
Can you remove the card, try one of ours, and see of this still happens?
Also, can you specify exactly what you're running when you're seeing this?
Cheers,
Martin
On 04/07/2016 12:08 PM, Ed via USRP-users wrote:
> 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
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 8
Date: Tue, 12 Apr 2016 11:03:02 +0200
From: Claudio Cicconetti <[email protected]>
To: [email protected], [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, Marcus,
I thank you both again for your support.
I look forward to receiving further updates on this issue, when available.
I must admit I am not fully satisfied by the final picture I get, which
is quite different from what I could understand from the E310 datasheet
and manual.
Surely all the information is there somewhere, but I would suggest to
make it clearer to potential customers that the best clock accuracy you
can obtain with E310 is much worse that what you get with any other
Ettus device.
This would have saved me a lot of time and bother.
Best regards,
Claudio
On 04/11/2016 07:46 PM, Derek Kozel wrote:
> I would add that your steady state plot appears to still be stabilizing
> over the 10 seconds plotted.
>
> On Mon, Apr 11, 2016 at 8:18 AM, <[email protected]> wrote:
>
>> My understanding is that the DPLL in the FPGA that is used to convert the
>> 1PPS from the on-board clock module to a synchronized master clock is going
>> to be revised to provide improved synchronization. I don't have any idea
>> about when that might happen.
>>
>> Looks like your steady-state stability is on the order of 10PPB
>> currently. I'm not sure what magnitude of improvement is envisioned.
>>
>>
>>
>>
>>
>>
>> On 2016-04-11 06:58, Claudio Cicconetti wrote:
>>
>> Dear Derek, Marcus,
>> I ran the experiments as you suggested.
>>
>> Specifically, in the E310 I used the GPSDO as time source and then
>> generated a constant signal while measuring from another (validated)
>> device the frequency drift with respect to the nominal expected
>> frequency. The centre frequency used is 1.2 GHz. The results were
>> repeatable, with negligible result differences from a run to any another
>> one.
>>
>> I collected about 5 minutes of traces. The raw data is available at the
>> following URL (column 1: time in ms; column 2: frequency drift in Hz):
>> https://dl.dropboxusercontent.com/u/3247031/freq_drift_trace.txt
>>
>> In the pictures at the following URL I have plotted, respectively, the
>> drift at start-up (first 10 s) and while the system is in a steady state
>> (for instance, in seconds from 60 to 70):
>> https://dl.dropboxusercontent.com/u/3247031/freq_drift_startup.png
>> https://dl.dropboxusercontent.com/u/3247031/freq_drift_steadystate.png
>>
>> The good news is that the drift converges after a few seconds.
>>
>> The bad news is that there are still non-negligible oscillations, in the
>> order of a few tens of Hz.
>>
>> In my application these oscillations may cause issues. In fact, I was
>> relying on the internal GPSDO to yield a much more stable clock,
>> comparable with what I get on a series N or X device.
>>
>> Is this the best I can ever get from my E310 or would it be possible to
>> have improvements with a change to the UHD library of E310 FPGA?
>>
>> Best regards,
>> Claudio
>>
>>
>> On 04/09/2016 01:38 AM, Derek Kozel via USRP-users wrote:
>>
>> Hi Claudio, The E310 can be locked to an external 1PPS or can use it's
>> internal GPS receiver with an external antenna to discipline it's
>> reference. It cannot use an external 10 MHz reference in the same way as
>> other USRPs. Marcus' questions are the ones I would have asked next to
>> determine many parts per million drift are you seeing. Can you capture a
>> longer duration, both starting from t=0 when you set the time source to the
>> gpsdo or 1PPS on the external SYNC, and where t=0 is more than a minute
>> after the ref_locked sensor returns true? Thanks, Derek On Fri, Apr 8, 2016
>> at 3:45 PM, Marcus D. Leech via USRP-users < [email protected]>
>> wrote:
>>
>> On 04/08/2016 03:35 AM, Claudio Cicconetti via USRP-users wrote:
>>
>> 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
>>
>> Claudio: I've raised this with engineering, and hopefully someone will
>> pipe up in the next couple of days on this subject, or sooner. So it looks
>> like the amplitude of corrections is about 120Hz, but at what center
>> frequency? Just to calibrate things. How long did you let the 1PPS run with
>> your program before taking measurements? The servo on the E310 can be
>> fairly slow to converge with a 1PPS input.
>>
>> 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.
>>
>> _______________________________________________ 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 list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
------------------------------
Message: 9
Date: Tue, 12 Apr 2016 09:46:35 +0200
From: Lars Almon <[email protected]>
To: [email protected]
Subject: [USRP-users] Reducing noise / alternative cooling
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hello list,
has anyone experience in alternative cooling methods for the USRPs
(preferably the X310 series)?
For a testbed we are going to deploy some X310s around the campus in
normal offices (indoor, ~21?C ambient temperature).
To increase the acceptance factor we would like to reduce the noise to a
minimum.
This means removing / deactivating the two small fans.
But to ensure proper cooling, we thought about creating a custom casing
with a larger heat sink and a bigger more silent fan.
Of course a passive solution would be best.
I would be interested if anyone of you already did something similar,
maybe with other USRPs?
Thank you!
- Lars Almon
------------------------------
Message: 10
Date: Tue, 12 Apr 2016 07:59:28 -0600
From: "Evan Merewether" <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] Fwd: Angle of Arrival Measurements
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Michael,
After a quick look, it seems that the methodology is sound, but you may have
problems with the way you are testing. Here are a few things you can do to
improve your measurements and test the performance.
First, height is your friend. Don?t think that getting closer to the station
tower is better. The Tower probably is an array so you will not be in the
main beam anyway. Find the tallest building in the area and ask if you can
do your tests on their roof. A clear and open line of sight to the tower is
your goal here.
Second, what else can the signal be bouncing off of? Is there a tall water
tower nearby? Could you be seeing the effects of reflected signals? For
this, again, height is your friend. By moving to a tall building, you will
minimize the number and strength of possible reflective surfaces.
Third, is the signal really entering the antenna? Or is it coupling to the
receiver. This can be easily tested by removing the antennas and verifying
that the signals drop by at least 10 dB. The more it drops, the better your
measurement. I would try and get at least 20 dB of isolation for a good AoA
measurement.
Evan
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus D. Leech via USRP-users
Sent: Friday, April 08, 2016 3:17 PM
To: [email protected]
Subject: Re: [USRP-users] Fwd: Angle of Arrival Measurements
On 04/08/2016 04:21 PM, Marcus M?ller via USRP-users wrote:
Hi Michael,
So, I'm currently having a look at your flow graphs; they look sound to me;
especially the complex method (Which pretty much is equivalent to picking
one frequency bin from the FFT, if you add a sharp bandpass filter, so that
you only see one frequency) looks efficient. In fact, seeing both approaches
in one place reminded me of OFDM radar, where one actually takes advantage
of the
I use the complex-conjugate method in astronomical interferometry, which is
related to AoA, at least in an incidental sense--the emergence
of fringes is due to change in phase due to change in arrival angle
relative to the baseline between the antenna.
I also just use it for measuring and/or looking-for phase-drift between two
sources that should be phase-coherent.
time/frequency structure of the signal, and, more elementarily, the fact
that a shift in time domain is a modulation with an offset frequency in
frequency domain. Maybe [1] is a bit of a fun read to you; for the angle of
arrival problem (which for your approaches is really but a time offset
problem), things boil down to:
If and are the same signal, but is delayed by , then their Fourier
transforms and are also the same but for the latter being the first
modulated by a complex sinusoid. Estimating that sinusoid's frequency gives
you the timing offset; you can get the "pure" tone by just dividing .
Looking at the discrete signal case, note that the frequency resolution you
can get depends on the DFT you're doing ? i.e. longer observation/larger DFT
has a very positive effect on accuracy!
I'd really love to see multiple approaches at AoA being implemented, that
will definitely be an interesting use case for both SDR in general, the USRP
B210, and GNU Radio; I don't remember fully, but I think the cel-kit account
on github has a gr-specest repo, where you can find a few examples of
parametric spectrum estimators; amongst these MUSIC, an algorithm actually
originating in the world of direction detection, applied to frequency
estimation. It should be pretty straightforward to adapt the algorithm to
spatial problems ? basically, you'd replace the estimated signal
autocovariance matrix by a antenna cross-correlation matrix.
Best regards,
Marcus
[1] Braun, Martin. Ofdm radar algorithms in mobile communication networks.
Diss. Karlsruhe, Karlsruher Institut f?r Technologie (KIT), Diss., 2014,
2014.
http://d-nb.info/104838490X/34
On 08.04.2016 21:15, Michael Duckett via USRP-users wrote:
We are using two antennas on the same B210 and the distance between them is
7cm (the distance between the two "TX/RX" ports). We understand that this
affects the measured phase difference and the further calculation for the
AOA. For future tests we may try to widen the distance between the two
antennas to half the wavelength (I think that would be around 1.3 to 1.7 m
for FM radio station frequencies).
This distance between the two antennas brings us to the first question.
Because the distance between the antennas was small compared to half the
wavelength of the frequency, the range of valid phase differences was
shrunk, too. Most of the time when we were measuring we got phase
differences which were out of range of the valid region. In one spot close
to the tower, we positioned our antenna array at the 0 degree orientation
and phase difference values which corresponded to 60-70 degrees. In another
spot with the same orientation, we got phase difference values which were
out of range. So when we rotated the antenna array, it was difficult to
compared the AOA because most of the time that calculation wasn't possible.
But we can see noticeable changes in the phase difference when rotating the
array. But there doesn't seem to be an easily decipherable pattern to the
error.
We haven't been monitoring the time domain signal levels. We can try that
next time, as well.
On Fri, Apr 8, 2016 at 2:19 PM, Derek Kozel <[email protected]
<mailto:[email protected]> > wrote:
Hello Michael,
In addition to Alexander's good thoughts, are you monitoring the time domain
signal levels to ensure that the receive gain is set appropriately? I see a
QT GUI Sink (you may consider using the QT Frequency Sink), but it would be
worth while looking at a QT Time Sink as well to see if you are clipping.
Regards,
Derek
On Fri, Apr 8, 2016 at 10:28 AM, Alexander Levedahl via USRP-users
<[email protected] <mailto:[email protected]> > wrote:
I do not have the ability to look at files right now so sorry if I am asking
questions that are answered in the files.
If you stand in one spot and rotate, is the error consistent? I.e., if you
are pointing the array right at it, it shows the AOA as 60-70. If you
change to pointing 30 degrees, does the AOA change to 90-100?
Are the results consistent across restarting the B210? Depending on the
answer to these questions, it may simply be a calibration problem. I.e.,
when you turn it on there needs to be a calibration step.
Finally, how many antennas are you using 2 or are you using multiple B210s?
Is your antenna spaced appropriately for the operating frequency?
On Fri, Apr 8, 2016 at 12:51 PM, Michael Duckett via USRP-users
<[email protected] <mailto:[email protected]> > wrote:
Hello,
We are trying to measure the angle of arrival of FM using USRP B210. We have
run into some problems with the measurements and hence we are writing this
email. It would be nice if we can get some inputs from you on how to fix
this issue. We have used two methods for computing the phase difference. We
have used the first one most of the time. However, we are posting both the
methods here for you to have a look.
I have attached method 1 (phase_difference_probe.grc for probing and
phase_difference_view.grc which provides a nice GUI to look at) and method 2
(complex_method.grc). Method 1 is based on the following "paper":
http://www.egr.msu.edu/classes/ece480/capstone/spring14/group02/docs/Applica
tion%20Note%20-%20Phase%20George%20Godby%20Team%202.pdf
We use these flow graphs and run them in another script which probes the
"top_block" to get 500 samples which are then averaged to produce one data
point.
We also attach a diagram (AoA_Figure.pdf) which shows a basic idea of how
the antennas and transmitter are setup and what the Angle of Arrival (AoA)
is, when it comes to our measurements.
We tried our code in two different situations. In our first test, our
transmitter was another B210 and we were in an open field. The frequency we
tried ranged from 200 MHz to 1.0 GHz and then 3 GHz and 4 GHz. Our Phase
difference and consequently our AoA measurement were not too far off, when
the antenna array was facing the transmitter (i.e. at an expected AoA of 0
degs). As we moved closer towards an AoA of +- 90 the accuracy of the
measurement fell off. But the consistency of the 500 samples was still
pretty good (we were getting a standard deviation under 0.10 radians).
For our second test, we tried to get the AoA from FM radio towers. We got
about 800-1000m away from a popular radio station tower and pointed the
antenna array at the tower (expecting an AoA of around 0 degs). But we got
measurements which were way off. We did this for a couple of different spots
but the measurements were all over the place (the standard deviation for
individual data points were pretty good but the measurement for the 0 deg
position at one spot was different for another spot around the tower). We
did manege to get angle measurements at one point when we were about 800
meters from the tower. The expected angle was 0 but we got 60 - 70 degrees
as the measured angle. We also tried at other places, one was about 800 m
from the tower and the other about 1200m. But both these places were
problematic.
It would be nice to get your inputs on the flow graphs. What are your
thoughts about the flow graph? Do you see any glaring problems with the flow
graph or with the set up? If you have any more questions about the setup
then feel free to ask.
Most of the information about the setup that we are using are in the
attached grc files. Thanks a lot for all your time.
Sincerely,
Michael Duckett
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160412/b60d6bfe/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 567 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160412/b60d6bfe/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 590 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160412/b60d6bfe/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 1170 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160412/b60d6bfe/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 526 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160412/b60d6bfe/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 598 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160412/b60d6bfe/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 583 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160412/b60d6bfe/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 1158 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160412/b60d6bfe/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.png
Type: image/png
Size: 657 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160412/b60d6bfe/attachment-0015.png>
------------------------------
Message: 11
Date: Tue, 12 Apr 2016 17:20:36 +0300
From: Vladimir <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Can I get arbitrary sampling rate with
X300+UBX?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Marcus,
Thank you for comprehensive answer! In fact, note, I didn't speak about 5 ppb
accuracy :). I'm not so experienced in sdr field yet, it's why I missed an
order of value - actually I should be talking about 1Hz at 2 MHz sampling rate,
and it makes it 0.5 ppm. But all this happened from my inexperience - actually
what I'm doing is trying to see a presence of LTE signal in the air, and having
X300 I tried to get an open src utility LTE Cell Scanner to work with it.
Actually, 184.32 MHz ideally fits this task, so problem is over now, it works
just fine. The matter was that LTE Scanner (working with RTLSDR) sets up the
sampling rate multiplied by some correction coeff wich is like 0.999998..., so
I didn't realize at once how to get a working set up.
Speaking about parameters passed to make() - can I find the list of all them
somewhere summarized? Couldn't find it. Can I cut some initialization time
instructing it not to perform some searching procedures - for example, tell it
not to search for GPSDO since it's not installed? Which parameters should I
pass to make() to minimize startup time of this combo - X300+UBX?
Thanks!
Vladimir
>???????????, 11 ?????? 2016, 20:53 +03:00 ?? Marcus M?ller via USRP-users
><[email protected]>:
>
>You can select one of the three possible master clock rates, 200MHz,
184.32MHz or 120MHz directly at initialization. A possible way to do
so is adding e.g "master_clock_rate=184.32e6" to the device address
you use with multi_usrp::make()
>
>Note that you can't really use the 120MHz clock rate with the
UBX-160; the daughterboard has a 160MHz baseband with, and Nyquist
frowns upon sampling that with 120MS/s!
>
>The real problem is that something like arbitrary resampling is
usually very demanding ? if you do it on a CPU, then it's often done
with an adjustable interpolation polynomial, and eats a lot of
cycles, and if done in hardware, complicated multi-staged fractional
resamplers might be the answer, or living with reduced signal
quality, switching between two "relatively close" resampling ratios.
>
>Now, one thing to realize: When sampling at 200MS/s, a sample rate
resolution of 1Hz is but 5ppb, so you'll need an insanely accurate
oscillator to even notice that. Usually, you don't resample for such
imperfections, at least not statically; you rather use a symbol
timing tracking loop in software, if you're building a
communications system.
>
>May I hence ask: Why do you need finely adjustable sampling rates
for?
>
>Best regards,
>Marcus
>
>On 11.04.2016 19:45, Vladimir via
USRP-users wrote:
>>Thank you!
>>
>>On Ettus site a support for 184.32 and 120 MHz is also declared
for X300. This might help us to some degree.
But?set_master_clock_rate() seems to have no effect. How difficult
is to build FPGA image with either of those hardcoded - is it like
changing some const in firmware source or requires significant
effort to get it running?
>>
>>Vladimir
>>
>>>???????????, 11 ?????? 2016, 17:54 +03:00
?? [email protected] :
>>>
>>>The standard DSP chain in the X3xx family only allows
sample rates that are an integer fraction of the
master clock rate (200MHhz,
>>>?by default).
>>>If you want to re-sample with such fine resolution,
you'll have to do it in host-side software, or do an
implementation of a fractional resampler in the FPGA.
>>>?
>>>?
>>>On 2016-04-11 08:04, Vladimir via USRP-users wrote: Hello,
>>>>
>>>>Is it possible by any means to get the sampling rate
fine tuned in X300 (eg 1 Hz resolution at 20 Msps
point)? Is there any input point where we can provide
some reference freq or directly Fs from an external
source? Or, may be some custom FPGA version
implementing arbitrary resampling or reprogramming dsp
to the exact freq?
>>>>
>>>>If there is no ready solution yet, what would be the
best (easiest) way to implement it by our own means?
>>>>
>>>>Vladimir
>>>>
>>>>
>>>>
>>>>_______________________________________________
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 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/20160412/8427c042/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 12 Apr 2016 10:29:59 -0400
From: [email protected]
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] building an E310 RFNoC FPGA image with HLS
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"
(Resending this since I forgot to click "reply to all")
Hi Jonathon,
So I've been following the addsub block example, and I was wondering
how to create a noc_block verilog file. Looking at the other noc_block
files only gives me a vague idea. Also I was wondering if you had some
documentation that I could read about what the noc_block verilog file
should contain.
Thanks,
An Qi
Quoting Jonathon Pendlum <[email protected]>:
> Hi An Qi,
>
> To build an image using HLS, you need to include a block that uses HLS and
> then run 'make E310_RFNOC_HLS'. To try it out, we have an example block
> that can use HLS, noc_block_addsub (usrp3/lib/rfnoc/noc_block_addsub.v). To
> build an image with that block in it for the E310, you would would add
> noc_block_addsub (with parameter USE_HLS set to 1) to
> rfnoc_ce_auto_inst_e310.v and then run 'make E310_RFNOC_HLS'. If you want
> to use HLS in your own blocks, you can add your C/C++ code in the directory
> /usrp3/lib/hls using addsub_hls as an example.
>
>
>
> Jonathon
>
> On Fri, Apr 8, 2016 at 12:45 PM, An Qi Zhang via USRP-users <
> [email protected]> wrote:
>
>> Hello,
>>
>> I was building the RFNoC FPGA image for the E310 and noticed there was an
>> option to build the FPGA image using Vivado HLS. I was wondering if you had
>> a complete set of instructions for building a custom FPGA image using the
>> E310_RFNOC_HLS option.
>>
>> Thanks,
>> An Qi
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
------------------------------
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 12
******************************************
