I’m working on something now. I’ll put it on GitHub within a week, and post it here.
1 Like
Any news about that?
Thanks!
I added a GPS app here:
I haven’t tested this, other than seeing the data show up on TTN. I’ll have to write a payload function to unpack the 2 4-byte floats into their respective JSON fields to test this. Feel free to test it out. I’ll be working on this some more soon.
Okay, I finished the GPS app, more or less. It’s interrupt-driven, with an interrupt every 10s. So you can decide how many increments to wait between capturing and reporting coordinates. I also included the payload function.
This can (and should) be improved by
- Making the device sleep when not in use
- Making the GPS sleep when not in use
- Using SF12 for greater range
- More experimentation with the OTAA version to make joining faster
Thanks a lot, I will have a deeper look at this and will go back to you. I tried your OTAA connecting code and for an unknown reason, the card was randomly resetting and re-joining every 2 messages (separated by a 5min delay), while it sent 7 to 15 or 20 messages before. I thought it was due to newest firmware, but same thing with older one.
BTW, do you know what is the uFL antenna connector for on the board? Is that for LoRa chip, GPS chip or both?
Yeah, the OTAA thing is weird. For me, after about 4 tries, it stays connected. I’m not sure about this, but I think I’m supposed to be using the saved Device Address, Network Session Key, and App Session Key after a join, and re-joins just use those. Definitely needs some work, and I need to understand better what’s going on. To save join time, I’m just using ABP, but for production we’d want OTAA.
I’m pretty sure the antenna is just for the LoRa radio, because even the boards without GPS have them.
Ok so I tried your LoRaWAN library with latest firmware (2.1.15) and the change you described to me in another post for lora.setReceiceWindowFirst(0, 868.1); (I’m only disabling duty cycles checking for testing like in your sketch) and that works pretty well (I have sent 70 128ms messages each 6min, so over 7hours before having to re-join).
For GPS, I took some ideas from your sketch, the one there https://github.com/toddkrein/OTAA-LoRaWAN-Seeed and adapted it to cayenne lpp.
For the uFL connector, it is for LoRa radio, Seeed confirmed that to me with a picture:
About 2.1.15 firmware, do you know if that leads to LoRaWAN 1.1 compatibility (did you test it)? Does that send these kind of packets out of the box? Is the device compatible with other LoRaWAN classes than initially?
Thanks for your help 
Another question sorry, did you had a look at LoRaWAN library changes made by toddkrein there https://github.com/toddkrein/OTAA-LoRaWAN-Seeed ? I tried to use them quickly, but as I can’t easily disable duty cycles check with these, I didn’t make further tries.
As for if the new firmware complies with the new 1.1 spec, I’m not sure. Though, if you wanted to track it down, I would look at the latest AT command guide. Apart from that, I may look through the spec, and try to spot related changes in Seeeduino’s LoRaWAN library.
I did check out the Todd Krein one, but I felt weird about using a personal version of the library, when the standard one was working okay.
Beware that you should not hardcode SF11 or SF12 into a node:
Yes: How often should a node do an OTAA Join, and is OTAA better than ABP?
1 Like
Hi,
I’m having some troubles with the GPS payload: it looked like my GPS module was not running properly (?) that I only had timestamp, but not position data
So when I run the code of (and reference to) brady_aiello, I only got uplink of 0s in TTN console?
Do I need to manually start the GPS module somehow? I have 2 Seeeduino boards and they have this same problem.
Yeah, you’ll get garbage data (Lat = Lng = 0.0000) until it hears from a satellite. This may take a few minutes, and it generally helps if you’re outside. I’ve found that after it gets its initial coordinates, it tends to update pretty quickly.
Hi, I bought a Seeeduino LoRaWAN W/GPS. I tried to get de GPS coordinates with your codes but it did not conect. I read the LoRaWAN has a INPAQ antenna for gps, but i don’t know if it enought. I have a question, should I conect a uFL antenna? or are there a way to activate the NIPAQ antenna?
PD: I tried all code of this forum and it didn’t work.
Hi, I’d like to help if I can. You’re just trying to get GPS coordinates to show up on the serial monitor? You don’t need any GPS antenna to do that, but it helps to go outside, and sometimes you need to wait a minute to get a satellite signal. If you plug in the GPS code at the official wiki here, it should work: http://wiki.seeedstudio.com/Seeeduino_LoRAWAN/
I’ve copied it here for reference. Let me know if that does the trick.
void setup()
{
Serial.begin(9600);
SerialUSB.begin(115200);
}
void loop()
{
while(Serial.available())
{
SerialUSB.write(Serial.read());
}
while(SerialUSB.available())
{
Serial.write(SerialUSB.read());
}
}Hi, I tried so wait outside my house and near window for several minutes. Then I start to get correct NMEA data ouput on serial monitor. Thanks for the info
Hi,
Working around the same issue, I wonder whether there is a command to tell the GPS it should issue NMEA messages at a chosen period of time. For example every minute instead of continuously?
Yes/no/may-be. It depends on the module used. Also cheap china clones of reputable modules usually don’t store settings if you are able to set anything at all.
What would be the benefit of that ?
To be fair, I try and tell the uBlox to shut the heck up and only give me position when I ask for it - so that I don’t end up with a random interrupt processing loop raining all over the rest of the code or twiddling characters until we get to the start of an actually useful sentence.
Doesn’t stop me asking for position every 10 seconds if I so desire and/or if the accelerometer interrupt says that the thing in question in on the move.
I’ve got a fair collection but none marked “the GPS” so hunting down it’s manual, possibly called “the Manual” will be pretty hard. But you could …