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

[Josh Blum]

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

2) FYI The second parameter to start_rx_streaming, if left out, means 
stream asap.

3) The time registers are write only. There is no control packet to 
read-back time registers. That should be removed from the code.

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...

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

-Josh

On 01/18/2010 08:18 AM, Mattias Kjellsson wrote:
> I was exited to see the vrt progress. I have compiled Josh's usrp2_vrt-
> branch, installed the required firmware/fpga- image in the sd- card, and
> can find the usrp2. Everything working so far.
>
> But now comes the question, is there a way to read the current usrp2-
> time, so that I can do something like "start_rx_streaming(0,
> &future_time)".
> I basically try to figure out what the time in the usrp2 is, and then
> add a number of seconds/ticks/whatever to that, in order to start
> receiving at some future instant.
>
> To do this, I have tried two ways
> First I tried to use two instances of a 16sc handler, one which just
> read one sample (writing it to /dev/null), from which I extracted the
> time, and then stopped the streaming.
> Then I add a number of seconds/ticks to the time I got from the usrp2,
> and start streaming again with that incremented time as the second
> parameter to "start_rx_streaming(..,..)", and try to receive samples
> using the second handler (which was actually writing to a file).
>
> This results in two things,
> 1) During reception with the first handler, a message about bad VRT-
> header is displayed, which I tracked back to usrp2_impl.cc, but not
> further than that, since I can't really figure out under which
> conditions the message is displayed.
> 2) During reception with the second handler, no samples are received. I
> thought that it might have something to do with seconds being to long,
> or a tick being to short, so I tried adding different values but that
> didn't seem to change much, since the out- file was still 0 bytes.
>
> In the second approach:
> I noticed that there is a #define OP_READ_TIME 3, but after some
> grepping I only found it in usrp2_eth_packet.h (where it was defined)
> and in "usrp2_impl.cc, std::string opcode_to_string(int opcode)". What
> are the plans of this op- code, a "what time is it on my usrp2 right
> now"- function?
>
> If that is the case, and it has not been written yet, I did some
> rewriting of usrp2.cc, usrp2_impl.cc, usrp2.h and usrp2_impl.h for that
> functionality (give me current time on the usrp2), using the already
> existing struct op_read_time_reply_t. But this raises another question,
> namely: What is "op_read_time_reply_t.time" actually describing? It is a
> uint32_t, but the vrt_header seems to use a uint32_t for integer
> seconds, and a uint64_t for fractional seconds, while the time_spec_t
> structure seems to use two uint32_t for ticks and seconds, and another
> structure for something I'm not sure about... I guess the question is,
> do I parse the 32 bit integer to a time_spec_t? And if so how?
>
> I think I lost my self somewhere. However would I be very happy if
> someone could straighten my questions out.
>
> Best regards
> Mattias Kjellsson
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio