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.
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.
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.
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.
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.
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
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 to make sure I understand you correct.
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
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?
Angle snapping will be disabled by default, but you can enable it by changing the hexadecimal characters.
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
Classic angle snapping isn't a big deal anymore because usually it doesn't get forced on you nowadays.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.
Judging the qualities of switch manufacturers by comparing a 140/150g force switch to a 75g one seems a bit weird. ;)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.
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).Classic angle snapping isn't a big deal anymore because usually it doesn't get forced on you nowadays.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.
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.
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?
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.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).Classic angle snapping isn't a big deal anymore because usually it doesn't get forced on you nowadays.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.
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.
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.
… acceleration …
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.
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.… 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?
replace with a philips sensor -- hope it can give you raw camera output :PThe twineye works with doppler effect, so there is no raw camera ouput. ;)
I have tried screws, shafts and little podests.That does not sound all that different to what I will do.
it operates over SPI? FACEPALMare 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).
this is why we need open standards and firmware and to adopt one of the current arm prototyping volume socs (the beaglebone cortex has a SWEET simd unit). hell, it's not that hard to build an optical sensor. you buy up some tiny high speed camera sensors in bulk from sony, you buy some binned LEDs and you go to town with a piece of plastic to aim them. the hardest thing by far is the optics, actually. you can't print that, and you can't build a small injection molding tool for it either. a molded optic would need hand or machine finishing etc. etc. ideally you could reverse engineer the avago sensor protocol and tap into the image feed by force but that's very much easier said than done.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.… 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?replace with a philips sensor -- hope it can give you raw camera output :PThe 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.
They are both around 140g. The Cherry ones with a flat lever are labeled around 45g and the ones with roller lever are at around 60g simply because those are measured on the lever. The actual switch is the same for all of them at 140g though. The lever will be popped off if I get ones with them anyway. They are all actually fairly similar in force.Judging the qualities of switch manufacturers by comparing a 140/150g force switch to a 75g one seems a bit weird. ;)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 omronsDon'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.
Although the are also 150g variants of the Omron switches the ones used in mice are 75g.They are both around 140g. The Cherry ones with a flat lever are labeled around 45g and the ones with roller lever are at around 60g simply because those are measured on the lever. The actual switch is the same for all of them at 140g though. The lever will be popped off if I get ones with them anyway. They are all actually fairly similar in force.Judging the qualities of switch manufacturers by comparing a 140/150g force switch to a 75g one seems a bit weird. ;)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 omronsDon'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.
Although the are also 150g variants of the Omron switches the ones used in mice are 75g.
Judging the qualities of switch manufacturers by comparing a 140/150g force switch to a 75g one seems a bit weird. ;)
Although the are also 150g variants of the Omron switches the ones used in mice are 75g.
Why would you look for a DG13-B1AA? DG23 series are what fit into mice, and DG23-B1AA is what I recommended and gave a link to.
Why would you look for a DG13-B1AA? DG23 series are what fit into mice, and DG23-B1AA is what I recommended and gave a link to.
I have listed that I am interested in other Cherry DG series switches as well, chill down. I have particular interest in the DG13B1AA model simply because I have found it. The only difference is that it is rater for higher currents. It fits mice as well.
Edit: To be able to compare the feel of them, I am particularly interested in Cherry DG*3-C*** as well.
Edit2: Are Omron D2FC discontinued? Their specs are harder to find.
A this point, I don't care all that much about what type of pins they have either. They will work fine for testing to see whether I want them and if it is worth the effort getting the correct ones. I can probably make any of them work if nee be.
Item D2F D2F-01 Specification Crossbar Crossbar Material Silver alloy Gold alloy Gap
(Standard value)0.25 mm 0.25 mm Minimum Applicable Load
(See note)100 mA at 5 VDC 1 mA at 5VDC
Note: Minimum applicable loads are indicated by N standard reference values. This value represents the failure rate at a 60% (λ60) reliability level (JIS C5003).
The equation λ60=0.5 x 10-6/operations indicates that a failure rate of 1/2,000,000 operations can be expected at a reliability level of 60%.
Using Microloads:
Using a model for ordinary loads to switch microloads may result in
faulty operation. Instead, use the models that are designed for microloads and that operate in the following range
{graph below}
Calm down.Judging the qualities of switch manufacturers by comparing a 140/150g force switch to a 75g one seems a bit weird. ;)
It's interesting that you are trying to twist my opinion down to being purely based on the actuation force. Have you personally tried the Cherry DG23-B1AA microswitches and compared them to the standard mouse's Omrons in both feel and electrical reliability/longevity? Don't make accusations about people and products you don't even know.
I don't know of any halfway common mouse that uses 150gf Omrons.Although the are also 150g variants of the Omron switches the ones used in mice are 75g.I see you are also lumping all mice that use Omron switches together as using the same actuation force. That is obviously not true since the only reason to make different actuation forces from a manufacturer's prospective is gaining more sales.
Oh and by the way, you measure the force it takes to actuate a switch in cN (centi-Newtons), N (Newtons), or gf (gram-force) as those are measures of force applied.Do we really have to go down that road when it's rather common practice (even on this forum)?
My mice over the years have taken more or less force than each other, but I haven't opened them all up and written down the part numbers of the microswitches, so I can't be absolutely sure that I have or haven't tried 150gf Omrons.The shell also has some impact on that.
You seem to think that the most important aspect of feeling is the actuation force for some reason. Why are you hung up on that? The Cherry DG23-B1AA microswitches are the loudest, toughest, most clicky, most tactile, and most crisp to actuate microswitches I have ever had the pleasure of using.I don't think it's the most important aspect but don't you think that having an actuation force of 75 or 140/150gf has quite some impact on the overall feel of a switch?
If anyone has any of these micro switches, I would appreciate it if you would send them to me.
Is it possible, to make a ring and index finger rest for the Rat 3/5/7/9 for the right side as an attachment to replace the current replacements.
I'll get some pictures up soon.
Man, you're living my dream. Just some weeks ago I considered harvesting an old mouse and somehow creating my own shell. I'm not very good with either my hands nor do I have access to a 3D scanner.
So I basically gave up... :(
I'll be watching this closely and with great interest. Maybe I'll find a way to do my own after all, somehow.
Oh and btw, new replacements for the RAT3/5/7 is a cool idea too!
is it possible to use mx switches as the left click and right click?
1. Too easy ;).Hmm. I dislike 2 simply because the gap becomes quite a bit wider when the button is pressed, and it does not provide any sort of stop except the switch and its holder. If I press it hard enough something will break. I have seen mice like this, but I would much prefer a solution where it stops at the hull and the hull can withstand the full force. The only problem then is that it has to have activated the switch, so the tolerances are quite tight. On the other hand, since the switch doesn't have to withstand large forces, it is easier to enable it to be adjusted in position slightly. The issue you mentioned with 5 is solved if I choose to have the button as a separate removable part.
2. option might reward you with some "sharp" edges while pressing the buttons, besides this, I would prefer it. It allows the easy travel down and not cause addition friction compared to the first option (which might have the sides sliding against each other if some wrapping occurs).
3. & 4. might cause the button to jam if shifted to the side, so it wont release instant - but this won't be a problem if you make both thicker around the cut. Also might be heavy to clean if needed.
5. You'll be unable to clean the cut, you cannot slip some paper in there to catch the dirt - or you have to lift the button, dunno if the material allows that much flex.
U or O? Going for the O also asks for an smooth and low frictional guiding of the "keycap".With the O, I would put a flange on it and attach it on the inside of the hull. This flange could have ribs to guide the bending of it in a certain direction a little. With the U, I am forced to let it bend largely according to the shape of the hull, although I can affect it a little by where I end the slits and such.