shorten sending interval when battery is at 100%

[notecp]

Hello, i am currently thinking about possible benefits for shortening the sending interval if the battery is at 100% - what do you think?

[jhughes1010]

I'm intentionally using infrequent updates for my needs (e-ink display updates weather changes every 30 min). Remember, that battery life is sacrificed by not letting the system sleep and weather does not usually change that quickly. NOTE: Wind measurement: I've got some ideas I'm playing with on min/max gust measurements. I may wake the system more often, but data will be stored and sent every 15 min as usual (in my situation)

[notecp]

gust meassurement was one of the things which i had in mind. you are totally right, weather doesn´t change that much, but wind gusts or maybe (sometime later) starting rain might be one use case for such a shorter interval. i mean some kind of alarm if it starts to rain or if there is a heavy gust of wind...

[jhughes1010]

All these are great ideas. You just need to clearly outline you design goals. There are low power modes with the ESP32 that support this sort of thing. We just want to stay away from the though process of waking and sending data more frequently. Thomas and I are in progress on a PCB with ESP32 that abandons the dev board all together. You cannot get low power operation described in the article with it. There are plans to take this design to the next level.

I've designed an i2c PCB module with an off board EEPROM for extended data storage. I still don't fully trust the new regulator design vs. RESET events (or I need to test it completely). Once it arrives, I'll start into software to record more data without powering up the WiFi radio all the time. I don't want to use on-board EEPROM as write endurance of the memory becomes a concern.

We can certainly attack many different algorithms for wind and rain measurements and warnings though.

[notecp]

ah okay, good to know. for now i start with your current state of the art :) i am asking upfront as i found more weather stations which aren´t getting updates or new ideas.

as i am making my first steps with ESPs i am looking forward to help someday. c++ skills are basicly there. Energy saving and so on is not mine until now as i don´t want cables from the roof connected to the inside of the house. i am considering adding solarpanles and eventually a bigger accumulator.... but that is future

for the external EEPROM maybe it is a two step approach. i think for alarms there isn´t a need to store something instead of just waking up sending and power off again. for other things like storing longer periods of rainfall for example there is such a need. i have my data send to an existing homeautomation server and store them there ;)

[jhughes1010]

Since we WAKE on rain tip gauge, making an alarm for frequent tip events and "phoning home" with the alarm trigger is pretty straightforward (for heavy rainfall in a time duration). A software only solution could be quite simple for that. I've added this to my jira task tracker. I'm not planning to use the EEPROM so much for rainfall, unless I see that my controller reset issues are still present.

Wind measurement can be attacked many different ways. This is where I'm interested in using the EEPROM. Wake every 5 sec and take wind measurements, for instance. Again, stay away from WiFi unless I have to do so.

Thomas and myself are committed to this project and interested in making a high quality, innovative project. Not moving on to anything else anytime soon. We are having a lot of fun with this. First order, get a usable solution that people can use and mount and use the existing project.

[notecp]

another thing, what about using a sd-card as storage? Do you think it will write too much? I saw the schematic here: https://github.com/espressif/arduino-esp32/tree/master/libraries/SD these ports ar currently free. The other thing is the question, if this is too much of storage - or is there a use for such an idea?

[jhughes1010]

You are reading my thoughts, kinda…

I’ve already got a small board coming back from fab next week that plugs into the spare I2C port and will have a serial EEPROM on it to capture rainfall, if non-zero values, before powering up WiFi to transmit (just as a backup). My short term goal is to make v3 usable with little or no updates. It will be easy to install in current environment and we can also play around with different techniques on wind data capture too! It will only have 64KB of memory, but that’s perfectly acceptable in the near term.

[notecp]

hmm, is i2c a good choice for this? i am surely not deep inside these sensor things, but most of them use i2c or onewire - wouldn´t it be wiser to have enough of them see for new sensors?

[jhughes1010]

Think of it from this perspective. You are a v3 user and want to be able to use the rain gauge without worry of RESET making you loose rainfall information. You may not feel comfortable with the hack for the better LDO (I still see some RESETs, but less frequently). There is a spare port and all you have to do is plug in a board. Memory address is not in conflict with any of the sensors we currently use.

Granted, as an engineer for Microchip with 25 years of NVMs and NVM security modules, I’m somewhat biased. My world is very much serial based (live and breathe I2C and SPI)

James Hughes

On Aug 9, 2021, at 2:16 PM, notecp @.***> wrote:

 hmm, is i2c a good choice for this? i am surely not deep inside these sensor things, but most of them use i2c or onewire - wouldn´t it be wiser to have enough of them see for new sensors?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[notecp]

ah okay, then it is fine for mee too :)

[jhughes1010]

Connecting a SPI based SD card socket is not a bad idea for a data logger mode on future revision. The article you sent connects to SPI port.

I’m thinking both short and long term on all this.

James Hughes

On Aug 9, 2021, at 2:33 PM, notecp @.***> wrote:

 ah okay, then it is fine for mee too :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[notecp]

sure, that was one idea for a maybe small webserver, and spi sounds easy to me

[jhughes1010]

I'm investigating a code error on my continued RESET woes. Running tests on this now without wind sensor plugged in. Code to check software 'divide by zero' was incorrect.

https://jameshughes.atlassian.net/wiki/spaces/WSV/pages/1752104971/Hardware+Items

Bottom log entry at bottom of the page

[jhughes1010]

Let me ask a question of you @notecp, have you seen the ESP32 RESET woes I've encountered with the 200mA LDO. Not many people have (as I have) which is why I switched to the 500mA LDO. I discovered the issue when writing the deep sleep code.

[notecp]

@jhughes1010 unfortunately not (yet) - i am still waiting for my pcb to arrive

[jhughes1010]

Did you order a pre-populated PCB? If so, double-check the orientation on the LDO.

[notecp]

yes, sure i will - as i normally do with all of this stuff ;)

[jhughes1010]

When your board arrives, don't rip out the LDO right away (asssuming it is inserted correct polarity). I'd like some feedback on operation with battery installed. Are you planning on MQTT? If so, you can set up to watch bootCount topic. We want to see if you suffer from ESP reset events.

[notecp]

okay, i will assume it is done fine :) i think i have to purchase the battery sperately,as i don´t think, it is included in the assemby. is it okay if i use 3.6volt instead of the 3.7volt or will it interfere with the testing? i am also considering buying two batteries and maybe connect them in parallel - as i plan to increase the solarpanels to two or three - but that is a task for later... but it won´t be a problem, right?

[jhughes1010]

What’s the battery chemistry? What is the working range?

James Hughes

On Aug 10, 2021, at 10:40 AM, notecp @.***> wrote:

 okay, i will assume it is done fine :) i think i have to purchase the battery sperately,as i don´t think, it is included in the assemby. is it okay if i use 3.6volt instead of the 3.7volt or will it interfere with the testing? i am also considering buying two batteries and maybe connect them in parallel - as i plan to increase the solarpanels to two or three - but that is a task for later... but it won´t be a problem, right?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[notecp]

these ones: https://www.berrybase.de/Pixelpdfdata/Articlepdf/id/6226/onumber/INR18650HG2 instead of the original ones: https://www.berrybase.de/Pixelpdfdata/Articlepdf/id/8800/onumber/INR18650-25R

[jhughes1010]

Ok, these are LiIon. Should have the normal 4.2 to 3.7 working range.

James Hughes

On Aug 10, 2021, at 10:54 AM, notecp @.***> wrote:

 these ones: https://www.berrybase.de/Pixelpdfdata/Articlepdf/id/6226/onumber/INR18650HG2 instead of the original ones: https://www.berrybase.de/Pixelpdfdata/Articlepdf/id/8800/onumber/INR18650-25R

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[notecp]

that was my consideration, the LG ones (planned replacement) are rated for 3.6V nominal voltag.

oh and yes, i am planning for only MQTT

[notecp]

@jhughes1010: the pcb arrived yesterday

[jhughes1010]

Great to hear! Let me know if you need help.

[notecp]

@jhughes1010 the tests are running :)

[jhughes1010]

I just push a release candidate 2 to master. Just resolved missing directions on my end. If you are working with 1.2 RC1 or RC2, you are in good shape

[notecp]

i am working with 1.2 RC1 - lucky me I have written extension code for wunderground pws - currently testing and messing around. i will file a pull request when done?

[notecp]

one correction: in sensors.ino line 58 should read "if (environment->batteryVoltage < 3780)" as the voltage is read in mV, right?

would it make sense to move things like gmtOffset etc. to a single file (maybe secrets.h)?

[jhughes1010]

Nope, value is in volts, not mV. I agree the time offsets need to be moved... slipped under my radar.

[notecp]

hmm, i have added a debugline before the comparison for the low battery (line 58 in sensors). the output shows mV at least in version 1.2 RC1:

Battery digital :2647 voltage: 2815.60 Voltage before compare: 2815.60 Current Hour: 8

Attempting to connect to Thingspeak

[jhughes1010]

Interesting. I've never used mV. I simply multiply ADC calibration factor (that you must fine tune), but #define batteryCalFactor .001167 times your ADC value of 2647 .001167 = 3.08V.

What value do you show for batteryCalFactor in secrets.h?

[notecp]

//measured battery voltage/ADC reading

define batteryCalFactor 1.063696

[jhughes1010]

Did you happen to change this while fine tuning? It should be a number much smaller than 1. Physical battery voltage (V)/ADC, in your case... 2647. I'll change the "Battery digital" to "Battery ADC" in the output statement for clarity, FYI.

PS: Thanks for working this with me. Maybe I have a documentation or instruction error.

[notecp]

sure, in my case right now: Batter / BatteryADC= 2,91 / 2,647 = 1,0993 sometimes more sometimes less ;)

[jhughes1010]

2.91V/2647 = .001099. This is your calFactor. ADC value is 2647 ( an integer value between 0-4095). It intrigues me that you have a measured battery voltage of 2.91V. You are not measuring at the ADC pin, but rather the battery terminals, correct?

[notecp]

yes directly at the battery

[jhughes1010]

Usually battery voltage is 4.2V to 3.7V for operating range. Nonetheless, ADC is 2647, not 2,647.

[notecp]

right now the batteries are not fully charged

[jhughes1010]

OK, got it. Do you understand the math error though? I'm guessing you have battery installed, but running with USB cable plugged in. Nonetheless, with that low of a voltage, software will set lowBattery = true and updating interval will be multiplied by 4.

[notecp]

i got the code, yes understood. but no usb is not plugged in right now - but it gave the same reading. i will wait for the batteries to get fully charged