Race Technology GPS Data (Heading and incorrect Latitude)

General support questions and announcements for MS3. See also MS3 manuals.

Moderators: jsmcortina, muythaibxr

Race Technology GPS Data (Heading and incorrect Latitude)

Postby Lokiel » Tue Nov 14, 2017 5:17 pm

I've been trying to inject GPS data into the MS using the Race Technology CAN GPS format and have set up Tuner Studio digital gauges to display the GPS data with mixed success.

So far I've managed to send and receive the following correctly (I'm injecting constant values via an Arduino with a CAN bus so that I know what values I SHOULD be seeing in TS on the GPS digital gauges):
Code: Select all
1. GPS Latitude
   Northern hemisphere (ie. +ve values) work
   Southern hemisphere (ie. -ve values) don't (eg. -271234567 is reported as -23abcdefg, where abcdefg are digits I don't have in front of me right now)

2. GPS Longitude
   East and West hemispheres both work
   
3. GPS Altitude

4. GPS Speed
   Note: The Race Tecnology CAN GPS Speed message contains 2D and 3D values; TS uses the 3D value.

I've failed to send GPS Heading data so far.
Race Technology defines 2 GPS Heading messages, RT_GPS_Heading_Gradient1 and RT_GPS_Heading_Gradient2.
I'm sending both of these messages via the CAN bus but don't see any heading updates on TS.

I have the following questions:

1. Is the Race Technology GPS Heading supported and, if so, which message is used by TS, RT_GPS_Heading_Gradient1 or RT_GPS_Heading_Gradient2?

2. Have Southern hemisphere Race Technology GPS Latitudes been tested in TunerStudio, mine are reported incorrectly? (my Southern Hemisphere values aren't correct - I AM sending all multi-byte values in Race Technology's "Little Endian" format and the Northern values are correct so it's not a byte-ordering issue)

3. It seems that TS is ignoring the validity fields in the CAN messages - is this correct?

4. Does TS use the accuracy fields in the CAN messages at all? (it appears not to)

5. Can TS make use of GPS time? (would be nice to have an option to allow it to set the MS time)


FYI: I've included extracts from Race Technology CAN data for the Position, Altitude and Heading below that I'm using to define the GPS CAN messages I'm sending so that you can see what I'm working with.

From http://www.race-technology.com/wiki/index.php/GPSMessages/3RTGPSPosLLH:
Code: Select all
    GPSMessages / 3RTGPSPosLLH
    RT_GPS_Pos_LLH GPS accuracy and latitude

    RT_GPS_Pos_LLH_1: 140, 2 (0x8C0220 + unit id) (0x302)
    ----
    Byte 0: Validity
    Byte 1: Accuracy Latitude
    Byte 2: Accuracy Longitude
    Byte 3: Accuracy Altitude
    Bytes 4-7: Latitude (degrees)
    ----
    Latitude resolution is degrees * 1e-7.
    The validity byte is used for the data packets in this message *and* in RT_GPS_Pos_LLH_2.
    Accuracy value have a resolution of 0.1m. The accuracy figures are a 1 sigma estimate of the accuracy for the position


From http://www.race-technology.com/wiki/index.php/GPSMessages/4RTGPSPosLLH2:
Code: Select all
    GPSMessages / 4RTGPSPosLLH2
    RT_GPS_Pos_LLH_2 GPS Longitude and altitude

    RT_GPS_Pos_LLH_2: 140, 3 (0x8C0320 + unit id) (0x303)
    ----
    Bytes 0-3: Longitude (degrees)
    Bytes 4-7: Altitude (m)
    ----
    Longitude resolution is degrees * 1e-7.
    Altitude resolution is m/1000.
    Validity is provided by RT_GPS_Pos_LLH_1.


From http://www.race-technology.com/wiki/index.php/GPSMessages/12RTGPSHeadingGradient1:
Code: Select all
    GPSMessages / 12RTGPSHeadingGradient1
    RT_GPS_Heading_Gradient1 Heading and gradient 1

    RT_GPS_Heading_Gradient: 140, 21 (0x8C1520 + unit id) (0x315)
    ----
    Byte 0: Validity
    Byte 1: Accuracy Heading
    Bytes 2-3: GPS Heading (-180 – 180 degrees)
    Byte 4: Accuracy Gradient
    Bytes 5-7: GPS Gradient
    ----
    Resolution of heading and gradient is degrees/100


From http://www.race-technology.com/wiki/index.php/GPSMessages/13RTGPSHeadingGradient2:
Code: Select all
    GPSMessages / 13RTGPSHeadingGradient2
    RT_GPS_Heading_Gradient2 Heading and gradient 2

    RT_GPS_Heading_Gradient: 140, 21 (0x8C1620 + unit id) (0x316)
    ----
    Byte 0: Validity
    Byte 1: Accuracy Heading
    Bytes 2-3: GPS Heading (0-360 degrees)
    Byte 4: Accuracy Gradient
    Bytes 5-7: GPS Gradient
    ----
    Resolution of heading and gradient is degrees/100


Corresponding definintions from the Race Technology CAN_RT.dbc file:
Code: Select all
BO_ 2156659236 RT_DL1MK3_GPS_Pos_LLH_1: 8 Vector__XXX
 SG_ GPS_Pos_LLH_Latitude : 32|32@1- (1E-007,0) [-90|90] "degrees" Vector__XXX
 SG_ Accuracy_GPS_Pos_LLH_Altitude : 24|8@1+ (1,0) [0|255] "" Vector__XXX
 SG_ Accuracy_GPS_Pos_LLH_Longitude : 16|8@1+ (1,0) [0|255] "" Vector__XXX
 SG_ Accuracy_GPS_Pos_LLH_Latitude : 8|8@1+ (1,0) [0|255] "" Vector__XXX
 SG_ Validity_GPS_Pos_LLH_Altitude : 2|1@1+ (1,0) [0|1] "" Vector__XXX
 SG_ Validity_GPS_Pos_LLH_Longitude : 1|1@1+ (1,0) [0|1] "" Vector__XXX
 SG_ Validity_GPS_Pos_LLH_Latitude : 0|1@1+ (1,0) [0|1] "" Vector__XXX

BO_ 2156659492 RT_DL1MK3_GPS_Pos_LLH_2: 8 Vector__XXX
 SG_ GPS_Pos_LLH_Altitude : 32|32@1- (0.001,0) [-1000|100000] "m" Vector__XXX
 SG_ GPS_Pos_LLH_Longitude : 0|32@1- (1E-007,0) [-180|180] "degrees" Vector__XXX

BO_ 2156794914 RT_SB_INS_Heading_Gradient: 8 Vector__XXX
 SG_ INS_Gradient : 40|16@1- (0.01,0) [-90|90] "degrees" Vector__XXX
 SG_ Accuracy_INS_Gradient : 32|8@1+ (1,0) [0|255] "" Vector__XXX
 SG_ INS_Heading : 16|16@1- (0.01,0) [-180|180] "degrees" Vector__XXX
 SG_ Accuracy_INS_Heading : 8|8@1+ (1,0) [0|255] "" Vector__XXX
 SG_ Validity_INS_Gradient : 1|1@1+ (1,0) [0|1] "" Vector__XXX
 SG_ Validity_INS_Heading : 0|1@1+ (1,0) [0|1] "" Vector__XXX

BO_ 2156795170 RT_SB_INS_Heading_Gradient_2: 8 Vector__XXX
 SG_ INS_Gradient : 40|16@1- (0.01,0) [-90|90] "degrees" Vector__XXX
 SG_ Accuracy_INS_Gradient : 32|8@1+ (1,0) [0|255] "" Vector__XXX
 SG_ INS_Heading_2 : 16|16@1+ (0.01,0) [0|360] "degrees" Vector__XXX
 SG_ Accuracy_INS_Heading : 8|8@1+ (1,0) [0|255] "" Vector__XXX
 SG_ Validity_INS_Gradient : 1|1@1+ (1,0) [0|1] "" Vector__XXX
 SG_ Validity_INS_Heading : 0|1@1+ (1,0) [0|1] "" Vector__XXX
Lokiel
MS/Extra Newbie
 
Posts: 19
Joined: Mon May 16, 2016 3:43 pm

Re: Race Technology GPS Data (Heading and incorrect Latitude

Postby jsmcortina » Tue Nov 14, 2017 5:45 pm

This isn't a TunerStudio question. Moving to MS3 support forum.

I used a Race Technology DASH2PRO and I believed that the numbers were showing correctly.
EDIT I'm near the middle of England, UK in the northern hemisphere. Close to 52.44,-1.79. I grabbed the datalog I took and used gpsvisualizer.com to plot it onto a map and it is correct for this data.

James
I can supply, repair or upgrade Megasquirts in UK. http://www.jamesmurrayengineering.co.uk

My Success story: viewtopic.php?f=104&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
jsmcortina
Site Admin
 
Posts: 33911
Joined: Mon May 03, 2004 1:34 am
Location: Birmingham, UK

Re: Race Technology GPS Data (Heading and incorrect Latitude

Postby Lokiel » Tue Nov 14, 2017 6:15 pm

Anyone using a Race Technology Dash that can confirm that the MS3 is receiving Race Technology CAN Heading Data?

Anyone in the Southern hemisphere using a Race Technology Dash that can confirm that the MS3 is reporting the Lattitude correctly?
Lokiel
MS/Extra Newbie
 
Posts: 19
Joined: Mon May 16, 2016 3:43 pm

Re: Race Technology GPS Data (Heading and incorrect Latitude

Postby jsmcortina » Wed Nov 15, 2017 6:40 am

Do you have a method to log the CAN data on the bus that the dash is sending? If you could post that and the data you think it should correspond to, that would help me investigate the MS3 firmware.

James
I can supply, repair or upgrade Megasquirts in UK. http://www.jamesmurrayengineering.co.uk

My Success story: viewtopic.php?f=104&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
jsmcortina
Site Admin
 
Posts: 33911
Joined: Mon May 03, 2004 1:34 am
Location: Birmingham, UK

Re: Race Technology GPS Data (Heading and incorrect Latitude

Postby Lokiel » Wed Nov 15, 2017 8:43 pm

While trying to get the Race Technology GPS data working I'm hard-coding the input data via constants that are converted to CAN packets - this way I know if the data is being received/decoded correctly.
When I get home I'll add all the CAN packet data I'm sending for each message, along with details of what I expect the received/decoded data to be.
Most of the GPS data is being received correctly, including Speed, Altitude, +ve Latitude values and both +ve and -ve Longitude values, so I'm confident that the CAN data I'm sending is correct.

If I use the same negative degree value for Latitude and Longitude, the Latitude value is NOT correct but the Longitude IS correct.
This indicates that you're not using a common decoder for Latitude and Longitude.

I played around with input values last night and also found that if I used a negative zero-decimal degree value (eg. -1deg=-10,000,000 or -50deg=-500,000,000) that the Latitude was reported correctly.

I've seen CAN implementations where only the integer component of a value takes into account the sign and the decimal component does not (eg. for Latitudes, which have a -90..90 degree range, -12.3456789 is stored as "-12" in one byte and the remaining decimal bytes are stored unsigned as "3456789").
Is it possible that is what is happening here?
Based on the fact that Latitude +ve values and -ve zero-decimal place values decode correctly but -ve non-zero decimal values don't, this would be my guess (ie. you're NOT treating the decimal degree component as a signed value when the degree component is -ve).

Here are some of the values I tried last night (note that the Input Latitude is the degreeValue*10,000,000, as required by Race Technology's CAN fornat):

InputLatitude(degrees*10,000,000),ReportedValue(degrees)
-901234567,-85.75439 <-- Incorrect by ~-5 degrees
-599999999,-55.63093
-231234567,-18.75439
-231000000,-18.73093
-230100000,-18.73093
-230010000,-22.89177
-230001000,-22.89087
-230000100,-22.89078
-230000010,-23 <-- This IS correct - note that there were NO decimals
-121234567,-7.75439
-99999999,-5.63093
-59999999,-1.63093
-50000000,-5 <-- This IS correct - note that there were NO decimals
-45555555,-0.18649
-44444444,-0.07538
-20001000,-1.89087
-20000100,-1.89078
-20000000,-2
-11000000,3.26907
-10000000,-1 <-- This IS correct - note that there were NO decimals
-9999999,3.36907
-5999999,3.76907
-5000000,3.86907
-500000,4.31907
-50000,0.10423
-5000,0.10873
-500,0.10918
-66,0.10922
-50,0.10922
-6,0
20000000,2 <- Correct
121234567,12.123456 <- Lost the last decimal place due to TS/MS precision
599999999,60 <- Correct

Hope this helps and will send the actual CAN data when I get home.
Lokiel
MS/Extra Newbie
 
Posts: 19
Joined: Mon May 16, 2016 3:43 pm

Re: Race Technology GPS Data (Heading and incorrect Latitude

Postby Lokiel » Thu Nov 16, 2017 4:28 am

I did 2 runs using constant values, one with the same +ve Latitude and Longitude values another with the same -ve Latitude and Longitude values (I just changed the sign value).
Screenshots corresponding to these are shown below.

1st Run
---------
latitude: 12.1234567 * 10,000,000
longitude: 12.1234567 * 10,000,000
altitude: -6.789 * 1000
speed: 65.4321 * 10,000 (this is a m/s value; 65.4321m/s = 235.55556km/h)
course: 123.45 * 100
signedCourse: 45.67 * 100

The following CAN data was broadcast at 10Hz (all values in hex, 1st column is CAN Message ID, 2nd: Data length, 2..10 data bytes):

0x301 08: 03 64 40 94 00 1c 14 00
0x302 08: 07 01 01 01 87 e4 39 07
0x303 08: 87 e4 39 07 7b e5 ff ff
0x310 08: 00 64 f1 fb 09 f1 fb 09
0x315 08: 01 01 d7 11 01 ff ff ff
0x316 08: 01 01 39 30 01 ff ff ff

Image
The code snapshot shows the two Heading+Gradient CAN messages and neither works (note that TS shows GPS Course as 0.0).

2nd Run
----------

latitude: -12.1234567 * 10,000,000
longitude: -12.1234567 * 10,000,000
altitude: 6.789 * 1000
speed: 12.3456 * 10,000 (this is a m/s value; 12.3456m/s = 44.44416km/h)
course: 123.45 * 100
signedCourse: 45.67 * 100

The following CAN data was broadcast at 10Hz:

0x301 08: 03 64 40 94 00 1c 14 00
0x302 08: 07 01 01 01 79 1b c6 f8
0x303 08: 79 1b c6 f8 85 1a 00 00
0x310 08: 00 64 40 94 00 1c 14 00
0x315 08: 01 01 d7 11 01 ff ff ff
0x316 08: 01 01 39 30 01 ff ff ff

Image
Notes:
* The code snapshot shows the 2 CAN messages that are sent
* The Latitude is NOT correct but the Longitude IS correct (the same value was sent for these).
Lokiel
MS/Extra Newbie
 
Posts: 19
Joined: Mon May 16, 2016 3:43 pm

Re: Race Technology GPS Data (Heading and incorrect Latitude

Postby jsmcortina » Thu Nov 16, 2017 5:45 am

Can you provide CAN bus logs of the dash sending the data and what the MS3 shows. That way there's no potential for other assumptions or errors creeping in.

James
I can supply, repair or upgrade Megasquirts in UK. http://www.jamesmurrayengineering.co.uk

My Success story: viewtopic.php?f=104&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
jsmcortina
Site Admin
 
Posts: 33911
Joined: Mon May 03, 2004 1:34 am
Location: Birmingham, UK

Re: Race Technology GPS Data (Heading and incorrect Latitude

Postby Lokiel » Thu Nov 16, 2017 3:58 pm

Unfortunately no, I don't have a Race Technology dash, which is why I asked in an earlier post above if anyone in the Southern hemisphere is using a Race Technology dash with a MS so that they can confirm the behaviour.

The only reason I'm trying to use the Race Technology CAN GPS format is because I'm trying to send GPS data via the CAN bus.
MS/TS only supports 2 GPS CAN input devices, JBperf and Race Technology.
JBperf requires a send/receive interface which requires more effort to implement.
Race Technology uses a simple broadcast 11-bit CAN message interface.
Broadcasted messages are MUCH simpler to handle, the user simply listens for the required messages.

WIth access to the firmware source code, can't you simply hack it to hard-code the -ve latitude value I provided and see how the firmware subsequently processes it?

FYI in case you missed it:

It may not have been clear in my previous post (there was a lot of information so it may have been easy to miss in there), but for the -ve Latitude example, I used the exact same -ve value for the Longitude (ie. -12.1234567 * 10,000,000). The Longitude was displayed correctly in TS, the Latitude was NOT.

CAN messages of interest:
0x302 08: 07 01 01 01 79 1b c6 f8 <-- RT_GPS_Pos_LLH_1 message, Latitude in the last 4 bytes (Little Endian format)
0x303 08: 79 1b c6 f8 85 1a 00 00 <-- RT_GPS_Pos_LLH_2 message, Longitude is in the first 4 bytes (Little Endian format)

-12.1234567 * 10,000,000 = -121,234,567 = 0xF8C61B79 (Big Endian) = 79 1b c6 f8 (Little Endian)

Once again, if there are no decimal degrees (ie. -12 * 10,000,000 = -120,000000 = 0xF8D8F200), -ve Latitudes ARE displayed correctly in TS so I suspect you're handling these different in the Latitude case than the Longitude case (which DOES handle/display them correctly in TS).
Lokiel
MS/Extra Newbie
 
Posts: 19
Joined: Mon May 16, 2016 3:43 pm

Re: Race Technology GPS Data (Heading and incorrect Latitude

Postby jsmcortina » Thu Nov 16, 2017 5:38 pm

I've investigated somewhat and I think it is a signed vs. unsigned data issue.
Try changing the following lines in the firmware ini file (stored by TunerStudio as maincontroller.ini)

Code: Select all
   gps_latmin       = scalar, U08,  489, "", 1,0
   gps_latmmin      = scalar, U16,  490, "", 1,0

to:
Code: Select all
   gps_latmin       = scalar, S08,  489, "", 1,0
   gps_latmmin      = scalar, S16,  490, "", 1,0

I've not tested this live, but have looked at the code and analysed on a piece of paper.

James
I can supply, repair or upgrade Megasquirts in UK. http://www.jamesmurrayengineering.co.uk

My Success story: viewtopic.php?f=104&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
jsmcortina
Site Admin
 
Posts: 33911
Joined: Mon May 03, 2004 1:34 am
Location: Birmingham, UK

Re: Race Technology GPS Data (Heading and incorrect Latitude

Postby racingmini_mtl » Thu Nov 16, 2017 6:03 pm

jsmcortina wrote:I've investigated somewhat and I think it is a signed vs. unsigned data issue.
Try changing the following lines in the firmware ini file (stored by TunerStudio as maincontroller.ini)

Code: Select all
   gps_latmin       = scalar, U08,  489, "", 1,0
   gps_latmmin      = scalar, U16,  490, "", 1,0

to:
Code: Select all
   gps_latmin       = scalar, S08,  489, "", 1,0
   gps_latmmin      = scalar, S16,  490, "", 1,0

I've not tested this live, but have looked at the code and analysed on a piece of paper.

James

Actually, the issue is not in the signed/unsigned assignment but rather when the latitude is computed from those:

Code: Select all
   gps_latitude = { gps_latdeg + (gps_latmin / 60) + (gps_latsec / 3600) }


Since the minute and second latitude values are always positive because the sign is in the degree value, this should instead be something like this (I have not validated this equation in TS):

Code: Select all
   gps_latitude = { (gps_latdeg < 0) ? (gps_latdeg - (gps_latmin / 60) - (gps_latsec / 3600)) : (gps_latdeg + (gps_latmin / 60) + (gps_latsec / 3600)) }


I realise that I have the same issue with the IOx. I never realised this since I'm in the Northern hemisphere and it never came up.

Jean
jbperf.com Main site . . . . . . . . . . . . . . . . . . . . . . jbperf.com Forum
Image
racingmini_mtl
Super MS/Extra'er
 
Posts: 7973
Joined: Sun May 02, 2004 6:51 am
Location: Quebec, Canada

Re: Race Technology GPS Data (Heading and incorrect Latitude

Postby Lokiel » Fri Nov 17, 2017 3:29 am

Not quite, here's the result of that change when Latitude and Longitude were both set to -12.1234567:

Image

The problem is that gps_latmin and gps_latsec were created from a two's complement -ve value so you can't simply subtract them; they need to have been created from a +ve number.

The longitude calculation, included in the screenshot above, is different and makes use of a gps_outstatus variable.
I assume that gps_outstatus has been set to 1 for the Eastern hemisphere somewhere when the 4 longitude bytes were decoded and the absolute value used to define gps_longdeg, gps_lonmin and gps_lonsec.
gps_long is calculated from these +ve values and gps_longitude is set to -1*gps_long if gps_outstatus is set (gps_long otherwise).
Lokiel
MS/Extra Newbie
 
Posts: 19
Joined: Mon May 16, 2016 3:43 pm

Re: Race Technology GPS Data (Heading and incorrect Latitude

Postby jsmcortina » Fri Nov 17, 2017 6:35 am

The ini tweak alone didn't resolve it. I had to change the internal vars to signed also.
The fix will be in the next beta.

James
I can supply, repair or upgrade Megasquirts in UK. http://www.jamesmurrayengineering.co.uk

My Success story: viewtopic.php?f=104&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
jsmcortina
Site Admin
 
Posts: 33911
Joined: Mon May 03, 2004 1:34 am
Location: Birmingham, UK

Re: Race Technology GPS Data (Heading and incorrect Latitude

Postby jsmcortina » Fri Nov 17, 2017 7:16 am

0x315 and 0x316 weren't supported.
I added support for receiving 0x316 and confirmed that I see 123.4 in "course". (There's no placeholder for gradient.)


James
I can supply, repair or upgrade Megasquirts in UK. http://www.jamesmurrayengineering.co.uk

My Success story: viewtopic.php?f=104&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
jsmcortina
Site Admin
 
Posts: 33911
Joined: Mon May 03, 2004 1:34 am
Location: Birmingham, UK

Re: Race Technology GPS Data (Heading and incorrect Latitude

Postby Lokiel » Fri Nov 17, 2017 6:10 pm

Thanks, and for including 0x0316 (Heading 0-360) in the next release.

I noted that the .ini file defines gps_course as U16, 0-360, so was surprised that the heading/course wasn't handled.

There's no TS variables for the Gradient and it's not a value provided by GPS NMEA data anyway (it can be calculated from successive altitude values if users ever want this feature so they can do it themselves).
Lokiel
MS/Extra Newbie
 
Posts: 19
Joined: Mon May 16, 2016 3:43 pm


Return to MS3 General Support

Who is online

Users browsing this forum: Bing [Bot] and 2 guests