Rodent Mark II

[damorgue]

Rodent MK II
Edit: It is a mouse, which I realized I never actually mentioned anywhere below in case it isn't obvious.

I have decided to make an improvement of an old project I made. There were some issues which I have always intended to correct, and with some neat avago sensors available now I might get some help making the internals as well. I will try to piggy back a bit onThe_Ed's project and just use his internals, saving me a bunch of work in a field I ain't very good at. Last time I butchered a G300, but the ability to control the software, liftoff distance, angle snapping, acceleration and such intrigues me.

Process so far: (crash course)
Create a clay model (actually just dough, nothing fancy here) which fits your taste.
Melt vinyl record on top to create a shell > Didn't turn out that great, although it would probably eventually have worked decently but required a lot of effort to get there. Internal structure is a pain with that method.
Remake another clay model because the old one got ruined by previous attempts.
Make a 3D scan of the clay model.
Retopology, adjust shape, add and correct some features etc.
Add structural elements.
Print the computer model.
Butcher an old mouse for internal parts and transplant them into my mouse.
Live with the flaws because you don't bother fixing them, for instance non working scroll wheel.

Thus begins the process of creating a better one, starting out with one of the scans again. Mesh



Things left to do:


-Better mounting for the Omron switches than last time, allow them to be securely fastened while easier replaced (Note to self: remember to use longer cables this time to make assembly easier)
-Move some mouse buttons a bit.
-Fix the scroll wheel which was sort of bugged and never really worked well. This is probably the most annoying and hardest part atm.
Plan better locations for the feet. Should they be on the bottom surface of the shell or on the plate? located on the plate would ensure strength and stability, but that can be accomplished by increased shell thickness at the bottom as well. It is preferable to place them as far out towards the edges as possible. The more bottom surface belonging to the shell, the smaller the hole to assemble/repair though. The sensor to measuring surface distance is what needs to be controlled.
-Smooth out a few dents still present from the clay model. They can be sanded down but might as well fix it now.
-The software/teensy/avago stuff which I hope I won't have to do that much of.
-Make a better name, Rodent was just a prototype name.
-Solder cables and connectors

[damorgue]

Reserved

[damorgue]

I made a far better inner surface this time. The shell is of even thickness on pretty much the entire surface except for at the bottom where it is thicker to meet up with the slot for the bottom plate better. It is also thicker, 2mm now, to account for weaker material. Supports will be added to certain points for structural rigidity as well though. I want to keep the amount of material, cost and weight down. It is somewhat hard to show with a complex organic surface though.  I made it a bit like an x-ray where you can see the inner surface through the opaque shell.






Perhaps this shows it better:

[digi]

That is really cool, get a couple thumb buttons on that bad boy. I can see it now, 250 hand molds getting sent to your house for a group buy, haha.

[Thimplum]

Very intriguing.

[damorgue]

That is really cool, get a couple thumb buttons on that bad boy. I can see it now, 250 hand molds getting sent to your house for a group buy, haha.

Hehe, nope, not likely. Hopefully someone else might be inspired to try and make their own though.

Regarding the buttons. I have placed them on the inside, currently doing a better mounting system for them as well as better buttons and mounting for the moveable plastic part. I will use ribs to make the right and left mouse button bend in the direction I want and behave as I want them to. They will be quite stiff rotation wise so that they won't warp as much if pressed off center.

I have yet to decide how many I want. I have use insides of a G300 in the past because it has a ton of buttons which I can wire siwtches to. Looking at 2 thumb buttons, left, scroll, extra in the middle beneath scrolland right. Then perhaps I will add to the other two fingers. they are a bit excessive though.

[linziyi]

That is quite amazing sir!

[vun]

I'm just wondering why this isn't a bigger thing already. You can get IEMs moulded to your ears, so I don't see why something like you're doing isn't common practice already. Everyone needs their e-mail and their apps and stuff, but there's a frighteningly small amount of attention paid to the equipment that makes creating all that possible in the first place.

[damorgue]

I'm just wondering why this isn't a bigger thing already. You can get IEMs moulded to your ears, so I don't see why something like you're doing isn't common practice already. Everyone needs their e-mail and their apps and stuff, but there's a frighteningly small amount of attention paid to the equipment that makes creating all that possible in the first place.

Exactly. The only mouse I know of (Mad Catz R.A.T 7) which you can customize the shape of, only allows very little change and it looks weird and unergonomic. It is also made by a company I sort of believe make bad products.

[vun]

I'm just wondering why this isn't a bigger thing already. You can get IEMs moulded to your ears, so I don't see why something like you're doing isn't common practice already. Everyone needs their e-mail and their apps and stuff, but there's a frighteningly small amount of attention paid to the equipment that makes creating all that possible in the first place.

Exactly. The only mouse I know of (Mad Catz R.A.T 7) which you can customize the shape of, only allows very little change and it looks weird and unergonomic. It is also made by a company I sort of believe make bad products.

I actually just used my RAT 7 for about a week, switched it out today, and to be fair I don't really know if I'd say they make bad products. Gimmicky, yes, but I find it hard to believe that something so well-built(apart from choice of sensor) and crazy is made by someone who doesn't care. But yeah, the change offered is minimal, although it's far from "unergonomic", it's actually one of the more comfortable mice I have.

Razer also have the Ouroboros which is pretty much their competitor to the RAT mice, although the Ouroboros is ambidextrous. I haven't had a chance to try one yet, so I can't say much more about it.

[mkawa]

actually after some exchanges with folks about the avago optical controllers, i'm like really annoyed about the non-openness of mouse sensors. imo the opticals should just output a several different mildly processed versions of their sensor output raw through a sufficiently wide gpio-based bus that any one of the millions of arm mcus out there can interpret. the lasers should output their raw signals as well in a standard format (duals just use the second to reduce error components on the same signal the singles use). the mcu code should be open and a chip should be produceable by anyone with an arm license. this would give us better mice for cheaper, frankly. the real challenge in making mice should just be the tooling for the plastic/composite/whatever body, the choice and configuration of switches, etc. this idea that there's a logitech specialized mouse driver with stupid flags to turn all the bad features off and a CM storm mouse utility that is accompanied by 1500 different firmwares for the avago MCU and a madcatz etc. etc. etc. etc. etc. etc.

just ONE of the benefits of this type of open development would mean more sensor vendors. at the moment there is pretty much just avago and philips. that is completely ridiculous. opticals are just a sensor, collimator and an LED. lasers are a collimated LED and a sensor with substantially different optics. the point is that any company that literally any company that can get optics and housings produced should be capable of marketing a better mouse sensor design. the lack of a standard MCU is the only thing preventing new mouse sensor products.

GRUMBLE

[damorgue]

I too am a proponent of open source software and open source hardware as well. I also strongly believe in users developing products. Companies are further from the usage, source of problems and the situations where the innovative ideas are created. The users are naturally closer, and although the companies try to get in touch and involve them, finding the critical power user is hard. Open source and user development will grow in the future with increased capabilities of users to make their ideas into reality. Kickstarter for financing is just an example a of tools which have risen to fulfill a need.

Standards have their drawbacks though. They certainly makes things easier, which in turn can allows more people to contribute and increase diversity, but there are cases where they have limited progress and caused less diversity because people have been constrained to them. It is sort of a double edged sword.

I will try to look into what internals I will use. Butchering a commercially available mouse like last time means closed source, less control, less support, probably harder to find replacement parts after a while etc.

It seems I have plenty of places to get it printed though. mkawa might do it on his Makerbot, a guy near me has offered me to print it on his Mendel90 and I have a few other options as well. I seem blessed in that regard. This link showcases the results of a technique to smooth out abs with acetone. I will probably try it out.

Edit: In the spirit of open source: I'll hand it out to any who want to print one themselves. Of course, it is sort of designed the way I like it and will probably not suit others very well.

[mkawa]

people have been doing abs smoothing by just vaporizing acetone underneath their objects until it seems smooth enough. not only is this incredibly nasty, but it doesn't give a lot of control over the amount of acetone exposure. stratasys has a smoothing machine based on this mechanism which is kind of ridiculous. basically it produces acetone vapor in a chamber, then releases it and vents it in fixed increments. the entire thing is stainless steel so you can't see the object during smoothing and hence it just smoothes a tiny bit at a time and you're supposed to hand cycle it through the machine until desired smoothness is achieve. kind of silly. ANYWAY

i picked up some parts for a very diy but slightly enlightened design based on the whole acetone vapor principles. basically, two chambers. one is a heated acetone vaporizer that produces vapor at a given pressure (although i haven't even sprung for a pressure reg or dial yet (ho ho ho), and glass vacuum chamber connected to it via check valve and I/O valve. open the valve to start smoothing process, then vent to atmo (OUTSIDE) when object is sufficiently smooth which AS IF BY MAGIC you can see through the 10$ glass bottle. the vapor chamber is currently PMP and the object chamber is just ye ole glass bottle with a wire-based pressure top and a PTFE gasket.

[damorgue]

Yeah, I was going to do a ghetto attempt at it. This guy's results were a bit so so imo. Some people achieve better results, but also use quite simple means. I will experiment a bit with it. The local guy uses nylon atm but will try abs. It all seems to mostly boil:P down to exposure time and acetone concentration. If all else fails, fine grit sand paper. Some people have gotten interesting results by flash heating. It needs to be very hot and very short exposure though, otherwise the entire thing deforms.

Edit: I will also try to mask out areas from the vapor. I most just need it on the outside surface and just barely into the split lines.

[mkawa]

going by the chemistry I understand (which is not a lot), acetone vapor (ideally cooled) depolymerizes the surface at a fixed depth that is a function purely of vapor concentration, pressure and time (assuming you release the vapor into a vacuum). at first order i just have some cheap little pinch-style pressure regulators and a source of vacuum that will allow me to figure out approximately what that function is.

we know approximately the depth of the striations. they are at most 0.4mm on most machines, as that is the standard nozzle output diameter. hence we only want penetration between 0 and 0.4mm, so we just need simple recipes for penetration to those depths. note that the vapor pressure that matters is actually the vapor pressure in the smoothing chamber, NOT the vapor generation chamber, so some amount of calculation needs to be done when generating the vapor. this is why i am just playing around with it by sight at a first order.

that said, FFM is about making things that are usable and mostly represent the solid attempting to be represented, so this whole thing is a second order concern to just extending the precision and capabilities of the machine itself.

[damorgue]

The easiest way to adjust the strength of the switches would probably be something like this:


The upper block is attached to the mouse and the lower is screwed to it. The bump at the far end would be where the button portrudes through a hole in the shell.

This would allow me to select where to fixate the button and a shorter distance from point of attachment to the button of course means a stiffer button and vice versa.

I could have the button be attached directly to the shell and built in one piece, but this also allows me to change the buttons in the future if they break. I can also put a small strip of sheet metal there to act as the deforming part if I feel like it and only have a button at the the end of it.

Currently estimating the forces and elastic deformation of ABS to get a rough idea of what length and thickness I need without it breaking.

[mkawa]

you can't base it on the material properties of the base polymer because FFM parts have such variable and lower density than eg injection molded ABS. further, ABS formulations are all subtly different. it's not surprising to get glass transition temp differentials of > 20C between one color of one vendor and another color of even the same vendor, much less a different vendor.

[damorgue]

you can't base it on the material properties of the base polymer because FFM parts have such variable and lower density than eg injection molded ABS. further, ABS formulations are all subtly different. it's not surprising to get glass transition temp differentials of > 20C between one color of one vendor and another color of even the same vendor, much less a different vendor.

Understandable, but the current size was made to suit titanium, so it would have been a bit off I figure I will get closer simply with taking any generic average polymer properties. As long as I am far from plastic deformation, I'll be able to adjust the stiffness with the different holes. Better to make bending part thick and compensate by making it long rather than a short and thin. This should avoid stress fatigue anywhere.

My mx500 uses a piece of sheet metal which acts as the bending part. I do think that would be a better solution. I'll probably end up there in the end.

[MOZ]

I'm just wondering why this isn't a bigger thing already. You can get IEMs moulded to your ears, so I don't see why something like you're doing isn't common practice already. Everyone needs their e-mail and their apps and stuff, but there's a frighteningly small amount of attention paid to the equipment that makes creating all that possible in the first place.

Agreed, I would get a custom mouse shaped to me liking in a blink. The closest thing is the RAT 7 and only reason I got it.

[The_Ed]

Would you be able to 3D print a part to mount the ADNS-9800 to the ball socket of the Microsoft Trackball Opticals I'm modding? Otherwise I'm currently stumped on how to mount them... Hopefully by the time you have your mouse case figured out my 1.0 code will be finished so that you can get started on the "Rodent Mark II" proper.

[damorgue]

Do you have a drawing for it or not? Someone here should be able to print it for you. I could probably help you design it if you don't already have a model for it but it might be a bit difficult without the actual mouse and chip. Do you have pics?


I will mount all my Omron switches to the shell, and collect the wires from them to a connector. This is one of the good things about my mouse, that it will work with pretty much anything which fits inside. The sensor, controller and such will be mounted to the bottom plate. I collect the wires which will lead to the switches into a connector and attach it to to the socket in the shell, then screw the bottom plate to the shell and it is done. The two are essentially independent though. Although a bit excessive, I could even have a few bottom plates with different sensors and controllers and easily switch them.

I have yet to decide if I should mount the scroll to the shell or the bottom plate.

[The_Ed]

I have absolutely no idea how to make 3D models...

My Dad is a photography guy, he can take any pictures with measurements you would need. I'll try to get on that this weekend.

[damorgue]

I don't think I ever posted vinyl testing. This post should summarize that, as well as some info for the ones interested in casting things. First the tests I mentioned earlier shaping it as a thin surface over my clay model:

This one was heated too much and started boiling a bit on the surface. The inside is smooth though:

One of the better:

I did quite a few:


I also did test casting it. A lot of people seem interested inc asting lately, so here are a few. I just did them for testing, so the molds were just aluminum foil which I shaped into concave surfaces, put some pieces of vinyl in and heated until the vinyl melted. As stated, the vinyl used in old records is fully dense, does not shrink, and is an excellent thermoplastic to use for this.

Here you can see underneath them. Notice that they took the small detailed shapes of the aluminum foil very well.

Here are the top of them, which shows how they flow out and become very shiny. The one to the right has been sandblasted to make it matte.

[Bullveyr]

I'm just wondering why this isn't a bigger thing already. You can get IEMs moulded to your ears, so I don't see why something like you're doing isn't common practice already.

Price

Especially considering that a mouse body also has some function (unlike IEM molds) which would make custom molds much more expensive if they want to compete with the quality of current higher end mice.
 

actually after some exchanges with folks about the avago optical controllers, i'm like really annoyed about the non-openness of mouse sensors. imo the opticals should just output a several different mildly processed versions of their sensor output raw through a sufficiently wide gpio-based bus that any one of the millions of arm mcus out there can interpret. the lasers should output their raw signals as well in a standard format (duals just use the second to reduce error components on the same signal the singles use). the mcu code should be open and a chip should be produceable by anyone with an arm license. this would give us better mice for cheaper, frankly. the real challenge in making mice should just be the tooling for the plastic/composite/whatever body, the choice and configuration of switches, etc. this idea that there's a logitech specialized mouse driver with stupid flags to turn all the bad features off and a CM storm mouse utility that is accompanied by 1500 different firmwares for the avago MCU and a madcatz etc. etc. etc. etc. etc. etc.

just ONE of the benefits of this type of open development would mean more sensor vendors. at the moment there is pretty much just avago and philips. that is completely ridiculous. opticals are just a sensor, collimator and an LED. lasers are a collimated LED and a sensor with substantially different optics. the point is that any company that literally any company that can get optics and housings produced should be capable of marketing a better mouse sensor design. the lack of a standard MCU is the only thing preventing new mouse sensor products.

GRUMBLE

Just to make sure I understand you correct.

You would like the sensor to output more raw movement data (less smoothing/corrections by the DSP, no advanced functions like angle snapping or LOD settings) and give the MCU more to do?
So basically shifting some of the processing from the sensors internal DSP to the MCU?

The real problem in the current sensor market is that there is a quasi monopoly.
Avago made a cross licensing deal with PixArt and left the sensor market.
I would love more competition for PixArt than only from Philips but I don't see that happening.
I would also love that they would stop squeezing out more CPI of the same old hardware and concentrate on improving other aspects of a sensor.

Obviously they would like to have that but I don't see how better and more different sensor would change much for the mouse manufacturers. A proper (MCU) firmware to get the most out of a given sensor is very important but the real challenge already is mouse body/switches/wheel/features design.

PS: Funny thing that I had "meeting" with 2 mouse designers when you posted that.

[damorgue]

You would like the sensor to output more raw movement data (less smoothing/corrections by the DSP, no advanced functions like angle snapping or LOD settings) and give the MCU more to do?
So basically shifting some of the processing from the sensors internal DSP to the MCU?

I think the idea is to have less DSP all together. Some anti-jitter and treatment is of course still necessary because as you say, they may have pushed the boundaries a little to far for a given hardware, but I find a lot of the treatments applied to be unnecessary and annoying. Angle snapping, prediction and acceleration are things I generally dislike. It might be because they are sometimes implemented to strongly and I just don't know the difference between the ones who have implemented it with less strength or nor at at all. There might be a setting there which is ideal.

The_Ed seems to be putting some sort of control on LOD at least in his firmware, and if I understand it correctly it will have no angle snapping or such. Ideally, I would like to experiment with how much angle snapping, prediction and acceleration I want. I am open minded and will consider the possibility that I actually still want a little of them, although perhaps not a cubic acceleration but a much lower for example. We'll see if I get to play around a bit with the code at a later date.

[The_Ed]

Angle snapping will be disabled by default, but you can enable it by changing the hexadecimal characters.

[damorgue]

Angle snapping will be disabled by default, but you can enable it by changing the hexadecimal characters.

I will check through your code later. I assume there is an if statement somewhere checking whether the movement is close enough to X or Y axis to snap it to them. I might play around with the "required angle for snapping" or however it is defined. It could be snapped only when very VERY close to either axis for instance. These are some things I intend to play around with. I will probably run with it completely off, but I am not going to decide until I have tried it.

[The_Ed]

It's either ±5 degrees of angle snapping or no angle snapping at all. You can't define the angle, it's just on or off.

[damorgue]

Ok. I guess the only way to try it then would be to have it turned off and treat the data in the teensy? Ouch

 Well, I was leaning towards not using it anyway I suppose.

[The_Ed]

Yes, both having a custom angle_snap angle and having the sensor at an angle would have to be implemented within the teensy. But remember that the calculations would also likely introduce rounding errors, cursor lag (NOT calculation lag), and erratic movement (ESPECIALLY when changing direction or moving slowly).

[damorgue]

I only thought there was a difference in the longevity of different brands of micro switches, and not as much difference in feel and sound. Apparently there is, so I will try a few. The ones I happen to have a spare bag of is actually from TIAIHUA. I am currently getting a few made by Omron and am looking for Cherry ones. I think Photekq proxied some from UK to you The_Ed, I might try some from that UK store or wherever I might find them as close to me as possible. Are there any other major brands which might be interesting?

[The_Ed]

Cherry DG23-B1AA microswitches are the good ones, Photekq was thinking about getting some for himself after he tried the ones he proxied to me. I got them from RS Components -> http://uk.rs-online.com/web/p/microswitches/0150798/ You'll need to get them proxied, unless you're fine paying them £20 for international shipping.

Omrons feel like **** once you've tried Cherry DG23-B1AA, plus it's always the Omrons that fail.

[mkawa]

there's definitely a difference in feel between microswitches. fightstick guys are serious about their microswitches. i'm surprised that the cherry b1aas are better than the high end omrons though. i quite like the omrons

[The_Ed]

there's definitely a difference in feel between microswitches. fightstick guys are serious about their microswitches. i'm surprised that the cherry b1aas are better than the high end omrons though. i quite like the omrons

Don't drink the Omron koolaid... Cherry is where it's at, and everyone I know who have personally tried the DG23-B1AA love them. Cherry DG23-B1AA are a bit heavier than the Omrons that most people are used to, but after you get used to them all those Omrons just feel wrong. They're just so CLICKY! They're the buckling spring of microswitches.

[damorgue]

I have heard many praise Omron microswitches, so I will reserve judgement until I have compared them. I believe almost all my mice of the past have used Omrons.

[Bullveyr]

You would like the sensor to output more raw movement data (less smoothing/corrections by the DSP, no advanced functions like angle snapping or LOD settings) and give the MCU more to do?
So basically shifting some of the processing from the sensors internal DSP to the MCU?

I think the idea is to have less DSP all together. Some anti-jitter and treatment is of course still necessary because as you say, they may have pushed the boundaries a little to far for a given hardware, but I find a lot of the treatments applied to be unnecessary and annoying. Angle snapping, prediction and acceleration are things I generally dislike. It might be because they are sometimes implemented to strongly and I just don't know the difference between the ones who have implemented it with less strength or nor at at all. There might be a setting there which is ideal.

The_Ed seems to be putting some sort of control on LOD at least in his firmware, and if I understand it correctly it will have no angle snapping or such. Ideally, I would like to experiment with how much angle snapping, prediction and acceleration I want. I am open minded and will consider the possibility that I actually still want a little of them, although perhaps not a cubic acceleration but a much lower for example. We'll see if I get to play around a bit with the code at a later date.

Classic angle snapping isn't a big deal anymore because usually it doesn't get forced on you nowadays.
Acceleration isn't artificially put in a sensor, it's a problem with the tracking code.

Allthough most people wouldn't use highly adjustable angle snapping and acceleration can be nice feature on a mouse level.

there's definitely a difference in feel between microswitches. fightstick guys are serious about their microswitches. i'm surprised that the cherry b1aas are better than the high end omrons though. i quite like the omrons

Don't drink the Omron koolaid... Cherry is where it's at, and everyone I know who have personally tried the DG23-B1AA love them. Cherry DG23-B1AA are a bit heavier than the Omrons that most people are used to, but after you get used to them all those Omrons just feel wrong. They're just so CLICKY! They're the buckling spring of microswitches.

Judging the qualities of switch manufacturers by comparing a 140/150g force switch to a 75g one seems a bit weird.

[mkawa]

You would like the sensor to output more raw movement data (less smoothing/corrections by the DSP, no advanced functions like angle snapping or LOD settings) and give the MCU more to do?
So basically shifting some of the processing from the sensors internal DSP to the MCU?

I think the idea is to have less DSP all together. Some anti-jitter and treatment is of course still necessary because as you say, they may have pushed the boundaries a little to far for a given hardware, but I find a lot of the treatments applied to be unnecessary and annoying. Angle snapping, prediction and acceleration are things I generally dislike. It might be because they are sometimes implemented to strongly and I just don't know the difference between the ones who have implemented it with less strength or nor at at all. There might be a setting there which is ideal.

The_Ed seems to be putting some sort of control on LOD at least in his firmware, and if I understand it correctly it will have no angle snapping or such. Ideally, I would like to experiment with how much angle snapping, prediction and acceleration I want. I am open minded and will consider the possibility that I actually still want a little of them, although perhaps not a cubic acceleration but a much lower for example. We'll see if I get to play around a bit with the code at a later date.

Classic angle snapping isn't a big deal anymore because usually it doesn't get forced on you nowadays.
Acceleration isn't artificially put in a sensor, it's a problem with the tracking code.

Allthough most people wouldn't use highly adjustable angle snapping and acceleration can be nice feature on a mouse level.

so if you tear a g9x apart and look at it at a block level, it really looks to me like the raw sensor output gets shoved to an arm (freescale MCU 32bit). the very slight negative accel is inherent to the sensor for some reason that probably has to do with weird optical stuff, but everything else is optional because i'm convinced that they're processing the laser receiver output at a DSP level. THIS is why accel, cpi/dpi, and everything else is fully adjustable in their gamer drivers. i haven't torn any of their other mice down, but you really want to buy big quantities of that mcu/sensor combo to deliver at their price points, so i suspect all the gamer mice use this same architecture (and this is why they all share the same really nice driver and utilities).

[mkawa]

in fact, if you can fit any of the logitech gamer pcbs into your rodent design, i would start with that as a base rather than the avago stuff. they seem to use this weird programmable asic that does fast gradient but needs a lot of custom programming to do anything interesting, and it isn't a particularly regular architecture or open at all.

[damorgue]

I still have the guts from a G300, and the shell too somewhere. I picked it last time because it was known for having a good sensor as well as several buttons I could wire my switches to.

[damorgue]

Cool! How do you intend to do the buttons? Cut slits into the body and let the plastic bend each time you press a button, or print individual buttons that fit and slide at the top of the mouse?

Combination I guess, mostly because I am undecided. I have added places where I can place nuts to avoid threads in the plastic. For instance the forward/back thumb buttons can be either printed along with the bending part and screwed there, or put on a small piece of sheet metal and then screwed there. The sheet metal idea is probably best longevity wise.

I am currently doing the left and right mouse button. I always intended for them to just be part of the shell, and a simple slit in a U shape would be sufficient. The problem is that they are really convex, which will make them far stronger than I want them to. I decreased their thickness to 1 mm and they will probably still be too strong. I can always cut them out completely like and have a small piece underneath them which attaches to the shell and bends, but then it would bend on a very small area which is likely to cause problems. I don't think I have space for more nut placement sites as well.

The middle mouse button next to the scroll is so complicated that It has to be printed atm. It is also mounted with screws to some slots where I can secure nuts. The mounting for the switch which belongs to it takes up place, and both sides are occupied by the RMB and LBM and the actual scroll wheel and its rig takes up a lot of space. I am short of space in certain areas.

I am thinking of redoing the nut placement
 This is how they look now. You slide the nut into the slot and it won't be able to rotate. i might fixate it with a small touch of adhesive. Not much though. I don't want it getting into the threads. Another pic of the inside of the shell

I could save a lot of space by doing this instead. The nut would just be placed in the slot with a little bit of adhesive. The hole behind it is required to allow the screw to pass through it a bit. Even with it, I am limited in the length of screws, or will have to use washers so that they don't stick in too far. It would be far weaker as well since the nut isn't behind anything. The only thing holding the nut in place would be adhesive. This is why I was against the idea at the start. However, if done correctly, the bending element screwed there will be screwed against the surface of the  nut and not the surrounding surfaces, hence I can screw really hard without it popping out. The adhesive would not have to resist such a large force as when you could have caused if the benind element would touch the surrounding surface first. The adhesive will just have to resist the forces applied when the button is pressed which is far less. A bit complicated in text, but hopefully it is understandable.

Edit: If I had a longer nut, something like a regular standoff perhaps, it would allow me to use the space behind the nut. That space would otherwise have been wasted as a hole for the screw to have a bit of clearance. Instead, I get a few extra threads, and more surface to put adhesive on. I might go for a female-female standoff instead.

[Bullveyr]

You would like the sensor to output more raw movement data (less smoothing/corrections by the DSP, no advanced functions like angle snapping or LOD settings) and give the MCU more to do?
So basically shifting some of the processing from the sensors internal DSP to the MCU?

I think the idea is to have less DSP all together. Some anti-jitter and treatment is of course still necessary because as you say, they may have pushed the boundaries a little to far for a given hardware, but I find a lot of the treatments applied to be unnecessary and annoying. Angle snapping, prediction and acceleration are things I generally dislike. It might be because they are sometimes implemented to strongly and I just don't know the difference between the ones who have implemented it with less strength or nor at at all. There might be a setting there which is ideal.

The_Ed seems to be putting some sort of control on LOD at least in his firmware, and if I understand it correctly it will have no angle snapping or such. Ideally, I would like to experiment with how much angle snapping, prediction and acceleration I want. I am open minded and will consider the possibility that I actually still want a little of them, although perhaps not a cubic acceleration but a much lower for example. We'll see if I get to play around a bit with the code at a later date.

Classic angle snapping isn't a big deal anymore because usually it doesn't get forced on you nowadays.
Acceleration isn't artificially put in a sensor, it's a problem with the tracking code.

Allthough most people wouldn't use highly adjustable angle snapping and acceleration can be nice feature on a mouse level.

so if you tear a g9x apart and look at it at a block level, it really looks to me like the raw sensor output gets shoved to an arm (freescale MCU 32bit). the very slight negative accel is inherent to the sensor for some reason that probably has to do with weird optical stuff, but everything else is optional because i'm convinced that they're processing the laser receiver output at a DSP level. THIS is why accel, cpi/dpi, and everything else is fully adjustable in their gamer drivers. i haven't torn any of their other mice down, but you really want to buy big quantities of that mcu/sensor combo to deliver at their price points, so i suspect all the gamer mice use this same architecture (and this is why they all share the same really nice driver and utilities).

Yes, all gaming use the same architecture (sensor + MCU) but usually the MCU (or software) doesn't fiddle much with the movement data from the sensor. It depends on the the sensor how much of various corrections are done.
In case of the G9x most of the things are options of the the sensor, CPI, angle snapping and afaik even the acceleration is a sensor level setting that comes with Logitechs special version of the A9500.

If you use a sensor with much less CPI options additional CPI settings are indeed done on a MCU or software level.

in fact, if you can fit any of the logitech gamer pcbs into your rodent design, i would start with that as a base rather than the avago stuff. they seem to use this weird programmable asic that does fast gradient but needs a lot of custom programming to do anything interesting, and it isn't a particularly regular architecture or open at all.

Using the PCB of a mouse certainly makes things easier but also leads to some limitation, although I would rather use a 2 PCB design mouse (Deathadder for example) for its flexibility.

[mkawa]

are you sure that _all_ the sensors output only movement data? in the g9x it looked like the laser receiver camera had a pretty wide bus to the MCU, enough that it could just be a raw image sensor that just scanned its photon wells and dumped the raw charge data onto the MCU. the MCU was certainly fast enough to handle all of that data.

[blueslobster]

… acceleration …

Hi Bullveyr

I was discussing the acceleration of the 9500/9800 with mkawa. For anyone not knowing what kind of acceleration this is, here is a short explanation by Cyro: http://www.teamliquid.net/forum/viewpost.php?post_id=18189604

Do you know of any way to find out whether the acceleration is a result of sensor architecture or SROM?

[mkawa]

from what i know, avago sensors don't give direct sensor output, period. you have to go through their controller. so in some ways it's the same thing. the SROM vs IC question is just one of how hard it is to fix. the problem is that the chip and compiler that avago uses for all their sensor controller units is completely closed. not even big vendors are given access.

[blueslobster]

How could fixing for both alternatives look like?

[mkawa]

replace with a philips sensor -- hope it can give you raw camera output

[Bullveyr]

are you sure that _all_ the sensors output only movement data? in the g9x it looked like the laser receiver camera had a pretty wide bus to the MCU, enough that it could just be a raw image sensor that just scanned its photon wells and dumped the raw charge data onto the MCU. the MCU was certainly fast enough to handle all of that data.

Yes, in normal operation mode it outputs Δx/y.
You can capture a single frame and you could use that to get a constant stream of the frames (afaik somebody did that with some older optical sensor).
I don't know if the bus would be wide enough but bear in mind that the SPI is 2 Mhz and the sensor operates with up to 12.000 FPS (images are 30*30 in grey-scale).

… acceleration …

Hi Bullveyr

I was discussing the acceleration of the 9500/9800 with mkawa. For anyone not knowing what kind of acceleration this is, here is a short explanation by Cyro: http://www.teamliquid.net/forum/viewpost.php?post_id=18189604

Do you know of any way to find out whether the acceleration is a result of sensor architecture or SROM?

It looks like it's a general problem with the architecture and not a simple SROM bug, it's probably not fixable but Avago never really cared anyway.

replace with a philips sensor -- hope it can give you raw camera output

The twineye works with doppler effect, so there is no raw camera ouput.
Besides, it also just outputs Δx/y

It also has it's own problem in the form of z-axis tracking.

[damorgue]

double post

[damorgue]

I received some questions on how I will attach the bottom plate. I have made the shell swell out in certain areas where I will make through holes. There will also be a hexagonal hole for a nut to be attached there. Placement:



Seen from the inside, this is the shape which will be cut out at removed. The thing illustrated is not a screw, simply what will be removed from the shell.




The screws with  countersunk heads will be screwed from underneath, through the bottom plate and holes in shell and then through the nuts attached on the inside. Hopefully that makes things a bit clearer.

Edit: I now realize that you were asking how I attach the PCB to the bottom plate and shell, not how the plate and shell are attached. D'oh! Well, I haven't fully decided on what sensor to use. It seems like it will be the adns 9800. If so, I will use a similar method: Countersunk screw from underneath the plate, possibly through some shims or washers to adjust height and then through the mounting points in the controller. Circular elongated holes could be used if I want to adjust the rotation of the sensor to align the X and Y to what feels natural. I don't want to leave gaping holes though, so that might be a prototype after which I change the holes to their exact position.

I have tried screws, shafts and little podests.

That does not sound all that different to what I will do.

[MOZ]

I can't wait to see where this leads to.