Wisblock RAK9010 GPS module

WisBlock
1

I’m trying already some days to get the GPS data correctly:

Using the code at:

I got incorrect GPS data:

13:58:24.397 -> [GPS] status_waitforsignal = 0
13:58:26.453 -> [GPS] status_waitforsignal = 0
13:58:27.575 -> status: Connected
13:58:27.575 -> latitude: 5215.941 longitude: 00510.98684
13:58:29.584 -> status: Connected
13:58:29.584 -> latitude: 5215.94 longitude: 00510.98361
13:58:31.593 -> status: Connected
13:58:31.593 -> latitude: 5215.94 longitude: 00510.98356
13:58:33.601 -> status: Connected
13:58:33.601 -> latitude: 5215.94 longitude: 00510.98221
13:58:35.614 -> status: Connected
13:58:35.614 -> latitude: 5215.94 longitude: 00510.98134
13:58:37.582 -> status: Connected
13:58:37.582 -> latitude: 5215.942 longitude: 00510.98112
13:58:39.590 -> status: Connected
13:58:39.590 -> latitude: 5215.94 longitude: 00510.98094
…
after 6 minutes still:
14:05:43.588 -> status: Connected
14:05:43.588 -> latitude: 5215.94 longitude: 00510.99026

I’m living at 52.26, 5.18…

When using the ‘soluton’ code at:


it is also incorrect and got a very instable setup. The RAK core module freezes spontaneously all the time.

Just wondering if any other is also experiencing these kind of issues?

BR,
Jeroen

2

additional info:
enabled in the log: ```
Serial.println(_dataBuffer)

15:05:47.372 -> ,140549.00,A,5215.95217,N,00510.98764,E,0.171,271220,A*
15:05:48.546 -> status: Connected
15:05:48.546 -> ,140549.00,5215.95,M,45.9,M,*
15:05:48.546 -> ,140550.00,5215.95244,N,00510.98785,E,1,06,1.91,32.9,M,45.9,M,*
15:05:48.546 -> latitude: 5215.95 longitude: 00510.98785
15:05:49.391 -> ,140551.00,A,5215.95288,N,00510.98812,E,0.462,271220,A*
15:05:50.518 -> status: Connected
15:05:50.518 -> ,140551.00,5215.954,M,45.9,M,*
15:05:50.518 -> ,140552.00,5215.95350,N,00510.98851,E,1,06,1.91,34.2,M,45.9,M,*
15:05:50.518 -> latitude: 5215.954 longitude: 00510.98851

not OK

3

Hi Jeroen, we will update the example to solve the issue you encounter. For now, you can have a look at other easy to use GPS libraries like tinygps++ which is also compatible with RAK1910 (based on U-Blox MAX-7Q) and WisCore RAK4631.

1 Like
4

Great you regocnize the incorrect GPS lat/lon values. Hope you can fix it soon.
Looks like nobody is experimenting with the RAK9010 yet.

BR, Jeroen

5

Whilst the RAK team make changes to the library you may want to expand on your serial pass through sketch so we can see which sentence types are arriving as I don’t see anything obvious in the code that could mysteriously move you 20km south-west down the road. However you do appear to have 6 satellites in view which should give a decent fix.

6

It would indeed be key to understand what is going on here, particularly if the NMEA outputs of the GPS are being parsed into numeric values, there are ways that could be done which would introduce error in some cases.

For that purpose passing through the raw GPS info would be key to debugging.

And if the NMEA is not being parsed to a numeric value, it needs to be - a printable string type encoding of coordinates as present in the NMEA from the GPS is just too inefficient for air transmission over LoRa.

7

Hi @carlrowan,

When do you have an update available for testing?

BR,
Jeroen

8

When using TinyGPS++ the data is correct!:
08:05:12.441 → Lat: 52.26xxx
08:05:13.467 → Long: 5.18xxxx
08:05:13.467 → Alt: 47.90
08:05:13.467 → Course: 0.00
08:05:13.467 → Speed: 0.18
08:05:13.467 → Date: 29/12/2020
08:05:13.467 → Time: 7:05:13
08:05:13.467 → Sats: 7

So there is something incorrect with the RAK library.

9

We are discussing to replace both the GPS tracker solution and the GPS example with this example: RAK4631-LPWAN-Tracker
This code is using the tinygps++ library already.

1 Like
10

Sounds great, please have it also available in Arduino IDE instead of only Platformio

11

Hi @beegee,
I used your code and adjusted the Lorawan settings according my TTN console device.
Everything works fine, very nice, but…
the GPS Lon upload (Seriallog and BLE) only! is incorrect:
I receive UP Lon 1179.588280 instead of 5.18xxxx

seriallog:
Got semaphore
Interrupt Active 0x56
Z low
Y low
X high
More than 10 seconds since last position message, send now
GPS poll finished
Lat: 52.26xx Lon: 5.18xx <<<< is OK!
Alt: 18.0000 Speed: 0.0000
Valid GPS position
UP Lat 52.26xx Lon 1179.5884 Alt 18 Pr 0 B 105% <<< is not OK

Lorawan upload is correct!

can you please check? (I’ll investigate in the meantime too.

BR,
Jeroen

12

The differences between lines 344 and 345 would appear to contain a typo, however the output routine overall is a bit odd as it appears to have an attempt at sign extension that actually overwrites rather than extends. It’s not really clear why sign extension would be needed at all, but if it were it would need to target bytes of the result value that were not encoded in the transmitted one, rather than overwrite those that were.

In simple terms if one has determined that the scaled value fits in an int32_t (as indeed it appears to), then send that as four bytes and put it back together as an int32_t (simply transcribing bits to bits) and then do the floating point display math on that as desired. (Or at some cost in ultimate portability the fact that his is being done in the native little-endian ordering of ARM/AVR/ESP could even be leveraged, or using conversion macros that are empty on platforms where the order matches anyway)

It’s not clear that the actual packet data is going to be wrong; but then whatever decoder processing it on the receiving side could perhaps also have issues.

These kind of issues often persist in GPS-related code, because unlike many other values a given person doing testing will likely never see them change more than slightly, so most of the value space remains unexplored. A test routine that feeds fake NMEA sentences fro the proverbial “four corners of the earth” might not be bad idea.

2 Likes
13

Well spotted @cstratton,

Line 361 is also a typo and after I changed it to trackerData.lng_4 << 24 the data on BLE and seriallog is ok!
Lon: 5.18xx ~

many thanks,

Jeroen

14

Basically the sign extension logic should be removed in all places and replaced with simply using the 4th byte in its proper bit 31-24 position.

1 Like
15

Agree, I’ll test it too
Thanks again

16

Dear @bengee,

Just being curious, any expected date the related github topics going to be updated?

thanks, appreciated,

Jeroen

1 Like
17

Dear JeroenKl,

We are working on a complete update of the WisBlock repo, but it will take some time. The reason is that we will soon release another WisBlock Core module and many new IO and Sensor modules. This requires a different structure of the repo, so I do not want to put too much work into the existing one.
But I promise that all community feedback we received will be in the new WisBlock repo.

1 Like
18

Dear Bernd

The new repo/WisBlock Core/IO and sensor modules will be backward compatible? If not, what we can do with our existing not functional WisBlock modules ? We still waiting for a solution for the GPS issues…

Zoltan Magdo

19

Thank you @beegee,

In case you want/need help with some testing, please let me know.

BR,
Jeroen

1 Like
22

Dear Bernd,

Any expected timeline, when could receive some new info?
I know you are very busy but nevertheless I’m curious with regards the updates, you can imagine :wink:

thanks again,

Jeroen

1 Like