Failure of HTCC-ABO1 after some days (LoRaWAN)

Hello,

I have a problem with a lot of unexplained sensor failures (LoRaWAN). Some sensors with identical software and hardware run without problems, others fail after a few days!

All are powered by LiPo an Solar!
Tt is not a problem of the connected I2C sensors!
Watch dog is used!

LoRaWAN (ADR; Uplinkmode unconfirmed; OTAA; Netresevation off)

I have changed many sensor yet, but i dont know where the problem is.

Had anyone a idea?

E_T

Greeting!

Have you measured the voltage of the battery in the failed boards?

Besides, for these failed boards, can you plug in the USB cable and open the serial port to see if there is any information output?

If I restart the device, will the data be restored?

Yes, some boards had abnormal power consumtion during deep sleep. This will cause low battery voltage.

But i mean here lost of communication and the last value of battery voltage is good!

In most times i can play a new programm to the board, but i changed the hardware everey time. One board had no function even no usb-communication.

The next curious behavior of a sensor: It runs from 23.11.2020 to 27.11.2020 3:56 o’clock then it stops until 09:07 o’clock and then it works again. Normally a packet is sent every 10 minutes. The battery voltage was always 3.9 V

Can it be a problem with ADR? (But i think, when we start with SF7 every change will leads to better communication)

Greeting

E_T

What hardware did you changed? Is that possible error connection caused hardware whort or broken?

This high probability is a network problem of your gateway. If the gateway fails to establish a stable connection with the server, the node will also go offline.

Hello Supporter,

i changed the cubecell-board, because it is very costly to replace a sensor during operation.

Yes this is possible, but other sensors worked fine, and the packets from this sensor are normally received by two independent gateways.

One possibility would be that an object has disturbed the sending of the packages in the time.

Greetings
E_T

Sorry for my poor English, did you mean you had changed a component of the HTCC-AB01 board?

I changed the HTCC-AB01 board in the sensor.

Greeting

E_T

Currently we again have a sensor that runs reliably at first, from 28.11.2020 to 01.12.2020 5:47 am! After that it does not transmit any data, the battery voltage of the last transmission was 3.65V!
The sensor is received by two independent gateways! The software had the LoRaWAN example with Watchdog as basis.

Greeting

E_T

Here the next surprise, a sensor runs reliably, but from one transmission to the next, the battery voltage allegedly drops from 4.188V to 1.496V. The sensor continues to deliver measured values!

Greetings

E_T

This information is critical. It seems that the power consumption of this kind of sensor will be relatively large, or the sensor has a short circuit when it is working, causing the voltage to be pulled down. I suggest you try the following:

  1. Let some CubeCell board not connect any sensor and use watchdog examples to see if it will stop working after working for a few days. The purpose of this is to determine whether the crash is caused by the sensor or caused by the code logic problem.

  2. Can you tell me the model of the sensor? We bought some samples back and tested them on our side.

Hello supporter,

we use the BME280!

The sensor is powered by VEXT!

So after deepsleep the bme280-sensor is powerd on!

The sensor is switched on briefly, delivers the measured values and is switched off again.

The basic software is the example LoRaWAN_watchDog!

The BME Library is SEEED_BME280!

If bme280.init() fails, special values are transmitted to detect a malfunction of the BME280 sensor!

//Region Region_EU868
//Class A
//OTAA
//ADR ON
//uplinkmode unconfirmed
//Netreservation OFF
//AT-Support Off
//RGB deactive

Proposal1 I will test.

Greeting E_T

How much is your payload length?

Hello,

the payload length is 7 Byte ( appDataSize = 7;).

Greetings

E_T