Android compass seems unreliable?

Your code looks fine to me, if there would be an error in your code I am pretty sure both devices would suffer from that. I think it's the hardware in the devices that's causing the differences. Have you "calibrated" both compasses by moving the phone in figure eight shapes?

Many compass apps suggest that, including the map software that comes with symbian devices. That could work.

Thanks for the response, and you do make a great point about calibrating that can make a huge difference and make the compasses unreliable. Unfortunately this was a step I forgot to mention that I did before the tests(i edited it in now). I will give it another go and calibrate even longer this time too see if I notice any better results.

– ocross Jun 6 at 23:26.

Even though the author answered his own question I have to chime in here just to reinforce the almost utter uselessness of any kind of compass functionality on the Android platform. I have come to the conclusion that anyone that depends on an Android compass application is asking for trouble, none of them work reliably and it is not the fault of the developer. Google and the mfg's simply have not provided a way to get reliable accuracy from these devices, or even to determine if the accuracy is reliable which is even worse because sometimes they are and many times they are not and if someone trusts these devices for real orienteering God help them.

The reason the author probably thinks he is getting better results is that they use a pretty good noise filter on the deprecated orientation sensor ( why they could not do this on the newer method is beyond me ) and in limited testing on a single device after calibration this will appear to work, but in the field using many devices I have found that for the most part the reliability is always in question. First the noise generated from the magnetic and orientation sensors are horrible, yes this can be overcome with proper DSP techniques, and with 2.3 and gyro enabled phones it will get better overall, but shame on Google and the Mfg's for wasting so much developer time with shoddy implementations of hardware and software outputs. Second, I have tested at least 18 phones with proper DSP filtering in place and while that cleans up the noise it does not help with accuracy, even the same model of phones have different outputs (though some models seem better than others) Third you have little in the way of determining if the sensors are calibrated, even doing the spastic figure 8 motion may or may not calibrate the phone and the user never really knows if it's working or not, unless you have a compass to verify, which kind of defeats the point doesn't it?

NOTE: you can multiply and sum the magnetic sensors with each other and take the square root of that sqrt(x*x+y*y+z*z) and make sure it's between 25 and 65 or so, this is one indicator you can use to detect anomalous fields but it's not completely reliable, better than nothing I guess. Fourth, many phones are completely unreliable, calibrated or not, which is not limited to model types but possibly shoddy QA on the part of the mfg, I really don't know why but I can say that 3 HTC ARIA's produced wildly different results (one 30 degrees off, the other 50, and a third almost spot on) same thing with incredible, nexus, etc. I tested 18 phones and many were pretty close to accurate IF you could calibrate properly, but many of those took 2-10 try's ( we verified after each calibration attempt with a high precision compass ) and more than a few times they would simply NOT calibrate at all. NOTE: you do have to account for declination for a true north offset, which you can do with the API in android if you have access to the current GPS coordinates, altitude, time of day etc. The problem was NOT declination and if you are comparing to a compass that's not an issue anyway since it will also be effected by local magnetic fields.

Fith, cold starts always require the calibration step on every phone we tested, which includes the X, the incredible, the Aria, the Nexus, and the Thunderbolt.In other words the first time you start sensor listening 95% of the time it will require a calibration step (even a broken clock is right twice a day) so if you insist on adding this functionality I would just tell your user to do it at the start of each listener event. If you leave the senors running (bad for battery) then you may or may not have to re-calibrate depending on the fields it's encountered) the above method works ok for that. The bottom line is that when they work they seem cool, but you can NEVER currently be sure of the accuracy of the azimuth, which makes them pretty unreliable and useless for any real work.

Personally I would use a GPS bearing while moving and then a rotation vector method if possible, it might not be perfect but it would be a heck of a lot better than the craptacular implementation that you have in the current line of phones for azimuth. Sorry about the long winded reply but I have wasted almost a month on trying to get this to work with the help of an expert DSP engineer and we have pretty much written of the android platform as useful in this respect. A "Sometimes this works, other times it won't, you can never be sure unless you have a real compass" disclaimer should be put in every compass application in my opinion.

Yes I agree with you. I came to the conclusion that you must realize that there will be around a +-30 degree margin of error with the readings it seems like on most my devices (only tested with 6) it sticks between a range of around 10. As for why I said the orientation sensor was the fix was because the droid X was not working at all.

The reading wasn't anywhere near correct when the others were close with an error margin and switching to the orientation made the X work similar to the others. The noise reduction was nice but I was doing my own low pass filter already after getting values. – ocross Jun 14 at 21:17 @ocross What I did find was that if the sensors cfg file was deleted the offset problem, and the re-calibration problem went away.

The problem is that requires root access, and it's only temporary. Also the sticking problem seems to be related to manual calibration on the phones I tests, the lazy-8 wrist motion fixed that at least. For the other I had to include and offset function that could be "synched" to the gps bearing (speed accuracy must be good) or manually by the user.

Problem is that drift happens over time – Idistic Jul 9 at 20:02.

Well after much testing, and debugging. I came to the conclusion that yes as some of you mentioned the differences my droid 1 and Nexus S were purely hardware difference and magnetic interference. However the Droid X was a different issue, whatever I tried I could not get the correct readings out of the recommended way with getRotationMatrix and getOrientation, even when added re-map coordinates function.So after some tinkering with no success I figured id give the Orientation sensor way a shot.

Google says that this way is deprecated and they recommend doing it the way I started off with, however I tried all types of combinations with that way with no success. So I went ahead and ignored thier warning and used the orientation sensor ... and it worked. Why?

I have no clue, the droid x is newer os than my droid 1 so it shouldn't have to do with using legacy code. However it does make sense why compass apps wrote to target 1.6 would work while my app doing the "recommended way" was not working. If anyone has any better way to do this let me know, or if you know a way to make it work with getRotationMatrix and getOrientation also do tell.

Otherwise for anyone else who hits this brick wall as hard as I did heres the code that ended up working for me. My on sensor changed switch (event.sensor.getType()) { case Sensor. TYPE_ORIENTATION: m_vforientVals = event.values.clone(); break; } if(m_vforientVals!

= null) { m_fCompBearing = m_vforientVals0; mCompHead. SetText("" + (int)m_fCompBearing); calcOffset(); rotateCmp(); } and initialize the sensor listener mSMngr. RegisterListener(mSListener,mSMngr.

GetDefaultSensor(Sensor. TYPE_ORIENTATION), SensorManager. SENSOR_DELAY_NORMAL).

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.