[USRP-users] GPSO Vita timestamp

Josh Blum josh at ettus.com
Fri Feb 8 14:30:58 EST 2013



On 02/04/2013 12:44 PM, A Bose wrote:
> 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

Well, I changed this example to lock to gps time and stream at gps time
+ some delta: http://pastebin.com/TKm6dm1B

This was the output (which looks ok):
http://pastebin.com/f9nkZPBe

I am curious how it works for you

-josh

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