Hello, I have some Dragino LDS02 Fesnter Sensor. It also works great, but if I open and close the door quickly, it unfortunately does not register that the door is closed, and the sensor shows that it is open until I open and close the door again.
I have the problem with all of my LDS02s.
Can you tell him via the AT commands that he should send more often?
thank you.
This would be inappropriate. LoRaWAN end nodes must not send too frequently.
What could be done is to send an event on a change (if there hasn’t been one for a while), or to have a periodic report include a fact such as that while the door was closed before, and is closed now, it has been opened in between.
Since reliable messages are too expensive, one possible solution would be having the message contain the current state of the door, and the total number of time it has been opened/closed (even if that total eventually rolls over after a week or something).
These kinds of optimizations are however likely to require replacing the factory firmware with your own custom one… I believe Dragino published source code for, if not this exact board, at least a closely related one, which could be used as a starting point.
Apart from the whole “what does it say in the manual” thing, how would increasing the send frequency help with the response time of the sensor?
If these devices are being used as a security measure, then LoRaWAN is not an appropriate solution - there are no guarantees about delivery or how quickly any elements can respond.
Hello, the problem is, if the door is closed, the reed contact should know that, then it should send it and it doesn’t. He just stays open. I’ll open the door for you again and close it.
I am still very familiar with the AT commands, so I thought I could ask questions in the forum.
The unit does know it. However due to legal airtime limitations LoRaWAN devices can not send data too soon after another transmission. As a result the LoRaWAN stack in the device ignores the data to be transmitted.
There is no way to have the LDS send the second update if the events happen to fast without replacing the software. You could ask the manufacturer to implement code to delay the update for a minute and transmit it then, however that will create new issues if there are new updates within that minute.
To have the correct status after some time you could update the status transmission interval to something smaller than the default 24 hours. However that will have huge impact on battery life (and you need to keep total transmission times for a day under 30 seconds if you are using TTN).
This is why I like something such as transmitting the current state of the door and a 16-bit count of the number of close open cycles hourly.
But also, if the door changes state after not doing so for an extended period of time, have that prompt a transmit a few minutes later.
Essentially, make sure each transmission contains a good stand-alone summary (the count) since it’s quite probable that some transmissions will be lost, and effectively impossible for the node to know which ones since confirmed uplink would too rapidly burn up the airtime allowance.
Also, use extra transmissions when interesting things happen during periods of time when the overall number of transmission has been low.
But it all starts with first figuring out how to build, flash, and successfully operate a custom firmware that correctly interacts with TTN and reflects the state of the sensor in the most trivial fashion.
Allegedly the CPU and radio are the same so after verifying that by looking at the chips, one should be able to use the published LM502 firmware as a starting point:
GitHub - dragino/LM502: LM502 Project Source code
apparently that is out of date and should not be used with TTN unless one figures out how to update the utilized LoRaWAN stack.
That code is based on a version of the LoRaWAN stack that fails to handle RX2 settings correctly. To have any chance of implementing a LoRaWAN compliant (and working on V3) firmware one needs to update the underlying stack to at least SDK 4.4.
One of the more shameful aspects of the vendors business models is the code & forget strategy - leaving published firmware in the dark ages and very few devices that have recent versions - by which I mean within the last 6 months - shipping in the distribution channels or a stupidly simple way for devices to be updated before deployment. Anything less than v1.0.3 going out in to the field runs the risk of having that extra something missing that becomes vital for managing airwave congestion in two or three years time. Not catastrophic, but there’s no reason for anyone to be shipping less than v1.0.3 right now.
I agree with you @descartes, but a lot of manufactures do not update or notify their customer base that there is a new update. And so the distributors also are unaware of the fact of an update and also fails to notify their customers.
Those deploying a batch of devices are well served pro-actively checking for updates - I know I can’t keep up with the Marketing/BS emails mixed in with the actual useful information from most manufacturers so I’m not reliant on that as a source of info - and by being proactive with checking we can insulate ourselves from issues further down the line - either technically in managing devices or with our clients if we missed an update.
But my comments were more about the lack of updates to the underlying LoRaWAN code base that manufacturers are using - they may fix issues in their part of the firmware, but they are usually doing that from their original code base - I’ve rarely seen updates to the LoRaMAC-node or LMIC code they started with.
As opposed to releasing a product and having to support it forever? Dragino has updated the code for their other products, just not for this development board which has not been available for sale for almost two years (at least I haven’t found it anywhere during that period)
Years ago I bought an expensive Nokia phone (with their own OS). After 1 year with one software update Nokia released a new model and stopped all support for the previous model. My request to make software updates available for a decent amount of money was not even deemed worth a decent reply.
Many LoRaWAN device vendors provide a more decent support as the mobile giant Nokia was in those days (they had a market share of over 30% at the time).
It seems Dragino did just that (ok, not LoRaMAC because their code was based on another SDK) for the LDS and LWL series…
I never said that. And I wasn’t picking on Dragino although their LoRa-STM32 code is in this camp with a version from 2018. I’d be specific about the version but Semtech don’t make that simple to uncover. The LM502 code base uses an older Semtech implementation, again hard to be specific, and only a minor update to the repro.
Whilst a device is available in the distribution channel, leaving aside any stragglers left over once discontinued with a bit of time to flush stocks and for a defined period after, keeping the firmware reasonably up to date should be factored in. Otherwise you end up with v1.0.2 devices with bugs in the MAC when v1.0.4 has been closed off with development moving to v1.1. If I can update from v1.0.2 to 3 to 4, which was pretty much drop in, why can’t larger organisations?
So I’d expect to liaise with distribution to monitor discontinued device stock levels and then I’d consider that purchases would be deployed within three months.
If I was going to single any one company out, it would be Lego - don’t bother bring your Mindstorms software up to date, just bring out a new set at £/$/€300 a pop.
Actually, no, I’d like to single ST out - their STM32duino offering is woefully out of date. And the CUBE LRWAN1 is a hot mess to use due to the mega-board mix that forces you to put code all over the place and delve in to files not obviously accessible in the IDE to commission a device. Thankfully they’ve merged the STM32WL55 in to Cube MX so you can define your board setup and have it linked to the latest LoRaMAC, still a random collection of files to incorporate your specifics.
If we don’t set expectations for updates, we’ll end up with a mini-TinyLoRa type situation. And whilst we are setting those expectations, getting everyone to follow Dragino’s lead on the SCPF offerings or tutorials wouldn’t hurt either.
The github version of the code is. Their proprietary device development base is not using the same code base (anymore).
We will end up with those deployed anyway because once deployed there is little chance devices will be updated. The fuota specification is nice, however it is just part of a very large puzzle called device life cycle management. Only when all parts of that puzzle are in place updates in the field might happen which I think is not anytime soon (yet).
May-be your code and adaptions are better organized? 
That distinction may be the heart of the matter - to them to the LM502 may be obsolete, but to “us” its code would be the starting point for making the current proprietary-firmware boards more usable than Dragino’s engineers had the vision to make them.
It’s kind of a case where what they’re doing is moderately reasonable in the context of what they are intending to sell, but unreasonable in the context of how it would be nice to be able to use their products.
I am looking to split this topic as we’re wandering off topic. Any suggestions where the split should happen?
IMHO maybe we just leave it as an explanation of why the Dragino board’s algorithm isn’t as readily extensible as would be nice.
And then the thread can sit awaiting any input on the range of adjustment which the stock firmware offers.
An active effort to run open source firmware on the boards, or develop a good from-scratch door sensor algorithm could be its own topic. But I’m increasingly disinclined to buy this hardware just to play with those ideas… if I were to dive into that, I’d use a more development-friendly starting point.
Looking at their website and the FAQs I don’t think their intention is to sell their hardware for others to make custom firmware. At least not these devices.
At request (and with NDA) they do supply the circuit diagrams for some of the hardware so it is possible to create you own firmware, which I have done for some models, but it is not their business model as far as I know.
I haven’t found a fully open source LoRaWAN stack for these devices yet. The SDK used contains closed source binaries which made me start looking at other microcontroller/Lora chipset combinations. A shame because the ASR6501/2 would be a nice starting point if sufficient information in the internals and a fully open source stack would be available.
What I’m saying is that with devices on v1.0.2 in the supply chain, it would be useful if the manufacturers supplied firmware on v1.0.4 so they can be updated before deployment. Otherwise in three years time we end up with active devices on v1.0.2 rather than v1.0.4
FUOTA is a nirvana red-herring - it massively complicates devices, both hardware & firmware and there isn’t the bandwidth even on multi-cast for some of the file sizes typically in use.
Which is probably why I make less money but have less issues. I’ve still got 15+ year old code bases I maintain after 28 years writing the stuff, which brings a different perspective.
Any vendor can set out their stall as they see fit. There seems to be a two choices:
If it is appropriate to extend a devices functionality and they choose to make the code base available, that’s fine as long as they do that before they expect people to buy so the code base can be looked at for maintainability - plus some defined policy on updates to the core code and a way for people to add their code in that’s not an almost re-write each time.