Downlink issue

End Devices (Nodes)
21

This is where you are letting yourself down - it’s not TTN that’s not keen on downlinks, it’s ALL LoRaWAN networks - and you do not appear to know why and you do not appear to have gone to find out what the problem is for a local area when a gateway is transmitting a downlink.

Downlinks are fine here and there - I figure on one a fortnight for device signal strength check for a device that is in a ‘safe’ coverage zone. And occasionally a device may need its configuration changing, typically on season change (no point monitoring soil moisture levels whilst there is no crop in the fields, may as well save battery life).

But if your use case for a device is fundamentally reliant on downlinks, you need to rethink the use case. Because connectivity is not guaranteed, by which we mean it may not get through for a number of hours, days even.

It is also a bit unfortunate that you have chosen a tracker as your first device, as the usefulness of such a thing with LoRaWAN is questionable at best and often prone to not meeting expectations. Again, multiple discussions on the forum for you to read.

TTN Mapper is for radio / gateway coverage - it’s an engineering application, not something end users will benefit from.

I think you gave up too quickly on the water meter - there are other ways to detect water issues as mostly they come from leaks and detecting leaks is something that LoRaWAN is a very good use case. You could have 100 of them setup before the cold weather starts bursting pipes and provide an excellent first project for your community.

And while you are working on the water issue, you can research fire detection for your forests for spring.

22

About downlink, yes , the point you wrote about occasionally review the configuration change. We can’alt Accept always default configuration of seller

Regards,
Paolo

23

Nick, do You have any good example of
successful project with pictures about water leaks detection in a public area?

Regards,
Paolo

24

That’s definitely true… I think we’re getting to the point where the OP needs to be asking the vendor.

That would appear to be simply visual, as the first screenshot example in the thread has multiple command sequences concatenated together and explicitly list their total of 9 bytes as the payload length - again, exactly the same mechanism as lower level LoRaWAN MAC commands and responses use.

25

Those are examples of responses. The commands to send imply a command byte with 2 bytes as a value.

This is pretty much consistent across the Browan manuals.

27

No one is expected to accept the default configuration of the manufacturer.

But we do ask people to find out about LoRaWAN - what have you found out about downlinks and their impact on the gateway and consequently the other devices in the area.

Yes, no, maybe, water leaks in public areas aren’t my thing, what does Mistress Google come up with?

But find out about downlinks first before I wonder if we are just helping facilitate a future train wreck. I trust you understand that it’s all volunteers answering on here, no one is obligated to help you, so some co-operation helps, particularly if the people answering have some modicum of experience and are desperately hinting at important things you really need to know and even provide a link to that basic information and suggest searching the forum for information.

28

@paolotr @descartes

I received an excel with a downlink calculator. Maybe you can use this one

Oeps… it’s an excel sheet… I can not add it to this post

Try my Dropbox link:

Suc6
marc
www.ttn0478.nl

29

Hmm, the payload in that spreadsheet is, well, absurd

But if it’s accurate, then not only are the command sequences legal to concatenate together but also raises the possibility that you might actually be required to specify everything in the downlink.

To bad the concept of “use your words” seems to be lost on this vendor.

30

It sure looks like a big bag of WTF and doesn’t really look much like the manual.

Any hoo, the OP can play with it and give us some feedback.

1 Like
31

At the end Brown object locator has been updated with a different time interval to send uplink.
Command for downlink to set a different interval was as written in their manual but with the flag in the Confirmed downlink . In the first trials I did not flag that option

Regard,
Paolo

32

I guess it’s sort of vaguely implied by the first command saying “only for unconfirmed downlink”.

But I continue to be concerned that you are still unaware of the consequences of a downlink to a local network.

33

I understand your point and what you said. At this step there is only a gateway and only a sensor.
In the future when there will be more end node I won’t use downlink

34

No, I don’t think you do.

No one has ever said don’t do downlinks - most of us use them appropriately - what is of concern is that you want to use a community network without understand how it works and the potential impact on it.

If people ask for help with trouble shooting it is always more efficient if they have a basic understanding the of the technology. Particularly if they want to setup devices in their neighbourhood that may be compromised by not understanding the fundamentals.

35

So this is why we are still learning. We take your advices, we are a group of engineers in our communities that we are learning. No one gateway will be released for public before knowing everything about risk. We Are not crazy to release something that could ve shut down everything
Regard,
Paolo

36

There is no evidence of that - I recommended 17d ago for you to find out what impact downlinks have on gateways but you still can’t tell me. It’s not fair on volunteers to answer questions if you do take time to learn the basics.

37

Nick, you’re right.
We will not write any further questions before learning and having answer on any questions about the basic knowledge of the system.

38

Sadly, both sides of this argument seem to have diverged from the facts of TTN and LoRaWAN.

Actually, every gateway connected to TTN is for public use from the moment of its connection. There are no private or “test” gateways.

The impact of a one-time or otherwise rare configuration downlink is next to nil. Downlink for purpose of configuration is quite normal, appropriate operation - after all, that’s what OTAA (the officially recommended method solution!) fundamentally is as well - a downlink to configure the node with a shorthand identity to use on the network and some other related details of the network.

Now, what is actually detrimental to the network?

One things that’s drastically worse than sending a downlink through a gateway, is unplugging it! Sending a downlink “removes the gateway from the network” for anywhere from say .1 to maybe 1.8 seconds (possibly a bit more if it runs out of airtime). In contrast, unplugging a gateways means it’s gone gone.

And that’s actually a lot worse. LoRaWAN’s ADR scheme adapts pretty quickly to the appearance of a gateway, in that nodes (including other people’s nodes) start transitioning to a faster, shorter range data mode to take advantage of a newly closest gateway.

But when the new gateway vanishes, it can take hours to even days for nodes to roll back to a data rate where they have the range to reach the next nearest surviving gateway.

So in actuality, if you’re going to plug in a gateway, feel free to send the occasional appropriate downlink through it. But if you want to be a good TTN citizen, then don’t plug in a gateway temporarily, but rather put it somewhere that you can leave it running for months on end.

The only private, temporary, test gateways are gateways that never connect to TTN’s severs at all.

(That said, using a 50 ohm terminator on the gateway instead of antenna would probably confine receive coverage to tens of meter’s radius, minimizing impact on others - it’s quite possible traffic to your nodes would go through someone else’s gateway at that point, but presumably the reason for doing this at all would be when you’re too far from any other gateway for intended tests)

39

I was referring to the apparent preference (this thread & on Slack) to asking questions & not using the documentation that was linked to, to understand the core concepts - mostly related to the FUP, both up & downlinks.