I have just migrated from v2 gateway to v3.
So, instead requesting for a copy of v2 gateway range, thought of doing the ranging again with my GPS node.
TTN mapper is showing my gateway in its map, but the heatmap is not yet available. In advanced maps, I am able to see the CSV format points of my location uplinks. The below link shows the data.
Is this normal as it is a work in progress? Or am I doing something wrong here?
Most of the data points are near the gateway, but there are points which were done for ranging. The required fields are present and the accuracy is mention in âhdopâ meeting its requirement in most of the cases where GPS signal was clear.
NB:ABP device. The server asks to get to SF12 (adr is disabled on TTN Console) on the first message and the device does. So all uplinks are in SF12 instead of recommended SF7
with a 20-30 sec update rate you massively breaching the TTN FUP, indeed that would be with just SF7âŚwith SF12 you are basically hitting the policy with sticks of dynamite! Stop it pleaseâŚread up in FUPâŚ
havenât bothered decoding the coordinates but depending on where you are in the world likely also massively breaching legal limitsâŚhope you like handcuffs as a fashion accessory!
was initially concerned at your RSSI valuesâŚearly data on view (most recent time wise) suggests likely you resting your tracker on the gatewayâŚanything higher than -40 like shouting in each otherâs ears and really should be looking at below -50⌠then I saw that data further down list (older) more sensibly in the -70 to<-100 rangeâŚgood values for tracking and getting decent signal to gw but you really need to get that SF downâŚand when I see RSSI values >-20 I get concerned for potential damage to gw or node!
Donât know how long you have been collecting data but IIRC it can take >24hrs for data to start to show on the mapâŚsometimes less and sometimes moreâŚ
Yes, you are right about the limits. I have been violating all the limits. I have read about the number of uplink-downlink limits and datarate air times etc.
But, you might have seen there is only one gateway and one user of that gateway in my area. The other two is from a state run open source which is well away from my possible frequency jams.
I have purposefully limited the times as I am running both gateway and nodes on experimental basis and possibly showing out its capabilities for increasing the usage of LoRa in my locality.
I would definitely come down to the air time limits when I fit everything together. Moreover I think I havenât breached the limits of the gateway for a day as I am the only user. So i think the network counts are still legal for me
Yes the gateway was close most of the time as I said, I am setting things up and it was part of the antenna testing. The antenna was a custom coaxial collinear antenna 8 array. So wanted to check its capability just outside the near field. Hope the RF front end hasnât taken the hit with that LNA switched ON.
The legal limits of transmission are 4watt EIRP (1 watt maximum) in 865-867. Location is India (South).
Both are transmitting only at 20dBm. Even with 8dBi of gateway antenna doesnât take it to even 1 watt or 30dBm. So since I didnât find any dutycycle specific limitation I think I am ok or in a manageable position.
Sensible values have passed atleast 48hours. There are many readings which were near gateway which are days old.
Basically you have no way of knowing! Not all GWs are declared openly on the maps⌠remember that tick box option when registering gw to âmake location publicâ, many commercial operations, state users and some more paranoid users () sometimes choose not declared e.g for device security reasons⌠or may dither actual gps location vs real deployment. Also with such high power Tx and high SF itâs possible get get a L O N G way with the signal⌠you know LoRa, thatâs Long RangeâŚclever marketing chaps those Franco Swiss! My own ground to ground record not at height! Is >>70km at SF12⌠and that at a mere 14dbm⌠like I say, please donât do thisâŚeveryone says âbut I am onlyâŚâ
If trying for 48hrs+ then something likely wrongâŚcan you share your TTN Mapper integration set up so we can look?
You are right about the private gateways. But even the community here in my city hasnât got their gateway running to my latest knowledge. So I was expecting the place to be just barren. I have kept the gateway running for almost a year in v2 not getting any signals other than mine. (gateway had description of the its reception frequency in maps). Moreover the terrain is very tough with tree line surrounding me. I hardly got 4Km range that too only in a tiny sector. But these are not any excuse, I would abide by the network rules when things are out of experiment.
I wanted it to be in SF7. In v2 it was where I used a GPS node hardcoded to SF7. In v3 I thought of being a bit more professional so used the exact LMIC version and now the server asks me to go to RX1 delay 5 as per the console and request for SF12 in mac commands opts.
So it automatically goes to SF12. I can hardcod SF7 if SF7 is the issue with the mapper.
Now for the last part, that line worries me. I thought I was good till there, as the data came up in the ttn-mapper. So I never went through any possible webhook integration problems. Please donât go havoc on me if thats where I went wrong. I know everyones time is precious.
Ok the settings. I will attach the image. I can see webhook pending, but I didnât mind it as I received data to ttn-mapper.
What device are you using (full h/w inc rev & firmware versions please) - inc LMIC version (source) and if home brew IDE/Dev environment (those who know about such things will only ask if I dont so lets get all details on the table at this point and see how we can get you running)⌠all was good under V2 and you had TTN Mapper with same device working OK?
Are you seeing correctly decoded data in the Device Console etc? ( I am assuming yes give the data link above but have to ask! )
BTW you might want to edit out/mask your email add in the post!
Have you used the TTN Mapper advance maps to select just your gateway and look at data/heatmap and similarly to just pick your device to look at any of its data plots - if data values getting to TTN Mapper usually you will see something even if not accepted/filtered out for main map - also I see you may be running as experimental vs main map? Check under experiments!
I already mentioned these in one of my earlier post, so I am doing a copy paste.
Hardware:
Lora Gateway: Raspberry PI + RAK833 SPI SX1301Chip
Lora Node: Atmega328p + HPD13A Sx1276 (RFM95W Compatible) - pin mapping has been taken care off. (DIO0 and DIO1 has been wired)
(memory is OK to work with and not affecting any normal operation of radio, but I am not sure if it affects any AES algorithms, possibly not otherwise the node should keep restarting)
Distance between Gateway and node is nothing but with in the room, which can be seen from the RSSI and SNR.
Software:
Gateway Current: v2.1.0 (GitHub - Lora-net/packet_forwarder: A LoRa packet forwarder is a program running on the host of a LoRa gateway that forwards RF packets receive by the concentrator to a server through a IP/UDP link, and emits RF packets that are sent by the server.)
Node Current: MCCI LoRaWAN LMIC Library v4.1.1
Region & Frequency:
Current: India (standard 3 frequencies used, others used in accordance with EU like style)
LoRaWAN MAC and PHY:
Current: MAC V1.0.3 and PHY V1.0.3 REV A
Activation mode:
ABP
History:
v2 gateway was running on the same version. Node was hardcoded to send only the GPS cordinates in payload at regular intervals. v2 GPS node was like a dumb transmitter which send only the required payload to the ttn-mapper integration node. It was working perfect :innocent:
The console data is decoding the payload correctly to long, lat, altitude, hdop etc.
Email, yeah I forgot about that. Anyway I think its ok if its legal, any querries are welcome, if I get to an expert one day. Otherwise I will post with masked images again.
??Where - not in this thread? Please dont expect people who may help to have to go off digging/looking! I did see you comment (at least your user ID elsewhere today ) but woudl not expect to go hunting!
That works We would not neccessarily associate device in one thread with a device in another and the mods and contributors may not read all threads in detail or in a given orderâŚ, as volunteers we often âcatch upâ out of order and out of hours after taking care of our day jobs!
As you can see in Node CSV as well as earlier shared gateway CSV, that the experiment is Gateway Range Map, which is I think the actual ttn-mapper experiment.
Sorry I was asking for the excuse of doing a copy paste. Not the other way. Sorry if I gave you the feeling that you should go and look for my old post. I would never dream of that. As I said everyones time is precious.
Dont sweat it - just saying given comment above bout getting all details out!
BTW in case you hadnt seen looks like (if I have have it right) you are one of maybe 5 other public/visible Gateways in reasonable range - hope your Txâs not saturating their GWâs/apps!
Especially as the one closest to you is a Medical Service - I hope they are not doing e.g. critical temp/cold chain monitoring of Covid Vaccines for the community!
You might want to try loosing the experiment and just run as a user contributing to the MAP - if using in an exceptional way such that coverage would not be valid for other general users - e.g. sending from a HAB - then may not need experiment status. Just contribute to the coverage overall
Per the documentation: Experiment name (optional): You only need to provide an experiment name if you are testing and do not want your mapping results to contribute to the main coverage map for the network. In other words, when you are mapping normally with a device that is between 1 and 2 metre above ground level, you can leave this field blank. If you are doing anything else like launching and tracking a ballon, please provide a unique experiment name here. Adding the date to the experiment name helps to find it again later.
The said medical service gateway go in and out in days. The same with the 3 gateways in our organisation. Other than medical gateway, other three are in known and verified for any interference with spectrum analyser but was some time back. Medical service is not using any frequency in my list, as I have received only one node packet and only in one frequency for the last one month. But again, its just there much difference between Europe and India. I think we might be trying to bring things up here. So, everyone is just starting. The complete spectrum is free in spectrum analyser. So, trying out things.
Anyway I will delete the field from the integration which names the experiment as Gateway Range Map.
So that means I will come back after may be atleast 36 hours.
But I am still confused why didnât it appear in the experiment heat map, when experiment CSV data is available.
The ttn-mapper showed the heatmap almost immediately on receiving the first location data. It didnât take 24 hours. So the heatmap is shown.
But, my two doubts remains.
Why server asks me to switch to SF12. I tried to make SF12 as not available from LMIC. So after sending SF12 not possible mac update, server asks for data rate of SF7. But further mac updates of confirmed data rate change to SF7 doesnât seem to stop server from asking for SF7 data rate request on each uplink.
Why my experiment data was not shown in heat map for node, gateway and experiment, when the CSV data was present.
Which exact version - GitHub repro or the name that appears in the Arduino/PlatformIO library list - and the numbers to go with - LMIC only recently supported most MAC commands properly.
Thatâs a question for the creator of TTN Mapper - itâs not actually part of TTN so the inner workings & support are more in his domain.
Thatâs to tell the Network Server not to send any ADR MAC requests.
Thatâs LMIC sending a header that says it will co-operate with any ADR requests. This shouldnât make any difference to the NS as itâs been told in the console not to do ADR but the ability to turn off ADR is a new console feature to the v3 stack so there could be some permutations that cause things to happen that werenât part of the plan. Plus âŚ
⌠the LoRaWAN Alliance requires network operators to limit devices that run on SF11 or 12 but Iâve not figured out if or how that may be implemented - which could mean that deep in the heart of the stack there are a few lines that do send ADR requests for devices that are burning up the airtime. Or not. Itâs all a jolly big learning curve of reading code & trying stuff out. I do have my suspicions on some combinations as I have devices on the bench that join and do uplinks at a reasonable interval and never get sent any MAC commands and then another build or different library or version (I use LMIC for cheap & cheerful devices and LoRaMAC-node for STM32 and Microchip LoRaWAN Stack for SAMR34) and the device gets hit at a ratio of 1 downlink for every 3 uplinks for itâs first 500 or so uplinks by which time I think the NS gives up trying to get itâs way! Go figure! Itâs on the list of things for my student placement to debug, or me if it turns in to an issue for a client device.
It was ok if the NS request was the other way round like asking me to accept SF7 instead of SF12.
But NS ask me to go to more airtime. If I do a range mapping it would be misleading for future users.
I donât feel good to ignore the request as NS didnât stop even upto 1000 uplinks. Its like wasting so much of airtime as NS keeps trying for SF12 when i send in SF7.
I can very well do that, just need to make SF12 invalid in in866lmic.c, but then NS never stop asking me and that means gateway is as well taking airtime of users.
So if I am not doing anything stupid here, which I have been trying to sort out for atleast a week now.
I have one more input.
I send a payload when node is switched on. Frame count is 0. SF7
Sever starts request for SF12.
I send back Mac command saying SF12 is not acceptable.
Server now ask ok change to SF7.
I send back. Ok SF7 is accepted. 0x03 0x07. If I remember right
But NS again ask me to get to SF7 for all next uplinks. (Last uplink already had SF7 confirmation and the last uplink was in SF7)
NB: The same server stops the request if I accepted SF12 and started uplinks in SF12
) sometimes choose not declared e.g for device security reasons⌠or may dither actual gps location vs real deployment. Also with such high power Tx and high SF itâs possible get get a L O N G way with the signal⌠you know LoRa, thatâs Long RangeâŚclever marketing chaps those Franco Swiss! 
