2 Replies Latest reply on Oct 30, 2014 12:55 PM by wishmaster88

    Gal 1 to DHT-22/11 interface through the serial port




      Read Strategy.bmp

      There have been several threads concerning interfacing the Gal board to the DHT humidity & temperature sensors. The difficulty arises from the timing requirements of the DHT and what can be provided by the Gal GPIO & OS. Most recently,  a two wire interface 'workaround' was posted. In this post, I present the method I implemented to use these sensors with the Gal.


      The DHT interface is a custom one wire protocol with some precise timing requirements that you can read about in the data sheets. The GPIO on the Gal, along with the OS, can not meet those requirements. You can still use the DHT but you need some help. In my implementation, the help comes from the use of an interface in the form of a  PIC 10F202. The chip costs all of about 50 cents and seems to me to be a justifiable solution. Basically, the Gal requests that the PIC read the DHT and, after the PIC reads the DHT, it transmits the data back to the GAL through the 5 volt serial port (not the little speaker jack serial port on the Gen1, but the 5v port on pins 0 and 1 - please don't get those confused).


      The first picture shows the kludged up prototype (prototype is my term for "this is as close to a real circuit board as I can manage"). Despite its looks, it performs like a charm and I have not seen a single error in thousands of reads.  Humidity accuracy, and how far away the sensor can be without noise problems, are other matters for other posts. My point is that this way worked for me and was much easier than I thought it would be.


      The second picture is the schematic (I need to learn how to make these) and it shows the simplicity of the circuit. The PIC chip connects to the DHT chip directly through GP0. There was some discussions that I saw about whether you had to use a resistor from +5 to data for the DHT and I chose to use a 4.7k and it works fine. GP1 and GP2 on the PIC chip connect to the GAL TX (pin 1) and GAL RX (pin 0), respectively to implement the serial communication. GP3 on the PIC is unused and I tied it low through a 10K resistor (again there was plenty of discussion on what to do with an used port pin and that's what I chose). The remainder of the circuit is just a few standard bypass capacitors. That's all there is.


      The third picture diagrams how the PIC is reading the DHT. It is worth a look if you want to understand the code. You will also need to get familiar with the DHT data sheet. I am not including the preamble in the diagram. Basically, serial data is sent by the DHT using a fixed start bit time (50us), then a data bit is sent and, this is where it is a little tricky, if the data bit is a '0' the time that the data line is high is ~ 27 us, if the data bit is a '1', the time that the data line is high is 70 us. In both cases, another start bit time starts right after the data bit time. So, the length of the transmission depends on the number of 0 and 1 bits. I looked around and saw that the way this was being handled in code was to measure the bit time and then decide whether it was short (~27us) or long (70us) to decide whether it was a '0' or a '1', respectively. I'm sure that way works fine, but I wanted to use the single timer on the PIC as a WDT, plus, the thinking about the coding was making my head hurt. So, instead, I read the bit at a fixed time (~43 us) after the start of a bit time. At this point, it will be low, if the bit was a 0 and we are actually into the start bit interval preceding the next bit time, or, it will be high and it is a '1' and we are still in the bit time. Both cases are easily handled in the code. It is unlikely that I am the only one who figured out how to do it this way because it appears to be simpler and more forgiving (although I have absolutely no evidence to support this). In any event, that is how I approached the job and it works.


      There are several loops in the PIC code that would be endless if the DHT malfunctions. To account for this possibility, the code enables a WDT that will time out if the DHT is unresponsive and will transmit 5 bytes of 'FF' to the Gal and then restart. You can see this section in the attached sketch, but I must admit that I am not happy with the way I am handling this case. I could not get the circuit to fail other than by pulling leads when it was operating on a breadboard. This did test the WDT and it worked, but you never know how many total bytes will be transmitted because, in addition to the 'FF' error sequence, there could be a partial number of valid DHT bytes. Oh well, maybe somebody else can tell me a better way.


      As for implementing a serial interface on the PIC, I was pleasantly surprised to see many examples of such code. I tested my implementation at 1200 and 2400 baud with absolutely no problems. Up at 9600, that was not the case, so I left it at 2400.


      The attached sketch is what I used to test the circuit and it is not particularly neat or efficient, but should not be too hard to understand. The Gal initiates a request by sending the PIC a 0x30, which the PIC is looping around waiting to receive. Make sure you understand how to enable the 5v serial port on the Gal gen 1. I included that code and my thanks to Sergey's blog for telling me how to do that. You can drop in a DHT-11 instead of a DHT-22 if you change the statement "DHT=22", to "DHT=11". Everything else works fine because the only difference I can see is that the DHT-11 sends zeros for the fractional values.


      Also attached is the PIC ASM code and a .hex file to use for the burn if you like.


      The DHT sensors are nice and I'm glad that I got them to work with the board. I have, however, moved on to an HIH-5030 for humidity with an LM35DZ as well as a thermistor for two accompanying temperature measurements. All three of these have voltage outputs and are working great with the Gal A-to-D ports. I can post those later if someone would like.


      Finally, and I have not come to this point yet, I intend to check how well these sensors are operating using the 'salts' calibration method. I will let you know how that goes.






      Message was edited: typos