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: Building UHD using MSVC 2008 (Josh Blum)
2. Re: Sych problem in 4*4 MIMO (Josh Blum)
3. Setting B100 Master Clock to 61.44 MHz (David Gibbon)
4. Re: FW: E100 problem (Almohanad Fayez)
5. Re: Setting B100 Master Clock to 61.44 MHz (Josh Blum)
6. Time from GPSDO vs. epoch seconds (Nowlan, Sean)
7. Re: Time from GPSDO vs. epoch seconds (Nick Foster)
8. Re: Time from GPSDO vs. epoch seconds (Nowlan, Sean)
9. Re: Building UHD using MSVC 2008 (Pol Henarejos)
10. Sc8 Over the wire (Paola Madonna)
11. FPGA and Firmware Images and RS232 (Cary, Paul)
12. Re: FPGA and Firmware Images and RS232 ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Mon, 21 May 2012 09:55:28 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Building UHD using MSVC 2008
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 05/21/2012 08:20 AM, Pol Henarejos wrote:
> Dear list,
>
> I am trying to build UHD driver using MSVC 2008, since it is my
> compiler. I know that in Build Guide MSVC 2010 is required but I have
FWIW, MSVC 2010 express is free
> not it. I would like to request you if you could provide me support for
> this compiler.
>
> When I build UHD using MSVC 2008 everything goes fine. But when I start
> some example or test the program closes suddenly with no useful error
> (windows error 0xc0000005). I tried to run the program as Administrator
> but no luck. Dependancy walker does not say anything anormal. All
> libraries are x64. I use the release mode and the master branch (git
> 003.004.001-145-g38043612). I also do not provide usb support, only usrp2.
>
> Do you have some hint?
>
What you are seeing is an access violation. There is some bug related to
MSVC2008 and boost that causes it. Other users have reported this, but
unfortunately, I have not been able to replicate the issue with MSVC2008
pro and boost 1.47 from boost pro website.
A user posted a patch here that may work around the issue:
http://comments.gmane.org/gmane.comp.hardware.usrp.e100/3420
-josh
------------------------------
Message: 2
Date: Mon, 21 May 2012 10:15:22 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Sych problem in 4*4 MIMO
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 05/21/2012 01:17 AM, Farrukh Aziz wrote:
> John, I had all the settings entered correctly as you have described
> (so there is no problem with my USRP settings). However the last
> thing that I did was to swap my master and slave nodes, and this
> solved the problem. I dont know why, but the issue is now solved and
> I am getting 4 complex, synchronized data streams. The system is
> working properly with the external references (clock and PPS) fed
> from signal generators, and it is also working with GPSDO
> references. Just wondering if MIMO cable is alike at its both ends.
> Thanks Farrukh Aziz Bhatti Department of Electrical & Computer
> Engineering University of Auckland
>
>
With just the MIMO cable. Ignoring internal GPSDO, PPS, external ref.
You should be able to set the clock and time source for one of the
motherboards to MIMO cable, and it will just work (tm). You should be
able to reverse which mboard sync over the MIMO cable.
See screenshot: http://i.imgur.com/rZdgL.png
The mboard that is currently set to default time and clock reference ->
can be changed to sync itself to an external reference, or internal
GPSDO (if configured to have internal GPSDO).
-josh
------------------------------
Message: 3
Date: Mon, 21 May 2012 14:27:16 -0400
From: "David Gibbon" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Setting B100 Master Clock to 61.44 MHz
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I've been attempting, without success, to set my B100 clock to 61.44 MHz.
Running uhd_usrp_probe gives the following output:
C:\Users\David>uhd_usrp_probe --args="master_clock_rate=61.44e6"
Win32; Microsoft Visual C++ version 10.0; Boost_104700;
UHD_003.004.001-0-release
UHD Warning:
The control endpoint was left in a bad state.
Attempting endpoint re-enumeration...
Error: AssertionError: handle.get() != NULL
in __thiscall b100_impl::b100_impl(const class uhd::device_addr_t &)
at
C:\cygdrive\c\remote_fs_root\workspace\b08_win7\s\Win7_x64\stable\uhd_x86\ho
st\lib\usrp\b100\b100_impl.cpp:176
In my own code, after calling set_master_clock_rate(61440000), a call to
set_tx_freq throws the exception:
RuntimeError: B100: timeout waiting for control response packet.
Moving the J15 jumper as specified in the B1XX application notes makes no
difference. I could not locate a J16 on the motherboard, and J17 came
configured without a jumper.
Any suggestions would be appreciated.
Thanks,
-David
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120521/b122342a/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 21 May 2012 14:12:41 -0400 (EDT)
From: Almohanad Fayez <[email protected]>
To: [email protected], [email protected]
Subject: Re: [USRP-users] FW: E100 problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello Sean, I'm attaching an updated E100 FPGA images that fixes the S-error
(Sequence error) at least on the E100s I have please try it and see if it fixes
your problem. Backup your current FPGA image just in case, it should go in the
following directory:
/usr/share/uhd/images/usrp_e100_fpga_v2.bin
Almohanad (Al) Fayez
-----Original Message-----
From: Nowlan, Sean <[email protected]>
To: USRP-users <[email protected]>
Sent: Thu, May 17, 2012 9:52 am
Subject: [USRP-users] FW: E100 problem
Forwarded from GNU Radio list?
From: [email protected]
[mailto:[email protected]]On Behalf
Of Nowlan, Sean
Sent: Thursday, May 17, 2012 12:47 PM
To: [email protected]
Subject: [Discuss-gnuradio] E100 problem
Hi all,
I?m trying to run benchmark_tx.py on an E100 (rev.3). When I do, I get a bunch
of ?S? symbols printed to the screen and nothing shows up on the Spec Analyzer
except a CW that appears for an instant and then dies. The reported sample rate
is 800ksps. I?m not sure what?s going on. Here?s the command I used:
./benchmark_tx.py -f 910000000 --tx-amplitude=0.3 --non-differential -v
--tx-gain=0.0 --args=?type=E100? -m bpsk -r 400000
The output of uhd_usrp_probe is attached. This is the e1xx-003 release. uname
-a gives:
Linux usrp-e1xx 3.0.0 #1 Mon Mar 26 04:45:32 PDT 2012 armv7l GNU/Linux
Thanks for your help!
Respectfully,
Sean Nowlan
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120521/427faf8e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usrp_e100_fpga_v2.bin
Type: application/octet-stream
Size: 878748 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120521/427faf8e/attachment-0001.bin>
------------------------------
Message: 5
Date: Mon, 21 May 2012 12:17:23 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Setting B100 Master Clock to 61.44 MHz
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 05/21/2012 11:27 AM, David Gibbon wrote:
> I've been attempting, without success, to set my B100 clock to 61.44 MHz.
>
>
Looks like I had some copypasta in the docs from E100. Here is the
proper instructions:
To use the 61.44MHz clock rate, the USRP embedded will require one
jumper to be moved, and X4 must be populated with a 61.44 MHz oscillator.
* J15 is a three pin header, move the jumper to (pin1, pin2)
* 357LB3I061M4400 is the recommended oscillator for X4
-Josh
------------------------------
Message: 6
Date: Mon, 21 May 2012 21:22:09 +0000
From: "Nowlan, Sean" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Time from GPSDO vs. epoch seconds
Message-ID: <195933287DC65748BA7AE867BA8E430B621A08C8@apatlisdmbx02>
Content-Type: text/plain; charset="iso-8859-1"
Hi all,
Last year I did some logging of data using the Epoch seconds obtained by
querying the GPSDO for time. According to the Jackson Labs Firefly-1A manual,
it returns UTC time, which I assume adjusts for leap seconds occurring since
Jan 1, 1970, since that's what the UTC definition specifies.
I just want to confirm that the time register in the FPGA is set by multiplying
dd, yy, mm, h, m, and s by their usual definitions to record Epoch seconds, in
other words, leap seconds are accounted for already. This differs from the
POSIX definition, which doesn't bother with leap seconds, i.e., it is truly the
number of seconds since the Epoch (Jan 1, 1970). Or, correct me if I'm all
mixed up! :-P
Regards,
Sean Nowlan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120521/8418fb98/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 21 May 2012 14:41:55 -0700
From: Nick Foster <[email protected]>
To: "Nowlan, Sean" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Time from GPSDO vs. epoch seconds
Message-ID:
<calalhjwtkukleod9pcsj-e1wmmgobcakrhidgqgewj4d_zx...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
FPGA time is set to whatever you set FPGA time to. It will increment one
second per second. If you set it to GPSDO UTC time using
set_time_next_pps(), that's what it will be. If you set it to POSIX time,
it'll be POSIX time. At initialization, UHD will set the FPGA to GPSDO time
from the Firefly.
--n
On Mon, May 21, 2012 at 2:22 PM, Nowlan, Sean
<[email protected]>wrote:
> Hi all,
>
> Last year I did some logging of data using the Epoch seconds obtained by
> querying the GPSDO for time. According to the Jackson Labs Firefly-1A
> manual, it returns UTC time, which I assume adjusts for leap seconds
> occurring since Jan 1, 1970, since that's what the UTC definition specifies.
>
> I just want to confirm that the time register in the FPGA is set by
> multiplying dd, yy, mm, h, m, and s by their usual definitions to record
> Epoch seconds, in other words, leap seconds are accounted for already. This
> differs from the POSIX definition, which doesn't bother with leap seconds,
> i.e., it is truly the number of seconds since the Epoch (Jan 1, 1970). Or,
> correct me if I'm all mixed up! :-P
>
> Regards,
>
> Sean Nowlan
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120521/08398943/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 21 May 2012 22:45:57 +0000
From: "Nowlan, Sean" <[email protected]>
To: Nick Foster <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Time from GPSDO vs. epoch seconds
Message-ID: <195933287DC65748BA7AE867BA8E430B621A091A@apatlisdmbx02>
Content-Type: text/plain; charset="us-ascii"
FYI - After looking through uhd/host/lib/usrp/gps_ctrl.cpp, I think I
understand what's going on. The code parses the $GPRMC NMEA sentence to get UTC
date and time, which should already be adjusted for leap seconds, since UTC
takes them into account. Then it basically converts this number into a 64-bit
time_t type. Finally UHD initializes the FPGA register to this value, plus one,
on the next PPS. At the end of the day, I think the value represents seconds
since the Epoch, but it *includes* leap seconds.
Sean
From: Nick Foster [mailto:[email protected]]
Sent: Monday, May 21, 2012 5:42 PM
To: Nowlan, Sean
Cc: [email protected]
Subject: Re: [USRP-users] Time from GPSDO vs. epoch seconds
FPGA time is set to whatever you set FPGA time to. It will increment one second
per second. If you set it to GPSDO UTC time using set_time_next_pps(), that's
what it will be. If you set it to POSIX time, it'll be POSIX time. At
initialization, UHD will set the FPGA to GPSDO time from the Firefly.
--n
On Mon, May 21, 2012 at 2:22 PM, Nowlan, Sean
<[email protected]<mailto:[email protected]>> wrote:
Hi all,
Last year I did some logging of data using the Epoch seconds obtained by
querying the GPSDO for time. According to the Jackson Labs Firefly-1A manual,
it returns UTC time, which I assume adjusts for leap seconds occurring since
Jan 1, 1970, since that's what the UTC definition specifies.
I just want to confirm that the time register in the FPGA is set by multiplying
dd, yy, mm, h, m, and s by their usual definitions to record Epoch seconds, in
other words, leap seconds are accounted for already. This differs from the
POSIX definition, which doesn't bother with leap seconds, i.e., it is truly the
number of seconds since the Epoch (Jan 1, 1970). Or, correct me if I'm all
mixed up! :-P
Regards,
Sean Nowlan
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120521/9c47a8d5/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 22 May 2012 11:41:14 +0200
From: Pol Henarejos <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Building UHD using MSVC 2008
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Dear Josh,
The main reason to use MSVC 2008 is that I cannot use MSVC 2010 with
Gnuradio and Qt application. I do not know why but it only works with
2008 version. So I decided to move UHD to 2008 and see if it works. I
followed your suggestion on the patch of an user and it works perfectly.
It is quite strange because the patched code does not seem to be anormal
or with some bug but it can be safely removed. I do not know if the
program will crash from another side or in the future. I will examine it.
If you are interested, I use Windows 7 x64 and a self-compiled boost
library, since there are no x64 binaries.
Thanks and regards.
--
Pol Henarejos
Research Engineer, MSc
[email protected]
Centre Tecnol?gic de Telecomunicacions de Catalunya (CTTC)
Engineering Unit
Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 396 71 70 Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es
On 05/21/2012 12:55 PM, Josh Blum wrote:
On 05/21/2012 08:20 AM, Pol Henarejos wrote:
> Dear list,
>
> I am trying to build UHD driver using MSVC 2008, since it is my
> compiler. I know that in Build Guide MSVC 2010 is required but I have
FWIW, MSVC 2010 express is free
> not it. I would like to request you if you could provide me support for
> this compiler.
>
> When I build UHD using MSVC 2008 everything goes fine. But when I start
> some example or test the program closes suddenly with no useful error
> (windows error 0xc0000005). I tried to run the program as Administrator
> but no luck. Dependancy walker does not say anything anormal. All
> libraries are x64. I use the release mode and the master branch (git
> 003.004.001-145-g38043612). I also do not provide usb support, only usrp2.
>
> Do you have some hint?
>
What you are seeing is an access violation. There is some bug related to
MSVC2008 and boost that causes it. Other users have reported this, but
unfortunately, I have not been able to replicate the issue with MSVC2008
pro and boost 1.47 from boost pro website.
A user posted a patch here that may work around the issue:
http://comments.gmane.org/gmane.comp.hardware.usrp.e100/3420
-josh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 552 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120522/c73d3d0e/attachment-0001.asc>
------------------------------
Message: 10
Date: Tue, 22 May 2012 12:14:52 +0200
From: "Paola Madonna" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Sc8 Over the wire
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi Josh,
I downloaded the UHD master version 003.004.001 because I need to work with
16MSps with DBSRX2+USRP1 to acquire GALILEO signals on a single-channel.
I have the following questions:
* The recv function was modified respect the old version of UHD
003.002.003 which I used to manage multi-channels. Now I need to have a
sample-rate of 16 MSps, so which value of cpu_format do I have to set in
order to manage an otw-wire of sc8?
* How do I have to interpret the sc8 representation? When I worked
with COMPLEX_INT_16, the generic sample was represented as 16I-16Q and now
for sc8 (8I-8Q)?This is important when I read the real and complex samples.
* Does this new UHD version support multi-channel?
Thanks in advance,
__________________
Paola Madonna
Senior SW Engineer
Space&Navigation Unit
TRS S.p.A.
Via Giulio Cesare 105
c/o Selex-SI, Stab. Fusaro
80070 Bacoli (NA)
Italy
Ph.: +39 081 0050 829
Fax: +39 081 52 72 828
Tecnologie nelle Reti e nei Sistemi T.R.S. SpA
Via della Bufalotta, 378 - 00139 Roma
Tel +39.06.87.28.1.1 - Fax +39.06.87.28.1.550
-------------------------------------------------------
Ai sensi del D.Lgs. 196/2003 si precisa che le informazioni contenute in questo
messaggio
sono riservate ed a uso esclusivo del destinatario. Qualora il messaggio in
parola Le
fosse pervenuto per errore, la preghiamo di eliminarlo senza copiarlo e di non
inoltrarlo
a terzi, dandocene gentilmente comunicazione. Grazie.
This message, for the law 196/2003, may contain confidential and/or privileged
information.
If you are not the addressee or authorized to receive this for the addressee,
you must not
use, copy, disclose or take any action based on this message or any information
herein.
If you have received this message in error, please advise the sender
immediately by reply
e-mail and delete this message. Thank you for your cooperation.
-------------------------------------------------------
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120522/5b18d9c6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature_trs.png
Type: image/png
Size: 1506 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120522/5b18d9c6/attachment-0001.png>
------------------------------
Message: 11
Date: Tue, 22 May 2012 10:43:32 -0500
From: "Cary, Paul" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] FPGA and Firmware Images and RS232
Message-ID:
<4d66f6e47222164e9e7604b40bafa91b3333232...@ausp01vmbx10.collaborationhost.net>
Content-Type: text/plain; charset="us-ascii"
Hello,
So I'm monkeying around with the firmware and FPGA images for the USRP N210 R2
and had a few probably really basic questions:
1. While rummaging through the firmware source code, I see a lot of
preprocessor directives that depend on "usrp2" or "usrp2p" being
defined...What's the difference between the two? (I see that the usrp2p has the
bootloader components, but I'm not sure I fully understand what this is
for...is it hexadecimal representation of the zpu opcodes to be loaded into the
RAMB16 instances?)
2. I have connected the UART 1 port (J305) to a serial-to-usb cable and am
monitoring the output in a terminal (Termite 2.9 if it matters). I'm using the
settings: 230400 bps, 8N1, no handshaking and getting gibberish...what is the
baud rate, data bit, stop bit, parity, and such for the N210? (looking at the
firmware code, I think I've got the baud rate right)
Thanks,
Paul Cary
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120522/3dd78931/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 22 May 2012 11:50:25 -0400
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] FPGA and Firmware Images and RS232
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On Tue, 22 May 2012 10:43:32 -0500, Cary, Paul wrote:
> Hello,
>
> So I'm monkeying around with the firmware and FPGA images for the
USRP N210 R2 and had a few probably really basic questions:
>
> 1.
While rummaging through the firmware source code, I see a lot of
preprocessor directives that depend on "usrp2" or "usrp2p" being
defined?What's the difference between the two? (I see that the usrp2p
has the bootloader components, but I'm not sure I fully understand what
this is for?is it hexadecimal representation of the zpu opcodes to be
loaded into the RAMB16 instances?)
>
> 2. I have connected the UART 1
port (J305) to a serial-to-usb cable and am monitoring the output in a
terminal (Termite 2.9 if it matters). I'm using the settings: 230400
bps, 8N1, no handshaking and getting gibberish?what is the baud rate,
data bit, stop bit, parity, and such for the N210? (looking at the
firmware code, I think I've got the baud rate right)
>
> Thanks,
>
>
Paul Cary
usrp2 refers to the original usrp2 hardware platform (now no
longer in production) and usrp2p refers to the newer generation based on
the USRP2 basic design--the N210 and N200.
Here is documentation on
the serial port:
http://files.ettus.com/uhd_docs/manual/html/usrp2.html#monitor-the-serial-output
-Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120522/a4a63e29/attachment-0001.html>
------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 21, Issue 21
******************************************
