How to Build a 4-Channel Wireless Sensor System: Page 2 of 3

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.
on the industry’s cutting edge.    Register Today!

The controller also responds to hosted DHT request (pin13) for data and returns the data and correct checksum in the format defined by the original sensor. Two input bits, PA0 and PA1, are qualified to determine which of the four monitored sensor data, collected in the data array, and are processed to the output, for each request transaction.

PA4, set low, will include the status, as the first byte of a 6-byte response with the requested data. PA4, set high, will format the DHTin/out pin output information with the data and sequence found on the original selected remote sensor’s 5-byte output. With PA4 left open (high), existing DHT22/11 or AM2302 applications will be able access the four channels and should not see any change in their expected operation.

All the LEDs shown in the schematic are used to provide channel status, including a collision and a receiver ‘hit’ pulse. If any of the four upper bits of the received sensor status are set, they are indicated by flashing the associated channel’s LED.

As the receiver will be integrated with a Wi-Fi module and controller I didn’t mount the hardware on a more permanent board. The receiver parts only include LEDs, the controller, discrete hardware, and the RF receiver module.

The interface should provide a low level sync request of > 2ms. If the request line is not released after 40ms the receiver controller will remain idle and will reset the controller whenever the line is finally released. Shown below, with PA4 grounded, is the output including the status byte.

Sensors can be added in real time without resetting the receiver controller. All data in the receiver’s array are initialized to zero and the status bytes of each channel are pre-loaded with only the channel’s 2-bit address value. The application maintains and sends only the last value of each received and qualified channel.

There are some constraints. The timing, both at the sensor transmit and receiver ends, is based on internal oscillators. Perfection costs money and this application didn’t demand crystal based sources or any extraordinary timing attention. For the sensor side there is also a trade needed between accuracy and power. For a possible solar-based power requirement some compromise was required. While there are no issues with the link transmission, the sensor update scheduling is based on the controller's watch dog timer, (WDT). The WDT is more loosely specified than the processor's internal clock, consequently there will be variation with the sensor update scheduling from sensor to sensor. A few to several seconds, more or less, particularly over the temperature variations the sensor may be exposed to should be expected.

Overall, the application allows for a flexible scheme permitting both this temperature/humidity sensor suite and other custom sensors, such soil and water characteristic, to be forwarded over the link. The use of four channels was selected based on practical considerations and controller memory size. Several available controllers would certainly be able to accommodate eight or more channels and their required memory array requirements.

As all transmissions

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.