TTN mapper expects a json object, see details at https://ttnmapper.org/faq.php
TTNMapper recommends to use SF7, for moving nodes that is the best option. See this reply for calculations related to duty cycle and FUP.
Yes, you would ideally send the data in a as small as possible package to TTN. 9 bytes is doable for latitude + longitude + altitude + hdop
On the TTN backend side you then translate it into JSON using a Payload format function.
don’t send JSON of LoRaWAN!
Appreciate that is the case, and it helps establish ‘worst case’ coverage of any given gateway but I’m also interested in deriving minimum number of economically viable gateways to cover a given area or region hence looking at any usable coverage out at SF 10, 11 & even 12. Hence using LoRaMotes vs TTN mapper for now… will likely add to the TTN Mapper community once baseline for wider coverage established in my case… Meantime am following TTN Mapper progress with interest, ready…
- It could be that the first package is not received, then having another go after 30 seconds makes sense.
- No GPS data is perfect, so having multiple GPS measurements even while not physically moving gave @jpmeijers more data to work with
- can’t think of a real number 3, just that while debugging I’m usually not moving, so I like to be able to account for that state also.
Fair enough. I’m focusing on SF7 for now, but using SF11 or SF12 would just mean changing the intervals in the code. I was planning on using variables for them also, so they could easily be changed.
Great. That sounds like a plan
Besides the LoRaMotes have just taken delivery of some RAK 811 Tracker boards & sensor boards and have some RAK813/Trackers in transit so hope to start using all of them from early next month… also that’s when I will likely start contributing data to TTN Mapper.
When figuring out the usable coverage of a gateway to ascertain how many gateways you will need, it is still best to stick to SF7. Say you are measuring with SF7 in winter with trees not having leaves. In summer it will work on SF12. If you do the measurements on SF12 now in winter, in summer it won’t work at all.
So in short, SF7 is still the best for mapping coverage.
Fully appreciate that is the case…this exercise has been >>2 years* and 10+ seasons so far, for that very reason, inc now also looking at using GW’s ‘off grid’ sizing up & testing different GW’s to determine PWR consumption as running some on Solar Panels in more remote locales if that helps coverage. (agritech & logistics business model support + environmental monitoring)
- actually started low level/intermittent coverage checks >5 years ago with LoRa (note not LoRaWAN) running on SMTC Eval kits/Eiger units…
Guess there has to be a ‘Lab’ write up or two in there someday!
I’ve been trying to get this integration to work since TTN Conference with no luck at all.
I’ve used my mapper node with my TTN Gateway and the TTNMapper iOS app successfully, but sending interpreted data via the TTN Mapper integration through the TTN Console doesn’t work at all for me.
A general problem with integrations is that there’s no feedback (eg, is the integration server even running?). I’ve no idea what may be wrong.
Here’s a sample of my JSON:
{
“altitude”: 172,
“hdop”: 2.1,
“latitude”: 55.86328779836225,
“longitude”: -3.5050358477256225
}
I’ve tried adding extra fields, I’ve tried the “lat”,“lon”,“alt” fields that @jpmeijers sample code seems to use. I’ve deleted and re-created my TTN Application and removed and re-added the TTN Mapper integration several times. I can’t find anything that seems to work.
I’d be grateful for any suggestions as I would really prefer to use this method rather than the iOS app.
I’ll try to document my code this weekend. I did already update the github files.
The way I could see that it works is that I can see the tracker symbol on the TTNMapper website as soon as I powered it on.
@Codion I’ll contact you in PM to ask for your Application ID. Then I can check the logs on my side to see what is going wrong.
@piair Great setup which i would very much like to replicate. However the LoPy scripts throw a memory allocation error when loading MicropyGPS. LoPy ver 1.17.0.b1. No other active modules i’m aware of…
Anything special needed? Did you cross-compile MicropyGPS first?
Update 1/3/18: Yes, you need to convert MicropyGPS.py and tools.py to frozen bytecode mpy files using my-cross_pycom to fit in memory (see: https://forum.pycom.io/topic/1917/loading-pyc-files).
Update 2: managed to get all up & running! Thanks @piair or the jumpstart (you saved me much time).
While testing i noticed a problem: During the programmed sleeps the GPS will happily keep sending data which will be buffered. The uart.readln() just takes the first scentence (which could be pretty old). This can be avoided by reading the uart until there is nothing left before continuing.
Update 3: Finished testing and debugging and published the code and schematics at https://github.com/keptenkurk/pyTTNmap.
Thanks for the code!
I’ve also been working on the LoPy with PyTrack code that I adjusted for use with the TTN Mapper integration. Basically parsing another NMEA sentence, and also retrieving the HDOP and ALT values. I walked around with the node attached to a lipo to map my gateways while they are indoor. This code is not yet published.
And I was planning to enhance the micropython code, so that from the TTN Console I can send information downstream to control the send frequency. Alternative is to have geofencing around the gw location, so it doesn’t send data that often. Another alternative is to look at the NMEA information for ground speed, and dynamically update the frequency based on that speed.
Is the JSON format needed as simple as that template you linked there?
I’ve got it working with LPP, but I’d like to move to JSON integration as I have the additional HDOP value I want to send…
Yes it is that simple…
I have updated my Adafruit tracker with their GPS Featherwing, and it worked almost immediately.
I pushed my code on Github, with the associated decoder (which is specific to my payload)