[USRP-users] GPSO Vita timestamp

A Bose abose at crc.gc.ca
Mon Feb 4 12:40:14 EST 2013


> Does your system have a 32 bit or 64 bit time_t?
I cannot compile with #define _USE_32BIT_TIME_T so I think I have 64 time_t.

I verified the wireshark packets and the vita time map correctly into
info.ifpi.tsf and info.ifpi.tsi in get_and_process_single_packet function of
super_recv_packet_handler.cpp

The next call populates info.time via a translation function, and I think
this could be my problem.

In the same function should the following line be:
info.time = time_spec_t::from_ticks(info.ifpi.tsf, _tick_rate); 
-OR-
info.time = time_spec_t(time_t(info.ifpi.tsi), size_t(info.ifpi.tsf),
_tick_rate);

I have seen both in the file history, and I am not sure if they are the
same.

Is this a Windows issue, because I am sure this timestamp is working on your
end?

Thanks,
A Bose

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:josh at joshknows.com] On Behalf Of Josh Blum
> Sent: Friday, February 01, 2013 3:55 PM
> To: A Bose
> Cc: usrp-users at lists.ettus.com
> 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:usrp-users-bounces at lists.ettus.com] On 
>> Behalf Of Josh Blum
>> Sent: Friday, February 01, 2013 11:24 AM
>> To: usrp-users at lists.ettus.com
>> 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/revision
>>> s
>>> /
>>> fac15d
>>> b5d77c5196badb4a06f2f5fec34eb57337/entry/host/lib/transport/super_re
>>> c 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:usrp-users-bounces at lists.ettus.com] 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()<<e
>>> n
>>> 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 <nick at ettus.com>
>>>
>>> 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
>>> USRP-users at lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>  
>>>
>>>  
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users at lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
> 





More information about the USRP-users mailing list