3
\$\begingroup\$

I am currently trying to test the SHT3x series humidity sensors by Senserion. I have their EK-H4 evaluation kit to get data from the sensors. I can plug in the sesnsors provided with the kit, and all 4 channels work fine.

I have made my own PCB which has 4x SHT31 and 4x SHT35 sensors (DATASHEET). The plan is for this to go into a humidity chamber and a ribbon cable then connects to a different PCB, which has connectors to allow the EK-H4 to plug in and communicate with the sensors. The schematic is as simple as can be (this is my own designed evaluation board, and as it is for work, company details etc have been hidden):

enter image description here

Each IC has a separate SDA and SCL line, as that is the way the EV kit works. All the provided sensors have the same device address and 4 can be read at the same time, so all run on separate busses. I just followed that. Each IC has a 100nF decoupling cap and 4k7 pullup resistors on the I2C lines. The PCBs look like this (the wires are to enable me to scope the comm lines):

enter image description here

After putting everything together, I am finding that I am only receiving a humidity reading from sensors 6, 7 and 8. 1-5 are not showing me anything. I replaced one of the sensors and still nothing. I double checked the soldering, and it all looks good, I checked it under our Mantis and EvoCam. Soldering seemed fine.

The EK-H4 came with its own leads to plug into the sensors. I swapped the leads round, to see if it could possibly be them, but all combinations yielded the same result, 1-5 not working and 6-8 giving me data. I made a new ribbon cable and still the same result.

The next stage was to check continuity. So using my multimeter, I was able to establish that everything was connected as it should be.

I scoped the SDA and SCL lines of one of the devices that was working and saw this:

enter image description here

This is exactly as you would expect. It is pretty similar for all working ones, with the exception of slightly different data at the end due to small changes in readings. I then scoped the ones that werent working and all showed me somethign I thought to be a bit odd:

enter image description here

My understanding of I2C is not great, I am more of a hardware kinda guy, but I thought there was supposed to be a START bit received from the SDA line before the clock would start? On all the non working sensors, there is no start or finish bits, yet the clock is going.

If it helps, here are the 2 scope readings side by side:

enter image description here

Strangely, there does seem to be a bit of a 'wobble' on the SDA line, but surely not enough to trigger the clock?

As I said, my understanding of I2C is not great, so I may be missing something very obvious but I have been trying to solve this for about 2 hours now and I've just got stuck and not sure what to try next. I may be missing something very obvious! I need some guidance to help solve this issue. Does anyone know what the problem could be?

Some additional info;

  • The ribbon cable is approx 1m in length, it needs to be that long to accomplish the task it needs to do once it is working.
  • The scope I am using is the Rigol DS1102D
  • The EK-H4 is the master

If any additional info is needed, or something is not clear, please let me know in a comment and I will do my best to address it.

Edit with response to comments

I have done continuity checks on all the IDC connector pins and these are all ok (I had done this earlier but it wasn't very clear). I did find a short on the 4k7 pullup on the SDA on sensor 5. This has now been rectified and that sensor is now working. This means that all the SHT35 sensors are giving me data. The SHT31 sensors are not working.

I am now getting some sort of data transfer on them, but something is definitely not right:

enter image description here

Compare this image side-by side with a working one:

enter image description here

As you can see, the data isn't what is expected, and it is only getting to about 1.25V instead of 3V. I have checked again for shorts and cannot find any. Looking through the datasheet, there should be no difference between the SHT31 and the SHT35 except for the tolerances, unless I have missed something or misread something?

It looks as if the SDA is attempting to start communications, but isn't actually transferring any data

\$\endgroup\$
  • 3
    \$\begingroup\$ No, all timing is generated by the I2C master device, and it should be driving both SCL and SDA for the first 8 bits on every transaction. Since SDA is not moving at all, you have an open circuit somewhere in the path. You need to do some basic continuity checks. For example, are you sure all of the wires in your ribbon cable are making proper contact to the IDC connector? \$\endgroup\$ – Dave Tweed May 31 at 12:15
  • \$\begingroup\$ @DaveTweed I am absolutely sure. The master is the EK-H4 device, and as it is generating the start bit on the 'working' sensors, that bit works. I have also scoped the pin of the sensor too, and have the same readings, as in no activity on the SDA line, yet there is 100% continuity between the connector pin and the sensor pin. I have done continuity checks on every pin of the IDC connector too and they are all fine. Probably should have expanded exactly which continuity checks I did! \$\endgroup\$ – MCG May 31 at 12:19
  • 1
    \$\begingroup\$ Perhaps SDA is shorted to V+ somewhere? Or an incorrect pull-up? I agree the master drives SDA during the start of the transaction. \$\endgroup\$ – Kevin Kruse May 31 at 12:35
  • 2
    \$\begingroup\$ @KevinKruse I think we are getting somewhere now, I did find a short one one of the pullups, I'll update the question \$\endgroup\$ – MCG May 31 at 13:05
  • 1
    \$\begingroup\$ @Justme SDA and SCL are both pulled up to the supply, right? And they are both resting at 1.25V. Either they're not really pulled up to the supply, or the supply is not at 3V. Sure, all the devices are pulled up to the same supply on the schematic, but the oscope says differently. \$\endgroup\$ – Annie Jun 1 at 0:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.