[USRP-users] GPSO Vita timestamp

A Bose abose at crc.gc.ca
Mon Feb 4 13:44:20 EST 2013


For the record I am running 32-bit windows xp, with UHD 3_4_3 Release and
using Visual Studio 10.

Awaiting your test results,

Thanks,
A Bose

On 02/04/2013 11:40 AM, A Bose wrote:
>> 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);
> 

The packets used to have integer seconds and fractional ticks. They now just
have 64 bits of tick counts for absolute time -- which is much easier to
deal with. So, anyway, thats the reason for the change.

> 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?
> 

Its possible that there is an issue when time_t is 64 bits, which might be
only on the x64 window binary. I am trying to replicate this.

For the curious, the conversion from 64 bit tick count to fractional and
full seconds happens here:

http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master
/entry/host/lib/types/time_spec.cpp#L71

http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master
/entry/host/lib/types/time_spec.cpp#L103

I am placing my suspicions either on the imaxdiv function, or the
time_spec_init macro

-josh

-josh

> 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/revisio
>>>> n
>>>> s
>>>> /
>>>> fac15d
>>>> b5d77c5196badb4a06f2f5fec34eb57337/entry/host/lib/transport/super_r
>>>> e 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