Syvecs Forums

Not Syvecs related but several Syvecs users have suggested there's someone here who could work this out in their sleep, or at least on a fag packet, and I am stuck.... Cheers.

My ecu outputs seven decimal place GPS coordinates as two 16 bit channels and the data reading software then combines them using maths to give a degree based GPS coordinate to generate a track map.

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. Can anyone work out what it's doing to the raw date to combine them to make the correct coordinate please? I can't....

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

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

All I can say is the hardware won't allow transmission of 32 bit data on the serial port, so they somehow split it up into two sets of 16 bit, then rejoin it in the software using maths. The end result is degrees, minutes and seconds to seven decimal places. I am collecting the data from the CAN BUS of the Motec ecu, and logging it in a none Motec data logger. The data logger's software has powerful maths functions, so once I can see how Motec split and rejoin the data streams I should be able to duplicate it in the other software. They also split the GPS time data stream into two 16 bit channels, this may be easier, example below, (the time format does not take into account British Summer Time offset, by the way).

GPS Time HW : 1614
GPS Time LW : -8040

GPS Time (combined) : 105832.600


Actual time was 10.58 AM and 32.600 seconds.

Thanks. I think HW is "high word", and LW is "low word", and combing the two 16 bit streams correctly is the key.

I think I can sort this for the time.

Start with the time 105832.600, but write it as 105832600. That, in Hex, is 0x064EE098.

Split that into two 16 bit hex numbers: 0x064E, and 0xE098.

Now look at your decimal numbers:

GPS Time HW : 1614 which is 0x064E
GPS Time LW : -8040 which is 0xE098

QED

It is much easier if you deal in hex. Simply concatenate the HW and LW (which as you correctly intuited as the High and Low words) then convert to decimal.

In other words, if you'd read the HW as 0x64E and the LW as 0xE098, concatenated to get 0x64EE098 then convert to decimal, you get the correct time.

The lat and long are more complex as it actually does need to represent negative numbers, and I can't immediately work out what the schema is - I suspect that the data coming from the receiver may not be in degrees, but in other units that the software is converting to degrees.

Do you know what GPS module is at the heart of the receiver? A check of it's data sheet might reveal what the format is.

But, anyway, hopefully this helps a little

Thanks Tim, I feel embarrassed to ask none Syvecs questions, but such is your burden for being a genius I see where you are coming from in the previous post, to add to this Motec have replied from Australia:


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

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.

Motec

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

However:

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 on with i2, and the numbers then 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 have to write a maths expression "thing" to do the change, which is almost certainly beyond me, but if I can at least find what the "thing" needs to do, it's a start Sincere thanks for your time. I assume I may have to do something similar if I want these GEMS CAN loggers to read from a Syvecs ecu GPS data?

It's to do with signed and unsigned numbers, that's all. If you take the example of GPS LONG HW where Motec says -364 and GDA says 65172, they are actually the same "raw" binary number.

65172 is FE94 in Hex. If this is an unsigned integer FE94 is, indeed, 65172. But "-364" - a signed integer - would be also be FE94. The most significant BIT is the sign (0=positive number, 1=negative number). So, it's just a case of how the numbers are defined: signed, or unsigned.

Thanks again Tim. As the data is straight off the CAN I take it there's no way to alter the signing of the data leaving the ecu, and the maths in the analysis software (GDA) will handle this? I *THINK* what I am asking is i2 or GDA seeing the raw data, or put another way, where is this signing added? If I tried to use these loggers with a Syvecs CAN output would I see the same as I do from a M800 ecu? Cheers.

The ecu will be sending them in the format if has been programmed to do, so I would think it is down to the logger to be programmed/configured to interpret the data the correct way.

For example, a racedash has a configuration program that you use to tell it how to pick data from the CAN bus, and you tell it whether the data is signed or unsigned. In the case of the Syvecs (since I don't know Motec) a given parameter is either signed or unsigned and you have no control of it, so it's up to the receiving device to be set up appropriately.

Got you. Thanks Tim, well beyond the call of duty and much appreciated. Does the S8 split GPS output as two sixteen bit channels, or can some ecus send 32 bit data for GPS in one go?

Sorry - not familiar with the S8, so someone else will have to help you there I'm afraid

What you need to remember with signed values is you are losing 1 bit of range to give you the signing, so a signed number sent with only 16 bits will be a 15bit number and a sign, which in effect is the same overall range as you can go from -32768 to +32768.

You can use you're maths function to decode this if you need to, because as Tim points out they are the same binary number, the same piece of information. I haven't looked at the GDA setup to know either way but it should be possible.

As far as the S8 goes, GPS support is somewhat lacking in the ENGINE Control Unit, but as the ECU does more that can use GPS information (like location/lap distance specific TC) I am sure than more support will come. Instead you will need to feed all your info into one central place for overall logging, especially for the chassis side of things, however there will be developments in time on all these fronts I hope.

MoTeC is fantastic as far as system integration goes.

More great info, thanks pavlo. Would anyone be willing to look at the maths options available in GDA Pro if I put some screenshots up on my server, and suggest a suitable "thing" to convert the data? It's not possible to download the GDA software to look at the maths in the flesh, as only the pro version has the necessary functionality, and it's pay for, with a dongle. I wish I'd paid more attention in maths, my teacher warned me I'd regret it one day

Motec is great for integration, yes, I'd have bought their ACL logger, but the price is just too much for my level of involvement, unless a very well priced used one turned up. I chose the GEMS loggers as they turned up cheap and the software felt pretty good, and quite like Motec in some ways. I meg of logging in the ecu seemed a lot a few years back, now it seems very minimal, 1 gig sounds much better with the new loggers, but I am having to work to get it all tied in together, but I am learning a lot along the way. Thanks again!