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. time sync 2 ettus x310 (Sanjoy Basak)
2. about time sync of 2 x310 (Sanjoy Basak)
3. Re: sample shift on x310 two channel synchronized receive (Sanjoy)
4. Ettus B200 ADS-B on Windows? (Paul B)
5. New to USRP Application (Deshpande, Manohar D. (GSFC-5550))
6. Re: Ettus B200 ADS-B on Windows? (Nick Foster)
7. Re: New to USRP Application (Mike McLernon)
8. Re: New to USRP Application (Neel Pandeya)
9. Re: UHD: What do the tx_metadata_t burst parameters mean?
(Martin Braun)
10. Re: [Discuss-gnuradio] New UHD seems to break a lot...
(Ian Buckley)
11. Re: Ettus B200 ADS-B on Windows? (Paul B)
12. Re: Ettus B200 ADS-B on Windows? (Nick Foster)
13. Re: Overrun on 56MHz with B210 (Martin Braun)
14. Re: Ettus B200 ADS-B on Windows? (Paul B)
15. Re: Overrun on 56MHz with B210 (Sylvain Munaut)
16. Re: [Discuss-gnuradio] New UHD seems to break a lot...
(Ralph A. Schmid, dk5ras)
17. Re: [UHD-3.8.3] Release Announcement (Martin Braun)
18. maint, master and auto clock rates (Martin Braun)
19. Re: maint, master and auto clock rates (John Ackermann N8UR)
20. Re: USRP UHD Library Release suggestion (hossein talaiee)
21. Subdevice Spec on X300 (John Malsbury)
22. Re: Subdevice Spec on X300 (Martin Braun)
23. Re: The FPGA build is not compatible with the host code build
(Martin Braun)
24. Re: time sync 2 ettus x310 (Martin Braun)
25. Real-time streaming input (???)
26. Announcing NEWSDR at WPI on Thr/Fri May 21/22 (Neel Pandeya)
27. Re: time sync 2 ettus x310 (Sanjoy Basak)
28. Re: Latency Through RF NoC on X310 (Johnathan Rodgers)
29. Re: ZPU Interrupt Service Routine(ISR) (Neel Pandeya)
----------------------------------------------------------------------
Message: 1
Date: Fri, 17 Apr 2015 15:00:17 +0200
From: Sanjoy Basak <[email protected]>
To: [email protected]
Subject: [USRP-users] time sync 2 ettus x310
Message-ID:
<cajpq1a11kcoyez6vj0z_rpqa35wmysk8hrn-ck4uacx4qj6...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I am trying to sync 2 ettus x310 in time. However, I am always having a
distortion at the beginning after receiving, and there is always a delay of
few microseconds between the tx and rx. I put tx in one x310 and rx in
another x310 and its in a wired connection. GPS antenna is connected
to one usrp(with
Tx) and another one is on external ref(Rx).
So now if I check the last pps on both usrp; it shows tx:0; rx:2s;
then I am compensating it making it set_start_time both at for 4s. So
ideally I should get time synced tx and rx signal.
But I am getting distortion in Rx signal for 2seconds at the beginning;
this is constant for every sampling freq; so if in that region I have my rx
signal I can't retrieve that as the distortion is already introduced there.
As I am trying to implement radar with x310, this is a serious problem for
me. As within first 2 seconds and few microseconds I can't receive anything.
I would really appreciate any kind of suggestion that come through. If
anyone have question regarding setup or python code please ask.
Thanks for reading.
Best regards
Sanjoy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150417/e7052139/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 17 Apr 2015 21:00:31 +0200
From: Sanjoy Basak <[email protected]>
To: [email protected]
Subject: [USRP-users] about time sync of 2 x310
Message-ID:
<cajpq1a2mstvspvl0xpqyj+yw7kyayb_ik4ymd6zrdd7zzek...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I am trying to sync 2 ettus x310 in time. However, I am always having a
distortion at the beginning after receiving, and there is always a delay
of few microseconds between the tx and rx. I put tx in one x310 and rx
in another x310 and its in a wired connection. GPS antenna is connected
to one usrp(with Tx) and another one is on external ref(Rx).
So now if I check the last pps on both usrp; it shows tx:0; rx:2s;
then I am compensating it making it set_start_time both at for 4s. So
ideally I should get time synced tx and rx signal.
But I am getting distortion in Rx signal for 2seconds at the beginning;
this is constant for every sampling freq; so if in that region I have my
rx signal I can't retrieve that as the distortion is already introduced
there.
I am using binary file for transmitting and also for receiving and doing
processing in matlab.
As I am trying to implement radar with x310, this is a serious problem
for me. As within first 2 seconds and few microseconds I can't receive
anything.
I would really appreciate any kind of suggestion that come through. If
you have any question regarding setup or python code please ask.
Thanks for reading.
best regards
Sanjoy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150417/8d25f80c/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 17 Apr 2015 20:50:31 +0000 (UTC)
From: Sanjoy <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] sample shift on x310 two channel
synchronized receive
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi all,
I am stating the actual problem here.
I am trying to sync 2 ettus x310 in time. However, I am always having a
distortion at the beginning after receiving, and there is always a delay
of few microseconds between the tx and rx. I put tx in one x310 and rx
in another x310 and its in a wired connection. GPS antenna is connected
to one usrp(with Tx) and another one is on external ref(Rx).
So now if I check the last pps on both usrp; it shows tx:0; rx:2s;
then I am compensating it making it set_start_time both at for 4s. So
ideally I should get time synced tx and rx signal.
But I am getting distortion in Rx signal for 2seconds at the beginning;
this is constant for every sampling freq; so if in that region I have my
rx signal I can't retrieve that as the distortion is already introduced
there.
I am using binary file for transmitting and also for receiving and doing
processing in matlab.
As I am trying to implement radar with x310, this is a serious problem
for me. As within first 2 seconds and few microseconds I can't receive
anything.
I would really appreciate any kind of suggestion that come through. If
you have any question regarding setup or python code please ask.
Thanks for reading.
best regards
Sanjoy
------------------------------
Message: 4
Date: Sun, 19 Apr 2015 16:24:50 +0100
From: Paul B <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Ettus B200 ADS-B on Windows?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi there,
First time i?ve posted here, but i could do with a little bit of help/advice.
I recently got a B200 and i?ve managed to get it working fine in Windows 8.1
with HDSDR and SDR#. I do enjoy decoding ADS-B and used to use my RTL Dongle to
do so before buying my B200.
I?ve tried to find a way to do this using the B200 on Windows, but i just can?t
seem to find anything that?ll do the job. Is there anything i?d be able to use
to decode ADS-B on Windows, or am i
going to have to try and get my B200 working on Linux? (I?ve tried for 3 days
now and can?t get it working on my vmware Ubuntu install)
Any advice would be greatly appreciated,
Thanks,
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150419/3724fbfc/attachment-0001.html>
------------------------------
Message: 5
Date: Sun, 19 Apr 2015 18:03:51 +0000
From: "Deshpande, Manohar D. (GSFC-5550)"
<[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] New to USRP Application
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
I am new to USRP devices and their programing using either GRC, Matlab , or
LabVIEW. I have USRP, USRP 2, USRPN210 devices, I would like to program them
to perform simple RF recording (I & Q data) . I sincerely appreciate receiving
guidance to start.
Thanks
MD
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150419/34d04d76/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 20 Apr 2015 09:19:22 -0700
From: Nick Foster <[email protected]>
To: Paul B <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Ettus B200 ADS-B on Windows?
Message-ID:
<ca+jmmq_3ssss4d3xkfeemh3a3y8hn57ttzdhqq2xve5ljhd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
If you get Gnuradio and UHD installed, gr-air-modes works just fine on
Windows and, of course, with the B200. Do you have specific problems with
your Linux install you'd like to ask about? Seems like it might be
something this list can help with.
--n
On Sun, Apr 19, 2015 at 8:24 AM, Paul B via USRP-users <
[email protected]> wrote:
> Hi there,
>
> First time i?ve posted here, but i could do with a little bit of
> help/advice.
> I recently got a B200 and i?ve managed to get it working fine in Windows
> 8.1 with HDSDR and SDR#. I do enjoy decoding ADS-B and used to use my RTL
> Dongle to do so before buying my B200.
> I?ve tried to find a way to do this using the B200 on Windows, but i just
> can?t seem to find anything that?ll do the job. Is there anything i?d be
> able to use to decode ADS-B on Windows, or am i
> going to have to try and get my B200 working on Linux? (I?ve tried for 3
> days now and can?t get it working on my vmware Ubuntu install)
>
> Any advice would be greatly appreciated,
> Thanks,
>
> Paul
>
> _______________________________________________
> 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/20150420/32bf741d/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 20 Apr 2015 16:24:43 +0000
From: Mike McLernon <[email protected]>
To: "Deshpande, Manohar D. (GSFC-5550)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] New to USRP Application
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi MD,
If you have the Communications System Toolbox from MathWorks, you can perform a
free download of a USRP support package to enable connectivity between your
USRP2 and N210 devices. (Support for USRP1 is not available from MathWorks.)
You can go to http://www.mathworks.com/hardware-support/usrp.html to find
information about the support package.
Best,
Mike
From: USRP-users [mailto:[email protected]] On Behalf Of
Deshpande, Manohar D. (GSFC-5550) via USRP-users
Sent: Sunday, April 19, 2015 2:04 PM
To: [email protected]
Subject: [USRP-users] New to USRP Application
Hi,
I am new to USRP devices and their programing using either GRC, Matlab , or
LabVIEW. I have USRP, USRP 2, USRPN210 devices, I would like to program them
to perform simple RF recording (I & Q data) . I sincerely appreciate receiving
guidance to start.
Thanks
MD
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150420/97d66ed9/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 20 Apr 2015 09:47:39 -0700
From: Neel Pandeya <[email protected]>
To: "Deshpande, Manohar D. (GSFC-5550)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] New to USRP Application
Message-ID:
<CACaXmv-AreRtjFGALyrYD6CycwPz4CwtdghpL=i_phc0m4h...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Manohar Deshpande:
Here are some resources that can help you get started with GNU Radio. Let
me know if you have any questions or problems installing GNU Radio.
GNU Radio Tutorials and Resources:
https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
https://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading
Going Deeper Into GNU Radio Companion by Hak5
https://www.youtube.com/watch?v=QhMET2mld14
GNU Radio Tutorials by Balint Seeber (five-part series)
https://www.youtube.com/watch?v=N9SLAnGlGQs&list=PL618122BD66C8B3C4
https://www.youtube.com/playlist?list=PL618122BD66C8B3C4
Introduction to GNU Radio from the DCC by Tom Rondeau (four-part series)
https://www.youtube.com/watch?v=_hGNT1w-jig
https://www.youtube.com/watch?v=cg3TA3EDx78
https://www.youtube.com/watch?v=nemfS9QAYHc
https://www.youtube.com/watch?v=94R2qE7mEc4
I hope this helps.
--Neel
On 19 April 2015 at 11:03, Deshpande, Manohar D. (GSFC-5550) via USRP-users
<[email protected]> wrote:
> Hi,
>
> I am new to USRP devices and their programing using either GRC, Matlab ,
> or LabVIEW. I have USRP, USRP 2, USRPN210 devices, I would like to program
> them to perform simple RF recording (I & Q data) . I sincerely appreciate
> receiving guidance to start.
>
>
>
> Thanks
>
> MD
>
>
> _______________________________________________
> 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/20150420/d66c2eb5/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 20 Apr 2015 11:04:29 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD: What do the tx_metadata_t burst
parameters mean?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Raj,
there is the docs on the structs themselves, plus the page I sent you.
Cheers,
M
On 18.04.2015 12:32, Raj Bhattacharjea via USRP-users wrote:
> Thank you for the references. Those examples give me a vague idea of
> what these concepts mean. I certainly can't say I have a precise
> definition, or understanding of how the behavior of UHD and/or the USRP
> will change with different uses of the burst parameters. I'll carry on
> by experimentation with the code and delving into the UHD source. I was
> hoping that there was documentation, but it appears that there is not.
>
> On Tue, Apr 14, 2015 at 3:27 PM, <[email protected]
> <mailto:[email protected]>> wrote:
>
> __
>
> I'd suggest looking at the source for tx_timed_samples.cpp and
> tx_bursts.cpp to get a feel for how this works, as well as
> tx_waveforms.cpp
>
>
>
>
>
>
>
> On 2015-04-14 15:00, Raj Bhattacharjea via USRP-users wrote:
>
>> What is the meaning of various tx_metadata_t fields in UHD? The
>> documentation is here:
>>
>> http://files.ettus.com/manual/structuhd_1_1tx__metadata__t.html
>>
>> This is API documentation explaining what functions and fields
>> exist, but it does not tell me much about the concepts this API is
>> implementing. Is there some document I'm missing that explains the
>> concepts of metadata in UHD, how it is used, and what terms like
>> time_spec and start_of_burst mean, precisely? When should a burst
>> be considered to start? To stop? If I send 20 pulses of a carrier,
>> each 20 microseconds long and separated by 10 microseconds, then
>> sleep for 1 second, then do it again, do I have one burst per
>> second, or 20? What difference does this metadata even make, the
>> samples still go out the TX port regardless of these flags, right?
>> If I don't use the burst start and stop metadata correctly, will
>> the state of the USRP be somehow invalid when I go to TX again
>> later in my application?
>>
>> --
>> Raj Bhattacharjea
>> Georgia Institute of Technology
>> School of Electrical and Computer Engineering
>> http://www.prism.gatech.edu/~gtg037s/
>> 404.894.7516 <tel:404.894.7516>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> --
> Raj Bhattacharjea
> http://www.prism.gatech.edu/~gtg037s/
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 10
Date: Mon, 20 Apr 2015 11:05:10 -0700
From: Ian Buckley <[email protected]>
To: "Ralph A. Schmid, dk5ras" <[email protected]>
Cc: [email protected], 'GNU Radio Discussion List'
<[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] New UHD seems to break a
lot...
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
To close the loop on this thread, 3.8.3-RC1 has a bug in new code that
automatically calculates master_clock_rates when they are not explicitly
stated. This specifically affects B2x0 and E3x0 since they are AD9361 based
with a very flexible master_clock_rate. In this case Ralph asked for a
sample_rate of 9.142857 MHz and UHD erroneously forced a master_clock_rate of
8MHz. An explicit master_clcok_rate request (in this case for 9.142857MHz)
works around the bug as shown (green without, yellow with):
http://ianbuckley.net/ralph_spectrum.jpg. The master_clock_rate override does
print a warning in the UHD log so you can see that this is happening:
UHD Warning:
The hardware does not support the requested TX sample rate:
Target sample rate: 9.142857 MSps
Actual sample rate: 8.000000 MSps
There is also another bug in RC1 that also prints incorrect warnings. Warnings
of this form can currently be ignored until this is fixed should you know that
you have actually set sensible sample_rates:
UHD Warning:
The requested decimation is odd; the user should expect CIC rolloff.
Select an even decimation to ensure that a halfband filter is enabled.
decimation = dsp_rate/samp_rate -> 37 = (9.142857 MHz)/(0.250000 MHz)
NOTE: Ralph, your flow graph used a TX gain of 99?this is way too high for the
signal being driven to the USRP, you were driving the output amp into
saturation.
-Ian
On Apr 18, 2015, at 12:24 AM, "Ralph A. Schmid, dk5ras" <[email protected]>
wrote:
> Yes, I can confirm hash 2fe3..., and the images were downloaded with the
> supplied uhd_image_downloader, what is configured like this:
>
> _DEFAULT_BASE_URL = "http://files.ettus.com/binaries/images/";
> _AUTOGEN_IMAGES_FILENAME = "uhd-images_003.008.003-rc1.zip"
> _AUTOGEN_IMAGES_CHECKSUM = "8522b02386f5fe0bb51baa3ba0001ef0"
>
> The GRC filkes are accessible now, the only modifications I made were due to
> Ron Economos' hints regarding sampling rate, and I added a frequency slider
> to choose the correct European TV channel without having to know the
> frequency.
>
> Ralph.
>
>
> From: Ian Buckley [mailto:[email protected]]
> Sent: Saturday, April 18, 2015 03:45
> To: Ralph A. Schmid, dk5ras
> Cc: 'Martin Braun'; [email protected]; 'GNU Radio Discussion List'
> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>
> Ralph,
> I'm not able to access either of the .grc files on your website, but using
> the original dvbt_tx_demo_8k flow graph from gr-dvbt, the spectrum I generate
> with 003.008.003-RC1 has a 3dB bandwidth of about ~7.5MHz the same as your
> uhd_master screen shot. I don't see the truncated bandwidth of your uhd_rc1
> screenshot. http://ianbuckley.net/dvbt.jpg
> Can you verify please that you have UHD at the current 003.008.003-RC1 tag
> position git hash 2fe319d9790c7ec0bcdb9582c4fea95f3fd809b9, and that the
> downloaded FPGA images are from:
> http://files.ettus.com/binaries/images/uhd-images_003.008.003-rc1.zip
>
> I'll need your exact flow graph if I'm to debug this anymore.
>
> -Ian
>
>
>
> On Apr 17, 2015, at 11:48 AM, "Ralph A. Schmid, dk5ras" <[email protected]>
> wrote:
>
>
> I have put it all here, flow graphs and screenshots of the flow graphs:
>
> http://dk5ras.dyndns.org/tmp/DVB/
>
> This way we can keep it on the list without sending attachments.
>
> They were taken from the VM container before all the upgrades were made, but
> I did not change anything when upgrading.
>
> Ralph.
>
>
>
> -----Original Message-----
> From: Ian Buckley [mailto:[email protected]]
> Sent: Friday, April 17, 2015 19:25
> To: Ralph A. Schmid, dk5ras
> Cc: 'Martin Braun'; [email protected]; 'GNU Radio Discussion List'
> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>
> Great Ralph, thats a big help. Can you send me your exact flow graph used to
> generate these 2 plots off list please. I want to re run this scenario and
> see your exact configuration.
>
> Thanks
> -Ian
>
> On Apr 17, 2015, at 10:00 AM, "Ralph A. Schmid, dk5ras" <[email protected]>
> wrote:
>
>
> OK, here we go. The hotel TV was dvb-c only, so I had to do the tests
> back at home.
>
> I took my perfectly working Kubuntu 14.04 64 bit VM container together
> with my B210, made a copy and updated this one, first I made a git
> pull to get latest master, built it, rebuilt gnuradio, rebuilt
> gr-dvbt, updated the FPGA images, and everything still was fine. The
> chosen dvb-t bandwidth is 8 MHz.
>
>
> Then I changed to 003_008_003_rc1, did the same procedure, fired up
> grc, and the signal was not decodable both with a dvb-t PC receiver
> and with an dvb-x analyzer. The analyzer saw the RF level, but no
> data, no constellation, nothing, it looked to him like interference.
>
> When you have a look at the two "uhd" screenshots here
> http://dk5ras.dyndns.org/tmp/DVB/ made with my spectrum analyzer then
> you will find that RC1 produces a somehow narrower signal, so it
> really looks something gets cut at the ends with all the filtering and DSP
> stuff.
>
> Adjusting the channel bandwidth in the uhd sink block from 0 to a
> sensible value changes nothing.
>
> Btw., the dvb-t2 package behaves identical.
>
> Ralph.
>
>
> -----Original Message-----
> From: Martin Braun [mailto:[email protected]]
> Sent: Wednesday, April 15, 2015 21:14
> To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
> Discussion List'
> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>
> master works, but RC1 does not? Huh, I'm confused now. Can you give
> some detail on what's going on, so we can try and reproduce this?
>
> Thanks,
> Martin
>
> On 15.04.2015 12:52, Ralph A. Schmid, dk5ras wrote:
>
> RC1, master seems to work.
>
> Ralph.
>
> -----Original Message-----
> From: Martin Braun [mailto:[email protected]]
> Sent: Wednesday, April 15, 2015 15:44
> To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
> Discussion List'
> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>
> Thanks, Ralph. Just to clarify: When you say 'New UHD', do you mean
> 3.8.3-RC1, or latest master?
>
> Martin
>
> On 15.04.2015 08:40, Ralph A. Schmid, dk5ras wrote:
>
> It is a B210, but as a note, due to the up to now missing FPGA
> images I used 003.008.003-RC1, not the latest master. Still I had no
> access to a spectrum and DVB-T analyzer, so I have no idea what is
> happening, I just can confirm that RF is transmitted, and the
> receiver doesn't get a picture, while with the snapshot of the same
> VM before the upgrade
> is received without problems.
>
> I will know more in about three hours.
>
> Ralph.
>
>
> -----Original Message-----
> From: Martin Braun [mailto:[email protected]]
> Sent: Wednesday, April 15, 2015 3:15 PM
> To: Ralph A. Schmid, dk5ras; [email protected]; 'GNU Radio
> Discussion List'
> Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
>
> On 15.04.2015 06:20, Ralph A. Schmid, dk5ras wrote:
>
> Hi,
>
> Not only OpenBTS is affected, also gr-dvbt/t2 do not work any more
> with latest uhd. A quick check during lunch break showed, the
> produced output is not decodable any more. I will take a closer
> look this evening at home, where I have more and better equipment.
>
> Ralph,
>
> which device is this on?
>
> Thanks,
> Martin
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150420/a1fd8c57/attachment-0001.html>
------------------------------
Message: 11
Date: Mon, 20 Apr 2015 19:18:03 +0100
From: Paul B <[email protected]>
To: "Nick Foster" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Ettus B200 ADS-B on Windows?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Nick,
I?ve got everything running smoothly on Ubuntu now (using VMworkstation 11),
and i?ve got gr-air-modes running as well. One thing i?m wondering is if it?s
possible to send the data from gr-air-modes to planeplotter or adsbscope to
plot the aircraft? I?ve tried setting gr-air-modes as an SBS1 server and
connecting to it through Windows, but it doesn?t seem to want to work. I?ve got
my VMworkstation Network Adapter set up as a NAT, not sure if thats correct or
not. I know you can use Google Earth to plot the aircraft, but i?ve tried that
also and had no luck in getting it working.
I?m wondering if theres something i?m missing thats causing it to not work?
Paul
From: Nick Foster
Sent: Monday, April 20, 2015 5:19 PM
To: Paul B
Cc: [email protected]
Subject: Re: [USRP-users] Ettus B200 ADS-B on Windows?
If you get Gnuradio and UHD installed, gr-air-modes works just fine on Windows
and, of course, with the B200. Do you have specific problems with your Linux
install you'd like to ask about? Seems like it might be something this list can
help with.
--n
On Sun, Apr 19, 2015 at 8:24 AM, Paul B via USRP-users
<[email protected]> wrote:
Hi there,
First time i?ve posted here, but i could do with a little bit of help/advice.
I recently got a B200 and i?ve managed to get it working fine in Windows 8.1
with HDSDR and SDR#. I do enjoy decoding ADS-B and used to use my RTL Dongle to
do so before buying my B200.
I?ve tried to find a way to do this using the B200 on Windows, but i just
can?t seem to find anything that?ll do the job. Is there anything i?d be able
to use to decode ADS-B on Windows, or am i
going to have to try and get my B200 working on Linux? (I?ve tried for 3 days
now and can?t get it working on my vmware Ubuntu install)
Any advice would be greatly appreciated,
Thanks,
Paul
_______________________________________________
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/20150420/6223b3e7/attachment-0001.html>
------------------------------
Message: 12
Date: Mon, 20 Apr 2015 11:30:08 -0700
From: Nick Foster <[email protected]>
To: Paul B <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Ettus B200 ADS-B on Windows?
Message-ID:
<CA+JMMq8Y5PGVAXT=2gh7g1xcmabtoaqcrt9futm5f4tj3z1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
"It doesn't seem to want to work" is a little nonspecific to diagnose the
problem. SBS1 export should work, although I've never tried to push that
across a VM boundary.
--n
On Mon, Apr 20, 2015 at 11:18 AM, Paul B <[email protected]>
wrote:
> Hi Nick,
>
> I?ve got everything running smoothly on Ubuntu now (using VMworkstation
> 11), and i?ve got gr-air-modes running as well. One thing i?m wondering is
> if it?s possible to send the data from gr-air-modes to planeplotter or
> adsbscope to plot the aircraft? I?ve tried setting gr-air-modes as an SBS1
> server and connecting to it through Windows, but it doesn?t seem to want to
> work. I?ve got my VMworkstation Network Adapter set up as a NAT, not sure
> if thats correct or not. I know you can use Google Earth to plot the
> aircraft, but i?ve tried that also and had no luck in getting it working.
>
> I?m wondering if theres something i?m missing thats causing it to not work?
>
> Paul
>
> *From:* Nick Foster <[email protected]>
> *Sent:* Monday, April 20, 2015 5:19 PM
> *To:* Paul B <[email protected]>
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] Ettus B200 ADS-B on Windows?
>
> If you get Gnuradio and UHD installed, gr-air-modes works just fine on
> Windows and, of course, with the B200. Do you have specific problems with
> your Linux install you'd like to ask about? Seems like it might be
> something this list can help with.
>
> --n
>
> On Sun, Apr 19, 2015 at 8:24 AM, Paul B via USRP-users <
> [email protected]> wrote:
>
>> Hi there,
>>
>> First time i?ve posted here, but i could do with a little bit of
>> help/advice.
>> I recently got a B200 and i?ve managed to get it working fine in Windows
>> 8.1 with HDSDR and SDR#. I do enjoy decoding ADS-B and used to use my RTL
>> Dongle to do so before buying my B200.
>> I?ve tried to find a way to do this using the B200 on Windows, but i just
>> can?t seem to find anything that?ll do the job. Is there anything i?d be
>> able to use to decode ADS-B on Windows, or am i
>> going to have to try and get my B200 working on Linux? (I?ve tried for 3
>> days now and can?t get it working on my vmware Ubuntu install)
>>
>> Any advice would be greatly appreciated,
>> Thanks,
>>
>> Paul
>>
>> _______________________________________________
>> 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/20150420/efd56e81/attachment-0001.html>
------------------------------
Message: 13
Date: Mon, 20 Apr 2015 11:45:39 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Overrun on 56MHz with B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
I get those high-pitched noises too -- the upside is I can acoustically
confirm if USB3 or USB2 is being used.
Also, just to point this out: The max clock rate on B2x0 is actually
61.44 MHz, but above 56 MHz, you'll see the effects of the analog filters.
Cheers,
M
On 18.04.2015 08:13, Marcus M?ller via USRP-users wrote:
> Hi Jason,
>
> yes, in most cases, that is a system bandwidth limitation. Many
> controllers just max out; your chipset is usually on the good side[1],
> but that doesn't actually mean that much.
>
> Also, I know the noise you're talking about -- it happens to my Laptop,
> too, and also on higher rates. I typically hear it when I do something
> CPU intensive, though -- my blind guess is that it's a voltage converter
> that supplies the CPU with power, and is driven at the edge of its
> specs. You're running osmocom_fft in fosphor mode, which means you're
> using openCL; I suppose you're using OpenCL as a means to get more out
> of your CPU, so that would align with my CPU load assumption.
>
> So, what you can do is first just use the rx_samples_to_file example
> that comes with uhd (look into /usr/[local/]/lib[64]/uhd/examples), and
> write your samples to /dev/null ; if the overflows go away, you're
> CPU-bound, if they persist, you're USB-bound.
>
> Greetings,
> Marcus
>
> [1]
> http://www.ettus.com/kb/detail/usrp-b200-and-b210-usb-30-streaming-rate-benchmarks
>
> On 04/18/2015 04:17 PM, Jason A. Donenfeld via USRP-users wrote:
>> Hi folks,
>>
>> I'm running a B210 over USB3. I seem to be getting buffer overruns
>> when asking for the maximum 56MHz of bandwidth. For example:
>>
>> zx2c4@thinkpad ~/Desktop/sdr $ osmocom_fft -a
>> uhd,master_clock_rate=56e6 -s 56e6 -f 420e6 -F
>> linux; GNU C++ version 4.9.2; Boost_105600; UHD_003.008.002-0-unknown
>> gr-osmosdr v0.1.4-16-g61184a19 (0.1.5git) gnuradio v3.7.6.1-103-g8ecfd13a
>> built-in source types: file rtl rtl_tcp uhd
>> -- Operating over USB 3.
>> -- Initialize CODEC control...
>> -- Initialize Radio control...
>> -- Performing register loopback test... pass
>> -- Performing register loopback test... pass
>> -- Performing CODEC loopback test... pass
>> -- Performing CODEC loopback test... pass
>> -- Asking for clock rate 56.000000 MHz
>> -- Actually got clock rate 56.000000 MHz
>> -- Performing timer loopback test... pass
>> -- Performing timer loopback test... pass
>> -- Using subdev spec 'A:A A:B'.
>> [+] Selected device: Quadro K2000M
>> OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO.....[repeated enormous amounts]
>>
>> Incidentally, when it's overrunning, I can hear a high pitched
>> capacitor noise inside of my laptop (Thinkpad W530, Intel i7-3820QM,
>> C210 chipset), which is a bit funny. Is it possible that the system's
>> USB controller is simply not up to task? Or is this a configuration
>> issue I can address?
>>
>> Thanks,
>> Jason
>>
>> _______________________________________________
>> 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: 14
Date: Mon, 20 Apr 2015 19:49:05 +0100
From: Paul B <[email protected]>
To: "Nick Foster" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Ettus B200 ADS-B on Windows?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Sorry, i should be a little more specific, i?m still experimenting with it at
the moment, but heres what i?ve tried.
I?ve ran gr-air-modes in terminal with the flags:
modes_rx ?g 45 ?P which should set my gain to 45dB, which is does, and set up
an SBS1 server on port 30003.
>From there, i go over to windows, into Planeplotter, set up the receive
>settings as SBS1 IP 127.0.0.1:30003 which is the local IP and port setting. I
>start Planeplotter, and its receiving nothing, which could either be a problem
>with how i?ve setup gr-air-modes, or a problem with how i?ve set my network
>card up in VMworkstation. I?m rather new to Linux and the whole Virtual
>Machine scene, so it?s pretty much new territory for me.
Paul
From: Nick Foster
Sent: Monday, April 20, 2015 7:30 PM
To: Paul B
Cc: [email protected]
Subject: Re: [USRP-users] Ettus B200 ADS-B on Windows?
"It doesn't seem to want to work" is a little nonspecific to diagnose the
problem. SBS1 export should work, although I've never tried to push that across
a VM boundary.
--n
On Mon, Apr 20, 2015 at 11:18 AM, Paul B <[email protected]> wrote:
Hi Nick,
I?ve got everything running smoothly on Ubuntu now (using VMworkstation 11),
and i?ve got gr-air-modes running as well. One thing i?m wondering is if it?s
possible to send the data from gr-air-modes to planeplotter or adsbscope to
plot the aircraft? I?ve tried setting gr-air-modes as an SBS1 server and
connecting to it through Windows, but it doesn?t seem to want to work. I?ve got
my VMworkstation Network Adapter set up as a NAT, not sure if thats correct or
not. I know you can use Google Earth to plot the aircraft, but i?ve tried that
also and had no luck in getting it working.
I?m wondering if theres something i?m missing thats causing it to not work?
Paul
From: Nick Foster
Sent: Monday, April 20, 2015 5:19 PM
To: Paul B
Cc: [email protected]
Subject: Re: [USRP-users] Ettus B200 ADS-B on Windows?
If you get Gnuradio and UHD installed, gr-air-modes works just fine on
Windows and, of course, with the B200. Do you have specific problems with your
Linux install you'd like to ask about? Seems like it might be something this
list can help with.
--n
On Sun, Apr 19, 2015 at 8:24 AM, Paul B via USRP-users
<[email protected]> wrote:
Hi there,
First time i?ve posted here, but i could do with a little bit of
help/advice.
I recently got a B200 and i?ve managed to get it working fine in Windows
8.1 with HDSDR and SDR#. I do enjoy decoding ADS-B and used to use my RTL
Dongle to do so before buying my B200.
I?ve tried to find a way to do this using the B200 on Windows, but i just
can?t seem to find anything that?ll do the job. Is there anything i?d be able
to use to decode ADS-B on Windows, or am i
going to have to try and get my B200 working on Linux? (I?ve tried for 3
days now and can?t get it working on my vmware Ubuntu install)
Any advice would be greatly appreciated,
Thanks,
Paul
_______________________________________________
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/20150420/7f9c9bd8/attachment-0001.html>
------------------------------
Message: 15
Date: Mon, 20 Apr 2015 21:03:03 +0200
From: Sylvain Munaut <[email protected]>
To: "Jason A. Donenfeld" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Overrun on 56MHz with B210
Message-ID:
<cahl+j0_s2mdfddmofb0tp1czguhx4gpy4sknicelevefvfj...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
> Incidentally, when it's overrunning, I can hear a high pitched
> capacitor noise inside of my laptop (Thinkpad W530, Intel i7-3820QM,
> C210 chipset), which is a bit funny. Is it possible that the system's
> USB controller is simply not up to task? Or is this a configuration
> issue I can address?
You might also want to try without fosphor, because maybe your GPU
isn't up to the task.
fosphor processes every input samples, it won't drop anything. But
that also means that if your GPU isn't fast enough, it won't consume
samples fast enough and the buffer will fill up and eventually the
'source' block will start dropping.
Usually this will also be accompanied by a sluggish fosphor
redraw/frame rate because it only redraws the screen when it managed
to empty the input buffer (which never happens if it's not fast
enough).
Have you tried the fosphor benchmark code ? What did it report ?
It might also be that the fosphor input buffer is too small. This has
been reported at high rates when working with 200 Msps with the X300.
In base_sink_c_impl.cc you can try to find "this->d_fifo = new fifo(2
* 1024 * 1024);" and increase it to (8 * 1024 * 1024).
Cheers,
Sylvain
------------------------------
Message: 16
Date: Mon, 20 Apr 2015 21:27:08 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'Ian Buckley'" <[email protected]>
Cc: [email protected], 'GNU Radio Discussion List'
<[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] New UHD seems to break a
lot...
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Thanks for all the research - sound reasonable, now I know what is going
wrong, great!
Regarding the TX gain, I was never able to see any nonlinearity from
saturation, the amp seems to be way below the critical input level. The
signal is 1a clean, no spurs and no excessive harmonics, no IM.
Ralph.
From: Ian Buckley [mailto:[email protected]]
Sent: Monday, April 20, 2015 20:05
To: Ralph A. Schmid, dk5ras
Cc: 'Martin Braun'; [email protected]; 'GNU Radio Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
To close the loop on this thread, 3.8.3-RC1 has a bug in new code that
automatically calculates master_clock_rates when they are not explicitly
stated. This specifically affects B2x0 and E3x0 since they are AD9361 based
with a very flexible master_clock_rate. In this case Ralph asked for a
sample_rate of 9.142857 MHz and UHD erroneously forced a master_clock_rate
of 8MHz. An explicit master_clcok_rate request (in this case for
9.142857MHz) works around the bug as shown (green without, yellow with):
http://ianbuckley.net/ralph_spectrum.jpg. The master_clock_rate override
does print a warning in the UHD log so you can see that this is happening:
UHD Warning:
The hardware does not support the requested TX sample rate:
Target sample rate: 9.142857 MSps
Actual sample rate: 8.000000 MSps
There is also another bug in RC1 that also prints incorrect warnings.
Warnings of this form can currently be ignored until this is fixed should
you know that you have actually set sensible sample_rates:
UHD Warning:
The requested decimation is odd; the user should expect CIC rolloff.
Select an even decimation to ensure that a halfband filter is enabled.
decimation = dsp_rate/samp_rate -> 37 = (9.142857 MHz)/(0.250000 MHz)
NOTE: Ralph, your flow graph used a TX gain of 99.this is way too high for
the signal being driven to the USRP, you were driving the output amp into
saturation.
-Ian
On Apr 18, 2015, at 12:24 AM, "Ralph A. Schmid, dk5ras" <[email protected]>
wrote:
Yes, I can confirm hash 2fe3..., and the images were downloaded with the
supplied uhd_image_downloader, what is configured like this:
_DEFAULT_BASE_URL = " <http://files.ettus.com/binaries/images/>
http://files.ettus.com/binaries/images/";
_AUTOGEN_IMAGES_FILENAME = "uhd-images_003.008.003-rc1.zip"
_AUTOGEN_IMAGES_CHECKSUM = "8522b02386f5fe0bb51baa3ba0001ef0"
The GRC filkes are accessible now, the only modifications I made were due to
Ron Economos' hints regarding sampling rate, and I added a frequency slider
to choose the correct European TV channel without having to know the
frequency.
Ralph.
From: Ian Buckley [mailto:ianb@ <http://ionconcepts.com> ionconcepts.com]
Sent: Saturday, April 18, 2015 03:45
To: Ralph A. Schmid, dk5ras
Cc: 'Martin Braun'; <mailto:[email protected]>
[email protected]; 'GNU Radio Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
Ralph,
I'm not able to access either of the .grc files on your website, but using
the original dvbt_tx_demo_8k flow graph from gr-dvbt, the spectrum I
generate with 003.008.003-RC1 has a 3dB bandwidth of about ~7.5MHz the same
as your uhd_master screen shot. I don't see the truncated bandwidth of your
uhd_rc1 screenshot. <http://ianbuckley.net/dvbt.jpg>
http://ianbuckley.net/dvbt.jpg
Can you verify please that you have UHD at the current 003.008.003-RC1 tag
position git hash 2fe319d9790c7ec0bcdb9582c4fea95f3fd809b9, and that the
downloaded FPGA images are from:
<http://files.ettus.com/binaries/images/uhd-images_003.008.003-rc1.zip>
http://files.ettus.com/binaries/images/uhd-images_003.008.003-rc1.zip
I'll need your exact flow graph if I'm to debug this anymore.
-Ian
On Apr 17, 2015, at 11:48 AM, "Ralph A. Schmid, dk5ras" <
<mailto:[email protected]> [email protected]> wrote:
I have put it all here, flow graphs and screenshots of the flow graphs:
<http://dk5ras.dyndns.org/tmp/DVB/> http://dk5ras.dyndns.org/tmp/DVB/
This way we can keep it on the list without sending attachments.
They were taken from the VM container before all the upgrades were made, but
I did not change anything when upgrading.
Ralph.
-----Original Message-----
From: Ian Buckley [ <mailto:[email protected]>
mailto:[email protected]]
Sent: Friday, April 17, 2015 19:25
To: Ralph A. Schmid, dk5ras
Cc: 'Martin Braun'; <mailto:[email protected]>
[email protected]; 'GNU Radio Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
Great Ralph, thats a big help. Can you send me your exact flow graph used to
generate these 2 plots off list please. I want to re run this scenario and
see your exact configuration.
Thanks
-Ian
On Apr 17, 2015, at 10:00 AM, "Ralph A. Schmid, dk5ras" <
<mailto:[email protected]> [email protected]>
wrote:
OK, here we go. The hotel TV was dvb-c only, so I had to do the tests
back at home.
I took my perfectly working Kubuntu 14.04 64 bit VM container together
with my B210, made a copy and updated this one, first I made a git
pull to get latest master, built it, rebuilt gnuradio, rebuilt
gr-dvbt, updated the FPGA images, and everything still was fine. The
chosen dvb-t bandwidth is 8 MHz.
Then I changed to 003_008_003_rc1, did the same procedure, fired up
grc, and the signal was not decodable both with a dvb-t PC receiver
and with an dvb-x analyzer. The analyzer saw the RF level, but no
data, no constellation, nothing, it looked to him like interference.
When you have a look at the two "uhd" screenshots here
<http://dk5ras.dyndns.org/tmp/DVB/> http://dk5ras.dyndns.org/tmp/DVB/ made
with my spectrum analyzer then
you will find that RC1 produces a somehow narrower signal, so it
really looks something gets cut at the ends with all the filtering and DSP
stuff.
Adjusting the channel bandwidth in the uhd sink block from 0 to a
sensible value changes nothing.
Btw., the dvb-t2 package behaves identical.
Ralph.
-----Original Message-----
From: Martin Braun [ <mailto:[email protected]>
mailto:[email protected]]
Sent: Wednesday, April 15, 2015 21:14
To: Ralph A. Schmid, dk5ras; <mailto:[email protected]>
[email protected]; 'GNU Radio
Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
master works, but RC1 does not? Huh, I'm confused now. Can you give
some detail on what's going on, so we can try and reproduce this?
Thanks,
Martin
On 15.04.2015 12:52, Ralph A. Schmid, dk5ras wrote:
RC1, master seems to work.
Ralph.
-----Original Message-----
From: Martin Braun [ <mailto:[email protected]>
mailto:[email protected]]
Sent: Wednesday, April 15, 2015 15:44
To: Ralph A. Schmid, dk5ras; <mailto:[email protected]>
[email protected]; 'GNU Radio
Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
Thanks, Ralph. Just to clarify: When you say 'New UHD', do you mean
3.8.3-RC1, or latest master?
Martin
On 15.04.2015 08:40, Ralph A. Schmid, dk5ras wrote:
It is a B210, but as a note, due to the up to now missing FPGA
images I used 003.008.003-RC1, not the latest master. Still I had no
access to a spectrum and DVB-T analyzer, so I have no idea what is
happening, I just can confirm that RF is transmitted, and the
receiver doesn't get a picture, while with the snapshot of the same
VM before the upgrade
is received without problems.
I will know more in about three hours.
Ralph.
-----Original Message-----
From: Martin Braun [ <mailto:[email protected]>
mailto:[email protected]]
Sent: Wednesday, April 15, 2015 3:15 PM
To: Ralph A. Schmid, dk5ras; <mailto:[email protected]>
[email protected]; 'GNU Radio
Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
On 15.04.2015 06:20, Ralph A. Schmid, dk5ras wrote:
Hi,
Not only OpenBTS is affected, also gr-dvbt/t2 do not work any more
with latest uhd. A quick check during lunch break showed, the
produced output is not decodable any more. I will take a closer
look this evening at home, where I have more and better equipment.
Ralph,
which device is this on?
Thanks,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150420/4ecbc35d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150420/4ecbc35d/attachment-0001.sig>
------------------------------
Message: 17
Date: Mon, 20 Apr 2015 12:54:51 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] [UHD-3.8.3] Release Announcement
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Everyone,
3.8.3 is now live. There were minimal changes concerning documentation
and some of the warnings/verbosity output, but otherwise, the functional
state is pretty much that of the RC.
You can find the tag here:
https://github.com/EttusResearch/uhd/tree/release_003_008_003
Binaries and tarballs are currently being prepared.
Thanks to all those who gave us feedback on the release candidate!
Cheers,
Martin
On 14.04.2015 09:32, Martin Braun wrote:
> Hi there, USRP-users,
>
> very soon, we'll be having a new maintenance update for our 3.8 UHD
> version. Unlike the previous version, we don't have any new features,
> but we do have some bugfixes and highly recommend updating. In
> particular, users of the USRP2 and N210 series need to update their FPGA
> images if you want to use the new UHD version. Following this, I will
> also update the images package on master branch.
>
> The release candidate tag is 003_008_003_rc1. Given that we're changing
> things in USRP2/N-Series, we'll give it a few days of testing before we
> release the actual release (3.8.3).
>
> Cheers,
> Martin
>
>
>
> Changelog:
>
> ## 003.008.003
> * UBX: Fixed phase synchronization issues
> (Related changes: Change X300 daughterboard frequency, increase
> N210 FIFO depth)
> * Fixed many compiler warnings
> * B200: Fixed timing issues, fixed tick rate issue, stabilized
> operations at high clock rates
> * X300: Improved phase alignment across devices
> * CMake: Build fixes
> * E300: Flow control fix
>
>
------------------------------
Message: 18
Date: Mon, 20 Apr 2015 13:07:59 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: [USRP-users] maint, master and auto clock rates
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
As there were some recent confusions between our branches, I'd like to
recap officially what our branches mean:
* maint: This is the stable branch. All our releases come off of maint.
In general, we only merge bugfixes into this branch, although we have
had some exceptions to this rule (e.g. the UBX driver). API should never
change on maint.
* master: This is where new development happens. New devices get support
on master first, and new features that change behaviour and/or API will
go onto this branch. maint is merged into master, so consider this
mostly a superset of maint -- except where master changes things.
When we put out patch-level releases (e.g. 3.8.2 -> 3.8.3), we use the
current state of maint, and tag that as the new release. master branch
doesn't care about this.
When we put out actual new versions (e.g. 3.8.x -> 3.9.0), things are
different: maint gets reset to master, then we tag the version. So for
every major release, maint and master are identical for a few weeks.
One thing we recently changed is that master now gets a new version
number. At this point, maint is identical to release 3.8.3, but master
has version number 3.9.git (the .git showing that this is a development
branch).
On a side note, we might have other branches (e.g. the rfnoc-devel
branch) that get other suffixes than .git.
We recently had some B200-related changes that caused some confusion,
which was related to this master/maint difference. In particular, on
master, we changed these things:
- The B200 has an auto-clock-rate feature, which will try to choose a
clock rate based off of your chosen sampling rate.
- The DSP chain changed on master, improving aliasing. We could have put
this into maint, but it did also change group delay of the filter chain,
hence we considered it too intrusive for maint.
Cheers,
Martin
------------------------------
Message: 19
Date: Mon, 20 Apr 2015 16:36:26 -0400
From: John Ackermann N8UR <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] maint, master and auto clock rates
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
When using the build-gnuradio script (which I still find much more
stable than pybombs, sorry), which branch is installed?
Thanks for your efforts managing all this!
John
----
On 4/20/2015 4:07 PM, Martin Braun via USRP-users wrote:
> As there were some recent confusions between our branches, I'd like to
> recap officially what our branches mean:
>
> * maint: This is the stable branch. All our releases come off of maint.
> In general, we only merge bugfixes into this branch, although we have
> had some exceptions to this rule (e.g. the UBX driver). API should never
> change on maint.
>
> * master: This is where new development happens. New devices get support
> on master first, and new features that change behaviour and/or API will
> go onto this branch. maint is merged into master, so consider this
> mostly a superset of maint -- except where master changes things.
>
> When we put out patch-level releases (e.g. 3.8.2 -> 3.8.3), we use the
> current state of maint, and tag that as the new release. master branch
> doesn't care about this.
>
> When we put out actual new versions (e.g. 3.8.x -> 3.9.0), things are
> different: maint gets reset to master, then we tag the version. So for
> every major release, maint and master are identical for a few weeks.
>
> One thing we recently changed is that master now gets a new version
> number. At this point, maint is identical to release 3.8.3, but master
> has version number 3.9.git (the .git showing that this is a development
> branch).
>
> On a side note, we might have other branches (e.g. the rfnoc-devel
> branch) that get other suffixes than .git.
>
>
> We recently had some B200-related changes that caused some confusion,
> which was related to this master/maint difference. In particular, on
> master, we changed these things:
> - The B200 has an auto-clock-rate feature, which will try to choose a
> clock rate based off of your chosen sampling rate.
> - The DSP chain changed on master, improving aliasing. We could have put
> this into maint, but it did also change group delay of the filter chain,
> hence we considered it too intrusive for maint.
>
> Cheers,
> Martin
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 20
Date: Tue, 21 Apr 2015 01:22:10 +0430
From: hossein talaiee <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP UHD Library Release suggestion
Message-ID:
<caaibebrajvwjmx_avy7afrgycx_ul88tryhhboe-9ycqcv3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I'm currently doing it for every version, but Really ? for size?
Dynamicly linked runtime : 3,621,376 bytes
Staticly linked runtime : 3,777,024 bytes
for 150 KB in 3 MB?
On Mon, Apr 20, 2015 at 6:39 PM, Marcus M?ller <[email protected]>
wrote:
> About VC runtime, yah, I and probably any other developer has it or know
> how to get it, but we want to distribute our application to non developers,
> why you dont staticly link it?
>
> Because that would unnecessarily increase library size for those 90% of
> developers who don't want that.
> If you want to distribute your UHD-based application statically linked to
> the VC runtime, you're free to do so -- but it's simply not what the
> majority of developers or users need.
>
> Best regards,
> Marcus M?ller
>
>
>
> On 04/20/2015 03:39 PM, hossein talaiee via USRP-users wrote:
>
> About VC runtime, yah, I and probably any other developer has it or know
> how to get it, but we want to distribute our application to non developers,
> why you dont staticly link it? what harm it may cause?
>
> On Fri, Apr 17, 2015 at 7:44 PM, Martin Braun via USRP-users <
> [email protected]> wrote:
>
>> Hi Hossein,
>>
>> the requirement to install VC runtime is actually quite common, and if we
>> included it in our binaries, they'd become huge. Also, if you're a
>> developer there's a high chance those runtimes are already installed, and
>> for a lot of our users, that's true.
>>
>> As for Boost, there's no reason for us to update that unless we run into
>> bugs or require more features, so we'll be sticking to our current version
>> for another while.
>>
>> Regards,
>> Martin
>>
>>
>> On 17.04.2015 04:37, hossein talaiee via USRP-users wrote:
>>
>>> I noticed that UHD.dll file linked dynamicly against VS C++ run-time
>>> library that make this dll needy of VS-C-Runtime installation to work,
>>> and I wonder why?
>>> Why when we can do it staticly and have an absolutely portable UHD
>>> driver!
>>>
>>> As a matter of fact, boost compile must be done with this option too
>>> that can be done with passing "runtime-link=static link=static" to b2
>>> command line of boost compile.
>>>
>>> Also, boost libraries updated now to 1.57 (1.58 also will be out very
>>> soon, they testing 1.58-RC version now), consider upgrading boost
>>> libraries in release version.
>>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
>
> _______________________________________________
> 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/20150421/3790534f/attachment-0001.html>
------------------------------
Message: 21
Date: Mon, 20 Apr 2015 14:16:58 -0700
From: John Malsbury <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Subdevice Spec on X300
Message-ID:
<CAK+fQfeYs_2xvOtjeN5=chGtwxyMA29j3CJnVSX8j=4qdhc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I am trying to use a subdevice spec "B:0" to set the output of a
single-channel tx stream to an SBX daughterboard on slot B. However, it
still seems to land on daughterboard A when it initializes. Did the subdev
convention change at all with X300? Or does the X300 just not support
"skipping" slot A?
UHD Release 3.8.1
-John
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150420/f522cc2e/attachment-0001.html>
------------------------------
Message: 22
Date: Mon, 20 Apr 2015 15:04:54 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Subdevice Spec on X300
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
The convention didn't change, and we've had support for skipping side-A
since 3.7.1 IIRC. So what you're doing seems correct, and I know I've
done exactly that in the past (with older versions than 3.8.1, too).
M
On 20.04.2015 14:16, John Malsbury via USRP-users wrote:
> I am trying to use a subdevice spec "B:0" to set the output of a
> single-channel tx stream to an SBX daughterboard on slot B. However, it
> still seems to land on daughterboard A when it initializes. Did the
> subdev convention change at all with X300? Or does the X300 just not
> support "skipping" slot A?
>
> UHD Release 3.8.1
>
> -John
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 23
Date: Mon, 20 Apr 2015 15:07:34 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] The FPGA build is not compatible with the
host code build
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Michel,
it seems like you're running master branch. Now, I'm not sure how your
FPGA image version + UHD version would drift.
In any case, I renamed the UHD image package on master to match the
version string -- can you just try a git pull on master, and then try
again? Also, you did update the USRP2 image on the SD card, right?
Martin
On 18.04.2015 11:33, Michel Burnand via USRP-users wrote:
> Hello Martin,
>
> I have the same issue as Yue with my USRP2...
>
> I have UHD_003.008.003-137-g2f760ac0 installed. Uploaded usrp2_fpga.bin
> and usrp2_fw.bin, burned a SD card. No success at all...
>
> The image file downloaded by uhd_images_downloader.py is:
> uhd_images_003.008.003-130-g4ca383f7.zip
>
> Thank you in advance for your help.
>
> Michel, HB9DUG
>
>
> ---
> L'absence de virus dans ce courrier ?lectronique a ?t? v?rifi?e par le
> logiciel antivirus Avast.
> http://www.avast.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 24
Date: Mon, 20 Apr 2015 15:10:48 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] time sync 2 ettus x310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Sanjoy,
if you want to do radar, you need to make sure both devices are
connected to the same external reference. For radar, you can't run off
of separate clocks.
We've confirmed timing accuracy across devices on the nanosecond scale
in the past (using OctoClocks for clock distribution).
Cheers,
M
On 17.04.2015 06:00, Sanjoy Basak via USRP-users wrote:
> Hi all,
> I am trying to sync 2 ettus x310 in time. However, I am always having a
> distortion at the beginning after receiving, and there is always a
> delay of few microseconds between the tx and rx. I put tx in one x310
> and rx in another x310 and its in a wired connection. GPS antenna is
> connected to one usrp(with Tx) and another one is on external ref(Rx).
>
> So now if I check the last pps on both usrp; it shows tx:0; rx:2s;
> then I am compensating it making it set_start_time both at for 4s. So
> ideally I should get time synced tx and rx signal.
>
> But I am getting distortion in Rx signal for 2seconds at the beginning;
> this is constant for every sampling freq; so if in that region I have my
> rx signal I can't retrieve that as the distortion is already introduced
> there.
> As I am trying to implement radar with x310, this is a serious problem
> for me. As within first 2 seconds and few microseconds I can't receive
> anything.
>
> I would really appreciate any kind of suggestion that come through. If
> anyone have question regarding setup or python code please ask.
> Thanks for reading.
>
> Best regards
> Sanjoy
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 25
Date: Tue, 21 Apr 2015 10:42:31 +0900 (KST)
From: ??? <[email protected]>
To: [email protected]
Subject: [USRP-users] Real-time streaming input
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Dear all,
I want to transmit transmit the real-time streaming packets in my USRP N210
devices.
How to input the streaming packet to the input of my USRP N210 to transmit the
packets?
Best regards
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150421/4f47c13d/attachment-0001.html>
------------------------------
Message: 26
Date: Mon, 20 Apr 2015 20:01:09 -0700
From: Neel Pandeya <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] Announcing NEWSDR at WPI on Thr/Fri May 21/22
Message-ID:
<CACaXmv9T1nT_piHyCE=vL6eH=zoyy974hwx4zwvnejrpwha...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
*********************************************************************
* NEWSDR 2015 *
* *
* New England Workshop on Software-Defined Radio *
* *
* Fifth-Annual *
* *
* Main Event *
* Friday May 22, 7:30 AM - 4:00 PM *
* *
* GNU Radio Hacking Workshop *
* Thursday May 21, 5:00 PM - 9:30 PM *
* *
* Worcester Polytechnic Institute (WPI) *
* Worcester, MA, USA *
* *
* http://www.sdr-boston.org/ *
* *
* Free Registration *
* *
*********************************************************************
INVITATION TO PARTICIPATE
You are cordially invited to the 2015 New England Workshop on
Software Defined Radio (NEWSDR 2015), which is the fifth installment
of an annual series of workshops organized by the Boston SDR User
Group (SDR-Boston).
This year, NEWSDR will be held at the Rubin Campus Center of
Worcester Polytechnic Institute (WPI), and consists of a day-long
Main Event on Friday, and a GNU Radio Hacking Workshop (GRHW) on the
evening before. People are welcome to attend either or both.
*********************************************************************
MAIN EVENT
Friday May 22, 7:30 AM - 4 PM
KEYNOTE SPEAKER:
* Professor frederic harris, San Diego State University
INVITED SPEAKERS:
* Professor Miriam Leeser, Northeastern University
* Professor Mieczyslaw Kokar, Northeastern University
TECHNICAL POSTER PRESENTATIONS:
* Covering the recent work in SDR and cognitive radio technology
* Poster presentations are now being solicited
* See link at the bottom of this email to submit your abstract
SPONSORS:
* The MathWorks Inc.
* National Instruments / Ettus Research
* MediaTek Wireless Inc.
* Wireless Innovation Laboratory (WI Lab) at WPI
DEMOS & TECHNICAL SEMINARS FROM:
* The MathWorks Inc.
* National Instruments / Ettus Research
COMPLIMENTARY:
* Free parking
* Free breakfast, lunch, coffee provided
The Main Event features invited speakers, technical poster
presentation sessions, hardware and software demonstrations from the
event sponsors, and two technical seminars, all focusing on recent
work in SDR and cognitive radio technology.
The event provides an excellent networking opportunity and a terrific
venue to exchange thoughts and ideas with other people working in
the SDR space.
*********************************************************************
GNU Radio Hacking Workshop (GRHW)
Thursday May 21, 5 PM - 9:30 PM
HOST:
* Dr. Tom Rondeau, Rondeau Research LLC
COMPLIMENTARY:
* Free parking
* Free pizza, drinks, and dessert provided
The GRHW is a great opportunity for people to learn about how to
productively use GNU Radio and USRP devices. The workshop is aimed
at both novice users as well as at those with some previous basic
experience.
The GRHW will be run by Dr. Tom Rondeau, who will briefly speak about
the current state and future directions of the GNU Radio project.
Afterwards, a brief GNU Radio tutorial will follow.
Then attendees will work individually or in groups to implement a
communications system from scratch, with guidance from on-hand staff
to answer questions and help with problems. A working system will be
presented at the end.
Attendees are required to bring their own laptops, but USRP radios as
well as bootable live USB flash drives will be provided. Nothing will
need to be installed on attendees' laptops.
*********************************************************************
REGISTRATION
* Registration is completely free
* Registration takes less than 5 minutes
* Registration includes free parking and free food
* You must register online in order to receive a voucher for
free parking and free food
* Attendance, food, parking are all limited, so please register
online as soon as possible to secure your spot
* Registration deadline is Friday May 15
* See link at the bottom of this announcement to register online
* Your registration information will be kept confidential and
private, and will *not* be shared with any other third-party
*********************************************************************
LINKS
REGISTRATION:
https://docs.google.com/forms/d/19sEkp0YOF17BGl_8wVCB2W66-entErgziyCEaY6Bi94/viewform
POSTER ABSTRACT SUBMISSION:
https://docs.google.com/forms/d/1UIixAhRdaTHP7eNDxD7kwwmKfFQlvXB-DKDFjJupwHo/viewform
*********************************************************************
ADDITIONAL INFORMATION
More information, and the event schedule,
for this event can be found at our website:
http://www.sdr-boston.org/
*********************************************************************
EOF
*********************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150420/5385d13b/attachment-0001.html>
------------------------------
Message: 27
Date: Tue, 21 Apr 2015 10:34:54 +0200
From: Sanjoy Basak <[email protected]>
To: Martin Braun <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] time sync 2 ettus x310
Message-ID:
<CAJPQ1a00f9+nsOtj6utmJYBKTTq3LCLuX_nmzhYWX==-yw9...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Mr. Martin,
Thanks for the reply. Yes, right now I am not using octoclock, so the
problem while using 2 USRPsis understandable.
However, regarding distortion, yes I am having distortion at the beginning
when I am using one usrp for SISO case for x310. I found this problem even
in b210 as well. I wonder why no one discussed or how did they actually
solved for radar uses. But I hope I would get my solution here.
[image: Inline image 1]
This is a figure of xcorr of rx and tx signal. The red marked distortion I
am having almost always. I don't know the reason. If I drop few bins in my
binary file and then start receiving my signal then I am getting an
undistorted signal looks like the following.( I am transmitting and
receiving using binary file).
However, dropping bins is undesirable for radar application.
[image: Inline image 3]
If I use the distorted frame, as obvious I get distorted result. However,
after dropping bins the fresh frame gives me the exact result after signal
processing in matlab.
Can you please tell me how to avoid this distortion at the beginning?
best regards
Sanjoy
On Tue, Apr 21, 2015 at 12:10 AM, Martin Braun via USRP-users <
[email protected]> wrote:
> Sanjoy,
>
> if you want to do radar, you need to make sure both devices are
> connected to the same external reference. For radar, you can't run off
> of separate clocks.
>
> We've confirmed timing accuracy across devices on the nanosecond scale
> in the past (using OctoClocks for clock distribution).
>
> Cheers,
> M
>
> On 17.04.2015 06:00, Sanjoy Basak via USRP-users wrote:
> > Hi all,
> > I am trying to sync 2 ettus x310 in time. However, I am always having a
> > distortion at the beginning after receiving, and there is always a
> > delay of few microseconds between the tx and rx. I put tx in one x310
> > and rx in another x310 and its in a wired connection. GPS antenna is
> > connected to one usrp(with Tx) and another one is on external ref(Rx).
> >
> > So now if I check the last pps on both usrp; it shows tx:0; rx:2s;
> > then I am compensating it making it set_start_time both at for 4s. So
> > ideally I should get time synced tx and rx signal.
> >
> > But I am getting distortion in Rx signal for 2seconds at the beginning;
> > this is constant for every sampling freq; so if in that region I have my
> > rx signal I can't retrieve that as the distortion is already introduced
> > there.
> > As I am trying to implement radar with x310, this is a serious problem
> > for me. As within first 2 seconds and few microseconds I can't receive
> > anything.
> >
> > I would really appreciate any kind of suggestion that come through. If
> > anyone have question regarding setup or python code please ask.
> > Thanks for reading.
> >
> > Best regards
> > Sanjoy
> >
> >
> >
> > _______________________________________________
> > 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/20150421/9d3079fc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: untitled2.jpg
Type: image/jpeg
Size: 18723 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150421/9d3079fc/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: untitled.jpg
Type: image/jpeg
Size: 122891 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150421/9d3079fc/attachment-0003.jpg>
------------------------------
Message: 28
Date: Tue, 21 Apr 2015 15:35:59 +0200
From: Johnathan Rodgers <[email protected]>
To: Martin Braun <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Latency Through RF NoC on X310
Message-ID:
<cacjvfc7zv7p_-2cwkpc6in9vwrk_e1j1l6lxfrbq5y-gb0b...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
Is there an alternative solution to measure the minimum loopback latency in
the fpga ?
I tried to do as follow (radio0 --> radio1) with RFnoc in grc without any
success : radio0 stays connected.
Thanks in advance.
Johnathan
Le 19 mars 2015 23:28, "Martin Braun" <[email protected]> a ?crit :
> FG == flow graph (what GRC produces).
>
> What I mean is a flow graph such as this: http://imgur.com/LuBHfxp
>
> However, we just yesterday realized that if you do this, the Rx radio
> won't be kicked off. We'll have a fix for that soon.
>
> Cheers,
> M
>
> On 19.03.2015 14:53, Johnathan Rodgers wrote:
>
>> Hi,
>> Martin, what do you mean by :
>> "To measure loopback latency, you'd need a simple GRC FG that connects
>> the rx radio to the tx directly on the FPGA".
>> Is it a simple radio0 --> radio1 connection in Gnuradio with a src/sink ?
>> What does FG mean ?
>> Thanks in advance.
>> Johnathan
>>
>> Nevermind again.
>>
>> On Wed, Mar 18, 2015 at 4:14 PM, John Malsbury
>> <[email protected] <mailto:[email protected]>>
>> wrote:
>>
>> "Traceback (most recent call last):
>> File "/home/jmalsbury/src/gr-ettus/build/top_block.py", line 122,
>> in <module>
>> tb = top_block()
>> File "/home/jmalsbury/src/gr-ettus/build/top_block.py", line 63,
>> in __init__
>> self.device3,
>> File
>> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
>> line 93, in __getattr__
>> return getattr(self._impl, name)
>> AttributeError: 'top_block_sptr' object has no attribute 'device3'"
>>
>> Am I missing some device args?
>>
>> On Wed, Mar 18, 2015 at 4:07 PM, John Malsbury
>> <[email protected] <mailto:[email protected]>>
>> wrote:
>>
>> I'm blind. disregard
>>
>> On Wed, Mar 18, 2015 at 4:00 PM, John Malsbury
>> <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> So... is there an RF NoC 101? I've used the UHD src/sink in
>> the UHD->RF NoC category. is there anything I need to
>> specify to route from Rx/Radio0 to RxRadio1?
>>
>> -John
>>
>>
>>
>> On Fri, Mar 13, 2015 at 2:21 PM, Martin Braun via USRP-users
>> <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Yes, you can reduce the 'spp' value. It defaults to 364,
>> because that's what fits into a standard MTU.
>>
>> To measure loopback latency, you'd need a simple GRC FG
>> that connects the rx radio to the tx directly on the
>> FPGA, and a scope or something to see the delay. In GNU
>> Radio, give the rx radio a stream arg value 'spp=20' or
>> whatever. There may be limits to the size, and
>> non-multiples of 64-bits won't do you any good (2 sc16
>> samples per line).
>>
>> M
>>
>>
>> On 13.03.2015 11:32, John Malsbury via USRP-users wrote:
>>
>> Are there any UHD tricks I might use to stream the
>> output of a radio
>> block through RF NoC, directly to the other radio
>> block for re
>> transmission, without any FPGA mods? I would like
>> to test/measure the
>> lowest delay possible across the rx frontend, ADCs,
>> RF NoC, DACs and tx
>> frontend...
>>
>> Are there knobs to tweak to reduce latency across RF
>> NoC (samples/frame
>> or equivalent)?
>>
>> -John
>>
>>
>> _________________________________________________
>> USRP-users mailing list
>> [email protected]
>> <mailto:[email protected]>
>>
>> http://lists.ettus.com/__mailman/listinfo/usrp-users___lists.ettus.com
>> <
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>
>>
>>
>> _________________________________________________
>> USRP-users mailing list
>> [email protected]
>> <mailto:[email protected]>
>>
>> http://lists.ettus.com/__mailman/listinfo/usrp-users___lists.ettus.com
>> <
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150421/8f469f7c/attachment-0001.html>
------------------------------
Message: 29
Date: Tue, 21 Apr 2015 08:07:07 -0700
From: Neel Pandeya <[email protected]>
To: [email protected]
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] ZPU Interrupt Service Routine(ISR)
Message-ID:
<CACaXmv8uwbqOdmdoNcD2zioisiN1sSZMmLu9weAD9-=pddd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Mojtaba Rostami:
The third generation ZPU firmware does not use IRQs. The IRQ signal is
hard-wired to 1'b0 in Verilog. For examples on how to use the PIC, you can
look at the USRP2 firmware files in uhd/firmware/usrp2/lib/pic.{h,c} (see
the links below).
https://github.com/EttusResearch/uhd/blob/master/firmware/usrp2/lib/pic.c
https://github.com/EttusResearch/uhd/blob/master/firmware/usrp2/lib/pic.h
Which USRP are you using??
--Neel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150421/e9d2ff8a/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 56, Issue 21
******************************************
