Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor I
1,911 Views

What is wrong with I2C on edison with HTU21D-F or MPL3115A2 or or BMP280

Hi everybody,

I am trying to build an teaching IoT-micro-weatherstation and I am facing problems with I2C sensors or more probably Edison I2C behavior. I had faced some hardware problems few weeks ago so I have bought a new Edison mini-breakout and a set of new sensors:

HTU21D-F

BME280

MCP9808

SI1145

MPL3115A2

BMP280

(I have also some other ones that are not involved in this question...)

First of all I am pretty sure that some months ago I have been abl to easily handle an HTU21D-F sensor with mraa and upm, then came the change in mraa that added a check on the communication between the Edison and the device that we overcome. But now the problem is worse the HTU21D-F is not detected any more !

I am using a level shifter to be shure to provide 1.8v signal on SDA and SCL pins of my minibreakout.

I am as sure as possible that my wiring is correct because I am using a breadboard with

SI1145 / MCP9808 / BME280 that are detected (I have not tried yet to get measurements)

on I2C bus 6 or BUS 1 I have activated bus 6 with these instructions:

echo 28 > /sys/class/gpio/export

echo 27 > /sys/class/gpio/export

echo mode1 > /sys/kernel/debug/gpio_debug/gpio28/current_pinmux

echo mode1 > /sys/kernel/debug/gpio_debug/gpio27/current_pinmux

i2cdetect -y -r 6

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: 60 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- 77

If I try to wire any of The three others one by one or in any combination I getno detection

i2cdetect -y -r 1

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

Same result on bus 6 or 1 !!

I have tested the sensors on an arduino, they perform very well, I have tested HTU21D-F on an arduino breakout it does not work with the adafruit IDE test program and sends the message no sensor detected. With the demo program the sensor is detected but the values read are wrong (probably empty buffer).

I have read a little bit the forum and have seen that there are many questions dealing with I2C buses, I can proove that "in many cases" everything works as expected but in some cases the communication situation seems locked between the sensor and the edison. It is just like if the Edison was not able to "bring the sensor to communicate with him" To confirm this hypothesis I removed the

MPL3115A2 and left it away, after some minutes when I plugged it back It was detected without changing anything :

i2cdetect -y -r 1

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: 60 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

Just if the sensor came back spontaneously to a good state... I tried to plug the BMP280 and....It was detected!!!!!!!

i2cdetect -y -r 1

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: 60 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- 77

I am getting mad on this question, do you have any suggestion, as this is for teaching K9-12 teachers I cannot resonably tell them : "unplug, wait for 4'47", then plug again it will work...."

Any help will be greatly appreciated, if needed I can do some tests and in teh meantime I will write the code to reas and compare measurements between sensors...

Thanks in advance and many thanks to all contributors and intel facilitators in this nice community.

G.

0 Kudos
18 Replies
Highlighted
Community Manager
41 Views

Hi Gerard,

 

 

Have you checked if these three sensors have this behavior on bus 6? Or viceversa, does the three working sensors work as well when connecting them to bus 1?

 

Also, how are you powering your Edison breakout board? Are powering through the micro USB port or with an external power supply?

 

Make sure that the sensors work with 1.8V and not with 3.3V, not so long ago there was a similar case with I2C and the sensor worked by applying 3.3V.

 

 

Regards,

 

-Pablo
0 Kudos
Highlighted
New Contributor I
41 Views

Hello Pablo,

yes I have exchanged connections to switch bus1 and bus6 with no effect.

This morning I plugged the power with everyting wired, and all the sensors were detected properly without the need to unplug / plug them. Except of course HTU21D-F and if I plug HTU21D I loose the detection of he others (unplugging HTU21D-F brings back to the correct situation)

I am powering on the J21 connector of the minibreakout using 9V external power supply, sensors are powered with the J20-1 pin and the level switcher power is plugged on J19-2 pin

I have measured 4.3 V delivered by the edison to the sensors through J20-1 and 1.81 through J19-2. Do you think that 4.3V is not enough and I should deliver 5V ? Is it possible to do that with the minibreakout ? How?

I may test with arduino breakout or arduino power supply to get 5V if you think it may help...

To be sure to avoid voltage problems I am using the bi-directionnal level shifter BSS138 from adafruit that is said to work on I2C according to their site: https://www.adafruit.com/products/757 https://www.adafruit.com/products/757

And for the rest of the captors everything is OK at least for detection (I have not yet finished the code to read data...)

Thanks again, I stay tuned.

0 Kudos
Highlighted
Community Manager
41 Views

Hi Gerard,

 

 

I'm not sure if this is the case but it sounds like this sensor, HTU21D-F, is dragging all the current causing the other sensors not to work as they should or being recognized only "sometimes". Would it be an option for you to test this same configuration but powering the sensors externally? Or at least the most problematic ones. I know you're already using the BSS138 as level shifter but it wouldn't be a bad idea to test with external power.

 

I would also appreciate if you try with 5V from your Arduino or your Edison expansion board. I would like to know what you get.

 

 

Regards,

 

-Pablo
0 Kudos
Highlighted
New Contributor I
41 Views

Thanks Pablo for the followup

I have used 5V and 3.3 V from an arduino Uno for the following tests.

Before any test I have checked that the HTU21D was OK with the Arduino. It measured properly T° and Humid with both Demo and test programs from the IDE.

I did not touch the low voltage side of the switcher of bus 6 and I have left the bus1 in its wiring configuration (MCP9808-BME280-SI1145)

Starting point

Bus6 powered by Edison MPL3115A2 -BMP280 detected

  • Bus6 - external power 3.3V MPL3115A2 -BMP280 detected (No HTU21D connected)
  • Bus6 - external power 3.3V HTU21D connected no sensor detected any more
  • After disconnecting HTU21D I had tu unplug replug BMP280 to detect both
  • Bus6 - external power 5V MPL3115A2 -BMP280 detected (No HTU21D connected)
  • Bus6 - external power 5V HTU21D connected no sensor detected any more
  • If I unplug BMP280 MPL3115 is detected (but not HTU21D)
  • If I replug no sensor detected
  • If I unplug MPL3115 no sensor is detected
  • If I leave only HTU21D on the bus it is not detected

It does not seem that the power is responsible. Would-it be the level shifter that breaks something ? Is it harmfull for the Edison to plug SCL and SDA from HTU21D without level shifter if powering the HTU21D with the Edison VSys or 3.3V supply.

Thanks again, tell me if I can try to remove the level shifter without burning my Edison.

Regards

0 Kudos
Highlighted
New Contributor I
41 Views

Hi

I have tried to connect the HTU21DF with an arduino breakout.....

Same result with 3.3 and 5V , not detected. I am pretty sure that some months ago I have seen 40 written on the I2C map from i2cdetect....I cannot undersatnd what happenned.

Regards

0 Kudos
Highlighted
Community Manager
41 Views

Hi Gerard,

 

 

I think it would a better idea not to remove the level shifter for now.

 

Have you tried with previous images before? You mention that some months ago you remembered seeing a "40" when running i2cdetect, do you remember which image you were using at that time. I guess it had to be the 3.0 or one prior to that one.

 

If possible, I would like you to test with those images just to see if you get different results:

 

http://iotdk.intel.com/src/3.0/edison/iot-devkit-yp-poky-edison-20160315.zip – This is the link for image 3.0

 

https://downloadmirror.intel.com/24910/eng/edison-image-ww18-15.zip - This is the link for image 2.1

 

 

Regards,

 

-Pablo
0 Kudos
Highlighted
New Contributor I
41 Views

Hi,

I'll do that as soon as possible but I am on vacation far away from my edisons ;-(.

I'll provide the answers as soon as I can .

Thanks again.

0 Kudos
Highlighted
Community Manager
41 Views

Hi Gerard,

 

 

We will be waiting for your results. Enjoy your vacations!

 

 

Regards,

 

-Pablo
0 Kudos
Highlighted
New Contributor I
41 Views

Hi Pablo,

Back to work :-) I have downloaded and installed older images on my Edison MiniBreakout but I have not been able to display detection of HTU21D-F with i2cdetect (I have checked with 3 sensors to be sure that the problem is not coming from the sensor). I can't remember how I managed to see a "40" on the output months ago, sorry for that. I remember that among many manipulations I performed some tests of couples of sensors on the i2c and at a time I also tried (unsuccessfuly) a trick to solve the "repeated start" problem for another sensor...Here are the outputs from my attempts.

image n-1

testhtu:/home/useradm# uname -a

Linux testhtu 3.10.17-poky-edison+ # 2 SMP PREEMPT Mon Mar 14 15:26:16 PDT 2016 i686 GNU/Linux

testhtu:/home/useradm# opkg list mraa

mraa - 0.9.5-r0

testhtu:/home/useradm# opkg list upm

upm - 0.5.1-r0

testhtu:/home/useradm# i2cdetect -y -r 1

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- /thread/102979 https://communities.intel.com/thread/102979

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

image n-2

root@test2htu:~# uname -a

Linux test2htu 3.10.17-poky-edison+ # 1 SMP PREEMPT Wed Apr 29 03:54:01 CEST 2015 i686 GNU/Linux

root@test2htu:~# opkg list mraa

root@test2htu:~# opkg list upm

upm - 0.1.9-r0

root@test2htu:~# i2cdetect -y -r 1

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

Even if HTU21D-F is not displayed it works properly with older versions of mraa.

image n-1

testhtu:/home/useradm# python

Python 2.7.3 (default, Mar 8 2016, 11:28:40)

[GCC 4.9.1] on linux2

Type "help", "copyright", "credits" or "license" for more information.

>>> import mraa

>>> import pyupm_htu21d

>>> bus = 1

>>> tempAddress = 0x40

>>> htu21df = pyupm_htu21d.HTU21D(bus, tempAddress)

>>> htu21df.resetSensor ()

>>> htu21df.testSensor ()

Executing Sensor Test

Device appears functional

Test complete

0

>>> hygro = htu21df.getHumidity ()

>>> htu21df.sampleData()

0

>>> RH = htu21df.getCompRH()

>>> temp = htu21df.getTemperature()

>>> hygro = htu21df.getHumidity ()

>>> print '%.3f\t\t\t'%temp + '%.3f\t\t\t'%hygro + '%.3f'%RH

23.849 42.828 43.000

# After blowing on the sensor

>>> htu21df.sampleData()

0

>>> RH = htu21df.getCompRH()

>>> temp = htu21df.getTemperature()

>>> hygro = htu21df.getHumidity ()

>>> print '%.3f\t\t\t'%temp + '%.3f\t\t\t'%hygro + '%.3f'%RH

25.909 56.500 56.364

>>>

image n-2

root@test2htu:~# python

Python 2.7.3 (default, Mar 31 2015, 14:39:49)

[GCC 4.8.2] on linux2

Type "help", "copyright", "credits" or "license" for more information.

>>> import mraa

>>> import pyupm_htu21d

>>> bus = 1

>>> tempAddress = 0x40

>>> htu21df = pyupm_htu21d.HTU21D(bus, tempAddress)

>>> htu21df.resetSensor ()

0

>>> htu21df.testSensor ()

Executing Sensor Test

Device appears functional

Test complete

0

>>> hygro = htu21df.getHumidity ()

>>> htu21df.sampleData()

0

>>> RH = htu21df.getCompRH()

>>> temp = htu21df.getTemperature()

>>> hygro = htu21df.getHumidity ()

>>> print '%.3f\t\t\t'%temp + '%.3f\t\t\t'%hygro + '%.3f'%RH

24.536 41.363 41.432

This situation brings me back to one of my earlier posts on that /thread/102979 topic : .

From what I have been able to trace out months ago and which is confirmed by these new observations :

* HTU21D-F is "partly" recognized and not shown by the i2cdetect -y -r 1 command.

* If mraa version used is prior to arflol contribution and https://github.com/intel-iot-devkit/mraa/commit/1e4516d0266679a67ad8487d6d17448b76d8c211 commit HTU21D-F can be controlled by upm functions and yields good measurements.

* Unfortunately in the latest upm versions, HTU21D functions cannot overcome the initial errror message pushed by error detection condition added to mraa.

I am not able to check if the origin is in low level mraa initialization primitives used in pyupm_htu21d code or if it is because HTU21D upm function is less elaborated than arduino IDE examples but the situation remains peculiar, the sensor works with arduino IDE interface but not with a mraa/upm program.

Let me know if I can do anything else to help on this problem, I have bought other sensors for my teaching weatherstation but still interested in this one...

Best regards

intel_corp , I have read interesting announcement from INTEL last week.... if you can push any lost joule towards me that would dramatically boost my IoT energy ;-)

0 Kudos
Highlighted
New Contributor I
41 Views

Hi Pablo,

Finally I found a trick to displayHTU21D !!

It does not work every time but sometimes the sensor shows up

I have used an arduino breakout with the last image.

I have plugged the board with 2 USB and connected to it at the same time with the Arduino IDE and by ssh, the sensor is plugged in 5V without the bridge

I have started the SparkFun_HTU21D_Demo on the IDE

then checked the bus on the i2c many times and here is the result :

root@emmett:~# i2cdetect -y -r 6

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

root@emmett:~# i2cdetect -y -r 6

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: 40 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

root@emmett:~# i2cdetect -y -r 6

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

As you can see the sensor appears from time to time..... (maybe HTU21D-F is a secret pokemon?) !

To be complete on the topic I must say that the measurements made are wrong

HTU21D Example!

Time:662 Temperature:998.0C Humidity:998.0%

Time:2093 Temperature:998.0C Humidity:998.0%

and that the other test program available on the IDE : HTU21DFtest does not find the sensor either

HTU21D-F test

Couldn't find sensor!

I hope this helps a little bit.

Best regards

0 Kudos
Highlighted
Community Manager
41 Views

Hi Gerard,

 

 

Thank you for running the tests for our suggestions, I'm sorry to hear that didn't solve the issue.

 

Regarding your latest tests, to be honest, I don't know what is causing this behavior. I have never seen anything similar before. Do you remember if this is what you did last time to get it recognized? Running the SparkFun_HTU21D_Demo on the Arduino IDE I mean. Or was it something different?

 

We would like to investigate this case a little bit more. So we appreciate your patience in the meantime.

 

 

Regards,

 

-Pablo
0 Kudos
Highlighted
41 Views

So the sensor may not appear because the i2c bus is not muxed in correctly? i'd recommend using i2cdetect after muxing the i2c from within mraa and setting owner to false so that the bus stays muxed.

Also you have a PR open than is unsigned, if you sign it, we can get it merged

https://github.com/intel-iot-devkit/upm/pull/433 Modif to prevent crash on the first readReg() for HTU21D by g-vidal · Pull Request # 433 · intel-iot-devkit/upm · GitHub

0 Kudos
Highlighted
41 Views

One of the issues here is that the HTU21d is not an 8bit register accessible device. There are a small number of active registers and many of those are 16 bit accesses (issue a temperature read (reg E3) and get back 16 bits). Some commands will stall the clock until data are ready and others don't. I'm sure this confuses the i2c tool when it tries to scan the bus.

Also, ensure you have two pull up resistors to 3.3v (one for SCL and other for SDA of 3K-10K ohms).

0 Kudos
Highlighted
New Contributor I
41 Views

Hi pablo arfoll and WilliP here are some good news.....

I am very sorry I do not understand arfoll's questions, I have done my best with http://iotdk.intel.com/docs/master/mraa/classmraa_1_1_i2c.html http://iotdk.intel.com/docs/master/mraa/classmraa_1_1_i2c.html which yield some information, if you can please give me further instructions for dummies I may keep on.

For the first time I can reproduce a behavior that leads to the detection of HTU21D ! I have opened two remote shells on my Edison, sudo on both and connect an HTU21D with a level shifter. I started python on one of the terminals and did :

import mraa

bus = 1

i2cBus = mraa.I2c(bus)

I2C_FAST = 1

mraa.printError(i2cBus.frequency(I2C_FAST))

MRAA: SUCCESS

htu21DAddress = 0x40

mraa.printError(i2cBus.address(htu21DAddress))

MRAA: SUCCESS

mraa.printError(i2cBus.writeByte(0xE3))

MRAA: SUCCESS

on the other terminal I got :

i2cdetect -y -r 1

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: 40 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

If I check again the bus the sensor disappears which could be explained by WilliP statement

2cdetect -y -r 1

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

If I write again on the bus, the sensor appears again (all times)

mraa.printError(i2cBus.writeByte(0xE3))

MRAA: SUCCESS

i2cdetect -y -r 1

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: 40 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

I have then checked WilliP advice, I have been able to read the temperature register and the value read changes which seems good but these actions did not make the sensor visible :

temp = i2cBus.readWordReg(0xE3)

print '\t%.3f'%temp

32880.000

temp = i2cBus.readWordReg(0xE3)

print '\t%.3f'%temp

34928.000

temp = i2cBus.readWordReg(0xE3)

print '\t%.3f'%temp

33904.000

no effect:

i2cdetect -y -r 1

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

Even if that does not explain why the sensor is not detected from scratch this demonstrates how to use it. My feeling is that the HTU21D program in UPM lib has bugs which brings an answer to arfoll question on my pull request. This contribution is not good enough it cures the problem only in one given situation but it is not generic. Please reject it. I will try to step into HTU21D programs by comparing Arduino IDE and UPM trying to find a generic solution.

I am working without pullup resistors I thought there was one on the Edison bus. I can further investigate if you want if I may understand the questions.

Thanks again for your time, with my apologies

Best regards

0 Kudos
Highlighted
Community Manager
41 Views

Hi Gerard,

 

 

Great to hear that you got it working! Or at least you found a way to get it recognized on your Edison. I will keep this workaround close for any future question about this sensor. Also and if you agree, we would like to pass your feedback to the right department, so if you have any other update on this it would be very helpful.

 

 

Regards,

 

-Pablo
0 Kudos
Highlighted
New Contributor I
41 Views

Hi WilliP, hi all

I have tried to add 4.7 K and 10 K pull up resistor on SDA and SCL. This does not change anything on the detection, the behavior remains exactly the same than in my previous post. I am using a level shifter HV = 3.3, LV = 1.8; Edison mini-breakout and Adafruit HTU21D-F.

Please WilliP can you confirm that if you use a pullup resistor you can detect the sensor all the time without the need to write anything on the bus with the command i2cdetect.

I will now compile and test the proposed HTU21D program https://github.com/intel-iot-devkit/upm/commit/77fbf49f939e316d05942bd7752db29dd152ce60 https://github.com/intel-iot-devkit/upm/commit/77fbf49f939e316d05942bd7752db29dd152ce60 and let you know.

Best regards

0 Kudos
Highlighted
New Contributor I
41 Views

Hi pablo arfoll and WilliP Some more news,

I have cloned grom github latest versions of mraa upm which is for mraa

'v1.3.0-7-g8ec4fcb'

with this version the trick reported on my previous message does not work anymore... I am no more able to make appear the desired 0x40 . This bad news is highly compensated by the good news from the commit on upm # 77fbf49f939e316d05942bd7752db29dd152ce60 from https://github.com/whpenner https://github.com/whpenner .

With the new HTU21D program everything works perfectly, My old python programs works again without any bug or problem. It is even better than before because now HTU21D works with another sensor on the same IéC bus.

To summarize :

  • With the latest upm version HTU21D-F works as expected (transformation of initialization as I suggested plus a great work by whpenner to read 16bit values)
  • With the latest version of mraa even if HTU21D-F works perfectly on 0x40 address it is not detected.
  • It seems that adding a pullup does not change anything (works perfectly now without, does not enable detection)

As "it works now" I will not do any more investigations, it is not convenient to be unable to detect the sensor on the bus but hopefully one knows what he/she plugs on the board .

Many thanks for the time spent, if you need any more tests let me know I will make them.

Best regards

Gérard

0 Kudos
Highlighted
Community Manager
41 Views

Hi Gerard,

 

 

Really good update!

 

Thanks for summarizing your results. We will share your posts with the development team to see if it's possible, in the future, to fix the bug with the HTU21D-F sensor not being recognized.

 

 

Regards,

 

-Pablo
0 Kudos