[Sampling][By Time] Develop sampling process by time

[ralcaide]

All peripherals OFF

After M minutes:

• Turn ON peripherals
• Read photodiode
• If value < TH -> Publish alert
• Save value in NVM
• Turn OFF peripherals

M and TH should be configurable in parametrization. By default:

M = 10 minutes TH = 2,7 V

[ralcaide]

It is necessary to find the best option in order to decrease the consumption as much as possible:

Quectel always connected VS Quectel connecting each M minutes ?

[ghost]

There is an issue with connecting only when publishing. One connection takes about 30-40 sec. If you will set period to 2 or more minutes, you can notice that after disconnection, we have power consumption reduced from 70 to 10 mA. But when connection is performed after disconnection we have situation when board is reboot, but without any HF. This situation same for AP and M2M. There is 2 possibilities: bug in m95 driver (I remember that we had something similar in past with disconnection, but not resolved it. but in this case we should see HF, but now we don't see it. Instead we have situation when whole board reboots, so it is very possible problem with M95 power circuit. We will investigate more with the scope.

[ralcaide]

Thanks for the commits and the comment.

Regarding the comment, I understand more or less the problem but I have a question: with this bug is the here proposed feature working? or is blocking the feature?

We would like to test the with period 15 min but we need to be sure that the device will publish if the measured level is lower than the TH.

If the bug is blocking the feature, the status is not "To be tested". It is "In Progress".

In other hand, here is required to disconnect all the peripherals, is the consumption reduced if the Quectel is always online?

[ghost]

If using M95 always online - feature is working. If disabling M95 when not publishing - it will not work because MCU is reset when re-enabling M95. When M95 is enabled consumption is still 60-70 mA. We will investigate how to fix bug and allow M95 to be disabled/enabled in runtime.

[ralcaide]

I understand. One of the main goal of this task is to reduce the consumption thanks to the disconnection of peripherals. If the disconnection of the M95 is not working, then this feature is still in progress. Please focus on this M95 problem because I think now is our biggest problem in order to get more lifespan of the battery, isn't?

[ralcaide]

@fpgamcu, any news about the M95 problem?

[ralcaide]

Testing AP_Based:

The periodic measurements are not published if the alerts are disabled.

Next definitions publish each 15 minutes Periodic and Alerts:

`//#define CONNECT_ONLY_TO_SEND // Enable periodic TF measurement and set default publish period in minutes

define ENABLE_PERIODIC

define DEFAULT_PERIOD "15"

//#define USE_SD_CARD // Enable alarm TF and set default period (minutes) and TH (mV)

define ENABLE_ALERT

define DEFAULT_ALERT_M "15"

define DEFAULT_ALERT_TH "2700"`

Next Definitions publishes nothing

`//#define CONNECT_ONLY_TO_SEND // Enable periodic TF measurement and set default publish period in minutes

define ENABLE_PERIODIC

define DEFAULT_PERIOD "15"

//#define USE_SD_CARD // Enable alarm TF and set default period (minutes) and TH (mV) // #define ENABLE_ALERT

define DEFAULT_ALERT_M "15"

define DEFAULT_ALERT_TH "2700"`

Are you able to reproduce this behavior?

[ghost]

Tested with first defined - getting each 15 minutes periodic and alerts Tested with second defined - getting each 15 minutes only periodic We could not reproduce the problem About M95 problem - seems like it is power issue on board. We will gather more info and send you pictures from scope.

[ralcaide]

With ap_based branch?

[ghost]

yes

[ralcaide]

Strange, our devices are not working like that

[ralcaide]

Are you able please to test the attached .hex? Is the same that we are testing with not valid results because is publishing only the messages the first time but not anymore. It is to say, for example at 8:15 is publishing them but not at 8:30, neither at 8:45 and so on...

TF-TESTING_TFS-sinapse-matoomam2m-0-9-V230818-AP_based-P=15m-A=15m.hex.txt

It is an .hex but I've added the .txt in order to be acceptable by github

[ralcaide]

Sorry, the previous file is using another APN. Here the file with your APN and default topic

TF-TESTING_TF-sinapse-kyivstar-0-9-V230818-AP_based-P=15m-A=15m.hex.txt

[ralcaide]

We are testing also without SD

[ralcaide]

We are testing with the device connected to the network and the result is the same, publish only the first time the periodic & alert message. Then, not anymore. We have tested in two different devices that were working right with the previous version. Could you try to reproduce, please?

[ghost]

We found the bug. Was not reproducible on our side because we used another broker set up to different ping period (longer, about 30 min). Now we used default broker and the issue was that we are not sending ping (because disabled on demand) and with 15 min period broker stop listening to the device. With enabled ping all works ok, latest commit should allow long periods.

[ralcaide]

Great, we will test it. Two questions:

This publish increase the consumption? Can me test with "CONNECT_ONLY_TO_SEND" or is buggy?

[ghost]

It will not increase consumption significantly. Comparing to measurement (300mA) send data consumption is near M95 standby.

CONNECT_ONLY_TO_SEND now cause restarts at reconnect. We are working on workaround.

[ralcaide]

Ok, we wait to the workaround.

Related with the consumption of measurement, I've already set a question in other issue but a put here again:

• How much time in the photodiode ON? If we are using it each 15 min but only some seconds the consumption should be not too big

[ghost]

It is on for the 100-150 msec when measurement executing (each 15 min in our case). For https://github.com/Sinapse-Energia/talking-fiber/issues/7 it will be on all the time in order to enable analog watchdog to work.

[ralcaide]

So, for #7 the consumption will be very high. This is not the goal. Is just the opposite. If #7 will consume more than #6 we need to think about another solution. Any idea? HW modification?

Regarding the ping problem: If the device is disconnected form the broker when trying to publish should try to reconnect automatically, is not done like that?

[ghost]

Yes, there is code to perform reconnect, but it is not working. We are checking why it is happening. About consumption - HW modification should help, usually such measurement should hot consume more that several uA.

[ralcaide]

Ok, we will try to improve the HW

[ghost]

Implemented workaround is not very good, but it is only thing we can do with current hardware. If you uncomment CONNECT_ONLY_TO_SEND_WORKAROUND Device will work in the next way: 1) Connect to MQTT 2) Publish periodic and if needed alert 3) Disconnect and disable M95 4) Wait for periodic period or alert period 5) If periodic enabled and periodic period reached - restart device (go to p.1) 6) If alert enabled and alert period reached and TH check passed - restart device (go to p.1)

TODO add going to sleep mode when waiting for period.

[ralcaide]

I understand the workaround but I'm also right is not very good. I have several questions:

• Is this method better that leave the Quectel always ON in terms of power consumption? I understand that restart the system consumes also battery
• Why the Quectel is able to connect when device starts and not when is running?

[ralcaide]

Regarding M95 and after read the attached documentation, regarding pages 24 -> 34. It is necessary check / test the following:

• Our device cover the design requirements
• Try to use pwrkey instead of modem power supply control.
• Try to use M95 low power modes. Like

Minimum functionality mode reduces the functionality of the module to a minimum level. The consumption of the current can be minimized when the slow clocking mode is activated at the same time. The mode is set with the “AT+CFUN” command which provides the choice of the functionality levels =0, 1, 4.

if the quectel goes fro FUN=0 to FUN=1 is restarted also?

[ralcaide]

Quectel_M95_Hardware_Design_V3.1.pdf

[ralcaide]

@fpgamcu , please take a look to this guide in order to understand how work with M95 for Low consumption. Maybe could Eugene also to take a look in order to verify our design

Quectel_Low_Power_Design_User_Guide_V1.3.pdf

TO BE DONE through other task because it is a transversal requirement: #9

[ralcaide]

After #9, we've performed testing and found a bug. The FW is set with periodic = 60m and alerts = 5m.

All the connections and publications are well done but seems that the reading of the sensor is only done at periodic level and not at alerts level. The value and the timestamp changes when a periodic frame is published, then the next alerts displays same values returned by last periodic frame until the next periodic frame is published and so on.

This is not a valid behaviour, the photo-diode should be read each T_sampling

[vAnArhist]

This bug appears because calling GetVariable("TFVOL") is not executing HOOK from wrsouth.cpp to measure voltage. Latest commit should fix the issue.

[ralcaide]

Thanks we will test it

[ralcaide]

Tested and working fine. The problem is still the high battery consumption. Publishing alerts each 15minutes, 1200mAh have a long life of less than 24 hours. We need to understand why is the consumption so high

[ralcaide]

To be tested with periods bigger than 60 min. Example = 720min