Send USRP-users mailing list submissions to
usrp-users@lists.ettus.com
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
usrp-users-requ...@lists.ettus.com
You can reach the person managing the list at
usrp-users-ow...@lists.ettus.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Any way to build JUST uhd_usrp_probe? (Martin Braun)
2. Re: RFNOC image for E310 (Ben Lapointe)
3. Re: RFNOC image for E310 (Philip Balister)
4. Re: RFNOC image for E310 (Philip Balister)
5. Regarding USRP B210 Tuning Frequency (Kiran Karra)
6. Re: Regarding USRP B210 Tuning Frequency (Marcus D. Leech)
7. Re: Regarding USRP B210 Tuning Frequency (Ron Economos)
8. NO UHD devices found for E100 (Jeon)
9. Re: NO UHD devices found for E100 (Marcus M?ller)
10. Re: RFNOC image for E310 (Sylvain Munaut)
11. missing library for E310 cross-compile (Jason Matusiak)
12. Re: missing library for E310 cross-compile (Philip Balister)
13. Re: Regarding USRP B210 Tuning Frequency (Kiran Karra)
14. Re: Regarding USRP B210 Tuning Frequency (Kiran Karra)
15. Re: Regarding USRP B210 Tuning Frequency (Kiran Karra)
16. Re: missing library for E310 cross-compile (Jason Matusiak)
17. Re: missing library for E310 cross-compile (Philip Balister)
18. Re: missing library for E310 cross-compile (Jason Matusiak)
19. Re: Regarding USRP B210 Tuning Frequency (Marcus M?ller)
20. Re: missing library for E310 cross-compile (Philip Balister)
21. Re: Regarding USRP B210 Tuning Frequency (Marcus M?ller)
22. Re: Regarding USRP B210 Tuning Frequency (mle...@ripnet.com)
23. Re: missing library for E310 cross-compile (Jason Matusiak)
24. Re: missing library for E310 cross-compile (Philip Balister)
25. Re: .bin make issues (Aaron Henderson)
----------------------------------------------------------------------
Message: 1
Date: Wed, 24 Jun 2015 09:20:31 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Any way to build JUST uhd_usrp_probe?
Message-ID: <558ad8cf.2000...@ettus.com>
Content-Type: text/plain; charset=windows-1252
On 24.06.2015 04:25, Jason Matusiak via USRP-users wrote:
> What I am trying to figure out is if there is a quick way to rebuild the
> uhd_usrp_probe binary without rebuilding all the other pieces (trying to
> cut down on my recompiling loop).
Don't think this was mentioned in this thread; but 'make -jX
uhd_usrp_probe' will do that. Of course, this util depends on libuhd, so
you might not necessarily save that much compilation time.
M
------------------------------
Message: 2
Date: Wed, 24 Jun 2015 16:14:23 -0400
From: Ben Lapointe <ben.lapoi...@gmail.com>
To: Jason Matusiak <ja...@gardettoengineering.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] RFNOC image for E310
Message-ID:
<CACkXhTES8p7Rn=rpwu0umxsurwcqdgc89g06u5kt3ra8e2g...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I also downloaded the demo version and followed all of the steps to update
the card; however, I am having trouble getting gnuradio-companion to run.
When I type gnuradio-companion, I get a long list of warnings (shown
below) and then a segmentation fault. Any ideas??
Steps that I did after creating the fido-rfnoc-test demo image:
- remove S34gps_prep and S35gpsd from /etc/rc5.d
- run uhd_images_downloader
- reboot
- enabled X11 forwarding in /etc/ssh/sshd_config
- reboot
- gnuradio-companion
Warnings that I get between running gnuradio-companion and the seg fault:
root@ettus-e300:~# gnuradio-companion &
[1] 951
root@ettus-e300:~#
** (process:951): WARNING **: Trying to register gtype 'GMountMountFlags'
as enum when in fact it is of type 'GFlags'
** (process:951): WARNING **: Trying to register gtype 'GDriveStartFlags'
as enum when in fact it is of type 'GFlags'
** (process:951): WARNING **: Trying to register gtype 'GSocketMsgFlags' as
enum when in fact it is of type 'GFlags'
/usr/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py:57: GtkWarning:
could not open display
warnings.warn(str(e), _gtk.Warning)
/usr/lib/python2.7/site-packages/gnuradio/grc/gui/Actions.py:32:
GtkWarning: IA__gdk_keymap_get_for_display: assertion 'GDK_IS_DISPLAY
(display)' failed
_keymap = gtk.gdk.keymap_get_default()
/usr/lib/python2.7/site-packages/gnuradio/grc/gui/Colors.py:24: GtkWarning:
IA__gdk_screen_get_system_colormap: assertion 'GDK_IS_SCREEN (screen)'
failed
_COLORMAP = gtk.gdk.colormap_get_system() #create all of the colors
Unable to import Colors
Warning: XML parsing failed:
Key "in_type" already exists in params
Ignoring: /usr/share/gnuradio/grc/blocks/uhd_rfnoc_streamer.xml
/usr/lib/python2.7/site-packages/gnuradio/grc/gui/MainWindow.py:75:
Warning: invalid (NULL) pointer instance
gtk.Window.__init__(self, gtk.WINDOW_TOPLEVEL)
/usr/lib/python2.7/site-packages/gnuradio/grc/gui/MainWindow.py:75:
Warning: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE
(instance)' failed
gtk.Window.__init__(self, gtk.WINDOW_TOPLEVEL)
/usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:180: GtkWarning:
IA__gtk_settings_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed
main_menu_item = main_action.create_menu_item()
/usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:180: Warning:
g_object_get: assertion 'G_IS_OBJECT (object)' failed
main_menu_item = main_action.create_menu_item()
/usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:180: Warning:
value "TRUE" of type 'gboolean' is invalid or out of range for property
'visible' of type 'gboolean'
main_menu_item = main_action.create_menu_item()
/usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:183: Warning:
invalid (NULL) pointer instance
main_menu = gtk.Menu()
/usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:183: Warning:
g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
main_menu = gtk.Menu()
/usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:186: GtkWarning:
IA__gtk_settings_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed
main_menu.append(action.create_menu_item() if action else
/usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:186: Warning:
g_object_get: assertion 'G_IS_OBJECT (object)' failed
main_menu.append(action.create_menu_item() if action else
/usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:186: Warning:
value "TRUE" of type 'gboolean' is invalid or out of range for property
'visible' of type 'gboolean'
main_menu.append(action.create_menu_item() if action else
/usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:157: Warning:
invalid (NULL) pointer instance
gtk.Toolbar.__init__(self)
/usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:157: Warning:
g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
gtk.Toolbar.__init__(self)
/usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:161: GtkWarning:
IA__gdk_screen_get_display: assertion 'GDK_IS_SCREEN (screen)' failed
self.add(action.create_tool_item())
/usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:161: Warning:
g_object_ref: assertion 'G_IS_OBJECT (object)' failed
self.add(action.create_tool_item())
/usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:163: GtkWarning:
IA__gdk_screen_get_display: assertion 'GDK_IS_SCREEN (screen)' failed
action.set_property('tooltip', action.get_property('tooltip'))
/usr/lib/python2.7/site-packages/gnuradio/grc/gui/BlockTreeWindow.py:60:
GtkWarning: IA__gdk_pango_context_get_for_screen: assertion 'GDK_IS_SCREEN
(screen)' failed
self.search_entry = gtk.Entry()
On Fri, Jun 19, 2015 at 9:18 AM, Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:
> >Thanks Philip, this worked great for me. I pulled down the demo version
> >and followed the steps to update my card. I then verified it by
> >creating a simple GRC that utilized some of the RFNoc blocks. The only
> >catch is to MAKE SURE you have a "Device3" block on the GRC for anything
> >running on the E310. Then you have to modify the Device Address of the
> >block to be "type=e3x0", then all is roses again.
> One other thing I should mention is the need to follow Philip's
> additional advice of: You'll need to remove S34gps_prep and S35gpsd from
> /etc/rc5.d (This stops gpsd from running). Then you also need to run
> uhd_images_downloader to get the proper fpga images. Finally restart.
>
> ~Jason
>
> _______________________________________________
> USRP-users mailing list
> 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/20150624/9144eb72/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 24 Jun 2015 17:16:40 -0400
From: Philip Balister <phi...@opensdr.com>
To: Ben Lapointe <ben.lapoi...@gmail.com>, Jason Matusiak
<ja...@gardettoengineering.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] RFNOC image for E310
Message-ID: <558b1e38.3010...@opensdr.com>
Content-Type: text/plain; charset=windows-1252
Did you ssh to the E310 with something like"
ssh -X address?
The line:
> /usr/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py:57: GtkWarning:
> could not open display
is suspicious.
Philip
On 06/24/2015 04:14 PM, Ben Lapointe via USRP-users wrote:
> Hi,
>
> I also downloaded the demo version and followed all of the steps to update
> the card; however, I am having trouble getting gnuradio-companion to run.
> When I type gnuradio-companion, I get a long list of warnings (shown
> below) and then a segmentation fault. Any ideas??
>
> Steps that I did after creating the fido-rfnoc-test demo image:
> - remove S34gps_prep and S35gpsd from /etc/rc5.d
> - run uhd_images_downloader
> - reboot
> - enabled X11 forwarding in /etc/ssh/sshd_config
> - reboot
> - gnuradio-companion
>
> Warnings that I get between running gnuradio-companion and the seg fault:
> root@ettus-e300:~# gnuradio-companion &
> [1] 951
> root@ettus-e300:~#
> ** (process:951): WARNING **: Trying to register gtype 'GMountMountFlags'
> as enum when in fact it is of type 'GFlags'
> ** (process:951): WARNING **: Trying to register gtype 'GDriveStartFlags'
> as enum when in fact it is of type 'GFlags'
> ** (process:951): WARNING **: Trying to register gtype 'GSocketMsgFlags' as
> enum when in fact it is of type 'GFlags'
> /usr/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py:57: GtkWarning:
> could not open display
> warnings.warn(str(e), _gtk.Warning)
> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Actions.py:32:
> GtkWarning: IA__gdk_keymap_get_for_display: assertion 'GDK_IS_DISPLAY
> (display)' failed
> _keymap = gtk.gdk.keymap_get_default()
> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Colors.py:24: GtkWarning:
> IA__gdk_screen_get_system_colormap: assertion 'GDK_IS_SCREEN (screen)'
> failed
> _COLORMAP = gtk.gdk.colormap_get_system() #create all of the colors
> Unable to import Colors
> Warning: XML parsing failed:
> Key "in_type" already exists in params
> Ignoring: /usr/share/gnuradio/grc/blocks/uhd_rfnoc_streamer.xml
> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/MainWindow.py:75:
> Warning: invalid (NULL) pointer instance
> gtk.Window.__init__(self, gtk.WINDOW_TOPLEVEL)
> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/MainWindow.py:75:
> Warning: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE
> (instance)' failed
> gtk.Window.__init__(self, gtk.WINDOW_TOPLEVEL)
> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:180: GtkWarning:
> IA__gtk_settings_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed
> main_menu_item = main_action.create_menu_item()
> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:180: Warning:
> g_object_get: assertion 'G_IS_OBJECT (object)' failed
> main_menu_item = main_action.create_menu_item()
> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:180: Warning:
> value "TRUE" of type 'gboolean' is invalid or out of range for property
> 'visible' of type 'gboolean'
> main_menu_item = main_action.create_menu_item()
> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:183: Warning:
> invalid (NULL) pointer instance
> main_menu = gtk.Menu()
> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:183: Warning:
> g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> main_menu = gtk.Menu()
> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:186: GtkWarning:
> IA__gtk_settings_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed
> main_menu.append(action.create_menu_item() if action else
> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:186: Warning:
> g_object_get: assertion 'G_IS_OBJECT (object)' failed
> main_menu.append(action.create_menu_item() if action else
> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:186: Warning:
> value "TRUE" of type 'gboolean' is invalid or out of range for property
> 'visible' of type 'gboolean'
> main_menu.append(action.create_menu_item() if action else
> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:157: Warning:
> invalid (NULL) pointer instance
> gtk.Toolbar.__init__(self)
> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:157: Warning:
> g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> gtk.Toolbar.__init__(self)
> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:161: GtkWarning:
> IA__gdk_screen_get_display: assertion 'GDK_IS_SCREEN (screen)' failed
> self.add(action.create_tool_item())
> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:161: Warning:
> g_object_ref: assertion 'G_IS_OBJECT (object)' failed
> self.add(action.create_tool_item())
> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:163: GtkWarning:
> IA__gdk_screen_get_display: assertion 'GDK_IS_SCREEN (screen)' failed
> action.set_property('tooltip', action.get_property('tooltip'))
> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/BlockTreeWindow.py:60:
> GtkWarning: IA__gdk_pango_context_get_for_screen: assertion 'GDK_IS_SCREEN
> (screen)' failed
> self.search_entry = gtk.Entry()
>
>
> On Fri, Jun 19, 2015 at 9:18 AM, Jason Matusiak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>>> Thanks Philip, this worked great for me. I pulled down the demo version
>>> and followed the steps to update my card. I then verified it by
>>> creating a simple GRC that utilized some of the RFNoc blocks. The only
>>> catch is to MAKE SURE you have a "Device3" block on the GRC for anything
>>> running on the E310. Then you have to modify the Device Address of the
>>> block to be "type=e3x0", then all is roses again.
>> One other thing I should mention is the need to follow Philip's
>> additional advice of: You'll need to remove S34gps_prep and S35gpsd from
>> /etc/rc5.d (This stops gpsd from running). Then you also need to run
>> uhd_images_downloader to get the proper fpga images. Finally restart.
>>
>> ~Jason
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 4
Date: Wed, 24 Jun 2015 18:55:27 -0400
From: Philip Balister <phi...@opensdr.com>
To: Ben Lapointe <ben.lapoi...@gmail.com>, Jason Matusiak
<ja...@gardettoengineering.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] RFNOC image for E310
Message-ID: <558b355f.2060...@opensdr.com>
Content-Type: text/plain; charset=windows-1252
On 06/24/2015 05:16 PM, Philip Balister via USRP-users wrote:
> Did you ssh to the E310 with something like"
>
> ssh -X address?
>
> The line:
>
>> /usr/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py:57: GtkWarning:
>> could not open display
>
>
> is suspicious.
I've proposed:
https://github.com/balister/gnuradio/commit/5946806c62e8a04f4b348455ce8aa762749ee59d
to make the problem clear.
Philip
>
> Philip
>
>
> On 06/24/2015 04:14 PM, Ben Lapointe via USRP-users wrote:
>> Hi,
>>
>> I also downloaded the demo version and followed all of the steps to update
>> the card; however, I am having trouble getting gnuradio-companion to run.
>> When I type gnuradio-companion, I get a long list of warnings (shown
>> below) and then a segmentation fault. Any ideas??
>>
>> Steps that I did after creating the fido-rfnoc-test demo image:
>> - remove S34gps_prep and S35gpsd from /etc/rc5.d
>> - run uhd_images_downloader
>> - reboot
>> - enabled X11 forwarding in /etc/ssh/sshd_config
>> - reboot
>> - gnuradio-companion
>>
>> Warnings that I get between running gnuradio-companion and the seg fault:
>> root@ettus-e300:~# gnuradio-companion &
>> [1] 951
>> root@ettus-e300:~#
>> ** (process:951): WARNING **: Trying to register gtype 'GMountMountFlags'
>> as enum when in fact it is of type 'GFlags'
>> ** (process:951): WARNING **: Trying to register gtype 'GDriveStartFlags'
>> as enum when in fact it is of type 'GFlags'
>> ** (process:951): WARNING **: Trying to register gtype 'GSocketMsgFlags' as
>> enum when in fact it is of type 'GFlags'
>> /usr/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py:57: GtkWarning:
>> could not open display
>> warnings.warn(str(e), _gtk.Warning)
>> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Actions.py:32:
>> GtkWarning: IA__gdk_keymap_get_for_display: assertion 'GDK_IS_DISPLAY
>> (display)' failed
>> _keymap = gtk.gdk.keymap_get_default()
>> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Colors.py:24: GtkWarning:
>> IA__gdk_screen_get_system_colormap: assertion 'GDK_IS_SCREEN (screen)'
>> failed
>> _COLORMAP = gtk.gdk.colormap_get_system() #create all of the colors
>> Unable to import Colors
>> Warning: XML parsing failed:
>> Key "in_type" already exists in params
>> Ignoring: /usr/share/gnuradio/grc/blocks/uhd_rfnoc_streamer.xml
>> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/MainWindow.py:75:
>> Warning: invalid (NULL) pointer instance
>> gtk.Window.__init__(self, gtk.WINDOW_TOPLEVEL)
>> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/MainWindow.py:75:
>> Warning: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE
>> (instance)' failed
>> gtk.Window.__init__(self, gtk.WINDOW_TOPLEVEL)
>> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:180: GtkWarning:
>> IA__gtk_settings_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed
>> main_menu_item = main_action.create_menu_item()
>> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:180: Warning:
>> g_object_get: assertion 'G_IS_OBJECT (object)' failed
>> main_menu_item = main_action.create_menu_item()
>> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:180: Warning:
>> value "TRUE" of type 'gboolean' is invalid or out of range for property
>> 'visible' of type 'gboolean'
>> main_menu_item = main_action.create_menu_item()
>> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:183: Warning:
>> invalid (NULL) pointer instance
>> main_menu = gtk.Menu()
>> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:183: Warning:
>> g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
>> main_menu = gtk.Menu()
>> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:186: GtkWarning:
>> IA__gtk_settings_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed
>> main_menu.append(action.create_menu_item() if action else
>> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:186: Warning:
>> g_object_get: assertion 'G_IS_OBJECT (object)' failed
>> main_menu.append(action.create_menu_item() if action else
>> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:186: Warning:
>> value "TRUE" of type 'gboolean' is invalid or out of range for property
>> 'visible' of type 'gboolean'
>> main_menu.append(action.create_menu_item() if action else
>> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:157: Warning:
>> invalid (NULL) pointer instance
>> gtk.Toolbar.__init__(self)
>> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:157: Warning:
>> g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
>> gtk.Toolbar.__init__(self)
>> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:161: GtkWarning:
>> IA__gdk_screen_get_display: assertion 'GDK_IS_SCREEN (screen)' failed
>> self.add(action.create_tool_item())
>> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:161: Warning:
>> g_object_ref: assertion 'G_IS_OBJECT (object)' failed
>> self.add(action.create_tool_item())
>> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/Bars.py:163: GtkWarning:
>> IA__gdk_screen_get_display: assertion 'GDK_IS_SCREEN (screen)' failed
>> action.set_property('tooltip', action.get_property('tooltip'))
>> /usr/lib/python2.7/site-packages/gnuradio/grc/gui/BlockTreeWindow.py:60:
>> GtkWarning: IA__gdk_pango_context_get_for_screen: assertion 'GDK_IS_SCREEN
>> (screen)' failed
>> self.search_entry = gtk.Entry()
>>
>>
>> On Fri, Jun 19, 2015 at 9:18 AM, Jason Matusiak via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>>> Thanks Philip, this worked great for me. I pulled down the demo version
>>>> and followed the steps to update my card. I then verified it by
>>>> creating a simple GRC that utilized some of the RFNoc blocks. The only
>>>> catch is to MAKE SURE you have a "Device3" block on the GRC for anything
>>>> running on the E310. Then you have to modify the Device Address of the
>>>> block to be "type=e3x0", then all is roses again.
>>> One other thing I should mention is the need to follow Philip's
>>> additional advice of: You'll need to remove S34gps_prep and S35gpsd from
>>> /etc/rc5.d (This stops gpsd from running). Then you also need to run
>>> uhd_images_downloader to get the proper fpga images. Finally restart.
>>>
>>> ~Jason
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
------------------------------
Message: 5
Date: Wed, 24 Jun 2015 19:50:43 -0400
From: Kiran Karra <kkarr...@vt.edu>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Regarding USRP B210 Tuning Frequency
Message-ID: <558b4253.9080...@vt.edu>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hello,
I am trying to use the USRP for a coherent transmitter application (I
have a spread spectrum waveform where I know how many zero crossings of
the carrier need to occur within each chip of the transmitted waveform)
and have several questions regarding the USRP B210 in this light:
1.) Is the DAC clock and the LO which mixes up the complex baseband
input to a desired frequency driven by the same reference oscillator?
If so, I would conclude that generating the spread data and mixing it
with the USRP sink block would be a coherent operation, but I am not sure.
2.) I looked at the specification for the AD9361 chipset
(http://www.analog.com/media/en/technical-documentation/data-sheets/AD9361.pdf)
which says that the LO step size is 2.4 Hz. I need my transmit
frequency to be *exactly* 1575.42 MHz ... so I'm wondering if because
the minimum frequency supported by the chipset is 70 MHz, and the
stepsize is 2.4Hz, doing the following math (1575.42-70)*1e6/2.4 yields
a non-integer value, that I am not getting exactly 1575.42 MHz as the
output frequency? When I run my waveform, I get the following output
from the UHD driver, which is also seemingly contradicting itself:
-- Asking for clock rate 32.000000 MHz
-- Actually got clock rate 32.000000 MHz
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
-- Tune Request: 1575.420000 MHz
-- The RF LO does not support the requested frequency:
-- Requested LO Frequency: 1575.420000 MHz
-- RF LO Result: 1575.420000 MHz
-- Attempted to use the DSP to reach the requested frequency:
-- Desired DSP Frequency: 0.000000 MHz
-- DSP Result: 0.000000 MHz
-- Successfully tuned to 1575.420000 MHz
What exactly does it mean when it says that the RF LO doesn't support
the requested frequency, but then it seems to successfully tune to that
frequency? Is the output I am seeing a "rounded" version, or is it
exactly what the LO is tuned to? The output is seemingly contradicting.
Thanks!
Kiran
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150624/685fe69e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2411 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150624/685fe69e/attachment-0001.p7s>
------------------------------
Message: 6
Date: Wed, 24 Jun 2015 20:22:17 -0400
From: "Marcus D. Leech" <mle...@ripnet.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Regarding USRP B210 Tuning Frequency
Message-ID: <558b49b9.5010...@ripnet.com>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 06/24/2015 07:50 PM, Kiran Karra via USRP-users wrote:
> Hello,
>
> I am trying to use the USRP for a coherent transmitter application (I
> have a spread spectrum waveform where I know how many zero crossings
> of the carrier need to occur within each chip of the transmitted
> waveform) and have several questions regarding the USRP B210 in this
> light:
>
> 1.) Is the DAC clock and the LO which mixes up the complex baseband
> input to a desired frequency driven by the same reference oscillator?
> If so, I would conclude that generating the spread data and mixing it
> with the USRP sink block would be a coherent operation, but I am not sure.
>
> 2.) I looked at the specification for the AD9361 chipset
> (http://www.analog.com/media/en/technical-documentation/data-sheets/AD9361.pdf)
>
> which says that the LO step size is 2.4 Hz. I need my transmit
> frequency to be *exactly* 1575.42 MHz ... so I'm wondering if because
> the minimum frequency supported by the chipset is 70 MHz, and the
> stepsize is 2.4Hz, doing the following math (1575.42-70)*1e6/2.4
> yields a non-integer value, that I am not getting exactly 1575.42 MHz
> as the output frequency? When I run my waveform, I get the following
> output from the UHD driver, which is also seemingly contradicting itself:
>
>
> -- Asking for clock rate 32.000000 MHz
> -- Actually got clock rate 32.000000 MHz
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
> -- Tune Request: 1575.420000 MHz
> -- The RF LO does not support the requested frequency:
> -- Requested LO Frequency: 1575.420000 MHz
> -- RF LO Result: 1575.420000 MHz
> -- Attempted to use the DSP to reach the requested frequency:
> -- Desired DSP Frequency: 0.000000 MHz
> -- DSP Result: 0.000000 MHz
> -- Successfully tuned to 1575.420000 MHz
>
>
> What exactly does it mean when it says that the RF LO doesn't support
> the requested frequency, but then it seems to successfully tune to
> that frequency? Is the output I am seeing a "rounded" version, or is
> it exactly what the LO is tuned to? The output is seemingly
> contradicting.
>
> Thanks!
> Kiran
>
The DSP in the FPGA will "mop up" any granularity issues in the LO
tuning, using a DUC. This is pretty a pretty standard thing to do in
the RF DSP
world.
Also, what do you mean by "exact"?? The on-board clock is good to about
2PPM, and you can get closer and closer to "exact" as you get into more
and more exotic external references. An OCXO would be good to about
20-50PPB. A GPSDO to about 5-10PPB, an Rb source, perhaps 0.5PPB.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150624/5c010d54/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 24 Jun 2015 17:42:44 -0700
From: Ron Economos <w...@comcast.net>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Regarding USRP B210 Tuning Frequency
Message-ID: <558b4e84.3010...@comcast.net>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
You can use uhd_fft to display the actual DSP frequency.
uhd_fft -f 1575420000 -s 8000000
On my B210, this gives a DSP frequency of -0.484288 Hz (shown as -484.288m).
The UHD driver isn't being contradictory, it just isn't using enough
significant digits.
Ron
On 06/24/2015 04:50 PM, Kiran Karra via USRP-users wrote:
> Hello,
>
> I am trying to use the USRP for a coherent transmitter application (I
> have a spread spectrum waveform where I know how many zero crossings
> of the carrier need to occur within each chip of the transmitted
> waveform) and have several questions regarding the USRP B210 in this
> light:
>
> 1.) Is the DAC clock and the LO which mixes up the complex baseband
> input to a desired frequency driven by the same reference oscillator?
> If so, I would conclude that generating the spread data and mixing it
> with the USRP sink block would be a coherent operation, but I am not sure.
>
> 2.) I looked at the specification for the AD9361 chipset
> (http://www.analog.com/media/en/technical-documentation/data-sheets/AD9361.pdf)
>
> which says that the LO step size is 2.4 Hz. I need my transmit
> frequency to be *exactly* 1575.42 MHz ... so I'm wondering if because
> the minimum frequency supported by the chipset is 70 MHz, and the
> stepsize is 2.4Hz, doing the following math (1575.42-70)*1e6/2.4
> yields a non-integer value, that I am not getting exactly 1575.42 MHz
> as the output frequency? When I run my waveform, I get the following
> output from the UHD driver, which is also seemingly contradicting itself:
>
>
> -- Asking for clock rate 32.000000 MHz
> -- Actually got clock rate 32.000000 MHz
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
> -- Tune Request: 1575.420000 MHz
> -- The RF LO does not support the requested frequency:
> -- Requested LO Frequency: 1575.420000 MHz
> -- RF LO Result: 1575.420000 MHz
> -- Attempted to use the DSP to reach the requested frequency:
> -- Desired DSP Frequency: 0.000000 MHz
> -- DSP Result: 0.000000 MHz
> -- Successfully tuned to 1575.420000 MHz
>
>
> What exactly does it mean when it says that the RF LO doesn't support
> the requested frequency, but then it seems to successfully tune to
> that frequency? Is the output I am seeing a "rounded" version, or is
> it exactly what the LO is tuned to? The output is seemingly
> contradicting.
>
> Thanks!
> Kiran
>
>
> _______________________________________________
> USRP-users mailing list
> 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/20150624/9e365e6d/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 25 Jun 2015 15:24:13 +0900
From: Jeon <sjeon87+usrpus...@gmail.com>
To: USRP users mailing list <usrp-users@lists.ettus.com>
Subject: [USRP-users] NO UHD devices found for E100
Message-ID:
<CACfn7v7d_7fVj9d-QS9OoVuwMqH-Kuf=q=y1OK-fFqSmst=t...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I am trying to connect USRP E100 to my PC, ubuntu 14.04
But I am having a difficulty on finding uhd device.
The followings what I have done til now:
$ sudo ethtool eth0 # check if ethernet is gigabit
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: external
Auto-negotiation: on
Supports Wake-on: g
Wake-on: g
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
$ ifconfig # check if PC and E100 is in a network
eth0 Link encap:Ethernet HWaddr 00:25:64:c2:16:be
inet addr:192.168.10.1 Bcast:192.168.10.255
Mask:255.255.255.0
inet6 addr: fe80::225:64ff:fec2:16be/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:251 errors:0 dropped:0 overruns:0 frame:0
TX packets:1943 errors:4 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:254997 (254.9 KB) TX bytes:193482 (193.4 KB)
Interrupt:16
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:839 errors:0 dropped:0 overruns:0 frame:0
TX packets:839 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:66205 (66.2 KB) TX bytes:66205 (66.2 KB)
$ uhd_find_devices # check if there is USRP connected
linux; GNU C++ version 4.8.2; Boost_105400;
UHD_003.009.git-189-g6b64d9bb
NO UHD Devices Found
Could you suggest anything else what I haven't done yet?
I use Cat 5 ethernet cable to connect USRP and PC (not sure it is 5e, I'll
check it.)
Regards,
Jeon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150625/546a63c2/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 25 Jun 2015 08:30:06 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] NO UHD devices found for E100
Message-ID: <558b9fee.3040...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
Hi Jeon,
I assume you execute uhd_find_devices on your PC?
The E100 is not like e.g. the N200, it doesn't connect to a PC like a
peripheral.
Hence, uhd_find_device doesn't detect it, and UHD applications on your
PC can't talk to the E100.
Instead, it has an embedded computer that runs a Linux of its own, and
can be used to run signal processing applications.
Best regards,
Marcus
On 06/25/2015 08:24 AM, Jeon via USRP-users wrote:
> I am trying to connect USRP E100 to my PC, ubuntu 14.04
>
> But I am having a difficulty on finding uhd device.
>
> The followings what I have done til now:
>
> $ sudo ethtool eth0 # check if ethernet is gigabit
> Settings for eth0:
> Supported ports: [ TP MII ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Half 1000baseT/Full
> Supported pause frame use: Symmetric Receive-only
> Supports auto-negotiation: Yes
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Half 1000baseT/Full
> Advertised pause frame use: Symmetric Receive-only
> Advertised auto-negotiation: Yes
> Speed: 100Mb/s
> Duplex: Full
> Port: MII
> PHYAD: 1
> Transceiver: external
> Auto-negotiation: on
> Supports Wake-on: g
> Wake-on: g
> Current message level: 0x000000ff (255)
> drv probe link timer ifdown ifup rx_err tx_err
> Link detected: yes
>
> $ ifconfig # check if PC and E100 is in a network
> eth0 Link encap:Ethernet HWaddr 00:25:64:c2:16:be
> inet addr:192.168.10.1 Bcast:192.168.10.255
> Mask:255.255.255.0
> inet6 addr: fe80::225:64ff:fec2:16be/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:251 errors:0 dropped:0 overruns:0 frame:0
> TX packets:1943 errors:4 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:254997 (254.9 KB) TX bytes:193482 (193.4 KB)
> Interrupt:16
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> inet6 addr: ::1/128 Scope:Host
> UP LOOPBACK RUNNING MTU:65536 Metric:1
> RX packets:839 errors:0 dropped:0 overruns:0 frame:0
> TX packets:839 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:66205 (66.2 KB) TX bytes:66205 (66.2 KB)
>
> $ uhd_find_devices # check if there is USRP connected
> linux; GNU C++ version 4.8.2; Boost_105400;
> UHD_003.009.git-189-g6b64d9bb
>
> NO UHD Devices Found
>
> Could you suggest anything else what I haven't done yet?
>
> I use Cat 5 ethernet cable to connect USRP and PC (not sure it is 5e,
> I'll check it.)
>
> Regards,
> Jeon.
>
>
> _______________________________________________
> USRP-users mailing list
> 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/20150625/75af4abe/attachment-0001.html>
------------------------------
Message: 10
Date: Thu, 25 Jun 2015 09:00:00 +0200
From: Sylvain Munaut <246...@gmail.com>
To: Philip Balister <phi...@opensdr.com>
Cc: Ben Lapointe <ben.lapoi...@gmail.com>, Jason Matusiak
<ja...@gardettoengineering.com>, "usrp-users@lists.ettus.com"
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] RFNOC image for E310
Message-ID:
<CAHL+j0_iSV-D01Hq=7Yj0+iu18JwF97=ecece8dxjia0pkk...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
> Did you ssh to the E310 with something like"
>
> ssh -X address?
>
It's even better with ssh -Y address
Cheers,
Sylvain
------------------------------
Message: 11
Date: Thu, 25 Jun 2015 06:03:29 -0700
From: "Jason Matusiak" <ja...@gardettoengineering.com>
To: "Ettus Mail List" <usrp-users@lists.ettus.com>
Subject: [USRP-users] missing library for E310 cross-compile
Message-ID:
<20150625060329.ba066092a6e013ef68fa4f5a8d80e9ee.42a642e23c....@email02.secureserver.net>
Content-Type: text/plain; charset="utf-8"
Trying to cross-compile the uhd_usrp_probe for an E310 and when I run it
on the E310 I get:
root@ettus-e300:/# /usr/local/bin/uhd_usrp_probe --init-only
/usr/local/bin/uhd_usrp_probe: error while loading shared libraries:
libboost_date_time.so.1.56.0: cannot open shared object file: No such
file or directory
It looks like the E310 has ./usr/lib/libboost_date_time.so.1.57.0 on it.
I went and pulled down the alpha fido image from the ettus file repo and
reset my cross-compile on my host, but it is still trying to link to the
older libboost.
What is the best method to work through this? I see on my host the
binary is in
/usr/local/oecore-x86_64/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/lib,
so I could drag it from there over to my E310, but that seems like it is
only a temporary solution (what else will be considered missing).
~Jason
------------------------------
Message: 12
Date: Thu, 25 Jun 2015 09:10:12 -0400
From: Philip Balister <phi...@opensdr.com>
To: Jason Matusiak <ja...@gardettoengineering.com>, Ettus Mail List
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] missing library for E310 cross-compile
Message-ID: <558bfdb4.7010...@opensdr.com>
Content-Type: text/plain; charset=windows-1252
On 06/25/2015 09:03 AM, Jason Matusiak via USRP-users wrote:
> Trying to cross-compile the uhd_usrp_probe for an E310 and when I run it
> on the E310 I get:
> root@ettus-e300:/# /usr/local/bin/uhd_usrp_probe --init-only
> /usr/local/bin/uhd_usrp_probe: error while loading shared libraries:
> libboost_date_time.so.1.56.0: cannot open shared object file: No such
> file or directory
>
> It looks like the E310 has ./usr/lib/libboost_date_time.so.1.57.0 on it.
Are you using the SDK that matches the image? When I post an image, I
post the matching sdk in the same directory. It is possible I made a
mistake uploading files.
Philip
>
>
> I went and pulled down the alpha fido image from the ettus file repo and
> reset my cross-compile on my host, but it is still trying to link to the
> older libboost.
>
> What is the best method to work through this? I see on my host the
> binary is in
> /usr/local/oecore-x86_64/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/lib,
> so I could drag it from there over to my E310, but that seems like it is
> only a temporary solution (what else will be considered missing).
>
> ~Jason
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
------------------------------
Message: 13
Date: Thu, 25 Jun 2015 09:12:52 -0400
From: Kiran Karra <kkarr...@vt.edu>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Regarding USRP B210 Tuning Frequency
Message-ID: <558bfe54.9090...@vt.edu>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Hello Ron,
This is great information. Thanks for the help.
Kiran
On 06/24/2015 08:42 PM, Ron Economos via USRP-users wrote:
> You can use uhd_fft to display the actual DSP frequency.
>
> uhd_fft -f 1575420000 -s 8000000
>
> On my B210, this gives a DSP frequency of -0.484288 Hz (shown as
> -484.288m).
>
> The UHD driver isn't being contradictory, it just isn't using enough
> significant digits.
>
> Ron
>
> On 06/24/2015 04:50 PM, Kiran Karra via USRP-users wrote:
>> Hello,
>>
>> I am trying to use the USRP for a coherent transmitter application (I
>> have a spread spectrum waveform where I know how many zero crossings
>> of the carrier need to occur within each chip of the transmitted
>> waveform) and have several questions regarding the USRP B210 in this
>> light:
>>
>> 1.) Is the DAC clock and the LO which mixes up the complex baseband
>> input to a desired frequency driven by the same reference
>> oscillator? If so, I would conclude that generating the spread data
>> and mixing it with the USRP sink block would be a coherent operation,
>> but I am not sure.
>>
>> 2.) I looked at the specification for the AD9361 chipset
>> (http://www.analog.com/media/en/technical-documentation/data-sheets/AD9361.pdf)
>>
>> which says that the LO step size is 2.4 Hz. I need my transmit
>> frequency to be *exactly* 1575.42 MHz ... so I'm wondering if because
>> the minimum frequency supported by the chipset is 70 MHz, and the
>> stepsize is 2.4Hz, doing the following math (1575.42-70)*1e6/2.4
>> yields a non-integer value, that I am not getting exactly 1575.42 MHz
>> as the output frequency? When I run my waveform, I get the following
>> output from the UHD driver, which is also seemingly contradicting itself:
>>
>>
>> -- Asking for clock rate 32.000000 MHz
>> -- Actually got clock rate 32.000000 MHz
>> -- Performing timer loopback test... pass
>> -- Performing timer loopback test... pass
>> -- Tune Request: 1575.420000 MHz
>> -- The RF LO does not support the requested frequency:
>> -- Requested LO Frequency: 1575.420000 MHz
>> -- RF LO Result: 1575.420000 MHz
>> -- Attempted to use the DSP to reach the requested frequency:
>> -- Desired DSP Frequency: 0.000000 MHz
>> -- DSP Result: 0.000000 MHz
>> -- Successfully tuned to 1575.420000 MHz
>>
>>
>> What exactly does it mean when it says that the RF LO doesn't support
>> the requested frequency, but then it seems to successfully tune to
>> that frequency? Is the output I am seeing a "rounded" version, or is
>> it exactly what the LO is tuned to? The output is seemingly
>> contradicting.
>>
>> Thanks!
>> Kiran
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> 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/20150625/8140ea39/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2411 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150625/8140ea39/attachment-0001.p7s>
------------------------------
Message: 14
Date: Thu, 25 Jun 2015 09:16:37 -0400
From: Kiran Karra <kkarr...@vt.edu>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Regarding USRP B210 Tuning Frequency
Message-ID: <558bff35.3000...@vt.edu>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Hi Marcus,
Right, I understand there will be a variance between what the LO thinks
it is tuned to due to temperature and other "real world" effects.
Perhaps I miscommunicated my question, but I wanted to know if the LO
thought it was tuned exactly to the frequency I gave it. Ron Economos
gave another answer using uhd_fft which tells you exactly what the LO
*thinks* it is tuned to, which is of interest to me.
Also, is the DAC clock and the LO driven by the same reference oscillator?
Cheers,
Kiran
On 06/24/2015 08:22 PM, Marcus D. Leech via USRP-users wrote:
> On 06/24/2015 07:50 PM, Kiran Karra via USRP-users wrote:
>> Hello,
>>
>> I am trying to use the USRP for a coherent transmitter application (I
>> have a spread spectrum waveform where I know how many zero crossings
>> of the carrier need to occur within each chip of the transmitted
>> waveform) and have several questions regarding the USRP B210 in this
>> light:
>>
>> 1.) Is the DAC clock and the LO which mixes up the complex baseband
>> input to a desired frequency driven by the same reference
>> oscillator? If so, I would conclude that generating the spread data
>> and mixing it with the USRP sink block would be a coherent operation,
>> but I am not sure.
>>
>> 2.) I looked at the specification for the AD9361 chipset
>> (http://www.analog.com/media/en/technical-documentation/data-sheets/AD9361.pdf)
>>
>> which says that the LO step size is 2.4 Hz. I need my transmit
>> frequency to be *exactly* 1575.42 MHz ... so I'm wondering if because
>> the minimum frequency supported by the chipset is 70 MHz, and the
>> stepsize is 2.4Hz, doing the following math (1575.42-70)*1e6/2.4
>> yields a non-integer value, that I am not getting exactly 1575.42 MHz
>> as the output frequency? When I run my waveform, I get the following
>> output from the UHD driver, which is also seemingly contradicting itself:
>>
>>
>> -- Asking for clock rate 32.000000 MHz
>> -- Actually got clock rate 32.000000 MHz
>> -- Performing timer loopback test... pass
>> -- Performing timer loopback test... pass
>> -- Tune Request: 1575.420000 MHz
>> -- The RF LO does not support the requested frequency:
>> -- Requested LO Frequency: 1575.420000 MHz
>> -- RF LO Result: 1575.420000 MHz
>> -- Attempted to use the DSP to reach the requested frequency:
>> -- Desired DSP Frequency: 0.000000 MHz
>> -- DSP Result: 0.000000 MHz
>> -- Successfully tuned to 1575.420000 MHz
>>
>>
>> What exactly does it mean when it says that the RF LO doesn't support
>> the requested frequency, but then it seems to successfully tune to
>> that frequency? Is the output I am seeing a "rounded" version, or is
>> it exactly what the LO is tuned to? The output is seemingly
>> contradicting.
>>
>> Thanks!
>> Kiran
>>
> The DSP in the FPGA will "mop up" any granularity issues in the LO
> tuning, using a DUC. This is pretty a pretty standard thing to do in
> the RF DSP
> world.
>
> Also, what do you mean by "exact"?? The on-board clock is good to
> about 2PPM, and you can get closer and closer to "exact" as you get
> into more
> and more exotic external references. An OCXO would be good to
> about 20-50PPB. A GPSDO to about 5-10PPB, an Rb source, perhaps 0.5PPB.
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> 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/20150625/d6c9cfcd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2411 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150625/d6c9cfcd/attachment-0001.p7s>
------------------------------
Message: 15
Date: Thu, 25 Jun 2015 09:22:18 -0400
From: Kiran Karra <kkarr...@vt.edu>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Regarding USRP B210 Tuning Frequency
Message-ID: <558c008a.90...@vt.edu>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Hello Ron,
When I run your command on my B210, I get the following:
Using Volk machine: avx_64_mmx
-- Tune Request: 1575.420000 MHz
-- The RF LO does not support the requested frequency:
-- Requested LO Frequency: 1575.420000 MHz
-- RF LO Result: 1575.420000 MHz
-- Attempted to use the DSP to reach the requested frequency:
-- Desired DSP Frequency: -0.000000 MHz
-- DSP Result: -0.000000 MHz
-- Successfully tuned to 1575.420000 MHz
Are you using a different UHD driver to get the extra significant
digits? I have the following version of UHD:
> uhd_fft -f 1575420000 -s 8000000
linux; GNU C++ version 4.8.2; Boost_105400; *UHD_003.008.000-0-a90a6af0*
Thanks again,
Kiran
On 06/25/2015 09:12 AM, Kiran Karra via USRP-users wrote:
> uhd_fft -f 1575420000 -s 8000000
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150625/6d9e7313/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2411 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150625/6d9e7313/attachment-0001.p7s>
------------------------------
Message: 16
Date: Thu, 25 Jun 2015 06:23:27 -0700
From: "Jason Matusiak" <ja...@gardettoengineering.com>
To: "Philip Balister" <phi...@opensdr.com>, "Ettus Mail List"
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] missing library for E310 cross-compile
Message-ID:
<20150625062327.ba066092a6e013ef68fa4f5a8d80e9ee.df845365bb....@email02.secureserver.net>
Content-Type: text/plain; charset="utf-8"
> Are you using the SDK that matches the image? When I post an image, I
> post the matching sdk in the same directory. It is possible I made a
> mistake uploading files.
>
> Philip
The short answer is sort-of :).
Originally I had grabbed from
http://files.ettus.com/e3xx_images/e310-release-002/oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
But before I sent out the email I moved the original folder created that
to a new name and rerand the script located here (which should be the
one you posted I believe):
http://files.ettus.com/e3xx_images/alpha/fido-rfnoc-test/oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
But since the
/usr/local/oecore-x86_64/./sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/lib/
directory contains libboost_date_time.so.1.57.0 I would think you would
be OK....
------------------------------
Message: 17
Date: Thu, 25 Jun 2015 09:34:44 -0400
From: Philip Balister <phi...@opensdr.com>
To: Jason Matusiak <ja...@gardettoengineering.com>, Ettus Mail List
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] missing library for E310 cross-compile
Message-ID: <558c0374.9030...@opensdr.com>
Content-Type: text/plain; charset=utf-8
On 06/25/2015 09:23 AM, Jason Matusiak wrote:
>> Are you using the SDK that matches the image? When I post an image, I
>> post the matching sdk in the same directory. It is possible I made a
>> mistake uploading files.
>>
>> Philip
>
> The short answer is sort-of :).
>
> Originally I had grabbed from
> http://files.ettus.com/e3xx_images/e310-release-002/oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
>
> But before I sent out the email I moved the original folder created that
> to a new name and rerand the script located here (which should be the
> one you posted I believe):
> http://files.ettus.com/e3xx_images/alpha/fido-rfnoc-test/oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
>
> But since the
> /usr/local/oecore-x86_64/./sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/lib/
> directory contains libboost_date_time.so.1.57.0 I would think you would
> be OK....
>
I'm wondering if the environment file you source has the wrong path
since you moved the directory.
I keep an sdk directory in my home dir and unpack sdks into it with
unique directory names for different builds.
Philip
------------------------------
Message: 18
Date: Thu, 25 Jun 2015 06:38:13 -0700
From: "Jason Matusiak" <ja...@gardettoengineering.com>
To: "Philip Balister" <phi...@opensdr.com>, "Ettus Mail List"
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] missing library for E310 cross-compile
Message-ID:
<20150625063813.ba066092a6e013ef68fa4f5a8d80e9ee.aba82eda83....@email02.secureserver.net>
Content-Type: text/plain; charset="utf-8"
> I'm wondering if the environment file you source has the wrong path
> since you moved the directory.
I can blow away the directory I "moved" to see if that helps, or do you
think that I am maybe pointing to somewhere totally different?
------------------------------
Message: 19
Date: Thu, 25 Jun 2015 15:40:42 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Regarding USRP B210 Tuning Frequency
Message-ID: <558c04da.1000...@ettus.com>
Content-Type: text/plain; charset=windows-1252
Hi Kiran,
On 06/25/2015 03:16 PM, Kiran Karra via USRP-users wrote:
> Also, is the DAC clock and the LO driven by the same reference oscillator?
Yes, they are.
------------------------------
Message: 20
Date: Thu, 25 Jun 2015 09:43:34 -0400
From: Philip Balister <phi...@opensdr.com>
To: Jason Matusiak <ja...@gardettoengineering.com>, Ettus Mail List
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] missing library for E310 cross-compile
Message-ID: <558c0586.8030...@opensdr.com>
Content-Type: text/plain; charset=utf-8
On 06/25/2015 09:38 AM, Jason Matusiak wrote:
>> I'm wondering if the environment file you source has the wrong path
>> since you moved the directory.
>
> I can blow away the directory I "moved" to see if that helps, or do you
> think that I am maybe pointing to somewhere totally different?
It definitely feels like you are using the wrong sdk.
The file:
http://files.ettus.com/e3xx_images/alpha/fido-rfnoc-test/oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.manifest
Suggests the sdk contains boost 1.57.
Philp
------------------------------
Message: 21
Date: Thu, 25 Jun 2015 15:47:02 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Regarding USRP B210 Tuning Frequency
Message-ID: <558c0656.5000...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
Hi Kiran,
this exact formatting mishappen came to my attention yesterday. You can
modify UHD's source code, if you want to, to display Hz instead of MHz,
and you will find out that the DSP tuning offset should be -0.483991 Hz
to make your received frequency 1575.42MHz; however, due to numeric
constraints, that offset can only be -0.484288 Hz. Which means you're
off by 0.3mHz, which is much much less than the accuracy of the
oscillator. Also, the DSP offset of ~0.5Hz is about 0.3 * 10^-9 of the
target frequency, so it's also much better than the oscillator accuracy.
What Marcus Leech said is therefore right: In essence, for all physical
considerations, the oscillator is *exactly* at 1575.42MHz, within the
physical accuracy of the oscillator frequency.
Best regards,
Marcus
On 06/25/2015 03:22 PM, Kiran Karra via USRP-users wrote:
> Hello Ron,
>
> When I run your command on my B210, I get the following:
>
> Using Volk machine: avx_64_mmx
> -- Tune Request: 1575.420000 MHz
> -- The RF LO does not support the requested frequency:
> -- Requested LO Frequency: 1575.420000 MHz
> -- RF LO Result: 1575.420000 MHz
> -- Attempted to use the DSP to reach the requested frequency:
> -- Desired DSP Frequency: -0.000000 MHz
> -- DSP Result: -0.000000 MHz
> -- Successfully tuned to 1575.420000 MHz
>
> Are you using a different UHD driver to get the extra significant
> digits? I have the following version of UHD:
>
> > uhd_fft -f 1575420000 -s 8000000
> linux; GNU C++ version 4.8.2; Boost_105400; *UHD_003.008.000-0-a90a6af0*
>
> Thanks again,
> Kiran
>
> On 06/25/2015 09:12 AM, Kiran Karra via USRP-users wrote:
>> uhd_fft -f 1575420000 -s 8000000
>
>
>
> _______________________________________________
> USRP-users mailing list
> 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/20150625/5b867eb5/attachment-0001.html>
------------------------------
Message: 22
Date: Thu, 25 Jun 2015 09:59:24 -0400
From: mle...@ripnet.com
To: Kiran Karra <kkarr...@vt.edu>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Regarding USRP B210 Tuning Frequency
Message-ID: <fba3b136f0a3dd82a5e6f3b10927e...@ripnet.com>
Content-Type: text/plain; charset="us-ascii"
This is just an issue of the precision of the printing done in the
startup stuff that the driver prints out, because it scales to MHz.
If you're concerned that it isn't tuning properly (and, I'm fairly
confident, it IS tuning 'exactly'), then you can use:
http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#adb1c803658f18006efc1dcd67de6d493
Which is what uhd_fft does internally, and prints things differently
than the UHD boilerplate header prints things out.
On 2015-06-25 09:22, Kiran Karra via USRP-users wrote:
> Hello Ron,
>
> When I run your command on my B210, I get the following:
>
> Using Volk machine: avx_64_mmx
> -- Tune Request: 1575.420000 MHz
> -- The RF LO does not support the requested frequency:
> -- Requested LO Frequency: 1575.420000 MHz
> -- RF LO Result: 1575.420000 MHz
> -- Attempted to use the DSP to reach the requested frequency:
> -- Desired DSP Frequency: -0.000000 MHz
> -- DSP Result: -0.000000 MHz
> -- Successfully tuned to 1575.420000 MHz
>
> Are you using a different UHD driver to get the extra significant digits? I
> have the following version of UHD:
>
>> uhd_fft -f 1575420000 -s 8000000
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.000-0-A90A6AF0
>
> Thanks again,
> Kiran
>
> On 06/25/2015 09:12 AM, Kiran Karra via USRP-users wrote:
>
>> uhd_fft -f 1575420000 -s 8000000
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
Links:
------
[1] 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/20150625/02873b45/attachment-0001.html>
------------------------------
Message: 23
Date: Thu, 25 Jun 2015 07:17:51 -0700
From: "Jason Matusiak" <ja...@gardettoengineering.com>
To: "Philip Balister" <phi...@opensdr.com>, "Ettus Mail List"
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] missing library for E310 cross-compile
Message-ID:
<20150625071751.ba066092a6e013ef68fa4f5a8d80e9ee.6884b82d92....@email02.secureserver.net>
Content-Type: text/plain; charset="utf-8"
> It definitely feels like you are using the wrong sdk.
OK, I am going to start over from scratch. One question I have though
is from this:
http://files.ettus.com/manual/page_build_guide.html#libpath_linux
Is this a step that needs to be taken? And if so, do I need to point to
something in the cross-compile for it?
------------------------------
Message: 24
Date: Thu, 25 Jun 2015 10:27:19 -0400
From: Philip Balister <phi...@opensdr.com>
To: Jason Matusiak <ja...@gardettoengineering.com>, Ettus Mail List
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] missing library for E310 cross-compile
Message-ID: <558c0fc7.3020...@opensdr.com>
Content-Type: text/plain; charset=utf-8
On 06/25/2015 10:17 AM, Jason Matusiak wrote:
>> It definitely feels like you are using the wrong sdk.
>
> OK, I am going to start over from scratch. One question I have though
> is from this:
> http://files.ettus.com/manual/page_build_guide.html#libpath_linux
>
> Is this a step that needs to be taken? And if so, do I need to point to
> something in the cross-compile for it?
>
>
Only if you are installing stuff in /usr/local/lib. The stuff I ahve
written that does that is for OOT's modules. Normally I try to install
user cross compiled uhd and gnuradio over the version installed by the
package manager. Yeah, bad form, but minimizes the chance of confusion
from two versions of something installed.
Philip
------------------------------
Message: 25
Date: Thu, 25 Jun 2015 10:54:04 -0500
From: Aaron Henderson <egine...@hotmail.com>
To: "Nowlan, Sean" <sean.now...@gtri.gatech.edu>, "mle...@ripnet.com"
<mle...@ripnet.com>
Cc: Neel Pandeya <neel.pand...@ettus.com>,
"usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] .bin make issues
Message-ID: <col401-eas36264d995a52b061150e579cc...@phx.gbl>
Content-Type: text/plain; charset="utf-8"
I finally got all working. I used Sean's suggestion on making a new file for
the clone. I am making the binary file now. I had another issue come up with
the bash file and xtclsh, but was able to resolve it.
Thanks to all that helped.
Sean, Marcus, and most of all Ian (the file paths and procedure helped
tremendously).
Aaron
Sent via the Samsung Galaxy Note? 3, an AT&T 4G LTE smartphone
-------- Original message --------
From: "Nowlan, Sean" <sean.now...@gtri.gatech.edu>
Date: 06/23/2015 9:39 AM (GMT-06:00)
To: Aaron Henderson <egine...@hotmail.com>, mle...@ripnet.com
Cc: Neel Pandeya <neel.pand...@ettus.com>, usrp-users@lists.ettus.com
Subject: RE: [USRP-users] .bin make issues
I recommend starting fresh. Delete uhd (unless, of course, you need to save
code changes).
git clone --recursive https://github.com/EttusResearch/uhd
Or, to optionally name the folder something else like uhd-new:
git clone --recursive https://github.com/EttusResearch/uhd uhd-new
This also worked for me, and it downloaded the fpga-src submodule as well.
Sean
From: Aaron Henderson [mailto:egine...@hotmail.com]
Sent: Tuesday, June 23, 2015 10:31 AM
To: mle...@ripnet.com
Cc: Nowlan, Sean; Neel Pandeya; usrp-users@lists.ettus.com
Subject: RE: [USRP-users] .bin make issues
Should I run the command from the uhd file path or fpga-src?
Aaron
Sent via the Samsung Galaxy Note? 3, an AT&T 4G LTE smartphone
-------- Original message --------
From: mle...@ripnet.com<mailto:mle...@ripnet.com>
Date: 06/23/2015 9:28 AM (GMT-06:00)
To: Aaron Henderson <egine...@hotmail.com<mailto:egine...@hotmail.com>>
Cc: "Nowlan, Sean"
<sean.now...@gtri.gatech.edu<mailto:sean.now...@gtri.gatech.edu>>, Neel Pandeya
<neel.pand...@ettus.com<mailto:neel.pand...@ettus.com>>,
usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] .bin make issues
I just tried this, and I got a complete source tree, including fpga-src and all
its child directories and files...
On 2015-06-23 10:21, Aaron Henderson via USRP-users wrote:
Sean,
Not sure why your method did not work, but through searching it seems like
something in the .git files.
So I used this command,
git clone --recursive https://github.com/EttusResearch/uhd.Everything
downloaded properly, but my fpga-src was still not populated.
Is there a good reason why this would happen?
Aaron
Sent via the Samsung Galaxy Note? 3, an AT&T 4G LTE smartphone
-------- Original message --------
From: "Nowlan, Sean"
<sean.now...@gtri.gatech.edu<mailto:sean.now...@gtri.gatech.edu>>
Date: 06/22/2015 9:54 AM (GMT-06:00)
To: Neel Pandeya <neel.pand...@ettus.com<mailto:neel.pand...@ettus.com>>, Aaron
Henderson <egine...@hotmail.com<mailto:egine...@hotmail.com>>
Cc: "'USRP-users@lists.ettus.com'"
<USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>>
Subject: RE: [USRP-users] .bin make issues
Not sure why usrp-usrs email was not included.
From: Nowlan, Sean
Sent: Monday, June 22, 2015 10:49 AM
To: 'Neel Pandeya'; Aaron Henderson
Subject: RE: [USRP-users] .bin make issues
If you've already got UHD cloned, you can also do this:
cd <path_to>/uhd/
git submodule init
git submodule update
Sean
From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of Neel
Pandeya via USRP-users
Sent: Monday, June 22, 2015 10:48 AM
To: Aaron Henderson
Cc: usrp-users
Subject: Re: [USRP-users] .bin make issues
The FPGA code is now a git sub-module, so if you want to get the FPGA code as
well as the UHD code, when you clone UHD, you need to do it recursively.
So use the command:
git clone --recursive https://github.com/EttusResearch/uhd
On 22 June 2015 at 07:24, Aaron Henderson via USRP-users
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote:
Ian,
Thanks for the help.
My issue is that fpga-src is empty.
Is there a step I am missing to get these files?
Aaron
Sent via the Samsung Galaxy Note? 3, an AT&T 4G LTE smartphone
-------- Original message --------
From: Ian Buckley <i...@ionconcepts.com<mailto:i...@ionconcepts.com>>
Date: 06/18/2015 12:58 PM (GMT-06:00)
To: Aaron Henderson <egine...@hotmail.com<mailto:egine...@hotmail.com>>
Cc: "'USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>'"
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>>
Subject: Re: [USRP-users] .bin make issues
Aaron,
Reading back through your posts to the list I think you may have some
fundamental miss-understandings with how ISE works. Fundamentally .bin files
are the *output* products of ISE, they contain all the compiled configuration
data required to program the FPGA. They are not *input* files to ISE, they do
not capture source code information. To run ISE you require Verilog or VHDL
source code files. In the case of N210R3 the FPGA source files are located in
directories below: $(AARANS_UHD_INSTALL)/fpga-src/usrp2. To compile the FPGA
design for N210R3:
cd $(AARANS_UHD_INSTALL)/fpga-src/usrp2/top/N2x0
make N210R3
-Ian
On Jun 18, 2015, at 7:09 AM, Aaron Henderson via USRP-users
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote:
When I use the command
1.
'aaron@waled-Precision-WorkStation-670:~/Desktop/uhd-images_003.008.001-release/share/uhd/images$
make -f usrp_n210_r3_fpga.bin' I get the error 'usrp_n210_r3_fpga.bin:1:
warning: NUL character seen; rest of line ignored
usrp_n210_r3_fpga.bin:1: *** missing separator. Stop.'
or if I use this command, as is specified in the FPGA manual,
'aaron@waled-Precision-WorkStation-670:~/Desktop/uhd-images_003.008.001-release/share/uhd/images$
make usrp_n210_r3_fpga.bin' I get the error 'make: Nothing to be done for
`usrp_n210_r3_fpga.bin'.'
I must be doing something wrong.
Aaron
> Date: Wed, 17 Jun 2015 09:19:57 -0700
> From: martin.br...@ettus.com<mailto:martin.br...@ettus.com>
> To: egine...@hotmail.com<mailto:egine...@hotmail.com>;
> usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] .bin make issues
>
> On 16.06.2015 12:46, Aaron Henderson wrote:
> > Martin,
> >
> > Yes. I have visited the link you sent me. That is where I discovered the
> > misnamed file path. Usrp3/top instead of usrp2/top, but I have no top
> > files through either of those file paths do it didn't matter anyways.
> >
> > I believe the apt-get command were through my not reading completely.
> > Those were for the UHD code.
> >
> > ISE is properly installed without any issues.
>
> Great, then you're all set! Good luck with your FPGA development.
>
> Cheers,
> Martin
>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com<mailto: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/20150625/970f18df/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 58, Issue 24
******************************************
