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. Is there an E310 OpenBTS image? (david wang)
2. Schematics DDC/DUC chains in x310 (Carlos L?pez-Mart?nez)
3. Re: Schematics DDC/DUC chains in x310 (Martin Braun)
4. Re: Schematics DDC/DUC chains in x310 (Marcus M?ller)
5. Re: fpga image types (Martin Braun)
6. recv_frame_size and num_recv_frames for B210 (Dario Fertonani)
7. Re: Trouble understanding o_tdata (Jonathon Pendlum)
8. Re: Trouble understanding o_tdata (Jason Matusiak)
9. Re: fpga image types (Aaron Henderson)
10. WG: fpga build win7 (Faller, Lisa-Marie)
11. Re: USRP E100 - updating UHD (Leonardo S. Cardoso)
12. create_live_sdr_fs.sh results in non-bootable LiveUSB (Martin)
13. Urgent Help Needed (prabhu)
14. Where does the RFNOC block name come from? (Jason Matusiak)
15. Re: rx_streamer->recv ([email protected])
16. Re: [Discuss-gnuradio] [UHD] Cause of sequence errors
(SSSSS...) when using USRP N210 as transmitter? ([email protected])
17. Re: Where does the RFNOC block name come from? (Sylvain Munaut)
18. Re: Where does the RFNOC block name come from? (Jason Matusiak)
19. Re: Where does the RFNOC block name come from? (Sylvain Munaut)
20. Re: [Discuss-gnuradio] [UHD] Cause of sequence errors
(SSSSS...) when using USRP N210 as transmitter? ([email protected])
21. Re: Urgent Help Needed (Marcus M?ller)
22. Re: Urgent Help Needed (Philip Balister)
23. Re: [UHD] Replacing Cheetah Templates with Mako (Martin Braun)
----------------------------------------------------------------------
Message: 1
Date: Tue, 7 Jul 2015 20:35:24 -0400
From: david wang <[email protected]>
To: [email protected]
Subject: [USRP-users] Is there an E310 OpenBTS image?
Message-ID:
<CAG8qimS2qgA9amXmaKJ9013R2SgDCBNfaLC7jbC5uqBvO1K8=g...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Total RF/EE/SDR/USRP/OpenBTS newbie here.
Too many gaps to filled...
I did followed the tutorial and got a FM receiver working and now I am
hook and want to do more.
Balint Seeber have OpenBTS running on an E310 that he demo @Blackhat.
Just wondering if that image available?
Anyway I updated my newly procure e310 to:
http://files.ettus.com/e3xx_images/e310-release-002/sdimage-gnuradio-demo.direct.xz
Followed build direction here:
http://openbts.org/w/index.php/E3x0
After creating some symlinks I got OpenBTS up and running (with 0
working configurations)
I was ecstatic; but that happiness was short lived.
I used an old 8gb SD card(it's all I had) and after couple power
cycle; I am getting quite a bit of block read error :-(
fsck the partition didn't help.
The build process isn't too difficult but time consuming.
It would be very helpful for newbie like me.
Thanks
David
------------------------------
Message: 2
Date: Wed, 08 Jul 2015 15:51:19 +0200
From: Carlos L?pez-Mart?nez <[email protected]>
To: [email protected]
Subject: [USRP-users] Schematics DDC/DUC chains in x310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Dear all,
In the frame of our research activities, we plan to use the x310 system.
Before to actually use them, we plan to do some simulations in order to
determine the performances we may expect. When confronted to the
simulation of the whole device, we have found accurate information to
simulate the daughter-board we are interested into. Nevertheless, when
addressing the simulation of the digital part, i.e., the mother-board,
the information is a bit limited. We have found some information about
the schematics of the DDC/DUC chains implemented into the FPGA, but this
information is not detailed enough for our purposes. I would like to
know where we could find the most detailed information and/or schematics
regarding the DDC/DUC chains implemented into the FPGA.
Best regards,
Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150708/69fb7ce3/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 08 Jul 2015 09:30:57 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Schematics DDC/DUC chains in x310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Carlos,
all our source files are up for perusal, e.g.
https://github.com/EttusResearch/fpga/blob/master/usrp3/lib/dsp/ddc_chain_x300.v.
I suggest cloning the repository and reading the files locally.
Regards,
Martin
On 08.07.2015 06:51, Carlos L?pez-Mart?nez via USRP-users wrote:
> Dear all,
>
> In the frame of our research activities, we plan to use the x310 system.
> Before to actually use them, we plan to do some simulations in order to
> determine the performances we may expect. When confronted to the
> simulation of the whole device, we have found accurate information to
> simulate the daughter-board we are interested into. Nevertheless, when
> addressing the simulation of the digital part, i.e., the mother-board,
> the information is a bit limited. We have found some information about
> the schematics of the DDC/DUC chains implemented into the FPGA, but this
> information is not detailed enough for our purposes. I would like to
> know where we could find the most detailed information and/or schematics
> regarding the DDC/DUC chains implemented into the FPGA.
>
> Best regards,
>
> Carlos
>
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 4
Date: Wed, 08 Jul 2015 18:33:39 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Schematics DDC/DUC chains in x310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Dear Carlos,
well, if a schematic overview is not enough for your purposes, I think
the only thing sufficient is looking at the source code itself:
looking into https://github.com/EttusResearch/fpga/, consider the
usrp3/top/x300 folder.
Inspecting x300_core.v you'll find that you need to understand radio.v,
https://github.com/EttusResearch/fpga/blob/master/usrp3/lib/radio/radio.v
where the different DSP parts, especially DDC/DUC, are actually
instantiated.
Best regards,
Marcus
On 07/08/2015 03:51 PM, Carlos L?pez-Mart?nez via USRP-users wrote:
> Dear all,
>
> In the frame of our research activities, we plan to use the x310
> system. Before to actually use them, we plan to do some simulations in
> order to determine the performances we may expect. When confronted to
> the simulation of the whole device, we have found accurate information
> to simulate the daughter-board we are interested into. Nevertheless,
> when addressing the simulation of the digital part, i.e., the
> mother-board, the information is a bit limited. We have found some
> information about the schematics of the DDC/DUC chains implemented
> into the FPGA, but this information is not detailed enough for our
> purposes. I would like to know where we could find the most detailed
> information and/or schematics regarding the DDC/DUC chains implemented
> into the FPGA.
>
> Best regards,
>
> Carlos
>
>
>
>
>
>
>
>
> _______________________________________________
> 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/20150708/e120656d/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 08 Jul 2015 09:35:17 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] fpga image types
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 07.07.2015 13:37, Aaron Henderson via USRP-users wrote:
> 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?
It would be random, but not inconceivable... how/when does this happen,
and does it also happen with master branch images?
M
------------------------------
Message: 6
Date: Wed, 8 Jul 2015 10:18:26 -0700
From: Dario Fertonani <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] recv_frame_size and num_recv_frames for B210
Message-ID:
<cajgedagl2srb3xf65cib7abnk4malfhoa9ne9vzwshr6hvg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I was able to eliminate the rare overflow errors just by using higher
values of recv_frame_size and num_recv_frames for the rx stream. Our stack
easily meet the timeline, so we're looking at eliminating rare overflow
errors due to the non-deterministic nature of the non-real-time OS (in our
case, Ubuntu 14.04 low latency), rather than to slow stack processing.
Any drawback in using high values of recv_frame_size and num_recv_frames,
besides memory usage/waste? For example, I don't fully understand what
happens when num_recv_frames is bumped up to 256 from the default value of
16. Does the worst-case latency increases by 16 times?
Thanks,
Dario
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150708/18a61f48/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 8 Jul 2015 10:33:54 -0700
From: Jonathon Pendlum <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: Ettus Mail List <[email protected]>
Subject: Re: [USRP-users] Trouble understanding o_tdata
Message-ID:
<CAGdo0uTovssoJc7au1yp-HLQMg=ln2ou5oh2_sdjepu3ncs...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jason,
You have the right idea on the meaning of the signals. I think you might
have a syntax issue though. Using the division operator with concatenation
is probably causing an issue since the resulting bitwidth is wider than
o_tdata. Try changing the code to:
assign o_tdata = {i_tdata[WIDTH-1:WIDTH/2] >>> 1,i_tdata[WIDTH/2-1:0] >>>
1};
Jonathon
On Tue, Jul 7, 2015 at 5:45 AM, Jason Matusiak via USRP-users <
[email protected]> wrote:
> In my endless pursuit to understand the inner workings of RFNoC, I am
> still having issues creating my dummy block that halves the incoming
> signal. I can create a new FPGA bitfile and GRC script and get
> everything to run, but I am having trouble getting it to function as I
> would expect.
>
> If I make a script that is:
> RFNOC: Radio -> RFNoC: FIFO -> QT GUI Freq Sink
>
> I can see noise and then when I turn on my exterior tone and broadcast
> it at 101MHz, see it pop up on my freq sink.
>
> I then modify my GRC script to add in my new block so that the stream
> looks like:
> RFNOC: Radio -> RFNoC: FIFO -> RFNoc: halfSignal -> QT GUI Freq Sink
>
> Now I would expect everything to function the same, and when I turn on
> my externally broadcast tone, it would show a 3-6dB decrease in power
> due to the halving block being in place. This does not happen, instead
> I always see a tone at the center of the freq sink, even when I am not
> broadcasting my external tone. This leads me to believe that I am not
> manipulating the data properly in my halving block on the FPGA.
>
> On the FPGA, I mimic the keep_one_in_n FPGA files by creating
> halfSignal.v and halfSignal_vec.v files. In the halfSignal_vec.v file,
> the pertinent info is:
> assign i_tready = o_tready;
> assign o_tvalid = i_tvalid;
> assign o_tdata = {i_tdata[WIDTH-1:WIDTH/2]/2,i_tdata[WIDTH/2-1:0]/2};
> assign o_tlast = i_tlast;
>
> Am I misunderstanding what o_tdata/i_tdata actually is used for? In my
> above example I am assuming that i_tdata contains a concatenation of the
> I/Q incoming stream.
>
> When I stop the script from running on the E310, I do see an error
> message, but I don't think it is relevant to this problem. Here it is
> anyway just in case:
> python2:
>
> /home/balister/fido-test/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/python/2.7.9-r1/Python-2.7.9/Modules/gcmodule.c:366:
> visit_decref: Assertion `gc->gc.gc_refs != 0' failed.
>
>
> _______________________________________________
> 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/20150708/5ab74549/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 08 Jul 2015 11:00:58 -0700
From: "Jason Matusiak" <[email protected]>
To: "Jonathon Pendlum" <[email protected]>
Cc: "Ettus Mail List" <[email protected]>
Subject: Re: [USRP-users] Trouble understanding o_tdata
Message-ID:
<20150708110058.ba066092a6e013ef68fa4f5a8d80e9ee.67554db00b....@email02.secureserver.net>
Content-Type: text/plain; charset="utf-8"
>You have the right idea on the meaning of the signals. I think you might have
>a syntax issue though. Using the >division operator with concatenation is
>probably causing an issue since the resulting bitwidth is wider than o_tdata.
>>Try changing the code to:
>assign o_tdata = {i_tdata[WIDTH-1:WIDTH/2] >>> 1,i_tdata[WIDTH/2-1:0] >>> 1};
Jonathon, I actually had your code originally and then changed it later
see if something else was going on. I have since changed things to be a
"doubler" by:
assign o_tdata =
{i_tdata[WIDTH-1:WIDTH/2]+i_tdata[WIDTH-1:WIDTH/2],i_tdata[WIDTH/2-1:0]+i_tdata[WIDTH/2-1:0]};
And that seems to be working better. So I am guessing that I have the
gist of things, I am probably just misunderstanding something with the
GRC script itself and its freq sink, or something of that ilk.
------------------------------
Message: 9
Date: Wed, 8 Jul 2015 16:21:38 -0500
From: Aaron Henderson <[email protected]>
To: Martin Braun <[email protected]>,
<[email protected]>
Subject: Re: [USRP-users] fpga image types
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
It happens during the synthesis phase.
I am not sure about which branch it is.
Which branch is downloaded with a recursive download using git?
Aaron
Sent via the Samsung Galaxy Note? 3, an AT&T 4G LTE smartphone
-------- Original message --------
From: Martin Braun via USRP-users <[email protected]>
Date: 07/08/2015 11:36 AM (GMT-06:00)
To: [email protected]
Subject: Re: [USRP-users] fpga image types
On 07.07.2015 13:37, Aaron Henderson via USRP-users wrote:
> 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?
It would be random, but not inconceivable... how/when does this happen,
and does it also happen with master branch images?
M
_______________________________________________
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/20150708/4a4b5e03/attachment-0001.html>
------------------------------
Message: 10
Date: Thu, 9 Jul 2015 05:19:06 +0000
From: "Faller, Lisa-Marie" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] WG: fpga build win7
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi,
By now I managed to build FPGA-master under Ubuntu using Vivado2014.4 (I
re-installed Vivado System Design Edition since I understood that the target
FPGA -device must be missing).
According to the build under Win7/MinGW: I tried to build the FPGA-maint with
ISE 14.7 and managed to setup the PATH accordingly, everything seems to work
until x300.v is added as source: it says the x300.v file cannot be found
although it is definitely there, any idea on that?
What I want to do finally is ?abuse? the USRP-devices (x310) to build a
measurement system. To do that, it will be necessary to reduce the code on the
FPGA. We want to read baseband signals (up to ~10MHz) from ADCs followed by
IQ-demodulation and filtering. On the transmit side we want to generate these
carrier signals (so up to ~10MHz). This should be done synchronously for 4 of
the x310 devices (at the end). The FPGA-generated carrier signals to be output
at the Tx will be used internally for demodulation.
Do you maybe have suggestions on how to go for that concerning FPGA programming?
Thank you and best regards,
Lisa
Von: Neel Pandeya [mailto:[email protected]]
Gesendet: 07 July 2015 20:17
An: Faller, Lisa-Marie
Cc: usrp-users
Betreff: [USRP-users] fpga build win7
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/20150709/7d93c5e0/attachment-0001.html>
------------------------------
Message: 11
Date: Thu, 9 Jul 2015 13:43:12 +0200
From: "Leonardo S. Cardoso" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP E100 - updating UHD
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Oops, just noticed we?re out of the list?
Bringing the discussion back to the list
Leo
--
Leonardo S. Cardoso
Maitre de Conference
CITI lab, INSA-Lyon - INRIA
> Begin forwarded message:
>
> From: "Leonardo S. Cardoso" <[email protected]>
> Subject: Re: [USRP-users] USRP E100 - updating UHD
> Date: 9 Jul 2015 12:02:42 pm CEST
> To: Philip Balister <[email protected]>
>
> Hi Philip,
>
> Thanks again for the tip.
>
> I?ve done what you advised but I?m still stuck a rather old version of UHD
> and GNU Radio. My ultimate goal is to move onto GNU Radio 3.7.x.
>
> Are there any pre-compiled images or an easy way to update UHD and GNU Radio
> by hand?
>
> Cheers,
>
> Leo
>
> --
> Leonardo S. Cardoso
> Maitre de Conference
> CITI lab, INSA-Lyon - INRIA
>
>
>
>> On 03 Jul 2015, at 19:28 , Philip Balister <[email protected]> wrote:
>>
>> On 07/03/2015 09:08 AM, Leonardo S. Cardoso via USRP-users wrote:
>>> Hello everyone,
>>>
>>> I?m facing some problems trying to update the UHD version of my USRP E100.
>>
>> Use opkg update; opkg upgrade
>>
>> That should get a reasonable version of UHD. What feature are you
>> looking for in uhd?
>>
>> Philip
>>
>>>
>>> I?ve followed the steps described in the redmine:
>>> http://code.ettus.com/redmine/ettus/projects/usrpe1xx/
>>> <http://code.ettus.com/redmine/ettus/projects/usrpe1xx/> to update the
>>> kernel modules as well as to re-compile UHD from the sources. Whenever I
>>> try to launch any uhd command to test the new installation I get:
>>>
>>> linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500;
>>> UHD_003.005.004-140-gfb32ed16
>>>
>>>
>>> Creating the usrp device with: ...
>>> -- Loading FPGA image: /usr/local/share/uhd/images/usrp_e100_fpga_v2.bin...
>>> done = 1
>>> -- Configuration complete.
>>> -- Initializing FPGA clock to 64.000000MHz...
>>> -- USRP-E100 clock control: 10
>>> -- r_counter: 2
>>> -- a_counter: 0
>>> -- b_counter: 20
>>> -- prescaler: 8
>>> -- vco_divider: 5
>>> -- chan_divider: 5
>>> -- vco_rate: 1600.000000MHz
>>> -- chan_rate: 320.000000MHz
>>> -- out_rate: 64.000000MHz
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20150709/c5685705/attachment-0001.html>
------------------------------
Message: 12
Date: Thu, 09 Jul 2015 14:46:24 +0200
From: Martin <[email protected]>
To: [email protected]
Cc: Ettus Research Support <[email protected]>
Subject: [USRP-users] create_live_sdr_fs.sh results in non-bootable
LiveUSB
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
I tried to make a bootable LiveUSB from the files found on:
http://files.ettus.com/liveusb/3.0/
When I use the create_live_sdr_fs.sh script, with fat.zip and
casper-rw.tar.bz2 and then the resulting usb stick is not bootable.
When I in stead use the 3.0-smaller.img.bz2 or 3.0.img.bz2 then the
resulting usb stick is bootable and works.
I am not a filesystem expert, but with a binary diff (dhex) is see many
differences in the resulting binary data on the first 10 MB of the disk.
Is suspect that the create_live_sdr_fs.sh script on the ettus website is
not the same (latest) version as the one that was used to create
3.0-smaller.img.bz2 and 3.0.img.bz2
Is the latest version of create_live_sdr_fs.sh also available somewhere ?
I would prefer not to use an image to create the stick, since writing a
solid state usbstick with an image from start to end will leave no room
for the wearleveling algorithm on the drive. This will ruin write
performance.
Using a substantially smaller image, leaving a gigabyte or more
unwritten at the end would help a bit. But not writing unused sectors
would be much better.
So I hope that someone knows how to get a working create_live_sdr_fs.sh
Thanks in advance,
Martin Dudok van Heel
------------------------------
Message: 13
Date: Thu, 9 Jul 2015 08:58:43 -0500
From: prabhu <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] Urgent Help Needed
Message-ID:
<caes_zqxcbepzv354+4jv7i7nwue6a_k+mkt-2bqylqt5ddo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I am using USRP E-310. It has an embedded OS. But this has very limited
functions. I am not able to install the SCIPY stack. I am not able to
complete it because of the warning which says "LAPACK" missing.
This device does not have package repository similar to other linux
operating systems. Only way I can install a new package is through OPKG
which also missing basic libraries.
This device cannot be operated in Network Mode. And because of this some we
need have the functionality of installing the missing library files.
SCIPY and NUMPY stack of python is heavily needed for some signal
processing and other math operations if I am writing a python script.
I tried to install the LAPACK library from source but new issues crops up
saying gfortran command not found. If any one faced the same issue and have
a solution do share with me.
*-------------------------------------------------------------------------------------------------------------------------------------*
*Thanks,*
*Prabhu Janakaraj*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150709/e815c82e/attachment-0001.html>
------------------------------
Message: 14
Date: Thu, 09 Jul 2015 07:00:55 -0700
From: "Jason Matusiak" <[email protected]>
To: "Ettus Mail List" <[email protected]>
Subject: [USRP-users] Where does the RFNOC block name come from?
Message-ID:
<20150709070055.ba066092a6e013ef68fa4f5a8d80e9ee.0409efbfa7....@email02.secureserver.net>
Content-Type: text/plain; charset="utf-8"
I did this once, but I must have got lucky as I haven't been able to
replicate it. I created a new RFNoC block, but when I run
uhd_usrp_probe --init-only, I see:
-- ========== Full list of RFNoC blocks: ============
-- * 0/Radio_0
-- * 0/Radio_1
-- * 0/FIFO_0
-- * 0/FIR_0
-- * 0/Block_0
Where is the "Block" name coming from? It should be called "doubler",
but I obviously don't have something configured properly. I need to get
it right, because if I use a script that needs to call doubler, I see:
RuntimeError: Cannot find a block for ID: doubler
------------------------------
Message: 15
Date: Thu, 9 Jul 2015 14:17:21 +0000 (UTC)
From: [email protected]
To: Neel Pandeya <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] rx_streamer->recv
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Neel,
Attached is a sample application that reproduces the problem.
It takes command line argument for usrp config string, please use the
following:
addr=YOUR_IP_ADDR,recv_frame_size=1044
This app is hard coded to the following specs:
900 MHz freq
10 MSA/sec
2 MHz bandwidth
applications recv buffer size = 32 samples
My software platform is
win7 SP1 64 bit
Visual Studio 2013 update 4
UHD 3.8.3 64 bit
Boost 1.56
The app is coded to print out a message any time recv takes longer than 1
millisecond using boost timers. This should never happen as the recv frame size
is set to 256 samples, which at 10 MSa/sec sampling rate is a packet arriving
every 25.6 + slop usec, on average. So in 1 millisecond, somewhere around 40
packets will have arrived to the NIC.
If you move the logging down into UHD to the line I identified previously (
info.buff.reset() ), you will see that this is where the slowdown takes place
periodically.
I havent investigated into that call, I leave that up to the experts :)
As I said previously, NIC is tuned, things work properly at all other times,
not the virus scanner or any govenors, fastdatagram set to 4088 (but for this
packet size, is not relevant).
Please let me know if I can provide any more details.
Thanks,
----- Original Message -----
From: "The Tilla via USRP-users" <[email protected]>
To: "Neel Pandeya" <[email protected]>
Cc: "usrp-users" <[email protected]>
Sent: Wednesday, June 17, 2015 10:34:21 PM
Subject: Re: [USRP-users] rx_streamer->recv
More information:
The ?slowdown? every second on calls to recv is * always * there?
At 1 GB memory utilization it is 100 usec ?pause? every second
At 10 GB memory utilization it is 2 millisecond ?pause? every second
At 20 GB memory utilization it is 3 milli-seconds ?pause? every second
So it seems to increase with increasing memory utilization at the call to
info.buff.reset()
The results of todays analysis J
From: Neel Pandeya [mailto:[email protected]]
Sent: Sunday, June 14, 2015 11:01 AM
To: The Tilla
Cc: [email protected]; Garey, Marshall Owen
Subject: Re: [USRP-users] rx_streamer->recv
Hello Tilla:
It looks like you're tried pretty much everything I can think of. I'm impressed
that you have been able to get 99.9% good sample delivery in Windows 7. These
infrequent, last-mile problems are the hardest to solve. At this point, I can
only offer of the following suggestions.
As Marshall Owen Garey mentioned, I have heard many times anecdotally from
customers that people are able to achieve better performance under Linux than
Windows. As a test of your hardware, perhaps try running your application under
Linux. An easy way to do this would be use a Live USB image [1,2].
I have also heard from two customers who were having performance problems on
Windows 7 that they were able to improve performance by upgrading to Windows 8.
I'm not sure if this is an option for you, but you might want to try this.
Have you made any tweaks to the registry? The only specific modification that
we suggest is [3].
Which version of Boost are you using?
Have you enabled any optimization or processing off-loading features of your
NIC?
Is there any other intermittent spike or burst in network traffic, perhaps on a
different port such as one for your corporate network, that could be causing
intermittent spikes in CPU load?
Certainly make sure that you have any background processes/services turn off,
such as anti-virus, update tools, firewall, etc.
[1] http://files.ettus.com/liveusb/3.0/
[2] https://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
[3]
https://github.com/EttusResearch/uhd/blob/master/host/utils/FastSendDatagramThreshold.reg
--Neel
On 10 June 2015 at 16:25, Garey,
??
Marshall Owen via USRP-users < [email protected] > wrote:
I have had a very similar problem with the same setup (Windows 7 64-bit, N210,
VS2013), and when I moved to Linux (which was a real pain) I was able to recv
at a higher rate with no problems. So I agree with you ? it?s probably Windows.
The only suggestions I have is to try turning off any background programs and
processes that you can (such as the antivirus). You could try the LiveUSB image
provided by Ettus Research to see if it is a Windows problem (that?s what I
did).
From: USRP-users [mailto: [email protected] ] On Behalf Of The
Tilla via USRP-users
Sent: Wednesday, June 10, 2015 4:31 PM
To: [email protected]
Subject: [USRP-users] rx_streamer->recv
Platform:
Win7 64 bit
N210
Visual Studio 2013
So may application is very sensitive to latencies.
I have taken 42 million measurements during runtime. 41+ million calls to recv
execute in under 10 micro-seconds. I am asking for 32 samples with packet size
of 256 samples and sampling rate of 10 MSA/sec.
Sample delivery is pretty awesome 99.999 percent of the time?
Then there are the times when recv takes very close to 1 millisecond to return
( ~5000 times out of 42 million (yeah, pretty crazy) ).
There is never a time where no packets are delivered within 1 millisecond given
a 10 MSA/sec sampling rate?
What this feels like is good old windows scheduler putting something in a state
where it will never come back on to the processor until around 1 millisecond
later no matter what interrupt is raised.
A timer was placed right before rx_streamer->recv and right after
rx_streamer->recv to take measurements, no other work being done during timer
measurement.
The only think that I could think of is the udp recv way down at the bottom of
the stack?
But it works ?properly? sooooo many times without blocking for a long period of
time.
Things I have tried:
Running process @ realtime priority
Mucking with recv sample sizes, packet sizes, etc.
Already disabled interrupt moderation and related settings
Used windows server setting for process quantum
Compiled with full optimizations
Recv is in its own thread and processing around recv is very fast
Affinitized application recv processing thread ( not UHD pirate thread, YAR! )
to CPU directly attached to NIC PCI card
NIC is Intel ET2 quad port card
Any suggestions?
Any OS settings to lower what feels like some sort of minimum a sleep/block
interval that anyone is aware of?
Thanks
_______________________________________________
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/20150709/2b0cecd0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rcvr.cpp
Type: text/x-c++src
Size: 2794 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150709/2b0cecd0/attachment-0001.cpp>
------------------------------
Message: 16
Date: Thu, 09 Jul 2015 10:19:40 -0400
From: [email protected]
To: George Hadley <[email protected]>
Cc: GNURadio Discussion List <[email protected]>,
[email protected],
[email protected]
Subject: Re: [USRP-users] [Discuss-gnuradio] [UHD] Cause of sequence
errors (SSSSS...) when using USRP N210 as transmitter?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
What version of UHD are you using?
Any idea what ethernet controller is used on that dual-port card?
You'd have to go into windows configuration to determine this, since I
think that 'lspci' on the VM side will see some kind of emulated network
card.
I've taken the liberty of copying this to the usrp-users list, since
this is more USRP-centric, than GnuRadio-centric.
On 2015-07-09 09:21, George Hadley wrote:
> I am indeed running inside a VM presently. Details below:
>
> Hardware:
> USRP N210 (2x) connected to dual-port gigabit ethernet card:
> http://www.newegg.com/Product/Product.aspx?Item=N82E16833166096 [2]
>
> Software:
> Windows 7 host OS
> VirtualBox VM running Mint Linux 17.1 (Mate Desktop edition)
> Network settings:
> + Adapter enabled and attached to NAT
> + No port forwarding settings defined
>
> It may be noteworthy that the receive operation of the USRPs works as
> expected. Only transmit doesn't appear to be working properly.
>
> Thanks,
> George
>
> On 7/9/2015 9:11 AM, [email protected] wrote:
>
> This is usually due to your network subsystem re-ordering packets, which is
> never supposed to happen but certain
> 1GiGe interfaces, particularly USB ones, do this quite a bit.
>
> Are you running inside a VM?
>
> What kind of network interface do you have?
>
> On 2015-07-09 09:09, George Hadley wrote:
>
> Hello,
>
> I'm working on developing some gnuradio exercises, some of which involve
> using USRP N210 devices as transmitters. When I attempt to run the related
> flowgraphs, I get a stream of sequence errors (S) in the GRC log window.
> Attached are a pair of GRC flowgraphs in which I am getting this error. I
> have tried installing the latest images to the USRPs and updating to the
> latest version of gnuradio available on the github master branch. Can
> somebody please point me to what I'm doing wrong? I've searched around on the
> topic for quite awhile, to no avail.
>
> Thanks,
> George
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
--
George Hadley
ECE Lab Coordinator
Purdue University
Links:
------
[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[2] http://www.newegg.com/Product/Product.aspx?Item=N82E16833166096
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150709/af70613f/attachment-0001.html>
------------------------------
Message: 17
Date: Thu, 9 Jul 2015 16:27:10 +0200
From: Sylvain Munaut <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: Ettus Mail List <[email protected]>
Subject: Re: [USRP-users] Where does the RFNOC block name come from?
Message-ID:
<CAHL+j0_VN9FuZSPbLnAp67=d53zxdbnuenwj24j4wem03xw...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
> Where is the "Block" name coming from? It should be called "doubler",
> but I obviously don't have something configured properly. I need to get
> it right, because if I use a script that needs to call doubler, I see:
> RuntimeError: Cannot find a block for ID: doubler
The xml installed in $PREFIX/share/uhd/rfnoc/blocks/whatever_your_block_is.xml
It will have the <blockname> for the name to use and a list of <ids>
that mut match the numeric 16 bit identifier used in your FPGA code.
Cheers,
Sylvain
------------------------------
Message: 18
Date: Thu, 09 Jul 2015 07:31:28 -0700
From: "Jason Matusiak" <[email protected]>
To: "Sylvain Munaut" <[email protected]>
Cc: "Ettus Mail List" <[email protected]>
Subject: Re: [USRP-users] Where does the RFNOC block name come from?
Message-ID:
<20150709073128.ba066092a6e013ef68fa4f5a8d80e9ee.7e2ae65694....@email02.secureserver.net>
Content-Type: text/plain; charset="utf-8"
> The xml installed in $PREFIX/share/uhd/rfnoc/blocks/whatever_your_block_is.xml
>
> It will have the <blockname> for the name to use and a list of <ids>
> that mut match the numeric 16 bit identifier used in your FPGA code.
Interesting, thanks for the quick response.
Does it get installed there by some other process, or do I need to
create a file there by scratch?
------------------------------
Message: 19
Date: Thu, 9 Jul 2015 17:08:29 +0200
From: Sylvain Munaut <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: Ettus Mail List <[email protected]>
Subject: Re: [USRP-users] Where does the RFNOC block name come from?
Message-ID:
<cahl+j0_vrsex8jxrtd44kv2sjorzgn8unxxo++eqx99bjuz...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Well nothing will create it for you. You're supposed to write that
file and put it there.
In my blocks I just added it to UHD and it gets installed when I
install UHD. Not sure if there is any kind of convention for how to do
OOT with rfnoc yet.
Cheers,
Sylvain
------------------------------
Message: 20
Date: Thu, 09 Jul 2015 11:25:55 -0400
From: [email protected]
To: George Hadley <[email protected]>
Cc: GNURadio Discussion List <[email protected]>,
[email protected],
[email protected]
Subject: Re: [USRP-users] [Discuss-gnuradio] [UHD] Cause of sequence
errors (SSSSS...) when using USRP N210 as transmitter?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
See Marcus Muellier's reply of earlier.
You need to configure your VM ethernet in bridge, rather than NAT
configuration. VMWare NAT re-orders UDP datagrams, which is fatal for a
number of applications.
On 2015-07-09 10:55, George Hadley wrote:
> UHD version is 3.008.004.
>
> Looking at the connection properties in the Windows Network/Sharing Center, I
> see "Realtek PCIe GBE Family Controller" listed as the ethernet controller.
> Looking at the network settings through the VM, the adapter type "Intel
> PRO/1000 MT Desktop (82540EM) is listed.
>
> Thank you for crossposting and your continued assistance.
> George
>
> On 7/9/2015 10:19 AM, [email protected] wrote:
>
> What version of UHD are you using?
>
> Any idea what ethernet controller is used on that dual-port card?
>
> You'd have to go into windows configuration to determine this, since I think
> that 'lspci' on the VM side will see some kind of emulated network card.
>
> I've taken the liberty of copying this to the usrp-users list, since this is
> more USRP-centric, than GnuRadio-centric.
>
> On 2015-07-09 09:21, George Hadley wrote: I am indeed running inside a VM
> presently. Details below:
>
> Hardware:
> USRP N210 (2x) connected to dual-port gigabit ethernet card:
> http://www.newegg.com/Product/Product.aspx?Item=N82E16833166096 [2]
>
> Software:
> Windows 7 host OS
> VirtualBox VM running Mint Linux 17.1 (Mate Desktop edition)
> Network settings:
> + Adapter enabled and attached to NAT
> + No port forwarding settings defined
>
> It may be noteworthy that the receive operation of the USRPs works as
> expected. Only transmit doesn't appear to be working properly.
>
> Thanks,
> George
>
> On 7/9/2015 9:11 AM, [email protected] wrote:
>
> This is usually due to your network subsystem re-ordering packets, which is
> never supposed to happen but certain
> 1GiGe interfaces, particularly USB ones, do this quite a bit.
>
> Are you running inside a VM?
>
> What kind of network interface do you have?
>
> On 2015-07-09 09:09, George Hadley wrote:
>
> Hello,
>
> I'm working on developing some gnuradio exercises, some of which involve
> using USRP N210 devices as transmitters. When I attempt to run the related
> flowgraphs, I get a stream of sequence errors (S) in the GRC log window.
> Attached are a pair of GRC flowgraphs in which I am getting this error. I
> have tried installing the latest images to the USRPs and updating to the
> latest version of gnuradio available on the github master branch. Can
> somebody please point me to what I'm doing wrong? I've searched around on the
> topic for quite awhile, to no avail.
>
> Thanks,
> George
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
--
George Hadley
ECE Lab Coordinator
Purdue University
--
George Hadley
ECE Lab Coordinator
Purdue University
Links:
------
[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[2] http://www.newegg.com/Product/Product.aspx?Item=N82E16833166096
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150709/57e29cf6/attachment-0001.html>
------------------------------
Message: 21
Date: Thu, 09 Jul 2015 17:26:36 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Urgent Help Needed
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Prabhu,
> I am using USRP E-310. It has an embedded OS.
Exactly! That means that it's not designed to run just any software, but
only the software you specifically compiled for it.
Hence, you typically use a SDK on a PC to compile software for the E310,
and build a filesystem image (to write it to the SD card) from that.
> This device cannot be operated in Network Mode. And because of this
> some we need have the functionality of installing the missing library
> files.
Good approach! The Network Mode is really just a diagnostic tool.
Otherwise, you could buy a B210 for a lot less money to get the same
functionality via USB (minus the better filtering on the E310).
> SCIPY and NUMPY stack of python is heavily needed for some signal
> processing and other math operations if I am writing a python script.
numpy is included in the current release [1]. I think there was so
problem with scipy's support on the arm platform; maybe someone can
comment on that.
> I tried to install the LAPACK library from source but new issues crops
> up saying gfortran command not found.
gfortran is a fortran compiler, LAPACK is implemented in Fortran90.
That's something you very definitely don't want to install on your
embedded platform.
So the solution would be getting Lapack, scipy, and all the tools you
need into your modified SD card image. You need to download the SDK from
[2].
Best regards,
Marcus
[1]
http://files.ettus.com/e3xx_images/e310-release-002/oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.manifest
[2]
http://files.ettus.com/e3xx_images/e310-release-002/oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
h
On 07/09/2015 03:58 PM, prabhu via USRP-users wrote:
> Hi all,
> I am using USRP E-310. It has an embedded OS. But this has very
> limited functions. I am not able to install the SCIPY stack. I am not
> able to complete it because of the warning which says "LAPACK" missing.
> This device does not have package repository similar to other linux
> operating systems. Only way I can install a new package is through
> OPKG which also missing basic libraries.
>
> This device cannot be operated in Network Mode. And because of this
> some we need have the functionality of installing the missing library
> files.
>
> SCIPY and NUMPY stack of python is heavily needed for some signal
> processing and other math operations if I am writing a python script.
>
> I tried to install the LAPACK library from source but new issues crops
> up saying gfortran command not found. If any one faced the same issue
> and have a solution do share with me.
>
>
>
>
>
> *-------------------------------------------------------------------------------------------------------------------------------------
> *
> *Thanks,
>
> *
> *Prabhu Janakaraj*
>
>
>
> _______________________________________________
> 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/20150709/35a291cf/attachment-0001.html>
------------------------------
Message: 22
Date: Thu, 09 Jul 2015 11:32:40 -0400
From: Philip Balister <[email protected]>
To: Marcus M?ller <[email protected]>,
[email protected]
Subject: Re: [USRP-users] Urgent Help Needed
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 07/09/2015 11:26 AM, Marcus M?ller via USRP-users wrote:
> Hi Prabhu,
>> I am using USRP E-310. It has an embedded OS.
> Exactly! That means that it's not designed to run just any software, but
> only the software you specifically compiled for it.
>
> Hence, you typically use a SDK on a PC to compile software for the E310,
> and build a filesystem image (to write it to the SD card) from that.
>
>> This device cannot be operated in Network Mode. And because of this
>> some we need have the functionality of installing the missing library
>> files.
> Good approach! The Network Mode is really just a diagnostic tool.
> Otherwise, you could buy a B210 for a lot less money to get the same
> functionality via USB (minus the better filtering on the E310).
>> SCIPY and NUMPY stack of python is heavily needed for some signal
>> processing and other math operations if I am writing a python script.
> numpy is included in the current release [1]. I think there was so
> problem with scipy's support on the arm platform; maybe someone can
> comment on that.
>
>> I tried to install the LAPACK library from source but new issues crops
>> up saying gfortran command not found.
> gfortran is a fortran compiler, LAPACK is implemented in Fortran90.
> That's something you very definitely don't want to install on your
> embedded platform.
>
> So the solution would be getting Lapack, scipy, and all the tools you
> need into your modified SD card image. You need to download the SDK from
> [2].
I've done some work looking at getting a recipe for Scipy, but haven't
had any luck. I'm also checking with some other guys who were
interested. Our preliminary work suggested the build process is painful.
If I needed scipy, I'd take a shot at building it on the E310. I think
you can use atlas to provide lapack and I think there are some NEON
speed ups there.
Personally, I would use scipy with a desktop PC to prototype my
algorithm and convert to c/c++ for the E310.
Philip
>
> Best regards,
> Marcus
>
> [1]
> http://files.ettus.com/e3xx_images/e310-release-002/oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.manifest
> [2]
> http://files.ettus.com/e3xx_images/e310-release-002/oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
>
> h
>
> On 07/09/2015 03:58 PM, prabhu via USRP-users wrote:
>> Hi all,
>> I am using USRP E-310. It has an embedded OS. But this has very
>> limited functions. I am not able to install the SCIPY stack. I am not
>> able to complete it because of the warning which says "LAPACK" missing.
>> This device does not have package repository similar to other linux
>> operating systems. Only way I can install a new package is through
>> OPKG which also missing basic libraries.
>>
>> This device cannot be operated in Network Mode. And because of this
>> some we need have the functionality of installing the missing library
>> files.
>>
>> SCIPY and NUMPY stack of python is heavily needed for some signal
>> processing and other math operations if I am writing a python script.
>>
>> I tried to install the LAPACK library from source but new issues crops
>> up saying gfortran command not found. If any one faced the same issue
>> and have a solution do share with me.
>>
>>
>>
>>
>>
>> *-------------------------------------------------------------------------------------------------------------------------------------
>> *
>> *Thanks,
>>
>> *
>> *Prabhu Janakaraj*
>>
>>
>>
>> _______________________________________________
>> 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: 23
Date: Thu, 09 Jul 2015 08:57:48 -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
FYI, Mako 0.4.2 works. We also found some other issues with Python 3
which could be fixed. I've updated the public branch accordingly.
Cheers,
Martin
On 07.07.2015 14:38, Martin Braun wrote:
> 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
>>
>
------------------------------
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 9
*****************************************
