Maths function question

[Chris Wilson]

It does matter! The function if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW') within the COMBINE channels accounts for the fact that the high word has been logged as an unsigned rather than a signed.

 

If you wanted to change it to be correct, you could set the high word to be signed, the low word to be unsigned and then change the COMBINE channels to be along the lines of:

 

GPS LAT COMBINE = ((('GPS LAT HW'*65536)+'GPS LAT LW')/10000000)

 

With the channels set up this way, the HW should show the same value in GDA and i2. The LW will show the same value if it is 32767 or lower, otherwise it will be negative in i2 and positive in GDA. This is not a problem however.

 

 

Right. So do I need to set up the logger to have those channels UNSIGNED, or can it be corrected in the maths functions? I have to clear the log in the ecu for Monday, I can do another real time test comparing the logger to the Motec ecu internal logging, with the signing changed if necessary.

[Andy Blyth]

Right. So do I need to set up the logger to have those channels UNSIGNED, or can it be corrected in the maths functions?

 

You can leave it as-is if you want. The if() function is performing the necessary correction.

[Andy Blyth]

For some reason, the check to see if the COMBINE channel is positive is not working correctly. if(('GPS LAT COMBINE'>=0),... is being evaluated as false for a GPS LAT COMBINE value of 52.5322762, which is clearly incorrect.

 

Could you try using just "greater than" rather than "greater than or equal to" in the GPS LAT channel? I.e.

 

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'))))

[Chris Wilson]

That seems a lot better Andy! Look at this!

[Andy Blyth]

Getting very close now!

 

The answer given for the COMBINE channel is slightly out (52.5322762 vs. 52.5322746). I think it's worth trying a slightly different method of generating it as I'm not 100% confident I know what's going on behind the scenes of the combine16() function. Try:

 

GPS LAT COMBINE = ((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+'GPS LAT LW')/10000000

[Wez]

[Chris Wilson]

I tried changing the signing in the logger, and will posy a screen shot later, but something odd has happened since retrieving data from the Motec and the logger today. If you export either the Motec log, or the GEMS log to Google Earth you end up with it showing 96% of Australia, random zig zag lines and it not homing in to any place in particular, yet the LAT and LON coordinates look fine... I will try the new functions on the older data now, cheers Andy ! The signal does drift a bit, the receiver was staitionary on a steel ledge on the workshop door, yet coordinates move about, they do say to ideally let it warm up for a while, plus Motec have some odd correction / time factor, I'll see if I can find it.

[Chris Wilson]

Here's the shift stuff:

[Chris Wilson]

With latest COMBINE functions for LAT and LON, I spotted a typo LAW instead of LAT, have edited it in the actual maths.

[Chris Wilson]

 

Yep, straightforward my *rse

[Andy Blyth]

With latest COMBINE functions for LAT and LON, I spotted a typo LAW instead of LAT, have edited it in the actual maths.

 

Oops, good spot.

 

You're still getting an answer that's slightly off. If you stick the following into a calculator:

 

((8015*65536)+51705)/10000000

 

You should get 52.5322745 but GPS LAT COMBINE is giving 52.5322762. I guess we're just hitting a precision limitation in the internal workings of GDA.

 

The position difference seems to be only a few yards. Google maps says the difference in the two coordinates puts you on the opposite side of the road:

 

 

I guess only you can decide if it's suitable for your application.

[Chris Wilson]

Even the Motec with its corrections shows some discrepancies, I didn't REALLY drive through the trees, lap after lap, so there's a shift, yet most of the rest of the circuit is correct.

[Chris Wilson]

Thanks Andy / Scott, after testing at Rockingham and grabbing plenty of data I can now say:

 

Post #15 gives perfect latitude conversions, but the longitude is not going negative when required, so track maps are on exactly the right latitude, but skewed east when the number should be a negative one. We are so close, I have racked my brains trying to see what the longitude is wrong, but sadly it's beyond me guys. Gems themselves said just using

 

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

 

works, well it does, until negative numbers come into play.... So they have now gone quiet

[Andy Blyth]

Thanks Andy / Scott, after testing at Rockingham and grabbing plenty of data I can now say:

 

Post #15 gives perfect latitude conversions, but the longitude is not going negative when required, so track maps are on exactly the right latitude, but skewed east when the number should be a negative one. We are so close, I have racked my brains trying to see what the longitude is wrong, but sadly it's beyond me guys. Gems themselves said just using

 

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

 

works, well it does, until negative numbers come into play.... So they have now gone quiet

 

What about the conversion in post #53 and #55? i.e.

 

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'))))

[Chris Wilson]

They give exactly the same results (answers) as the #15 functions Andy. Lat is spot on, lon is a positive figure and should be a negative one, and a different figure, too. Beggared if I know why though....

[Andy Blyth]

Have you got a few examples where the longitude is wrong? Ideally with the expected longitide, the high and low words and the longitude that you are getting.

[Chris Wilson]

I don't think the radians issue below has anything to do with, although the text is a bit ambiguous. I think GDA does this INTERNALLY.... I have to go out now, to meet Pete from on here, so God knows what state I'll be in later Cheers

[Chris Wilson]

Heres an example of the LON error.

 

In GEMS

 

LON HW -60

LON LW 3844

GPS LON 0.0119473

 

In Motec

 

LON HW -60

LON LW 3612

GPS LON -0.6547579

 

OK, the figures for LON LW are slightly different, but it's all but impossible with the scaling on the graphs to get the two to tie up precisely, IYSWIM?

 

 

Thanks. Latitude seems to work fine.

Function being used in GEMS for both LAT and LON is:

 

(((combine16(if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW'),'GPS LAT LW')/10000000)-(floor(combine16(if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW'),'GPS LAT LW')/10000000)))/0.6)+(floor(combine16(if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW'),'GPS LAT LW')/10000000))

[Andy Blyth]

Aha! We've regressed back to before the point where we added the ceil() function. You simply need to use ceil() when the number is negative rather than floor(). This will round the number to the first whole number reached when going towards zero. The formulae in post #64 will fix this; if you want to do it in one step rather than two, you could use:

 

GPS LAT = if(((((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+'GPS LAT LW')/10000000)>0.0),((((((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+'GPS LAT LW')/10000000)-floor((((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+'GPS LAT LW')/10000000)))/0.6)+(floor((((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+'GPS LAT LW')/10000000)))),((((((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+'GPS LAT LW')/10000000)-ceil((((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+'GPS LAT LW')/10000000)))/0.6)+(ceil((((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+'GPS LAT LW')/10000000)))))

[Chris Wilson]

Wow, we are into modern art now Something is definitely awry, I can *PROMISE* my lines were better than this

[Chris Wilson]

In Google earth with Motec map in red.

 

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

[Chris Wilson]

Looking at the lat and lon channels changing as I move the cursor it all looks good and sensible with the functions set as in #64 or #69 , yet it draws crazy maps now.

[Andy Blyth]

In your image in post #70 I can see some LW fields with negative numbers. The equations above need the LW to be unsigned (i.e. always positive numbers). You 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'

GPS LON COMBINE = ((if('GPS LON HW'>32767,('GPS LON HW'-65536),'GPS LON HW')*65536)+if('GPS LON LW'

 

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'))))

 

3> Do the same as the above, only with 1 step per axis:

 

GPS LAT = if(((((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+if('GPS LAT LW'0.0),((((((if('GPS LAT HW'>32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+if('GPS LAT LW'32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+if('GPS LAT LW'32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+if('GPS LAT LW'32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+if('GPS LAT LW'32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+if('GPS LAT LW'32767,('GPS LAT HW'-65536),'GPS LAT HW')*65536)+if('GPS LAT LW'

 

GPS LON = if(((((if('GPS LON HW'>32767,('GPS LON HW'-65536),'GPS LON HW')*65536)+if('GPS LON LW'0.0),((((((if('GPS LON HW'>32767,('GPS LON HW'-65536),'GPS LON HW')*65536)+if('GPS LON LW'32767,('GPS LON HW'-65536),'GPS LON HW')*65536)+if('GPS LON LW'32767,('GPS LON HW'-65536),'GPS LON HW')*65536)+if('GPS LON LW'32767,('GPS LON HW'-65536),'GPS LON HW')*65536)+if('GPS LON LW'32767,('GPS LON HW'-65536),'GPS LON HW')*65536)+if('GPS LON LW'32767,('GPS LON HW'-65536),'GPS LON HW')*65536)+if('GPS LON LW'

[Chris Wilson]

You really are going well beyond any reasonable expectations in helping here Andy, I insist on sending you a bottle or something! Obviously changing the logger is best, but that means messing about getting more data to test things. I will try the new function and if that works I will change the logger settings to do it internally with the signing. There is also the option to add the maths functions to the logger, in the setup file. I guess this is the more elegant approach once it's finally working. Thanks once again, I'll try the functions now. Cheers!!

 

Right! This looks a lot better! Some spurious lines again, but the track layout is bang on

 

 

Overlay in Google Earth:

 

http://www.gatesgarth.com/overlay.png

[Andy Blyth]

Interesting! For those spiky bits, I assume that it's the software drawing the lines between the track and the tip of the spike and you're not seeing GPS readings along the length of the spike?

 

Do you have the ability to pick out the readings you were getting at the point immediately before a spike and at the end of a spike? It's interesting to me that it seems repeatable, happening several times in each of three parts of the track. The attached image makes it look as if the spikes are diagonal, but on the Google Earth image the spikes are either N/S or E/W, suggesting that for some cases the latitude is still valid but the longitude is incorrect and in others vice versa.

 

I see in the attached image that your logger is seeing both the lat and lon high words as 0 and both the low words as -32768. Does the i2 log show the same? Those values would put you somewhere in the middle of the Atlantic Ocean, south of Ghana so clearly they are wrong!

 

I'm starting to wonder if there's some errors in the data transmission at some point. It's maybe worth a question to MoTeC to see if they transmit those specific values if there's an error.