Timestamps on position proxies

[Doug McCorkle]

Hello,

When running on a cluster the timestamps on positional devices (like the head proxy) can be used for timing purposes. Is the ability to use the timestamps in a non-cluster use case or in a simulator still supposed to function? Thanks.

Doug

[Todd Furlong]

Doug,

I'm pretty sure simulated inputs should carry time stamps.

-Todd

[Doug McCorkle]

Hmmm. I am getting a Nan when I get the timestamp from a simulated head position proxy. Any ideas?

Doug

[Patrick Hartling]

The time stamp for a sample recored by an instance of gadget::SimPosition is set on line 197 of modules/gadgeteer/gadget/Devices/Sim/SimPosition.cpp. The sample time used comes from the keyboard/mouse proxy that supplies input to the simulated positional device. This should be the same for all simulated device types, but if you're only experiencing it with simulated positional devices, what I say below may have no relevance.

I don't think I fully realized this before, but the way that gadget::KeyboardMouseProxy gets its current time stamp is different from that of the other proxy types. If you look at the implementation of gadget::KeyboardMouseProxy::getTimeStamp(), you'll see that there is a "sync time" being requested from the referenced gadget::KeyboardMouseDevice. As best as I can tell from scanning the code, it appears that, for a non-cluster configuration, this sync time should be getting set every time gadget::KeyboardMouse::updateEventQueue() is called. That is invoked by gadget::KeyboardMouseDevice::updateData(), and that in turn should be getting called every time gadget::InputManager::updateAllDevices() is invoked.

There are a lot of pieces in play here, and I will need to do some more thorough digging in order to determine whether there is a bug. It would definitely help to know if this problem is limited to simulated positional devices.

-Patrick

--
Patrick L. Hartling
Senior Software Engineer, Priority 5
http://www.priority5.com/

[Doug McCorkle]

On Sun, Mar 11, 2012 at 3:04 PM, Patrick Hartling <patrick....@gmail.com> wrote:

The time stamp for a sample recored by an instance of gadget::SimPosition is set on line 197 of modules/gadgeteer/gadget/Devices/Sim/SimPosition.cpp. The sample time used comes from the keyboard/mouse proxy that supplies input to the simulated positional device. This should be the same for all simulated device types, but if you're only experiencing it with simulated positional devices, what I say below may have no relevance.

I don't think I fully realized this before, but the way that gadget::KeyboardMouseProxy gets its current time stamp is different from that of the other proxy types. If you look at the implementation of gadget::KeyboardMouseProxy::getTimeStamp(), you'll see that there is a "sync time" being requested from the referenced gadget::KeyboardMouseDevice. As best as I can tell from scanning the code, it appears that, for a non-cluster configuration, this sync time should be getting set every time gadget::KeyboardMouse::updateEventQueue() is called. That is invoked by gadget::KeyboardMouseDevice::updateData(), and that in turn should be getting called every time gadget::InputManager::updateAllDevices() is invoked.

There are a lot of pieces in play here, and I will need to do some more thorough digging in order to determine whether there is a bug. It would definitely help to know if this problem is limited to simulated positional devices.

So, I jumped the gun a bit. It appears that the data is coming back correct for positional and the keyboardmouse interface but is coming back in odd units.

If I compute the delta between timestamps I get a reasonable value that is always increasing and appears to be in seconds. The raw values appear to be in some odd form though.

 I get this printed to standard output: 1.33158e+09 even though I am asking for this:

vrjHead->getTimeStamp().secd()

I have used vpr::Interval before and I believe I always received a value that seemed reasonable for a time so I am not sure what it going on. Like I said the delta between two frames give an increasing number that appears to be the raw run time in seconds. Am I not using the timestamp correctly?

Doug

[Doug McCorkle]

Never mind. I got it figured out. Thanks for the help.

Doug