search

matthias-bs / BresserWeatherSensorLW

Bresser 868 MHz Weather Sensor Radio Receiver based on ESP32/RP2040 and SX1262/SX1276 - sends data to a LoRaWAN Network
MIT License
12 stars 1 forks source link

Implemented battery voltage measurement for Heltec WiFi LoRa 32 V3 #16

Closed matthias-bs closed 6 months ago

matthias-bs commented 6 months ago
evon800c commented 6 months ago

Hi @matthias-bs, i'll try to do some test in the next few days. If you need specific test, let me know. Davide

matthias-bs commented 6 months ago

@evon800c Could you please check the battery voltage measurement with and without a battery? I'm not sure if VBAT equals VUSB / VDD_5V in the latter case.

evon800c commented 6 months ago

Hi, @matthias-bs Could you please tell me the pins and headers (j3/j2) where you want me to take the measurement? https://resource.heltec.cn/download/WiFi_LoRa_32_V3/HTIT-WB32LA(F)_V3.png I imagine that the battery is the one connected to the connector below. davide

matthias-bs commented 6 months ago

Hi @evon800c ,

the battery connector is a white JST connector on the bottom side of the PCB.

The second case can only be tested if USB is not connected (otherwise you will still see the voltage coming from USB), which means you cannot check it in the debug output. Instead you have to check the LoRaWAN uplink payload.

I have recently added some documentation and the payload formatters, so you can hopefully use this without too much effort.

Best regards and a happy May Day, Matthias

evon800c commented 6 months ago

Hi, @matthias-bs

you have perfectly described what i have in mind.

I'll try to explain what is my lab environment at the moment. I have 2 heltec board with the same code, that are in power on. Both of them are receiving data from the same weather station. I'm doing some test to understand the better way to manage the energy... batteries, solar power panel size and and so on. Both boards are not connected to pc usb, so as you correctly say, i can't see any info from debug side. I observe data only from uplink "supply_v" field.

node 1 is connect with usb to power line, has no battery attached and as you can see from image 1 has more or less the same supply_v value ~ 3.9V, on my tester i see 4118/9mv.

node 2 is connect with jst board connector to a 18650 (3.7V 2600mh), has no other external power atteched. and as you can see from image node 1 the value go down as i expected. During the night at ~4:00 AM change the sleeping time to 900s.

From my point of view, all is working fine.

At "2024-05-02 11:45:45 GMT+2" the uplink supply_v show 3325, while on tester i can see 3516, i suppose that some adjust is need to be done.

I have attached the usb supply on node 2, also with battery attached (this board can charge the battery when powered with usb) on tester i can see 3890 in increasing. I'm waiting for other uplink value to read the supply_v value.

At "2024-05-02 12:00:58 GMT+2" the uplink supply_v show 3995, while on tester i can see 4112. The new voltage level permit to change sleep value and as we can see in the images ... supply_v increase as expected.

At "2024-05-02 13:44:58 GMT+2" the uplink supply_v show 4020, while on tester i can see 4196.

I hope this information can be useful to you. For any other test and/or consideration, i'm here.

Thanks a lot Davide

image 1 01

image 2 02

image 3 03

matthias-bs commented 6 months ago

Hi @evon800c,

thank you very much for testing! The difference in voltage measurements between the ADC readings and your tester is a little bit concerning. 100...200mV difference means a lot when measuring a li-ion battery voltage. I think the usual effects like tolerances and voltage drop across the supply connections are not big enough to cause such a difference.

Maybe this is caused by the weird implementation of the voltage divider as described in https://github.com/matthias-bs/BresserWeatherSensorLW/issues/4#issuecomment-2070626966. If this is the case, the accuracy could be improved by using a lower attenuation of the ADC input.

Best regards, Matthias

BTW: You seem to use InfluxDB & Grafana for processing and displaying the data. If you like, you could add a short tutorial on how to set this up to the project...

evon800c commented 6 months ago

Hi, @matthias-bs

no problem writing something to indicate how to integrate influxdb and / or grafana, let me know what approach to take and I'll try to do something.

Note: I don't use TTN as a LoRaWAN network, but a personal LoRaWAN network implemented with Chirpstack on my personal lab.

Davide

evon800c commented 6 months ago

Hi @matthias-bs,

I don't know if it can be useful... but I did some tests by varying the attenuation by inserting "analogSetPinAttenuation(ADC_CTRL, ADC_XXdb)" before the "delay (100)" in the reading of the value for the "heltec".

I report the values detected. they are not very precise but they can be a starting point.

ADC_0db    multimeter=4151 supply_v=4065 diff=86
ADC_2_5db  multimeter=4162 supply_v=4088 diff=74
ADC_6db    multimeter=4157 supply_v=3972 diff=185
ADC_11db   multimeter=4157 supply_v=3935 diff=222

cheers, Davide

matthias-bs commented 6 months ago

Hi @evon800c ,

great finding! I thought it were more complicated. I'll add it in the next release!

Thanks and have a nice evening! Matthias

matthias-bs commented 6 months ago

Should be analogSetPinAttenuation(PIN_ADC_IN, ADC_0db), right?

evon800c commented 6 months ago

yes correct,

I set analogSetPinAttenuation(ADC_CTRL, ADC_2_5db); //ADC_2_5db, ADC_6db, ADC_11db to remeber the other possible values.

There is also another command "analogSetAttenuation(ADC_2_5db);" that can be used in the same way, but in that case the attenuation are applied to all pin

matthias-bs commented 6 months ago

Hmm, I mean it should be applied to the ADC input pin, not the ADC control pin (which is just used as digital output to switch the MOSFET between VBAT and the ADC input). I just added the line to the main branch.

evon800c commented 6 months ago

mmmm correct