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
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
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.032250Hi @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
Hello @Fomi Me also having same problem regarding this RAK5205 and RAK811 Breakout Board accuracy. The GPS Location around 300 meters showing Data what should has to do RAK5205 .Please i want to learn how to start to develop my own firmware please help me .So ,Please Give me access for Login ID Credentials to modify the required data and code to get the correct GPS Location Data.
Thank you in advance
[email protected]
Its firmware issue.RAKWireless assumed boundary for all of China and includes several countries. You can actually reverse the computatiin upon using the data. There are several software libraries available on the web
Best Regards
Neil Ablang
Thank so much …