[Top][All Lists]
[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