[USRP-users] GPSO Vita timestamp

Josh Blum josh at ettus.com
Mon Feb 11 14:07:00 EST 2013



On 02/11/2013 11:20 AM, A Bose wrote:
> I changed my project to "Release" and run your code and there are no
> problems.
> 

Thats a good data point. So, I just tried Debug mode, but the
application is still behaving as expected. I am having a hard time
replicating the issue :-(

> So why does the debug version fail under windows?  As though the
> info.ifpi.tsi memory gets clobbered ...
> 
> -A Bose
> 
> -----Original Message-----
> From: USRP-users [mailto:usrp-users-bounces at lists.ettus.com] On Behalf Of A
> Bose
> Sent: Friday, February 08, 2013 4:42 PM
> To: josh at ettus.com
> Cc: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] GPSO Vita timestamp
> 
> 
> Josh,
> 
> Seconds are still bad:
> http://imgshr.com/grxRX4
> 
> 
> 
> 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/revisi
>>>>>> o
>>>>>> 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
>>>>>
>>>>
>>>
>>
> 
> 
> _______________________________________________
> 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