Controlling Vibration Intensity

[syncosised]

I'm currently working on a project where a phone receives an int by bluetooth from a distance sensor. I want the phone to vibrate differently depending on how far an object is from the sensor. If the object is very close, the phone should vibrate strongly, but if it is far away, the phone should vibrate weakly.

From what I understand, there doesn't seem to be any way of controlling the intensity of vibration directly in Java. I intend to deploy this program on many phones, not just Nokia devices, so I need a method that works on all Java ME devices.

Currently I have the following code:

    
    public void vibrate(int v) { // v will be an int between 1 and 5
        for (int i=0; i<1000; i+=(int)250/v) {
            Display.getDisplay(midlet).vibrate(10*v); // vibrate for 10 times v - 10 to 50ms
            try {
                Thread.sleep((int) 250/v);   // sleep for longer when the desired intensity is lower
            } catch (Exception e) {}
        }
    }

It's very messy, but the idea is that the lower intensity (1), will vibrate for a shorter period than the highest (5), and will also stop for longer. The result is that the lower intensities give small bursts of vibration, while the highest vibrates consistently.

It works, but I can't imagine it's terribly good for the vibration motor. Does anyone else have experience with a similar situation or have any suggestions? Thanks.

[grahamhughes]

There is no API for controlling vibration, beyond making the phone vibrate for a specific duration. The Nokia API provides a parameter for "frequency"... however, I'm not sure if any devices actually use it. It maybe that the hardware simply does not support that level of control. The only fine-grain control over vibrate I am aware of is on those phones that support Immersion's "VibeTonz" technology, but that's limited to a small number of Samsung devices, I think.

Graham.

[syncosised]

Thanks for confirming that, I was afraid that was the case. Do you have any suggestions for an alternative? Is the code I have written bad for the vibration motor?

[grahamhughes]

Vibration is pretty much the only option for non-visual, non-audio communication with the user. Hmmm... unless you connected some kind of loud-speaker to the phone, and played low frequency tones, it might be possible to feel them. I'm assuming this is aimed at deaf-blind people?

Is this a commercial or academic project? If academic, then I suggest you do your testing on a cheap handset! I've never seen a phone damaged by excessive or inappropriate use of the vibration mechanism, but I'm not a mechanical engineer, I can't really comment on what such a mechanism is likely to withstand. You might want to play some of the phone's ring-tones with vibrate enabled, see how rapidly they switch vibrate on and off.

While it doesn't relate to you question, there are some traps to fall into with vibration. Many devices will not vibrate when a charger or data cable is attached - don't fall into the trap of thinking your software or handset is broken! Also, some Nokia Series 40s have a separate vibrate on/off for MIDlets installed in the "games" folder. Knowing this might save you some hours spent tracking down "bugs" that don't exist!

Graham.

[syncosised]

Your deduction skills are very good! It's an academic project for visually impaired users. We did a lot of research before we started designing, and the general feedback was that audio feedback is not desirable as you're pretty much taking away another one of their senses. A vibration system is pretty intuitive though, so it seems like the best option. The phone will be more of a secondary feedback, there will probably be a dedicated vibration motor built into the main device later on.

For now I'm testing it on a Nokia 2323, so if it breaks I won't have lost too much money. Thanks for your help. I'll continue with this line of coding and hope it doesn't break!

[grahamhughes]

OK, so at least you don't have to worry about distributing this to end users, who might later sue you if your application breaks their phone!

You could pick up some cheap, second-hand phone if you want to test-to-destruction, or simply write up in your documentation that you recommend such testing as a future extension to the project. Perhaps keep some log of how many hours running the app (or vibration test apps, or whatever) your phone survives. I would hope that the fact that you have thought about it, researched it, and come up with some ways to evaluate any potential problem would score you some points, even if you don't have a definitive answer. A definitive answer is probably hard to come by, unless you can identify specific parts used in specific phones, and find their manufacturers' specification (particularly, MTBF (mean time between failure) and recommended operational conditions).

Good luck!
Graham.