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: GPSO Vita timestamp (A Bose)
2. Re: Unsubscribe me please, thanks. (Ben Hilburn)
3. Re: GPSO Vita timestamp (Josh Blum)
4. Re: GPSO Vita timestamp (A Bose)
5. Re: GPSO 1PSS (Damien Serant)
6. USRP-Tx (babar aziz)
7. Re: GPSO Vita timestamp (Josh Blum)
8. Re: USRP-Tx (Nazmul Islam)
9. Re: GPSO 1PSS (Josh Blum)
----------------------------------------------------------------------
Message: 1
Date: Fri, 1 Feb 2013 14:36:44 -0500
From: "A Bose" <[email protected]>
To: <[email protected]>, <[email protected]>
Subject: Re: [USRP-users] GPSO Vita timestamp
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello,
I am using a N200 and UHD in windows, and I am trying to set the VITA frame
timestamp to the GPS time. The md.time_spec.get_full_secs() seems to go
positive and negative and is just random and is the same at the
super_recv_packet_handler.hpp after the packet receive.
Here is my code:
usrp->set_clock_source("external");
//set_time_source allows the FPGAs internal tick counter to be
synchronized by a PPS pulse coming into the external SMA
usrp->set_time_source("external");
...
//setup the VITA frame time to gps_time
uhd::sensor_value_t gps_time = usrp->get_mboard_sensor("gps_time");
uhd::time_spec_t gpsTime = uhd::time_spec_t(1.0)
+uhd::time_spec_t((double)gps_time.to_int());
//set the gps time
usrp->set_time_next_pps(gpsTime);
boost::this_thread::sleep(boost::posix_time::seconds(1.5)); //wait for pps
sync pulse
uhd::time_spec_t last_pps_time2 = usrp->get_time_last_pps();
boost::posix_time::ptime tpps(date(1970,1,1),
boost::posix_time::seconds(last_pps_time2.get_full_secs()));
std::string testLastPPS = to_simple_string(tpps); //THIS IS GOOD
//setup streaming
uhd::stream_cmd_t stream_cmd((num_requested_samples == 0)?
uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS:
uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE
);
stream_cmd.num_samps = num_requested_samples;
stream_cmd.stream_now = true;
stream_cmd.time_spec = uhd::time_spec_t();
usrp->issue_stream_cmd(stream_cmd);
while(not stop_signal_called and (num_requested_samples !=
num_total_samps or num_requested_samples == 0)){
size_t num_rx_samps = rx_stream->recv(&buff.front(), buff.size(),
md, 3.0);
...
//error checking
...
num_total_samps += num_rx_samps;
outfile.write((const char*)&buff.front(),
num_rx_samps*sizeof(samp_type));
}
boost::posix_time::ptime t0(date(1970,1,1),
boost::posix_time::seconds(md.time_spec.get_full_secs()));
std::string test0 = to_simple_string(t0); //THIS IS BAD
//get pps time again to check
uhd::time_spec_t last_pps_time3 = usrp->get_time_last_pps();
boost::posix_time::ptime tpps3(date(1970,1,1),
boost::posix_time::seconds(last_pps_time3.get_full_secs()));
std::string testLastPPS3 = to_simple_string(tpps); //THIS IS GOOD
The Vita Frame timestamp just doesn't seem to be set to the internal time.
Any ideas?
Thanks,
A Bose
-----Original Message-----
From: USRP-users [mailto:[email protected]] On Behalf Of
Josh Blum
Sent: Friday, February 01, 2013 11:24 AM
To: [email protected]
Subject: Re: [USRP-users] GPSO 1PSS
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()<<end
> l;
> //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
>
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 2
Date: Fri, 1 Feb 2013 12:09:18 -0800
From: Ben Hilburn <[email protected]>
To: "Luis F. Chaparro" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Unsubscribe me please, thanks.
Message-ID:
<caoevzkkysr9rktr0rirgvc5_mzmtrm29s1zzrtu+4ux6fvx...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Luis -
You can unsubscribe from this list on the same page you used to subscribe
to it:
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Cheers,
Ben
----------------------------
Ettus Research, LLC <http://www.ettus.com/> | USRP <http://goo.gl/Ixjhh>
On Thu, Jan 31, 2013 at 6:40 PM, Luis F. Chaparro <[email protected]>wrote:
>
>
> _______________________________________________
> 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/6612825b/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 01 Feb 2013 14:55:22 -0600
From: Josh Blum <[email protected]>
To: A Bose <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] GPSO Vita timestamp
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 02/01/2013 01:36 PM, A Bose wrote:
> Hello,
>
> I am using a N200 and UHD in windows, and I am trying to set the VITA frame
> timestamp to the GPS time. The md.time_spec.get_full_secs() seems to go
> positive and negative and is just random and is the same at the
> super_recv_packet_handler.hpp after the packet receive.
>
> Here is my code:
>
> usrp->set_clock_source("external");
> //set_time_source allows the FPGAs internal tick counter to be
> synchronized by a PPS pulse coming into the external SMA
> usrp->set_time_source("external");
> ...
> //setup the VITA frame time to gps_time
> uhd::sensor_value_t gps_time = usrp->get_mboard_sensor("gps_time");
> uhd::time_spec_t gpsTime = uhd::time_spec_t(1.0)
> +uhd::time_spec_t((double)gps_time.to_int());
>
> //set the gps time
> usrp->set_time_next_pps(gpsTime);
> boost::this_thread::sleep(boost::posix_time::seconds(1.5)); //wait for pps
> sync pulse
> uhd::time_spec_t last_pps_time2 = usrp->get_time_last_pps();
>
> boost::posix_time::ptime tpps(date(1970,1,1),
> boost::posix_time::seconds(last_pps_time2.get_full_secs()));
> std::string testLastPPS = to_simple_string(tpps); //THIS IS GOOD
>
> //setup streaming
> uhd::stream_cmd_t stream_cmd((num_requested_samples == 0)?
> uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS:
> uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE
> );
> stream_cmd.num_samps = num_requested_samples;
> stream_cmd.stream_now = true;
> stream_cmd.time_spec = uhd::time_spec_t();
>
> usrp->issue_stream_cmd(stream_cmd);
>
> while(not stop_signal_called and (num_requested_samples !=
> num_total_samps or num_requested_samples == 0)){
> size_t num_rx_samps = rx_stream->recv(&buff.front(), buff.size(),
> md, 3.0);
> ...
> //error checking
> ...
> num_total_samps += num_rx_samps;
> outfile.write((const char*)&buff.front(),
> num_rx_samps*sizeof(samp_type));
> }
>
> boost::posix_time::ptime t0(date(1970,1,1),
> boost::posix_time::seconds(md.time_spec.get_full_secs()));
> std::string test0 = to_simple_string(t0); //THIS IS BAD
OK I see what the test is doing.
So, can you tell me, what is the value of:
md.has_time_spec
md.error_code
md.time_spec.get_full_secs()
md.time_spec.get_frac_secs()
-josh
>
> //get pps time again to check
> uhd::time_spec_t last_pps_time3 = usrp->get_time_last_pps();
> boost::posix_time::ptime tpps3(date(1970,1,1),
> boost::posix_time::seconds(last_pps_time3.get_full_secs()));
> std::string testLastPPS3 = to_simple_string(tpps); //THIS IS GOOD
>
>
> The Vita Frame timestamp just doesn't seem to be set to the internal time.
>
> Any ideas?
>
> Thanks,
> A Bose
>
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Josh Blum
> Sent: Friday, February 01, 2013 11:24 AM
> To: [email protected]
> Subject: Re: [USRP-users] GPSO 1PSS
>
>
>
> 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()<<end
>> l;
>> //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
>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 4
Date: Fri, 1 Feb 2013 16:48:19 -0500
From: "A Bose" <[email protected]>
To: <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] GPSO Vita timestamp
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
md.has_time_spec = true
md.error_code = ERROR_CODE_NONE
md.time_spec.get_full_secs() = 56935896589
md.time_spec.get_frac_secs() = 0.74093313000000005
md.timespec = UTC "2004-Nov-24 18:42:21"
-----------------------------------------------------------------
If I run the code a couple more time again I get:
md.time_spec = {_full_secs=-31005044168 _frac_secs=0.65193984000000005 }
md .time_spec = {_full_secs=-20673319605 _frac_secs=0.40310016000000004 }
md .time_spec = {_full_secs=-52058959422 _frac_secs=0.74874366999999997 }
md .time_spec = {_full_secs=-29287266028 _frac_secs=0.69364738999999997 }
power cycle
md .time_spec = {_full_secs=19686160971 _frac_secs=0.20780288000000000 }
md .time_spec = {_full_secs=89173861499 _frac_secs=0.37283071000000001 }
md.time_spec = {_full_secs=-46045442223 _frac_secs=0.46386945999999996 }
md .time_spec = {_full_secs=-53333033252 _frac_secs=0.32941052000000004 }
md.time_spec = {_full_secs=-87239595147 _frac_secs=0.76753658000000002 }
Thanks for any input,
A Bose
-----Original Message-----
From: Josh Blum [mailto:[email protected]] On Behalf Of Josh Blum
Sent: Friday, February 01, 2013 3:55 PM
To: A Bose
Cc: [email protected]
Subject: Re: [USRP-users] GPSO Vita timestamp
On 02/01/2013 01:36 PM, A Bose wrote:
> Hello,
>
> I am using a N200 and UHD in windows, and I am trying to set the VITA
> frame timestamp to the GPS time. The md.time_spec.get_full_secs()
> seems to go positive and negative and is just random and is the same
> at the super_recv_packet_handler.hpp after the packet receive.
>
> Here is my code:
>
> usrp->set_clock_source("external");
> //set_time_source allows the FPGAs internal tick counter to be
> synchronized by a PPS pulse coming into the external SMA
> usrp->set_time_source("external");
> ...
> //setup the VITA frame time to gps_time uhd::sensor_value_t gps_time =
> usrp->get_mboard_sensor("gps_time");
> uhd::time_spec_t gpsTime = uhd::time_spec_t(1.0)
> +uhd::time_spec_t((double)gps_time.to_int());
>
> //set the gps time
> usrp->set_time_next_pps(gpsTime);
> boost::this_thread::sleep(boost::posix_time::seconds(1.5)); //wait for
> pps sync pulse uhd::time_spec_t last_pps_time2 =
> usrp->get_time_last_pps();
>
> boost::posix_time::ptime tpps(date(1970,1,1),
> boost::posix_time::seconds(last_pps_time2.get_full_secs()));
> std::string testLastPPS = to_simple_string(tpps); //THIS IS GOOD
>
> //setup streaming
> uhd::stream_cmd_t stream_cmd((num_requested_samples == 0)?
> uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS:
> uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE
> );
> stream_cmd.num_samps = num_requested_samples;
> stream_cmd.stream_now = true;
> stream_cmd.time_spec = uhd::time_spec_t();
>
> usrp->issue_stream_cmd(stream_cmd);
>
> while(not stop_signal_called and (num_requested_samples !=
> num_total_samps or num_requested_samples == 0)){
> size_t num_rx_samps = rx_stream->recv(&buff.front(),
> buff.size(), md, 3.0);
> ...
> //error checking
> ...
> num_total_samps += num_rx_samps;
> outfile.write((const char*)&buff.front(),
> num_rx_samps*sizeof(samp_type));
> }
>
> boost::posix_time::ptime t0(date(1970,1,1),
> boost::posix_time::seconds(md.time_spec.get_full_secs()));
> std::string test0 = to_simple_string(t0); //THIS IS BAD
OK I see what the test is doing.
So, can you tell me, what is the value of:
md.has_time_spec
md.error_code
md.time_spec.get_full_secs()
md.time_spec.get_frac_secs()
-josh
>
> //get pps time again to check
> uhd::time_spec_t last_pps_time3 = usrp->get_time_last_pps();
> boost::posix_time::ptime tpps3(date(1970,1,1),
> boost::posix_time::seconds(last_pps_time3.get_full_secs()));
> std::string testLastPPS3 = to_simple_string(tpps); //THIS IS GOOD
>
>
> The Vita Frame timestamp just doesn't seem to be set to the internal time.
>
> Any ideas?
>
> Thanks,
> A Bose
>
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf
> Of Josh Blum
> Sent: Friday, February 01, 2013 11:24 AM
> To: [email protected]
> Subject: Re: [USRP-users] GPSO 1PSS
>
>
>
> 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_rec
>> v _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()<<en
>> d
>> l;
>> //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
>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 5
Date: Fri, 1 Feb 2013 23:02:12 +0100
From: Damien Serant <[email protected]>
To: [email protected]
Cc: USRP List <[email protected]>
Subject: Re: [USRP-users] GPSO 1PSS
Message-ID:
<CAM=tNLmpFqONZhhi=p89co+dva20qld7bl76yxzcv_g3nvl...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I confirm the issue with the query_gpsdo_sensors util that i built myself
from the version in the git repo (master branch). I always get the error
message "GPS and UHD Device time are NOT aligned". I found why and how
correct that :
Actually on my PC, last_pps_time.get_full_secs() and gps_time.to_int() have
different values and the difference between the two integers is 1 while
thier real values are very close. Perhaps a rounding issue. My work around
is to use the following condition instead:
if (abs(last_pps_time.get_real_secs() - gps_time.to_real())<DBL_EPSILON)
For the second issue I confirm also:
I configure the stream command with a time t which is a full second (equal
to get_last_pps() command +1)
In the metadata of the fisrt received packet i get : t+eps, where eps is
constant from a test to another, but change with the sampling frequency:
about 5000 ns at 0.2 Mhz, 700 ns at 2 Mhz, 200 ns at 10 Mhz and 200 ns at
20 Mhz (however this is true that i obtained this value from the
get_real_sec()...). You can test that with the rx_timed_samples example
with some modification (no set_time_now() and augmentation of the number of
decimals when printing the metadata time).
This time offset is too important to be the filter group delay, no ?
So my question is: what is the right time of the samples : the time
requested in the issue stream command or the time in the metadata of the
first packet ?
Thanks in advance
Damien
2013/2/1 Josh Blum <[email protected]>
>
>
> 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]://
> 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
> >
>
> _______________________________________________
> 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/7e895a7a/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 1 Feb 2013 23:23:32 +0000
From: babar aziz <[email protected]>
To: <[email protected]>
Subject: [USRP-users] USRP-Tx
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hello everyone,
I am new to USRP. I have some data(I&Q) in a .dat file and I want to transmit
with USRP using simulink.
Can any body give me hints/links/tutorials to do this.
Thanking in advance
====================================
Best Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130201/f24bd9c9/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 01 Feb 2013 17:30:21 -0600
From: Josh Blum <[email protected]>
To: A Bose <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] GPSO Vita timestamp
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 02/01/2013 03:48 PM, A Bose wrote:
> md.has_time_spec = true
> md.error_code = ERROR_CODE_NONE
> md.time_spec.get_full_secs() = 56935896589
I agree, these full seconds count look kind of like random junk.
That number is larger than 32 bits.
Does your system have a 32 bit or 64 bit time_t?
-josh
> md.time_spec.get_frac_secs() = 0.74093313000000005
>
> md.timespec = UTC "2004-Nov-24 18:42:21"
>
> -----------------------------------------------------------------
> If I run the code a couple more time again I get:
> md.time_spec = {_full_secs=-31005044168 _frac_secs=0.65193984000000005 }
> md .time_spec = {_full_secs=-20673319605 _frac_secs=0.40310016000000004 }
> md .time_spec = {_full_secs=-52058959422 _frac_secs=0.74874366999999997 }
> md .time_spec = {_full_secs=-29287266028 _frac_secs=0.69364738999999997 }
> power cycle
> md .time_spec = {_full_secs=19686160971 _frac_secs=0.20780288000000000 }
> md .time_spec = {_full_secs=89173861499 _frac_secs=0.37283071000000001 }
> md.time_spec = {_full_secs=-46045442223 _frac_secs=0.46386945999999996 }
> md .time_spec = {_full_secs=-53333033252 _frac_secs=0.32941052000000004 }
> md.time_spec = {_full_secs=-87239595147 _frac_secs=0.76753658000000002 }
>
>
> Thanks for any input,
> A Bose
>
> -----Original Message-----
> From: Josh Blum [mailto:[email protected]] On Behalf Of Josh Blum
> Sent: Friday, February 01, 2013 3:55 PM
> To: A Bose
> Cc: [email protected]
> Subject: Re: [USRP-users] GPSO Vita timestamp
>
>
>
> On 02/01/2013 01:36 PM, A Bose wrote:
>> Hello,
>>
>> I am using a N200 and UHD in windows, and I am trying to set the VITA
>> frame timestamp to the GPS time. The md.time_spec.get_full_secs()
>> seems to go positive and negative and is just random and is the same
>> at the super_recv_packet_handler.hpp after the packet receive.
>>
>> Here is my code:
>>
>> usrp->set_clock_source("external");
>> //set_time_source allows the FPGAs internal tick counter to be
>> synchronized by a PPS pulse coming into the external SMA
>> usrp->set_time_source("external");
>> ...
>> //setup the VITA frame time to gps_time uhd::sensor_value_t gps_time =
>> usrp->get_mboard_sensor("gps_time");
>> uhd::time_spec_t gpsTime = uhd::time_spec_t(1.0)
>> +uhd::time_spec_t((double)gps_time.to_int());
>>
>> //set the gps time
>> usrp->set_time_next_pps(gpsTime);
>> boost::this_thread::sleep(boost::posix_time::seconds(1.5)); //wait for
>> pps sync pulse uhd::time_spec_t last_pps_time2 =
>> usrp->get_time_last_pps();
>>
>> boost::posix_time::ptime tpps(date(1970,1,1),
>> boost::posix_time::seconds(last_pps_time2.get_full_secs()));
>> std::string testLastPPS = to_simple_string(tpps); //THIS IS GOOD
>>
>> //setup streaming
>> uhd::stream_cmd_t stream_cmd((num_requested_samples == 0)?
>> uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS:
>> uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE
>> );
>> stream_cmd.num_samps = num_requested_samples;
>> stream_cmd.stream_now = true;
>> stream_cmd.time_spec = uhd::time_spec_t();
>>
>> usrp->issue_stream_cmd(stream_cmd);
>>
>> while(not stop_signal_called and (num_requested_samples !=
>> num_total_samps or num_requested_samples == 0)){
>> size_t num_rx_samps = rx_stream->recv(&buff.front(),
>> buff.size(), md, 3.0);
>> ...
>> //error checking
>> ...
>> num_total_samps += num_rx_samps;
>> outfile.write((const char*)&buff.front(),
>> num_rx_samps*sizeof(samp_type));
>> }
>>
>> boost::posix_time::ptime t0(date(1970,1,1),
>> boost::posix_time::seconds(md.time_spec.get_full_secs()));
>> std::string test0 = to_simple_string(t0); //THIS IS BAD
>
> OK I see what the test is doing.
> So, can you tell me, what is the value of:
>
> md.has_time_spec
> md.error_code
> md.time_spec.get_full_secs()
> md.time_spec.get_frac_secs()
>
> -josh
>
>>
>> //get pps time again to check
>> uhd::time_spec_t last_pps_time3 = usrp->get_time_last_pps();
>> boost::posix_time::ptime tpps3(date(1970,1,1),
>> boost::posix_time::seconds(last_pps_time3.get_full_secs()));
>> std::string testLastPPS3 = to_simple_string(tpps); //THIS IS GOOD
>>
>>
>> The Vita Frame timestamp just doesn't seem to be set to the internal time.
>>
>> Any ideas?
>>
>> Thanks,
>> A Bose
>>
>> -----Original Message-----
>> From: USRP-users [mailto:[email protected]] On Behalf
>> Of Josh Blum
>> Sent: Friday, February 01, 2013 11:24 AM
>> To: [email protected]
>> Subject: Re: [USRP-users] GPSO 1PSS
>>
>>
>>
>> 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_rec
>>> v _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()<<en
>>> d
>>> l;
>>> //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
>>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
------------------------------
Message: 8
Date: Fri, 1 Feb 2013 19:00:57 -0500
From: Nazmul Islam <[email protected]>
To: babar aziz <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] USRP-Tx
Message-ID:
<caftrfeysaekbbqqt7kogkg_8uexy65e4utrvx3auc__onvk...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
You can use gnuradio to do this. Download gnuradio. Open GRC and just use
the following transmit and receive flowgraphs:
File Source --> USRP Sink (Tx)
USRP Source --> File Sink (Rx)
You will have to use modulator, synchronizer, etc. to achieve your
objective. GRC is similar to Simulink and it should help you.
Thanks,
Nazmul
On Fri, Feb 1, 2013 at 6:23 PM, babar aziz <[email protected]> wrote:
> Hello everyone,
> I am new to USRP. I have some data(I&Q) in a .dat file and I want to
> transmit with USRP using simulink.
>
> Can any body give me hints/links/tutorials to do this.
> Thanking in advance
> ====================================
> Best Regards
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
Muhammad Nazmul Islam
Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130201/bd12ec33/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 01 Feb 2013 18:08:49 -0600
From: Josh Blum <[email protected]>
To: Damien Serant <[email protected]>
Cc: USRP List <[email protected]>
Subject: Re: [USRP-users] GPSO 1PSS
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 02/01/2013 04:02 PM, Damien Serant wrote:
> I confirm the issue with the query_gpsdo_sensors util that i built myself
> from the version in the git repo (master branch). I always get the error
> message "GPS and UHD Device time are NOT aligned". I found why and how
> correct that :
> Actually on my PC, last_pps_time.get_full_secs() and gps_time.to_int() have
> different values and the difference between the two integers is 1 while
> thier real values are very close. Perhaps a rounding issue. My work around
> is to use the following condition instead:
> if (abs(last_pps_time.get_real_secs() - gps_time.to_real())<DBL_EPSILON)
last_pps_time is only good if the USRP's time was previously sync'd to
PPS, and the clock reference was the GPS unit ("external"). Otherwise,
there could be drift.
>
> For the second issue I confirm also:
> I configure the stream command with a time t which is a full second (equal
> to get_last_pps() command +1)
> In the metadata of the fisrt received packet i get : t+eps, where eps is
> constant from a test to another, but change with the sampling frequency:
> about 5000 ns at 0.2 Mhz, 700 ns at 2 Mhz, 200 ns at 10 Mhz and 200 ns at
> 20 Mhz (however this is true that i obtained this value from the
> get_real_sec()...). You can test that with the rx_timed_samples example
> with some modification (no set_time_now() and augmentation of the number of
> decimals when printing the metadata time).
> This time offset is too important to be the filter group delay, no ?
The codec clock is a 10ns period. The 200 ns would be 20 samples at the
codec rate, and then you basically see this delay increasing as the
decimation rate increasing.
> So my question is: what is the right time of the samples : the time
> requested in the issue stream command or the time in the metadata of the
> first packet ?
The input to the DDC chain began at the time you requested. The
timestamp comes from the first sample out of the DDC chain. Thats just
how its implemented.
Hope that clarifies things :-)
-josh
------------------------------
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 2
*****************************************
