Maths function question

[CMW]

Hi r!co. I have done the donkey work regarding how raw GPS data from the M800 CAN BUS should be recombined. (Well, a talented friend made a software app to check it out....).

In i2 you can see raw data and the two channels for each of Latitude and Longitude actually combined.

Below are two samples, one raw data from the ecu as two 16 bit channels, the other the GPS coordinate in degrees after the software has done the maths wizardry

########################.

ECU output: GPS Latitude HW : 8015
GPS Latitude LW : -13983

Maths gives : Coordinate 52.8870988 degrees latitude

########################

ECU output : GPS Longitude HW : -364
GPS Longitude LW : 14387

Maths gives : Coordinate -2.6401195 degrees longitude

####################################

This is how he achieved this

:
8015*2^16 (shift left 16 bits)
+ -13983 (add on the second word)
/ 10^7 (7 decimal place fixed point)
=52.5

The same as Motec's i2 gets when converted to degrees, minutes and seconds.
The first figure is given as a decimal point from 10, rather than minutes and seconds. The 0.5322 etc has to be divided by 0.6 to convert it to minutes & seconds.


and

-364*2^16 (shift left 16 bits)
+ 14387 (add on the second word)
/ 10^7 (7 decimal place fixed point)
=-2.384

Again the same.

It's putting together the 16-bit words. It looks like both words are 2's complement - it doesn't work if you assume it is two halves of a 32-bit 2's complement word.

##########################################

Can you create a suitable maths "thing" to do this and convert to degrees, minutes and seconds as the actual Latitude and Longitude channels please? It's certainly well outside my comfort zone! Thanks.

[CMW]

I have found an anomaly between what i2 is processing and what GDA is seeing from the CAN BUS

Example:

Motec GDA
GPS LONG HW -364 65172
GPS LONG LW 14386 14386
GPS LAT HW 8015 8015
GPS LAT LW -13983 51553

Now, subtract 65536 from the numbers GDA does not agree with i2 on, and the numbers agree. Why's that then, whwn they do tally on the other data?

Same with the GPS Time, allowing for a tad of time shift reading the two cursor V time lines in the two apps:

Motec GDA
GPS TIME HW 1614 1614
GPS TIME LW -10040 55096

55096 minus 65536 = -10440 which, allowing for tiny time shift reading the graphs is OK.

Not sure why the data is in differing formats, but the maths could sort this, couldn't it?

I also had a reply overnight from the horse's mouth at Motec, which was:

####################

You just need to place the high word to the left of the Low word, without
any multiplication, division or anything.

You can then put the decimal place at the 7th number in from the right.

Example:

The GPS Lat and GPS Long are just split in 2, nothing more challenging that
that.

GPS LON HW is the High word component.
GPS LON LW is the Low Word component.

Eg
144.9688203
Is
HW is 0101011001101000

LW is 0111110010001011

Put them together


01010110011010000111110010001011
= 1449688203

Divide by
10000000

Gives you

144.9688203

This is the GPS Long value.



Jamie Augustine

MoTeC Research Centre

#########################################

[R!C0]

Hi, Sorry for the delay in response, have been having a quick hols.

From what i can see (we are starting to get out of my confirm zone aswell! I will confirm with the office on tuesday) it requires the combine function as I previously suggested then a divide by 10000000. Which would look like:

Code: Select all

combine('GPS Lat HW', 'GPS Lat LW') / 10000000

Have you tried this?

[CMW]

I have tried that, but it immediately barfs with this error, as soon as the script is written:

(0): Invalid number of arguments for function: 'combine'. 3 expected.

If you just carry on and ignore it there's an exclamation mark by the new channel created, which I called GPS LAT

I am going to Rockingham on Monday, I'll let the logger run and see if we can work out the maths to read the data next week, hope you had a good holiday, all the best r!co.

[CMW]

It seems to like this better:

combine('GPS LAT HW', 'GPS LAT LW', 'GPS LAT')/10000000

But now shows a Recursive channel reference [GPS LAT] ion the channels list whwn you click on the yellow triangle with the exclamation mark in it. In the maths editor I put GPS LAT in the name box, with degrees as the units.

[R!C0]

sorry that should have been:

Code: Select all

combine16('GPS Lat HW','GPS Lat LW') / 10000000

[CMW]

I managed to trial and error my way to that, myself (honest....) It hangs up on negative values though and gives impossible longitude values. Getting very close to a result though!

http://www.gatesgarth.com/GDA/gps_logging.png

[R!C0]

if possible, could you send that data.

Thanks

[CMW]

What I have done is zipped up the Motec log, the GDA log, the setup file, and the GDA maths file for you. That way there's a direct comparison. Both logs are from the same session at Rockingham yesterday. I have checked and the Motec GPS is spot on, and draws perfect track maps, so the GPS channels are accurate there. I am 99.9% confident the GDA maths for latitude is spot on, that for longitude has a major issue unless Rockingham is in Antartica.... The Motec log will open in i2 Standard.

Someone helped me with the maths functions, please don't assume it's my ow work!!

http://www.gatesgarth.com/GDA/data.zip

Hope this has what you need r!ico, and thanks.

[CMW]

BTW, the DA99-L2 does not seem to be reading Satellites in View, nor Satellite Quality, I was going to add these to the maths to try and create a work around for poor reception or drop-outs. The data should definitely be there on the CAN

[R!C0]

So looking at your maths, I think you may have gone a bit to far!

Have a look at the project that I have attached. Essentially doing the maths as suggested previously works fine.

When creating the track, you need to make sure you do not include the duff data at the beginning, so in the source section of track setup, select "Selection" or "Fixed range" of a lap or two from the middle. You could also do some smoothing of the data, to make the track even better. See the "Generating a track map" section of the GDA manual for this.

You also need a distance channel setup. You can get GDA to get this from a speed. As it looks like you are not using Ground Speed, you can use GPS speed. Go to: Data > Distance channel setup. In the second box, add GPS Speed and remove all others. HOWEVER, it looks like your GPS Speed is not scaled correctly, so this is currently throwing of the distance calculations by a lot. Check your CAN setup in the ADL thing to check for any mulitpliers etc.

Pretty much there!

[CMW]

Thanks for that. Have you tried exporting that data to Google Earth though? Because the coordinates have no signing the results are (very) wrong. This is where the extra complication came in, stripping the number from in front of the decimal places, and correcting whether it's a negative coordinate. I an tryinbg to find the right multipliers for the GPS speed, will let you know when I have sorted that! Cheers.

[CMW]

GPS Speed sorted, and reading correctly. These rather large ( ) functions result in seemingly correct data with negative values being created for lat and lon, but the track maps GDA draws are like modern art.
Functions used:

GPS LAT COMBINE = ((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+'GPS LAT LW')/10000000
GPS LON COMBINE = ((if('GPS LON HW'>32767,('GPS LON HW'-65536),'GPS LON HW')*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'))))


http://www.gatesgarth.com/GDA/wow.png
http://www.gatesgarth.com/GDA/google.png

[R!C0]

What are you trying to do with these functions?

As I have stated before a straight forward combine16 draws the correct track map. So what you are doing with those can not be right.

Yes just doing the combine16 does give results that are about 20 miles off in position, but what you are doing seems to being doing something very odd, and not fixing that small offset.

[R!C0]

It looks like the HW of both could be missing a byte.

Is there anyway you can look at the HW and LW in Motec, you could then compare this to the raw values in GDA. From that you could tell whether the maths is wrong or the data is not being sent properly.