I’ve seen this issue on a few other posts, and it comes up a lot in
searches, but I can’t find a clear solution or answer.
I have two antennas for the E100 that both overlap the 915MHz range,
and would like to send a constant 915MHz wave with one, while
receiving a modulated 915MHz wave on the other (for communicating with
the RFID-style FasTrak Transponders used on the West Coast, US).
I’ve tried this by using separate flow graphs and separate programs,
but in all cases either TX or RX seems to take out a lock on the
device, preventing the other from accessing it.
If there any way to achieve full-duplex communication on the E100,
with or without two antennas?
-Meyer S. Jacobs
On Thu, 2011-08-04 at 13:22 -0700, Meyer S. Jacobs wrote:
device, preventing the other from accessing it.
If there any way to achieve full-duplex communication on the E100,
with or without two antennas?
Use a single flowgraph with both a source and a sink in it.
Using gnuradio-companion for code generation, with the UHD drivers for
the E100, it still locks up. I can provide my .grc files and generated
python code when I get back to my desk.
-Meyer S. Jacobs
Using this flow graph: http://i.imgur.com/K9TaN.png
I get this traceback:
– Opening USRP-E on /dev/usrp_e0
Traceback (most recent call last):
File “full_duplex.py”, line 60, in
tb = full_duplex()
File “full_duplex.py”, line 31, in init
num_channels=1,
File “/usr/lib/python2.6/site-packages/gnuradio/uhd/init.py”, line
74,
in constructor_interceptor
return old_constructor(*args, **kwargs)
File “/usr/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py”, line
2045, in usrp_sink
return _uhd_swig.usrp_sink(*args, **kwargs)
RuntimeError: EnvironmentError: IOError: Failed to open /dev/usrp_e0
This never occurs when using only one source or sink, but occurs with
two,
independent of the antennas I specify.
I updated the usrp kernel module and boot files with the versions
published on the wiki. The problem persists. I also recently applied
the Console Development Image from
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/usrpe1xx/wiki/Images
(within the last week).
root@usrp-e1xx:~# uname -a
Linux usrp-e1xx 2.6.38 #1 PREEMPT Tue Aug 2 08:56:51 EDT 2011 armv7l
GNU/Linux
root@usrp-e1xx:~# modinfo usrp_e
filename: /lib/modules/2.6.38/kernel/drivers/misc/usrp_e.ko
license: GPL v2
author: Philip B. [email protected]
description: usrp_e
alias: usrp_e
version: 0.2
srcversion: 2D513E631A29B9FC987759B
depends:
vermagic: 2.6.38 preempt mod_unload modversions ARMv7
On Fri, 2011-08-05 at 13:40 -0700, Meyer S. Jacobs wrote:
Using this flow graph: http://i.imgur.com/K9TaN.png
What version of E100 images are you using? The older stuff had a known
bug that would cause this. Update to latest images & try again.
–n
On Fri, Aug 5, 2011 at 15:41, Josh B. [email protected] wrote:
Can you tell me the output of uhd_usrp_probe
thanks
-josh
It appears I must have botched something during the updating. Now
everything gives this error:
root@usrp-e1xx:~# uhd_usrp_probe
linux; GNU C++ version 4.5.2 20101204 (prerelease); Boost_104100;
UHD_003.001.001-3724b82
– Opening USRP-E on /dev/usrp_e0
Error: EnvironmentError: IOError: Failed to open /dev/usrp_e0
I seem to remember having this problem early on, but recompiling the
UHD drivers and Gnuradio solved it. I’ll try that again in an hour,
unless advised otherwise. Also, it seems another thread on discuss is
related to the most recent problem.
On 08/05/2011 03:53 PM, Meyer S. Jacobs wrote:
linux; GNU C++ version 4.5.2 20101204 (prerelease); Boost_104100;
UHD_003.001.001-3724b82
Yes, 3.1.* had this issue, its been fixed on the master for some time,
and now 3.2.* is an official release with the fix.
-josh
