orgua / OneWireHub

OneWire slave device emulator
GNU General Public License v3.0
343 stars 86 forks source link

Master Unable To Read DS18b20 After Firmware Ugrade #13

Closed NickCoolasia closed 6 years ago

NickCoolasia commented 7 years ago

Hi, I'm using Arduino Pro Mini 5V/16MHz to emulate 2 DS18b20 temperature sensor. My one wire master is a GPS device which can read any one wire device. Previously, I modified the timing of .h file until the master can read my emulated DS18b20 properly.

But recently, the GPS company publish a new firmware. And this new firmware cannot read the temperature reading, But by reading the GPS log using terminal, 2 DS18b20 were detected and ID were shown in the terminal but readings are not showing in the server. But when I try to downgrade GPS to old firmware, readings show on server immediately.

New firmware is able to show the readings of real DS18b20 on server. So I suspect it is write or read timing issue. But I have tried to adjust the timing by comparing the real DS18b20 timing and emulated timing using USBee AX PRO logic analyser but 2 seems like the same.

So hope I get get some help from you. Thank you.

orgua commented 7 years ago

that sounds interesting. If you haven't allready, could you please migrate to the latest hub-version 0.9.9? my troubleshooting would look something like that:

  1. record a trace of the old GPS-FW with a real ds18b20 and the emulated one, at best with enabled gpio-debug (both sensors should work)
  2. record a trace with the new FW, same setup --> there must be some kind of difference in timing or usage (i think the alarm-functionality is not emulated)

the sensor doesn't support overdrive. that is good for us. Have you tried cloning the sensor, including ID and valid temperature? If you want i have a look at your logic-traces. And i would be interested to see your changes in timing. I hope we can find a set that is working for everyone.

NickCoolasia commented 7 years ago

Thanks for your reply. What do you mean by migrate to latest hub-version 0.9.9? Traces.zip

Above is all the traces that I recorded, also there is an image of the timing that I changed

Also, what do you mean by cloning?

Hope you can help me. Thank you

orgua commented 7 years ago

Sorry, i meant latest version 0.9.8: https://github.com/orgua/OneWireHub/releases And cloning means, that you take the ID and current temp-value from the original Sensor and put it in the emulator. So you can at least eliminate some possibly new plausability check causing the error in the new gps-FW.

orgua commented 7 years ago

hmmm, the software for your traces doesn't run on win10. i have nothing else left :-(

NickCoolasia commented 7 years ago

Ok I will migrate to the newest version and also test to clone.

But I'm using win 10 also. Maybe you can try to download pulseview. There is a installation guide in the first post of the link below. http://forum.arduino.cc/index.php?topic=333017.180

Thank you

orgua commented 7 years ago

i noticed your timings are a little bit strange. the changes in reset and presence should make compatibility worse and not better. the last four timing-values (starting with time_slot_max) could be ok if your bus is this a little bit weird.

NickCoolasia commented 7 years ago

Sorry for the late reply,

May I know what do you mean by "the changes in reset and presence should make compatibility worse and not better"?

orgua commented 7 years ago

you set reset_min from 430 to 720µs. Every reset shorter than that won't be recognized as a reset. normal masters emit a reset for about 500µs. Same with presence detection. per standard it should be low between 160 to 300µs. your slave tries to respond with this presence-detection. Your setting limites the low-state to 110-120µs. My master would reject this and conclude that there is no slave on the bus.

btw: i was very busy with the rework of the lib. if your problems still persist please try the current branch: https://github.com/orgua/OneWireHub/tree/tick_timing_and_overdrive

orgua commented 6 years ago

did you use negative temperatures? speaking of "silly things" -> i just wrote new unittests for the examples in the datasheets of the three sensors. My implementation was wrong for degC <= 0. will push new release in some minutes