Like I said in my last post, I only want to control de valve when I need to, whitout any frecuency. It doesn’t a cyclical task. When I decide to open or close the valve, that’s when I want the data to be sent.
If it doesn’t close when I want, it will continue watering a flower. I create a watering control system. It just for a school project.
Same answer that point 2.
The packet loss that I should expect up to 10% according to Learn Section. If I think on just 1 value, I believe that it will be a low packet loss. I don’t know how to work if I have packet loss with one value.
I don’t know about the impact on the network, sorry.
I own a milesight UG67 gateway, so it isn’t a problem for me.
Your last post didn’t help, this doesn’t help as there are always numbers, even if they are a guess - you could be talking 10 times a minute or once a year - but the fact it is a watering project gives us context to know that it won’t be that often - once a day if that - and you can live with valve not opening, not sure if value left open is an issue.
It’s still a very poor implementation of LoRaWAN - you could use any number of more reliable radios over a short range as a proof that you can control a valve remotely. What would be suitable for LoRaWAN would be automating the watering with a soil moisture sensor and sending updates on that & the water reserve level. Downlinks would be to change the settings.
Now that you’ve read the Learn section and you’ve presumably read the docs for LMIC and you are student that should be used to researching a topic, what is holding you back? The LMIC code has the placeholders for when a downlink arrives, add the code there.
As, by forum policy, we don’t do student homework, feel free to ask questions but you will have to show a lot of detail & prior research to inspire assistance.
Indeed, we could say once a day or even spontaneously. Multiple opening/closing of the valve in a short time is not required. So one message will be sent to the device per day or even none at all.
If the valve remains closed nothing important will happen. However, if it were to remain open, water would be wasted. It is a school project but I would like to adapt it as much as possible to reality.
I am aware that maybe LoRa would not be the best solution for this, as there are other, possibly easier options. However, the key to the project is to use LoRa.
My project actually has two devices, one is dedicated exclusively to the reading of humidity, temperature and soil moisture sensors, while the second one opens or closes the valve, this is the one I am talking about. All the data is sent through LoRa.
To be completely honest, I didn’t know anything about LMIC. I am trying to learn about LMIC, hence my initial question. After talking to you, exposing my project to you, it has left me uncertain as to whether it will be able to work without too many problems, knowing that I will only be sending one value to the device.
I’m sorry if my questions may seem unlogical or unintelligent. Thank you very much for your time, patience and help.
It’s very simple - you read the docs and look at the examples - it pretty much tells you where to code. If you can’t get it going with LMIC, you won’t have much joy with the more complex setups. But mostly it’s about mindset, it’s not trivial stuff, there are many moving parts, but if you look at each section individually and not worrying about the whole overall, you’ll build the systems.
You may want to look at LMIC-node which is the most documented & gift-wrapped version ever. You’d have to look at using the Blue/Black Pill setup with some modifications.
Now, Im testing my end node with the code from @skovholm. I can see it on my GW but it cannot join on TTN console. I got a MIC Mismatch error. I checked my DEVEUI, APPEUI, and former devdeky (now APPKEY). Im using LoRaWAN version 1.0.1 but I tried with 1.0.3 too, but I have the same problem.
I reversed the bytes of APPKEY, but it doesn’t work. I was reanding about endian-ness. Are you trying to tell me that I should enter my numbers without inverting because APPKEY is in Big Endian, and DEVEUI and APPEUI are on little endian?
No, I was pretty clear that the AppKey is not end sensitive. Whereas the EUI’s are endian specific which is why you need to check the docs. So pretty much the reverse of your interpretation.
If you are using the ancient code base of the IBM LMIC of 2016 it may not be clear. More recent versions are clear. More recent versions are far more compatible with pretty much everything LoRaWAN so you may get the code base at the top of this thread working, it wasn’t a good choice, which is why I directed you to LMIC-node which has gold-plated documentation with gift-wrapping.
In the meanwhile, if you’ve had your EUI’s MSB, try them LSB. DO NOT try to mix & match - it’s either BOTH MSB or BOTH LSB.
Referencing your duplicate post, this is by design - you are likely recycling the DevNonce and duplicates are rejected by the LNS. For development work you can turn this off in the console or you can make your version aligned with LMIC which does NOT support v1.0.4 incrementing Nonces.
Edit 11 Jan: failed to include NOT in the last sentence - LMIC doesn’t support incrementing DevNonces as required for v1.0.4 so you MUST use v1.0.3
actually i need to have deep undrestand of concept of lorawan
but i only study “the thing network” document could you give me road map to have better undrestand of it
i didnt found anything with this title in forum does it exist?
That will guarantee it gets re-used…which is the problem. You want a value (preferably random?) that increments each time and isnt re-used. Note any given device has a limited pool of DevNonces (actually quite a lot!) which under normal use & life time operation should not become exhausted, but if joining regularly (some badly witten s/w joins every time before 1st data TX and is a waste of space/should be avoided like the plague) such that you run out in the working life of the device then only option is to delete device in LNS and start again!
How about the Learn link at the top of the every forum page? And the link bottom right to the documentation on every console page?
And then there is the LoRaWAN specification on the LoRa Alliance website.
There is an error in my post above - I missed a not - I’ve edited this now - LMIC does NOT support v1.0.4 so if you’ve selected that as your device version, it will need to be changed to v1.0.3
We’d need some more info on what it’s doing for those 15 minutes - serial logs from the device as text formatted with the </> tool plus screen shots at a reasonable “old person” resolution of the exact same time from the device console in verbose mode.
You want a value (preferably random?) that increments each time and isnt re-used. Note any given device has a limited pool of DevNonces (actually quite a lot!) which under normal use & life time operation should not become exhausted, but if joining regularly (some badly witten s/w joins every time before 1st data TX and is a waste of space/should be avoided like the plague) such that you run out in the working life of the device then only option is to delete device in LNS and start again!
