Where did you get the code 1? Also where did you get code 2?
Yes. You got no GPS signal at all. Is the part of the GPS antenna with the tape (not the metal shield) facing the sky?
GPS will only work outside. GPS does not work indoors.
got one from the documentation on raks docs for the gps and the other came from github solutions for the rak 4630. So there is no way to get gps signals indoors?
The correct code should be here WisBlock/GPS_Tracker.ino at master · RAKWireless/WisBlock · GitHub
Yes. GPS is only for outdoors.
I did the sensor code by itself and was able to get correct coordinates. I was also able to see the right coordinates in the print on the gps tracker solution u sent me but My gps data keeps coming over the network incorrectly once the data is sent over helium or ttn.
This is my debug data in datacake over helium. When I tried TTN it kept saying longitude was 0, so something I guess in the payload decode is messed up. I’ll post the payload decoder at the bottom
[
{
"field": "LOCATION",
"value": "(7381.97504,0)"
}
]
Log:
null
Recorded measurements:
LOCATION = (7381.97504,0) (timestamp: auto)
Payload decoder is below. I am using the example gps tracker code in arduino
function Decoder(bytes, port)
{
var longitude_int, latitude_int;
var decoded = {};
if (port === 2)
{
if(bytes[0]==9) // check if the header byte is 9.
{
latitude_int = (bytes[1] << 24) | (bytes[2] << 16) | (bytes[3] << 8) | (bytes[4]);
decoded.latitude = latitude_int / 100000;
longitude_int = (bytes[6] << 24) | (bytes[7] << 16) | (bytes[8] << 8) | (bytes[9]);
decoded.longitude = longitude_int / 100000;
return decoded;
}
}
}
any idea why this code above is doing this?
Check first the output via serial logs. Then compare it to what’s being decoded.
The console is showing the correct longitude and latitude data in Helium. I can confirm that it is the payload decoder that is giving the wrong results.
function Decoder(bytes, port)
{
var longitude_int, latitude_int;
var decoded = {};
if (port === 2)
{
if(bytes[0]===9) // check if the header byte is 9.
{
latitude_int = (bytes[1] << 24) | (bytes[2] << 16) | (bytes[3] << 8) | (bytes[4]);
var latitude = latitude_int / 100000;
longitude_int = (bytes[6] << 24) | (bytes[7] << 16) | (bytes[8] << 8) | (bytes[9]);
var longitude = longitude_int / 100000;
return [{
"field": "LOCATION",
"value": "(" + latitude + "," + longitude + ")"
}]
}
}
}
This was a slight modification to the decoder just to be able to add the data into the widget but is still based on the same principles as the TTN Decoder here GPS Tracker Example. Why is the decoder giving this as the data points?
After running a test with the standard TTN payload decoder I can confirm that it is not giving correct gps coordinates, but it is in helium console debug. This is with the standard payload decoder from your GPS Tracker Example and is definitely giving invalid coordinates
The coordinates you see in the helium console is the location/coordinates of the hotspot/gateway, not your device. As I said before, it is hard to tell what is the root cause unless we see if the device is giving the right coordinates on the device level first and not on the decoded one in ttn or helium. That is the reason why I propose to check the serial logs first on the device level.
I did it with that gps example not connected to lora and it was definitely giving the correct coordinates. We traveled around town with a laptop connected and looked up the locations and everything came out fine. Something is wrong maybe somewhere between when it is submitted to helium or when it goes from helium to datacake and I use the payload decoder
When I use TTN it also gave wrong info too, same wrong info as datacake
If you test the only the GPS without the LoRa code, the test verifies that the GPS is working but we can’t verify if the GPS data is parse correctly in the LoRaWAN code before transmission. If I am in your case, I will test again and check the logs in the actual code used for the LoRaWAN transmission.
Check the coordinates before the payload is formatted as well as how the data looks before sending a s LoRaWAN uplink packets. Along the way in steps, one is is probably not right. I am the one who created that documentation with the decoder and tested it many times already 
Ok so when I use the gps ublox it is giving correct coordinates. should I try and re print ilat and ilong to see what it is giving before and send that to you?
We already know that the GPS module is working based on your independent test. What I am saying is on the LoRaWAN code you use.
For sure, I’m trying to figure out where I need to look or print out to see what/where things are going wrong. where do I need to make print statements to check these things?? The lora code I use came from rak example and has not been touched in the gps tracker solution/example ino file
I replied about this checking of data first (via adding Serial print) before the payload is formatted. You can back read about it.
Carl thank you so much for your amazing support. I finally figured it out. The key was that the code in arduino is wrong and I needed to grab that raw github and then add it to that code otherwise it doesn’t work. You will need to update the arduino sketch example for your solution but it does work great and i have it working on the maps. Thank you for your patience and thorough detail helping me out along the process. Great things to come!
One more question. Does the Rak have to be facing with usb up to get gps data even when a battery is plugged into it instead?
Hi @a1projects ,
That’s good to news.
Yes it still needs to be like that. But if you do not need the accelerometer functionality, you have to remove the conditional code block if(abs(x-z) < 400). Of course you have to remove the closing curly bracket pair as well.
1 Like