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