Related
Could an app be developed to use the gsensor and measure distances. I was thinking you could press a button to start a measurement move your phone press another button and we could see the distance in feet meters etc. is this feasable
commodore65 said:
is this feasable
Click to expand...
Click to collapse
no.
go and get a tape measure and selotape it to the side of ur phone
It would get pretty complicated. Your phone would have to keep track of each and every different acceleration and the duration of that acceleration to then calculate out the distance traveled during each acceleration. Since we are human I highly doubt we can keep a constant enough acceleration to measure anything short. It does seem to me that the longer the distance being measured (maybe in a moving car as foot steps may throw the measurment off) the better chance there could be for accuracy as the small accelerations that would normally throw off the measurement would be less of a problem. (then again I am a physicist and not a phone programmer so I don't know how accurate the accelerometers in these phones are).
I bet something could be written to tell you how far the phone has been dropped... if you could keep the phone from rotating during the fall. The acceleration of gravity is constant and that would be an easy calculation that could just cut off as soon as the acceleration changes drastically (when it stops falling suddenly). Then again I am physicist not a programmer.
If someone wants to try feel free to ask me for a set of fairly simple equations or help with the math. I doubt most people that program will need that help though.
i think the G sensor in the phone is a bit too "hit-and-miss" for this application, it would require a very fine tuned, high contrast sensor (most likely costing more than the phone!)
it you want to do a large distance, then u could use the GPS positioning, but yet again, wont be very accurate.
+ 1
i subscribe to this program but I don't believe is posible. I'm an architect so I'd strongly need it. you can youse GPS for outside mesurements and you can use SuperRuler for smole mesurements or distance mesurements.
http://www.pocketdevelop.com/index.aspx
I dont think its that much of a stretch. Using tweeter i find the sensor is extremely accurate and sensitive. While i dont need the app, basically as he said press start and then start moving the phone left or right up or down and press stop.
However since the sensor is not made to do that, i could be totally wrong it it is not possible at all. Basically because the sensor is made to track tilt movements and not distances. Lol im basically debating with myself
xboxhaxorz said:
I dont think its that much of a stretch. Using tweeter i find the sensor is extremely accurate and sensitive. While i dont need the app, basically as he said press start and then start moving the phone left or right up or down and press stop.
However since the sensor is not made to do that, i could be totally wrong it it is not possible at all. Basically because the sensor is made to track tilt movements and not distances. Lol im basically debating with myself
Click to expand...
Click to collapse
it might work
It's all relative, I can play teeter on a train!
uniqueboy said:
It's all relative, I can play teeter on a train!
Click to expand...
Click to collapse
If you're playing tweeter on a train traveling near the speed of light and I am at the train station watching you play teeter as you pass by, is the ball falling in the whole or the whole falling around the ball? Where was I going with this? Oh yeah would this tape measure have to account for time dilation? I mean the Lorentz equations are the most accurate set of linear coordinate transformations we have, right? As you move the phone time will dilate, lengths will contract and let's not even mention the rotation of objects from the phone's perspective... wait did I just mention it by stating that I wasn't going to mention it?
Like I stated before... it is completly possible to measure distance using nothing but acceleration information... beyond that the accuracy in your measurement will depend on the accuracy of the device measuring the acceleration(s). Of course you may have to get into the rate of change of you acceleration (the rate of change of the rate of change of the rate of change of your position) which is called jerk.
Beherrschen said:
it is completly possible to measure distance using nothing but acceleration information...
Click to expand...
Click to collapse
Erm guys, this is only a lil bit right ;D You can't measure a distance with an accelerometer... very well. As the word says, it measures accelerations... so if you walk 10 Meters to check the distance, your Device only accelerates the first meter when you start walking... when you walk with the same speed the accelerometer shows:
0
(at this moment it has to know how fast your speed has to be when you accelerated in the first x seconds with x G's to calculate how many meters you walked within the x seconds till the -G starts when you stop ... almost impossible ;D )
Absolutely 100% not possible, for any kind of practical purpose.
If the device could be held exactly flat, it would be just about possible to use acceleration data to make a guess at speed and therefore at distance... but it would be such a wild guess it would not be useful.
A visual estimate will always be better!
Phexi said:
Erm guys, this is only a lil bit right ;D You can't measure a distance with an accelerometer... very well. As the word says, it measures accelerations... so if you walk 10 Meters to check the distance, your Device only accelerates the first meter when you start walking... when you walk with the same speed the accelerometer shows:
0
(at this moment it has to know how fast your speed has to be when you accelerated in the first x seconds with x G's to calculate how many meters you walked within the x seconds till the -G starts when you stop ... almost impossible ;D )
Click to expand...
Click to collapse
Seems like you told me I was only partially correct but then the second part of what you wrote seemed to agree that it possible (maybe not practical) to calculate distance traveled from nothing but acceleration information. It is possible to calculate distance traveled from nothing but acceleration (and the duration of each acceleration but that goes without saying since you must always know the duration of a motion to determine distance) information.
For example: If you have a situation where there is an initial acceleration A1 for t1 seconds, followed by a contstant speed S for t2 seconds, and finished off with another negative acceleration A2 for t3, then you have all the information needed to determine the overall distance traveled. During the first section of our travel the acceleration, A1, and the duration of that acceleration, t1 are can be used to calculate your total distance during that acceleration. A1 and t1 can also be used to calculate the speed you are traveling at the end of the initial acceleration, S. Use S and t2 to calculate the distance traveled during the constant speed portion. Then use S, A2 and t3 to calculate the distance traveled during the final accleration (even if your final speed isn't zero). Equations below:
Set 1: acceleration = A, velocity (speed) = V, distance = X, time = T, initial = i and final = f
starting with the assumption of constant acceleration then each successive equation can be derived by integrating the previous equation with respect to time.
A = A
Vf = At + Vi
Xf = (1/2) A (T^2) + Vi T + Xi
Set 2: also at constant acceleration with the same key as above.
A = (Vf - Vi)/T
V(average) = (Vf + Vi)/2 = (Xf - Xi)/T
Either set of equations can be used. They are basically the same set of equations. One derived using calculus (Set 1) and the other using conceptual ideas of motion (Set 2). With a little algebra both sets can be derived from eachother. If you add in an inconstant acceleration (jerk) then the equations become more complicated and I am not gonna derive them out here.
I am sticking to my is it possible but most likely not practical. Unless you came up with a way to maybe statistically ignore any little outlyer type accelerations... anyway, I am rambling. Feel free to let me know if you can't solve a problem like the one I stated above using those equations and I wll be glad to help.
Beherrschen said:
Seems like you told me I was only partially correct but then the second part of what you wrote seemed to agree that it possible (maybe not practical) to calculate distance traveled from nothing but acceleration information. It is possible to calculate distance traveled from nothing but acceleration (and the duration of each acceleration but that goes without saying since you must always know the duration of a motion to determine distance) information.
For example: If you have a situation where there is an initial acceleration A1 for t1 seconds, followed by a contstant speed S for t2 seconds, and finished off with another negative acceleration A2 for t3, then you have all the information needed to determine the overall distance traveled. During the first section of our travel the acceleration, A1, and the duration of that acceleration, t1 are can be used to calculate your total distance during that acceleration. A1 and t1 can also be used to calculate the speed you are traveling at the end of the initial acceleration, S. Use S and t2 to calculate the distance traveled during the constant speed portion. Then use S, A2 and t3 to calculate the distance traveled during the final accleration (even if your final speed isn't zero). Equations below:
Set 1: acceleration = A, velocity (speed) = V, distance = X, time = T, initial = i and final = f
starting with the assumption of constant acceleration then each successive equation can be derived by integrating the previous equation with respect to time.
A = A
Vf = At + Vi
Xf = (1/2) A (T^2) + Vi T + Xi
Set 2: also at constant acceleration with the same key as above.
A = (Vf - Vi)/T
V(average) = (Vf + Vi)/2 = (Xf - Xi)/T
Either set of equations can be used. They are basically the same set of equations. One derived using calculus (Set 1) and the other using conceptual ideas of motion (Set 2). With a little algebra both sets can be derived from eachother. If you add in an inconstant acceleration (jerk) then the equations become more complicated and I am not gonna derive them out here.
I am sticking to my is it possible but most likely not practical. Unless you came up with a way to maybe statistically ignore any little outlyer type accelerations... anyway, I am rambling. Feel free to let me know if you can't solve a problem like the one I stated above using those equations and I wll be glad to help.
Click to expand...
Click to collapse
For this to work we would have to stop the rotation of the Earth, but then there is not a stationary point anywhere in the universe, so I will never be able to measure the train I was on playing teeter. I always loved Newtons equations of motion especially the one A=A
uniqueboy said:
For this to work we would have to stop the rotation of the Earth, but then there is not a stationary point anywhere in the universe, so I will never be able to measure the train I was on playing teeter. I always loved Newtons equations of motion especially the one A=A
Click to expand...
Click to collapse
Actually if we are going special relativity on this problem then we also need to eliminate any form of gravity since special relativity only applies to inertial frames of reference. And since I am not about to break out the tensor mathematics of general relativity, then it would seem we are SOL in finding out what really did happen with your teeter game. :-(
Just remember: Things are the way they are because if things weren't they way they are we wouldn't be here asking why are things the way they are.
Anyone else having as much fun as I am with this thread?
IDEA:
I have thought of a way to at least get a close approximation to this. I am not a programmer but it seems to me this should be possible. The area under the graph of acceleration vs time is velocity. Make a program that would plot the information acceleration vs time information on a graph in excel. Then, after the recording is finished, the program could go in at fixed intervals, turn the smoth graph into a point to point graph with straight lines from point to point (using the line of best fit feature in excel... assuming it is also in excel mobile...) and calculate out areas under the curve. Then you would have all the information needed, velocity and duration of each velocity, to easily calculate out distance. Now this would be an approximation and never be exact. But even calculators only give you Tailor Series approximations. The smaller the interval taken on the graph the more accurate the final distance would be. You could even make it work with an adjustable interval so the sensitivity could be adjusted.
To better explain my idea for manipulating the graph then picture a sine graph. On it's own it is a nice smooth wave looking graph that repeats every 2pi (don't want to look up the symbol for pi to type. just take 3.14159 = pi). Now imagine you marked a point every 0.5pi on that curve and then connected the points together with a straight line. You would end up with a saw tooth graph. Now what if you did that at every 0.2pi, or .1pi, or... you get my drift. The smaller the interval that you make a point and connect it the closer and closer you get to a good approximation of the original sine graph (much the way Archamedes used ever increasing numbers of triangles inside a circle to approximate its circumference and calculate pi). The advantage of doing this is to eliminate calculus and use nothing but algebra.
This could all be done without graphing and just having the program do the math tiself but why not let excel do the work? I could be way off and using excel this way may suck from a programming point of view, but this is how I would handle a lot of data if I were given a bunch of acceleration and time information. Making the sensitivity and accuracy changable by allowing the user to define how far apart to set the points could allow for some decent measurements. I think if done right even outlying movements (slight tilting of the phone or taking a step or two) could be negated by the approximation.
Let me know what people think. Even if this doesn't work maybe it will inspire a better idea!!
I have noticed that my HTC Touch HD consistently shows heights incorrectly - about 50m too high where I live. After some research I have identified that the NMEA message GGA contains 0 in field 11 (Geoid separation) which should contain the difference between the ellipsoid height and mean sea level height. In my Mio A701 this field contains 50.5, which explains the 50m error on the HTC.
Despite searching this forum I have been unable to find any reports of this problem. Has anyone else experienced it?
What gps chipset does the HTC Touch HD use? My copy of Sirftech does not work on it, so perhaps it is not the Sirf ?
Is there any way to correct this error?
Thanks for any information
Edit
The problem has been solved thanks to the GpsModDriver which performs this correction (amongst other things), and which can be found at http://forum.xda-developers.com/showthread.php?t=571266.
rpettipher said:
What gps chipset does the HTC Touch HD use? My copy of Sirftech does not work on it, so perhaps it is not the Sirf ?
Is there any way to correct this error?
Click to expand...
Click to collapse
It uses the Qualcomm GPSone receiver, this isn't a discrete component as a SiRF chip would be, but is integrated into the 7201A chipset
Sounds like you need to try to flash a few different radios.
GPS height error
Thanks for the information about the chipset.
Because of that I found a small program (MyGPS) which is largely based on an MS SDK demonstration, and that gives the correct height !!
As I understand it, please correct me if I am wrong, that program uses the MS SDK primitives to get information from the GPS without going through the NMEA messages (?). If it can get the correct answer then the GPS must be working, but the NMEA messages, and the programs using them (ozi explorer, visualgps ...) are wrong.
It would be very helpful if someone could confirm that they do see non-zero values in field 11 of the GGA NMEA message (between the two Ms) on an HTC Touch HD.
(One easy way to see the messages is to use the log feature of visualgps).
Thanks for your help
Actually, I noticed it, and I programmed a soft-coded separation correction into the program GPSVP: http://code.google.com/p/gpsvp/
Not many chipsets have the separation. To date, I had none in my hands, other than when using a 'real' garmin connected via a cable to my PC.
Additionally, I have encountered no program that does the correction, other than gpsVP, in which I programmed that myself. I shall check that MyGPS, if it is correct, but I am sceptical, I do not believe that MS would strip the info from the chipset, nor do I believe MS has a softcoded correction.
I guess I could write some sort of serial loopback to insert the logic into other programs, but I am far to busy.
EDIT: just so you know: I only programmed this very small part into gpsVP, the rest is done by others.
GPS height error
Thanks for the reply cybermaus, unfortunately I am not sure what you are saying.
What did you notice ? Zero in field 11 of the GGA message?
Are you suggesting that most chipsets put 0 in field 11?
This is certainly not the case with my Mio A701 with the Sirftech chip, which puts 50.5 into that field and gives me accurate altitude values.
It seems (I am still learning) that there are two ways to get the information from the gps, either parsing the NMEA messages or using the MS API.
In my case it seems that the first way fails and the second works.
Which does your program use, and how have you made the correction?
Thanks (in advance) for your patience with these questions.
Well, yes, I am saying that the devices I encountered, all gave 0 in that field, except actual Garmin handhelds connected by serial. Also, I learned from reading in the internet, that many other people noticed the same. But that does not mean there are none. I believe any real Sirf III will do it correct, but I have a Sirf II dongle witch also does it wrong.
It even turns out there are a few devices, that put 0 in that field, but already subtract the correct separation from the geoid height, so you should not correct the value yourself.
The geoid separation is stable, and well known, you can look up the value for every coordinate on the internet. Also it varies only with a few meters per degree in the steepest places. The steepest separation is west of the mountains range of Peru. The biggest separation is a 100 mtr hole in the sea south of India.
What I did was program a hardcoded matrix with 10 degree resolution (to keep it small) with the correct geoid separation value. The program than takes your coordinates, and *interpolates* these in the matrix, to find your separation. I found it will yield the correct value within 1.5 mtrs, which is well within the GPS precision.
Also, if my program finds there is already a separation value in the field, it will *not* apply the correction, because it knows the chipset behaves properly.
If you want more details, browse the source to gpsVP. Unfortunately, you will not be able to use it for other programs if you are not a programmer or do not have access to the source of those other programs.
As I said, if I have some time, I will check out the MS API you mentioned, there is indeed a new API data structure in WM 6.1 and above, I played with it, but I did not check it for this parameter specifically. However, I am skeptical. I find it more likely the programmer from MyGPS did something similar as myself.
As to your Mio A701. Good. I said I did not encounter any other than the dedicated GPS handhelds from Garmin, but that does not mean there are none. To be quite honest, I only held 5 or so non-Garmins, so who knows.
I think the problem is not widely recognized because most people use GPS in 2D, for navigation. This 3D is more for people doing hiking, with programs like gpsVP or Ozi. Pilots and paragliders may have a 3D GPS, but know better than using it for altitude (I am a paraglider myself)
BTW: Ozi also does not correct the value, I checked.
GPS height error
Thanks again for the comprehensive reply.
I am surprised that you say that most GPSs give incorrect altitudes due to the missing geoid separation field, since I have seen a lot of discussion about this problem, mostly several years old, so I assumed that any modern chipset would have it sorted. I am also surprised that no-one with an HTC Touch HD (for instance) has complained about it.
Do you have an HTC Touch HD, and are therefore confirming that this model is faulty? That is - the NMEA message GGA field 9 gives height above ellipsoid and field 11 is 0.
I would still appreciate input from any other HTC Touch HD owner on the values in these fields.
As you say, and as I have seen, ozi explorer does not do a manual correction in the way you do. It does not need to when the NMEA messages are correct since field 9 is specified to contain height above MSL.
It does, however, have an option to subtract the geoid separation field from the value in field 9 to correct for the (other faulty) case where field 9 contains the height above ellipsoid and field 11 gives the geoid separation. If I use this option on the HTC it changes nothing, since field 11 is 0, but on the Mio it then gives me heights 50m too low (as would be expected).
I will now try your program.
Well, this not just my program, I only supplied 1% of the code, it just happens to be this particular part.
Anyway, yes, I do have a Touch HD. And yes, I am talking about the GGA message fields. One with altitude according to WGS84 ellipsoid, and one with the separation of said ellipsoid from the actual geoid according to the '96 model. Probably indeed fields 9 and 11, though I have not looked at the code for a few months, but it sounds about right.
Your MIO has a real Sirf III chipset. I would have expect that to work, because my Garmin also has a Sirf III in it. But as stated, I have a dongle with Sirf II, and that did not have the correction. Neither did the other dongles I have, but granted, they are all a bit aged and budget quality. Maybe my experiences are a non representative sample
But I confirm the Touch HD is faulty, and I suspect other HTC's and many other brands & models with non-dedicated chips. These do not have a real GSM chip, but a generic secondary ARM cpu shared with the GSM radio function and other radio functions like WiFi, UMTS, Bluetooth and probably even FM.
----
The way I understand it, the original GPS specifications did not have the separation specification. In '84, they simply did not realize that a simple mathematical ellipsoid model for earth and earth gravity was so incorrect.
It was only after the launch of the GSM network that they started to realize that there were so many fluctuations in the local gravity of the earth, which causes this effect, that they came up with the new '96 numerical geoid, rather than the mathematical '84 ellipsoid. Or something like that.
Of course, if HTC wanted, they could program the similar correction into the radio chip firmware, it is simple and small code. And it is 14 years after the fact. But I think they simply do not see the need.
----
If you start to use gpsVP, and you go hiking off-road, please note I find it best to use with GARMIN vector maps. I can also downloads Bing and Google raster maps, but those are not good in off-road data, though the satellite view is sometimes nice.
All in all, the program is a bit 'coarse' in its use. If you understand what it does (vector maps and preloaded cache for raster maps), it has value, but you will not be able to impress friends who are used to the smooth Google map application.
GPS height error
Thanks again cybermaus.
I tried the gpsvp program, both in the htc and the Mio. On both machines I got a correct altitude and a value of 51 for the geoid separation field, which compares well with the 50.5 which appears in the GGA messages on the Mio, so it looks as if your calculation works well.
I tried changing the value of the Geoid separation parameter in the setup options, trying auto, always and never, and in all cases got exactly the same results for altitude and geoid separation, so I am a bit puzzled. Does the setup option change anything, or does one have to do something else to activate it?
Well, the setup part of it is not complete yet, I think it is essentially always auto. Need to find the time and motivation to complete the coding. Log a case in the gpsVP website please.
I do not have much to contribute, but yes, living in Switzerland and hiking in the mountains I have also noticed that the altitude was wrong.
I first thought it was the inherent imprecision of the GPS, but then remarked that it was systematically off by several tens of meters.
I was also surprised that nobody complained, now I know that I am not alone.
I wish that programs like Ozi could apply the correction, or at least allow entering a fixed offset.
Thanks to cybermaus for explaining it.
Will give a try at gpspv.
GPS height error
Thanks marder.
Could you try running visualgps with the log activated, then look at the log file for the message $GPGGA? If the 11th field, between the two Ms, is always 0 then it proves the point.
I remain very surprised at the lack of complaints about this, if it is such a common problem.
But why would people complain? Or even notice?
The height error is absolute, but in differential measurements, it still works well. In other words, if you have a height, and you walk up a hill, it will give you a higher height (most of the time, and within margin of error). And most people are not aware of their absolute altitude anyway. Lets face it, if you live in Moscow, and the device tells you you are at 200mtrs, why would you distrust it?
I only noticed because I live at sea-level (Holland). You only noticed because you live in an area with above average separation, and got annoyed with two devices giving you 2 different values. And marder probably scratched his head when encountering these "xxxx above sea" markers which you get when hicking in the mountains. He would not encounter such markers in the city he lives.
Face it, if you had not had you Mio, would you have noticed? Or be able to confirm it?
Of course, once we know, we think it is unacceptable. Thats human nature, myself included.
But there are other people who did see it. Searching for keywords geoid and gps shows this thread, and the program appears also to have a fixed geoid position.
Like I said before, did you try different radios? As this affects the functions of the GPS. I had this problem too but flashing to the latest radio cleared it right up, along with making the gps now lock on with a strong signal within 8 seconds. Going through the complicated route of coding things to fix it is a bit pointless when others have fixed it before you. I'm not saying it will definitely clear it up for you, but taking 20mins to try a few radios is probably worth your time.
Oh and a good way to tell if it's accurate or not, for anyone else wondering, is to check on google earth for the "elevation".
GPS height error
cybermaus, I expect you are right - people do not notice.
I certainly did notice, independently of the Mio, by comparing the heights marked beside the autoroute that I use with those displayed by the HTC.
But you are right in that without the experience of the Mio I might well have assumed that it was due to some inherent inaccuracy in the GPS system and not searched further (and not found the thread at http://www.gpspassion.com/forumsen/topic.asp?TOPIC_ID=10915 where this is all explained).
stuntdouble, thanks for the input. I assume that flashing new radios is trivial for you, but somewhat more traumatic for people like me, aware that a problem during the process can end with a dead phone. Could you perhaps tell me
1. Does it actually correct the problem i.e. does the NMEA message $GPGGA give a non-zero value in field 11?
2. Do I lose all my programs and data in the process
3. Which of these many radios do you recommend
4. Where do I find it/them
5. Are you sure it will work on my phone (which is apparently of Malaysian origin)?
6. What is the procedure?
Sorry for the interrogation but this is not as easy for me as it is for you.
For information I have:
ROM version 1.18.707.3 (23358) WWE
ROM date 12/10/08
Radio version 1.09.25.14
Protocol version 52.49a.25.26U
rpettipher said:
stuntdouble, thanks for the input. I assume that flashing new radios is trivial for you, but somewhat more traumatic for people like me, aware that a problem during the process can end with a dead phone. Could you perhaps tell me
1. Does it actually correct the problem i.e. does the NMEA message $GPGGA give a non-zero value in field 11?
2. Do I lose all my programs and data in the process
3. Which of these many radios do you recommend
4. Where do I find it/them
5. Are you sure it will work on my phone (which is apparently of Malaysian origin)?
6. What is the procedure?
Sorry for the interrogation but this is not as easy for me as it is for you.
Click to expand...
Click to collapse
1. Yes. All seemingly corrected.
2. No programs are touched as long as it's a successful flash. Radio is separate from the rest of the device's memory. Just backup your device with Sprite Backup or SPB Backup before you try it, in case you do need to do a hard reset. This way you can get your device back to exactly the way it was before.
3. The one in my sig fixed mine. However every device is different so you would need to find the best radio for your own device. I'd start with the latest and work backwards though if I were you.
4. Get them here.
5. If it doesn't work, it doesn't work. You can always re-flash your old radio if you wish. However I suggest you ask in the radio thread before trying, which radio would be best for your operator. There will be plenty of people who will know this and have tried it before you have I'm sure. The radio info is based on your operator and not on country of origin for the phone.
6. Easy procedure is in link above.
I'm not guaranteeing this will fix your problem, but it really is easy to do and well worth attempting as like I said it fixed it easily for me. It also increased battery life dramatically, and the faster gps fix like I mentioned before.
I understand that it may seem difficult on first read. I felt that way too when I first tried it. But it really is very simple and I was wondering what I was scared of after I tried it. Just follow the instructions in that thread carefully and there won't be any problems. If you use windows vista/7 then make sure you run as admin if you are flashing via the pc. Good luck.
Sorry guys.
I have followed most of the radio updates, and never noticed this being fixed. I have to admit, I never checked since I updated to 1.17 radio, so I checked just now, and it still reports 0 meters separation and at 43 meters altitude (at the coastline of Holland...) So for clarity, I logged out the NMEA messages, and all $GPGGA mssages give 43.5,M,0,M for field 9 through 12. On the latest 1.17 radio.
While theoretically possible they fix it in the radio, it still has not been done, not even at 1.17. I guess you either have the luck of living in a region where geoid and ellipsoid are very close to each other, and/or you are not aware of your true absolute altitude.
GPS height error
Thanks guys now I am confused.
I suppose we need to know what "seemingly corrected" means.
Has stuntdouble actually seen the NMEA messages with the correct data?
Rom update
I do not know about taking "20mins to try a few radios" - I have spent several times that amount just reading some of the information relating to flashing!!
But then I am a slow reader.
Following the links I eventually found what is apparently the 1.17 radio rom on a support page of the HTC site.
I am puzzled to see that it is described as for South Africa only, and concerned to see that it says it is only for ROM version less than or equal to 1.14.421.5. when my ROM is 1.18.707.3.
Should I be concerned and should I also be concerned about the caution when starting the program that it will destroy all the information on my phone?
Just being cautious, especially as I do not know what improvements if any I will see.
Hi,
i need a Tool to calculate the distance of two devices with an accuracy of about 1 meter by a distance of 0-3 meter.
GPS doesn't suite this needs, but i guess bluetooth signal-strength does.
I was looking up the android bluetooth api but can't find anything to read signal strength. Anyone any tips how to get on the strength of the bluetooth signal?
thanks, exec
Cool idea
That is a pretty cool idea. I'm not a developer but I like it.
Another way is to use sound along with a tcp/ip or bluetooth connection
1) keep track of each phone's clock (or difference between)
2) make the second phone chirp/beep and record
a)the time the second phone started the beep
b)the time the first phone heard the beep.
3) calculate the distance using the amount of time it took to hear the beep.
note: the speed of sound may differ slightly but should be within your accuracy range
see http://www.sengpielaudio.com/calculator-soundpath.htm for an example.
nice idea, i'll keep this in mind. But for the moment it doens't fit my needs, cause it can be a loud enviorment with a lot of phones where i have to find the nearest one
exec87 said:
nice idea, i'll keep this in mind. But for the moment it doens't fit my needs, cause it can be a loud enviorment with a lot of phones where i have to find the nearest one
Click to expand...
Click to collapse
A pure tone at an agreed upon frequency will be hard to miss. If you have the service installed on all the phones you can query each one in turn and then figure out which one is nearest.
do you know any example how to analyse the frequenze of the current recorded tone?
exec87 said:
do you know any example how to analyse the frequenze of the current recorded tone?
Click to expand...
Click to collapse
This looks promising
http://code.google.com/p/moonblink/wiki/Audalyzer
sry but if you want to measure distances of up to 3 metres with the help of sound speed, that wont work
sonic speed is 343m/s, that means it takes 0,002.9sec for one meter to pass.
or otherwise, it would pass the 3 meters in 0,008.7 sec for 3m
to compare it, a nexus one would do a clock cycle every 0,000.000.01 seconds, and in that time, the sound weave moves 0,000.000.343 metres.
So if you're optimistic and it takes "only" 100.000 to 500.000 cycles to sample the sound AND compare it to the clock, your diffrence of that two cases would be 3cm to 15cm, so you got a standard "uncorrectness" of about 12cm.
but thats if it takes 100.000 to 500.000 cyles, and it would be worse if it takes more time or if the clock is not 100% correct (this example is with a 100% exact clock)
if the clock is only correct for 1ms, you must add another 30cm of "uncorrectness"
arthofer said:
So if you're optimistic and it takes "only" 100.000 to 500.000 cycles to sample the sound AND compare it to the clock, your diffrence of that two cases would be 3cm to 15cm, so you got a standard "uncorrectness" of about 12cm.
but thats if it takes 100.000 to 500.000 cyles, and it would be worse if it takes more time or if the clock is not 100% correct (this example is with a 100% exact clock)
if the clock is only correct for 1ms, you must add another 30cm of "uncorrectness"
Click to expand...
Click to collapse
Dont think sampling and processing cpu-time matters so much as to make this method unusable.
a)The sample time does not matter. It will be:
system time when the recording started + time within the sample where the frequency is found (comparison is part of post-processing). The sample window can be fixed at 0.5 seconds (or less) as 343/2= 171.5m is huge.
The phone emitting the frequency can be triggered over wifi/radio and that will be very very quick (speed of light+message processing time)
b)the time taken for the comparison will not matter as its done after the event has occurred. (post-processing)
The 1ms clock problem can possibly be overcome by using System.nanoTime()
exec87 said:
Hi,
i need a Tool to calculate the distance of two devices with an accuracy of about 1 meter by a distance of 0-3 meter.
GPS doesn't suite this needs, but i guess bluetooth signal-strength does.
I was looking up the android bluetooth api but can't find anything to read signal strength. Anyone any tips how to get on the strength of the bluetooth signal?
thanks, exec
Click to expand...
Click to collapse
Maybe use a ruler?
Sorry that I can't stop myself doing this after reading your question
ok, to a more serious side, if bluetooth don't work, then maybe use wi-fi. don't know if they have the api for wi-fi to measure signal strength neither.
What if you had one phone act as a Wi-fi hot spot, then the other connect to it. Then someone write an app that will use GPS to determine the distance between the two. IDK, just a shot in the dark. I really dont have a lot of knowledge about that stuff.
You could use a PRF (pulse repitition frequency) but I have no idea what these would be for bluetooth or even the radios. Honestly I think using the GPS coordinates and distance equation would be the easiest.
Unfortunately our consumer gps's rarely go down to 1m, and that the max... And it will likely not work indoors
britoso is right... i'll keep the hint with wlan strength in mind, but atm i'm working at the audio idea... it's a little bit hard, and first tests show that an accuracy of 1-2 meters is possible... i'll reply if i'm done.
however i'm thankful for EVERY input
edit: i think i will give up... the delay of analyzing the sound is between 150ms and 250ms... and i can't see in code where this 100ms difference come from... i think i need a kind of realtime system to build this...
exec87 said:
britoso is right... i'll keep the hint with wlan strength in mind, but atm i'm working at the audio idea... it's a little bit hard, and first tests show that an accuracy of 1-2 meters is possible... i'll reply if i'm done.
Click to expand...
Click to collapse
however i'm thankful for EVERY input
exec87 said:
edit: i think i will give up... the delay of analyzing the sound is between 150ms and 250ms... and i can't see in code where this 100ms difference come from... i think i need a kind of realtime system to build this...
Click to expand...
Click to collapse
If you can PM me the code I can take a look.
I didn't want to start coding this because
a) I only have one phone
b) havent used the bluetooth API.
I'm comfortable using tcp/ip though
i don't know if this is impossible.. but i think its worth the try.. i'm horrible at development nor i have taken any advanced math courses... so heres the concept:
how about getting two people hold a phone facing each other.... they both have to hold the phone upright and straight...(using Spirit Leveler)
with one of the phones... the app takes a picture of the other phone... and asks you to point out the phone's height in the picture...
and given the real height of the phone (this should be a dropdown box for known phone types.. and custom if you want to use a credit card... or anything else u find) it should tell you the height..
possible?
oh and one more thing.. u can have the phone's screen facing the camera with white background and black DOT... if that helps to do live tracking of the phone's size...??
britoso said:
If you can PM me the code I can take a look.
I didn't want to start coding this because
a) I only have one phone
b) havent used the bluetooth API.
I'm comfortable using tcp/ip though
Click to expand...
Click to collapse
This is what i first thought of when i saw this thread. Why not establish an ad-hoc network and send over a series of pings, each one send over one packet of info from phone A to phone B. have phone B process the information and show its good then send it back to A and have it verify it also. Then based of this data(and experiments to see hwo long it takes to process the information. you the time from a-b-a to calculate the distance.
This is all hoping that the speed of travel of the packet is not to fast to calculate the distance lol.
Any results?
This is the exact answer I'm looking for, which method produce better accuracy, is it the sound (measuring time difference) or the signal strength test (measuring the RSSI)
I've been looking a various GPS apps and suspect that my comments in a previous point about Samsung mixing sensor and GPS data might be correct.
Most of the GPS apps that examine the NMEA string don't return any speed data that I can see. I am trying to write an app using the ADT/Eclipse to dump raw NMEA to file to see exactly what is there but as a C/Perl fan Eclipse and Java are a steep learning curve. Someone who is already well versed in Android developing could try something like this...
Would it be possible to take the NMEA string from the GPS, throw away the heading and speed elements and re-compute them from the lat/long data? This new NMEA string could then be passed to the OS as a mock location in the same way that the bluetooth GPS dongles work.
I would be very interested to see what behaviour this approach causes.
Any takers?
I think that should be a bounty request.
Anything to GPS will get a bounty from me anyway...
I've just gone from JM2 to JPA.
Before I would run "GPStracker light", which would keep the GPS busy. JM2 would randomly disable or enable the GPS and give stray values in between. But with 'GPStracker light' running it would stay active and behave a whole lot better.
Now, with JPA, "GPStracker light" restarts and stops tracking. So I was not able to check track quality. But in normal use, it seems to react pretty slowly, lagging reality more than JM2 did.
I've updated GPStracker Light, and will see what happens now.
Kep in mind that the GPS chip used does not output NMES data itself, but some halfway processed data. It does come over a UART, but the CPU of the phone has to do a lot of calculations to urn that into NMEA. Thus, I do not think reading NMEA directly will solve anything.
First noticed a problem using Google Sky Maps. I couldn't tilt phone to view above the horizon. I was on a 2.2 ROM, but I never tried it on a stock ROM. This position sensor error would effect any app that uses the phones position (pitch, roll, azimuth) as an input, for instance game control. It would manifest as not being able to turn or climb. It also effects horizontal/vertical screen switching.
What I know from testing:
A. Download Sensor Debug from market. The simple program lists the sensor values that are reported to programs: Azimuth, Pitch, Roll, as well as force sensed along X,Y and Z axis. If the system is working properly, values with the phone sitting still would read: Pitch 0, Roll 0, X and Y Forces = almost zero, Z (gravity)= -9.xx. Tilting the phone to the left or right, Roll goes +/- 90. When tilted toward the sky, pitch would smoothly increment from 0 to -90 when vertical, and -180 when upside down. My phone when sitting on the table will read (depending on calibration method): Pitch= 0 or -180, Roll =0, Z axis= either +9 or -9. Rolling the phone is sometimes limited to +/-30 degrees. Pitch increments in the proper direction, but is capped. If I start at 0 when flat, it stops at 90 degrees when vertical. If it starts at -180, it stops at -150.
B. Calibration settings appear to be stored in /data/system/ms3c_yamaha.cfg. Changes are real time. If deleted, it is recreated. Values vary greatly. Settings/display/horizontal calibrate effects the values. There is also a calibration utility available from terminal: su system/bin/sensorcalibutil_yamaha. The terminal method has been reported as more accurate.
C. The problem has persisted with full data wipes, factory resets and ODIN return to stock.
So, is anyone else seeing these kind of problems. Questions:
1. What kind of pitch/roll values do you see in Sensor Debug:
2. What are the values in your /data/system/ms3c_yamaha.cfg? and what kind of calibration did you do if any?
3. I want try going back to stock 18 again, but think my method is not complete. What is the most thorough method?
I used the method described in the "my gps fix for 2.2" thread: http://forum.xda-developers.com/showthread.php?t=869806. It uses Odin 1.3 and SPH-D700-DI18-8Gb-REL.tar.md5.
There's another "Return to Stock" thread http://forum.xda-developers.com/showthread.php?t=773032. It uses the same version of Odin and SPH-D700-DG27-8Gb-REL.tar, and maybe a different PIT. Not sure what a PIT file is.
It appears that the threads re ODIN for DK28 use a different version of ODIN and or PIT, or no PIT.
4. Is it possible that ODIN isn't writing part of the firmware? If I can verify the problem after a thorough return to stock, well maybe it is a hardware issue and I'll just go down to Sprint and get a new one!
Hey thanks for listening! So looking forward to fixing this issue and appreciate any and all help/comments. Thanks!
I've had the same exact problems that you're having. I've done the same things you've done to try and fix the problem but nothing works. I've really only noticed the problem in sky maps because I haven't played any games that required going above the horizon. Hopefully someone can figure out a fix for this because I'd really like to use sky maps again.
I used the link above, return to stock, last page of that thred. Odin3 ver 1.67, and DI 18 stock with no PIT. Sensor debug values are the same....
What are your sensor debug values? Maybe try the su calibrate if u can.
Went to Sprint store. Nominal debug values on an Epic and an Intrepid...
Not a tech store so walking 1 mi to the other one. I am resolveed that I have hardware issues, or at least issues that ODIN can't fix.
I don't have insurance, but it's only 3 months old...should be covered?
Make a big scene, ask for manager... they may try to refer you to sammy warranty... don't put up with it. But the 7 bux a month is def worth it...
I don't think that the problem is the hardware. Sky maps was working for me before flashing over to the froyo roms. I'm just hoping that once the official froyo is released, it'll be fixed with that.
Update of my journeys....
2 mi walk to the tech store. 45 min later, they say yes the accelerometers are faulty, you need a new phone. Don't know what they did, but the only two things not stock on the phone where Google Sky and Sensor Debug.
So great, I get a new phone! But wait.... "it'll be here in a week." But I don't live in San Francisco, so that does me no good. They say to talk to go to my local store in SC, or call CS to get it mailed. Evidently they won't swap with a retail phone.
CS is no help. Won't authorize a retail swap. Won't have replacement sent to residence or my local store. I'll try calling them tomorrow.
In the meantime, I'm going to ODIN 1.6.1 straight to SPH-D700-DK28-8g-rel.tar.md5 OFFICIAL with no PIT, one click root, and restore my Bonsai system and data. My previous 2.2 upgrades have all been via update zip from DI 18.
So I guess the question remains, does the phone have hardware issues, or did my 2.2 upgrade dork something up that ODIN can't fix. Seems like it will be a while till I can Google Sky....
You cannot use another person's accelerometer values. Each and every accelerometer is different and calibrating will give everyone different values.
To fix the accelerometer you can run the following command in a terminal emulator :
Code:
su
/system/bin/sensorcalibutil_yamaha
The problem is that something has changed from Eclair to Froyo that Samsung hasn't taken into consideration. The update from a DI18 stock to the OTA Froyo should work without a hitch.
Hopefully w/ the official Froyo update we will get a fix. Otherwise, we should confer w/ noobnl or the CMSGS team to figure out how they were able to resolve the issue.
I've used the utility numerous times. Agreed that individual accelerometers would be somewhat different, but I think the differences wouldn't be very large in the .cfg file. The utility is "fine" calibration.
My device has gross errors.... Z axis prior to running the utility is +9.xx instead of -9.xx, and lay flat pitch is -179. The utility helps a little, but pitch values are referenced wrong, and don't increment properly even after running it.
Obviously there are areas of the phone that don't get reset with ODIN return to stock (Phone remembers the time, account info, etc). Sprint Tech couldn't get the g-sensors working right either with what ever reset procedure they use. Either data is stored on a level ODIN can't reach, or it's hardware failure.
Im a complete noob so correct me if I am imagining this... I had the same problem and fllashed back from froyo. Did the su/system/bin/sensorcalibutil_yamaha fix and it worked. Started restoring all my stuff and the orientation started to dog again.
I messed around and tried changing my launchers. I was using ADW and switched back to TW and the response was much better. I changed to Launcherpro and it is a little slower but not as bad as ADW. Am I high? Please forgive my noobiness.
I have noticed the same problem. The D18 rom was fine and all the games worked good. I checked the horizontal calibration and the sensors seem fine but the games and sky map don't seem to register properly with 2.2. I'm waiting for the OTA to come out b4 I take the phone back for a swap.
I'm actually having the exact problems you all are having with the pitch sensor, ever since I moved to DK28. Right now it is annoying, but I am hoping it will be resolved when DL11 is released. If not, it looks like I'll have to call Sprint and have them get me a new phone, because some programs don't work correctly right now.
Sent from my SPH-D700 using XDA App
I noticed this problem while using maps, my compass seemed to have East and West swapped (but North and South were fine). I used the calibration tool in the Settings menu under "Display" (horizontal calibration), but I put the phone on the table upside down (hanging off the edge enough for the "calibrate" button to be in reach).
Not ony did this fix my compass, it seems to have improved the auto rotation response time dramatically
Sent from my SPH-D700 using XDA App
styles420 said:
I noticed this problem while using maps, my compass seemed to have East and West swapped (but North and South were fine). I used the calibration tool in the Settings menu under "Display" (horizontal calibration), but I put the phone on the table upside down (hanging off the edge enough for the "calibrate" button to be in reach).
Not ony did this fix my compass, it seems to have improved the auto rotation response time dramatically
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
Wow...that seemed to help a ton. The games are off, but I don't really play them anymore so no issue. Sky map actually works now. The auto rotation is much better also. Thanks.
Edit: This fix works. I also started my game prior to doing the fix paused it and did the calibration. The game works great now.
styles420 said:
I noticed this problem while using maps, my compass seemed to have East and West swapped (but North and South were fine). I used the calibration tool in the Settings menu under "Display" (horizontal calibration), but I put the phone on the table upside down (hanging off the edge enough for the "calibrate" button to be in reach).
Not ony did this fix my compass, it seems to have improved the auto rotation response time dramatically
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
Thanks! This seems to have fixed problem. I'm not exactly sure which part fixed it for me so I'll just go through what I did. I placed my phone face down and did the calibration in display settings, but then my phone wasn't switching to the correct orientation, so I rebooted my phone to see if that would help. It didn't. So I then did the terminal emulator calibration and now it's fixed. So, that makes me wonder if it has something to do with the calibration utility in display settings having some settings that are flipped around.
Woah... that worked. For whatever reason, it actually worked. Hmm...
Sent from my SPH-D700 using XDA App
Wow!
I actually tried the upside down trick once before with out success. Thought I had some results this time... then added another step. Voilla!
1. Working on a rooted froyo ROM. Upside down horizontal calibration from system/display/settings/display.
2. Reboot. (Not sure if that step is needed)
3. Connectbot su system/bin/sensorcalibutil_yamaha
At this point, sensor debug showed no success. Pitch and roll both limited to 30 deg.
4. Settings/display/autorotate. Uncheck.
Back in sensor debug, every thing checked out.
Anyone think it's still fixed if you enable autorotate?
Sent from my SPH-D700 using XDA App
I agree that the calibration in display settings seems to be the problem, sensorcalibutil works fine right-side-up. But sensorcalibutil didn't seem to fix the orientation lag, so it's possible that the display settings' calibration is correct, the internal compass I installed upside down, and sensorcalibutil has been modified to compensate... but I doubt it, the hardware should work no matter what the orientation, so a software problem in the settings' calibration is more likely the cause
Sent from my SPH-D700 using XDA App
I've tried everything in this thread and I still can't get google sky maps to tilt up, above the horizon. Anyone word on EB13 resolving this particular issue?
no matter what i do, pitch is never a positive value in sensordebug..
same with sky maps. only other problem i'm having after calibration with the exception of an occasional compass jitter
I also have a problem with Sky Maps.. Pointing up will not register.