Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: GPSDO loss of lock (Sivan Toledo)
2. Re: GPSDO loss of lock (Marcus D. Leech)
3. Re: GPSDO loss of lock (Sivan Toledo)
4. Announcing NEWSDR at WPI on Friday May 17 (Bruce Penswick)
5. Peak center frequency error (Julio Hector Aguilar Renteria)
6. GPSDO on N210 problem (Sam mite)
7. Re: GPSDO on N210 problem (Josh Blum)
8. ISWCS 2013 Call for Demonstrations (Andre Puschmann)
9. Re: Receiving wlan signals on USRP N210 (andrew smith)
10. Problems using Airprobe with USRP1 (GSM Research)
----------------------------------------------------------------------
Message: 1
Date: Sun, 14 Apr 2013 20:36:23 +0300
From: Sivan Toledo <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] GPSDO loss of lock
Message-ID:
<CAOL_ruG-H65Z6He1G-62Nfxy5yuZ2HbygL4sKsk5sPo5=xu...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
The UHD version is UHD_003.005.001. Not sure about firmware version because
we did not write down which version we uploaded to the N200. Is there a way
to tell? Should we upgrade to the latest firmware/FPGA image?
On Thu, Apr 11, 2013 at 6:14 PM, Marcus D. Leech <[email protected]> wrote:
> We are trying to accurately measure time-of-arrival in two identical USRPs
>> (N200 with WBX), both with the built-in GPSDO. We see differences in
>> time-of-arrival between the two receivers, even at excellent SNRs, and we
>> are trying to track the reason for this. Both receivers are connected to
>> the same antenna through a T connector with identical cables.
>>
>> One thing that we checked is the GPS lock, the LO lock, and the REF lock.
>> We test for all 3 every 64 packets of samples we get from UHD. We found
>> that the LO and REF are locked all the time, but the gps_locked sensor
>> reports loss of lock every 2 to 3 seconds. It then locks and unlocks a
>> couple of times (usually 4) in quick succession, then locks for 2-3 more
>> seconds, and so on.
>>
>> The GPS antennas seem fine and the GGA sentence reports that the receiver
>> sees 11 satellites. So I don't think that flaky GPS reception is the
>> problem. This happens to both units.
>>
>> We have 2 questions:
>> 1. Why does the gps_locked reports no lock for a short period every few
>> seconds?
>> 2. How does this affect the 10MHz clock to which the sampling clock and
>> the LO are locked? Can GPS loss of lock cause a significant drift or
>> increased phase noise in the 10MHz reference and the clocks that are locked
>> to it?
>>
>> Thanks, Sivan
>>
> I can't tell you why the gps_locked sensor is coming and going.
>
> But the oscillator on board the GPSDO is of high quality, and the servo in
> the GPSDO takes a "long view", so loss-of-lock won't necessarily cause
> any really bad issues with clock stability, as long as it's getting good
> timing data on a regular basis.
>
> Which version of UHD and firmware are you using?
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> ______________________________**_________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/**mailman/listinfo/usrp-users_**lists.ettus.com<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130414/87015335/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 14 Apr 2013 13:55:15 -0400
From: "Marcus D. Leech" <[email protected]>
To: Sivan Toledo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] GPSDO loss of lock
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 04/14/2013 01:36 PM, Sivan Toledo wrote:
> The UHD version is UHD_003.005.001. Not sure about firmware version
> because we did not write down which version we uploaded to the N200.
> Is there a way to tell? Should we upgrade to the latest firmware/FPGA
> image?
>
>
Testing those values so frequently is going to cause unnecessarily-high
control traffic. Unless things are *broken*, there's absolutely no reason
to test them so frequently. Every few seconds perhaps, but every 64
packets? That's a very high rate. And the GPS_LOCK sensor mechanism
within the GPSDO probably doesn't even operate over such short time
intervals--like I said, it's taking a "long view".
The VCTCXO is your typical GPSDO is designed to provide fairly-long
"holdover" times, and the servo mechanism tends to be able to cope with
only-occasional "good" fixes from the satellite constellation.
Again, I can't comment on why your GPSDO is reporting loss-of-lock so
frequently,
but it likely won't have a huge impact.
> On Thu, Apr 11, 2013 at 6:14 PM, Marcus D. Leech <[email protected]
> <mailto:[email protected]>> wrote:
>
> We are trying to accurately measure time-of-arrival in two
> identical USRPs (N200 with WBX), both with the built-in GPSDO.
> We see differences in time-of-arrival between the two
> receivers, even at excellent SNRs, and we are trying to track
> the reason for this. Both receivers are connected to the same
> antenna through a T connector with identical cables.
>
> One thing that we checked is the GPS lock, the LO lock, and
> the REF lock. We test for all 3 every 64 packets of samples we
> get from UHD. We found that the LO and REF are locked all the
> time, but the gps_locked sensor reports loss of lock every 2
> to 3 seconds. It then locks and unlocks a couple of times
> (usually 4) in quick succession, then locks for 2-3 more
> seconds, and so on.
>
> The GPS antennas seem fine and the GGA sentence reports that
> the receiver sees 11 satellites. So I don't think that flaky
> GPS reception is the problem. This happens to both units.
>
> We have 2 questions:
> 1. Why does the gps_locked reports no lock for a short period
> every few seconds?
> 2. How does this affect the 10MHz clock to which the sampling
> clock and the LO are locked? Can GPS loss of lock cause a
> significant drift or increased phase noise in the 10MHz
> reference and the clocks that are locked to it?
>
> Thanks, Sivan
>
> I can't tell you why the gps_locked sensor is coming and going.
>
> But the oscillator on board the GPSDO is of high quality, and the
> servo in the GPSDO takes a "long view", so loss-of-lock won't
> necessarily cause
> any really bad issues with clock stability, as long as it's
> getting good timing data on a regular basis.
>
> Which version of UHD and firmware are you using?
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130414/8986427d/attachment-0001.html>
------------------------------
Message: 3
Date: Sun, 14 Apr 2013 21:07:14 +0300
From: Sivan Toledo <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] GPSDO loss of lock
Message-ID:
<caol_ruea+-a2nce7i8et0eazvyn_-cp2uy+jcfmqgp76u-9...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Sounds good. I also assumed the the GPS frequency lock has a slow loop
filter, but it's good to get a verification of this. Thanks a lot Marcus.
Sivan
On Sun, Apr 14, 2013 at 8:55 PM, Marcus D. Leech <[email protected]> wrote:
> **
> On 04/14/2013 01:36 PM, Sivan Toledo wrote:
>
> The UHD version is UHD_003.005.001. Not sure about firmware version
> because we did not write down which version we uploaded to the N200. Is
> there a way to tell? Should we upgrade to the latest firmware/FPGA image?
>
>
> Testing those values so frequently is going to cause unnecessarily-high
> control traffic. Unless things are *broken*, there's absolutely no reason
> to test them so frequently. Every few seconds perhaps, but every 64
> packets? That's a very high rate. And the GPS_LOCK sensor mechanism
> within the GPSDO probably doesn't even operate over such short time
> intervals--like I said, it's taking a "long view".
>
> The VCTCXO is your typical GPSDO is designed to provide fairly-long
> "holdover" times, and the servo mechanism tends to be able to cope with
> only-occasional "good" fixes from the satellite constellation. Again, I
> can't comment on why your GPSDO is reporting loss-of-lock so frequently,
> but it likely won't have a huge impact.
>
>
>
> On Thu, Apr 11, 2013 at 6:14 PM, Marcus D. Leech <[email protected]>wrote:
>
>> We are trying to accurately measure time-of-arrival in two identical
>>> USRPs (N200 with WBX), both with the built-in GPSDO. We see differences in
>>> time-of-arrival between the two receivers, even at excellent SNRs, and we
>>> are trying to track the reason for this. Both receivers are connected to
>>> the same antenna through a T connector with identical cables.
>>>
>>> One thing that we checked is the GPS lock, the LO lock, and the REF
>>> lock. We test for all 3 every 64 packets of samples we get from UHD. We
>>> found that the LO and REF are locked all the time, but the gps_locked
>>> sensor reports loss of lock every 2 to 3 seconds. It then locks and unlocks
>>> a couple of times (usually 4) in quick succession, then locks for 2-3 more
>>> seconds, and so on.
>>>
>>> The GPS antennas seem fine and the GGA sentence reports that the
>>> receiver sees 11 satellites. So I don't think that flaky GPS reception is
>>> the problem. This happens to both units.
>>>
>>> We have 2 questions:
>>> 1. Why does the gps_locked reports no lock for a short period every few
>>> seconds?
>>> 2. How does this affect the 10MHz clock to which the sampling clock and
>>> the LO are locked? Can GPS loss of lock cause a significant drift or
>>> increased phase noise in the 10MHz reference and the clocks that are locked
>>> to it?
>>>
>>> Thanks, Sivan
>>>
>> I can't tell you why the gps_locked sensor is coming and going.
>>
>> But the oscillator on board the GPSDO is of high quality, and the servo
>> in the GPSDO takes a "long view", so loss-of-lock won't necessarily cause
>> any really bad issues with clock stability, as long as it's getting
>> good timing data on a regular basis.
>>
>> Which version of UHD and firmware are you using?
>>
>>
>> --
>> Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortium
>> http://www.sbrac.org
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130414/688205e3/attachment-0001.html>
------------------------------
Message: 4
Date: Sun, 14 Apr 2013 16:32:35 -0700 (PDT)
From: Bruce Penswick <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Announcing NEWSDR at WPI on Friday May 17
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
***********************************************************
*????????????????????? Third-Annual?????????????????????? *
*???? New England Workshop on Software-Defined Radio????? *
*????????????????????? NEWSDR 2013??????????????????????? *
*???????????????????????????????????????????????????????? *
*???????? Friday 17 May 2013, 8:30 AM - 5:30 PM?????????? *
*???????????? Worcester Polytechnic Institute???????????? *
*?????????????????? Worcester, MA, USA??????????????????? *
*???????????????????????????????????????????????????????? *
*?????????????? http://www.sdr-boston.org/??????????????? *
*???????????????????????????????????????????????????????? *
***********************************************************
*???????????????????????????????????????????????????????? *
* You are cordially invited to the 2013 New England?????? *
* Workshop for Software Defined Radio (NEWSDR 2013),????? *
* which is the third installment of an annual series of?? *
* workshops organized by the Boston SDR User Group??????? *
* (SDR-Boston). This year NEWSDR 2013 will be held at the *
* campus of Worcester Polytechnic Institute (WPI)???????? *
* on Friday 17 May 2013.????????????????????????????????? *
*???????????????????????????????????????????????????????? *
* NEWSDR 2013 features 6 technical presentations,???????? *
* 2 tutorials, as well as numerous posters and hardware?? *
* demonstrations, all focusing on the latest advances in? *
* software-defined radio and cognitive radio technology,? *
* including the use of GNU Radio software and USRP radio? *
* hardware.?????????????????????????????????????????????? *
*???????????????????????????????????????????????????????? *
* The event is a valuable opportunity to connect with a?? *
* dedicated SDR community in the area, to attend numerous *
* technical presentations on the subject, to meet vendors *
* who are active in SDR technology, to learn about new??? *
* products, and to explore various product and project??? *
* demos.????????????????????????????????????????????????? *
*???????????????????????????????????????????????????????? *
***********************************************************
* KEYNOTE SPEAKER:??????????????????????????????????????? *
*???????????????????????????????????????????????????????? *
*?? Dr. Joseph B. Evans?????????????????????????????????? *
*?? Deane E. Ackers Distinguished Professor?????????????? *
*?? The University of Kansas????????????????????????????? *
*???????????????????????????????????????????????????????? *
***********************************************************
* INVITED SPEAKER:??????????????????????????????????????? *
*???????????????????????????????????????????????????????? *
*?? Dr. Kapil Dandekar??????????????????????????????????? *
*?? Associate Professor and Associate Dean of Research??? *
*?? Drexel University???????????????????????????????????? *
*???????????????????????????????????????????????????????? *
***********************************************************
* TUTORIAL SESSIONS:????????????????????????????????????? *
*???????????????????????????????????????????????????????? *
* - Hands-On SDR Experimentation Using??????????????????? *
*?? Simulink and MATLAB?????????????????????????????????? *
*???????????????????????????????????????????????????????? *
* - GNU Radio: Latest Approaches for????????????????????? *
*?? Constructing SDR Systems????????????????????????????? *
*???????????????????????????????????????????????????????? *
***********************************************************
* REGISTRATION:?????????????????????????????????????????? *
*???????????????????????????????????????????????????????? *
* - Free registration online????????????????????????????? *
* - Free breakfast, lunch, and parking included?????????? *
* - Space is limited, so register soon!?????????????????? *
*???????????????????????????????????????????????????????? *
***********************************************************
*???????? Additional information can be found at:???????? *
*?????????????? http://www.sdr-boston.org/??????????????? *
*???????????????????????????????????????????????????????? *
*???? Please forward this message to your friends and???? *
*???? colleagues who may be interested in NEWSDR 2013.??? *
*??????????????? We hope to see you there!??????????????? *
*???????????????????????????????????????????????????????? *
***********************************************************
*????????????????????? Sponsored by:????????????????????? *
*????? The MathWorks, National Instruments, Xilinx??????? *
*???????????????????????????????????????????????????????? *
***********************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130414/86e9d8f8/attachment-0001.html>
------------------------------
Message: 5
Date: Sun, 14 Apr 2013 19:49:15 -0500
From: Julio Hector Aguilar Renteria <[email protected]>
To: [email protected], "[email protected]"
<[email protected]>
Subject: [USRP-users] Peak center frequency error
Message-ID:
<CACBKi8ft=v18anatwkjnxa2xgfs-2+f5rk+cmyl70bnb5oo...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Regards,
Hi all,
When uhd_fft.py graphic always appears a peak at the center frequency,
because appears?, can be corrected?
Thanks you
Julio H.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130414/15196828/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 15 Apr 2013 10:28:53 +0500
From: Sam mite <[email protected]>
To: [email protected]
Subject: [USRP-users] GPSDO on N210 problem
Message-ID:
<CAPhW9TScdj7gQBXbNbyOPWuSRLuX=i1rnbo5digonfjyxe+...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I am trying to setup GPS on my N210. The problem is that Detecting internal
GPSDO returns *"not found"* as shown below. Whereas it also says that *gpsdo:
internal. *What is wrong ? I am on ubnutu Gnuradio 3.6.3rc0. My UHD
version is UHD_003.005.000-26-gb65a3924
UHD Warning:
The send buffer could not be resized sufficiently.
Target sock buff size: 1048576 bytes.
Actual sock buff size: 1000000 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=1048576
-- Detecting internal GPSDO.... not found
_____________________________________________________
/
| Device: USRP2 / N-Series Device
| _____________________________________________________
| /
| | Mboard: N210r4
| | hardware: 2577
| | mac-addr: a0:36:fa:25:33:e9
| | ip-addr: 192.168.10.2
| | subnet: 255.255.255.255
| | gateway: 255.255.255.255
| | *gpsdo: internal*
| | serial: EER13V9UP
| | name: sdr_2
| | FW Version: 12.3
| | FPGA Version: 10.0
| |
| | Time sources: none, external, _external_, mimo
| | Clock sources: internal, external, mimo
| | Sensors: mimo_locked, ref_locked
| | _____________________________________________________
Thanks.
--
Best Regards,
Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130415/1bd94c7f/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 15 Apr 2013 02:38:31 -0500
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] GPSDO on N210 problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/15/2013 12:28 AM, Sam mite wrote:
> Hi,
>
> I am trying to setup GPS on my N210. The problem is that Detecting internal
> GPSDO returns *"not found"* as shown below. Whereas it also says that *gpsdo:
> internal. *What is wrong ? I am on ubnutu Gnuradio 3.6.3rc0. My UHD
> version is UHD_003.005.000-26-gb65a3924
>
The gpsdo internal is just an entry in the device's eeprom to tell it
that it should look for the GPSDO. So, I think you are looking at a
communication issue. Double check that the power and serial cables
appear to be plugged in correctly.
-josh
>
> UHD Warning:
> The send buffer could not be resized sufficiently.
> Target sock buff size: 1048576 bytes.
> Actual sock buff size: 1000000 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.wmem_max=1048576
> -- Detecting internal GPSDO.... not found
> _____________________________________________________
> /
> | Device: USRP2 / N-Series Device
> | _____________________________________________________
> | /
> | | Mboard: N210r4
> | | hardware: 2577
> | | mac-addr: a0:36:fa:25:33:e9
> | | ip-addr: 192.168.10.2
> | | subnet: 255.255.255.255
> | | gateway: 255.255.255.255
> | | *gpsdo: internal*
> | | serial: EER13V9UP
> | | name: sdr_2
> | | FW Version: 12.3
> | | FPGA Version: 10.0
> | |
> | | Time sources: none, external, _external_, mimo
> | | Clock sources: internal, external, mimo
> | | Sensors: mimo_locked, ref_locked
> | | _____________________________________________________
>
>
>
> Thanks.
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 8
Date: Mon, 15 Apr 2013 15:25:36 +0200
From: Andre Puschmann <[email protected]>
To: [email protected]
Subject: [USRP-users] ISWCS 2013 Call for Demonstrations
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Call for Demonstrations for ISWCS 2013
The Tenth International Symposium on Wireless Communication Systems
(ISWCS) to be held in Ilmenau, Germany, 27-30 August 2013 will offer the
invaluable opportunity to demonstrate novel, innovative and original
research in the area of Software Defined Radio/Cognitive Radio as well
as Future Internet technologies. The goal
of this demonstration session is to provide an opportunity to bridge the
gap between both research fields and to connect world-wide technical
researchers in both areas. Therefore, the session will welcome
contributions presenting novel and innovative demonstrations in one or
both of the above mentioned areas of interest.
Submission Requirements:
------------------------
The submissions should include an extended abstract of two pages in
accordance with the IEEE author guidelines. The authors should
explicitly state what will be demonstrated to the ISWCS audience, and
how the attendees will be able to interact, enjoy, and experiment. All
submissions must be submitted through EDAS.
The proposals will be evaluated by the ISWCS 2013 demo review committee
based on the following criteria:
? Relevance and novelty of the topic: How important and novel is the
proposed demonstration to the community?
? Interactivity and originality of the idea: What can the conference
attendees observe and how can they interact with the proposed demo?
The extended abstracts of accepted demonstrations will be included in
the proceedings of ISWCS 2013 and in the IEEE Xplore database. The
abstract should include a full list of authors with complete
affiliations. At least one author of each accepted demo is required to
register and present the demo at the conference.
Important Links:
----------------
- Conference website: http://www.iswcs2013.org
- EDAS submission: https://edas.info/newPaper.php?c=13295&track=32879
Important Dates:
----------------
? Demo proposal submission deadline: May 8, 2013
? Notification of acceptance: May 29, 2013
? Camera-ready version of demo papers: June 24, 2013
Demonstration Chairs:
---------------------
? Andre Puschmann, Ilmenau University of Technology, Germany
? Thomas Volkert, Ilmenau University of Technology, Germany
Demo Review Committee:
----------------------
? Martin Braun, Karlsruhe Institute of Technology, Germany
? Paul Sutton, CTVR, Trinity College, Ireland
? Joseph Gaeddert, Virginia Tech, USA
? Toma? ?olc, Jo?ef Stefan Institute, Slovenia
? Oliver Waldhorst, Karlsruhe Institute of Technology, Germany
? Paul M?ller, University of Kaiserslautern, Germany
? Thomas Magedanz, TU Berlin/Fraunhofer FOKUS, Germany
? Thomas Dreibholz, Simula Innovation AS, Norway
? Florian Liers, Ilmenau University of Technology, Germany
--
Andre Puschmann
Ilmenau University of Technology, Integrated Communication Systems Group
Cognitive Radio Network Group
Phone: +49 3677 69-4132, Fax: +49 3677 69-1614
Email: [email protected], Web: http://www.tu-ilmenau.de/crng
Office: Zuse Building, corridor f, room 1071
PGP/GnuPG key: 2C734140
fingerprint: 546F F71F 3185 0388 94C3 FA7A DDE6 00B9 2C73 4140
------------------------------
Message: 9
Date: Mon, 15 Apr 2013 18:59:52 +0530
From: andrew smith <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Receiving wlan signals on USRP N210
Message-ID:
<cad2xrl4qc1fu6ur79ohzrjyzbxehmlfyyozcfl75nvjpp_q...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi
I'm trying to receive Wlan signals using N210 & XCVR2450 but Iam not
seeing any,not even a very weak one. I am not using any external
antenna. Is it required?
Regards,
Smith
------------------------------
Message: 10
Date: Mon, 15 Apr 2013 11:30:39 -0400
From: GSM Research <[email protected]>
To: [email protected]
Subject: [USRP-users] Problems using Airprobe with USRP1
Message-ID:
<CAKH+_5HG53ZOc9Kg4zF0jMSAUGsy1uAtFgt2Q=lugovl9rg...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Thanks to everyone who responded to my queries so far. At this point, I
think that the problem must lie in the gsm_receive.py script. I appear to
be able to capture data, but go.sh (and running gsm_receive.py directly)
does not show any data after the initial output (unlike Thomas' example
below).
To verify that my uhd_rx_cfile is working, did a run using the following
command:
./uhd_rx_cfile.py --samp-rate 571428.571429 -f 19878e6 -a usb -A TX/RX -N
10000000 capture.dat
Could some kind soul offer to attempt to decode it? I don't want to send it
as an attachment to the list (the file is ~8Mb), but if someone with a
working setup can run it through their go.sh script, it would help me
verify that the problem is in the actual decoding.
The output I get when I run it through gsm_receive.py (I have to run it as
root for some reason - I don't know if that may be part of the issue) is:
$ sudo ./gsm_receive.py -d 112 -I ./capture.dat -c "" -k "00 00 00 00 00
00 00 00"
input_rate: 571428.571429 sample rate: 0.527472527473 filter_cutoff:
145000.0 filter_t_width: 10000.0
>>> gr_fir_ccc: using SSE
>>> gr_fir_ccf: using SSE
Key: '0000000000000000'
Configuration: ''
No configuration set.
configure_receiver
gr_buffer::allocate_buffer: warning: tried to allocate
115 items of size 568. Due to alignment requirements
512 were allocated. If this isn't OK, consider padding
your structure to a power-of-two bytes.
On this platform, our allocation granularity is 4096 bytes.
$
[with no other output. It is similar to Thomas' example until the data
output]
BTW, for the signal, I am running openbsc with an ip.access PCS1900. The
config file is set so the ARFCN is 800.
Could it be that the frequency of my USRP1 is off by enough such that it is
actually receiving dead air? The hexdump of capture.dat is showing actual
values...
Thanks again for any assistance!
John
On Fri, Apr 12, 2013 at 2:48 PM, Thomas Tsou <[email protected]> wrote:
>
> As previously stated, Airprobe assumes a decimation of 112 on a 64 MHz
> clocked USRP1. The decimation rate itself isn't relevant in
> gsm-receive.py, just sample rate. I ran the following on B100
> similarly clocked at 64 MHz.
>
> $ uhd_rx_cfile.py --samp-rate 571428.571429 -f 1978e6 capture.dat
>
> $ ./go.sh capture.dat
> >>> gr_fir_ccc: using SSE
> >>> gr_fir_ccf: using SSE
> Key: '0000000000000000'
> Configuration: ''
> No configuration set.
> configure_receiver
> gr_buffer::allocate_buffer: warning: tried to allocate
> 115 items of size 568. Due to alignment requirements
> 512 were allocated. If this isn't OK, consider padding
> your structure to a power-of-two bytes.
> On this platform, our allocation granularity is 4096 bytes.
> 2336549 0: 31 06 21 20 08 39 01 62 50 46 91 16 84 2b 2b 2b 2b 2b 2b 2b 2b
> 2b 2b
> 2336553 0: 15 06 21 00 01 f0 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
> 2b 2b
> 2336559 0: 15 06 21 00 01 f0 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
> 2b 2b
> 2336563 0: 49 06 22 a0 0b 5a d9 4d f8 59 15 2d 17 05 f4 c4 5a 36 4d cb 2b
> 2b 2b
> ...
>
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130415/88b5d5c0/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 32, Issue 11
******************************************
