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. fpga build win7 (Faller, Lisa-Marie)
2. [UHD] Replacing Cheetah Templates with Mako (Martin Braun)
3. Fwd: B210 verilog source code problems (Vitaliy Lazarev)
4. Re: fpga build win7 (Martin Braun)
5. Re: fpga build win7 (Neel Pandeya)
6. Re: [Discuss-gnuradio] [UHD] Replacing Cheetah Templates with
Mako (Martin Braun)
7. fpga build win7 (Neel Pandeya)
8. Amplifiers for USRP Transmission (evan)
9. Amplifiers for USRP Transmission (evan)
10. Re: Newbie Issue (Tom Tsou)
11. Re: XISE project USRP3 B200 (Ian Buckley)
12. fpga image types (Aaron Henderson)
13. Re: [UHD] Replacing Cheetah Templates with Mako (Perelman, Nathan)
14. Re: B210 verilog source code problems (Ian Buckley)
15. Re: [UHD] Replacing Cheetah Templates with Mako (Martin Braun)
16. Re: Newbie Issue (gsmandvoip)
17. PhD position in GNSS Reflectometry (GNSS-R) (Thomas Hobiger)
----------------------------------------------------------------------
Message: 1
Date: Tue, 7 Jul 2015 04:32:36 +0000
From: "Faller, Lisa-Marie" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] fpga build win7
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Dear all,
I would like to run an x310 under Windows7/8 64bit with customized FPGA code.
Since I am all new to that topic, I started by installing MinGW and UHD as well
as Vivado 15.1.
I downloaded all fpga images (master, maint, rfnoc-devel) from ettus_research
github.
Until now I could not manage to compile any of them.
Below is the output I get with the make command.
Can you maybe help me further? What is the difference between the 3
fpga-image-branches?
Is there some kind of documentation on how all the different blocks of
Verilog/vhdl code link together?
Or on how to write customized code?
Thank you and best regards,
Lisa
[cid:[email protected]]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150707/49887bf4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 316376 bytes
Desc: image001.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150707/49887bf4/attachment-0001.jpg>
------------------------------
Message: 2
Date: Tue, 07 Jul 2015 10:27:32 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>,
"[email protected]" <[email protected]>
Subject: [USRP-users] [UHD] Replacing Cheetah Templates with Mako
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Dear UHD users,
We will be replacing Cheetah as a template engine with the less-dead
Mako template engine. I have pushed a branch for feedback etc. to our
github page:
https://github.com/EttusResearch/uhd/tree/uhd/python3_mako_831
This only affects people building UHD from source. People using binaries
will not care or even need to know about this.
*Why are we doing this?* The issue with Cheetah is, the project seems
inactive and has not been updated in a long while. Also, it is not
Python 3 compatible, and some of the distributions we support are
starting to switch over to Python 3 as the default. We spent some time
researching other template engines not only for quality and features,
but also for stability of API, user base, community etc. Mako is used
widely on the webs, and has a mostly backward-compatible API for several
years now, as well as an active community.
*What does UHD need a template engine for?* We use it to auto-generate
code in some places. It saves us from typing out long, boring and
repetitive sources files, which a computer can do much better than a
human without typos. We do *not* use it during runtime or anytime after
installation.
*When will this be changed?* Soon, and will be permanent for the next
major release (3.9.0).
*Doesn't GNU Radio work fine with Cheetah?* GNU Radio is facing similar
issues (e.g. no Python 3 compatibility), but Cheetah is much more deeply
woven into GNU Radio and it's harder to replace, and such things can't
happen unless for major releases. It's certainly not a single commit as
for UHD.
I'll leave this public branch up for a bit, and will then merge this
into master -- but I'm happy for any feedback!
Thanks,
Martin
------------------------------
Message: 3
Date: Tue, 7 Jul 2015 20:32:15 +0300
From: Vitaliy Lazarev <[email protected]>
To: [email protected]
Subject: [USRP-users] Fwd: B210 verilog source code problems
Message-ID:
<CABnsJXoPoHcKsufGKMFCgaY=wfPAm1bYEVoQ1CC9CuPPRUt=1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all, again.
Several months ago I posted a message about some problems in
understanding verilog code and how it works. Still seeking for help.
---------- Forwarded message ----------
From: ??????? ??????? <[email protected]>
Date: 2015-04-13 15:54 GMT+03:00
Subject: B210 verilog source code problems
To: [email protected]
> Hi All,
>
> I'm working on the project by implementing a modulator (e.g.BPSK) in
> FPGA on board B210.
> And the more I digging the Verilog code, the more questions I have
> about how it actually works.
> Down below I will talk about only a TX chain, because there's no
> priority to implement an RX chain right now. Anyway, everything has
> its time and I hope for your help.
>
> 1) There's a module gpif2_slave_fifo32 in b200.v file, that gets a
> tx_tdata and ctrl_tdata lines forward to DSP chain. In this module I
> found that it works with a tristate buffer model and depending on what
> information module get (i.e. what's on GPIF_CTL11 and GPIF_CTL12,
> which are used for fifo address), it will take it to different
> fifo-modules. Then it splits to tx_tdata and ctrl_tdata. At this point
> I don't understand the logic of setting these pins (GPIF_CTL11 and
> 12). Is there any description of transactions into GPIF? Or maybe
> there's a documentation how to work with this interface?
>
> 2) There's a pin, named codec_data_clk_p. This is a Baseband PLL
> clock, I suppose, that goes from AD9361. I got the full path:
> DATA_CLK_P -> G11 -> K3 -> IO_L44P_GCLK21_M3A5_3 (codec_data_clk_p).
> AD datasheet says, that this clock is programmed from 700 MHz to 1400
> MHz. How should I know, what clock is going from AD right now, when I
> run my board with .bin and .hex files? Can I change or reconfigure it
> from somewhere?
>
> 3) While I was surfing the source code it was obvious, that tx data
> goes from tx0 and tx1 buses (inside b200_core.v). It goes up to
> tx_data1 and tx_data2 and then it goes to catcodec module and to DAC.
> But when I looked at it with the Chipscope, I didn't see nothing that
> proves my theory. Tx bus (inside radio_b200.v) consists from run_tx
> signal and two other buses - tx_idle and tx_fe_q or tx_fe_i (depends
> on I and Q components). In Chipscope run_tx signal was 0, so data goes
> only from tx_idle. But I didn't see at least something that was
> similar to data from tx_tdata (up in b200.v). Honestly, I didn't see
> nothing on these buses (it was zeroes, or some constant value that
> didn't change). Here's the question - how data goes from GPIF and
> tx_tdata bus down to radio_b200 and goes up to tx_data1 and tx_data2?
> Maybe I did something wrong with Chipscope, but on tx_tdata there's a
> data, that transmits from GNURadio. I just don't get the full path.
> Chipscope was running on radio_clk and bus_clk and it didn't change
> anything.
>
> 4) As I said before, while I was chipscoping, run_tx was set to 0. But
> there a lot of DSP modules inside radio_b200.v, that run from run_tx
> (e.g. Digital Up Converter, CIC filter, CORDIC-module and so on). It
> means that these modules are not working right now. But it ruins my
> understanding of digital up and down converter chains at all! If all
> these modules aren't used, why they are in the source code? For other
> board models? Or if I just didn't turn them on, how can I enable them?
>
> All of these things are prevent my attempts to implement something in
> verilog source code.
> I have a feeling, that I miss some fundamental things. I hope someone
> will help me with my questions, cause I'm stuck.
--
Best regards,
Vitaliy Lazarev.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150707/8e27a35f/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 07 Jul 2015 10:38:35 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] fpga build win7
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 06.07.2015 21:32, Faller, Lisa-Marie via USRP-users wrote:
> Below is the output I get with the make command.
>
> Can you maybe help me further? What is the difference between the 3
> fpga-image-branches?
Hi Lisa,
the branches match to the equivalent UHD branches. I.e. if you want to
run UHD master branch, you need the code from the FPGA master branch
etc. Note that maint branch uses ISE, whereas master + rfnoc-devel use
Vivado, so you won't be able to build maint with your setup anyway.
> Is there some kind of documentation on how all the different blocks
> of Verilog/vhdl code link together?
>
> Or on how to write customized code?
There's our FPGA manual: http://files.ettus.com/manual/md_fpga.html, but
not that is valid for *maint* branch only (we always publish the latest
release manual). In your local source directory, you will find manuals
for your current branch.
We *do* assume familiarity with the Vivado toolchain and FPGA
development in general. There's no high-level documentation of the
individual modules. I suggest you give us some idea what you're trying
to build, and we'll be able to point you into the right direction. Maybe
RFNoC is what you want.
I'm not sure anyone's ever tried to build the FPGA image with MinGW; and
we don't use 15.1, either (see the master branch manual). Maybe that's
part of the issue.
Regards,
Martin
------------------------------
Message: 5
Date: Tue, 7 Jul 2015 11:01:36 -0700
From: Neel Pandeya <[email protected]>
To: "Faller, Lisa-Marie" <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] fpga build win7
Message-ID:
<CACaXmv_=bca32ywnyh_vkd0dfsufry0mynppvxhghhpfdcu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I just wanted to add that we current do FPGA builds on Ubuntu 14.04, so if
you can also use that platform, then the Makefiles should run without any
problems. We only support Xilinx ISE at the moment, but there is
preliminary Vivado support in the maint branch. We currently support
version 2014.4, but I don't think your version 2015.1 will work, although
we plan to add support for 2015.1 or 2015.2 later this year. I think Xilinx
lets you access any recent version of Vivado on any platform, so you should
be able to install 2014.4 on Ubuntu 14.04 using your current Vivado license.
--Neel
On 7 July 2015 at 10:38, Martin Braun via USRP-users <
[email protected]> wrote:
> On 06.07.2015 21:32, Faller, Lisa-Marie via USRP-users wrote:
> > Below is the output I get with the make command.
> >
> > Can you maybe help me further? What is the difference between the 3
> > fpga-image-branches?
>
> Hi Lisa,
>
> the branches match to the equivalent UHD branches. I.e. if you want to
> run UHD master branch, you need the code from the FPGA master branch
> etc. Note that maint branch uses ISE, whereas master + rfnoc-devel use
> Vivado, so you won't be able to build maint with your setup anyway.
>
>
> > Is there some kind of documentation on how all the different blocks
> > of Verilog/vhdl code link together?
> >
> > Or on how to write customized code?
>
> There's our FPGA manual: http://files.ettus.com/manual/md_fpga.html, but
> not that is valid for *maint* branch only (we always publish the latest
> release manual). In your local source directory, you will find manuals
> for your current branch.
>
> We *do* assume familiarity with the Vivado toolchain and FPGA
> development in general. There's no high-level documentation of the
> individual modules. I suggest you give us some idea what you're trying
> to build, and we'll be able to point you into the right direction. Maybe
> RFNoC is what you want.
>
> I'm not sure anyone's ever tried to build the FPGA image with MinGW; and
> we don't use 15.1, either (see the master branch manual). Maybe that's
> part of the issue.
>
> Regards,
> Martin
>
> _______________________________________________
> 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/20150707/aed3c4cf/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 07 Jul 2015 11:08:05 -0700
From: Martin Braun <[email protected]>
To: [email protected], "'[email protected]'"
<[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] [UHD] Replacing Cheetah
Templates with Mako
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 07.07.2015 10:59, Marcus D. Leech wrote:
> OK, so for those of us who maintain builder packages, like
> build-gnuradio, what new packages do I need in the pre-reqs? Just
> python-mako, or are
> there more packages that are required?
Excellent question: For Ubuntu, Debian + Fedora, it depends on the
Python version, so it's either python-mako or python3-mako. Mako can
also be installed from PyPi using e.g. 'pip install Mako'.
There are no other packages required. Note you (for build-gnuradio)
can't rip out Cheetah because it's still required by GNU Radio.
Cheers,
Martin
------------------------------
Message: 7
Date: Tue, 7 Jul 2015 11:16:53 -0700
From: Neel Pandeya <[email protected]>
To: "Faller, Lisa-Marie" <[email protected]>
Cc: usrp-users <[email protected]>
Subject: [USRP-users] fpga build win7
Message-ID:
<CACaXmv89ySx8=daruvbp2adfqcat7zthecogvknokb9upzr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Sorry, there was a typo, I meant to say that we have preliminary Vivado
support in the *master* branch.
--Neel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150707/647daca5/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 7 Jul 2015 14:35:21 -0400
From: evan <[email protected]>
To: [email protected], [email protected]
Subject: [USRP-users] Amplifiers for USRP Transmission
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hello Derek,
Thanks for the response. My original question was really just intended
to be about what factors I'd need to consider if I were to going to try
to use an amplifier along with the USRP; I think I may have kind of
confused people with my unclear description of the receiving side.
You're right though, I have been trying to replicate some of the Ghost
Talk stuff, currently I've gotten it working at a short range on a
Bluetooth headset and the "wire attached to an old microphone" receiver
that I tried to describe before. I don't know if I'm going to add an
amplifier to what I've been trying just yet because there's some other
devices I can try this out on at a short range without needing an
amplifier, but this thread has certainly given me a lot of stuff to
check out before I do add an amplifier. I'll learn about the filtering
you and some others talked about as well as the Nyquist rule before I
try increasing the power of my transmission.
Thanks,
Evan
------------------------------
Message: 9
Date: Tue, 7 Jul 2015 14:46:51 -0400
From: evan <[email protected]>
To: [email protected], [email protected]
Subject: [USRP-users] Amplifiers for USRP Transmission
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hello,
The set-up that I think I did a pretty bad job describing earlier goes
USRP ---> tx antenna ~~~~~~ AIR GAP ~~~~~~~ RX antenna ----> some
components from an old microphone -----> PC sound card. I believe your
theory about non-linearities creating a sort of envelope detection is
accurate, but I think it might be the non-linearities of the
microphone's amplifier that are the component that are doing the
envelope detection. I've begun reading more about Nyquist rates.
Thanks for all your responses, they've been very educational.
Evan
------------------------------
Message: 10
Date: Tue, 7 Jul 2015 12:07:32 -0700
From: Tom Tsou <[email protected]>
To: gsmandvoip <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Newbie Issue
Message-ID:
<CAGNiu+eGF8cB_m_ib1hFKKA-YGHr5Y1v+HxvB8qUeq=ut_c...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Tue, Jul 7, 2015 at 12:45 AM, gsmandvoip via USRP-users
<[email protected]> wrote:
> I have used USRP1 + DBSRX1+LNA for a while with modified clock (52 MHz) in
> order to work with GSM signals but I use to get lot of noise along with my
> interested signals.
> I want to know which factor is responsible to this noise??
> Is it happening due to 20ppm calibration rate of USRP??
If you are driving a USRP1 with a 52 MHz clock, the accuracy of the
stock oscillator is not relevant. If it's phase noise you are seeing,
then the modified clock is likely to blame. Other sources of
noise/interference will be difficult to ascertain without additional
information. Can you describe the noise you see in the frequency
domain?
-TT
------------------------------
Message: 11
Date: Tue, 7 Jul 2015 12:23:53 -0700
From: Ian Buckley <[email protected]>
To: Ezequiel <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] XISE project USRP3 B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Ezequiel,
You should use the Makefile to directly synthesize new B200 images, this is the
only supported build methodology. Review usrp3/top/b200/Makefile.b200.inc and
also usrp3/lib/*/Makefile.srcs to see how to add new source files to the
project.
-Ian
On Jul 3, 2015, at 9:47 AM, Ezequiel via USRP-users
<[email protected]> wrote:
> Hello , I want to synthesize the project .xise generated by the makefile
> provided by GitHub ( USRP3 / top / b200 ) to generate a new FPGA bitstream
> with some more verilog modules created by me , but when I open the project
> with ISE14.7 i can't synthesize because of errors. How should I proceed to
> generate the project to make changes?
> Thanks
> Ezequiel
> _______________________________________________
> 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/20150707/889e84f6/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 7 Jul 2015 15:37:18 -0500
From: Aaron Henderson <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] fpga image types
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
In an earlier email Martin said that the maint branch was used for ISE.
Would using a different fpga image cause a zpu.config error to be thrown in ISE?
Aaron
Sent via the Samsung Galaxy Note? 3, an AT&T 4G LTE smartphone
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150707/66c160c4/attachment-0001.html>
------------------------------
Message: 13
Date: Tue, 7 Jul 2015 21:13:41 +0000
From: "Perelman, Nathan" <[email protected]>
To: Martin Braun <[email protected]>, Ben Hilburn via USRP-users
<[email protected]>
Subject: Re: [USRP-users] [UHD] Replacing Cheetah Templates with Mako
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I haven't tried building it yet, but it looks like this means that UHD will
no long build on Redhat/CentOS 5 or 6 with the stock packages + EPEL, which
would be a problem for me. The build instructions state that Mako 0.5 is the
minimum version, is this accurate? If Mako 0.4.2 worked then CentOS 6 might
work since it has a package for that version.
Alternatively, is there some way to run just the code generation to produce
a source directory that would then not require Mako to build at all?
-Nathan
-----Original Message-----
From: USRP-users [mailto:[email protected]] On Behalf Of
Martin Braun via USRP-users
Sent: Tuesday, July 7, 2015 1:28 PM
To: '[email protected]'; [email protected]
Subject: [USRP-users] [UHD] Replacing Cheetah Templates with Mako
Dear UHD users,
We will be replacing Cheetah as a template engine with the less-dead Mako
template engine. I have pushed a branch for feedback etc. to our github
page:
https://github.com/EttusResearch/uhd/tree/uhd/python3_mako_831
This only affects people building UHD from source. People using binaries
will not care or even need to know about this.
*Why are we doing this?* The issue with Cheetah is, the project seems
inactive and has not been updated in a long while. Also, it is not Python 3
compatible, and some of the distributions we support are starting to switch
over to Python 3 as the default. We spent some time researching other
template engines not only for quality and features, but also for stability
of API, user base, community etc. Mako is used widely on the webs, and has a
mostly backward-compatible API for several years now, as well as an active
community.
*What does UHD need a template engine for?* We use it to auto-generate code
in some places. It saves us from typing out long, boring and repetitive
sources files, which a computer can do much better than a human without
typos. We do *not* use it during runtime or anytime after installation.
*When will this be changed?* Soon, and will be permanent for the next major
release (3.9.0).
*Doesn't GNU Radio work fine with Cheetah?* GNU Radio is facing similar
issues (e.g. no Python 3 compatibility), but Cheetah is much more deeply
woven into GNU Radio and it's harder to replace, and such things can't
happen unless for major releases. It's certainly not a single commit as for
UHD.
I'll leave this public branch up for a bit, and will then merge this into
master -- but I'm happy for any feedback!
Thanks,
Martin
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4327 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150707/45f9d8fe/attachment-0001.p7s>
------------------------------
Message: 14
Date: Tue, 7 Jul 2015 14:21:23 -0700
From: Ian Buckley <[email protected]>
To: Vitaliy Lazarev <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] B210 verilog source code problems
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Vitaliy,
I'm going to suggest you start with greatly reduced scope, there's a lot of
code you are asking questions about here that is both complicated and unrelated
to implementing a simple TX modulator.
The first thing you should do is focus on observing a simple transmit operation
running on an unmodified B210 design. Start by instrumenting duc_chain.v using
chipscope. This block contains a series of configurable digital filters that
allow a signal to be up sampled (interpolated) whilst preserving the original
input signal. The input data stream to this block is the raw sample data that
is output from GNURadio so by starting here you do not need to understand any
of the details of how data is packetized and transported from Host to USRP, but
you get to observe *exactly* the same numerical values you see at the sink of
your flow graph.
Signals you care about to start with:
clk - Everything in this module and under it runs synchronous this clock. This
clock runs at the input sample rate to the AD9361 (which is at a fraction of
the Baseband PLL set by UHD). "master_clock_rate" set as an arg to your flow
graph controls this clock rate.
rst - Active high reset signal.
sample[31:0] - 32 bit (fractional fixed point) sample data. [31:16] is 16bit
signed I data, [15:0] is 16bit signed Q data ( the same ports/data as your UHD:
USRP Sink in GNURadio, possibly transformed from floating point to fixed point
representation).
run - This control signal is asserted whenever transmit is *active*. Whenever
this signal is asserted then the data on the sample bus is valid.
strobe - This control signal is asserted by the DUC in every clock cycle that
data from the sample bus is consumed by the DUC.
tx_fe_i/tx_fe_q[WIDTH-1:0] - Output buses with Tx sample data sent to AD9361
(every clk cycle when run is asserted).
This set of signals alone provide enough connectivity to implement a basic BPSK
modulator inside the DUC without modifying UHD or GNURadio. Something that is
configurable or more sophisticated will require some more signals?but thats the
next step.
-Ian
On Jul 7, 2015, at 10:32 AM, Vitaliy Lazarev via USRP-users
<[email protected]> wrote:
> Hi all, again.
>
> Several months ago I posted a message about some problems in
> understanding verilog code and how it works. Still seeking for help.
>
> ---------- Forwarded message ----------
> From: ??????? ??????? <[email protected]>
> Date: 2015-04-13 15:54 GMT+03:00
> Subject: B210 verilog source code problems
> To: [email protected]
>
>
> > Hi All,
> >
> > I'm working on the project by implementing a modulator (e.g.BPSK) in
> > FPGA on board B210.
> > And the more I digging the Verilog code, the more questions I have
> > about how it actually works.
> > Down below I will talk about only a TX chain, because there's no
> > priority to implement an RX chain right now. Anyway, everything has
> > its time and I hope for your help.
> >
> > 1) There's a module gpif2_slave_fifo32 in b200.v file, that gets a
> > tx_tdata and ctrl_tdata lines forward to DSP chain. In this module I
> > found that it works with a tristate buffer model and depending on what
> > information module get (i.e. what's on GPIF_CTL11 and GPIF_CTL12,
> > which are used for fifo address), it will take it to different
> > fifo-modules. Then it splits to tx_tdata and ctrl_tdata. At this point
> > I don't understand the logic of setting these pins (GPIF_CTL11 and
> > 12). Is there any description of transactions into GPIF? Or maybe
> > there's a documentation how to work with this interface?
> >
> > 2) There's a pin, named codec_data_clk_p. This is a Baseband PLL
> > clock, I suppose, that goes from AD9361. I got the full path:
> > DATA_CLK_P -> G11 -> K3 -> IO_L44P_GCLK21_M3A5_3 (codec_data_clk_p).
> > AD datasheet says, that this clock is programmed from 700 MHz to 1400
> > MHz. How should I know, what clock is going from AD right now, when I
> > run my board with .bin and .hex files? Can I change or reconfigure it
> > from somewhere?
> >
> > 3) While I was surfing the source code it was obvious, that tx data
> > goes from tx0 and tx1 buses (inside b200_core.v). It goes up to
> > tx_data1 and tx_data2 and then it goes to catcodec module and to DAC.
> > But when I looked at it with the Chipscope, I didn't see nothing that
> > proves my theory. Tx bus (inside radio_b200.v) consists from run_tx
> > signal and two other buses - tx_idle and tx_fe_q or tx_fe_i (depends
> > on I and Q components). In Chipscope run_tx signal was 0, so data goes
> > only from tx_idle. But I didn't see at least something that was
> > similar to data from tx_tdata (up in b200.v). Honestly, I didn't see
> > nothing on these buses (it was zeroes, or some constant value that
> > didn't change). Here's the question - how data goes from GPIF and
> > tx_tdata bus down to radio_b200 and goes up to tx_data1 and tx_data2?
> > Maybe I did something wrong with Chipscope, but on tx_tdata there's a
> > data, that transmits from GNURadio. I just don't get the full path.
> > Chipscope was running on radio_clk and bus_clk and it didn't change
> > anything.
> >
> > 4) As I said before, while I was chipscoping, run_tx was set to 0. But
> > there a lot of DSP modules inside radio_b200.v, that run from run_tx
> > (e.g. Digital Up Converter, CIC filter, CORDIC-module and so on). It
> > means that these modules are not working right now. But it ruins my
> > understanding of digital up and down converter chains at all! If all
> > these modules aren't used, why they are in the source code? For other
> > board models? Or if I just didn't turn them on, how can I enable them?
> >
> > All of these things are prevent my attempts to implement something in
> > verilog source code.
> > I have a feeling, that I miss some fundamental things. I hope someone
> > will help me with my questions, cause I'm stuck.
>
> --
> Best regards,
> Vitaliy Lazarev.
> _______________________________________________
> 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/20150707/fccf2e1e/attachment-0001.html>
------------------------------
Message: 15
Date: Tue, 07 Jul 2015 14:38:02 -0700
From: Martin Braun <[email protected]>
To: "Perelman, Nathan" <[email protected]>, Ben Hilburn
via USRP-users <[email protected]>
Subject: Re: [USRP-users] [UHD] Replacing Cheetah Templates with Mako
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Nathan,
thanks for the feedback -- Mako 0.4.2 probably works, too, we just
haven't tested it yet. It looks like we can possibly go back as far as
0.4.1 (which is more than four years old, which seems like a fair age
for a dependency).
We'll give it a spin and roll back the minimum version, if possible.
Thanks again,
Martin
On 07.07.2015 14:13, Perelman, Nathan wrote:
> I haven't tried building it yet, but it looks like this means that UHD will
> no long build on Redhat/CentOS 5 or 6 with the stock packages + EPEL, which
> would be a problem for me. The build instructions state that Mako 0.5 is the
> minimum version, is this accurate? If Mako 0.4.2 worked then CentOS 6 might
> work since it has a package for that version.
>
> Alternatively, is there some way to run just the code generation to produce
> a source directory that would then not require Mako to build at all?
> -Nathan
>
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Martin Braun via USRP-users
> Sent: Tuesday, July 7, 2015 1:28 PM
> To: '[email protected]'; [email protected]
> Subject: [USRP-users] [UHD] Replacing Cheetah Templates with Mako
>
> Dear UHD users,
>
> We will be replacing Cheetah as a template engine with the less-dead Mako
> template engine. I have pushed a branch for feedback etc. to our github
> page:
> https://github.com/EttusResearch/uhd/tree/uhd/python3_mako_831
>
> This only affects people building UHD from source. People using binaries
> will not care or even need to know about this.
>
> *Why are we doing this?* The issue with Cheetah is, the project seems
> inactive and has not been updated in a long while. Also, it is not Python 3
> compatible, and some of the distributions we support are starting to switch
> over to Python 3 as the default. We spent some time researching other
> template engines not only for quality and features, but also for stability
> of API, user base, community etc. Mako is used widely on the webs, and has a
> mostly backward-compatible API for several years now, as well as an active
> community.
>
> *What does UHD need a template engine for?* We use it to auto-generate code
> in some places. It saves us from typing out long, boring and repetitive
> sources files, which a computer can do much better than a human without
> typos. We do *not* use it during runtime or anytime after installation.
>
> *When will this be changed?* Soon, and will be permanent for the next major
> release (3.9.0).
>
> *Doesn't GNU Radio work fine with Cheetah?* GNU Radio is facing similar
> issues (e.g. no Python 3 compatibility), but Cheetah is much more deeply
> woven into GNU Radio and it's harder to replace, and such things can't
> happen unless for major releases. It's certainly not a single commit as for
> UHD.
>
> I'll leave this public branch up for a bit, and will then merge this into
> master -- but I'm happy for any feedback!
>
> Thanks,
> Martin
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 16
Date: Wed, 8 Jul 2015 17:25:11 +0530
From: gsmandvoip <[email protected]>
To: Tom Tsou <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Newbie Issue
Message-ID:
<CADE+fGBms9uNkoxbs-Ydi095r2GPx=uBiYsyGKME=grzKo+=t...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks Marcus, Tom for response.
It is happening when I am trying to monitor GSM spectrum, happens with all
frequency range.
Here is how it came in.
I am trying to use airprobe to monitor Sys Info of my surrounding BTS,
which I am able to do successfully but when I am trying to analyze with
telit modem I see more BTS around, also I see those those frequencies in
Kaliberate but when I tune to it sometimes it is decodable and sometimes
not, which I blame to signal strength.
But here my point is if modem is able to get exact frequency and says it
has Beacon channel which I verified using airprobe, what level of
sensitivity do I need in order to keep USRP tuned??
Things get worse if I change gain of DBSRX, so I presumed it works best at
50 (?5) which is default.
My first guess for this random behavior was 52 MHz external clock installed
on it, but I get even more errors when I use onboard clock in another USRP
with same configuration.
So external clock is making things better but not as per my expectations
Also I want to learn more about PPM factor and its role in signal reception
or digitization. googled, but could not find from where should I start
Would you please guide me through my issue ref. signal reception using
USRP, would love to learn step by step
On Wed, Jul 8, 2015 at 12:37 AM, Tom Tsou <[email protected]> wrote:
> On Tue, Jul 7, 2015 at 12:45 AM, gsmandvoip via USRP-users
> <[email protected]> wrote:
> > I have used USRP1 + DBSRX1+LNA for a while with modified clock (52 MHz)
> in
> > order to work with GSM signals but I use to get lot of noise along with
> my
> > interested signals.
> > I want to know which factor is responsible to this noise??
> > Is it happening due to 20ppm calibration rate of USRP??
>
> If you are driving a USRP1 with a 52 MHz clock, the accuracy of the
> stock oscillator is not relevant. If it's phase noise you are seeing,
> then the modified clock is likely to blame. Other sources of
> noise/interference will be difficult to ascertain without additional
> information. Can you describe the noise you see in the frequency
> domain?
>
> -TT
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150708/2a636a7a/attachment-0001.html>
------------------------------
Message: 17
Date: Wed, 8 Jul 2015 14:10:29 +0200
From: Thomas Hobiger <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] PhD position in GNSS Reflectometry (GNSS-R)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; format=flowed
Dear colleagues,
(sorry for cross postings)
I want to draw your attention to this recently opened
PhD position in GNSS-R for which we are searching candidates with
experience in signal processing and software-defined radio (SDR).
http://www.chalmers.se/en/about-chalmers/vacancies/?rmpage=job&rmjob=3255
Please share this announcement with students who might be interested or
circulate this information within you SDR network.
Thank you very much.
Thomas Hobiger
--
******************************************************************
Thomas Hobiger, Dr.
Associate Professor
Department of Earth and Space Sciences
Onsala Space Observatory
Chalmers University of Technology
------------------------------------------------------------------
Observatoriev?gen 90, R??
SE-439 92 Onsala
Sweden
------------------------------------------------------------------
email: [email protected]
phone: ++46-31-772-5549
fax: ++46-31-772-5590
******************************************************************
------------------------------
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 59, Issue 8
*****************************************
