Maths function question
Moderators:R!C0, JonMan, RickS
Morning r!co. I think I have sorted it, although I will check out the missing byte thing. What I have found is I can see some LW fields with negative numbers. The equations need the LW to be unsigned (i.e. always positive numbers). I have a few different ways of fixing this:
1> Change the logger settings so that all of the LW fields are set to unsigned.
2> Change the "2-step" approach such that it doesn't matter if the number is signed or not:
GPS LAT COMBINE = ((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+if('GPS LAT LW'<0,('GPS LAT LW'+65536),'GPS LAT LW'))/10000000
GPS LON COMBINE = ((if('GPS LON HW'>32767,('GPS LON HW'-65536),'GPS LON HW')*65536)+if('GPS LON LW'<0,('GPS LON LW'+65536),'GPS LON LW'))/10000000
GPS LAT = if(('GPS LAT COMBINE'>0.0),((('GPS LAT COMBINE'-floor('GPS LAT COMBINE'))/0.6)+(floor('GPS LAT COMBINE'))),((('GPS LAT COMBINE'-ceil('GPS LAT COMBINE'))/0.6)+(ceil('GPS LAT COMBINE'))))
GPS LON = if(('GPS LON COMBINE'>0.0),((('GPS LON COMBINE'-floor('GPS LON COMBINE'))/0.6)+(floor('GPS LON COMBINE'))),((('GPS LON COMBINE'-ceil('GPS LON COMBINE'))/0.6)+(ceil('GPS LON COMBINE'))))
These functions now work correctly and produce the map below. I wouldn't mind a few more tips on smoothing the data, even an example maths function. WITHOUT these functions I just cannot see how merely combining the 16 bit streams will allow accurate map placement in Google Earth, as signing errors can put the albeit accurately drawn track map way off in relation to real world coordinates.
The raw data does seem to match the Motec, but I intend to try removing signing at the logger for the LW figures.
Is there any advantage adding the maths functions to the logger set up, rather than running them in GDA?
I also need to see why no data for GPS sats Used and GPS Quality appear to be being logged at all, and to fix the GPS Speed channel to have correct scaling in the logger, rather than using maths in GDA.
Thanks for your continued support!
http://www.gatesgarth.com/GDA/rockgda.kmz
1> Change the logger settings so that all of the LW fields are set to unsigned.
2> Change the "2-step" approach such that it doesn't matter if the number is signed or not:
GPS LAT COMBINE = ((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+if('GPS LAT LW'<0,('GPS LAT LW'+65536),'GPS LAT LW'))/10000000
GPS LON COMBINE = ((if('GPS LON HW'>32767,('GPS LON HW'-65536),'GPS LON HW')*65536)+if('GPS LON LW'<0,('GPS LON LW'+65536),'GPS LON LW'))/10000000
GPS LAT = if(('GPS LAT COMBINE'>0.0),((('GPS LAT COMBINE'-floor('GPS LAT COMBINE'))/0.6)+(floor('GPS LAT COMBINE'))),((('GPS LAT COMBINE'-ceil('GPS LAT COMBINE'))/0.6)+(ceil('GPS LAT COMBINE'))))
GPS LON = if(('GPS LON COMBINE'>0.0),((('GPS LON COMBINE'-floor('GPS LON COMBINE'))/0.6)+(floor('GPS LON COMBINE'))),((('GPS LON COMBINE'-ceil('GPS LON COMBINE'))/0.6)+(ceil('GPS LON COMBINE'))))
These functions now work correctly and produce the map below. I wouldn't mind a few more tips on smoothing the data, even an example maths function. WITHOUT these functions I just cannot see how merely combining the 16 bit streams will allow accurate map placement in Google Earth, as signing errors can put the albeit accurately drawn track map way off in relation to real world coordinates.
The raw data does seem to match the Motec, but I intend to try removing signing at the logger for the LW figures.
Is there any advantage adding the maths functions to the logger set up, rather than running them in GDA?
I also need to see why no data for GPS sats Used and GPS Quality appear to be being logged at all, and to fix the GPS Speed channel to have correct scaling in the logger, rather than using maths in GDA.
Thanks for your continued support!
http://www.gatesgarth.com/GDA/rockgda.kmz
Re: Maths function question
Good to see its accurate now. Yes you should change the setup for unsigned. The CAN output info in Motec should have displayed this.
IF the data provided is correct, and there is no other scaling to do, then what Motec have said (which i believe was: "The GPS Lat and GPS Long are just split in 2, nothing more challenging that
that.") should apply, which means that using just the combine16 function with a divide by 10000000 should work.
For all the other outstanding issues, i would again check your setup and the motec output.
IF the data provided is correct, and there is no other scaling to do, then what Motec have said (which i believe was: "The GPS Lat and GPS Long are just split in 2, nothing more challenging that
that.") should apply, which means that using just the combine16 function with a divide by 10000000 should work.
For all the other outstanding issues, i would again check your setup and the motec output.
Re: Maths function question
Can anyone suggest a suitable real world filter to remove this sort of effect please:
http://www.gatesgarth.com/GDA/garden.kmz
Thanks, with some smoothing the data seems pretty spot on now. In i2 this is a smooth line when I turned the car around in the back garden, and reversed back again, not zig zag. I assume they do some internal smoothing.I've read the help file but don't know what sort of figures to try as a starting point, Thanks.
http://www.gatesgarth.com/GDA/garden.kmz
Thanks, with some smoothing the data seems pretty spot on now. In i2 this is a smooth line when I turned the car around in the back garden, and reversed back again, not zig zag. I assume they do some internal smoothing.I've read the help file but don't know what sort of figures to try as a starting point, Thanks.
Re: Maths function question
Try using the maths function filter_avg, this is a fairly basic but but works well with the rockingham data. There are a number of filter options available with more configurability.