Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: E310 compatibility issue (Jason Matusiak)
2. Two RFNoC FFT blocks on X310? (Raj Bhattacharjea)
3. Re: rx_samples_to_file bandwidth does not take effect
(Marcus D. Leech)
4. Re: Two RFNoC FFT blocks on X310? (Jonathon Pendlum)
5. Re: Two RFNoC FFT blocks on X310? (Raj Bhattacharjea)
6. Re: rx_samples_to_file bandwidth does not take effect (olivani)
7. Re: rx_samples_to_file bandwidth does not take effect
(Marcus D. Leech)
8. Re: X300 timing (Jacob Knoles)
9. Re: rx_samples_to_file bandwidth does not take effect (olivani)
10. GPS of the USRPE312 (Alexander cortes Uniandes)
11. Re: GPS of the USRPE312 (Marcus M?ller)
12. Re: GPS of the USRPE312 (Philip Balister)
13. Re: rx_samples_to_file bandwidth does not take effect
(Marcus D. Leech)
14. Re: Exception raised when trying to read FPGA time (Marcus M?ller)
15. Re: Exception raised when trying to read FPGA time
(Felipe Augusto Pereira de Figueiredo)
16. Re: rx_samples_to_file bandwidth does not take effect (olivani)
17. Re: rfnoc-modtool cores (Jason Matusiak)
18. sensors values access when string representation in gnu radio
(LEMENAGER Claude)
19. CVE-2017-9371: Vulnerability in OpenEmbedded (Ben Hilburn)
----------------------------------------------------------------------
Message: 1
Date: Tue, 20 Jun 2017 12:04:15 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] E310 compatibility issue
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Solved my issue again. I needed to remove the link from libuhd.so.3 to
libuhd.so.3.11 and replaced it with libuhd.so.003 (which points to
libuhd.so.003.009)
On 06/20/2017 11:58 AM, Jason Matusiak wrote:
> I am having an E310 compatibility issue that I can't seem to resolve.
> When messing with things earlier in RFNoC, I decided to go back to
> regular UHD for my associates. I cross-compiled UHD and moved it over
> and get this error now:
> root@ettus-e3xx-sg1:~# uhd_usrp_probe
> [INFO] [UHDlinux; GNU C++ version 4.9.2; Boost_105700;
> UHD_3.11.0.git-208-g1da86f9c]
> [INFO] [E300] Loading FPGA image:
> /usr/share/uhd/images/usrp_e310_fpga.bit...
> [INFO] [E300] FPGA image loaded
> [INFO] [E300] Initializing core control...
> [INFO] [E300] Performing register loopback test...
> [INFO] [E300] Register loopback test passed
> Error: RuntimeError: Expected FPGA compatibility number 16.x, but got
> 14.0:
> The FPGA build is not compatible with the host code build.
> Please run:
>
> "/usr/lib/uhd/utils/uhd_images_downloader.py"
>
>
> I want to be running UHD 3.9.2, so I checked out that tag and rebuilt
> things and did an install like this:
> make install DESTDIR=~/E310_remote/home/root/usr/
>
> If I then source set_env, everything is happy again.
>
> I then decided to try to make things permanent and did an install like
> this: make install DESTDIR=~/E310_remote/usr/
>
> Now when I reboot, I get the compatibility errors again. But if I
> source the set_env in /usr, things are happy again. So why isn't this
> getting source automagically since I installed it over /usr?
------------------------------
Message: 2
Date: Tue, 20 Jun 2017 14:39:46 -0400
From: Raj Bhattacharjea <[email protected]>
To: Neel Pandeya <[email protected]>, Martin Braun
<[email protected]>, usrp-users <[email protected]>
Subject: [USRP-users] Two RFNoC FFT blocks on X310?
Message-ID:
<cap3eqjerjcqqm6fbfhpqkjy2hn4x2rtxe_3lvicv_c-cmm1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
We have an application with an X310 where we'd like to have two
daughterboards (both UBX-160) receiving on one X310, and we'd like to do
length 1024 FFTs on these two parallel streams on the FPGA using RFNoC. I'm
not somewhere where I can check what's in the stock image, but is having
two RFNoC FFT blocks (one for each RX chain) supported and will it fit on
the FPGA on the X310 in this configuration? Note I'm willing to take out TX
capabilities from the image.
--
Raj Bhattacharjea
http://www.prism.gatech.edu/~rb288/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170620/125bb050/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 20 Jun 2017 14:57:03 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] rx_samples_to_file bandwidth does not take
effect
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 06/20/2017 11:35 AM, olivani via USRP-users wrote:
> Hi ,
>
> I set a time on 105MHz and collected data with center freqnecy 99 MHz
> at sampling rate 16 Msps and set the bandwidth to 4MHz and collected
> data using rx_samples_to_file in E310 board. When I plotted the data
> , I was able to see the tone which should have not been visible. After
> couple of trials , I understood that rx_samples_to_file collect data
> based on samplerate and the bandwidth specification does not have any
> effect. Has anyone noticed this ...
> Olivani Subbukutty
> 571-331-2481
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Do you get a "Setting Bandwidth" message when the program starts up?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170620/7eceb09f/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 20 Jun 2017 12:10:46 -0700
From: Jonathon Pendlum <[email protected]>
To: Raj Bhattacharjea <[email protected]>
Cc: Neel Pandeya <[email protected]>, Martin Braun
<[email protected]>, usrp-users <[email protected]>
Subject: Re: [USRP-users] Two RFNoC FFT blocks on X310?
Message-ID:
<cagdo0ut9x_1of6ezfrxf27ge3d7hxb7ka-xqqdwlrxeuuae...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
The stock image does not have two FFTs. You can make an image with two of
them in it and it will fit.
Jonathon
On Tue, Jun 20, 2017 at 11:39 AM, Raj Bhattacharjea via USRP-users <
[email protected]> wrote:
> We have an application with an X310 where we'd like to have two
> daughterboards (both UBX-160) receiving on one X310, and we'd like to do
> length 1024 FFTs on these two parallel streams on the FPGA using RFNoC. I'm
> not somewhere where I can check what's in the stock image, but is having
> two RFNoC FFT blocks (one for each RX chain) supported and will it fit on
> the FPGA on the X310 in this configuration? Note I'm willing to take out TX
> capabilities from the image.
>
> --
> Raj Bhattacharjea
> http://www.prism.gatech.edu/~rb288/
>
> _______________________________________________
> 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/20170620/0320f24f/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 20 Jun 2017 15:13:37 -0400
From: Raj Bhattacharjea <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: Neel Pandeya <[email protected]>, Martin Braun
<[email protected]>, usrp-users <[email protected]>
Subject: Re: [USRP-users] Two RFNoC FFT blocks on X310?
Message-ID:
<CAP3eQJcg4NHqru0mO6UDUHROVENhOGD3tcssMM85o=n9mg5...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks!
On Tue, Jun 20, 2017 at 3:10 PM, Jonathon Pendlum <
[email protected]> wrote:
> Hi,
>
> The stock image does not have two FFTs. You can make an image with two of
> them in it and it will fit.
>
> Jonathon
>
> On Tue, Jun 20, 2017 at 11:39 AM, Raj Bhattacharjea via USRP-users <
> [email protected]> wrote:
>
>> We have an application with an X310 where we'd like to have two
>> daughterboards (both UBX-160) receiving on one X310, and we'd like to do
>> length 1024 FFTs on these two parallel streams on the FPGA using RFNoC. I'm
>> not somewhere where I can check what's in the stock image, but is having
>> two RFNoC FFT blocks (one for each RX chain) supported and will it fit on
>> the FPGA on the X310 in this configuration? Note I'm willing to take out TX
>> capabilities from the image.
>>
>> --
>> Raj Bhattacharjea
>> http://www.prism.gatech.edu/~rb288/
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
--
Raj Bhattacharjea
http://www.prism.gatech.edu/~rb288/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170620/5fe017d5/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 20 Jun 2017 15:32:37 -0400
From: olivani <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] rx_samples_to_file bandwidth does not take
effect
Message-ID:
<cabq0vixuwbvg8fox5uglvxeybbzqwjwiov4poirhwz2dc1m...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I did get that message and it says the bandwidth is set . But once you
collect the data and plot it out for example say you have a tone
on 12 MHz and collect data of 10 MHz bandwidth with center 5 MHz freq
and set the clock rate and sampling rate to 16 Msps , when I collect the
data , I am not supposed to see a tone as I assumed the data would be
collected from 0-10 MHz . But it seems that the data bandwidth collected is
equal to the sampling rate and so in the upper edge from 5 to 13 MHz I am
able to see the tone. I tried in different devices and using 3.92 release
code. We did a fpga probe and also noticed the same scenario. So I am
wondering does the sample rate option overrides the analog filter BW option
. Does the bw option has any effect. It would be great if somebody could
help me out with this.
Thanks and Regards,
Olivani Subbukutty
571-331-2481
On Tue, Jun 20, 2017 at 2:57 PM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 06/20/2017 11:35 AM, olivani via USRP-users wrote:
>
> Hi ,
>
> I set a time on 105MHz and collected data with center freqnecy 99 MHz at
> sampling rate 16 Msps and set the bandwidth to 4MHz and collected data
> using rx_samples_to_file in E310 board. When I plotted the data , I was
> able to see the tone which should have not been visible. After couple of
> trials , I understood that rx_samples_to_file collect data based on
> samplerate and the bandwidth specification does not have any effect. Has
> anyone noticed this ...
> Olivani Subbukutty
> 571-331-2481 <(571)%20331-2481>
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> Do you get a "Setting Bandwidth" message when the program starts up?
>
>
>
> _______________________________________________
> 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/20170620/70b67427/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 20 Jun 2017 15:37:28 -0400
From: "Marcus D. Leech" <[email protected]>
To: olivani <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] rx_samples_to_file bandwidth does not take
effect
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 06/20/2017 03:32 PM, olivani wrote:
>
>
> I did get that message and it says the bandwidth is set . But once you
> collect the data and plot it out for example say you have a tone
> on 12 MHz and collect data of 10 MHz bandwidth with center 5 MHz
> freq and set the clock rate and sampling rate to 16 Msps , when I
> collect the data , I am not supposed to see a tone as I assumed the
> data would be collected from 0-10 MHz . But it seems that the data
> bandwidth collected is equal to the sampling rate and so in the upper
> edge from 5 to 13 MHz I am able to see the tone. I tried in different
> devices and using 3.92 release code. We did a fpga probe and also
> noticed the same scenario. So I am wondering does the sample rate
> option overrides the analog filter BW option . Does the bw option has
> any effect. It would be great if somebody could help me out with this.
>
>
Well, it's complex-baseband, so the useful samples go from -bw/2 to +bw/2
Could you perhaps produce an FFT plot to show the artifacts you think
shouldn't be there?
------------------------------
Message: 8
Date: Tue, 20 Jun 2017 13:14:07 -0700
From: Jacob Knoles <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] X300 timing
Message-ID:
<ca+z4yfhz0tivemjuyfzweob4qirrzgxrxwdtyqyvzwg-qey...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey Marcus,
Some details, I need the frequency to hop at a rate of 0.333 kHz or every
3.003 ms. At the same time I am playing a sequence of pulses continuously
so my actual available hopping time is more like 333 microseconds (time
between two pulses).
I am aware of the queue limit and have programmed to accommodate that, I
try to keep no more than 3-5 commands queued up at a time. In my code I am
pre-loading 4 commands, then using boost::this_thread::sleep_for() I have
the thread wait for the 3 ms hop time and loop, adding one more command to
the queue, until all my hop commands have been issued. I have a queue of
all the hop commands set up on the host.
I calculate the command execution time using a reference start time which I
grab from the usrp just before the entire process starts, then offset by
the hop time multiplied by a loop counter.
Thanks.
Jacob
-----------------------------
Jacob Knoles
Compliance Engineer / Software Developer
MiCOM Labs Inc.
Pleasanton, CA
On Sun, Jun 18, 2017 at 12:10 AM, Marcus M?ller via USRP-users <
[email protected]> wrote:
> Hi Jacob,
>
> hm, the timing should not becoming worse, unless at some point, you don't
> get the commands or the samples out to the USRP in time. So, the GPSDO
> shouldn't improve things.
>
> Since the command queue is of limited depth, the latter might be the case.
> What's your hop time, just to give us an order of magnitude?
>
> Best regards,
>
> Marcus
>
> On 06/17/2017 12:08 AM, Jacob Knoles via USRP-users wrote:
>
> Hello,
>
> I am developing a frequency hopper that must transmit a specified number
> of pulses on each frequency, then change frequencies within a short and
> specific window of time.
>
> I am currently achieving this using the timed commands of the X300, I load
> the buffer with frequency tune requests all increasingly offset from a
> reference start point.
>
> For example (pseudo-code):
>
> set usrp time = 0
> reference time = get usrp time
> change frequency at reference time + (hop time * 1)
> change frequency at reference time + (hop time * 2)
> change frequency at reference time + (hop time * 3)
> .... and so on.
>
> Meanwhile in a helper thread I have the tx_streamer that replays the
> pulse sequence the specified number of times.
>
> So far this is working out very well, but I have noticed that with more
> hops, the timing becomes less accurate, there is more time between each
> frequency change.
> And since my ultimate goal is 100 frequency hops this is an issue.
>
> My initial thought is that this could be remedied by utilizing the GPSDO
> option, thus giving the X300 a much better clock source. Could someone
> please confirm this for me as I do not have the GPSDO option.
>
> Or if anyone has any better ideas I am open to suggestions.
>
> Note: I am using the UHD C++ API directly (not using GNU-Radio).
>
> Thanks!
>
> -- Jacob
>
>
> _______________________________________________
> 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/20170620/f0858970/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 20 Jun 2017 16:33:50 -0400
From: olivani <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] rx_samples_to_file bandwidth does not take
effect
Message-ID:
<CABq0ViwDv_5A8uP1bWhygPE=PwYLOPfX7=2ez_cllcxwf1o...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Marcus ,
Please find the attached document along with this mail.
Thanks and Regards,
Olivani Subbukutty
571-331-2481
On Tue, Jun 20, 2017 at 3:37 PM, Marcus D. Leech <[email protected]> wrote:
> On 06/20/2017 03:32 PM, olivani wrote:
>
>>
>>
>> I did get that message and it says the bandwidth is set . But once you
>> collect the data and plot it out for example say you have a tone on 12
>> MHz and collect data of 10 MHz bandwidth with center 5 MHz freq and set
>> the clock rate and sampling rate to 16 Msps , when I collect the data , I
>> am not supposed to see a tone as I assumed the data would be collected from
>> 0-10 MHz . But it seems that the data bandwidth collected is equal to the
>> sampling rate and so in the upper edge from 5 to 13 MHz I am able to see
>> the tone. I tried in different devices and using 3.92 release code. We
>> did a fpga probe and also noticed the same scenario. So I am wondering does
>> the sample rate option overrides the analog filter BW option . Does the bw
>> option has any effect. It would be great if somebody could help me out with
>> this.
>>
>>
>> Well, it's complex-baseband, so the useful samples go from -bw/2 to +bw/2
>
> Could you perhaps produce an FFT plot to show the artifacts you think
> shouldn't be there?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170620/42f11bfd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bandwidth_setting_error.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 71903 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170620/42f11bfd/attachment-0001.docx>
------------------------------
Message: 10
Date: Tue, 20 Jun 2017 16:05:24 -0500
From: Alexander cortes Uniandes <[email protected]>
To: [email protected]
Subject: [USRP-users] GPS of the USRPE312
Message-ID:
<CABLQQRCEu=TiZSaFHym5A-T9NMwpyz6=furgv=4h6jiutri...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello everyone
I am currently working with the USRP E312, but I have not been able to get
a way to access the internal GPS data. I would like someone to please guide
me in the set-up to get the GPS data. I also have the antenna connected to
the USRPE312. When I run the command: uhd_usrp_probe, the following appears:
Linux; GNU C ++ version 4.9.2; Boost_105700; UHD_003.009.002-0-unknown
- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga_sg3.bit ... done
- Detecting internal GPSDO .... found
I appreciate if anyone can help me with the procedure to turn the GPS on
and get the positioning data.
Thank you very much
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170620/7bf4169b/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 20 Jun 2017 23:20:01 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] GPS of the USRPE312
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Just to give you a quick direction to investigate:
Use the GPSD software that ships with it!
Best regards,
Marcus
On 20.06.2017 23:05, Alexander cortes Uniandes via USRP-users wrote:
> Hello everyone
>
> I am currently working with the USRP E312, but I have not been able to
> get a way to access the internal GPS data. I would like someone to
> please guide me in the set-up to get the GPS data. I also have the
> antenna connected to the USRPE312. When I run the command:
> uhd_usrp_probe, the following appears:
>
> Linux; GNU C ++ version 4.9.2; Boost_105700; UHD_003.009.002-0-unknown
>
> - Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga_sg3.bit ...
> done
> - Detecting internal GPSDO .... found
>
> I appreciate if anyone can help me with the procedure to turn the GPS
> on and get the positioning data.
>
> Thank you very much
>
>
> _______________________________________________
> 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/20170620/75b74042/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 20 Jun 2017 17:39:50 -0400
From: Philip Balister <[email protected]>
To: Marcus M?ller <[email protected]>,
[email protected]
Subject: Re: [USRP-users] GPS of the USRPE312
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
You can run cgps on the nuit to check it locks and get status info.
Philip
On 06/20/2017 05:20 PM, Marcus M?ller via USRP-users wrote:
> Just to give you a quick direction to investigate:
>
> Use the GPSD software that ships with it!
>
> Best regards,
>
> Marcus
>
>
> On 20.06.2017 23:05, Alexander cortes Uniandes via USRP-users wrote:
>> Hello everyone
>>
>> I am currently working with the USRP E312, but I have not been able to
>> get a way to access the internal GPS data. I would like someone to
>> please guide me in the set-up to get the GPS data. I also have the
>> antenna connected to the USRPE312. When I run the command:
>> uhd_usrp_probe, the following appears:
>>
>> Linux; GNU C ++ version 4.9.2; Boost_105700; UHD_003.009.002-0-unknown
>>
>> - Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga_sg3.bit ...
>> done
>> - Detecting internal GPSDO .... found
>>
>> I appreciate if anyone can help me with the procedure to turn the GPS
>> on and get the positioning data.
>>
>> Thank you very much
>>
>>
>> _______________________________________________
>> 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: 13
Date: Tue, 20 Jun 2017 22:56:51 -0400
From: "Marcus D. Leech" <[email protected]>
To: olivani <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] rx_samples_to_file bandwidth does not take
effect
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 06/20/2017 04:33 PM, olivani wrote:
> Hi Marcus ,
>
> Please find the attached document along with this mail.
>
> Thanks and Regards,
> Olivani Subbukutty
> 571-331-2481
Could you try running the master clock at 40Msps? With
master==sample-rate, there's not much room to do any digital fitlering.
Also, what levels are the signals entering the device?
>
> On Tue, Jun 20, 2017 at 3:37 PM, Marcus D. Leech <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 06/20/2017 03:32 PM, olivani wrote:
>
>
>
> I did get that message and it says the bandwidth is set . But
> once you collect the data and plot it out for example say you
> have a tone on 12 MHz and collect data of 10 MHz bandwidth
> with center 5 MHz freq and set the clock rate and sampling
> rate to 16 Msps , when I collect the data , I am not supposed
> to see a tone as I assumed the data would be collected from
> 0-10 MHz . But it seems that the data bandwidth collected is
> equal to the sampling rate and so in the upper edge from 5 to
> 13 MHz I am able to see the tone. I tried in different
> devices and using 3.92 release code. We did a fpga probe and
> also noticed the same scenario. So I am wondering does the
> sample rate option overrides the analog filter BW option .
> Does the bw option has any effect. It would be great if
> somebody could help me out with this.
>
>
> Well, it's complex-baseband, so the useful samples go from -bw/2
> to +bw/2
>
> Could you perhaps produce an FFT plot to show the artifacts you
> think shouldn't be there?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170620/d37dc1a1/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 21 Jun 2017 09:14:39 +0200
From: Marcus M?ller <[email protected]>
To: Felipe Augusto Pereira de Figueiredo <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Exception raised when trying to read FPGA
time
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Felipe,
wow! Great debugging :)
A couple of questions arise on my side from this, but I think we've got
a lead here:
You say "AGC thread"; does that imply that you're interacting with the
USRP from multiple threads? While recv() and send() are thread-safe,
that doesn't apply to most UHD functions. What I could imagine happening
here is that setting the RF gain, which is, on a hardware level,
multiple commands, might be "interrupted" by another command, and the
result of that command ends up being handled by the set_*_gain handler,
and that gets confused.
For performance reasons, we do not wrap our functions in mutexes; can
you try to do that, so that you don't tune while your code is still in
another UHD function (and don't call other UHD functions while you tune)?
Best regards,
Marcus
On 06/15/2017 10:52 AM, Felipe Augusto Pereira de Figueiredo wrote:
> Dear Ettus Support Team,
>
> This is an update the my last email. After some more investigation I
> could figure out the reason for the exception is not coming from
> reading the FPGA time (uhd_usrp_get_time_now).
>
> The issue we have been facing seems to be related to the UHD driver.
> We have an AGC thread that constantly tries to automatically adapt the
> RX Gain. For that purpose, the AGC thread changes the RX Gain whenever
> it is necessary, however, sometimes the application crashes with the
> following exception:
>
>
> *terminate called after throwing an instance of 'std::length_error'
> what(): basic_string::_S_create*
>
>
> I've googled for that exception and the information I've got is that
> it happens when trying to create a string bigger than
> *std::string::max_size()*.
>
>
> My code is written in C and I don't use strings except the ones used
> by the UHD driver once that code was written in C++.
>
>
> I have been hunting down the source of the exception and figured out
> it might be coming from the UHD library. I used gdb with the following
> commands:
>
> *set pagination off
> catch throw
> commands
> backtrace
> continue
> end
> run*
>
> After running my application with GDB I've got the following stack
> trace when the exception happens:
>
> --------------------------------------------------------------------------------------------
>
> Catchpoint 1 (exception thrown), 0x00007ffff2b6d8b0 in __cxa_throw ()
> from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>
> #0 0x00007ffff2b6d8b0 in __cxa_throw () from
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>
> #1 0x00007ffff2bbf3a7 in std::__throw_length_error(char const*) ()
> from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>
> #2 0x00007ffff2bc9262 in std::string::_Rep::_S_create(unsigned long,
> unsigned long, std::allocator<char> const&) () from
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>
> #3 0x00007ffff2bc93d6 in std::string::_M_mutate(unsigned long,
> unsigned long, unsigned long) () from
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>
> #4 0x00007ffff36b5e1e in uhd_usrp_set_rx_gain () from
> /usr/local/lib/libuhd.so.3
>
> #5 0x00007ffff4ee6a20 in rf_uhd_set_rx_gain (h=0x7cbce0,
> gain=631,56964111328125) at
> /home/zz4fap/imec/scatter/phy/srslte/lib/rf/rf_uhd_imp.c:507
>
> #6 0x00007ffff4ee52e7 in thread_gain_fcn (h=0x654740 <rf>) at
> /home/zz4fap/imec/scatter/phy/srslte/lib/rf/rf_imp.c:72
>
> #7 0x00007ffff4c75184 in start_thread (arg=0x7fffe6ffd700) at
> pthread_create.c:312
>
> #8 0x00007ffff4410bed in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
>
> terminate called after throwing an instance of 'std::length_error'
>
> what(): basic_string::_S_create
>
>
>
> Program received signal SIGABRT, Aborted.
>
> 0x00007ffff4349c37 in __GI_raise (sig=sig@entry=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
>
> 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>
> (gdb) quit
>
> A debugging session is active.
>
> --------------------------------------------------------------------------------------------
>
>
> As you can see, the exception happens after the application tries to
> call the UHD function: "uhd_usrp_set_rx_gain".
> I have done some modifications to the UHD code and so far I couldn't
> spot the crash anymore. Basically what I've done is to add try/catch
> statements to get that exception and try to understand the root cause.
> You will find the files I've modified enclosed to this email. Apart
> from adding try/catch I've done the following modifications that I
> think could impact:
> 1) In file: host/lib/usrp/multi_usrp.cpp I commented out "catch
> (uhd::key_error &)" and added a catch for all exceptions
> + } catch (...) {
> + //} catch (uhd::key_error &) {
> 2) In file: host/lib/usrp/usrp_c.cpp I removed the use of
> "UHD_SAFE_C_SAVE_ERROR" and added a try/catch.
> - UHD_SAFE_C_SAVE_ERROR(h,
> +
> + try {
> + std::string name(gain_name);
> + if(name.empty()){
> + USRP(h)->set_rx_gain(gain, chan);
> + }
> + else{
> + USRP(h)->set_rx_gain(gain, name, chan);
> + }
> + } catch(...) {
> + std::cout << "OMG!!! An exsception" << std::endl;
> + exit(-1);
> + }
> +
> +return UHD_ERROR_NONE;
> +
> +/* UHD_SAFE_C_SAVE_ERROR(h,
> std::string name(gain_name);
> if(name.empty()){
> USRP(h)->set_rx_gain(gain, chan);
> @@ -952,6 +968,7 @@ uhd_error uhd_usrp_set_rx_gain(
> USRP(h)->set_rx_gain(gain, name, chan);
> }
> )
> +*/
> That crash was happening very often without my modifications and now,
> with these modifications, I haven't been able to reproduce the crash
> anymore.
> Could you help me trying to understand the root cause for that issue,
> please? I wouldn't like to keep those changes to the UHD code without
> knowing the real reason for crash.
> Many Thanks and Kind Regards, Felipe Augusto
>
> On Tue, Jun 13, 2017 at 11:45 AM, Felipe Augusto Pereira de Figueiredo
> <[email protected] <mailto:[email protected]>> wrote:
>
> Dear Folks,
> I've got a piece of code where I read the FPGA time and use that
> information as a timestamp on a message I send to another
> application. I'm using the following function:
> uhd_usrp_get_time_now(handler, 0, secs, frac_secs);
> After sometime I've got the following exception:
> terminate called after throwing an instance of 'std::length_error'
> what(): basic_string::_S_create
> I was hard to figure out where that exception was coming from.
> I've added a lot of printfs to my code until I found it was
> happening when I tried to read the FPGA timestamp.
> Could you tell me why that happens and how to solve it, please?
> I've got a B200 and UHD driver [INFO] [UHDlinux; GNU C++ version
> 4.8.4; Boost_105400; UHD_3.11.0.git-208-g1da86f9c]
> Thanks and Kind Regards,
> Felipe Augusto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170621/d9536ed4/attachment-0001.html>
------------------------------
Message: 15
Date: Wed, 21 Jun 2017 09:30:41 +0200
From: Felipe Augusto Pereira de Figueiredo <[email protected]>
To: Ettus Research Support <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Exception raised when trying to read FPGA
time
Message-ID:
<ca+abmwkvmocuq6+nw5qq762ob7eohym4hjdamkfajro99tc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Marcus,
Thanks for your reply. My answers follows inline.
Thanks again and Kind Regards,
Felipe Augusto
On Wed, Jun 21, 2017 at 8:50 AM, Ettus Support - Marcus M?ller <support@
ettus.com> wrote:
> Hi Felipe,
>
> wow! Great debugging :)
>
> A couple of questions arise on my side from this, but I think we've got a
> lead here:
>
> You say "AGC thread"; does that imply that you're interacting with the
> USRP from multiple threads? While recv() and send() are thread-safe, that
> doesn't apply to most UHD functions. What I could imagine happening here is
> that setting the RF gain, which is, on a hardware level, multiple commands,
> might be "interrupted" by another command, and the result of that command
> ends up being handled by the set_*_gain handler, and that gets confused.
>
*Yes, I have two threads and only two. One running transmission and
reception procedures (i.e., recv() and send()) and the other one only for
AGC things like calculating a gain and then applying it to the RX chain
through uhd_usrp_set_rx_gain().*
>
> For performance reasons, we do not wrap our functions in mutexes; can you
> try to do that, so that you don't tune while your code is still in another
> UHD function (and don't call other UHD functions while you tune)?
>
*Yes, I can try to do that I just don't understand what do you mean by
"don't call other UHD functions while you tune". By that do you mean I
should check if there is other function like recv() and send() before
setting the RX gain through uhd_usrp_set_rx_gain()?*
> Best regards,
>
> Marcus
> On 06/15/2017 10:52 AM, Felipe Augusto Pereira de Figueiredo wrote:
>
> Dear Ettus Support Team,
>
> This is an update the my last email. After some more investigation I could
> figure out the reason for the exception is not coming from reading the FPGA
> time (uhd_usrp_get_time_now).
>
> The issue we have been facing seems to be related to the UHD driver. We
> have an AGC thread that constantly tries to automatically adapt the RX
> Gain. For that purpose, the AGC thread changes the RX Gain whenever it is
> necessary, however, sometimes the application crashes with the following
> exception:
>
>
>
> *terminate called after throwing an instance of 'std::length_error'
> what(): basic_string::_S_create*
>
>
> I've googled for that exception and the information I've got is that it
> happens when trying to create a string bigger than
> *std::string::max_size()*.
>
>
> My code is written in C and I don't use strings except the ones used by
> the UHD driver once that code was written in C++.
>
>
> I have been hunting down the source of the exception and figured out it
> might be coming from the UHD library. I used gdb with the following
> commands:
>
>
>
>
>
>
> *set pagination off catch throw commands backtrace continue end run*
>
> After running my application with GDB I've got the following stack trace
> when the exception happens:
>
> ------------------------------------------------------------
> --------------------------------
>
> Catchpoint 1 (exception thrown), 0x00007ffff2b6d8b0 in __cxa_throw () from
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>
> #0 0x00007ffff2b6d8b0 in __cxa_throw () from
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>
> #1 0x00007ffff2bbf3a7 in std::__throw_length_error(char const*) () from
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>
> #2 0x00007ffff2bc9262 in std::string::_Rep::_S_create(unsigned long,
> unsigned long, std::allocator<char> const&) () from
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>
> #3 0x00007ffff2bc93d6 in std::string::_M_mutate(unsigned long, unsigned
> long, unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>
> #4 0x00007ffff36b5e1e in uhd_usrp_set_rx_gain () from
> /usr/local/lib/libuhd.so.3
>
> #5 0x00007ffff4ee6a20 in rf_uhd_set_rx_gain (h=0x7cbce0,
> gain=631,56964111328125) at /home/zz4fap/imec/scatter/phy/
> srslte/lib/rf/rf_uhd_imp.c:507
>
> #6 0x00007ffff4ee52e7 in thread_gain_fcn (h=0x654740 <rf>) at
> /home/zz4fap/imec/scatter/phy/srslte/lib/rf/rf_imp.c:72
>
> #7 0x00007ffff4c75184 in start_thread (arg=0x7fffe6ffd700) at
> pthread_create.c:312
>
> #8 0x00007ffff4410bed in clone () at ../sysdeps/unix/sysv/linux/x86
> _64/clone.S:111
>
> terminate called after throwing an instance of 'std::length_error'
>
> what(): basic_string::_S_create
>
>
>
> Program received signal SIGABRT, Aborted.
>
> 0x00007ffff4349c37 in __GI_raise (sig=sig@entry=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
>
> 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>
> (gdb) quit
>
> A debugging session is active.
>
> ------------------------------------------------------------
> --------------------------------
>
> As you can see, the exception happens after the application tries to call
> the UHD function: "uhd_usrp_set_rx_gain".
> I have done some modifications to the UHD code and so far I couldn't spot
> the crash anymore. Basically what I've done is to add try/catch statements
> to get that exception and try to understand the root cause. You will find
> the files I've modified enclosed to this email. Apart from adding try/catch
> I've done the following modifications that I think could impact:
> 1) In file: host/lib/usrp/multi_usrp.cpp I commented out "catch
> (uhd::key_error &)" and added a catch for all exceptions
> + } catch (...) {
> + //} catch (uhd::key_error &) {
> 2) In file: host/lib/usrp/usrp_c.cpp I removed the use of
> "UHD_SAFE_C_SAVE_ERROR" and added a try/catch.
> - UHD_SAFE_C_SAVE_ERROR(h,
> +
> + try {
> + std::string name(gain_name);
> + if(name.empty()){
> + USRP(h)->set_rx_gain(gain, chan);
> + }
> + else{
> + USRP(h)->set_rx_gain(gain, name, chan);
> + }
> + } catch(...) {
> + std::cout << "OMG!!! An exsception" << std::endl;
> + exit(-1);
> + }
> +
> +return UHD_ERROR_NONE;
> +
> +/* UHD_SAFE_C_SAVE_ERROR(h,
> std::string name(gain_name);
> if(name.empty()){
> USRP(h)->set_rx_gain(gain, chan);
> @@ -952,6 +968,7 @@ uhd_error uhd_usrp_set_rx_gain(
> USRP(h)->set_rx_gain(gain, name, chan);
> }
> )
> +*/
> That crash was happening very often without my modifications and now, with
> these modifications, I haven't been able to reproduce the crash anymore.
> Could you help me trying to understand the root cause for that issue,
> please? I wouldn't like to keep those changes to the UHD code without
> knowing the real reason for crash.
> Many Thanks and Kind Regards, Felipe Augusto
>
> On Tue, Jun 13, 2017 at 11:45 AM, Felipe Augusto Pereira de Figueiredo <
> [email protected]> wrote:
>>
>> Dear Folks,
>> I've got a piece of code where I read the FPGA time and use that
>> information as a timestamp on a message I send to another application. I'm
>> using the following function:
>> uhd_usrp_get_time_now(handler, 0, secs, frac_secs);
>> After sometime I've got the following exception:
>> terminate called after throwing an instance of 'std::length_error'
>> what(): basic_string::_S_create
>> I was hard to figure out where that exception was coming from. I've added
>> a lot of printfs to my code until I found it was happening when I tried to
>> read the FPGA timestamp.
>> Could you tell me why that happens and how to solve it, please?
>> I've got a B200 and UHD driver [INFO] [UHDlinux; GNU C++ version 4.8.4;
>> Boost_105400; UHD_3.11.0.git-208-g1da86f9c]
>> Thanks and Kind Regards,
>> Felipe Augusto
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170621/5b5b265a/attachment-0001.html>
------------------------------
Message: 16
Date: Wed, 21 Jun 2017 09:23:54 -0400
From: olivani <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] rx_samples_to_file bandwidth does not take
effect
Message-ID:
<CABq0ViyiRuQPYrSxDWLBjxaAnu1LKWGQA8miC6zhgxFUkg=k...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Marcus,
I tried with master clock at 40 Msps but I am still able to see the tone.
Please have a look at the attached document.
The incoming signal is -27.3 dbm .
Thanks and Regards,
Olivani Subbukutty
571-331-2481
On Tue, Jun 20, 2017 at 10:56 PM, Marcus D. Leech <[email protected]> wrote:
> On 06/20/2017 04:33 PM, olivani wrote:
>
> Hi Marcus ,
>
> Please find the attached document along with this mail.
>
> Thanks and Regards,
> Olivani Subbukutty
> 571-331-2481 <(571)%20331-2481>
>
> Could you try running the master clock at 40Msps? With
> master==sample-rate, there's not much room to do any digital fitlering.
>
> Also, what levels are the signals entering the device?
>
>
>
> On Tue, Jun 20, 2017 at 3:37 PM, Marcus D. Leech <[email protected]>
> wrote:
>
>> On 06/20/2017 03:32 PM, olivani wrote:
>>
>>>
>>>
>>> I did get that message and it says the bandwidth is set . But once you
>>> collect the data and plot it out for example say you have a tone on 12
>>> MHz and collect data of 10 MHz bandwidth with center 5 MHz freq and set
>>> the clock rate and sampling rate to 16 Msps , when I collect the data , I
>>> am not supposed to see a tone as I assumed the data would be collected from
>>> 0-10 MHz . But it seems that the data bandwidth collected is equal to the
>>> sampling rate and so in the upper edge from 5 to 13 MHz I am able to see
>>> the tone. I tried in different devices and using 3.92 release code. We
>>> did a fpga probe and also noticed the same scenario. So I am wondering does
>>> the sample rate option overrides the analog filter BW option . Does the bw
>>> option has any effect. It would be great if somebody could help me out with
>>> this.
>>>
>>>
>>> Well, it's complex-baseband, so the useful samples go from -bw/2 to +bw/2
>>
>> Could you perhaps produce an FFT plot to show the artifacts you think
>> shouldn't be there?
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170621/1103839b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rx_samples_to_file_bandwidth_error.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 22139 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170621/1103839b/attachment-0001.docx>
------------------------------
Message: 17
Date: Wed, 21 Jun 2017 09:45:43 -0400
From: Jason Matusiak <[email protected]>
To: EJ Kreinar <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] rfnoc-modtool cores
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
EJ, How did you add more than one repo to the line?
~Jason
On 06/14/2017 08:43 PM, EJ Kreinar wrote:
> Yes, this is an admitted hack, I should say.
>
> The assignment to MY_OOT_DIR := OOT_DIR in the
> rfnoc-ootexample/rfnoc/Makefile.inc forces the evaluation of OOT_DIR
> immediately, and the OOT modules uses MY_OOT_DIR from then on, for
> example. I've tested this successfully with multiple different OOT repos.
>
> If you have a suggested improvement that's less hacky though, I'm
> definitely interested :)
>
> EJ
>
> On Wed, Jun 14, 2017 at 2:08 PM, Jason Matusiak
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> EJ,
> I am creating a new RFNoC repo and thought I would go through your
> write up and see if I can find anything that we missed while you
> and I were working offline. The first thing I wondered was, in
> the Makefile.OOT.inc, can I have more than one OOT_DIR? I have
> one in there right now for my current blocks, but I am not sure
> how to point to a different folder without screwing your setup up.
>
> ~Jason
>
>
> On 05/23/2017 10:04 PM, EJ Kreinar wrote:
>> Hi Jason and others,
>>
>> As a follow up, I put together an rfnoc OOT repo that uses
>> Makefiles to build Vivado IP and HLS IP:
>> https://github.com/ejk43/rfnoc-ootexample
>> <https://github.com/ejk43/rfnoc-ootexample>
>>
>> The simulations should run successfully when uhd-fpga is set up
>> correctly (see readme), and also should build the OOT noc_blocks
>> into an FPGA image using "make E310_RFNOC" etc etc.
>>
>> Hope this helps,
>> EJ
>>
>> On Fri, May 19, 2017 at 12:08 PM, EJ Kreinar <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Jason,
>>
>> Sure, I'd say just clone my fpga repo and apply the patch for
>> now. Quick instructions:
>>
>> 1. In your uhd-fpga repo: `git remote add ejk
>> https://github.com/ejk43/fpga.git`
>> <https://github.com/ejk43/fpga.git>
>> a. This now sets up a remote named "ejk" which points to
>> my fork
>> 2. Then: `git fetch ejk new_oot_includes`
>> 3. Then you can either checkout this branch (if you have no
>> other changes on your uhd-fpga repo), or cherry-pick the
>> commits from the new_oot_includes branch.
>>
>>
>> In lieu of an example OOT repo, here's how I set up my
>> "rfnoc" folder structure in the OOT repo:
>>
>> rfnoc:
>> + Makefile.inc
>> + blocks
>> + testbenches
>> + fpga-src
>> + Makefile.inc
>>
>> + noc_block_testblock.v
>>
>> + ip
>> + Makefile.inc
>> + my_ip
>> + my_ip.xci
>> + Makefile.inc
>>
>>
>>
>> Here's an example top-level Makefile.inc:
>>
>> RFNOC_MYTEST_DIR := $(OOT_DIR)
>> include $(abspath $(RFNOC_MYTEST_DIR)/fpga-src/Makefile.inc)
>> include $(abspath $(RFNOC_MYTEST_DIR)/ip/Makefile.inc)
>>
>>
>>
>> Then the fpga-src Makefile.inc:
>>
>> RFNOC_OOT_SRCS += $(addprefix
>> $(RFNOC_MYTEST_DIR)/fpga-src/, \
>> noc_block_testblock.v \
>> )
>>
>>
>>
>> Then the IP Makefile.inc (modeled after the Makefile.inc in
>> the uhd-fpga/usrp3/lib/ip:
>>
>> include $(RFNOC_MYTEST_DIR)/ip/my_ip/Makefile.inc
>>
>> LIB_MYTEST_IP_XCI_SRCS = \
>> $(LIB_IP_MY_IP_SRCS)
>>
>> LIB_MYTEST_IP_SYNTH_OUTPUTS = \
>> $(LIB_IP_MY_IP_OUTS)
>>
>> LIB_IP_XCI_SRCS += $(LIB_MYTEST_IP_XCI_SRCS)
>>
>>
>>
>> And finally, the Makefile.inc inside the my_ip directory
>> (modeled after the lib/ip/xxx Makefile.inc):
>>
>> include $(TOOLS_DIR)/make/viv_ip_builder.mak
>>
>> LIB_IP_MY_IP_SRCS = $(IP_BUILD_DIR)/my_ip/my_ip.xci
>>
>> LIB_IP_MY_IP_OUTS = $(addprefix $(IP_BUILD_DIR)/my_ip/, \
>> my_ip.xci.out \
>> synth/my_ip.vhd \
>> )
>>
>> $(LIB_IP_MY_IP_SRCS) $(LIB_IP_MY_IP_OUTS) :
>> $(LIB_IP_DIR)/my_ip/my_ip.xci
>> $(call
>>
>> BUILD_VIVADO_IP,my_ip,$(ARCH),$(PART_ID),$(LIB_IP_DIR),$(IP_BUILD_DIR),0)
>>
>>
>>
>> It's also possible to rejigger the testbench makefiles to
>> build the OOT IP for your testbench.
>>
>> Again, I should pull this into an example OOT repo sometime
>> soon, which would make it a bit easier to have an example.
>> Let me know if you hit any problems.
>>
>> EJ
>>
>> On Fri, May 19, 2017 at 8:38 AM, Jason Matusiak
>> <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> EJ, that looks exactly like what I need to do. Is there a
>> way for me to patch in your changes so I can try to use
>> them while we wait for Ettus to (dis)approve your PR?
>>
>> Thanks!
>> ~Jason
>>
>>
>>
>> On 05/18/2017 04:11 PM, EJ Kreinar wrote:
>>> Hi Jason,
>>>
>>> I currently have a PR in to the fpga repo
>>> (https://github.com/EttusResearch/fpga/pull/12
>>> <https://github.com/EttusResearch/fpga/pull/12>) that
>>> adds support for linking Makefile.inc files in OOT
>>> repos. Your OOT Makefile can then build the Xilinx IP
>>> and append it to your build as needed. I've been using
>>> this approach for some time now with success for both
>>> Xilinx IP and HLS designs.
>>>
>>> I have an action to provide a sample "dummy" OOT repo
>>> with the correct Makefiles-- but I havent gotten to it
>>> yet, unfortunately-- Was waiting for confirmation if
>>> this approach will be supported in-tree in the future. I
>>> could put something together soon though if this would help.
>>>
>>> I'd also be interested in other good solutions, if
>>> anyone has an alternate approach :)
>>>
>>> EJ
>>>
>>> On Thu, May 18, 2017 at 2:22 PM, Jason Matusiak via
>>> USRP-users <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> I wanted to create an RFNoC block that utilized some
>>> Xilinx cores. Where do I need to put these cores in
>>> the rfnoc-modtool project created directory
>>> structure, and how do I go about tying that into the
>>> Vivado GUI so I can build them up (just use the
>>> GUI=1 CL argument and do the save-as project approach?)?
>>>
>>> _______________________________________________
>>> 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/20170621/c18b4829/attachment-0001.html>
------------------------------
Message: 18
Date: Wed, 21 Jun 2017 16:23:09 +0200
From: LEMENAGER Claude <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] sensors values access when string representation
in gnu radio
Message-ID:
<59957d668d245c4eb38e8f85c054e90112dad7b...@thsonea01cms09p.one.grp>
Content-Type: text/plain; charset="iso-8859-1"
Some additional information:
GR 3.7.12, UHD 3.11.0 BOOST 1.58
Public members (type, value...) are available when accessors (.to_bool(),
.to_pp_string()...) make python to fail.
Claude
Hello,
Developing a control box under gnu radio, the sensor_value_t type seems not
defined in.
I have seen usage of boost bind() to recover lock (get_mboard_sensor()) in
USRP_SINK impl but what when I want to obtain gpgga message (e.g. to set the
system time or issue timed commands)
Thanks for support
Claude Lem?nager
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170621/26ee78b9/attachment-0001.html>
------------------------------
Message: 19
Date: Wed, 21 Jun 2017 10:44:43 -0400
From: Ben Hilburn <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] CVE-2017-9371: Vulnerability in OpenEmbedded
Message-ID:
<CAOEVZkK07bpU5SxyKm3RqrKxfC=Es9SQ=r8xxhcjwfheks+...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all -
On Monday (June 19th), the OpenEmbedded project shared
<http://lists.openembedded.org/pipermail/openembedded-architecture/2017-June/000638.html>
that a security vulnerability has been reported for OE-Core. If you are an
USRP E-Series user that is building binary ipkgs which you then distribute
to your customers, you may be affected by this issue. No other workflows
are impacted.
The vulnerability is documented as CVE-2017-9731
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-9731>. The issue is
that information in the `SRC_URI` for software repositories used by OE
recipes is ?leaked? by binary ipkgs. For example, if you are using the
E-Series OE-generated SDK to build binary ipkgs, and the URI you use for
your source code repository contains sensitive information (examples: `
https://github.com/company-name/secret-project-name`, or `
local-server.internal.com?USER=admin?PASSWORD=password`), that information
will be leaked in the `Source:` field of the ipkg.
The OpenEmbedded team has merged a fix for this into OE-Core `master`, and
backported the change to previous versions of OpenEmbedded. Generally,
including sensitive information in the `SRC_URI`s is not a good idea, and
we highly recommend users avoid doing this in their build process. Some
recommendations provided on the OpenEmbedded discussion list:
- Use non-confidential path names (i.e., don?t include confidential
customer or project names in build paths).
- Change or manage the host name of your build system so that it is
non-confidential, like `build-1` instead of `
secret-product.my-company.internal.com`.
- Use a ?build user? who does not have network credentials to access
sensitive machines during the build process.
If you have questions about this, or need help determining if this issue
affects you, please let us know by contacting [email protected].
Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170621/83b2c72f/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 82, Issue 20
******************************************
