How to Build a 4-Channel Wireless Sensor System

Do you have a DIY monitoring project that could use a boost? Here's how to create a 4 channel Wi-Fi sensor system with a 200ft increase in range over most projects you'll find online.

Search around online IoT communities and resource sites such as thingspeak and you can find several examples of Wi-Fi-based, Arduino-sourced projects that include a popular wireless sensor application using a HDT11 humidity and temperature sensor. These projects have a number of applications in garden, home, and other automation and monitoring projects, including environmental applications, resource, and utility monitoring.

However, the simplest systems are constrained in that they require both a Wi-Fi environment and that they must be located within some fixed distance from the wireless router.

While this may be overcome with cell based systems, when creating local hotspots you still have limits location and perhaps cost return issues.

This project intends to build on the value found in those other projects by providing a wireless DHT-based sensor that extends the range up to 200 ft while allowing for up to four sensors to be monitored using a wired power source, battery, or a solar-based operation. This specific project is for a greenhouse remotely located a few hundred feet away. Its operation includes the sensors, fans, pumps and a misting system.

The hardware is based on a MicroChip 12F509 (transmitter) and 16F676 controller for the receiver. The application uses an inexpensive 433MHZ (up to 4) transmitters and a single receiver. The remote sensor used in my project was a AM2302, (DHT22 or DHT11) humidity/temperature sensor and was built without the up-convertor and terminal headers, shown in the figures and schematic. It uses a 9-volt battery and 78L05 regulator and can be assembled for about $5-6.

The receiver, which handles up to four sensors, provided with all the LEDs, shown in the schematic below, still comes in at $5. For all four remote wireless sensors and the receiver the total costs come in at about $25.

 

The transmitter features a 2-bit, settable, sensor id (S1,S2) and a power control signal to be used either as a transmit drive control (GP1), not shown and or for a transmit indicator. The transmitter reads the sensor, qualifies it, formats a 7-byte outgoing message, shown below, and repeats the transmit at a semi-random delay. Scheduling is coded to be pin allocated by qualifying a signal delay at GP1 upon power up. This allows sensor query and transmissions in 30-second or five-minute schedules.

Depending on the available power, the up-convertor, shown in the schematic, may not be needed. The transmitter I used will operate at 5 volts and allows operation up to 12 volts. I have also coded a second pin, GP5, which will translate the degrees celsius to fahrenheit before assembling the transmission bytes and calculating the correct checksum.

At the receiver, the controller monitors the 433MHz receiver’s output, qualifies the message for transmit collision events and the checksum. It then packs the data into a sorted data array based on the received, transmitted sensor’s ID, included in its transmission.

Pacific Design & Manufacturing, Anaheim, Rising Engineering Star, Linz Craig, Lindsay Craig, FundiBots, Golden Mousetrap Awards, GMTs, Registration is open!      Pacific Design & Manufacturing      connects you with over 20,000 engineers and executives, as well as hundreds of leading suppliers, across the advanced design and manufacturing spectrum who understand the value in working together

Comments

My contact link is: [email protected] The code for both the sensor and receiver controllers should be available with the article. I have the originals and could also provide them. They are coded in assembly language with comments.

Jerald Cogswell's picture
Nice project, William. I will be emailing to ask for source code, etc. If I understand correctly, you created your own simple protocol involving a packet header, device ID, data, and checksum. The Dynamixel motors use a similar protocol with the checksum being calculated as the low byte of the bit inversion of the packet length.

>>> If I understand correctly, you created your own simple protocol involving a packet header, device ID, data, and checksum. I'd also be interested in learning how you implemented your protocol. A good protocol is the key to using these very simple and cheap 433MHz transmitter/receiver sets. That super-regenerative receiver needs to be "primed" with some kind of header so that it can properly set its thresholds for detecting the data bits.

There is always a risk of losing important information while using a cellphone. Smartphones can combine the functionalities of different devices together. It allows us to send emails, navigate through a city, click pictures, or make a call. Instead of carrying multiple devices a... <a href="https://titaniumbackupapk.org/titanium-backup-pro/">titanium backup pro</a>

There is always a risk of losing important information while using a cellphone. Smartphones can combine the functionalities of different devices together. It allows us to send emails, navigate through a city, click pictures, or make a call. Instead of carrying multiple devices a... www.titaniumbackupapk.org

Add new comment

By submitting this form, you accept the Mollom privacy policy.