Analysing Signals from SHT1X Software Module
Recently I wrote a software module to allow the Espruino development board send commands and receive data from the Sensirion SHT11 temperature and relative humidity sensor.
The SHT11 sensor uses a 2 wire bus similar to i2c but has a slight variance in the protocol which prevents using any standard i2c libraries or built in i2c hardware to communicate with it so I designed my software to manually reproduce clock and data signals that are compatible.
(the way the sensor tells us it has completed taking its reading and has data ready to send back to us also makes it unsuitable for using on a multi device bus so trying to coerce any built in i2c systems into playing nicely with the sensor wouldn't be a realistic solution)
The Setup is using the MikroC Click board mounted onto a Click board that's designed for Arduino headers but in this example, I'm using the empty click socket to plug jumpers from the Espruino board into. Excuse the rats nest of wires lower down, there's another project connected to the Espruino that isn't used in this write up but will be documented at a later date.
and closer:
The 2 black probes near the top of the picture below are connected to the scl &sda pins of the 2 wire bus.
Below, I used the Tektronix 1202B-EDU scope to capture the Espruino sending a command to the SHT11 sensor, I set the oscilloscope to trigger on the rising edge of the first clock pulse and scaled the acquisition timebase long enough to include the response from the sensor once it had completed it's task and then reading the data from the sensor back into the Espruino.
In the top section of the scope display above is the entirety of the data captured by the oscilloscope, with the information to the left side of that top section being the command to read temperature being sent from the Espruino. There's then a large pause around the middle while the sensor is accurately measuring the temperature. Towards the right side of that top bar is another section of tightly packed signals (similar in style to those on the left). This section is where the sensor signals that it has some data ready and the Espruino reads that data into itself.
The larger section of the display underneath is a zoomed in close up of a section of the captured data. The zoom display in the picture is showing the very beginning of the command transfer.
The yellow lines are the pulses sent from the clock line of the bus so they are pretty much in a uniform pattern during the communication sequences.
The blue lines are the signals captured from the data line of the bus and changes state if necessary between the clock pulses (except for the very beginning where the clock/data signals are sent out of their normal phase as a start sequence to tell the sensor to get ready to receive a new command).
Above is a page from the SHT11 datasheet showing an example of communicating with the sensor. Since my software module already manages to get the sensor to perform it's temperature and humidity readings and then transfers the data back to itself, I'm confident that the signals captured by the TBS1202B oscilloscope resemble those provided as an example in the datasheet.
The signals in the datasheet look to be a little more uniform and cleaner than the ones I'm capturing which tells me that even though my module is working, there is still room for improvement and could probably benefit from tightening up a little bit, there is also a few minor glitches along the captured data that could do with investigating too.
In the picture above, notice the glitch on the lower blue signal close to the right side. This is the data signal and should be quite clean transitions going between gnd(0v) to represent a binary 0 and +3.3v to represent a binary 1.
The signal dips from 3.3v down to around 2.9v; This happens right on the falling edge of a clock signal and stays like that until near the end of the next clock pulse where it dips very briefly to 0v then rises back to 3.3v.
Because the zoom display is showing the very end of the command sequence, it's easy enough to work out whats going on here:
1. The Espruino communicates the last bit of it's command to the sensor and the releases the data line to float freely. The data line is externally tied to the circuits +ve (in this case 3.3v) power supply using resistors to pull them high.
2. Once the Espruino releases the data line, the pull up resistor takes over trying to keep the data signal at 3.3v but since the resistor itself causes the voltage to drop a small amount aswell as some draining through the floating connections, the data signal suffers and can't maintain a 3.3v high but manages to keep at 2.9v which is still in range.
3. The reason the Espruino released the data line is to hand control of that bus line to the sensor.
4. In order for the sensor to signal it has recieved the command to start measuring the sensor, it takes control of the data line pulls the signal down to 0v(gnd) in acknowledgement while the clock signal is mid pulse.
5. The sensor then pulls the data signal back up to 3.3v. Once the SHT11 has finished measuring the temperature, it will pull that data signal back down to 0v(gnd) to let the Espruino know that it's finished and has that information ready to transfer.
6. This is the reason there is a large pause between the 2 sets of signals on the left and right hand sides of the upper section of the display.
The picture above shows the yellow clock signal being kept at 0v(gnd) for longer than the rest of the pattern 2 thirds along the display; once again, because of where about's in the signal transfer that we are looking at, we can work out what's going on..
1. The SHT11 sends back 16bits of data to the Espruino, but in 2 lots of 8bits.
2. That extended low cycle on the clock line is at the point where the sensor has transmitted the first 8bits and the 2 devices are sending acknowledge signals to each other before transferring the next 8bits.
3. These differences in the signals will always be there but with some more work on the software module, and possibly even some hardware changes should tighten it up and pull the signals closer together and look a bit cleaner.
An overview of this project showing all of the different aspects in 1 picture.
Final thought:
Even though the software module I made works and enables the Espruino to communicate with an SHT11 sensor, Using the TBS1202B-EDU from Tektronix has enabled me to see areas where I could pay more attention in improving both my software module as well as investigating the hardware. The improvements once factored in to this design will make for a much more reliable and stable device, The communication between the 2 devices is reliable enough in my testing environment but when it gets packaged into a standalone device, it's very probable that it will come into contact with interference, noise and general disturbance from other sources, those small glitches in the software could add to those other influences and be the thing that stops the device from functioning correctly so I'm using the TBS1202B-EDU as a tool to help take a "proof of concept" design and turn it into a robust device capable of being used in a wide range of environments and make it more able to cope with other sources of interference that might be present.
Lucie
A sneaky first look at the Gizmo2 that I'm turning into a retro games console to enable me to produce a road test review on it's suitability.
Bonus picture!! My little corner of CyberPunk heaven... and yep! my desk is actually quite tidy for a change hah!!
