It certainly looks nice, but if you're worried about condensation, why not use the current that would have gone into the fan to heat a few small resistors glued onto the plastic holding the sensors ?
Maybe I'm wrong, but I expect that the only time you'd be expecting dew (or maybe frost) is at night between sunset and sunrise and so temperature, not airspeed, would be the answer. Instead of feeding 100 mA into a 12V fan, you could feed it to, say, four 30ohm eighth watt resistors around the sensor "nozzle". That'd add the same power as the fan would have used (1.2 watts) as a mini-heater to prevent dew or frost from forming. It would also cut down maintenance, since the fan would probably need to have bugs and dust cleared away from it occasionally.
I'm assuming here that the fan is intended to circulate the air and won't be powerful enough to just blow the condensation off the sensor's surface. That is another possibility.
But, since I also assume that desert air should have very low ambient humidity, just drilling holes in the side of the pipe should allow the humid air trapped in the pipe to escape and lower (or eliminate) the chance of condensation. This is an experiment you could try over the winter. Just put some water in one of your test pipes with a plastic bottle cap screwed onto a board across the top. Leave it out for a couple of nights and then check it in the morning to see if the bottom of the cap is palpably wet.
If it never feels wet then you don't need to worry about condensation on the sensor.
If it gets wet, then drill holes in the pipe and re-test.
If it still gets wet, put in a fan at the top of the pipe.
If it still gets wet, try a small circle of resistors around the plastic.
If it still gets wet, move somewhere with a better water supply 🙂
Anything seems possible when you don't know what you're talking about.
Then The following might include a fan and allow room for weatherproofing processors.
Thats a promising design, I like the look of that. 👍
A simple fan arrangement that can be set to blow for a short while before taking any readings would probably eliminate moisture problems, though I note the article was not definitive the moisture was the actual cause of the rogue readings. Could it have been caused, for example, by the whole sensor overheating in the sun I wonder. Once your initial experiments are concluded then a mockup outside where you intend to put the whole apparatus may give some more information.
But I'm not clear whether this pipe topped with its sensors and possible fan arrangement all in the enclosure you show, is going to be within an enclosure of some sort (some sort of outdoor building), or under a protective roof, or open to the sky. Understanding this actual physical arrangements of the installation are key to being able to proffer well considered comments.
But I'm not clear whether this pipe topped with its sensors and possible fan arrangement all in the enclosure you show, is going to be within an enclosure of some sort (some sort of outdoor building), or under a protective roof, or open to the sky. Understanding this actual physical arrangements of the installation are key to being able to proffer well considered comments.
For sure under a protective roof. All electronics will be in some type of weatherproof cabinet.
Maybe I'm wrong, but I expect that the only time you'd be expecting dew (or maybe frost) is at night between sunset and sunrise and so temperature, not airspeed, would be the answer. Instead of feeding 100 mA into a 12V fan, you could feed it to, say, four 30ohm eighth watt resistors around the sensor "nozzle". That'd add the same power as the fan would have used (1.2 watts) as a mini-heater to prevent dew or frost from forming. It would also cut down maintenance, since the fan would probably need to have bugs and dust cleared away from it occasionally.
Once frost arrives irrigation needs are about done and wow just learned how to create a mini heater. And I do wonder what the effects of heat on the transducer might be.
I'm assuming here that the fan is intended to circulate the air and won't be powerful enough to just blow the condensation off the sensor's surface. That is another possibility.
Yep just circulate air.
But, since I also assume that desert air should have very low ambient humidity,
Yes very low except when it is not and that does happen
Ideally I could do without forced air circulation and possibly there needs to be some experimentation.
though I note the article was not definitive the moisture was the actual cause of the rogue readings.
Yes this is probably what stood out most in the article. 1/3 or readings were bad and they seemed to determine this by getting readings at the extremes of the sensors ability. But the other 2/3 of the time the readings appeared valid. So their sensor, and I see no mention of redundancy, worked and I wonder if they had > 1 sensor what kind of observations they would have experienced. Seems they were keeping records, good for them!
Maybe I'm wrong, but I expect that the only time you'd be expecting dew (or maybe frost)
Speaking of frost we've had some and more important the River Water supply is off until March 15, 2022. With that I need to winterize the current irrigation system AND I did fill both my 275 gal IBC tanks awhile back to assure no leaks. Well they are still full, absolutely nothing missing, but I have to drain them.
A roof will give protection from the sun and rain but, here's another thought. Bugs.
Not a comment on your programming prowess, but real bugs. Flying bugs coming in for a drink of water in the pipe. Some may drown and some may fly or crawl up and prowl on your sensor.
Not a comment on your programming prowess, but real bugs.
I watched a video where they were collecting rain water. There was a nice approach to placing screen in open pipe, they ended pipe with a female coupling, pushed a piece of screen in and pushed a piece of pipe in to hold it in place. As for the design just offered all openings to outside world would be appropriately screened. One way or another!
Now if I could just find a just as easy way to keep the bugs out of my code, that would be a blessing. And NMW (No Matter What) bugs find their way in and often caused by a difference you missed between testing and production. My biggest barf was in an IMS DB/DC (IBM Information Management System Database/Data Communication) application where all your restart data was logged by IMS and allowed you to restart at your last checkpoint. Checkpoints were overhead so you used them sparingly. Well test, test, test! Go through all code with an interactive debugger. Bring in the team for another code and implementation review. Put trips in to ABEND program and test the restart. Did it run fast, was it efficient YEA! I was good to go and the program went into production.
What was overlooked was often the schedulers run stuff in the foreground (along with online systems) instead of background. Well all that restart data when in the foreground was written to fast online buffer instead of DASD. YEP, I brought all of Bayer USA to its knees, the buffer overflowed and the online system crashed. Should have had a test in there for foreground/background. To say the least it was embarrassing, but we added something to the code/system implementation process.
You know your speaking, more than once, of "Bugs", not software, but from the animal world crawling into the system to "Bug" things up brings me back to the early 1980's and teaching night school Basic classes. I used to enjoy telling the students where the name "Bug" in relation to computers came from. You probably know, but may not, but those first mainframes kept track of the 0'1 and 1's, Low's & Highs, Off and On with little magnetic doughnuts with I believe 3 wires passing through then by which magnetic state, positive or negative, could be set or read. Well a fly landed on one of those junctures and got fried/electrocuted and the setting and reading of that doughnut did not work. I would follow up this little explanation with an analogy centered on the "Bug Wacker", popular at the time, in my yard that when bugs landed on the wires it fried them and you would hear them getting fried. Subtle? One little bit not working? Yea! I guess the first discovered occurrence was met with a WTF but subsequently it was standard procedure to Debug the Computer for unexplained errors.
There you go, we have to seriously consider "Bugs" in both software and hardware, thanks for reminding me!
Nooooo, all that water to waste? Why do you need to drain them?
Won't be wasted, we like to do a deep watering on shrubs and trees now and partway through winter. We see trees dying pretty often that are ignored all winter long. Last year lucky we got a couple inches of snow, if that. Some years we get 3-4 feet all at one time.
You know your speaking, more than once, of "Bugs", not software, but from the animal world crawling into the system to "Bug" things up brings me back to the early 1980's and teaching night school Basic classes. I used to enjoy telling the students where the name "Bug" in relation to computers came from. You probably know, but may not, but those first mainframes kept track of the 0'1 and 1's, Low's & Highs, Off and On with little magnetic doughnuts with I believe 3 wires passing through then by which magnetic state, positive or negative, could be set or read. Well a fly landed on one of those junctures and got fried/electrocuted and the setting and reading of that doughnut did not work. I would follow up this little explanation with an analogy centered on the "Bug Wacker", popular at the time, in my yard that when bugs landed on the wires it fried them and you would hear them getting fried. Subtle? One little bit not working? Yea! I guess the first discovered occurrence was met with a WTF but subsequently it was standard procedure to Debug the Computer for unexplained errors.
There you go, we have to seriously consider "Bugs" in both software and hardware, thanks for reminding me!
You know your speaking, more than once, of "Bugs", not software, but from the animal world crawling into the system to "Bug" things up brings me back to the early 1980's and teaching night school Basic classes. I used to enjoy telling the students where the name "Bug" in relation to computers came from. You probably know, but may not, but those first mainframes kept track of the 0'1 and 1's, Low's & Highs, Off and On with little magnetic doughnuts with I believe 3 wires passing through then by which magnetic state, positive or negative, could be set or read. Well a fly landed on one of those junctures and got fried/electrocuted and the setting and reading of that doughnut did not work. I would follow up this little explanation with an analogy centered on the "Bug Wacker", popular at the time, in my yard that when bugs landed on the wires it fried them and you would hear them getting fried. Subtle? One little bit not working? Yea! I guess the first discovered occurrence was met with a WTF but subsequently it was standard procedure to Debug the Computer for unexplained errors.
@wamagee Did you know that for the LCS at least, they had women using knitting needles to construct the memory. IIRC, some of those magnetic systems were 5 wires as well as the 3 wire versions. Don't remember why, memory is fading,
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.
We use cookies on the DroneBot Workshop Forums to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
