Re: [Discuss-gnuradio] What time is it?

[Josh Blum]

There are new updates to the usrp2_vrt branch.

1) The sync at pps calls have been removed. They no longer apply and 
have been replaced with the set time calls (see below).

2) The mimo config call has been replaced with a clock config call that 
handles setting the pps source, pps polarity, ref source, (and other 
options).

3) Two calls were added to set the time: set_time and 
set_time_at_next_pps. A host pc hooked up to the serial port of a GPSDO 
could use set_time_at_next_pps to set the usrp2 with absolute time. 
Example mentioned in usrp2.h

4) That bug with the junk data i believe to be fixed. There was an 
improper way to stop the streaming.

5) There is an example app usrp2/apps/rx_timed_samples
This app will set the usrp2 time to the host system time with subsecond 
precision. Then it will call start streaming with a time in the future. 
The timestamps on the received packets are printed to verity working.

These changes require burning new fw and fpga images. I will post these 
if there is an interest. Otherwise, I will refrain from posting them as 
there are other kinks to work out in the codes.

-Josh


On 01/18/2010 04:11 PM, Mattias Kjellsson wrote:
> > > Glad you are trying out the branch. A few notes here:
> > >
> > > 1) There is a bug where after power-up, everytime (but the first) you
> > > restart streaming and get samples there is junk data, and it will read
> > > "bad vrt header". Its harmless, but should be fixed
> When you mention it, I do believe there was a discussion regarding the
> junk data when the usrp2 was first released. I have a vague memory of
> someone writing code to "get rid of this". But thats as far as my memory
> goes, and I actually don't know if there were any progress. Maybe it was
> more of a -"Yeah sure, I'll try to do that when I have some time to
> spare..."
> > > 3) The time registers are write only. There is no control packet to
> > > read-back time registers. That should be removed from the code.
> Okay, I see, but in that case what am I getting back from the USRP2
> then? I send a op_generic_t with op_code = 3, and get something that can
> be interpreted as a op_time_reply_t, with op_code = 83.
> > > 4) There needs to be a way to set the time on the next pps. This must
> > > be added, I am working on this now.... When done, you should be able
> > > to get the timestamp off of the serial port of a gps device and sync
> > > up the usrp2 to the correct seconds. Or use your own free-running
> > > seconds...
> I concur with the former writer, "Brilliant" =;oD
> > > 5) When you didnt get any samples back after setting time time: I cant
> > > tell if this is a bug or just a bad time. I will test this out
> I can send you the code I wrote if you would like to take a look at it.
> But if the first few (hundred) samples are junk, maybe the time- filed
> of those were corrupt as well. I could try to receive say 10k samples,
> take the time of the last one and then do something like:
>
> time_spec_t future_time
> future_time.integer_seconds = last_time_stamp.iteger_seconds+10;
> start_rx_streaming(0,&future_time);
>
> Is this the current (and possible future way) of starting rx at a future
> time instant?
> > >
> > Does this imply that timestamps are completely useless without a pps
> > signal ?
> >
> > 4) This sounds brilliant
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio