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. NoC-Script List of Functions (Muhammad, Siraj)
2. Re: By-Pass DDC Chain in B210 for Reading Raw Data (Marcus M?ller)
3. Re: By-Pass DDC Chain in B210 for Reading Raw Data (Ian Buckley)
4. Re: By-Pass DDC Chain in B210 for Reading Raw Data
([email protected])
5. Re: By-Pass DDC Chain in B210 for Reading Raw Data (Ian Buckley)
6. Re: By-Pass DDC Chain in B210 for Reading Raw Data
([email protected])
7. Re: problems about using rfnoc on e310 (Nate Temple)
8. Re: NoC-Script List of Functions (Nicolas Cuervo)
9. Lower power in latter part of transmision (Bakshi, Arjun)
10. Re: Lower power in latter part of transmision (Marcus M?ller)
11. E300 GPSD Enable issue in rfnoc-devel (Prager, Samuel M (334E))
12. Re: Adding 10 MHz permanently to B210? (Ralph A. Schmid, dk5ras)
13. USRP B210 does not lock to external reference clock
(George Vardakis)
14. Re: By-Pass DDC Chain in B210 for Reading Raw Data (altu? kaya)
15. Re: By-Pass DDC Chain in B210 for Reading Raw Data (Marcus M?ller)
16. Re: By-Pass DDC Chain in B210 for Reading Raw Data (altu? kaya)
17. Re: NoC-Script List of Functions (Muhammad, Siraj)
18. RFNoC Log Power Block (Muhammad, Siraj)
19. USB 3.0 B200, not recognised with VM running ArchLinux
(Jacqueline.Walker)
20. Re: RFNoC Log Power Block (Sylvain Munaut)
----------------------------------------------------------------------
Message: 1
Date: Thu, 29 Jun 2017 17:27:29 +0000
From: "Muhammad, Siraj" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] NoC-Script List of Functions
Message-ID:
<dm2pr03mb335ed1a14135be9d10b3074cd...@dm2pr03mb335.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hello All,
Can you please provide us with a list of functions that can be used in the XML
files bindings? E.g. GE(), LE(), ADD()...
I couldn't find that in the documentation!
I tried to use Cheetah to evaluate an expression, namely: #echo ... # but the
parser failed.
Thanks,
Siraj
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170629/a537ee52/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 29 Jun 2017 19:58:06 +0200
From: Marcus M?ller <[email protected]>
To: altu? kaya <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] By-Pass DDC Chain in B210 for Reading Raw
Data
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Altug!
> In the DDC chain, there are several modules that are responsible from
> adding/clipping bits?
Yes, but they don't change the info in the samples by adding bits, or
clipping off the last bits after a bit-widening operation.
> During the operation of the device a non-determined frequency offset
> in between the two inputs deteriorates the reception quality of
> signals and complicates the synchronization process.
Well, the raw data won't change that fact; receivers /never/ are
synchronized, and clock and frequency recovery is a must-have for any
sufficiently fast receiver system, as physically, no two oscillators in
this universe are identical.
Best regards,
Marcus
On 06/29/2017 12:17 PM, altu? kaya wrote:
> Dear Marcus,
>
> Thank you for your comment. I respect your answer, but I would like to
> ask how can be the output is an unprocessed data? In the DDC chain,
> there are several modules that are responsible from adding/clipping bits?
>
> The problem X is as the following. During the operation of the device
> a non-determined frequency offset in between the two inputs
> deteriorates the reception quality of signals and complicates the
> synchronization process.
>
> I am looking forward to your reply,
> Altug
>
> On Thu, Jun 29, 2017 at 11:32 AM, Marcus M?ller via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi Altug,
>
> how much more unprocessed than simply padded with zeros to 16 bit
> in case you choose master clock rate == sampling rate do you need?
> Generally, if our DSP is bug-free, Nyquist says what you get after
> all the DDC is mathematically equivalent to the unprocessed
> signal, and thus, especially, contains 100% of the original
> information; so, typically, you won't win anything by *not* using
> the DSP chain for any given bandwidth==sample rate.
>
> I feel this is kind of an XY problem[1], where you ask for a
> solution to a bit of a weird problem in expectation it'll solve
> another, more complex problem, which you forget to mention. But:
> Maybe we have a solution to that original problem, if you could
> elaborate on what you're trying to achieve with the raw data?
>
> Best regards,
>
> Marcus
>
> [1] http://xyproblem.info
>
>
> On 29.06.2017 11:25, altu? kaya via USRP-users wrote:
>> Hello everyone,
>>
>> I would like to read the raw (unprocessed) data, namely I and Q,
>> of B210. I think if I by-pass the DDC chain module (located in
>> Radio Legacy Module), then I should read the raw data. However,
>> the input of the DDC chain is 11-bit (interleaved I and Q data)
>> and the output is 32-bit. This prevents me to short circuit the
>> input and the output.
>>
>> How can I get the unprocessed data? Should I leave DDC chain and
>> search for other solutions?
>>
>> I am looking forward to your reply,
>> Altug
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> <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
> <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/20170629/7653df92/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 29 Jun 2017 11:21:38 -0700
From: Ian Buckley <[email protected]>
To: altu? kaya <[email protected]>
Cc: Marcus M?ller <[email protected]>,
[email protected]
Subject: Re: [USRP-users] By-Pass DDC Chain in B210 for Reading Raw
Data
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Altug
Before RX data is feed to the DDC, the 12 signed bits of I & Q are left
justified and a total of 12 zero bits added as LSB?s.
Since we by convention treat radio data as fractional fixed binary point data,
with a single sign bit, a binary point then a variable number of fractional
data bits, we are not scaling the data but providing additional dynamic range
that downstream DSP can take advantage of. (1.11 -> 1.23)
If, as Marcus suggests, you configure your setup so that
sample_rate=master_clock_rate, then all filters in the DDC will be bypassed.
That leaves the CORDIC and the gain compensation multiplier in the signal chain.
Assuming you configure the CORDIC with no rotation (0 Hz) then the signal will
still be subject to approximately 0.8 gain due to the CORDIC algorithm and the
implementation. No data is lost due to this this gain reduction since those
additional LSB?s exist.
After the bypassed filters, the gain compensation multiplier will scale the
data by approx 1/0.8, scaling the data back to it?s original magnitude. Excess
LSB?s are truncated at this point so that 16 bit fractional data can be
returned to the host, but there is no useful data in them in this bypass
configuration. The host will map that fractional binary representation to a
float data type and return those values to your application.
The clipping logic will never activate in this configuration, it can only
become active in configurations where the CORDIC is configured to add rotation
*and* the input data to the FPGA has dynamics where the polar magnitude is
greater than 1.0 (In other words we deal gracefully with the upstream radio
being poorly configured with excess gain).
TL;DR The DDC should be transparent to data in this configuration. It certainly
can?t introduce any type of frequency offset with the CORDIC configured as 0Hz.
-Ian
> On Jun 29, 2017, at 3:17 AM, altu? kaya via USRP-users
> <[email protected]> wrote:
>
> Dear Marcus,
>
> Thank you for your comment. I respect your answer, but I would like to ask
> how can be the output is an unprocessed data? In the DDC chain, there are
> several modules that are responsible from adding/clipping bits?
>
> The problem X is as the following. During the operation of the device a
> non-determined frequency offset in between the two inputs deteriorates the
> reception quality of signals and complicates the synchronization process.
>
> I am looking forward to your reply,
> Altug
>
> On Thu, Jun 29, 2017 at 11:32 AM, Marcus M?ller via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
> Hi Altug,
>
> how much more unprocessed than simply padded with zeros to 16 bit in case you
> choose master clock rate == sampling rate do you need? Generally, if our DSP
> is bug-free, Nyquist says what you get after all the DDC is mathematically
> equivalent to the unprocessed signal, and thus, especially, contains 100% of
> the original information; so, typically, you won't win anything by *not*
> using the DSP chain for any given bandwidth==sample rate.
> I feel this is kind of an XY problem[1], where you ask for a solution to a
> bit of a weird problem in expectation it'll solve another, more complex
> problem, which you forget to mention. But: Maybe we have a solution to that
> original problem, if you could elaborate on what you're trying to achieve
> with the raw data?
>
> Best regards,
>
> Marcus
> [1] http://xyproblem.info <http://xyproblem.info/>
>
> On 29.06.2017 11:25, altu? kaya via USRP-users wrote:
>> Hello everyone,
>>
>> I would like to read the raw (unprocessed) data, namely I and Q, of B210. I
>> think if I by-pass the DDC chain module (located in Radio Legacy Module),
>> then I should read the raw data. However, the input of the DDC chain is
>> 11-bit (interleaved I and Q data) and the output is 32-bit. This prevents me
>> to short circuit the input and the output.
>>
>> How can I get the unprocessed data? Should I leave DDC chain and search for
>> other solutions?
>>
>> I am looking forward to your reply,
>> Altug
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> <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
> <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/20170629/3cb4eb4b/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 29 Jun 2017 14:47:54 -0400
From: [email protected]
To: Ian Buckley <[email protected]>
Cc: altu? kaya <[email protected]>, [email protected]
Subject: Re: [USRP-users] By-Pass DDC Chain in B210 for Reading Raw
Data
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I think the main point is that for a randomly-chosen TX and a
randomly-chosen RX that aren't sharing a clock, there will be some
unknown (but usually small in terms of PPM) frequency offset between the
two devices. This is as inevitable as the Sun coming up in the morning.
Communications systems that require close frequency offsets are usually
designed with a compensation loop for this. Generally, narrowband
systems, or schemes with multiple narrowband "carriers" (like OFDM) have
this requirement, but they compensate at the receiver.
Now, in the original post, it was suggested that there was a residual
frequency offset *betwee* the RX channels on the B210. This generally
isn't possible, except for bugs, since the RF downconversion hardware
(the LO in particular) is shared between the two channels. There cannot
be any residual frequency offset between two RX channels in a B210
(assuming the two channels are being fed the same signal).
> TL;DR The DDC should be transparent to data in this configuration. It
> certainly can't introduce any type of frequency offset with the CORDIC
> configured as 0Hz.
>
> -Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170629/6edfa70a/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 29 Jun 2017 11:52:49 -0700
From: Ian Buckley <[email protected]>
To: [email protected]
Cc: altu? kaya <[email protected]>, [email protected]
Subject: Re: [USRP-users] By-Pass DDC Chain in B210 for Reading Raw
Data
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
?.unless the CORDIC?s are programmed differently, which is a legitimate
configuration.
> Now, in the original post, it was suggested that there was a residual
> frequency offset *betwee* the RX channels on the B210. This generally isn't
> possible, except for bugs, since the RF downconversion hardware (the LO in
> particular) is shared between the two channels. There cannot be any residual
> frequency offset between two RX channels in a B210 (assuming the two channels
> are being fed the same signal).
>
>
>> TL;DR The DDC should be transparent to data in this configuration. It
>> certainly can't introduce any type of frequency offset with the CORDIC
>> configured as 0Hz.
>>
>>
>> -Ian
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170629/95db93ab/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 29 Jun 2017 14:58:16 -0400
From: [email protected]
To: Ian Buckley <[email protected]>
Cc: altu? kaya <[email protected]>, [email protected]
Subject: Re: [USRP-users] By-Pass DDC Chain in B210 for Reading Raw
Data
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I don't think that's the case here. If it is, then, yes, there could be
frequency offset.
On 2017-06-29 14:52, Ian Buckley wrote:
> ....unless the CORDIC's are programmed differently, which is a legitimate
> configuration.
>
> Now, in the original post, it was suggested that there was a residual
> frequency offset *betwee* the RX channels on the B210. This generally isn't
> possible, except for bugs, since the RF downconversion hardware (the LO in
> particular) is shared between the two channels. There cannot be any residual
> frequency offset between two RX channels in a B210 (assuming the two channels
> are being fed the same signal).
>
> TL;DR The DDC should be transparent to data in this configuration. It
> certainly can't introduce any type of frequency offset with the CORDIC
> configured as 0Hz.
>
> -Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170629/274571d2/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 29 Jun 2017 14:44:55 -0700
From: Nate Temple <[email protected]>
To: Hu Chaoran <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] problems about using rfnoc on e310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Hu,
The process is the same, and within that App Note, it will give an example of
building a E310 image.
http://kb.ettus.com/Getting_Started_with_RFNoC_Development#Build_custom_image_with_pre-built_RFNoC_blocks
$ ./uhd_image_builder.py window fft -d e310 -t E310_RFNOC_sg3 -m 5
--fill-with-fifos
Regards,
Nate Temple
> On Jun 29, 2017, at 12:05 AM, Hu Chaoran via USRP-users
> <[email protected]> wrote:
>
> Hello,
> I want to use the rfnoc block DUC and Siggen on e310, but when I run them I
> got the error : 'RuntimeError: Cannot find a block for ID: DUC'.
> Then I found that on my device there are only these blocks as fellows.
> | | _____________________________________________________
> | | /
> | | | RFNoC blocks on this device:
> | | |
> | | | * Radio_0
> | | | * FIFO_0
> | | | * Window_0
> | | | * FFT_0
> | | | * fosphor_0
> | | | * FIFO_1
> | | | * FIR_0
>
> on the document ' Getting started with RFNoC Development '
> (http://kb.ettus.com/Getting_Started_with_RFNoC_Development) I find something
> about image building, but I think that method is only for PC, because I
> didn't found files such as 'uhd_image_builder.py' on my e310 device. Then
> how can I update the image on my e310 device to support the DDC, Duc, siggen
> or other blocks?
>
> Thanks a lot.
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 8
Date: Fri, 30 Jun 2017 00:03:36 +0200
From: Nicolas Cuervo <[email protected]>
To: "Muhammad, Siraj" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] NoC-Script List of Functions
Message-ID:
<CAOuPCvihFFXriq-E6ydjeYqTt8d1DPvhBd3GdhJ-jZ=3_0a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Siraj,
there is a python script that generates a file with the basic nocscript
syntax that you can use for the XML called "gen_basic_funcs.py" [1]. Its
usage is very straightforward: you go to the uhd repository, while being in
the "rfnoc-devel" branch, and within go to the nocscript path in the library
$ cd uhd/host/lib/rfnoc/nocscript/
and then call the script followed by the filename that you want for the
file that contains the basic syntax. For example:
$ ./gen_basic_funcs.py outfile.txt
Where outfile will contain the basic functions that you can use with their
syntax.
I hope this helps.
Regards,
- Nicolas
[1]
https://github.com/EttusResearch/uhd/blob/rfnoc-devel/host/lib/rfnoc/nocscript/gen_basic_funcs.py
On Thu, Jun 29, 2017 at 7:27 PM, Muhammad, Siraj via USRP-users <
[email protected]> wrote:
> Hello All,
>
>
>
> Can you please provide us with a list of functions that can be used in the
> XML files bindings? E.g. GE(), LE(), ADD()?
>
> I couldn?t find that in the documentation!
>
> I tried to use Cheetah to evaluate an expression, namely: #echo ? # but
> the parser failed.
>
>
>
> Thanks,
>
> Siraj
>
>
>
> _______________________________________________
> 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/20170630/fd9f8a42/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 29 Jun 2017 22:21:31 +0000
From: "Bakshi, Arjun" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Lower power in latter part of transmision
Message-ID:
<mwhpr01mb2286f440f20929450bb6f39fbc...@mwhpr01mb2286.prod.exchangelabs.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello everyone,
I have a simple setup where I periodically transmit and receive a preamble.
I've observed in recent experiments that the latter part of my preamble is
received with much lower power than the first few samples. I've attached a plot
of a received preamble. Any ideas on why this is happening?
Setup: 2x USRP N210, WBX boards, vert 400 antennae, sampling at 200ksps,
CF@310MHz
Thank you,
Arjun
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170629/f57d2817/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: act_rx.png
Type: image/png
Size: 34756 bytes
Desc: act_rx.png
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170629/f57d2817/attachment-0001.png>
------------------------------
Message: 10
Date: Fri, 30 Jun 2017 00:28:19 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Lower power in latter part of transmision
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Arjun,
if this was a channel of significantly more bandwidth, I'd immediately
guess that might be the effect of a multipath channel (which exhibits a
FIR-like impulse response). However, at 200 kHz bandwidth, that would
require enormous distances ($d=c_0\cdot t = c_0\cdot \frac1b =
\frac{c_0}{b} = \frac{\SI{3e8}{\meter\per\second}}{\SI{2e5}{\hertz}} =
\frac32\si{\kilo\meter}$) so, I guess that's not the case. Considering
the amplitudes are pretty small: What happens if you either increase the
TX or the RX gain?
Best regards,
Marcus
On 30.06.2017 00:21, Bakshi, Arjun via USRP-users wrote:
>
> Hello everyone,
>
>
> I have a simple setup where I periodically transmit and receive a
> preamble. I've observed in recent experiments that the latter part of
> my preamble is received with much lower power than the first few
> samples. I've attached a plot of a received preamble. Any ideas on why
> this is happening?
>
>
> Setup: 2x USRP N210, WBX boards, vert 400 antennae, sampling at
> 200ksps, CF@310MHz
>
>
> Thank you,
>
>
> Arjun
>
>
>
> _______________________________________________
> 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/20170630/b546c4e8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-1.png
Type: image/png
Size: 2364 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170630/b546c4e8/attachment-0001.png>
------------------------------
Message: 11
Date: Thu, 29 Jun 2017 22:45:49 +0000
From: "Prager, Samuel M (334E)" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] E300 GPSD Enable issue in rfnoc-devel
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello,
Setting the time source to 'gpsdo' on our E312 running rfnoc fails. I believe
this is due to the uhd/host/usrp/e300/CMakeLists.txt file missing the following
line:
IF(ENABLE_GPSD)
SET_SOURCE_FILES_PROPERTIES(
${CMAKE_CURRENT_SOURCE_DIR}/e300_impl.cpp
${CMAKE_CURRENT_SOURCE_DIR}/e300_impl.hpp
${CMAKE_CURRENT_SOURCE_DIR}/e3xx_radio_ctrl_impl.cpp
PROPERTIES COMPILE_DEFINITIONS "E300_GPSD=1"
)
ENDIF(ENABLE_GPSD)
Regards,
Sam
--
Samuel Prager
[email protected]<mailto:[email protected]>
[email protected]<mailto:[email protected]>
(916) 671-0976
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170629/451dfae2/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 30 Jun 2017 07:48:30 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'Derek Kozel'" <[email protected]>
Cc: <[email protected]>
Subject: Re: [USRP-users] Adding 10 MHz permanently to B210?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Derek,
Modifying something would not matter, I am skilled enough for this, and the
thing is out of warranty anyway :)
Remains one basic question, will the PLL lock as soon as it sees 10 MHz on its
REF input, or does it need to be enabled by the command that chooses external
clock or GPSDO?
Thank you, and with best regards
Ralph.
From: Derek Kozel [mailto:[email protected]]
Sent: Thursday, June 29, 2017 5:06 PM
To: Ralph A. Schmid, dk5ras
Cc: [email protected]
Subject: Re: [USRP-users] Adding 10 MHz permanently to B210?
Hallo Ralph,
The default source is internal which does not use the GPSDO or external source.
This is the 40 MHz TCXO. I'm not certain which state the switch is initialized
in but it can probabt
If you want to permanently supply a 10 MHz external reference it should be
connected to the external connector. It is required to select the external
reference every time a session is made with the B210, there is no way to set
the external as the default without modifying UHD.
Viele Gr??e,
Derek
On Thu, Jun 29, 2017 at 7:20 AM, Ralph A. Schmid, dk5ras via USRP-users
<[email protected] <mailto:[email protected]> > wrote:
Hi,
As far as I understand I have to enable external 10 MHz clock source before
the PLL locks onto it and syncs the 40 MHz internal master clock, is this
right? When I look into the circuit diagram I see a switch, choosing between
external clock and GPSDO. What input is selected by default, without
specifying anything? GPSDO?
And is the PLL active all the time, meens, normally running free, and when
it sees a 10 MHz reference it automagically locks?
The idea is, connecting a 0.something ppm TCXO to one of those inputs, to
achieve something better than 10 KHz error at 5.5 GHz without having to turn
this on all the time :)
Ralph, dk5ras.
--
Ralph A. Schmid
Mondstr. 10
90762 F?rth
+49-171-3631223
<mailto:[email protected]> [email protected]
<http://www.bclog.de/> http://www.bclog.de/
_______________________________________________
USRP-users mailing list
<mailto:[email protected]> [email protected]
<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/20170630/4d8fcb43/attachment-0001.html>
------------------------------
Message: 13
Date: Fri, 30 Jun 2017 11:44:51 +0300
From: George Vardakis <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP B210 does not lock to external reference
clock
Message-ID:
<caghzxvnypyyfmvczothugc193crnl0x8fq2ufqvdgup9x4z...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
It seems i have a problem with one of my two USRP B210 devices. I connect
them both to my ClockTamer, external reference clock, and only one of them
locks to the 10 MHz reference. The other one, always the same device, does
not lock. Should i start worrying this is a hardware issue, or is there
anything i can do to try to fix it?
Thank you in advance
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170630/bcfc65d8/attachment-0001.html>
------------------------------
Message: 14
Date: Fri, 30 Jun 2017 12:21:29 +0200
From: altu? kaya <[email protected]>
To: [email protected]
Cc: Ian Buckley <[email protected]>, [email protected]
Subject: Re: [USRP-users] By-Pass DDC Chain in B210 for Reading Raw
Data
Message-ID:
<cahq6uv_73sfldgyuj_0jzkuz7weoqdjmscsjex0r+7pdkh6...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello everyone,
First of all, thank you so much guys. Appreciated.
Ian Buckley, I think I can add 0 degree rotation to the system by modifying
the CORDIC Module by writing "#<insert the total amount of delay that
default CORDIC has> xo <= xi". Do you suggest any other way to do that?
I am looking forward to your reply,
Altug
On Thu, Jun 29, 2017 at 8:58 PM, <[email protected]> wrote:
>
>
> I don't think that's the case here. If it is, then, yes, there could be
> frequency offset.
>
> On 2017-06-29 14:52, Ian Buckley wrote:
>
> ....unless the CORDIC's are programmed differently, which is a legitimate
> configuration.
>
> Now, in the original post, it was suggested that there was a residual
> frequency offset *betwee* the RX channels on the B210. This generally
> isn't possible, except for bugs, since the RF downconversion hardware (the
> LO in particular) is shared between the two channels. There cannot be any
> residual frequency offset between two RX channels in a B210 (assuming the
> two channels are being fed the same signal).
>
>
> TL;DR The DDC should be transparent to data in this configuration. It
> certainly can't introduce any type of frequency offset with the CORDIC
> configured as 0Hz.
>
>
> -Ian
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170630/ddf5de99/attachment-0001.html>
------------------------------
Message: 15
Date: Fri, 30 Jun 2017 12:30:09 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] By-Pass DDC Chain in B210 for Reading Raw
Data
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Don't do that at all? The cordic is part of the digital receive chain.
Simply set the digital part of a tune request to zero. The CORDIC
doesn't have default delay.
Best regards,
Marcus
On 06/30/2017 12:21 PM, altu? kaya via USRP-users wrote:
> Hello everyone,
>
> First of all, thank you so much guys. Appreciated.
>
> Ian Buckley, I think I can add 0 degree rotation to the system by
> modifying the CORDIC Module by writing "#<insert the total amount of
> delay that default CORDIC has> xo <= xi". Do you suggest any other way
> to do that?
>
> I am looking forward to your reply,
> Altug
>
> On Thu, Jun 29, 2017 at 8:58 PM, <[email protected]
> <mailto:[email protected]>> wrote:
>
>
>
> I don't think that's the case here. If it is, then, yes, there
> could be frequency offset.
>
> On 2017-06-29 14:52, Ian Buckley wrote:
>
>> ....unless the CORDIC's are programmed differently, which is a
>> legitimate configuration.
>>>
>>> Now, in the original post, it was suggested that there was a
>>> residual frequency offset *betwee* the RX channels on the B210.
>>> This generally isn't possible, except for bugs, since the RF
>>> downconversion hardware (the LO in particular) is shared between
>>> the two channels. There cannot be any residual frequency offset
>>> between two RX channels in a B210 (assuming the two channels are
>>> being fed the same signal).
>>>
>>>
>>>
>>> TL;DR The DDC should be transparent to data in this
>>> configuration. It certainly can't introduce any type of
>>> frequency offset with the CORDIC configured as 0Hz.
>>>
>>>
>>> -Ian
>>>
>>>
>>>
>
>
>
> _______________________________________________
> 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/20170630/5dc802cd/attachment-0001.html>
------------------------------
Message: 16
Date: Fri, 30 Jun 2017 16:20:59 +0200
From: altu? kaya <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] By-Pass DDC Chain in B210 for Reading Raw
Data
Message-ID:
<CAHq6UV9vBsmSxcXOmyBS6NK6qngSN1r1o=HOsWRQ-q8=h9f...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
How should I set the digital part of a tune request to zero? There are two
C++ files in UHD\include\uhd\types called tune_request one of which is a
library. There are three constants, namely:
UHD_TUNE_REQUEST_POLICY_NONE = 78, UHD_TUNE_REQUEST_POLICY_AUTO = 65,
UHD_TUNE_REQUEST_POLICY_MANUAL = 77
Are these related with the question that I have mentioned above this mail?
Sincerely,
Altug
On Fri, Jun 30, 2017 at 12:30 PM, Marcus M?ller via USRP-users <
[email protected]> wrote:
> Don't do that at all? The cordic is part of the digital receive chain.
> Simply set the digital part of a tune request to zero. The CORDIC doesn't
> have default delay.
>
> Best regards,
>
> Marcus
> On 06/30/2017 12:21 PM, altu? kaya via USRP-users wrote:
>
> Hello everyone,
>
> First of all, thank you so much guys. Appreciated.
>
> Ian Buckley, I think I can add 0 degree rotation to the system by
> modifying the CORDIC Module by writing "#<insert the total amount of delay
> that default CORDIC has> xo <= xi". Do you suggest any other way to do that?
>
> I am looking forward to your reply,
> Altug
>
> On Thu, Jun 29, 2017 at 8:58 PM, <[email protected]> wrote:
>
>>
>>
>> I don't think that's the case here. If it is, then, yes, there could be
>> frequency offset.
>>
>> On 2017-06-29 14:52, Ian Buckley wrote:
>>
>> ....unless the CORDIC's are programmed differently, which is a legitimate
>> configuration.
>>
>> Now, in the original post, it was suggested that there was a residual
>> frequency offset *betwee* the RX channels on the B210. This generally
>> isn't possible, except for bugs, since the RF downconversion hardware (the
>> LO in particular) is shared between the two channels. There cannot be any
>> residual frequency offset between two RX channels in a B210 (assuming the
>> two channels are being fed the same signal).
>>
>>
>> TL;DR The DDC should be transparent to data in this configuration. It
>> certainly can't introduce any type of frequency offset with the CORDIC
>> configured as 0Hz.
>>
>>
>> -Ian
>>
>>
>>
>>
>
>
> _______________________________________________
> 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/20170630/3ce8cecc/attachment-0001.html>
------------------------------
Message: 17
Date: Fri, 30 Jun 2017 14:58:09 +0000
From: "Muhammad, Siraj" <[email protected]>
To: Nicolas Cuervo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] NoC-Script List of Functions
Message-ID:
<dm2pr03mb3353cfcfbe1146169bc666dcd...@dm2pr03mb335.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Thanks Nicolas! That does help.
Siraj
From: Nicolas Cuervo [mailto:[email protected]]
Sent: Thursday, June 29, 2017 5:04 PM
To: Muhammad, Siraj <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] NoC-Script List of Functions
Hello Siraj,
there is a python script that generates a file with the basic nocscript syntax
that you can use for the XML called "gen_basic_funcs.py" [1]. Its usage is very
straightforward: you go to the uhd repository, while being in the "rfnoc-devel"
branch, and within go to the nocscript path in the library
$ cd uhd/host/lib/rfnoc/nocscript/
and then call the script followed by the filename that you want for the file
that contains the basic syntax. For example:
$ ./gen_basic_funcs.py outfile.txt
Where outfile will contain the basic functions that you can use with their
syntax.
I hope this helps.
Regards,
- Nicolas
[1]
https://github.com/EttusResearch/uhd/blob/rfnoc-devel/host/lib/rfnoc/nocscript/gen_basic_funcs.py<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_EttusResearch_uhd_blob_rfnoc-2Ddevel_host_lib_rfnoc_nocscript_gen-5Fbasic-5Ffuncs.py&d=DwMFaQ&c=qKdtBuuu6dQK9MsRUVJ2DPXW6oayO8fu4TfEHS8sGNk&r=ToS7EjuDGfB6A6qGHWQt9r8_NP34wBV_sAv_IzxySeI&m=gVHTO3QIHxid5A1e6tlxd3ebRsZYap2EedgJivGqOyI&s=1k7r8BhHs8YbuS8JvdJyq-QyCpqnwSlIr2ozjlfsPVU&e=>
On Thu, Jun 29, 2017 at 7:27 PM, Muhammad, Siraj via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hello All,
Can you please provide us with a list of functions that can be used in the XML
files bindings? E.g. GE(), LE(), ADD()?
I couldn?t find that in the documentation!
I tried to use Cheetah to evaluate an expression, namely: #echo ? # but the
parser failed.
Thanks,
Siraj
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwMFaQ&c=qKdtBuuu6dQK9MsRUVJ2DPXW6oayO8fu4TfEHS8sGNk&r=ToS7EjuDGfB6A6qGHWQt9r8_NP34wBV_sAv_IzxySeI&m=gVHTO3QIHxid5A1e6tlxd3ebRsZYap2EedgJivGqOyI&s=Bw0Ev_lafkpinCpymEIkgxmj4g7LD4N1MquzCJ0hc5w&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170630/f47963d1/attachment-0001.html>
------------------------------
Message: 18
Date: Fri, 30 Jun 2017 15:06:53 +0000
From: "Muhammad, Siraj" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] RFNoC Log Power Block
Message-ID:
<dm2pr03mb335fe5934a1d927147c3e87cd...@dm2pr03mb335.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hello All,
I am examining the RFNoC Loq Power block which is based on f15_logpwr.v. In
that Verilog source code, the header says it computes
2048 * log2(i^2+q^2) given a complex input. So I tested this by feeding the
block a constant complex number: 1+1j. The expected output is 2048. However, I
am getting 0.97 instead. Is there something I am missing here? Should I treat
the output in a certain way to get the expected? Check my flowgraph below.
Thanks,
Siraj
[cid:[email protected]]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170630/a4d14758/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 22952 bytes
Desc: image003.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170630/a4d14758/attachment-0001.jpg>
------------------------------
Message: 19
Date: Fri, 30 Jun 2017 15:16:53 +0000
From: Jacqueline.Walker <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] USB 3.0 B200, not recognised with VM running
ArchLinux
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello,
I am using a newly acquired B200 via a VM running ArchLinux. The VM runs in
either VMware Workstation Pro 12 or VMware Workstation Player 12. Archlinux
kernel version 4.11.3-1. Uhd version 003.010.001.
It's all working ok except that I am having to run it off USB 2.0 and I would
like to run it off USB 3.0. The knowledge base promised an application note for
particular issues arising when using VMs but it doesn't seem to have been
written. The VM is capable of seeing and mounting a storage device on the USB
3.0 bus but it cannot open or talk to the B200 through it. I will keep looking
for fixes to try via the Archlinux community but does anyone have any
suggestions?
It works fine through USB 2.0, but I do have a question about this too. It
seems to be powering itself ok off the USB 2.0 - it runs and the blue led is
lit: is this 'enough' power or should I be using the external power supply (I
have one)? Which works too, as I have tried it, but it doesn't seem to be
necessary.
Thanks for any suggestions,
Jacqueline
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170630/c688558f/attachment-0001.html>
------------------------------
Message: 20
Date: Fri, 30 Jun 2017 17:31:46 +0200
From: Sylvain Munaut <[email protected]>
To: "Muhammad, Siraj" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC Log Power Block
Message-ID:
<CAHL+j0--C8_M0y6w_vHWkAYGykt-1-2Z=r3n9lvt0whtmx7...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi,
> I am examining the RFNoC Loq Power block which is based on f15_logpwr.v. In
> that Verilog source code, the header says it computes
>
> 2048 * log2(i^2+q^2) given a complex input.
That statement is only valid for the 16 bits fixed points values fed
to the verilog code.
> So I tested this by feeding the block a constant complex number: 1+1j.
Well there's your first issue, you can't actually represent '1' really.
Because the FPGA uses 16 bits fixed point, it will take floating point
number and multiply by 32768 then map that to 16 bits. Problem is that
16 bits signed number go from -32768 to 32767 ... to you can't really
represent '1' but only ~0.9997 as the max value.
Then the return value when fed back to GR is converted back from 16
bits fixed point to float by dividing by 32768.
So in your case the block computes 2048 * log2( 32767 * 32767 + 32767
* 32767 ) ~= 63488 (because the output is 16 bits unsigned).
Then if you look when this is mapped back to rfnoc, the LSB is dropped :
assign s_axis_data_tdata = { 1'b0, s_axis_data_tdata16[15:1], 16'b0 };
So 31744 is what's sent back to the host. And when mapped to float
31744 / 32768 = 0.96875
Cheers,
Sylvain
------------------------------
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 82, Issue 29
******************************************
