#46 Wireless 433MHz Rain Sensor (Transmitter)
HTML-код
- Опубликовано: 15 сен 2024
- Oh no! It's raining and the washing (or cat) is still out! It's VERY easy to create a wireless rain sensor that communicates via a 433Mhz (or 315Mhz) wireless link giving you that all important heads-up that the weather has changed.
This is the transmitter part of the project (with a very simple breadboard receiver to prove it's all working) that transmits via a 433Mhz link the temperature, the humidity, whether it's raining (and the level of rain falling) and the light level too just for good measure. Oh, and it has a capacitive touch sensor just for good measure. Well, why not?
This was originally meant to be an early-warning system to alert us that it was starting to rain and the cat needed to be brought in from his cat run, but has turned into a mini-weather station (that might be expanded in the future). Joy!
----------------------------------------------------------------------------------
The Arduino sketches (code) can all be found here:
----------------------------------------------------------------------------------
1. Very simple capacitive rain sensor 433Mhz transmitter:
bit.ly/2anN82p
2. A very simple 433Mhz receiver to prove it all works
bit.ly/2a3EzNG
3. The final, full-blown transmitter sketch, using just a pinch of C++ pointers, a soupçon of a template and a je-ne-sais-quoi of techniques you may find useful (but not compulsory) in your own projects, yes, really!
bit.ly/2aaSdx0
The DHT11, OneWire and Touch Capacitive libraries are zipped up here but you may wish to find the most up-to-date ones on the Internet.
bit.ly/2am7c8A
Your coding was edifying, showing some excellent practices. Just a comment about memory management and addressing structs: Like all static data declared outside of a function definition, structs are stored in SRAM. In Arduinos, SRAM is limited to 1KByte (ATmega168) or 2KByte (ATmega328) and static data shares SRAM with Stack memory. Stack's use of SRAM varies as different functions are called, memory used by each function call remains in use until that function returns. Thus, when calling a function from within a function, stack will use more memory. In a more complex program, stack can use quite a lot of that small SRAM allocation. One way to reduce stack's use of memory is to minimise the number of arguments to each of your defined functions. When addressing structs this can be used by addressing only the struct (as Ralph does in:
void xmitData(struct WeatherData *weatherData ){
In this example, xmitData's parameters only add 2 bytes to the stack's SRAM use. Now, if one were to employ this policy in all the functions that reference weatherData, detectRain() would be written as:
void detectRain(struct WeatherData *data){
data->rainA = analogRead(rainAnalog);
data->rainD = digitalRead(rainDigital);
debugPrint("Analog Rain: ");
debugPrint(data->rainA, true);
debugPrint("Digital Rain: ");
debugPrint(data->rainD, true);
} // saves 2 bytes of stack memory when compared to using two parameters
NB. the '->' construct is solely for addressing struct fields. It is syntactic sugar for *data.rainA. The difference being that it can be chained. that is IF rainA had been a pointer to another struct, it could be used thus data->rainA->theFieldOfThatOtherStruct.
None of the above is to suggest that there is a bug in Ralph's code. It is just that, with SRAM at a premium, the use of struct addressing is a better practice, thus reducing the chance that a complex sketch might run out of memory and crash. This also demonstrates the efficacy of using structs for blocks of related data.Had Ralph used global variables for all his transmitted data, he probably would have used a lot more memory. BTW, when reading general C/C++ books one often comes across the technique of recursion. This is a very useful technique that reduces complex computations down to a few function calls. Now a recursive function achieves this by calling itself over and over again until the return value comes to a predefined figure. You will learn a lot by studying this technique, but with a the restriction on memory availability in most MCUs, it would be unwise to employ recursion on an embedded system.
Thanks for very interesting (certainly to me anyway) discussion on structs and memory constraints. I must admit that I'm much more familiar with 'managed code' in the .Net world (C# being my current language of choice) where memory (or lack of it) just doesn't come into the equation. But...
But spookily, my very next video is about how we might save some (EEPROM) memory in embedded systems, where you need several predefined messages that won't fit into the available space. And recursion is always a good plaything until you run out of stack and I've even used it a few time when drilling down into directories (folders) and their (sub-) folders looking for files. Ho hum, those were the days.
I'm glad my code stood up to scrutiny (pretty much) but I should have made it simpler; looking at it now I can see how noobs would be well put off by its seeming complexity. I shall bear this in mind for future sketches. Thanks for posting, Michael.
Just found my way to your channel and videos, these kind of videos are what I'm mostly looking for on RUclips.. I love all the descriptions, the electronics, your drawing, the programming/code bits.. You and a couple more, not many though, such as Great Scott, Andreas Spiess, Voltlog, Hari Wiguna and a couple more does these kind of videos and I just love it! Yours are probably the longest also but they are so easy to watch and your voice is just excellent! Easy to understand and easy to listen to.
This specific project is quite close to what I'm "working" with right now, haven't really defined it in any way, just tinkering around so far. But your project inspires me to work on mine more and gives me some tips and ideas for extra stuff to work with.
Really fun and interesting, I'm happy that I found your channel! =)
I'm glad you found me! Keep tuned, more on the way! Thanks for the kind words, great to get feedback.
various modules integrated into the one Arduino board, very nice
Exactly so: each module is an Arduino 'Lego brick' and the code is the 'glue' that holds them all together. Glad you liked the video.
I'm interested in this and would like to have a go at it. I like your channel and you cat :-)
Thanks for your post, Tony weavers, good to hear from you. Benny also says "Hi! and reminds me he appears briefly in my very next video this weekend (or maybe even tonight).
I forgot to mention that if I were doing this project again I would use nRF24L01+ transceivers (I also have a video on them) but there's nothing intrinsically wrong with the 433Mhz transmitter/receiver pair. Just a heads-up, really.
Hello again, Ralph! Sorry to bother you once more. I finally assembled the prototype of the Tx/Rx Rain System (mainly to warn my wife in case her laundring is hanging out to dry!) Unless I'm wrong, you have employed the DHT11 sensor , whose range is 0° - 50°C: what if temperature goes below 0? Benny freezes outside? Or have you switched to DHT22 giving you a warning?
I know: you're not letting Benny out when it's so cold... but I think you get the point.
I am trying to add a second Rx + datalogger unit, to read & store inside temperature (another DHT11) + outside (received) values. But RTC/ SD Card get very cross and stop working... Working on it!
I'm sooo glad I have accumulated all sorts of Arduino bits & knobs during the last years: now plenty of time to play aroud with them!
All the best, Ralph, and thank you for all the work you do!!
I switched from a DHT11 to a (larger) DHT22 at least 2 years ago now, Daniel, as I couldn't understand how it was not below zero with snow on the ground! Doh! I'm _pretty_ sure it was just a straight swap, no change to the electronics or code, but best to check the code! BTW Benny comes and goes as he pleases into his run. He realises when it is cold and comes back in pretty sharpish! This has been running for a few years now, works like a dream!
I did at least one video on the SD module. Make sure your power is nice and clean or the SD card can corrupt the data. And always close the file after each write to avoid the same. Good luck with your enhancement. Good to hear from you.
@@RalphBacon Thanks for the reply and the advise! Keep well!
Some very useful info in this video. I'm going to delve deeper into the capacitance touch sensor circuit and code.
I admire someone who takes such fine care of their animals the same way I do.
I was wondering about the refractive/laser rain sensor you started a in a different video. Did that work out?
Thanks.
I just know I replied to this, Dirk, but it's not here!
My laser rain sensor was not sensitive enough (too small, maybe) but then again my car rain sensor seems to work just fine and it's not very big either. So I chose a standard PCB sensor but only turned it on a few times a minute and in that way prevented all the corrosion. It's still working today! Benny doesn't care any more because I've put a clear roof over his entire cat run now so he is rain-free all year round. He loves it out there.
Good to hear from you!
@@RalphBacon Thanks Ralph. Benny makes a great co-host. My little dog Trixie and I have been watching a ton of your vids as I try to get myself up to speed on micro-controllers. She likes to bark at Benny though.
I was a software engineer before I became disabled and this has been a great help in my occupational/physical therapy. Your vids have a good focus on the hardware aspect of the micro-controller programming and that suits me well. Your efforts have been a huge help and I just want you to know how much I enjoy and appreciate your content. Cheers.
Hello Ralph and thanks once again for your wonderful videos! A real pleasure to follow. I have a question on the TX sketch included here concerning the pin assignment: Pin 7 for both the rain sensor AND for the Beeper? Pin 3 Both for DoorPin and LDR? Where have I lost your explanation of this? Best wishes for your eyes! Daniel from Spain
I had to read my own code to find the (partial) answer, Daniel!
Pin 7, in the TX module is used to read (INPUT) the analog rain sensor. It's also used to beep using TONE (PWM) when the door opens.
Pin 3 is used to read (ANALOG INPUT) the LDR and also as an interrupt pin (TRIGGER, DIGITAL INPUT) when the door opens.
They all comfortably share the functions! I must have tested all this before implementing it and it's been working fine for several years now. Arduino does do a lot to protect us from out own stupidity, so if a pin was generating PWM at the time an analog READ was required, it would switch off the PWM before attempting to read the pin's value. Clever, huh?
@@RalphBacon Veeery clever!! Many thanks for your explanation. In these days of isolation (I'm considered 'at high risk' because of my diabetis & chronical leukemia) I've become a full time experimenter. I've been accumulating boards, sensors, etc.. for the past year and a half, so I'm well equipped! All the best and 'hello' from Maicol (my cat) to Benny!
Hi i need some help for my projet.
And im totally new in this field
Your best resource, Alan, is the Arduino forum (forum.arduino.cc) who have many experts willing to guide and assist newbies to the Arduino world. Just ensure you describe what the stumbling blocks are and what YOU have done to overcome them so far. They won't do your project for you, but they will help you.
Hi, Ralph, I think your rain sensor is a DC component so like all the rest of the cheap china modules is crap and will corrode in a short time and fail so your cat will get wet then he will be waiting to come in but have to take shelter somewhere.
Yes it is, Bob, and you're right that it most certainly does corrode. I don't know whether you've seen updates to this video (yet) but it corroded very quickly. However, I have a couple of other ideas, one of which has been working for several weeks now: don't keep this sensor at a permanent 5v, switch it on, take a reading, switch it off again. Repeat every 30 seconds or so. Works well. A brand new sensor (identical) has been placed next to my original and left unconnected so I can determine the effect of the weather. Result? After several weeks it looks brand new still. I'm also looking at putting a simple heater element underneath the sensor (quite cheap ones available from eBay, waterproof too) so that I can get notified when the rain has stopped. But that's for a future day, after I return from vacation... Oh BTW, Benny has a large covered area; it's not him I'm trying to protect, it's his bedding that we put out in the 'open air' part of his run.
Hi, Ralph, I was not raining on your parade I just did want to warn you of the problems people have as I know when I designed my rain sensor I used a square wave and not dc, Plus wet cats are not good.
All the best Bob and love the channel you are very good presenter
Ha ha, "rain on my parade", I see what you did there Bob, very good! Wet cats are definitely not good, I agree. Wet (or damp) dogs are even worse! Square wave is better than just DC, AC is better than square wave. But taking intermittent readings every 30 seconds or so is pretty good for this type of sensor, at least according to my empirical evidence. Thanks for your support Bob, and kind words, greatly appreciated.
Hi, Ralph we English do have a weird sense of humor yes wet dogs haha not good.
Love your bedroom light at night must look like my old darkroom when I did photography do you have the part number for the LEDs they look bright? Thanks, Bob-UK ps don't think your led propellor will work!!
The LEDs I used were 1 Watt DEEP RED - search ebay uk for "1 - 30 pcs 1W 3W High Power LED without PCB" and you'll see them from supplier 'futureeden'.
Normally I'd buy things like this from the Far East but it was much quicker this way (but much more expensive too).
And it does look *exactly* like a darkroom, but works so well I'm impressed with my own handiwork! When I turn off the bedside light I think "Oh no! I forgot to turn on the red lights" but no, it takes time for your eyes to adjust to the low level red light. Come 2am it is easily bright enough (yet also dim, in a strange sort of way) to see by to visit the loo without waking everyone else up. Great for kids too, when they wake up it's not dark (but not light either). Win win.