Hi,
maybe the API has changed since gr-air-modes was written, or I’m doing
something stupid, but I tried:
$ ./uhd_modes.py -g 60
linux; GNU C++ version 4.4.5; Boost_104200;
UHD_0001.20101124180824.2568efd
Traceback (most recent call last):
File “./uhd_modes.py”, line 167, in
fg = adsb_rx_block(options, args, queue)
File “./uhd_modes.py”, line 57, in init
self.u = uhd.simple_source("", uhd.io_type_t.COMPLEX_FLOAT32)
AttributeError: ‘module’ object has no attribute ‘simple_source’
I’ve used the latest “next” branch of gnuradio, installed and
successfully tested UHD. My prefix for all three packages is
/opt/gnuradio.
According to
/opt/gnuradio/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py,
there is indeed no simple_source, there are single_usrp_source and
multi_usrp_source, but they have a different interface…
Any hints?
Alex
Those were deprecated interfaces for several months. They were just
removed: OSDIR
The method calls should be nearly identical. Just change the
constructor. -Josh
On Sun, 2010-11-28 at 17:25 -0500, Josh B. wrote:
Those were deprecated interfaces for several months. They were just
removed: OSDIR
The method calls should be nearly identical. Just change the
constructor. -Josh
Mea culpa, I thought the deprecated interfaces would stay in there a
while longer. The fix has been pushed to the Github repo. It was already
in the pmt branch, but that’s not ready for primetime yet.
git://github.com/bistromath/gr-air-modes.git
–n
Nick,
Got it working on my USRP2 by changing to line 57 to:
self.u = uhd.single_usrp_source(“addr=192.168.1.15”,
uhd.io_type_t.COMPLEX_FLOAT32)
and line 119 to:
result = self.u.set_center_freq(freq,0)
I’m getting 0 aircraft locations in the KML file but the stdout is as
follows:
(-40) Type 11 (all call reply) from e9fc9f in reply to interrogator 5
(-41) Type 11 (all call reply) from 2c4e09 in reply to interrogator 0
I assume these are Mode-S packets, thus no position info?
–
View this message in context:
http://old.nabble.com/gr-air-modes%3A-problem-with-uhd-and-USRP1-tp30326133p30336873.html
Sent from the GnuRadio mailing list archive at Nabble.com.
I am getting output like the following:
(-35) Type 11 (all call reply) from ac85cc in reply to interrogator 4
(-34) Type 11 (all call reply) from ac85cc in reply to interrogator 4
(-35) Type 11 (all call reply) from ac85cc in reply to interrogator 4
(-33) Type 4 (short surveillance altitude reply) from ac85cc at 5900ft
(-33) Type 0 (short A-A surveillance) from ac85cc at 5875ft
(-34) Type 11 (all call reply) from ac85cc in reply to interrogator 0
(-34) Type 0 (short A-A surveillance) from ac85cc at 5825ft
(-34) Type 0 (short A-A surveillance) from ac85cc at 5825ft
(-34) Type 0 (short A-A surveillance) from ac85cc at 5800ft
(-33) Type 0 (short A-A surveillance) from ac85cc at 5600ft
(-33) Type 0 (short A-A surveillance) from ac85cc at 5575ft
(-36) Type 11 (all call reply) from ac85cc in reply to interrogator 0
However I can’t renewed output to GoogleEarth. On occasion I get a plane
showing as in the attached file but I can’t get a continually renewing
display.
Any ideas on how to fix?
Thank you,
Al Vinegar
----- Original Message -----
From: “madengr” [email protected]
To: [email protected]
Sent: Monday, November 29, 2010 11:16 PM
Subject: Re: [Discuss-gnuradio] gr-air-modes: problem with uhd and USRP1
and line 119 to:
result = self.u.set_center_freq(freq,0)
I intended the channel parameters to default to 0 for the single usrp*
blocks. It looks like i missed that. Will fix, thanks. -Josh
On Wed, 2010-12-01 at 13:55 -0500, Allen Vinegar wrote:
(-33) Type 0 (short A-A surveillance) from ac85cc at 5600ft
(-33) Type 0 (short A-A surveillance) from ac85cc at 5575ft
(-36) Type 11 (all call reply) from ac85cc in reply to interrogator 0
However I can’t renewed output to GoogleEarth. On occasion I get a plane
showing as in the attached file but I can’t get a continually renewing
display.
Those squitters don’t contain any position information. The majority
(70% or so) of Mode S-equipped aircraft do not broadcast their position
via ADS-B. ADS-B packets are type 17 and you will see lat/lon in the
text when they come up.
The default KML settings only display aircraft which were heard in the
last 5 minutes. This is to prevent old data from being displayed on
screen. You can edit modes_kml.py to change that timeout if you like.
If your display doesn’t auto-renew, look at the network link settings in
Google Earth. Make sure under the “Refresh” tab the “Time-Based Refresh”
is set to “Periodically” and set the timeout to 4 or 5 seconds.
–n
On Mon, 2010-11-29 at 20:16 -0800, madengr wrote:
Nick,
Got it working on my USRP2 by changing to line 57 to:
self.u = uhd.single_usrp_source(“addr=192.168.1.15”,
uhd.io_type_t.COMPLEX_FLOAT32)
and line 119 to:
result = self.u.set_center_freq(freq,0)
That’s correct. The Github repo has the latest changes to make this work
as well.
I’m getting 0 aircraft locations in the KML file but the stdout is as
follows:
(-40) Type 11 (all call reply) from e9fc9f in reply to interrogator 5
(-41) Type 11 (all call reply) from 2c4e09 in reply to interrogator 0
I assume these are Mode-S packets, thus no position info?
Those are interrogator replies which contain no information except the
ICAO number of the aircraft and the interrogator ID.
–n
I do have the Refresh tab set to time-based refresh periodically and 5
second timeout. I seem to make one capture with no following renewals.
----- Original Message -----
From: “Nick F.” [email protected]
To: “Allen Vinegar” [email protected]
Cc: [email protected]
Sent: Wednesday, December 01, 2010 3:21 PM
Subject: Re: [Discuss-gnuradio] gr-air-modes: problem with uhd and USRP1
Nick F.-4 wrote:
That’s correct. The Github repo has the latest changes to make this work
as well.
May want to add an parser option string to specify the usrp source
address;
I have been editing the source code to add it. I believe the UHD
documentation says if no address is specified then it uses udp to find
the
USRP2, however if a firewall is running (as is my case), then it will
never
find it and err out.
http://www.ettus.com/uhd_docs/manual/html/identification.html#identifying-usrps
–
View this message in context:
http://old.nabble.com/gr-air-modes%3A-problem-with-uhd-and-USRP1-tp30326133p30355735.html
Sent from the GnuRadio mailing list archive at Nabble.com.