Hi to everyone. I’ve a strange problem on my Fez Spider II. I’m trying to use a mouse to measure movements.
When I move the mouse up and to the left, movements are recognized almost precisely (even if I move slowly the mouse).
When I move it in the opposite direction (down and right) movements are recognized only if the mouse is moved fastly and result is unpredictable so not precise.
I tried with 3 different mouse and all of them present this strange behavior.
Here there’s my simple code:
GHI.USB is the GHI proprietary code, so no source.
The problem is that you are trying to print in a routine that runs a LOT when the mouse moves. Why does it appear to work better in one way than another, I have no idea, but trying to do debug.prints in that kind of handler doesn’t make a lot of sense I’m afraid. What are you trying to control with the mouse, can you simply hook that up, and does your code without debug.print work better or still show this direction priority?
Thanks for your answer.
I removed mouse_CursorMoved callback and, in order to test it, I’ve added a Timer that every second print the mouse.CursorPosition property.
Problem stil persist, if I move the mouse bottom and/or to the right slowly no movement is recognized. In the other directions even the small movement is caught.
What I need to do is a simple device that monitor wall crack distance, so I wanted to do it using a mouse but I need that it works on an entire direction and not only half.
Any suggestion? Can someone do same test and check if it’s a common problem?
Do the delta’s appear correct? Just theorizing… if the delta’s are correct but the new position is incorrect it would seem maybe the math involved in subtracting values is dropping data (rounding?) while the other direction is remaining precise.
If you can see raw (or something closer to raw) data that appears correct maybe you can implement the last part on your own.
Delta values have the same problem. I switched to another solution. Instead using GHI.Usb.Host.Mouse class,
I’m trying to read data from a mouse using directly RawDevice, and after studying few things about HID, I was able to read correctly data about X and Y movements with very high precision in all directions.
But sometimes when I read from Pipe I get a strange exception raised by NativeTransfer:
As described in another thread, I had to use Reflection to invoke NativeTransfer because RawDevice.Pipe.Transfer() blocks the execution without considering TransferTimeout argument.
The problem in this case is that sometime the exception is raised just one time and after execution restart correctly, other time it starts raising a lot of exception in a row (like a loop) and I need to move the mouse to stop it. What can be the problem?
Here is my check event function:
protected override void CheckEvents(object sender)
{
if (base.CheckObjectState(false))
{
int bytesReceived = 0;
try
{
bytesReceived = (int)transferMethod.Invoke(inputPipe, new object[] { inputData, 0, inputData.Length, 100 });
}
catch (Exception)
{
Debug.Print("WARNING: First Level Exception!");
}
if (bytesReceived == 7)
{
X += BitConverter.ToInt16(inputData, 1);
Y += BitConverter.ToInt16(inputData, 3);
}
}
}
inputData is an array of 8 byte (MaximumPacketSize of the Endpoint), mouse gives me back a 7 byte report in the interruptPipe. I tried to change timing (modifying WorkerInterval and TransferTimeout) but the problem persists.