discuss-gnuradio
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]