Hello all, I’m hoping for a bit of help if anybody has had experience with this. I’m using a Dragino PS-LB (which is a liquid pressure sensor). I’ve got a reasonable understanding of the device but like all LoRaWAN setups, my setup misses messages sometimes; let’s say it’s transmitting every 10 minutes - the gateway/TTN is picking up maybe 90% of those, so there are gaps in the sequence which I would rather fill in.
This Dragino device has the ability to be interrogated and re-transmit readings between a particular time range (I expect people will immediately start worrying about fair use policy, if somebody was to go back and try and get it to re-transmit a whole bunch of missing values). But I’m just wondering if anybody has systematised this, i.e., written some sort of code or monitoring that detects gaps and catches them as they happen. Obviously you can’t send the downlink and get the fresh uplink until the next time it connects, so you never really know when you’re going to have the opportunity to do the gap filling.
Is this a good or bad thing to try to do? (but please assume I have a valid need for complete time-series). Does this make seasoned users shudder in horror at the idea of doing this? Any thoughts please.
Thank you.
ps: or is there any other way to dump all the device’s stored history?
Only if you actually breach FUP - if you design something so it doesn’t, what’s there to worry about.
If you know the uplink interval, you can have your server send a re-send request at the interval * 1.5 mark - ie, about half way when it’s over due.
Or when it receives an uplink, using the frame counter you can look for a gap and send a request. Some code will be required to queue multiple requests to fill a gap larger than one at an appropriate rate.
If the firmware is available, you could modify it to send the current and the last two values - usually adding a few more bytes to a payload isn’t super detrimental.
If you absolutely can’t live without any gaps in the data, maybe you should consider a TTI instance so you aren’t bound by FUP - @rish1 can help out there.
Thank you. I very much like that firmware-tweak idea. I don’t have access myself but Dragino actually seem to be quite responsive to user comments so I might suggest that to them (or they might be listening in here). A parameter to determine how many (historical) messages are sent each transmission would be a potentially useful feature. They already have something similar in that you can batch up readings and send the current readings in a batch. But I don’t think that can be used to send the current reading plus a number of historical readings that had already been transmitted. It doesn’t sound like it would be too much of a change for them to make though.
Thanks for your other comments. I made the observation about FUP because this is the sort of thing that if coded incorrectly could go seriously wrong
But you have some good ideas about using the frame counter and I could use a backend to keep track of missing transmissions and the time range that they were expected in and then assemble intelligent queries based upon that.
At least you didn’t say it was a terrible idea, it’s beginning to sound like a lot of work though. And I’ve read just this morning that the Dragino devices that have the Bluetooth connection have the ability to download the flash memory history if you’re close enough to access it with Bluetooth.
