[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] What time is it?
From: |
Mattias Kjellsson |
Subject: |
Re: [Discuss-gnuradio] What time is it? |
Date: |
Tue, 19 Jan 2010 01:11:36 +0100 |
User-agent: |
Thunderbird 2.0.0.23 (X11/20090817) |
>> 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