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
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.
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
Thanks!
On 8/3/07, George N. [email protected] wrote:
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 am not sure how the host side of things wants to handle sending
something out - so this is just complete speculation on my part.
What I thought would happen is that the RX side of things sends in
timestamps with the packets. During processing, if a correlation or
some special event occurs - the timestamp for that event can be
calculated (based on decimation rates, etc). Given that reference,
you can calculate a new timestamp based on whatever your MAC requires.
Do you think something like that would work?
Brian
On Fri, Aug 03, 2007 at 11:12:30AM -0400, George N. 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
Eric B. wrote:
On Fri, Aug 03, 2007 at 11:12:30AM -0400, George N. 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.
Check!
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
Right, this is where the current hole is. I will add a timestamp field
for the response-from-control-channel.
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)
Got ya, I’ll stick with the source code. We’ll work out mapping the
clock to a register.