correction: the panel shoulndn't exceed 3.6V...
michael.k...@gmx.at schrieb am Sonntag, 27. Dezember 2020 um 19:17:11 UTC+1:

> @Peter Quinn, thank you. I'll check the weewx part!
>
> Just my 2 off-topic cents: using the breadboard the voltage regulator and 
> the UART, powered by 5V ist a very inefficient way to run this sensor. The 
> simplest approach to get more time from the solar/battery combo would be to 
> use a 3V solar panel (which should exceed a maximum idle voltage of 3.6V) 
> and directly charge a LiFe battery with it. If you ensure that the ESP 
> powers off (deep sleep) at the ESP lower limit (datasheet says 2.5V, my 
> experience says ~2.3V) the LiFe lower discharge limit (2,0V) will probably 
> never be reached. Even with your LiPo this should be possible this way, but 
> you can't use all capacity, since you can't charge it over 3.6V, because 
> this would kill the esp.
>
> In brief:
> - don't use such a breadboard or remove the voltage regulator and the 
> UARTs supply
> - connect a LiFe directly to 3V3 and GND
> - connect a 3V solar panel directly to 3V3 and GND
> - ensure to power off the ESP when it reaches it's minimum required 
> voltage (maybe it's never reached), either with a protection circuit 
> (preferred) or the ESPs internal voltage measurement ability (not 
> preferred, because ESPs sometime run into a state where they aren't really 
> running but drawing current from the battery until the battery is flat and 
> damaged.
>
> This will extend your runtime dramatically.
>
> Currently I'm running my sensor on a 2500mAh LTO Battery, one sample a 
> minute with deep sleep in between gives me more than a week runtime. 
>
> peterq...@gmail.com schrieb am Sonntag, 27. Dezember 2020 um 18:49:54 
> UTC+1:
>
>> I have a secondary temperature sensor that runs on solar and a battery. 
>> This time a year in the northern hemisphere there's not enough sunlight to 
>> charge the battery sufficiently to make it through the night. I handled the 
>> failover to the main thermometer in my customized driver. Details here: 
>> https://hackaday.io/project/101680-solar-powered-wifi-temperature-sensor-for-weewx/details
>>
>> On Sun, Dec 27, 2020 at 7:53 AM michael.k...@gmx.at <michael.k...@gmx.at> 
>> wrote:
>>
>>> The the ESP just reads the SHT35 in a given interval and publishes the 
>>> reading, nothing else. No calibration necessary, the sensor is really as 
>>> good as advertised in the data sheet. And only the outHumidity values of 
>>> the station are off when humidity > 80%rh, other values are pretty much 
>>> accurate and even outHumidity is very accurate below 80%rh. Since I don't 
>>> attach too much importance on historical humidity readings, mixing up 
>>> different source from time to time is no big deal for me. We're talking 
>>> about >99% availability with the less reliable sensor. But the current 
>>> dewpoint and windchill are interesting for me, which both require some 
>>> realistic humidity values.
>>>
>>> "Ok, but I am not sure what ‘prefer_hardware’ has to do with things; it 
>>> is not the same as hardware record generation nor does ‘prefer_hardware’ 
>>> have anything to do with corrections. ‘prefer_hardware’ is used with the 
>>> StdCalculate service, corrections are used with the StdCalibrate service 
>>> and hardware or software record generation is used with the StdArchive 
>>> service."
>>>
>>> Thanks for pointing out.
>>>
>>> Greg Troxel schrieb am Sonntag, 27. Dezember 2020 um 15:01:08 UTC+1:
>>>
>>>>
>>>> You may also want to think about calibration. Besides absolute 
>>>> calibration there is going to be some offset or other more complicated 
>>>> relationship between your two sensors. Given a "prefer precise if 
>>>> available" this is going to cause some flipping betweeen them. I had a 
>>>> little trouble following this thread, and perhaps StdCalibrate runs 
>>>> before the choice. 
>>>>
>>>> But if not, and maybe you want to do this anyway, basically 
>>>> cross-correlated the data from both over a wide range, calculate a 
>>>> mapping function, and put that in the ESP8266 code so that it emits 
>>>> values that are consistent with your other sensor. 
>>>>
>>>> I did this with an ESP8266 that is measuring a 12V lead-acid battery. 
>>>> While I can calculate expected values from the divider resistors and 
>>>> the 
>>>> data sheet, I ended up just measuring the battery and looking at the 
>>>> raw 
>>>> values and figuring out a divisor, which I stored in a calibration 
>>>> file. 
>>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "weewx-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to weewx-user+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/1d8b9f9d-1aed-49db-8090-40ce627c1819n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/weewx-user/1d8b9f9d-1aed-49db-8090-40ce627c1819n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
>> -- 
>> Peter Quinn
>> (415)794-2264 <(415)%20794-2264>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/c167cb2b-559b-4a4e-a581-24ebde53cfb3n%40googlegroups.com.

Reply via email to