Are they running on same SF, same TX pwr, confirmed or unconfirmed messages and same update rate (message periodicity) with same payload? Also 2nd looks like the classic discharge curve/end of life you can expect #1 to go through suggesting, all things being equal, that #2 battery was already part used by the time you started using/plotting here.
Are they running the same firmware version? (Such that e.g. sleep configurations are the same - also can you check internally to see if the builds/pcb’s are same h/w versions? - Not unknown for Dragino to make minor h/w changes for what is then the same Sales SKU) Are you able to measure e.g. sleep currents for the respective units to see if it really is one unit having a problem. Are the batteries the same make and type (chemistry)? Are you able to determine the age of the respective batteries? TBH in my experience these issues are usually a problem of the battery being poor or defective rather than the units themselves. One test is put identical fresh batteries in each unit and restart and see if the same unit dies faster again - looking at your graphs you should get a clear picture within 1-1.5months If you dont see a repeat building within that time put it down to #2 having had a bad battery and move on
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.