Hi everyone, I tried a downlink to my Browan object locator from TTN by using schedule downlink under Messaging in my end device: port 204 and exadecimal payload sent as for content in the device doc without flag Confirmed downlink, but nothing changed in the default setup for update event interval or keep alive interval. I don’t know where I’m wrong, I see in TTN forward downlink under live data but nothing else.
Regards
Paolo
How exactly did you submit the payload to TTN?
Eg, it looks like it should be a sequence of raw bytes with that hexdump (it had better be if the designers weren’t naive), did you perhaps submit it as an ASCII string instead?
I did this:
Regards,
Paolo
The phrase “Response Content” could mean that that’s an example of the message you will get in response to a downlink.
Sorry below the appendice two with the command:
I think maybe I see the problem.
Notice how there are two fundamentally incompatible uses of the command code 00 which required different following lengths?
I bet the 0-following-bytes “get” form is only for unconfirmed downlink as stated.
But what they may have neglected to say is that I bet the “set” version is only for confirmed downlink.
Otherwise I can’t really see how the parser could distinguish them.
So I think you need to send a confirmed downlink.
If not, you may ultimately need to get in touch with the vendor
I did 5 minutes ago as you said, selecting Confirmed Downlink and send a payload equal to 017800, that send upling every 120 seconds when is in stationary mode, as it is now. Now because I’m far from my end node I don’t Know if it would be necessary to power off and then power on again the sensor. Uplink in stationary is setup be for this command every 2 Hours, that is the default now it is worked so far. I sent the command above only to see if I have a quick response
Regards,
Paolo
Unclear if you are saying that worked or not.
If you are far from the gateway, maybe the downlink is simply never being received…
What’s your typical uplink spreading factor, RSSI, and SNR? If those are poor, it might suggest the downlinks just aren’t getting through.
Is it your gateway or someone elses?
I would say that sensor is only at 200 meters far from the gateway. I am far ( other city) but I sent downlink through internet in TTN.
SNR is 3.5, RSSI is -108
Regards,
Paolo
Whilst using the same command code for two different things, the parser should be able to tell from the downlink length.
01 for the stationary uplink mode, 0x7800 = 30720 = 8 hours.
The two bytes is little endian.
[School boy error 
]
But if your intention was …
then apart from the questionable use of battery sending a message to say something is in the same place every two minutes, there is no region where that doesn’t breach the TTN Fair Use Policy.
Well, I understand the policy:
my intention was only to see if downlink was working. At the end I would have in stationary mode one up link every 2 Hours, and when moving I would every 30 minutes. What you said about the 8 Hours I think that is not correct because If you see the command example attached there is a switch in the digit: 01201C Command for example become 0x1C20,yhat is 7200secs.Not sure if I’m right or you are right, this is what I understand. But apart the frequency I need to figure out if downlink work
Regards, Paolo
As there is no point in duplicating the image, it’s been removed along with my embarrassing error. Ideally you could supply a link to the entire PDF so there is context and we can remove the mauve colour scheme!
But you don’t have to break FUP to do that - 5 minutes would suffice. What if it gets through and then it’s not able to be reversed or you forget?
Why not send the 00 command - that way it should send back the current configuration and it is documented that it just needs a standard downlink.
Has it been uplinking in the meanwhile so you know the battery is OK, ie it is still running?
Can you get someone to check on it?
Why are you trying to debug something so far away?
Can it be bought to you so you have more control over the situation?
What will happen to it when its battery runs out?
Do you have another one you can try?
If the “get” version can only be sent by itself, that’s possible.
But from the context of the examples, it looks like it’s legal to put multiple verbs in sequence, each of which encodes the length of the following data, if any, that would have to be included before the next verb.
Note that’s exactly how LoRaWAN MAC commands are encoded, and while these aren’t those (they’re sent on port 204 with application keys, rather than unencrypted in the fopts or on port 0 with network keys), inspiration wouldn’t be surprising.
Hmm, those uplink numbers are neither great nor terrible, they start to get into the range where I’d expect things to often work but there to be occasional packets dropped even absent specific intereference.
Do you have any independent confirmation that the node is managing to receive downlinks at all?
If there is some other evidence that the node is receiving downlinks, and these in particular aren’t working, you may need to pursue clarification with the vendor.
A lot of Questions, thank you for your kindness.
Sensor is working, because I have the integration with Cayenne and i see every day the sensor update, that is in stationary mode and send up link every two hours. It has been one week and battery it’s 100%.Sensor is in my bedroom ( parent’s house), I’m living 30km away. On Wednesday when I will go there I would try some On Off director in the sensor, that has also a push button to trigger up link and anyway it could start moving and give by default up link every 15 secs. Attached data on Cayenne web app: last SNR e RSSI is better than before:
This is my first end node with first gateway installed in our municipality for testing before going to the next step. For GPS tracking we would preservativo buttery consumption to send up link not every 15 secs, but something like 15 min or 30 min would be useful for our utilization. I’ve already figured out that with uplink every 15 secs, in moving situation, battery went away in less than 24 Hours.
I could setup moving mode up link every 2 minutes on order to got 8 days sensor alive. Or a multiple of 2 minutes, but 15 secs it Is too high frequency. People don’t Want put on charge their smartphone and a certain number of sensors every day,. I undestand that tracking need high frequency update, but a compromise could help for now
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