@Gijs thank you very much for your response.

@robert-hh Oh! thank, I missed it. Great I am happy to try it, this evening! Thank a lot!

For lower attenuation it would better to go with 433 MHz, even better to 169 MHz that is also an ISM band. The big problem with compost, if I remember well how is processed, it is its high water content. There are several studies that can be found about "soil" and wireless sensors networks, search for WUSN (wirelss underground sensor network) and UG2AG (underground 2 aboveground). Usually are studies made for agriculture, forestry, soil, pipelines, ... sensors deployment.

@xykon Thanks Xykon. Yes, I connected a wire between 23 and GND before plugging it in and flashing. I think if there are thermal issues affecting all Fipys and its a known issue you should slap a sticky note or something on the site. I mean all the Fipys just went out recently. t.pirk and myself can't be the only ones noticing this. Should we not use the Fipys until a fix is available? I don't want to damage my units.

@kop524 said in temerature sensor for Wipy 2.0 w/ext. board: As near all pins can be redirected then choose is quite simple i only ommit for sensors pins used for SD card communication and sometimes inputonly look at https://docs.pycom.io/chapter/datasheets/ there are good descriptions about pins - you must choose self.

Regarding the light sensor (LTR-329ALS), my understanding was that it LTR329ALS01.light() gives the 2 numbers representing the lux values of 2 channels. If you left the default configuration registers (Gain 1x-> 1lux to 64k lux) then the lux values are exact the values returned. The 2 channels have a different sensitivity based on wavelength (ch0 ~450nm violet-blue and ch1 ~770nm red). I don't know what's raw2lux. Also the ratio d1/(d1+d0), is mentioned in datasheet but I did not understood the meaning. I've read the datasheet from: http://optoelectronics.liteon.com/upload/download/DS86-2014-0006/LTR-329ALS-01_DS_V1.pdf On my desk, evening, I have: '>>> lt = LTR329ALS01(py) '>>> print("Light: " + str(lt.light())) 'Light: (45, 33) 45 lux, 1.5m away (surface is sphere with 1.5m radius) -> 1272 lm, seems ok, as I have 3 bulb-lights of ~400lm. But with cellphone, 2 cm away: Light (6617, 2758) <Later edit> I've used this online tool to convert lux to lumens, as light-bulbs have specs in lumens http://www.rapidtables.com/calc/light/lux-to-lumen-calculator.htm Also with a Blue+Green LED, I've obtained values (85,7), which indicates a blue light, and lack of red light.

@catalin Thank you for the response. Can you please provide the link to the forum thread debating this?

@BetterAuto said in Onboard temperature sensor: I suppose that it is still not avaiable in ESP-IDF (or not ported yet to pycom). ESP have also hall sensor not avaiable yet and few other things..

I have been working on the mlx90614 for the last day and can communicate successfully with 6 on an I2C bus, but am am receiving an overwhelming number of errors. Right now it hovers around 25% of attempts to read the sensor. I believe it could be related to a timing issue of the I2C communication in micropython. Some errors are the result of a bad read of the I2C data, which can be verified if you read the PEC byte after the data. The third byte should come back with a crc-8 value, but sometimes it comes back as 0xFF, as if the mlx90614 is one byte ahead of the lopy. The other error is related to readfrom_mem function in i2c. This error produces an OSError exception about every one in four attempts. In other mlx90614 libraries the flow for reading bytes is slightly more complicated, for example // send the slave address then the command and set any // error status bits returned by the write Wire.beginTransmission(_addr); Wire.write(cmd); _rwError |= (1 << Wire.endTransmission(false)) >> 1; // experimentally determined delay to prevent read errors // (manufacturer's data sheet has left something out) delayMicroseconds(30); // resend slave address then get the 3 returned bytes Wire.requestFrom(_addr, (uint8_t)3); // data is returned as 2 bytes little endian val = Wire.read(); val |= Wire.read() << 8; // read the PEC (CRC-8 of all bytes) _pec = Wire.read(); return val; Is there anyway to imitate this flow control? Using the above style code on an Arduino I receive no errors and do not have to do coding gymnastics to control errors.

@crankshaft said in SI7021 I2C sensor: Try This; WOW! You're great, works like a charm... Thank you very very much!

@jmarcelino: Yes, Ive read that. But you would still have to compensate for the non-zero range (at least in your circuit). So at the moment and with limited requirements for precision, using the lower attenuation variants 0 and 6db and simply adding an offset would be sufficient as compensation. If you need precise values, yes, then an external ADC is anyhow recommended. B.T.W. Is there still the option to use the ADC in 10 bit mode, like by an option res = xx in the channel set-up?