Downlink issue

You were already told that 2 minute intervals weren’t allowed.

Why are 15 seconds intervals even being mentioned in your posts?

Please return to step 0 where you have a gateway and two or three devices in the same room and you learn LoRaWAN really well before inflicting complications on yourself like trying to debug downlinks on a device 30km away whilst saying things that break the FUP - you know we hate that, well we’re not so keen on downlinks either - search the forum for more info, very particular the why and what happens to a gateway when you do a downlink.

I think you are spinning your wheels at present so I’d suggest you stop for now - get the device in the same room as you to debug things and as you have aspirations for a great TaDa roll out across your village, you really need to know LoRaWAN well before your neighbours start trying to warp time & space with their ideas and you literally break LoRaWAN / TTN in your area.

As a minimum, you need to know: https://www.thethingsnetwork.org/docs/lorawan/ which should get you to a point where you can get the basic certification. Inevitably you will end up wanting or needing to build your own devices, so getting good with Arduino & LMIC-node & an Adafruit Feather M0 with RFM95 would be a good start.

The documents are clearly written by someone technical who forgot to give it to someone else that doesn’t know the product - ie they forgot testing - as I’d not describe much of that section as a model of clarity.

Apart from the colours making things fuzzy, I think that’s a || aka a logical or between the different packet examples.

As you almost inevitably end up sending two bytes for a time period, I make it simple on myself for testing & anyone else using the console and use HHMM - although I’ve not ended up with any consistency on what to do if they send bigger numbers than 9 or more than 60 in the MM etc. But mostly the downlinks are generated from a UI so it can be sanity checked before hand.

Thank you for your advice. Anyway I understand to procede slowly and increase my skill step by step.
For studying I’ve only bought a gateway and a device, there are not more people insolventi, only the municipality is happy if this project will work some day in the future, it could be one, or two or 3 Years never Mind, in the respect of the regulation and local certification when installing everything: no things will be done with risk.
It was only a start and for sure I have a lot of question. Some young engineer could work as well on Arduino and build own devices, some others, old people could use a commercial end device, so this is why I bought a Browan GPS device, registered on TTN and see data on Cayenne, TTN mapper and anche Mqtt client.
I know that to have a good coverage could be necessary 5 gateway. Municipality looks very interested and appreciate my free study ( I don’t get any money for this, because is my village and i love it) and it would be very happy if one day in the next years if Lorawan could help to prevent fire events in the hills by using hundred of sensor that detect spike on temeprature or umidity. I’m keep studying on it, and ask for help in these topics to solve my doubts and go on.
If downlink is something that are not regular under TTN, we will not use it

Regards,
Paolo

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.

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

Regards,
Paolo

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

Regards,
Paolo

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.

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.

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.

@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

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.

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

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

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.

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

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.

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

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.

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.