 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : GPS averaging
| Author | Message | ||||
vk4tec Senior Member  Joined: 24/03/2012 Location: AustraliaPosts: 239 |
Hello Do you think that I could use MMBasic to do GPS averaging ? Would it come down to "how big a number" MMBasic can handle ? I would like to average out a set of GPS co-ords I am around -27 S 153 E - Andrew- Andrew Rich VK4TEC www.tech-software.net |
||||
| vk4tec Senior Member Joined: 24/03/2012 Location: AustraliaPosts: 239 |
How do I make a string into a number ? I have "27304.909" say I would like to turn that from a string into a number lat$ = "27304.909" lat = < number > - Andrew - Andrew Rich VK4TEC www.tech-software.net |
||||
| JohnS Guru  Joined: 18/11/2011 Location: United KingdomPosts: 3801 |
Try VAL(str) returns a number. As soon as you have decimal points (well, fractional i.e. non whole numbers), you will have an approximate value. This is inherent to any fixed length system - you'll have seen the kind of thing with a calculator and you understand I hope that in ordinary use things like a third (1/3) can't be written down fully in a fixed number of digits without sticking to the division symbol or that trick where you put a dot to mean recurring. Computers, like calculators, don't have these tricks. So, if you can use whole numbers (integers) then do. It can help to scale by say 1000. Only divide by the 1000 when you have to. Otherwise, live with the inaccuracies. Even with integers there is a limited range where they are accurate, because of the fixed length (in this case I think a floating point number is 4 bytes). It's all a compromise but usually can be worked around. BTW, generally when printed out some rounding is done so you don't quite see exactly what a number is stored as. Can really be confusing till you think it through! John |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Multiplying longitudes and latitudes is mostly done by 100000 to keep enough accuracy, but only when you need integers. Another way is to use a projection. Mercator is popular. If you want/need the math for that, just ask. :) Remember that all numbers in MMBasic are floats so it is unneccesary to convert them into ints because when you do that then MMBasic stores that int as a float. Just add them and then divide to get an average. Also a thing to check is that sometimes GPS gives a wrong position. Often this is a big difference in one of the numbers. Filtering those out is not an easy task as many values have to be checked and stored to get it accurate. In my tracking application i sample only per minute and calculate average speed and distance. If one of those is extraordinary big i ignore that position and wait for the next minute update. Sampling faster will make the average speed and distance more 'jumpy' and can lead to filter to much or to little. It goes good with sampling rates up to 2-3 per minute. Microblocks. Build with logic. |
||||
| TinkersALot Regular Member  Joined: 20/11/2012 Location: United StatesPosts: 72 |
Did I see a set of big integers routines in an MMBASIC library? |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6098 |
The big int routines are an example of doing the maths using strings. It means you can work with up to 255 digits but I think the routines are way to slow for Andrew's purposes. (I am allowed to be critical because they are my routines) MMBasic works in 32bit floating point so the big problem will be the limitation of 7 and a bit significant figures. There are ways to limit this problem but it depends on the precision required and whether a running average is needed. Jim VK7JH MMedit MMBasic Help |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3801 |
Umm, I think that's misleading to the point of almost being wrong isn't it? The overall storage is "floating point" but within the data (32 bits total) an integer will be stored exactly if it is within certain limits. Non-integers will generally NOT be stored exactly. My point is that if you want exactness then you'd be wise only to use the mentioned integer range and if need be scale the number you really wanted to store so that it becomes an appropriate integer. John |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Just a little more inof what is underneath it all for the OP. A float in C and also in MMBasic because MMBasic is written in C has 23 bits mantissa (with hidden bit it is 24 bits), 8 bits exponent and bit for sign. The precision is about 7 digits. The exponent is from -126 to +127. All just standard IEEE 754 floating point stuff. Sure integers can be stored 'exactly' if it stays within those bounds. But as this topic is about longitudes and latitudes this will not be the case as the bounds are to narrow. As longitude is normally in degrees, minutes and seconds (alternative way to store but difficult to manage/calculate with) it is in most gps equipment already translated to a WGS84 projection which is one of the most common. A WGS84 projection can have many digits for precision, you have no choice then to drop digits as only 7 digits can be stored without loss in a float. With a 32 bit integer you would have the possibility of having 10 digits precision but with mmbasic that is an impossibility. Even then you run into extra manipulations which again will not help the calculation, in fact they can make them even less precise because an int will round a number in all cases and that would not always be the case with a float. A float can have a bigger or smaller exponent to get maximum precision with 7 digits. When you start adding these values (longitudes/latitudes) you will loose more precision as a float is already not that precise for a single location. A 'running' average of two positions could be acceptable it all depends on how precise you want it to be. When MMBasic is used it has no practical use to change them into integers because that is an extra operation which has no benefit at all, the precision stays the same. When you use val() to parse the string the result is a float. If you change that into an int you first need to remove the decimal point by multiplying the value and then take the integer value of that which will be stored as a float. That is wasting cpu time for no benefit at all. This is also the case with javascript and alike languages, so it is not really a practical problem for not scientific work. Microblocks. Build with logic. |
||||
| cwilt Senior Member Joined: 20/03/2012 Location: United StatesPosts: 147 |
I will make a suggestion that may not be popular here. Look at the uM-FPU64. Its a 64bit floating point processor that will decode NEMA, do the math at the needed precision, and many other things. FPU64 |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6098 |
I like it! I don't have a use for one at the moment but I am very tempted to get one to have a play with, just in case a use appears. Jim VK7JH MMedit MMBasic Help |
||||
| cwilt Senior Member Joined: 20/03/2012 Location: United StatesPosts: 147 |
The application notes have some good examples. GPS Calculate great circle distance. Time and date. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3801 |
Just thought I should point out that I did not suggest to use the INT function and that as far as I can see what I wrote was correct. To the extent anyone thought I meant to use INT please realise I did not mean that. The issue of exactness, and the range over which it applies, is separate. If the natural range of one numeric value in MMBasic is not adequate for the specific use then clearly that requires some extra effort but the issues do not change - life just gets tougher. The best solution may be the big integer library (or it may not be). John (who knows IEEE 754 etc) |
||||
 Print this page |
