[USRP-users] GPSO 1PSS

Damien Serant damien.serant at gmail.com
Fri Feb 1 17:02:12 EST 2013


I confirm the issue with the query_gpsdo_sensors util that i built myself
from the version in the git repo (master branch). I always get the error
message "GPS and UHD Device time are NOT aligned". I found why and how
correct that :
Actually on my PC, last_pps_time.get_full_secs() and gps_time.to_int() have
different values and the difference between the two integers is 1 while
thier real values are very close. Perhaps a rounding issue. My work around
is to use the following condition instead:
if (abs(last_pps_time.get_real_secs() - gps_time.to_real())<DBL_EPSILON)

For the second issue I confirm also:
I configure the stream command with a time t which is a full second (equal
to get_last_pps() command +1)
In the metadata of the fisrt received packet i get : t+eps, where eps is
constant from a test to another, but change with the sampling frequency:
about 5000 ns at 0.2 Mhz, 700 ns at 2 Mhz, 200 ns at 10 Mhz and 200 ns at
20 Mhz (however this is true that i obtained this value from the
get_real_sec()...). You can test that with the rx_timed_samples example
with some modification (no set_time_now() and augmentation of the number of
decimals when printing the metadata time).
This time offset is too important to be the filter group delay, no ?
So my question is: what is the right time of the samples : the time
requested in the issue stream command or the time in the metadata of the
first packet ?

Thanks in advance
Damien


2013/2/1 Josh Blum <josh at ettus.com>

>
>
> On 01/31/2013 07:31 PM, Damien Serant wrote:
> > 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;
>
> FYI, its possible that you could get a late command if
>
> 1) if get_time_last_pps()+1 is actually on the hairy edge of the
> beginning of a new pps and the command ended up getting into the device
> right after the pps
>
> or 2) there wasnt a pps to continually update this value
>
> > 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...
> >
> >
>
> The real seconds is a double field in units of seconds, but its not
> actually enough precision to represent the time in seconds. Thats why
> there is an integer full seconds and a fractional only seconds.
>
> You may noticed that the get_time_last_pps()+1 was not exactly the time
> requested. This is because the DSP units were run exactly at that time,
> but the samples were timestampped after the filter group delay.
>
> -josh
>
> > 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 listUSRP-users at lists.ettus.comhttp://
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130201/7e895a7a/attachment-0002.html>


More information about the USRP-users mailing list