search

Sinapse-Energia / talking-fiber

Firmware for optic fiber activity detection. Based on M3 MCU
0 stars 1 forks source link

[HW] Redesign for Low Consumption #16

Open ralcaide opened 5 years ago

ralcaide commented 5 years ago

The current HW/FW is working well but the consumption is very high. Measuring each 15 minutes and connecting each 60 minutes in order to publish a measurement consumes around 40-50mAh. This consumption is not acceptable. Our goal is to have < 0.2mAh of consumption publishing once per day and measuring each 5-10min . Planned improvements:

  1. Change current MCU (STM32F215RET) for a similar LowPower MCU from ST
  2. Improve photodiode part in order to decrease its consumption. Now is consuming a lot
  3. Improve power stage in order to optimize consumption
  4. Improve Quectel part in order to decrease its consumption and using PSM modes
  5. Change M95 (GPRS) for BC95-BG (NB IoT)

It is necessary to understand where is going the consumption of the current HW and estimate the improvement obtained with the previous steps. For the points 1. and 2. we are willing to know the experts proposals

ralcaide commented 5 years ago

Design Files V1

Quectel BC95 Low Power Design Guide

Quectel M95 Low Power Design

ralcaide commented 5 years ago

Photodiode documents:

75um Pin Photodiode.pdf

Operational Amplifier 62689.pdf

ralcaide commented 5 years ago

@fpgamcu (with the help of Eugene). We need the following answers ASAP:

ghost commented 5 years ago

While in sleep device consumes 1.5-1.7 mA, while measuring it consumes about 250 mA but only for 100 msec. While publishing/connecting it consumes about 60 mA for 30-45 sec. We have 3600000 msec in one hour. So total consumption should be next: (250 100 4 + 60 45000 + (3600000 - 100 4 - 45000) * 1.7)/3600000 = 2.46 mAh Second and third question should be answered by Eugene. Please contact Sergey to arrange his work investigating HW.

ralcaide commented 5 years ago

Thank you very much. With this HW, 2.46 mAh is not so bad but the fact is that we are consuming between 14-20mAh, so we are far away from the theoretical minimum. @fpgamcu , we will have an improvement soon? The actual consumption is still very high

ghost commented 5 years ago

With this commit FW operation is fully fixed according to Eugene recommendations. I tested on both devices I have and got 1.5-1.7 mA sleep on one device and 2.1-2.5 mA on sleep on other (newer) device. One more thing. With this code on older device I have different readings when there is signal on photodiode and when there is not. So it is working ok. On new device I have same readings when there is signal and when there is not.

ghost commented 5 years ago

Also while device is in the listen state, it will consume about 30-60 mA all the time listen state is active.

ralcaide commented 5 years ago

OK, in relation your last comment, yes, we know. We are testing with listen status only two minutes each 24 hours. In relation you tests after last commit. We will test in our side. It is strange your new device is always measuring the same. Is the device broke?

ralcaide commented 5 years ago

Uploaded first version of report sent by Oleksii

Talking Fiber Review Report rev.1.00.pdf

ralcaide commented 5 years ago

@fpgamcu , we've tested last version and the consumption is not low as expected. The devices are consuming between 8-11 mAh with the following characteristics:

Regarding this configuration you told us the expected consumption will be < 3mAh but is not. Any idea?

ghost commented 5 years ago

On all board that we have now in office I am getting around 1.5 mA (1-2 mA). I think you may have damaged IC_67_2 on board.

ralcaide commented 5 years ago

with the same characteristics as I explained before?, publishing each 60 minutes and measuring each 15 minutes?

ralcaide commented 5 years ago

Sviatoslav response:

Hi. Eugene diagnosed it was broken because in measurement it was consuming several hundreds of mA and was very hot. After I replaced it all was normalized. As Eugene explained, one of the reason of it is broken may be that board was powered up without code setting proper state of this pins. As I remember at the beginning of development we had the code that was not fully operated with pins. For me it was surprise that we can broke something on board so easily from FW. Maybe we can somehow avoid this in future by placing some pull up / pull down resistors on power enable circuits.

@francisjjp, could you test if the IC_67_2 is broke in our devices? If yes, please change it and perform the retest