[USRP-users] GPSO Vita timestamp

A Bose abose at crc.gc.ca
Mon Feb 11 12:20:48 EST 2013


I changed my project to "Release" and run your code and there are no
problems.

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