Hi again HB, prompted by your story I thought I would go look carefully at one of my own LHT65’s - this is deployed at a remote site in the north of England, so I cant make physical checks only look at received data - installed July/Aug’19 running at SF7 under ADR (so likely also with slightly reduced TX power as with very good signal level & conditions to nearby TTIG as GW. Little battery drop so far - if anything the slightly warmer weather over the summer has helped recovery. Note update rate is every 20mins, and unit also has an external temp probe so reporting T&H directly along with additional T.
Are both of yours the same distance, and essentially the same or very different signal paths, to GW - such that one might be commanded to run at lower TX pwr if both on SF7? Tx will have significant impact on battery life…are they configured for ADR?
I share your observation: I have a dozen LHT65 sensors deployed and although 99% of them work fine, the battery of one LHT65 drained within a month. I had to replace it.
Although a bad battery may be the case, the following could be a reason too: these sensors are manufactured with the battery switched on and set to deep sleep until they are deployed. It could be of course that a single LHT65 was on stock longer than the others. Even in deep sleep batteries drain over time.
It is not a conclusive answer but these things happen.
You’re not kidding. After having experimented with various Dragino products I noticed that with other Dragino products as well. And it never work in my favor, which is why I noticed FW bugs and old HW versions . So for experimenting Draginos are fine, but currently I would tend to rather not use them in a major product rollout. (Unless you want to open up every unit before deployment, to examine HW versions and FW versions. And even that won’t protect you from bad quality batteries.)
@ bluejedi Since the data of the LHT65 with the dying battery is not important, I wait until it dies completely, then break the sealed case open, examine and replace the battery and report back .
Hi, same to me, one sensor drained in 3 month. Dragino replaced it without problem after showing the discharge curve and purchase bill to check that was really ony 3 months.
I have three units and am curious if you changed the transmit time to anything less than 20 minutes (default)? My oldest LHT65 is about six weeks and the battery seems to stay slightly above 3 volts. Thanks.
Bob
Where did you find that information? Nothing in the manual and no hits on google apart from 1 YouTube clip (which shows an empty unit, probably LHT65-BAT-CA, being opened) and a question (yours?)/reply on Twitter.
There seems to be some kind of design issue with lht65.
I have seven lht65s. Two of them failed after a couple of years. Somewhat early, but I opened them up to change batteries. Even though they are not exactly easy to open up it is a pretty safe prying and bending operation, as the risk of accidentally damaging the electronics in the process is low.
Both of them had drained the old batteries down to about 0.3 volt. When replacing the battery and connecting the battery PCBA to the main PCBA the supply voltage would drop down to 1.4 volt. Measuring the current with an externally connected power supply indicated that the main PCBA would draw 42 mA. Less than a Tesla, but something is clearly amiss.
And this was true in exactly the same way for both of the failing devices. (Work done in an EPA setting)
Which suggests they were ‘exhausted’ from a practical perspective long before attempting the swap out - a common issue when remote/in the field. So this begs the question how have the batteries/chemistry behaves in the the intervening period? Have you pulled the main pcb and inspected for any outgassing/vapour issues where mosture might get deposited causing corrosion and pcb/connections/tracing ‘creap’ leading to near shorts or (relatively) low impedance paths to be formed that then get exercised by the new batteries leading to such pull down and current draw? Its good practice to monitor batteries and schedule change what say 80%, ensuring work done by around 90% max
Maybe - that will depend on update rate and how ADR has adjusted SF in long term use - what does your (meta)data history say about how SF has varied over the life of the deployment? As GW’s come and go over such a long time not uncommon to see significant variance over time…and of course high up link rates combined with high SF mean fast battery exhaustion…
Plus temperature profiles & location - ambient doesn’t have to be hot - direct sunlight can warm up a device, then it gets cold overnight and the chemistry doesn’t play out as expected.