High Speed Laser Optical Sensor (Avago ADNS-9800) [$28 shipped - DONE]

[damorgue]

But how do I ensure that it is located exactly in front of the sensor? There are many possible solutions to not make it removable as you say, but isn't the position of it crucial?

I haven't measured how much it moves but I would estimate that it is a good 0.3mm in the x-y plane The image output ought to become very distorted if the lens is placed off center. The low precision of this assembly concerns me a great deal.

[MrJohnK]

The lens and the sensor IC were designed to work together within these tolerances, originally by Avago.  Agreed, there is a little bit of play, however, I've never been able to detect any issues as a result in the few years I've been using this form factor (I originally started with the ADNS-9500).  The "stake" process is described in the datasheet as an acceptable way to attach the lens to the sensor IC. While that doesn't directly answer your question, I believe the small amount of wiggle room is within acceptable tolerance as it was designed to work this way as a matched set from the manufacturer.

-John

[damorgue]

I don't understand how that can be the case. The importance of the distance from lens to tracking surface has been stated several times, and that distance is longer than that between the lens and the sensor. If you have a tolerance of the placement of the lens relative the tracking surface the tolerance needs to be tighter for the placement of the lens relative the sensor since it is a shorter distance and simple optical laws apply. The lens has to follow the laws of physics. This either means that the tolerance for the lens to tracking surface is heavily exaggerated or the tolerance of the lens to sensor is is tighter than indicated.

[The_Ed]

Liftoff distance is a setting. So if you are placing it farther from the surface you will have to increase that setting, conversely if you are placing it closer to the surface you will have to decrease that setting.

[The_Ed]

Small update time again:

I think it is most logical to define 4 scroll wheels (standard 1-byte and smooth 2-byte), with the 2 smooth scrolling wheels in my third custom endpoint that also contains the system and consumer controls. Some applications may not support smooth scrolling, thus it wouldn't make sense to make only 2 smooth scrolling wheels.

I am also contemplating defining 2 sets of X/Y axes (1-byte and 2-byte) so as to try to make it work in the BIOS (I believe this is for UEFI support). I would then put those secondary scroll wheels and X/Y axes in a fourth custom endpoint, leaving just the system and consumer controls in the third. I think this might be better in the long run as then I wouldn't have to change anything in the future if I get a motherboard with UEFI.

But of course these duplicates will increase the amount of commented out code I'll have to include... I think I'll only test the parts I'll be using in my trackball mod before passing it on to a few other people for a more thorough testing in their own projects.

Each endpoint has a single function to send data, which is much more efficient. I still don't understand why the stock code breaks them up.

I wonder how many times I've revised the code by now... Hopefully I don't mix up the versions of the pieces...

[dorkvader]

I wonder how many times I've revised the code by now... Hopefully I don't mix up the versions of the pieces...

are you using some sort of version control like mercurial?

[The_Ed]

I wonder how many times I've revised the code by now... Hopefully I don't mix up the versions of the pieces...

are you using some sort of version control like mercurial?

Nope, and I've never heard of mercurial... It's just folders...

I'll try to hammer out some more code near the end of the week after I get some orders and keyboard mods out.

[MrJohnK]

Ed,
I'm just curious, have you been able to hook the sensor up to your Teensy 3.0 at least get some basic SPI hardware communication established and movement data sent?  I've not tried it on a Teensy 3.0, so just wanted to hear it it works as expected.

-John

[The_Ed]

My breakthrough on endpoints was only on the 17th, and my quarter just ended so it's break week this week. Which means I *may* get 1.0 alpha completely written, but won't have time to test it until later. Most of my time spent on this has been research (mostly on endpoints...), and making changes to code. It's just a matter of time, it'll get done eventually. Also with each change I make I have to cascade changes to other parts, which is why I am a little concerned with confusing the versions. I really hope that the first tests go without a hitch, but I know there will be something wrong. No code is perfect on the first try, there's always some simple mistakes that are bastards to track down.

I still remember writing c++ in the campus library a few years ago. Taping and stapling pieces of paper together with lines between them for the flow of the voids. Good times.

[The_Ed]

I guess it's a good thing when I find bugs in the stock teensy code, but you'd think they would all be fixed by now... Oh well, as long as I find and fix all the ones that affect me it'll be good enough. It's also probably not a good thing that one computer has teensyduino 1.15 and the other has 1.16. It still amazes me with how much code and documentation I have gone through, and how much I've had to figure out and understand to do these custom things with a teensy. I'm probably not gonna finish the code before school starts again next week... Oh well, I've been doing other things and I shouldn't stress myself out during break week.

[damorgue]

Has the compatibility from the older version been heavily broken? The reason why I am asking is to ask if I could get one of the earlier firmwares to look through. If nothing else, which pins as you planning on using for what on the teensy? I am currently planning placement and electrical connections which have to be made between the parts atm. Something like Pin 1 and 2 for switch A and B, and which pins will communicate with the sensor would be quite useful for now.

[The_Ed]

Pins are mapped by the user in a section near the top, but there are only 2 pin options for things like SCK, MOSI, and MISO. Pretty much anything else can use any of the digital pins.

One of these days I'll have some time time to test the code on the hardware, but today I did some car stuff which is more important than code.