Enhancing GPS height accuracy in ECEF XYZ converted data - Page 1
Forum section: electronics / projects

author: eneuro
author_rank: Super Contributor
timestamp: May 19, 2015, 11:45:20 am
content: Hello,Working now with GPS NMEA log files converted to ECEF XYZ (fixed earth centered cartesian) registered in vehicle driving 50km/h-70km/h and as expected not great height accuracyThere are four ~4km tracks (two of them taken today within a few hours delay) and height values (ECEF XYZ in local WGS-84 ellipsoide view where y axis is S-N direction and x axis is W-E) as we can see looks quite noisy, while its latitude/longitude data is fine and nice fits into road map.I've found some hints howto postprocess this noisy GPS data there:Path Estimation from GPS Tracks, however there is not too much about improoving GPS height accuracy.I'll try register more GPS points on this well known a few km road from home to city centre which is in my interest first, while I'd like to estimate energy needs for different vehicles types (including my HPEV with flywheel battery) and recreate it in virtual reality for visualisation and simulation purposes to optimize vehicle design.It is important to have decent accuracy altitude data-height changes are needed to estimate gravitational energy on hills slopes.Maybe some GIS databased could be usefull or someone knows good source of terrain elevation based on its ECEF XYZ data or latitude/longitude values ?There are some links, but I wouldn't land on the bottom of the river, when road crosses river and in Google Earth sometimes elevation data shows bad altitudehttp://vterrain.org/Elevation/global.htmlMaybe better GPS equipment could help read higher quality altitude GPS data-aviation GPS could help?

author: eneuro
author_rank: Super Contributor
timestamp: May 19, 2015, 07:01:05 pm
content: Made another experiment with my solar powered GPS.Created regular triangle 9 m base and registered ~1000 GPS points while not moveing just sitting on each of three edges of this traingle in open space yard.What is interesting, two different sets of data in each triangle corner created...not noisy clund of points around corner, but...something which looks like discrete values of latitude/longitude3D view of those 9m size triangle corners shows also that there is no cloud of noisy latitude/longitude points, since in GPS NMEA log file those GPS locations repeats and leads to discrete latitude/longitude values, so it looks like in the set of ~1000 registered GPS fixed positions they have only a few discrete values?I'lll try tomorow make another set of readings in those triangle corners, while altitude doesn't change too much and in all ~3700 registered triangle corners GPS data altitude converted to absolute height in ECEF XYZ projection to triangle center WGS-84 ellipsoid changes in the range of ~10m only-which is not so bad?Note: those corners are more or less on the same height of course +/-1m

author: suicidaleggroll
author_rank: Super Contributor
timestamp: May 19, 2015, 07:13:27 pm
content: Quote from: eneuro on May 19, 2015, 07:01:05 pmYou're seeing the resolution in the NMEA format code. If it's spitting out positions with a resolution of 0.1m, then you're going to see discrete points with 0.1m spacing.If you want better accuracy, use a better GPS, better antenna, better antenna installation, or any combination therein. If your GPS gave you raw pseudoranges and phases there would be a lot more you could do, but without that you're pretty much stuck.

author: Niklas
author_rank: Frequent Contributor
timestamp: May 19, 2015, 09:33:03 pm
content: Do you have any kind of alignment of the antenna to keep it horizontal at all times? Are there any high walls along the road? The signal can bounce on walls and the reflected signal will travel a little bit longer than the signal from straight above.

author: eneuro
author_rank: Super Contributor
timestamp: May 19, 2015, 09:59:10 pm
content: Quote from: suicidaleggroll on May 19, 2015, 07:13:27 pmYep, however have no idea, why there is only24lat/lon combinations in 1300 samples GPS data in one of the triangle corners?It is 56 when added altitude data which changes in multiply of 0.1m .Lat/lon changes projected on local ground on a map with North on top are close to 0.1m too, and last 4 digit changes in lat/lon GPS NMEA data (DDMM.MMMM) are discrete values, but why such distribution that in more than 1000 samples there is only 24 changes in lat/lon on last decimal positions ?Quote from: Niklas on May 19, 2015, 09:33:03 pmThere is no external antena for the moment-this wireless GPS has builtin and between sets of data in the case of experiment with 9m size triangle corners probably this GPS unit was randomly rotated around height axis-I have no idea what kind of antena is inside and how it is mounted in this GPS unit.I expected more noisy output in fixed position for a tens of minutes, but it looks like I should leave it for much longer time (hours, days?) to see if more discrete lat/lon combinations will be visible in output GPS NMEA data.Anyway it is strange noise distribution or missing something and GPS NMEA lat/lon format DDMM.MMMM leads to such strange output patterns not changing too much...ONLY 24 lat & lon combinations (56 lat & lon & alt sorted and taken unique values) in 1300 sample set-I didn't expected such distribution

author: suicidaleggroll
author_rank: Super Contributor
timestamp: May 19, 2015, 10:05:55 pm
content: It probably has quite a bit of filtering/averaging built in to cut down on noise, so what you're left with is multipath and ionospheric errors, which change on the order of minutes/hours, not "number of samples".

author: Mechatrommer
author_rank: Super Contributor
timestamp: May 20, 2015, 02:32:12 am
content: Quote from: eneuro on May 19, 2015, 11:45:20 ami guess gps is not about elevation but i could be wrong... yesterday i just got my ublox neo-6m gps with bmp085 barometer module but dont think to play with them soon. if you have a sample arduino code to read the gps data i will appreciate and maybe make a quick slap to see how it works. you maybe want to fuse (kalman or weighted average filter) the altitude data using one of this...http://www.ebay.com.my/itm/Replace-BMP085-5Pin-3-3V-5V-BMP180-Digital-Barometric-Pressure-Sensor-Module-/201125045279?pt=LH_DefaultDomain_0&hash=item2ed3fca41fbmp180, 0.25m resolution better and cheaper than my my bmp085 0.5m resolution. i got the bmp085 because i'm buying from a single seller to save shipping cost and hassles. my key item from the seller was the 6dof imu mpu-6050 3axis accel 3axis gyro module... the bmp085 link is here, but the bmp180 above is better and cheaper, not sure though how they both perform as i just got the bmp085 yesterday...http://www.ebay.com.my/itm/NEW-BMP085-Barometric-Digital-Pressure-Sensor-Module-Board-For-Arduino-/290904869255?pt=LH_DefaultDomain_0&hash=item43bb480987

author: eneuro
author_rank: Super Contributor
timestamp: May 20, 2015, 07:20:26 am
content: Quote from: Mechatrommer on May 20, 2015, 02:32:12 amMessing with this bluetooth device is only some kind of feasibility study to better understand GPS internals andublox neo-6mwith I2C is what I'm interested in final DIY design with GPS and MPU-6050.Sincebmp180is quite cheap it is worth to test it.Anyway, it could be interesting to try use MPU-6050 with GPS NMEA sentenceVTG - Vector track an Speed over the Groundand using this field with ground speedCode:010.2,K Ground speed, Kilometers per hourwith hills slope data obtained from 3axis accelerator in MPU-6050 try to estimate height changes, however for absolute height information probably fussing GPS altitude with barometer module could give better height information in unknown terrain.Probably will try use MPU-6050 with RTC clock synchronized with GPS timestamp data and log GPS NMEA road track data with raw MPU-readings to postprocess this data later and calculate slopes based on MPU-6050 acceleration changes, which in the case of slow driving vehicle at close to constant speed 25km-50kmh, even on road turns there shouldn't be too much acceleration components, so for road maping it should be fineThe only thing is that probably GPS NMEA VTG data will output vehicle speed in surface perpendicular to local ground WGS-84 ellipsoide normal, so for bigger hills with huge up/down slopes we'll need take this into account to get something closer to real vehicle speed at given road slopeUpdate: Ups, now realized than while moving at quite low ~constant speed probably speed information will not be needed to estimate slope from 3axis accelaration components assuming known gravity acceleration component-need to review my derived equations, but for something else than low speed road mapping knowledge of vehicle speed changes will be needed while we need to know accelearation component in direction of vehicle movement...For the moment thinking about GPS antena position, I've some idea howto keep GPS unit at the same position in space during GPS data loging in vehicle-mount it on some kind of machanical gyroscope and keep in the same orientation in space during recording and see if I'll get more consistent GPS altitude changes better reflecting road slopes

author: eneuro
author_rank: Super Contributor
timestamp: May 21, 2015, 07:37:20 pm
content: Ok, registered a few more GPS logs on my often used a few km trip to city center and tennis court , but a few times a day, so significant number of km and fuel to safe-much more than electricity bills, so this project will have much faster ROI than solar PVs with quite long investment return...While it looks like horizontal position can be determined and aproximated with decent accuracy within meters, I think it is time make a try to aproximate also altitude changes while there is some hope GPS altitude data is shifted and while i do not need exact absolute values of altitude but its changes to estimate hills slopes and gravity energy changes, maybe it will work for this particular well known road