Problem: DS18B20 no longer working, interfering with serial?

[A.Harrenberg]

Hi PoltoS,

it is getting more and more weird...

I took my logic-analyzer to make some measurements and I noticed that the timing is significantly changing after a reset when the USB-serial is detected. To have some "reference" I used the pins 21 and 22 to generate a pulse signal with delay(5) for pin 22 and delayMicroseconds(5000) with pin 21. On pin 22 where the delayMicroseconds() is used, the change in timing can also be seen.

When USB is not recognized the pin 22 show a signal with ~4200 to 5200 ms which seems to be ok given the tolerances/resolution with the simple timer. The pin 21 show a signal with approx. 2800 us which is NOT ok, it should be 5000 us!

During that time, the "reset condition" on the onwire is approx. 700us, the sensor set the "presence" condition after approx. 30 us (for about 110 us). In the onwire library, the delay value for the reset condition was changed from 480us to 1500us to solve the power-on problem, so the reset condition is also only approx. half of the expected length. (However, it is working...)

After a reset and the recognition of the USB-serial the timing change...
Pin 22 is still at ~4700-5200 us, but pin 21 is now showing a signal with approx. 5200 us. The "reset condition" on the onewire is now at ~1350 us, but the sensor set the presence only after 280 us (for approx. 160 us). The presence condition is checked 70 us after the end of the reset condition, so that is where the protocol fails. Somehow the sensor seems to switch to a slower timing, which is not specifiied...

So I see two major problems here:
1.) Timing with delayMicroseconds() is changing by approx. factor of 2, depending on the recognition of the USB-serial
2.) Timing of the DS18B20 sending the presence condition is changed (which is not according to the specification of the sensor). This might be due to the extreme long reset that could drain the internal capacitor of the sensor even with the power supplied to the sensor...

If the sensor would not behave like this, I would expect that it would be working. I set the reset delay in ZUNO-OneWire.cpp (line 155) to delayMicroseconds(980); and now sensor is working in both states, resulting in a reset condition of approx. 800us and the sensor still answering after approx. 30 us.

Problem 2 is not your problem, but I guess that problem 1 needs to be investigated...

But on top of that, both pins 21 and 22 are behaving "uncontrolled" when my main programm is reading the other sensors, updating the OLED and doing the zunoSendReport() stuff! Both signals are set to LOW at least twice during this phase...

Are these pins used for some internal things connected to ZWave? I thought there were completly free with no other usage... If there are not free, where is it documented?

I attached a zip file with some measurements from my logic-analyzer:
DS18B20_working9_4 MHz.logicdata: measurement before reset while the USB in not recognized -> working
DS18B20_not_working9_4 MHz.logicdata: reset performed during the measurement -> working at the beginning, not working at the end, changed timing can be seen!
DS18B20_working10_980us_4 MHz.logicdata: changed reset delay to 980us, measurement after reset
(Software can be downloaded here to import and analyze the signals)

Best regards,
Andreas.

[A.Harrenberg]

Hi,

i tested a little bit more, the pins 19 to 22 are all going to LOW during ZWave activity, either from zunoSendReport() or a communication issued by the controller.
For pin 24 and pin 25 this is not the case, they don't change their state.
Same for pin 11, 14, 15 they seems to not affected as well.

Regards,
Andreas.

[michap]

The issue about invalid USB device (after power on) was already reported - but there is something else strange.

If you will connect any LED to (as sample pin 9/10) and use the USB debug print (as sample with DHT sample from https://forum.z-wave.me/viewtopic.php?f=3427&t=23981 thwn Z-Uno will hang after some time while switching LED

Using the same sketch and PowerBank - all is working

Connecting the LEDs to pin 21/22 - the same without active Z-Wave connection (not included) - maybe problem exist only with active debugging - with Powerbank Z-Uno work long time...

@ Andreas - can you recheck it without debugging window or external Powerbank?

Michael

[A.Harrenberg]

Hi, have already done some of that...

Completly removing all serial code from sketch does not change the behavior. -> not related to serial debugging

At the moment I can't remember if the timing changed after a reset if a use just an USB-charger, need to measure that again, but I expect it to be the "wrong" timing, but the sensor working.

Regards,
Andreas.

[A.Harrenberg]

Hi,

i can confirm now that with only a power supply and no USB-serial the timing is "wrong" for both situations, after power-up and after a reset.

I hope that PoltoS can have a look at the measurements and find out what is going on here. For the timing problem that might be tricky, but I am more concerned about the behavior of the pins 19-22. It is not very funny having something connected to those pins while there are going to LOW during ZWave activities...

Regards,
Andreas.

[PoltoS]

Thanks for your deep investigation. We will make sure we hunt it and fix in 2.0.7

[A.Harrenberg]

Hi PoltoS,

i expect that you will find the bug and fix it
If you need more testing just let me know. It would be good if you can reproduce this so I can be sure that it is nothing that only exist on my system. I had some other problems with serial connection in the first place when i used an USB-Hub... But after testing with 4 different computers it should be a general problem.

Regards,
Andreas.

[A.Harrenberg]

Hi PoltoS,

I just found an older post here from mid of August where the problem of a pin going low during zunoSendReport() was mentioned. I think that this was not followed up as the topic changed then to some more logic of HIGH/LOW and that pin 23 is "reversed".

Regards,
Andreas.