rolo644u
Sun Aug 14, 2016 1:52 pm
Working on a lux meter to connect with Domoticz Home Automation. It’s a hybrid, it emulates the LaCrosse WS2500-19 lux meter protocol and for low battery signal it can transmit a “Klik aan Klik uit” switch (well known remote switch protocol here in The Netherlands).
First version of the software is running for a day now. It transmits every 7 minutes, but only if lux value is changed. It uses the blue pill board, a low voltage 433Mhz transmitter and a BH1750 light sensor board. No bootloader, programming is done by STLink.
When battery level comes below a treshold two times it transmits a “Low Battery” signal.
The blue pill has the power led and regulator removed, to keep power consumption as low as possible.
Now let’s see it the software and hardware runs ok for a longer time.


mrburnette
Sun Aug 14, 2016 2:24 pm
While your sensor is human-eye light spectrum corrected and will give fair results on “relative brightness” you should be aware that the LUX value is likely 20% “off” due to the clear enclosure absorption spectra.

Ray
Ollie
Sun Aug 14, 2016 2:27 pm
Did you have a chance to measure power consumption for the 7 minute idle time? How about the transmit time?
rolo644u
Sun Aug 14, 2016 4:28 pm
Yes, I know that the clear enclosure will have effect on the lux value’s but the absolute lux value is not important here, the relative value is good enough for my application. Once I know the lux at dusk, or at a cloudy day I can use the values in domoticz scripts.
About the power consumption, it a bit theoretical and my goal was to go over a year of battery use. I measured 3.3 uA when in standby, and 23.12 mA peak when awake and transmitting. That takes 644 ms.
So using this formula : Iavg = ((I1xT1) + (I2xT2))/(T1+T2) = 0,0386 mA so do the math. A CR123 should have 1500mAh but I’m not discharging it to 2V, that’s to low for the light sensor. So I take 1000mAh capacity, with Iavg at 0.0386mAh it should last for 1079 days.
The controller switches back to 8 MHz clock after wake up, no need to go for the full 72 MHz, the transmitting of the data does take a fixed amount of time.
In real life the battery life has to be tested, there are more factors involved, self discharge, temperature, ect. But as long as it’s > 1 year I’m happy.
Also I’m not sure if I’m putting the sensor outside or inside behind a window. Adding glass wil introduce more diviation but the sensor will stay clean and dry.
RogerClark
Sun Aug 14, 2016 10:38 pm
Very interesting. Thanks for sharing.
I’m currently building a device which operates from a battery as it will be on a bicycle, and I have been experimenting with how much power can saved by reducing the main clock freq.
Im using a GD32 at the moment, which has a 12Mhz crystal, and takes 11mA when running at 12Mhz.
I presume you set the PLL multipler to 2 and used the Divider ( by 2) which is in front of the Pll multiplier, (bit 17 of the control register) to achieve 8MHz ?
i removed the power LED but I have not removed the regulator yet, as I am still uploading via USB for testing.
Did you try changing the GPIO clock divider ? I think we have this set to its fastest setting, but you may be able to use a slower GPIO clock and save some power.
I presume you have also shut down the ADCs etc etc?
My main problem is that I need wake from external input and also milliscecond sleep times.
So I need to modify the RC library to use milliseconds instead of seconds as its timebase, and I am still mot sure how to wake from external interrupt.
rolo644u
Mon Aug 15, 2016 3:17 pm
The first instruction after wake up is :
// Step down to External (RCC_CLKSRC_HSE) 8MHz, no multiplier.
rcc_switch_sysclk(RCC_CLKSRC_HSE);
RogerClark
Tue Aug 16, 2016 3:53 am
rolo644u wrote:The first instruction after wake up is :
// Step down to External (RCC_CLKSRC_HSE) 8MHz, no multiplier.
rcc_switch_sysclk(RCC_CLKSRC_HSE);
ahull
Tue Aug 16, 2016 3:50 pm
RogerClark wrote:Its a shame that it doesn’t allow the whole processor to be run from the LSE, but as far as I can tell that’s not possible.
rolo644u
Tue Aug 16, 2016 5:46 pm
Now the sensor is running for a few day’s and it’s working, but I noticed that the interval time between measurements shown on Domoticz was exactly 5 minutes. That’s strange, I use 420 seconds for the alarmDelay in :
sleepAndWakeUp(STANDBY, &rt, alarmDelay);
ahull
Tue Aug 16, 2016 9:08 pm
rolo644u wrote:Now the sensor is running for a few day’s and it’s working, but I noticed that the interval time between measurements shown on Domoticz was exactly 5 minutes. That’s strange, I use 420 seconds for the alarmDelay in :
sleepAndWakeUp(STANDBY, &rt, alarmDelay);
RogerClark
Tue Aug 16, 2016 11:10 pm
Andy
I will need to look in more closely at the code, but I was under the impression that the RTC counter had 0x7FFF selected as its clock divider from the 32.768kHz LSE crystal.
i.e one count per second.
But perhaps the alarm timer is different from the RTC time register
rolo644u
Wed Aug 17, 2016 6:58 am
I think I have solved the time issue. I did the folowing changes :
After power up I set the time, this gives the RTC registers valid values :
rt.setTime(1471392000); // Set time to 08/17/2016 @ 12:00am
// Real time not important, just give the RTC registers sensible starting values after powerup
RogerClark
Wed Aug 17, 2016 7:37 am
Was the main thing that fixed this, the setting of the actual time into the RTC register ?
I just checked the programming reference and the RTC counter register would default to 0x00000000
The Alarm register defaults to 0xffffffff so should not trigger an interrupt for years.
rolo644u
Wed Aug 17, 2016 9:06 am
The second thing, not using STM32sleep library did the fix, setting the RTC to a sensible time is good practice, I found this in other STM32 pieces of code. The theory behind it is (I think) that the RTClock lib calculates unix times to the BCD format of the RTC registers.
ahull
Wed Aug 17, 2016 1:49 pm
rolo644u wrote:The second thing, not using STM32sleep library did the fix, setting the RTC to a sensible time is good practice, I found this in other STM32 pieces of code. The theory behind it is (I think) that the RTClock lib calculates unix times to the BCD format of the RTC registers.
rolo644u
Sat Aug 20, 2016 4:41 am
Lux meter is running for some day’s now and the timing is still not ok. At first there is 420 seconds sleep time, but after a while the sensor sleeps with greater, unpredictable intervals, going into > 10 hours. Pressing the reset button (no battery pull needed) get’s it on track again and the same story repeats. I found the ST Application note AN2821 where the RTC is described, I will take a good look at this but a quick scan shows that it’s using the backup registers for the calender. I’m using some of the backup registers to save variables, maybe there is a conflict.
enijeboer
Thu Aug 25, 2016 8:42 am
This is an interesting project for me as well as I am using Domoticz with RFLink to drive my sunblinds. Are you willing to share this project. So what hardware you used, how they are connected and also the software that you are running on it.
ahull
Thu Aug 25, 2016 9:54 am
rolo644u
Fri Aug 26, 2016 12:09 pm
enijeboer wrote:This is an interesting project for me as well as I am using Domoticz with RFLink to drive my sunblinds. Are you willing to share this project. So what hardware you used, how they are connected and also the software that you are running on it.
rolo644u
Sun Aug 28, 2016 1:14 pm
I have decided to switch to using MySensors for my lux meter, so will not be updating this post. For who’s interested I’m open to publish the code that I developed in this project. I comes “as-is”, let me know by pm if you want it.
I will be using the STM32, just not for this specific project.