battery level
micg77 opened this issue · 3 comments
micg77 commented
Hello,
thanks a lot for your program.
I have found where the battery level is fixed : it is the 3rd bite of nyble 8.
If you add battery_level = bitRead(nyb(8),2); you get it.
Hope it will help.
Micg77
robwlakes commented
Hi Micg77,
Thank you for your interest in my work. I spent a fair bit of time
trying to find a battery status bit, but could not confidently establish
anything I was confident in. The very low current draw of these sensors
mean they approach the thermodynamic optimum to extract every last drop
from the battery (ie very little energy wasted as heat within the
battery due to its own internal resistance, which becomes more
significant the heavier the current). As you will be aware I gave up
and devised a check on the consistency with the signals are received as
the indicator of battery health. This also checks the actual state of
the sensor as well, ie has it fallen off the roof and lying at the
bottom of the garden???
You have also sent me another email regarding the negative bit on the
temperature sensor. This one worries me more as people who are unlucky
enough to have to endure very cold temperatures maybe relying on that
data. However I live in a climate that hardly ever reaches 2-3 degrees
Celsius let alone, negative Celsius. We occasionally get frosts. I
will definitely look into that myself.
You quote the model number of the Oregon Sensor for the thgr810
(humidity and temperature sensor using Oregon v3 protocol), was that the
one that you found the low battery bit as well? I now have four
sensors stations: wind speed and direction, temperature and humidity,
rainfall, and have now added a UV sensor as well (3months ago). I am
very occasionally getting some weird stuff from it though. This morning
is an example.
SolarPower
Where you can see 5 hours ago (in total darkness) I have registered a
blip in UV Light. I have used the standard OS checksum for the sensor
readings, so it must have complied with that to be recorded by the
Arduino. Because I take the average of 16 readings, it is actually only
one rogue reading of 255, but this messes up the 16 subsequent readings,
hence 255/16=15, for 16 readings. It can go for weeks before this
happens. I am reluctant to write a crude filter, as I would prefer to
understand it and knock it out logically. So for the moment I am
tolerating it.
If you happen to get a UV Sensor, then I would love to hear if you have
the same problem, or whether I have a faulty sensor.
Also when you were testing for the battery bit with the low temperature,
how did you eliminate the possibility that the battery low bit that
turned over did not come from erratic low voltage behaviour of the whole
system, rather than the sensor CPU deliberately switching that bit? I
found I could not be confident in the low battery indicators (that I
thought I had found) were not just random bits changing as the system
got closer to totally shut down. Do you have an Oregon console that
receives and shows that low battery condition at the same time as you
can detect on the Arduino? My console I keep in the kitchen does not
have any low battery indicators. I feel that if Oregon had implemented
such a system their consoles would have shown the data on their LCDs.
Thank you for your interest and communication of your ideas. As you can
see I retain an ongoing interest in this project and always keen to
improve it so I really appreciate your communication. Have you
published your code anywhere? I need to update my GitHub site very soon
so the UV stuff and LED activity indicators are revealed.
Cheers, Rob
…On 21/03/17 07:26, micg77 wrote:
Hello,
thanks a lot for your program.
I have found where the battery level is fixed : it is the 3rd bite of
nyble 8.
If you add battery_level = bitRead(nyb(8),2); you get it.
Hope it will help.
Micg77
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#6>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/AGzc5RvseeiaPs1UO97WuqzPBbL5rrrMks5rnuD7gaJpZM4Mi-A8>.
--
*Rob Ward*
Lake Tyers Beach, 3909
Lake Tyers Beach Website <http://www.laketyersbeach.net.au>
Ubuntu Mate - A great OS <https://ubuntu-mate.org/>
micg77 commented
Hello,
thank you for your developed answer. (sorry for my level of english, I will do my best to answer you)
I don't have any UV sensor. so I can't help about your problem. But I have in mind to have one. So it is interesting for me anyway to have your feedback.
My project is not finished yet, so I haven't published anything. My goal is to control my electric heaters in each room of my house. So my arduino reads the temperature coming from 3 THGR810 sensors, and asked every electric heater to turn on or off depending on the instruction.
That is why it is important for me to have the low battery information;
I have done all my test with 3 THGR810 sensor. This kind sensor has a small screen. So i can read on it : temperature, humidity and low battery information.
So i can easily compare the screen with what tells the arduino.
I have also discover that the low battery sign turns on on the screen when the voltage is below 2,5 Volt.
To avoid rolling code problem, and minimise the number of changing value in the signal, I have build the following protocol : I have chosen 2 old AAA battery which have 2.53 Volt together at ambiant temperature (thanks to the toys of my kids). I have put the sensor in my freezer (minus -18°C) hoping that the old battery would have their voltage to decrease.
Then i have displayed all nyble waiting for any change and it has worked.
I have done many checks using this protocol.
To validate I have done some other tests with my other THGR810 sensor. And now I am really confident with my result.
Of course, I can't tell with the other kind of sensor (wind and rain).
Thanks again for your program which has helped me a lot to understand the oregon v3 protocol.
Cheers,
Micg77
robwlakes commented
Hi,
My observation of the UV sensor is that it seems to reflect the "solar
power" of the day, and fluctuates largely in line with cloud cover. So
while not being a direct solar power indicator could be used for home
control of solar heating features. Eg opening or closing blinds etc We
live by the sea at a popular but slightly remote beach front and people
getting exposure to UV (ie and later on cancer) is a problem so I
thought that sensor could help people be more careful.
THGR810 sensors is a good choice as think they have their station
numbers as switches? So you can identify them. Excellent choice. I
have looked at those sensors in the shops but had not noticed the
battery level indicator. I will check again for interest. I tried to
do the low battery bit search on my anemometer as it the highest and
most dangerous to service (approx 8m high on top of steep roof). I
could not determine any bit that changed predictably enough to be
confident of its status. It would be good to focus though on that bit
you have identified and recheck it all over again. I have a spare
anemometer as a backup, so I could experiment with it. I really like
the idea of putting the batteries in the freezer to help accentuate the
"failing" battery voltages. Excellent work!!
Replicating the same bit across three sensors is also excellent
science. I like what you do.
I will take my anemometer to my son's place next time and experiment for
the battery bit. (Ignoring the rolling ID codes means I can't use it at
our home or it will confuse the Weather station Arduino.) You have
inspired me to give it one more try.
Thank you, Micg77.
Rob
…On 22/03/17 05:25, micg77 wrote:
Hello,
thank you for your developed answer. (sorry for my level of english, I
will do my best to answer you)
I don't have any UV sensor. so I can't help about your problem. But I
have in mind to have one. So it is interesting for me anyway to have
your feedback.
My project is not finished yet, so I haven't published anything. My
goal is to control my electric heaters in each room of my house. So my
arduino reads the temperature coming from 3 THGR810 sensors, and asked
every electric heater to turn on or off depending on the instruction.
That is why it is important for me to have the low battery information;
I have done all my test with 3 THGR810 sensor. This kind sensor has a
small screen. So i can read on it : temperature, humidity and low
battery information.
So i can easily compare the screen with what tells the arduino.
I have also discover that the low battery sign turns on on the screen
when the voltage is below 2,5 Volt.
To avoid rolling code problem, and minimise the number of changing
value in the signal, I have build the following protocol : I have
chosen 2 old AAA battery which have 2.53 Volt together at ambiant
temperature (thanks to the toys of my kids). I have put the sensor in
my freezer (minus -18°C) hoping that the old battery would have their
voltage to decrease.
Then i have displayed all nyble waiting for any change and it has worked.
I have done many checks using this protocol.
To validate I have done some other tests with my other THGR810 sensor.
And now I am really confident with my result.
Of course, I can't tell with the other kind of sensor (wind and rain).
Thanks again for your program which has helped me a lot to understand
the oregon v3 protocol.
Cheers,
Micg77
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGzc5VDHPbjqDI2v0KhEnDeMywuhuHQjks5roBYIgaJpZM4Mi-A8>.
--
*Rob Ward*
Lake Tyers Beach, 3909
Lake Tyers Beach Website <http://www.laketyersbeach.net.au>
Ubuntu Mate - A great OS <https://ubuntu-mate.org/>