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.
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.
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
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!
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.
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.