discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] inband pings and clock


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] inband pings and clock
Date: Sat, 4 Aug 2007 08:59:34 -0700
User-agent: Mutt/1.5.9i

On Fri, Aug 03, 2007 at 11:12:30AM -0400, George Nychis wrote:
> What is 'pingval' and what is its units?  I didn't think most pings had 
> a value, only empty responses for which you could compute whatever delay 
> value you please by calculating the time between.
> http://gnuradio.org/trac/browser/gnuradio/branches/developers/gnychis/inband/usrp/host/lib/inband/usrp_server.mbh#L105

The pingval is arbitrary.

> Second question.  For an application to properly timestamp outgoing 
> packets, the application needs some general idea of the current clock 
> value on the USRP.  At first I was thinking "oh well the app can just 
> send a ping and read the timestamp off of the response while calculating 
> the delay."  Well, the ping doesn't carry the clock back up to the 
> application.  RX packets (response-recv-raw-samples) carry the timestamp 
> back up to the application, but there is no notion of calculating delay 
> here.

The usrp_server should be passing the timestamp back to the
application.  It's in the header of the packet containing the ping
reply.  We should add the timestamp to the response-from-control-channel

> Is the clock stored in a readable register somewhere on the USRP that a 
> register read could be used?  The delay could be calculated here between 
> the request and response.  I checked our wiki but see no register:
> http://gnuradio.org/trac/wiki/UsrpFPGA

I think having the clock counter mapped to a register is a fine idea.
Note that the list of regs at http://gnuradio.org/trac/wiki/UsrpFPGA
is the existing list of regs, and hasn't been refactored to reflect
the requirements for inband signaling.  Also, I think it's a bad idea
to use the wiki for data where the ultimate source is the source code.
A link to the source would make more sense, otherwise the wiki is
pretty much guaranteed to be out-of-date.  (Basically we're violating
the "write it once" principle)

Eric




reply via email to

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