Gateways locations information in the payload header

[descartes (Nick McCloud)]

@claudiormrosa

Both gateways and the Field Testers are in my desk, this is reason the RSSI is so strong.

That’s EXACTLY my point. YOU ARE SHOUTING AT THE GATEWAYS SO LOUD YOU ARE OVERPOWERING THEM. So it’s likely that one of them is being so overpowered that it’s ending up with a CRC error and not being uploaded.

There are no circumstances worth debugging gateway/device issues when the signal strength is so high.

Given the signal strength and it all being on your desk, it seems pointless to try to figure out why the other gateway appears to work when you turn the first one off. And it’s hard to comment when we don’t know makes & models and how many you have, connected to what, etc etc.

To be clear, yes, if your gateways are able to hear your tester, the message is not corrupt, then you will get the gateways listed in the metadata.

Did you search the forum as suggested? Did you try the simple test of moving further away from the gateway? Did you check the gateway logs?

If not, what would you suggest that we suggest to you that you may be inclined to try out? There is no point asking for assistance and then not following advice.

@Jeff-UK

WHat works for one should work for the other

The Chirpstack gateways could be somewhere else - or by some random quirk of moving stuff around between tests it works.

[Johan_Scheepers]

@Jeff-UK

WHat works for one should work for the othe

It is not a LNS issue, this is a issue where the OP don’t understand LoRaWAN and the equipment been deployed operating parameters.

[Jeff-UK]

@descartes, @Johan_Scheepers indeed, of anyone I get that even if OP doesnt, but I come back to

@Jeff-UK

OP is implying that under same GW saturation conditions it works on Chirpstack, but not on TTN?

And we need OP to clarify. Havent seen suggestion of different GW’s at this point, and we have guided to increased seperation. It may well be that OP has never actually tested the Chirpstack Decoder using CS GW’s, again need to confirm, and as LoRaWAN is LoRaWAN and a decoder is a decoder in same circumstances it should work in either BUT if OP has ignored suggestions wrt getting the RSSI down to acceptable limits through seperation and absorbers as all three of us have now suggested and as recommended on many Forum threads, if only OP was to use search!, then guess we may never know…

[claudiormrosa]

In fact @descartes alert me about another problem, that ADR is not doing the Tx Power adjustment as I was expecting. I was expecting the TTN LNS the lowest power level, if I am not wrong, in RAKWireless LoRaWAN Gateways 7249 and 7258 it is 2dBm.

But what I was expecting it is to find the number of gateways in the coverage zone, in the Chirpstack this is a feature called “Gateway Discovery”: Features - ChirpStack open-source LoRaWAN^® Network Server

In other words, it is how my is being seen by the all gateways in the coverage zone

Is it more clear now?

Cláudio

[Johan_Scheepers]

@claudiormrosa

Tx Power adjustment

Save your self some head acks and us.

@descartes

RSSI = -11 - wow, just wow.

@Johan_Scheepers

overloading your gateways RX

@Jeff-UK

Can you get 3-5m additional seperation between all elements, pref with some kind of absorber inbetween - window, wall, etc… as that will likely remove all doubts & concerns

Just move your gateway and node apart, get the RSSI down, ADR ain’t going to fix it.

100’s have tried it and 1000’s have failed at it.

[descartes (Nick McCloud)]

@claudiormrosa

that ADR is not doing the Tx Power adjustment as I was expecting. I was expecting the TTN LNS the lowest power level, if I am not wrong, in RAKWireless LoRaWAN Gateways 7249 and 7258 it is 2dBm.

ADR is entirely on the device and TTS does request a power drop once it’s hit DR5 but yes, it is possible for the gateway to be told to reduce power. But the gateway output is not the issue here.

As to the network discovery, apart from the curious idea of rendering a gateway deaf whilst it talks to other gateways, the simple presence of uplinks from devices is more than enough to create a rough & ready coverage map if you need it.

@claudiormrosa

Is it more clear now?

Not at all, you appear to have confused ADR & gateway power settings and you’ve asked about a feature that’s not available for reasons that are immediately obvious to me and I’m not a member of “Team Gateway”. Your device will need several uplinks before ADR starts to take effect and the gateway transmit power is irrelevant at this stage.

This all looks like a distraction from your original issue which appears to be that you have your device & gateways too close and it has been recommended that you move them 5m+ apart with a wall in between. A test that need only take a few minutes.

If you have other issues unrelated to your RAK10701, please can we solve this one first or close it and then you can open a new topic on power levels. Feature requests like “Gateway Discovery” need to be posted on GitHub for consideration by TTI.

[Jeff-UK]

@claudiormrosa

alert me about another problem, that ADR is not doing the Tx Power adjustment as I was expecting. I was expecting the TTN LNS the lowest power level

To clarify 1st step wrt ADR is changing SF’s! So if SF10 is giving a good link quality with appropriate signal margin then the LNS may command SF9, then SF8, then SF7 etc, or may just jump to commanding SF7 if signal is very good to start with and over a number of messages. Only once at the shorted SF (lowest value) will it then start to look at dialing back the power level! Of course per all the advise and hints/instructions so far this is predicated on the idea that the device has effectively joined, is recognised by the LNS and signals are manageabe such that there is no corruption or CRC errors etc, which the LNS will consider as equivalent to a signal that is too weak and therfore potentially not demand an ADR related SF change. Job 1 therefore get the RSSI values down to manageable levels, then the LNS and system will start to do what they are designed to do…and not before!

Manageable mean say -50 → -110 with a reasonable associated SNR, in practice we recommend -60-100 as a prudent range Hence need for seperation and absorbers…

[Johan_Scheepers]

@claudiormrosa

But what I was expecting it is to find the number of gateways in the coverage zone, in the Chirpstack this is a feature called “Gateway Discovery”

The gateways your gateway can TX/RX too is not necessarily the same gateways that can receive your node.

From gateway A to gateway B their is a clear LOS. Your node could be hidden behind a hill from a gateway A and clear LOS to gateway B. So it does not mean that A have clear LOS to B your node is going to see both.

But this is hijacking the thread, start a new one if you want to discuses something ells.

[claudiormrosa]

Thank you by your support.

We can close the ticket.

Regards,

Claudio

[descartes (Nick McCloud)]

@claudiormrosa

Thank you by your support. We can close the ticket.

Pardon? This is the community forum run by volunteers, not some nightclub where you can love & leave in the morning. At the very least we like feedback on the solution found to expand the knowledge base.

But it appears you should already know this:

@descartes

The forum is entirely run by volunteers so we ask people to use the forum search to see if something has been answered already - or multiple times.

[claudiormrosa]

“Nightclub”, sorry I didn´t understand your point, but you that it is not first time that you are not exactly polite with me.

But anyway I wish you a good Sunday.

Claudio

[descartes (Nick McCloud)]

@claudiormrosa

it is not first time that you are not exactly polite with me.

I think you are confusing polite with direct - if you can show me where I’ve been rude I’ll happily apologise.

The bottom line is that we are not commercial so some thanks is due, not just a dismissive “close the ticket”

And you have not told us what the solution is.

This is a community, if you treat people like this, you should not expect much response if you need help in the future.

[claudiormrosa]

I am still looking for the solution. I suggested to close the ticket but when I have the solution, I will share with all community, because I think that everybody has something to learn and to teach. I have a lot to learn everyday and I try to share with everybody what I have. This is me.

Claudio

[descartes (Nick McCloud)]

I think we are still hoping you’ll just put some separation between the device & gateway as that’s often the problem with a receiver not hearing a transmitter - literally comes up two or three times a week.

[Johan_Scheepers]

Simply pick up the nodes, take 10 steps and put them down, what is the results? 15 post less would it have been

[claudiormrosa]

Take a look in the Raw Payload that it is coming from TTN to the TagoIO. My point is that in the “gateway_ids” I just can see one of my two gateways (RAK7249 and RAK7258).

Maybe I am wrong but I was expecting to see both gateways. Is it correct?

{
        "variable": "ttn_payload_v3",
        "value": "{\"end_device_ids\":{\"dev_eui\":\"AC1F09FFFE08E7AF\",
										\"device_id\":\"eui-ac1f09fffe08e7af\",
										\"application_ids\":{\"application_id\":\"rakwireless-field-tester\"},
					\"join_eui\":\"AC1F09FFF9150701\",
					\"dev_addr\":\"260BED93\"},
					\"uplink_message\":{\"frm_payload\":\"0D8MnssBBBYLCQ==\",
										\"f_port\":1,
										\"f_cnt\":2793,
										\"session_key_id\":\"AYb+daPeaUVdGsjZkawKGQ==\",
										\"rx_metadata\":[{\"gateway_ids\":{\"gateway_id\":\"brrjnasondasgw01\",
																		   \"eui\":\"60C5A8FFFE74D380\"},
															                \"time\":\"2023-03-20T21:48:56.559190034Z\",
															\"timestamp\":2370786211,
															\"rssi\":-12,
															\"channel_rssi\":-12,
															\"snr\":8.75,
															\"location\":{\"latitude\":-22.998018054874855,
																		  \"longitude\":-43.38812005529691,
																		  \"altitude\":5,
																		  \"source\":\"SOURCE_REGISTRY\"},
															 \"uplink_token\":\"Ch4KHAoQYnJyam5hc29uZGFzZ3cwMRIIYMWo//5004AQo6e96ggaCwjJqeOgBhC0lqcVILjp+u7//Bc=\",
															 \"received_at\":\"2023-03-20T21:48:56.945147562Z\"}],
										\"settings\":{\"data_rate\":{\"lora\":{\"bandwidth\":125000,
																			   \"spreading_factor\":7,
																			   \"coding_rate\":\"4/5\"}},
													  \"frequency\":\"915800000\",
													  \"timestamp\":2370786211,
													  \"time\":\"2023-03-20T21:48:56.559190034Z\"},
										\"received_at\":\"2023-03-20T21:48:57.045688303Z\",
										\"confirmed\":true,
										\"consumed_airtime\":\"0.061696s\",
										\"locations\":{\"frm-payload\":{\"latitude\":-22.9978493,
																		\"longitude\":-43.3880212,
																		\"altitude\":26,
																		\"source\":\"SOURCE_GPS\"}},
										\"network_ids\":{\"net_id\":\"000013\",
														 \"tenant_id\":\"ttn\",
														 \"cluster_id\":\"eu1\",
										\"cluster_address\":\"eu1.cloud.thethings.network\"}},
					\"correlation_ids\":[\"as:up:01GW0FYCH621SCR0GMK9KSW3CW\",
										 \"gs:conn:01GVXBC8B0QFV2NPXRAPDVGQA1\",
										 \"gs:up:host:01GVXBC8B8F09AXT49NENTJ3QQ\",
										 \"gs:uplink:01GW0FYCAMH9CVH4K5KBG5267Y\",
										 \"ns:uplink:01GW0FYCANERHAW7GD81CTJ48Y\",
										 \"rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01GW0FYCAN3XRDCD33256TH4KE\",
										 \"rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01GW0FYCH57Y0DDFKER059PXSW\"],
					\"received_at\":\"2023-03-20T21:48:57.254112409Z\"}",
        "group": "1679348937325"
    }

[Johan_Scheepers]

@descartes

RSSI = -11 - wow, just wow.

The first gateway is feeling very poorly - you may need to take it to an audiologist to get it’s hearing sorted out. I suspect your other TTN gateway is unconscious due to the shouting.

@Johan_Scheepers

You are busy overloading your gateways RX, you are lucky that one of the gateways are actually processing the packet successfully.

@Jeff-UK

Can you get 3-5m additional seperation between all elements, pref with some kind of absorber inbetween - window, wall, etc… as that will likely remove all doubts & concerns

@descartes

That’s EXACTLY my point. YOU ARE SHOUTING AT THE GATEWAYS SO LOUD YOU ARE OVERPOWERING THEM. So it’s likely that one of them is being so overpowered that it’s ending up with a CRC error and not being uploaded.

@Johan_Scheepers

Simply pick up the nodes, take 10 steps and put them down, what is the results?

@claudiormrosa

Maybe I am wrong but I was expecting to see both gateways. Is it correct?

You are wrong, sorry for been so blunt, we have dealt more times than you had breakfast with this issue, and it is 99% chance this is the issue.

Follow the advise on the RSSI, then we can look and see if anything else is wrong. (this is for your equipment sake)

And by having very fast browse, your one gateway ID is brrjnasondasgw01, may I ask the other gateways ID? As I don’t pick up one in the close vicinity (except if its location is not set, then I will not pick it up)

[Johan_Scheepers]

Can you also please dial back on those messages? On every 15 sec you are exceeding the FUP. You are only aloud for total uplink time per day 30sec.

“consumed_airtime”:“0.061696s” x 5760 messages per day = 355,36896 sec per day

Your gateway “rxRate”:240.90814 per hour, equites to a message every 15 sec

[descartes (Nick McCloud)]

Looking at the console screen shot that clearly has another gateway in the meta data but is not on view and taking the description of:

@claudiormrosa

Take a look in the Raw Payload that it is coming from TTN to the TagoIO

and the change in format of the JSON in the quoted message, perhaps the issue isn’t that both gateways aren’t appearing in the meta data (hard to tell without seeing the entire of the console event details) but that the original opening description was referring to the data as it appears in TagoIO.

As this has only just come to light and because the device is hammering TTN way beyond anything reasonable for the Fair Use Policy, I’m closing this thread because it has, as a notable Python would say, got silly.

@claudiormrosa, can you look at how you originally presented the information, what we asked you to try that as yet hasn’t been actioned, read up on the Fair Use Policy and look at the entire of the device JSON. It is still not clear to us if both gateways are on TTN, if only one is, then you should only expect to see data for one.

If it transpires that both gateways are on TTN and being heard as seen in the device meta data, you’ll have to take up the issue about why they only keep the first gateway entry with TagoIO. This is a common JSON processing error - device health & mapping is all about having more than one gateway hearing a device.

After you have reduced uplink interval inline with FUP and the RSSI to a reasonable level as detailed above, if you are still only getting one gateway entry in the TTS meta data, then please open a new fresh topic with a more considered description, copy & paste text carefully formatted, only use screen shots when you can’t, show both gateway logs, both gateway console entries, the device console JSON and the TagoIO JSON for the same point in time - this takes a few minutes to setup the browser windows but if your device is only uplinking every 3 minutes, you will have about 90 minutes to capture all the information before it all scrolls off the end.