Battery RAK7205 drained beyond reported value

Issue:Hardware

Setup: 2x out-of-the-box RAK7205

Server:

Details:I am currently testing some applications for the RAK 7205 module, untill both of my two test devices stopped transmitting data. The received data put both devices at around 3.7V, but upon retrieval both devices were drained beyond what I would have expected, one even measured 2.55V.

I tested both devices with a freshly new battery, and they exhibit the same behavior. The battery was drained to 3.15V, while the tracker still reported 3.67V.

Both devices are running V3.0.0.14.H.R, should this be relevant.

Can this be fixed?

Hello @jorenv,
Which LNS are you using?
Can you share the settings of 7205 as well as the decoder that you are using for the uplink data?

Best Regards

Hi Nikola,

Something I forgot to mention is that the decoding works fine for 3.65V and up from there.

I’m using Proximus Mythings, which I assume is what you mean by lns.
I’m not entirely certain which settings you are require, but I hope this works:

Region: EU868
Send_interval: 300s
Auto send status: true
Send_interval work at sleep
MulticastEnable: false
DutycycleEnable: false
Send_repeat_cnt: 0
Join_mode: OTAA
Class: A
Joined Network:false
IsConfirm: unconfirm
AdrEnable: true
EnableRepeaterSupport: false
RX2_CHANNEL_FREQUENCY: 869525000, RX2_CHANNEL_DR:0
RX_WINDOW_DURATION: 3000ms
RECEIVE_DELAY_1: 1000ms
RECEIVE_DELAY_2: 2000ms
JOIN_ACCEPT_DELAY_1: 5000ms
JOIN_ACCEPT_DELAY_2: 6000ms
Current Datarate: 3
Primeval Datarate: 3
ChannelsTxPower: 0
UpLinkCounter: 0
DownLinkCounter: 0

As for the decoder, I based myself on the decoder as specified on the github

    while (Str.Length > 4)
        {
            string flag = Str.Substring(0, 4);
            switch (flag)
            {
                case "0768": // Humidity
                    rakData.Humidity = (float)Math.Round(Convert.ToByte(Str.Substring(4, 2), 16) / 2 * 0.01 * 100, 1); // unit: %RH

                    Str = Str.Substring(6);
                    break;
                case "0673": // Atmospheric pressure
                    rakData.Pressure = (float)Math.Round(Convert.ToUInt16(Str.Substring(4, 4),16)*0.1,2); // unit: hPa
                    Str = Str.Substring(8);
                    break;
                case"0267": // Temperature
                    rakData.Temperature = (float)Math.Round(Convert.ToInt16(Str.Substring(4, 4), 16) * 0.1, 2); // unit: °C
                    Str = Str.Substring(8);
                    break;
                case "0188": // GPS
                    rakData.Latitude = (float)Math.Round(Convert.ToInt32(Str.Substring(4, 8), 16) * 0.000001, 6); // unit: °
                    rakData.Longitude = (float)Math.Round(Convert.ToInt32(Str.Substring(12, 8), 16) * 0.000001, 6); // unit: °
                    rakData.Altitude = (float)Math.Round(Convert.ToInt32(Str.Substring(20, 8), 16) * 0.01, 6); // unit: m
                    Str = Str.Substring(28);
                    break;
                case "0371": // Triaxial acceleration
                    rakData.AccX = (float)Math.Round(Convert.ToInt16(Str.Substring(4, 4), 16) * 0.001, 3); // unit: g
                    rakData.AccY = (float)Math.Round(Convert.ToInt16(Str.Substring(8, 4), 16) * 0.001, 3); // unit: g
                    rakData.AccZ = (float)Math.Round(Convert.ToInt16(Str.Substring(12, 4), 16) * 0.001, 3); // unit: g
                    Str = Str.Substring(16);
                    break;
                case "0402": // air resistance
                    rakData.GasResistance = (float)Math.Round(Convert.ToInt16(Str.Substring(4, 4), 16) * 0.01, 2); // unit: KΩ
                    Str = Str.Substring(8);
                    break;
                case "0802": // Battery Voltage
                    rakData.Battery = (float)Math.Round(Convert.ToInt16(Str.Substring(4, 4), 16) * 0.01, 2); // unit: V
                    Str = Str.Substring(8);
                    break;
                case "0586": // gyroscope       // currently not used
                    rakData.GyroX = (float)Math.Round(Convert.ToInt16(Str.Substring(4, 4), 16) * 0.01, 2); // unit: °/s
                    rakData.GyroY = (float)Math.Round(Convert.ToInt16(Str.Substring(8, 4), 16) * 0.01, 2); // unit: °/s
                    rakData.GyroZ = (float)Math.Round(Convert.ToInt16(Str.Substring(12, 4), 16) * 0.01, 2); // unit: °/s
                    Str = Str.Substring(16);
                    break;
                case "0902": // magnetometer x  // currently not used
                    rakData.MagnetometerX = (float)Math.Round(Convert.ToInt16(Str.Substring(4, 4), 16) * 0.01, 2); // unit: μT
                    Str = Str.Substring(8);
                    break;
                case "0a02": // magnetometer y  // currently not used
                    rakData.MagnetometerY = (float)Math.Round(Convert.ToInt16(Str.Substring(4, 4), 16) * 0.01, 2); // unit: μT
                    Str = Str.Substring(8);
                    break;
                case "0b02": // magnetometer z  // currently not used
                    rakData.MagnetometerZ = (float)Math.Round(Convert.ToInt16(Str.Substring(4, 4), 16) * 0.01, 2); // unit: μT
                    Str = Str.Substring(8);
                    break;
                
                default:
                    Str = Str.Substring(7);
                    break;
                
            }
        }

How much time elapsed between the last received message, and the retrieval?

Could this be explained by battery draining to the point where transmission is no longer successful, meaning you stop getting reports, but then continuing to drain?

A largely depleted battery may be particularly likely to “brown out” under the substantial peak load of attempting to transmit. Depending on how software is written, it could even enter a loop where it’s constantly browning out, recovering, re-attempting transmit, and browning out again, with the particular issue that by never succeeding it never goes to sleep for a normal inter-packet interval, and so actually ends up running down the last of the battery more quickly than ordinary operation would.

I had the same idea, so keeping in mind this “browning out” I ran tests with a brand new battery and this one never dropped below 3.15V, at which point the GPS tracker registered 3.67V and stopped the tests there. So the behaviour repeated itself for a battery that should not have reached the brownout point.

With the initial testing, it took a few days. But upon retesting with the same batteries, I retrieved them within minutes. It was these that drained to 2.55V but read out 3.7V, but those initial batteries might not have been reliable, hence retesting withfresh batteries.

@Nikola Do you have any idea of what the issue may be?