RAK5205 GPS Location Accuracy off by 500 meters

Hello,

I got two RAK5205 working and both have GPS reading that is off by 500 meters. I was reading the specs of MAX 7 u blox and it says should be about 2.5Meters accurate.

The RAK7249 gateway’s GPS is very accurate to about 2 meters compared to the RAK5205

Is there any way to correct this?

Thank you in advance

Best Regards

Neil Ablang

Hi @slyfoxneil

What firmware version are you using?

Regards
Vladislav

Hi @slyfoxneil
From where you get GSP data? If you relay to Cayenne, it is inaccurate due to LPP standard. They only show GPS data (lon/lat) to 4th symbol after decimal point.

Regards
Todor Velev

Hello Todor,

Yes it was in Cayenne LPP but the result is shown here is 500meters away from me compared to the hundreds of kilometers the serial tool is showing at lat/long. See the logs below

this is from InlfuxDB, as parse thru Cayenne LPP (using loraserver,io)
time application_name dev_eui device_name f_port geohash latitude longitude


2019-08-27T16:33:03.364078+08:00 OurApplication 60c5a8fffe760016 TrioTwo 3 wdw43tef5nf9 14.4886 121.0087
2019-08-27T16:35:03.417035+08:00 OurApplication 60c5a8fffe760016 TrioTwo 3 wdw43tkjs3sv 14.4878 121.0091
2019-08-27T16:37:17.367332+08:00 OurApplication 60c5a8fffe760016 TrioTwo 3 wdw43tkpk3sf 14.4881 121.0091
2019-08-27T16:38:59.372084+08:00 OurApplication 60c5a8fffe760016 TrioTwo 3 wdw43tkndnfq 14.488 121.009
2019-08-27T16:40:57.412381+08:00 OurApplication 60c5a8fffe760016 TrioTwo 3 wdw43tknnsr3 14.4879 121.0092
2019-08-27T16:42:28.361792+08:00 OurApplication 60c5a8fffe760016 TrioTwo 3 wdw43tebmqv5 14.4883 121.0088

But getting the value from the device terminal display is more erroneous. Its showing In in the middle of the sea hundreds of kilometers away (14.48830, longitude: 121.888 ) as shown below.

[16:41:51:017] Start Search Satellite …

[16:42:27:039] Gps normal.

[16:42:27:049] latitude: 14.48830, longitude: 121.888 , altitude: 19m

[16:42:27:052] Battery Voltage = 4.194 V

As @Hobo ask, what version of firmware you use?

at+version
OK3.0.0.3.L
[16:58:35:106] ===============Device Status List================

[16:58:35:106] Board Core: RAK811

[16:58:35:106] MCU: STM32L151CB_A

[16:58:35:106] LoRa chip: SX1276

[16:58:35:106] Battery Voltage = 4.198 V

[16:58:35:106]

[16:58:35:106] Support Gps:true

[16:58:35:106] Gps Timeout:90 s

[16:58:35:117] latitude: 14.48792, longitude: 121.916 , altitude: 28m

[16:58:35:117]

[16:58:35:117] LIS3DH sensor:ACC X: 0 mg, Y: -256 mg, Z: -256 mg

[16:58:35:123]

[16:58:35:123] BME680 sensor:pressure:1001.0 hPa

[16:58:35:699] Temperature:35.0 degree

[16:58:35:989] Humidity:59.0 %RH

[16:58:35:995] ===================List End======================

[16:58:36:002] *************************************************

[16:58:47:051] OK3.0.0.3.L

any update on this? firmware revision?

Hi @slyfoxneil
Sorry for late replay. Can you test this with firmware for high bands? You use 433/470MHz firmware, so i presume that your Gateway is in this frequency.
Please if you can flash the H firmware and check again GPS position fix.

Regards
Todor Velev

Hi Todor,

Sure. Ill load the H firmware. My gateway is 433MHz

Best Regards

Neil Ablang

Hello Todor

I loaded the H version and the following are showing up in terminal

========================================================


RAK5205 Version:3.0.0.3.H


========================================================
BME I2C WRITE ERROR
BME set regs ERROR
BME soft reset ERROR
BME680 Init ERROR
LIS3DH no ack
LIS3DH is not found!

Selected LoRaWAN 1.0.2 Region: EU868
Initialization OK,Current work_mode:LoRaWAN, join_mode:OTAA, Class: A
OTAA:
DevEui:60C5A8FFFE760016
AppEui:00137A1000000000
AppKey:5A6967426565416C6C69616E63653039
OTAA Join Start…
[LoRa]:Join retry Cnt:1
[LoRa]:Join retry Cnt:2
[LoRa]:Join retry Cnt:3
[LoRa]:Join retry Cnt:4
[LoRa]:Join retry Cnt:5
[LoRa]:Joined Failed!

Hello RakWireless Team,

I traced the 400 meters error to the OutOfChina function in the gps.c source file , https://github.com/RAKWireless/RAK5205-WisTrio-LoRa/blob/master/src/LoRaWAN/master/system/gps.c

and the gps84_To_Gcj02() function where you have a defined offsetting if the coordinates are within “China”. The boundaries set on the OutOfChina() are actually encompassing a huge geographic area, from near Russia at the north side and Borneo on the south side and at middle of pacific ocean on the east side. There is a need to revise the values for the lat/lon pairs defined in the OutOfChina() function. You are defining a rectangular boundary with the set of coordinates.My suggestion is to disable this coordinates checking function since it is flawed. China is not on a rectangular box.

BTW, i can upload and provide my test source code in C on this , using the sources at gps.c

The current code is the one causing the 400 meters offset to the south/east.

Expected: latitude 14.510805, longitude 121.032250
Transformed: latitude 14.509103 longitude 121.035666

I dont have uVision Kiel IDE and I cant compile a firmware with revisions based on github sources so I did standalone run for the gps routines in Linux GCC. If you can show how I can revise this on RUI, I will be glad to do so.

I noticed that logic at OutOfChina() is not quite correct because of the big scope of the boundary defined.

static bool outOfChina(double lat, double lon) {
if (lon < 72.004 || lon > 137.8347)
return true;
if (lat < 0.8293 || lat > 55.8271)
return true;
return false;
}

since the calling function was done in gps84_To_Gcj02() as

	if (outOfChina(lat, lon)) {  
			*lat02 = lat;
			*lon02 = lon;
			return;
	} 

We should be returning true when not on the boundaries and false if the coordinates fall within the boundaries. The if statement expects a logical True value to execute what is inside the {…}

In sample case for my revision just to show the program error (misjudjing im in China since the box boundary is very big) ,I use the following coordinates, 14.51N, 121.03E,

A = 14.51 < 0.8293 is false
B = 14.51 > 55.8271 is false

C = 121.03 < 72.004 is false
D = 121.03 > 137.8347 is false

(A || B) && (C||D) results to false, making the if statement not evaluated and returns true.

On my simulation (on LInux GCC ) i revised it to ;
(this is actually still not correct if you really want rectangular boundary, I made this just to demo the error of the logic on the OutOfChina() function because of the big boundary)

static bool outOfChina(double lat, double lon) {
if ((lon < 72.004 || lon > 137.8347) && (lat < 0.8293 || lat > 55.8271))
return false;

return true;

}

This now gives me a correct reading based on my simulation and location

If you can revise such, and compile a new firmware, I would be glad to test

The results are consistent with what Im seeing from the RAK5205 with firmware version 3.0.0.3.L, which is being offset by 400 meters towards south east.

Here is a log of my simulation on linux pc
##############################################################
This is the GPS Sentence : $GPGGA,092725.00,1430.64833,N,12101.93500,E,1,08,1.01,499.6,M,48.0,M,*51


GPS84 OutOfChina Original Code Scenario

5 1
NMEA GPS Sentence is checksum is correct
1 NMEA NmeaDataType:  GPGGA,
1 NMEA UTC Time:  092725.00,
1 NMEA NmeaLatitude:  1430.64833,
1 NMEA NmeaLatitudePole:  N,
1 NMEA NmeaLongitude:  12101.93500,
1 NMEA NmeaLongitudePole:  E,
from GpsFormatData -->> latitude: 14.510805, longitude: 121.032250 , altitude: 499.6, ; 

NMEA Data Type : GPGGA
NMEA UTC Time : 092725.00
NMEA Latitude : 1430.64833
NMEA Latitude Pole : N
NMEA Longitude : 12101.93500
NMEA Longitude Pole: E
NMEA NmeaFixQuality: 1
NMEA NmeaSatelliteTracked: 08
NMEA NmeaHorizontalDilution: 1.01
NMEA NmeaAltitude: 499.6
NMEA NmeaAltitudeUnit: M
NMEA NmeaHeightGeoid: 48.0
NMEA NmeaHeightGeoidUnit: M
NMEA NmeaChecksum: *51
from GpsFormatData -->> latitude: 14.510805, longitude: 121.032250 , altitude: 499.6 ; 

Before transforming geographic coordinates inside gps84_To_Gcj02 function
Before transformation : latitude : 14.510805, longitude : 121.032250


after calling gps84_To_Gcj02 --> latitude: 14.509103 , longitude: 121.035666

Inside FormatToLPP after gps84_To_Gcj02 function executed
@FormatToLPP latitude: 14.509103, longitude: 121.035666 , altitudeGps: 499m 


GPS Cayenne LPP Data 0: 01
GPS Cayenne LPP Data 1: 88
GPS Cayenne LPP Data 2: 02
GPS Cayenne LPP Data 3: 36
GPS Cayenne LPP Data 4: c3
GPS Cayenne LPP Data 5: 12
GPS Cayenne LPP Data 6: 77
GPS Cayenne LPP Data 7: f4
GPS Cayenne LPP Data 8: 00
GPS Cayenne LPP Data 9: c2
GPS Cayenne LPP Data 10: ec

GPS Cayenne LPP Data : 01880236c31277f400c2ec

Expected: latitude 14.510805, longitude 121.032250
Transformed: latitude 14.509103 longitude 121.035666

GPS84 OutOfChina Corrected and Revised Code Scenario

5 1
NMEA GPS Sentence is checksum is correct
1 NMEA NmeaDataType:  GPGGA,
1 NMEA UTC Time:  092725.00,
1 NMEA NmeaLatitude:  1430.64833,
1 NMEA NmeaLatitudePole:  N,
1 NMEA NmeaLongitude:  12101.93500,
1 NMEA NmeaLongitudePole:  E,
NMEA Data Type : GPGGA
NMEA UTC Time : 092725.00
NMEA Latitude : 1430.64833
NMEA Latitude Pole : N
NMEA Longitude : 12101.93500
NMEA Longitude Pole: E
NMEA NmeaFixQuality: 1
NMEA NmeaSatelliteTracked: 08
NMEA NmeaHorizontalDilution: 1.01
NMEA NmeaAltitude: 499.6
NMEA NmeaAltitudeUnit: M
NMEA NmeaHeightGeoid: 48.0
NMEA NmeaHeightGeoidUnit: M
NMEA NmeaChecksum: *51
from GpsFormatData -->> latitude: 14.510805, longitude: 121.032250 , altitude: 499.6 ; 

Before transforming geographic coordinates inside gps84_To_Gcj02 function
Before transformation : latitude : 14.510805, longitude : 121.032250


after calling gps84_To_Gcj02 --> latitude: 14.510805 , longitude: 121.032250

Inside FormatToLPP after gps84_To_Gcj02 function executed
@FormatToLPP latitude: 14.510805, longitude: 121.032250 , altitudeGps: 499m 


GPS Cayenne LPP Data 0: 01
GPS Cayenne LPP Data 1: 88
GPS Cayenne LPP Data 2: 02
GPS Cayenne LPP Data 3: 36
GPS Cayenne LPP Data 4: d4
GPS Cayenne LPP Data 5: 12
GPS Cayenne LPP Data 6: 77
GPS Cayenne LPP Data 7: d2
GPS Cayenne LPP Data 8: 00
GPS Cayenne LPP Data 9: c2
GPS Cayenne LPP Data 10: ec

GPS Cayenne LPP Data : 01880236d41277d200c2ec

Expected: latitude 14.510805, longitude 121.032250
Transformed: latitude 14.510805 longitude 121.032250

Hi @slyfoxneil
Impressive work! Sir Fomi is informed for this possible bug in 433/470 firmware. I will deep review your findings and will make suggestions to fix.
Thank you again to be part of the community.

Best Regards
Todor Velev

Hi Todor,

After discovering that WGS84 data was converted to GCJ-02 ,my current work around is to convert back to WGS84 from China GCJ-02 format.

Affected users for your devices using this GPS code are mostly in Asia since the code assumes most of Asia is China, and it converts WGS84 datum to GCJ-02. That includes Thailand, India, Vietnam, Philippines (where I am), Singapore, Malaysia, Korea, Japan to name few countries where users are affected. Europe , US and Africa are non-issues. since they are well outside that rectangular box defined in OutOfChina() function

From influxDB where I store my data, I fetch and convert it to WGS84 using the Go Lang libraries from https://github.com/googollee/eviltransform

This may help other users with same issue .

It so happen that I am within the boundaries defined by the OutOfChina() function.

Best Regards

Neil Ablang