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. I/O DIGITAL PINS (Luis Daniel Quintero)
2. Selling a USRP2 (Dean Ferraro)
3. Re: I/O DIGITAL PINS (Ben Hilburn)
4. Re: ADF4360 spi interface can not work (Ben Hilburn)
5. GPSO 1PSS (Damien Serant)
6. Re: GPSO 1PSS (Nick Foster)
7. Re: GPSO 1PSS (Damien Serant)
8. Unsubscribe me please, thanks. (Luis F. Chaparro)
9. offline hopping (Nuria Ibrahim)
10. Re: offline hopping (Nick Foster)
11. Re: GPSO 1PSS (A Bose)
12. Re: GPSO 1PSS (Josh Blum)
13. Re: GPSO 1PSS (Josh Blum)
----------------------------------------------------------------------
Message: 1
Date: Thu, 31 Jan 2013 13:03:52 -0600
From: Luis Daniel Quintero <[email protected]>
To: [email protected]
Subject: [USRP-users] I/O DIGITAL PINS
Message-ID:
<CA+DwuKaicWvb9v4FVM8AkeqYef8ZcSk4bshF4M=wbahhupq...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I'm adapting a signal from the USRP1 to a optical medium. The question is:
Can i recover the received signal directly from the I/O Digital Pins in the
Daughterboard RFX900? If its true, how can i do it??
Any ideas??
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130131/9fa061c4/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 31 Jan 2013 14:39:30 -0500
From: Dean Ferraro <[email protected]>
To: [email protected]
Subject: [USRP-users] Selling a USRP2
Message-ID:
<cahhsw8zjdbmm+gl4bvhwxw1uho7qrik5bwtvdwncecfsfzm...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I have a USRP2 w/LFRX board I'm selling. Price is $1000.
If interested please email me at [email protected]
Thanks,
Dean
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130131/76c3f943/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 31 Jan 2013 13:39:38 -0800
From: Ben Hilburn <[email protected]>
To: Luis Daniel Quintero <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] I/O DIGITAL PINS
Message-ID:
<caoevzkldfti50c4f+ealxe9w-gh8ucovftkokozle8miaba...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Luis -
The analog signal does not go to any I/O pins. If you want to pull the
received signal off of the board, you'll need to modify the FPGA to take
the digital samples and put them back out on a digital I/O on either the
motherboard or daughterboard.
Cheers,
Ben
----------------------------
Ettus Research, LLC <http://www.ettus.com/> | USRP <http://goo.gl/Ixjhh>
On Thu, Jan 31, 2013 at 11:03 AM, Luis Daniel Quintero <
[email protected]> wrote:
> Hi,
>
> I'm adapting a signal from the USRP1 to a optical medium. The question is:
> Can i recover the received signal directly from the I/O Digital Pins in the
> Daughterboard RFX900? If its true, how can i do it??
>
> Any ideas??
>
>
>
> _______________________________________________
> 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/20130131/3ac48750/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 31 Jan 2013 13:42:33 -0800
From: Ben Hilburn <[email protected]>
To: Page Jack <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] ADF4360 spi interface can not work
Message-ID:
<caoevzklopozu2xfqn45yngkoythev3gstxjgwya8_ttvxia...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Jack -
Are you aware that we sell daughterboards that are far newer, and have much
better performance, than the RFX boards? Both the SBX and WBX have the
ADF4350 on them.
Regardless, if you want to make your modified RFX work, you'll need to
write the register map for it, as well as the driver in UHD that instructs
UHD how to control the chip. Look at how the 4350 register map is
implemented in ic_reg_maps/ and then write your own daughterboard class
that implements the control algorithms defined in the chip's datasheet.
Cheers,
Ben
----------------------------
Ettus Research, LLC <http://www.ettus.com/> | USRP <http://goo.gl/Ixjhh>
On Tue, Jan 29, 2013 at 11:03 PM, Page Jack <[email protected]> wrote:
> Hi list,
> For poor performance of rfx1800 I make a daughter board for my needs. I
> swear the board is only used in my product.
> The pll part is exactly the same with rfx1800, but the ADF4360 spi can not
> work properly with mother board. when I connect
> the board to mother board the frequency tuning can not work, the ADF4360
> do not lock. but if I use a mcu board connect to
> the daughter board and set the ADF4360. ADF4360 can lock. So it seems my
> daughter board do not fit usrp mother board well
> So ettus can you provide me some hint with making daughter board for usrp.
> I can provide schematic and pcb layout of my board.
>
> Regards!
>
> _______________________________________________
> 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/20130131/632375d7/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 1 Feb 2013 01:00:40 +0100
From: Damien Serant <[email protected]>
To: USRP List <[email protected]>
Subject: [USRP-users] GPSO 1PSS
Message-ID:
<CAM=tnlnixa1f54wjdffkctkxrvwflwea7wzdpqbs6ggmsqc...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi list,
Two small issues about 1PPS signal with the GPSDO:
1) When i run the query_gpsdo_sensors util i obtain : "GPS locked", "10
MHz" locked but always "GPS and UHD Device time are NOT aligned" (I triple
checked the 1PPS connection)
2) I my program the time get from the "get_time_last_pps()" function is
surprisingly never a full second (about 500 ns before or after a full
second). In the same way, when i set the time spec of a receiver stream
with get_time_last_pps() + 1, i never get a full second in the time spec
field of the metadata of the first received packet .
This is a normal behavior and if yes why ?
Configuration; win XP, USRP N200 r4 with SBX daughterboard, UHD 351.
Thanks,
Damien
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130201/eb48f088/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 31 Jan 2013 16:12:35 -0800
From: Nick Foster <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] GPSO 1PSS
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Forgot to cc list.
On 01/31/2013 04:12 PM, Nick Foster wrote:
> On 01/31/2013 04:00 PM, Damien Serant wrote:
>> Hi list,
>>
>> Two small issues about 1PPS signal with the GPSDO:
>> 1) When i run the query_gpsdo_sensors util i obtain : "GPS locked",
>> "10 MHz" locked but always "GPS and UHD Device time are NOT aligned"
>> (I triple checked the 1PPS connection)
> We just recently fixed a bug relating to this. The PPS functionality
> is fine; the query_gpsdo_sensors program wasn't waiting long enough to
> be sure the PPS had been latched in. It's checked into master, but I
> don't think a release has been cut since then.
>
>> 2) I my program the time get from the "get_time_last_pps()"
>> function is surprisingly never a full second (about 500 ns before or
>> after a full second). In the same way, when i set the time spec of a
>> receiver stream with get_time_last_pps() + 1, i never get a full
>> second in the time spec field of the metadata of the first received
>> packet .
>> This is a normal behavior and if yes why ?
> Can you cut and paste the relevant section of code?
>
> --n
>
>>
>> Configuration; win XP, USRP N200 r4 with SBX daughterboard, UHD 351.
>>
>> Thanks,
>>
>> Damien
>>
>>
>> _______________________________________________
>> 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/20130131/70b9979b/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 1 Feb 2013 02:31:06 +0100
From: Damien Serant <[email protected]>
To: Nick Foster <[email protected]>
Cc: USRP List <[email protected]>
Subject: Re: [USRP-users] GPSO 1PSS
Message-ID:
<CAM=tNLkUe1D5zU-96gB1ugA_vQ24Ge=xcpuyjx+fib8oayb...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Thanks Nick for your kick answer.
"We just recently fixed a bug relating to this."
I know. I am using UHD 003.005.001 (from installer) which contains
the patch according to the repository. May be the installer does not have
the patch ? I will try tomorrow to build from source.
"Can you cut and paste the relevant section of code?"
>From memory (i don't have access to my code right now) :
For the stream command config:
uhd::stream_cmd_t
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
stream_cmd.stream_now = false;
stream_cmd.time_spec = get_time_last_pps()+1;
usrp->issue_stream_cmd(stream_cmd);
cout<<fixed<<setprecision(9)<<get_time_last_pps().get_real_secs()<<endl;
//Not full sec
For the receiving part:
nbSamp = 0;
timeout = 3;
while(nbSamp<nbSampTot){
num_rx_samps = rx_stream->recv(&buff.front(), buff.size(), md, timeout);
//buff.size() about 100000
if(nbSamp == 0){
cout<<fixed<<setprecision(9)<<md.time_spec.get_real_secs()<<endl; //Not
full sec
}
timeout = 0.1;
nbSamp+=num_rx_samps;
...
}
May be i don't use the right method to extract the time from the time spec ?
Since i wrote this from memory it is possible that there is an error in my
actual code and not here...
Damien
2013/2/1 Nick Foster <[email protected]>
> On 01/31/2013 04:00 PM, Damien Serant wrote:
>
> Hi list,
>
> Two small issues about 1PPS signal with the GPSDO:
> 1) When i run the query_gpsdo_sensors util i obtain : "GPS locked", "10
> MHz" locked but always "GPS and UHD Device time are NOT aligned" (I triple
> checked the 1PPS connection)
>
> We just recently fixed a bug relating to this. The PPS functionality is
> fine; the query_gpsdo_sensors program wasn't waiting long enough to be sure
> the PPS had been latched in. It's checked into master, but I don't think a
> release has been cut since then.
>
>
> 2) I my program the time get from the "get_time_last_pps()" function
> is surprisingly never a full second (about 500 ns before or after a full
> second). In the same way, when i set the time spec of a receiver stream
> with get_time_last_pps() + 1, i never get a full second in the time spec
> field of the metadata of the first received packet .
> This is a normal behavior and if yes why ?
>
> Can you cut and paste the relevant section of code?
>
> --n
>
>
> Configuration; win XP, USRP N200 r4 with SBX daughterboard, UHD 351.
>
> Thanks,
>
> Damien
>
>
> _______________________________________________
> USRP-users mailing
> [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/20130201/030ea837/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 31 Jan 2013 21:40:23 -0500
From: "Luis F. Chaparro" <[email protected]>
To: [email protected]
Subject: [USRP-users] Unsubscribe me please, thanks.
Message-ID:
<CAHwUKnx=afQaBw7A3cQYNcQWfT7T=jtzy5mawyjb+1msvxg...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130131/6d793923/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 31 Jan 2013 22:29:12 -0800 (PST)
From: Nuria Ibrahim <[email protected]>
To: usrp users forum <[email protected]>
Subject: [USRP-users] offline hopping
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Dear Mr Josh
I want to capture entire GSM900 band i.e 25MHz wide signal and do offline
hopping in my PC.To sample 25MHz wide signal I would need sampling rate of
50MHz(Nyquist sampling theorem), however how can I achieve this rate given the
USRPN200 minimum decimation rate of 4(i.e 25MHz input rate)?
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130131/a811aaa0/attachment-0001.html>
------------------------------
Message: 10
Date: Thu, 31 Jan 2013 23:09:53 -0800
From: Nick Foster <[email protected]>
To: Nuria Ibrahim <[email protected]>, [email protected]
Subject: Re: [USRP-users] offline hopping
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
You can do 50Msps if you use 8-bit sampling. If you're using
rx_samples_to_file to capture samples, you can use the --wirefmt=sc8
option to select 8-bit samples.
--n
On 01/31/2013 10:29 PM, Nuria Ibrahim wrote:
> Dear Mr Josh
>
> I want to capture entire GSM900 band i.e 25MHz wide signal and do
> offline hopping in my PC.To sample 25MHz wide signal I would need
> sampling rate of 50MHz(Nyquist sampling theorem), however how can I
> achieve this rate given the USRPN200 minimum decimation rate of 4(i.e
> 25MHz input rate)?
>
> Thanks!
>
>
>
> _______________________________________________
> 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/20130131/02516627/attachment-0001.html>
------------------------------
Message: 11
Date: Fri, 1 Feb 2013 11:09:36 -0500
From: "A Bose" <[email protected]>
To: "'Damien Serant'" <[email protected]>, "'Nick Foster'"
<[email protected]>
Cc: 'USRP List' <[email protected]>
Subject: Re: [USRP-users] GPSO 1PSS
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I am having the exact same problem and I found this discrepancy:
The latest
http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/fac15d
b5d77c5196badb4a06f2f5fec34eb57337/entry/host/lib/transport/super_recv_packe
t_handler.hpp has fixed the meta time to include seconds:
info.time = time_spec_t(time_t(info.ifpi.tsi), size_t(info.ifpi.tsf),
_tick_rate); //assumes has_tsi and has_tsf are true
but the 003.005.001 release has the old code bug with no seconds:
info.time = time_spec_t::from_ticks(info.ifpi.tsf, _tick_rate); //assumes
has_tsf is true
I am running with an old FPGA rev and this fix doesn't work for me, so I am
assuming there is/was something wrong on the FPGA side as well? If so does
anyone know what exactly was fixed (what rev)?
From: USRP-users [mailto:[email protected]] On Behalf Of
Damien Serant
Sent: Thursday, January 31, 2013 8:31 PM
To: Nick Foster
Cc: USRP List
Subject: Re: [USRP-users] GPSO 1PSS
Thanks Nick for your kick answer.
"We just recently fixed a bug relating to this."
I know. I am using UHD 003.005.001 (from installer) which contains the patch
according to the repository. May be the installer does not have the patch ?
I will try tomorrow to build from source.
"Can you cut and paste the relevant section of code?"
>From memory (i don't have access to my code right now) :
For the stream command config:
uhd::stream_cmd_t
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
stream_cmd.stream_now = false;
stream_cmd.time_spec = get_time_last_pps()+1;
usrp->issue_stream_cmd(stream_cmd);
cout<<fixed<<setprecision(9)<<get_time_last_pps().get_real_secs()<<endl;
//Not full sec
For the receiving part:
nbSamp = 0;
timeout = 3;
while(nbSamp<nbSampTot){
num_rx_samps = rx_stream->recv(&buff.front(), buff.size(), md, timeout);
//buff.size() about 100000
if(nbSamp == 0){
cout<<fixed<<setprecision(9)<<md.time_spec.get_real_secs()<<endl; //Not
full sec
}
timeout = 0.1;
nbSamp+=num_rx_samps;
...
}
May be i don't use the right method to extract the time from the time spec ?
Since i wrote this from memory it is possible that there is an error in my
actual code and not here...
Damien
2013/2/1 Nick Foster <[email protected]>
On 01/31/2013 04:00 PM, Damien Serant wrote:
Hi list,
Two small issues about 1PPS signal with the GPSDO:
1) When i run the query_gpsdo_sensors util i obtain : "GPS locked", "10
MHz" locked but always "GPS and UHD Device time are NOT aligned" (I triple
checked the 1PPS connection)
We just recently fixed a bug relating to this. The PPS functionality is
fine; the query_gpsdo_sensors program wasn't waiting long enough to be sure
the PPS had been latched in. It's checked into master, but I don't think a
release has been cut since then.
2) I my program the time get from the "get_time_last_pps()" function is
surprisingly never a full second (about 500 ns before or after a full
second). In the same way, when i set the time spec of a receiver stream
with get_time_last_pps() + 1, i never get a full second in the time spec
field of the metadata of the first received packet .
This is a normal behavior and if yes why ?
Can you cut and paste the relevant section of code?
--n
Configuration; win XP, USRP N200 r4 with SBX daughterboard, UHD 351.
Thanks,
Damien
_______________________________________________
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/20130201/01e6755d/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 01 Feb 2013 10:23:50 -0600
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] GPSO 1PSS
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 02/01/2013 10:09 AM, A Bose wrote:
> I am having the exact same problem and I found this discrepancy:
>
>
>
> The latest
>
> http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/fac15d
> b5d77c5196badb4a06f2f5fec34eb57337/entry/host/lib/transport/super_recv_packe
> t_handler.hpp has fixed the meta time to include seconds:
>
> info.time = time_spec_t(time_t(info.ifpi.tsi), size_t(info.ifpi.tsf),
> _tick_rate); //assumes has_tsi and has_tsf are true
>
>
>
> but the 003.005.001 release has the old code bug with no seconds:
>
> info.time = time_spec_t::from_ticks(info.ifpi.tsf, _tick_rate); //assumes
> has_tsf is true
>
The time is always parsed from the packet, even if the fields may not
have been populated. The time is qualified with the has_time_spec which
is also parsed from the packet. So time is only valid if the boolean
field says true.
>
>
> I am running with an old FPGA rev and this fix doesn't work for me, so I am
> assuming there is/was something wrong on the FPGA side as well? If so does
> anyone know what exactly was fixed (what rev)?
>
Sorry I am unsure, but what exactly is the issue?
-josh
>
>
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Damien Serant
> Sent: Thursday, January 31, 2013 8:31 PM
> To: Nick Foster
> Cc: USRP List
> Subject: Re: [USRP-users] GPSO 1PSS
>
>
>
> Thanks Nick for your kick answer.
>
>
>
> "We just recently fixed a bug relating to this."
>
> I know. I am using UHD 003.005.001 (from installer) which contains the patch
> according to the repository. May be the installer does not have the patch ?
> I will try tomorrow to build from source.
>
>
>
> "Can you cut and paste the relevant section of code?"
>
> From memory (i don't have access to my code right now) :
>
>
>
> For the stream command config:
>
> uhd::stream_cmd_t
> stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
>
> stream_cmd.stream_now = false;
>
> stream_cmd.time_spec = get_time_last_pps()+1;
>
> usrp->issue_stream_cmd(stream_cmd);
>
> cout<<fixed<<setprecision(9)<<get_time_last_pps().get_real_secs()<<endl;
> //Not full sec
>
>
>
> For the receiving part:
>
> nbSamp = 0;
>
> timeout = 3;
>
> while(nbSamp<nbSampTot){
>
> num_rx_samps = rx_stream->recv(&buff.front(), buff.size(), md, timeout);
> //buff.size() about 100000
>
> if(nbSamp == 0){
>
> cout<<fixed<<setprecision(9)<<md.time_spec.get_real_secs()<<endl; //Not
> full sec
>
> }
>
> timeout = 0.1;
>
> nbSamp+=num_rx_samps;
>
> ...
>
> }
>
>
>
> May be i don't use the right method to extract the time from the time spec ?
>
> Since i wrote this from memory it is possible that there is an error in my
> actual code and not here...
>
>
>
>
>
> Damien
>
>
>
> 2013/2/1 Nick Foster <[email protected]>
>
> On 01/31/2013 04:00 PM, Damien Serant wrote:
>
> Hi list,
>
>
>
> Two small issues about 1PPS signal with the GPSDO:
>
> 1) When i run the query_gpsdo_sensors util i obtain : "GPS locked", "10
> MHz" locked but always "GPS and UHD Device time are NOT aligned" (I triple
> checked the 1PPS connection)
>
> We just recently fixed a bug relating to this. The PPS functionality is
> fine; the query_gpsdo_sensors program wasn't waiting long enough to be sure
> the PPS had been latched in. It's checked into master, but I don't think a
> release has been cut since then.
>
>
>
>
>
>
> 2) I my program the time get from the "get_time_last_pps()" function is
> surprisingly never a full second (about 500 ns before or after a full
> second). In the same way, when i set the time spec of a receiver stream
> with get_time_last_pps() + 1, i never get a full second in the time spec
> field of the metadata of the first received packet .
>
> This is a normal behavior and if yes why ?
>
> Can you cut and paste the relevant section of code?
>
> --n
>
>
>
>
>
>
> Configuration; win XP, USRP N200 r4 with SBX daughterboard, UHD 351.
>
>
>
> Thanks,
>
>
> Damien
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 13
Date: Fri, 01 Feb 2013 10:28:11 -0600
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] GPSO 1PSS
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 01/31/2013 07:31 PM, Damien Serant wrote:
> Thanks Nick for your kick answer.
>
> "We just recently fixed a bug relating to this."
> I know. I am using UHD 003.005.001 (from installer) which contains
> the patch according to the repository. May be the installer does not have
> the patch ? I will try tomorrow to build from source.
>
> "Can you cut and paste the relevant section of code?"
> From memory (i don't have access to my code right now) :
>
> For the stream command config:
> uhd::stream_cmd_t
> stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
> stream_cmd.stream_now = false;
> stream_cmd.time_spec = get_time_last_pps()+1;
FYI, its possible that you could get a late command if
1) if get_time_last_pps()+1 is actually on the hairy edge of the
beginning of a new pps and the command ended up getting into the device
right after the pps
or 2) there wasnt a pps to continually update this value
> usrp->issue_stream_cmd(stream_cmd);
> cout<<fixed<<setprecision(9)<<get_time_last_pps().get_real_secs()<<endl;
> //Not full sec
>
> For the receiving part:
> nbSamp = 0;
> timeout = 3;
> while(nbSamp<nbSampTot){
> num_rx_samps = rx_stream->recv(&buff.front(), buff.size(), md, timeout);
> //buff.size() about 100000
> if(nbSamp == 0){
> cout<<fixed<<setprecision(9)<<md.time_spec.get_real_secs()<<endl; //Not
> full sec
> }
> timeout = 0.1;
> nbSamp+=num_rx_samps;
> ...
> }
>
> May be i don't use the right method to extract the time from the time spec ?
> Since i wrote this from memory it is possible that there is an error in my
> actual code and not here...
>
>
The real seconds is a double field in units of seconds, but its not
actually enough precision to represent the time in seconds. Thats why
there is an integer full seconds and a fractional only seconds.
You may noticed that the get_time_last_pps()+1 was not exactly the time
requested. This is because the DSP units were run exactly at that time,
but the samples were timestampped after the filter group delay.
-josh
> Damien
>
>
> 2013/2/1 Nick Foster <[email protected]>
>
>> On 01/31/2013 04:00 PM, Damien Serant wrote:
>>
>> Hi list,
>>
>> Two small issues about 1PPS signal with the GPSDO:
>> 1) When i run the query_gpsdo_sensors util i obtain : "GPS locked", "10
>> MHz" locked but always "GPS and UHD Device time are NOT aligned" (I triple
>> checked the 1PPS connection)
>>
>> We just recently fixed a bug relating to this. The PPS functionality is
>> fine; the query_gpsdo_sensors program wasn't waiting long enough to be sure
>> the PPS had been latched in. It's checked into master, but I don't think a
>> release has been cut since then.
>>
>>
>> 2) I my program the time get from the "get_time_last_pps()" function
>> is surprisingly never a full second (about 500 ns before or after a full
>> second). In the same way, when i set the time spec of a receiver stream
>> with get_time_last_pps() + 1, i never get a full second in the time spec
>> field of the metadata of the first received packet .
>> This is a normal behavior and if yes why ?
>>
>> Can you cut and paste the relevant section of code?
>>
>> --n
>>
>>
>> Configuration; win XP, USRP N200 r4 with SBX daughterboard, UHD 351.
>>
>> Thanks,
>>
>> Damien
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
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 30, Issue 1
*****************************************
