[USRP-users] GPSO 1PSS

Josh Blum josh at ettus.com
Fri Feb 1 11:23:50 EST 2013



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/revisions/fac15d
> b5d77c5196badb4a06f2f5fec34eb57337/entry/host/lib/transport/super_recv_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()<<endl;
> //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
> 




More information about the USRP-users mailing list