Closed JopWerff closed 2 years ago
This looks much better! Today too busy, but I will try as soon as possible.
OK.
I let him run for a few hours today and do some tests. to see if things pop up.
next release There is a delayMicroseconden(1500) in the code - (see datasheet) - and that value might be tunable in the next release. Now a acquisition takes 3.3 ms and it might be possible to bring it down to 2.5 or even 2.0 ms.
Furthermore I am going to test the I2C clock frequency, Could also give some gain, maybe another ms. That does not look much but for RTOS environments every gain counts.
Ice-thickness I understand the context, any specific sensor / technology in mind?
I wait until you give a signal that a new version AM2315 library can be updated.
IceThickness - yes I have a technology found (maybe) - later I will write more.
If you have an idea or found something in the area of mprocessor sensors, let me know.
You can try the develop branch as I found no problems with it. It ran for an hour or so yesterday every 2 seconds with no failures.
About the Ice thickness you might mail me directly - see library.json
released 0.1.1 - found no problems anymore today.
I got problems and very weird and not clear I used the forked develop version 0.1.1
here some problems:
the weird thing, it has also a relation with the delay between the sampling calls
I will send you my sketch - based on your example - by mail (see the comments)
Strange, not expected this
With the unknown error it just repeats the last values
If time permits I will try to replicate the setup with a ESP32 today. Do you power the sensor with 5V or 3V3?
now with 5V, before it was 3.3 but this was with your early version of the library. (and with the Adafruit-libr)
Shel I try with 3.3 again?
First test ESP32
On 3V3 I got no data at all, on 5V I get output similar to yours (investigation starts )
TEST 1: AM232X library
So this works, now look at the diff in implementation.
TEST: adapt read() function to working AM232x version.
"transplanted" the wakeUp part in the read() of the AM2315 library == Looks good!
Now check next difference in timing.
@JopWerff
Looks slightly better as time between 2 read calls is closer to the 2.000 seconds.
I let it run for half an hour, clean up and prepare a new release, so you can test too.
ok, thnx
@JopWerff
All looks stable on ESP32,
please verify if it works for you
update:
@JopWerff Short test 1 read per minute.
Looks stable, I let the test run for some time.
What came up in my mind: wouldn't it be possible to create a possibility to switch off (and on) this automatic "go sleep" mode? Of course for battery and solar charged situations this sleep mode is very useful.
In my situation this "go sleep" is not necessary as all the m-processors (ESP32) are fed with continuous power. For test and demo modes I would disable the automatic "go sleep" mode and for regular use I would enable it (because as an ice skater I'm also worried about the climate change. - we shouldn't destroy our habitat - waiting so long on the next Elfstedentocht )
The sensor itself shuts down to save energy, that is why the library needs a wake-up function. As far as I know there is no switch to disable/enable it, The only way to overrule it is constant reading. (however there are several undocumented registers)
The one minute test still going strong.
16:30:01.230 -> AM2315, OK, 50.1, 19.2 16:31:01.248 -> AM2315, OK, 50.1, 19.2 16:32:01.226 -> AM2315, OK, 50.0, 19.2 16:33:01.235 -> AM2315, OK, 50.0, 19.2 16:34:01.260 -> AM2315, OK, 50.0, 19.2 16:35:01.257 -> AM2315, OK, 50.0, 19.2 16:36:01.258 -> AM2315, OK, 50.0, 19.2 16:37:01.225 -> AM2315, OK, 50.0, 19.2 16:38:01.241 -> AM2315, OK, 50.0, 19.2 16:39:01.272 -> AM2315, OK, 50.2, 19.1 16:40:01.242 -> AM2315, OK, 50.4, 19.2
17:55:01.446 -> AM2315, OK, 49.0, 19.7 17:56:01.451 -> AM2315, OK, 49.0, 19.7 17:57:01.439 -> AM2315, OK, 49.0, 19.8 17:58:01.425 -> AM2315, OK, 49.0, 19.8 17:59:01.443 -> AM2315, OK, 48.9, 19.8 18:00:01.433 -> AM2315, OK, 49.0, 19.8
3.5 hrs no failure with ESP
mmm, next test fails again
18:29:48.452 -> AM2315, Connect error, -997.8, -999.8 18:29:58.460 -> AM2315, Connect error, -997.8, -999.8
Had connected a 2nd I2C device and system fails. Not clear what is the cause...
powerline error, fix and it works again 😀
20:00:06.511 -> AM2315, OK, 51.9, 20.2 20:00:16.541 -> AM2315, OK, 51.6, 20.2 20:00:26.547 -> AM2315, OK, 51.4, 20.2 20:00:36.534 -> AM2315, OK, 51.4, 20.2 20:00:46.529 -> AM2315, OK, 51.4, 20.2 20:00:56.542 -> AM2315, OK, 51.4, 20.2
1.5 hrs every 10 seconds no problemo.
@JopWerff Going to dive in another project now, If you can confirm it works I will merge the 0.1.2 version into master
This is much better. It seems that all is ok. But wait until I've tested this also with other I2C pins dedicated, because that's my need in the end for my crowded ESP32-board.
Why is the Wire-library included?
As this code
#include <AM2315.h>
//#include "Wire.h"
AM2315 sensor(&Wire);
compiles also.
That extra include is probably some leftover from testing. I check the code once again today to see if there are other minor edits to improve maintainability.
0.1.2 released.
Hoi Rob,
Your DHTNew is a very nice library and has advantages over the other DHT-libraries. I tested it with the DHT22. I'm working with an ESP32,
For my real life project in the open air in conditions of rain and frost I would like to use a more robust version. This one: https://www.tinytronics.nl/shop/nl/sensoren/lucht/vochtigheid/am2315-i2c-temperatuur-en-vochtigheidsmeter
This complete product is using the AM2315, as you see.
But I read in the specs for your DHTNew: "Supports DHT11, DHT22, DHT33, DHT44, AM2301, AM2302, AM2303 as these all have the same protocol."
You will understand my question now: is your fine library DHTNew also suitable for the AM2315?
Kind regards,