-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
After calling sensor.sleep(), can't read value #8
Comments
Do you have more infos? Your code, details to the used sensors (like FW versions and such), which library version you use? ... Normally after using sleep you must send a "reset" to wake the sensors up again |
I'll try using The sensors are all running FW 2.3, and are addressed 0x21, 0x22, and 0x23. My code looks like this:
|
I've just tried again, by resetting and sleeping the bottom sensor in every
@Miceuz This is starting to seem like it is more of a hardware issue than one with the library - have you come across anything like this in your testing/development? |
@simonrobb can you paste your code for this particular case? 4294967295 is all '1' for 32 bit value. This means, sensor is not responding at all. Do you get the same result if you just have one sensor on the bus? Does everything work fine without using sleep()? In general, I2C address match will wakeup the sensor from sleep, so no reset should be necessary, but maybe wakeup takes some time and that throws I2C master off track. BTW, how long is your wiring? You have pullups? Can you have a look at waveform on scope? Another thing to try - slow down the I2C bus speed. I'm really busy these days till mid April, so it would be really helpful if you could check all those things for me. |
Thanks for the reply @Miceuz. I've looked into a few of these things today. The sensors work fine when not using the sleep function. My SCL/SDA lines are going into pins D3/D4 of the Wemos D1 mini, which have pullups built in. I've tested using one, two and three sensors. The number doesn't appear to make any difference. However, when I switch out the top and bottom sensors for new ones, there haven't been any problems. So it could be at the hardware level. I observed no problems while mocking up the unit on a breadboard - using jumper wires only. So that's a good question regarding the wire length - the distance to the further sensor is around 2 metres. I understand that might be an issue. I've tried slowing the bus speed using I may try using a CAT5 cable instead of the basic wire I'm currently using. One last thing - after the problem occurs and I soft reboot the Wemos, I get the following when I tune into the Wemos' boot baud rate:
The code I've used for testing today:
|
Hi @simonrobb, thanks for the report. Might be the wiring. Using cat5 or just twisting the wire might improve things significantly. Do you have a scope to look at the waveform? Maybe attiny441 in sleep mode has some different requirements for the incoming signals than in active mode and it just does not recognize the address. Or goes into some forever loop... Another thing, the fact that Wemos goes the way of the dodo is really strange. Maybe Wemos I2C library does not handle problems on the bus properly. Sensor does not answer for once because of the long wire, this throws Wemos I2C driver off track. Can you try this on Arduino Uno? |
i think i did have the same problem and i think i solved it: if you send the sensor to sleep you have to "wake" it before getting any reading... example code:
|
It should wake up in much shorter time. 17 microseconds should be enough according to the datasheet. This might be related to the fact that the MCU is being operated outside of it's specification - 16MHz at 3.3V is too fast, but I did not notice any problems before, as usually functions related to writing flash and eeprom memory fail first. |
ok 1000 ms delay was a bit high, i reduced it to 20 ms and it also works... |
@krikk can you try reducing it to 1ms? |
works also with 1ms :) |
..but i noticed something strange: ...after this the whole i2c bus is "crashed" and does only recovery with powercycling the whole setup |
@krikk thanks for your contribution. What platform are you using to do the scan? What voltage is used to power the sensor? |
@krikk thanks for the tip; I did have a call to The issue you're seeing now sounds very similar to what I have, in that the sensor is non-responsive, then the entire I2C bus goes down, and requires a hard reset to get it working again. |
@Miceuz sorry I've been unable to try on an Uno yet - I do have one at my workshop, but haven't been there in the last week. As to the scope, I can probably get one but I've never used one before. Is there anything in particular that I should look for? |
@simonrobb the fact that entire I2C bus is non responsive is really suspicious. This means that either esp8266 I2C library is not robus enough or that the sensor hogs down the bus by dragging it down. Can you check with scope or multimeter the voltages on SCL and SDA lines - are they pulled low or high? The best would be if you could get the bus to hang, then stop all the activity on it and then measure the voltages. |
i did my tests on a wemos d1 R2, a esp8266 board, the code: https://github.com/letscontrolit/ESPEasy/blob/mega/src/_P047_i2c-soil-moisture-sensor.ino#L116 powersupply, 3.3v directly attached to board, board is powered with usb ...i will try to measure the voltage, but i only have a cheap multimeter no oscilloscope |
I am working on a similar setup (d1 mini connected to 3 or more sensors w/6ft cables), and having the same issues. I figured I have overestimated what I could do with cable length and number of sensors, but it is hard to give up on it, considering it has worked for up to 40mins without crashing. After seeing this thread, I added Wire.setClock(40000), which seems to help. Also, playing with other tricks mentioned in this thread didn't hurt. I have very little (no) experience or diagnostic tools, so I am eagerly following this. |
so did check the voltage of SCL and SDA lines when the error occures: test with sleep mod ENABLED: |
So, I finally got around to test this. The bug you were experiencing was caused by a combination of clock stretching from the sensor side and default settings in the ESP8266 I2C library. When Attiny441 receives I2C address that it recognises, it drags the SCL line low and then goes into the wakeup sequence, stretching the clock line until it is ready to service request. It appears to be taking about 2ms to do that. Default ESP8266 I2C library waits for 230us before sending garbage into the bus. This throws Attiny441 off as it releases clock line and keeps SDA line down waiting for ACK clock pulse. A timeout definitely would help in the sensor side, but the problem can be easily mitigated on the master side, it enough to specify clock stretching timeout long enough: My test sketch that illustrates the problem and the remedy:
|
@Miceuz Thanks so much for this. I've incorporated it into my code and I'll keep a close eye on the issue. Since it's intermittent, it's going to be difficult for me to say it's fixed 100% - but if we don't see the bug come up in the next few weeks of my testing let's call it fixed. It certainly makes sense (with my limited understanding of I2C). Thanks again for the help. |
Should I incorporate something of this into my library or in the README ?! What you think? |
@simonrobb I think this is really fixing the issue. |
Then I would add it more to the README because I explicitely decided to have the Wire-initializsation outside of the class exactly to allow the users to handle such specific stuff in their code without need to change the library ... |
I recently ordered the rugged version of Miceuz's sensor, which comes with a 1m cable. I was able to communicate with the sensor using my Wemos D1 mini esp8266, but some values where very odd. For example the temperature read fine but only if it was above 255, else I would get 255 or 127. Miceuz pointed me in the right direction when he asked me to tinker with the suggestions in this thread. I was able to solve the issue by slowing down the bus speed with Wire.setClock(x), in my case I chose 50000. |
@derSeddy good pick up. I didn't test setting the clock speed in isolation, so I'd guess the reason the fix worked was because of the line Further to that, clock stretching was most definitely the issue, and I've since moved away from the ESP8266 in favour of micropython running on an ESP32. I had the same problems which were immediately fixed by lowering the clock speed. |
I experienced the same problem on an ESP8266. I tried with |
I'm using the library on an ESP8266 (Wemos D1 mini) connected to three sensors, each addressed individually.
After calling
sensor.sleep()
on one of the sensors, it returns 4294967295 for subsequent capacitance readings. The other two sensors continue to operate normally for the next reading, however on further readings all sensors give that same value of 4294967295 (and -0.1 for temperature).At this point the board can't be reset using the onboard reset button. I can power cycle the board and it will start up again, but now the sensor which was put to sleep doesn't respond to I2C messages, and all three sensors return the bad value for capacitance.
What am I missing here? Is there a method to wake the sensor after sleeping?
The text was updated successfully, but these errors were encountered: