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
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio