Blizzard

Most recent activity

• Problem with the DS18B20 temperature sensor (NUCLEO-F401RE board )

  @Blizzard started

  • 24 comments
  • 7,904 views

  @Wilberforce replied
• HD44780 Character LCD: problem with I2C and ST NUCLEO-F401RE

  @Blizzard started

  • 23 comments
  • 7,811 views

  @Blizzard replied
• HD44780 Character LCD: problem with I2C and ST NUCLEO-F401RE

  in Other Boards • 6 years, 7 months

  

  The

  pinch of salt

  that is also the beauty of using a device with limited resources ...
  Thanks so much !

• Problem with the DS18B20 temperature sensor (NUCLEO-F401RE board )

  in Other Boards • 6 years, 7 months

  

  Thanks a lot for the complete code.
  Unfortunately I am not yet able to read the correct temperature (see below):

   _____                 _
  |   __|___ ___ ___ _ _|_|___ ___
  |   __|_ -| . |  _| | | |   | . |
  |_____|___|  _|_| |___|_|_|_|___|
            |_| http://espruino.com
   1v93 Copyright 2016 G.Williams
  Espruino is Open Source. Our work is supported
  only by sales of official boards and donations:
  http://espruino.com/Donate
  >
  =undefined
  Temp is -0.0625°C
  Temp is -0.0625°C
  Temp is -0.0625°C
  Temp is -0.0625°C
  Temp is -0.0625°C
  Temp is -0.0625°C
  Temp is -0.0625°C
  

  The device returns a negative temp value that seems compatible with a scratchpad reading like FF ... FF.
  Also changing the value of the pull up resistor between data and 3.3V (e.g. 3.3K or 2K) the result does not change (note: the "native code" also works fine without pull-up connected!)
  At this point, I try to focus on the low level differences between the two implementations (the one that works and Espruino).
  I see so far slight differences in the low-level commutation timings (e.g. in reset pulse, write bit "0" or "1"), though both implementations seem compatible with device sampling / response times.
  Maybe these differences combined with the fact that I'm using a sensor with only a 1m cable can determine the different behavior.
  Obviously to go deep I have to recover an oscilloscope that can help me in the analysis of the low level signals between the two cases (not immediately unfortunately).
  Any other suggestion from you is welcome!

• Problem with the DS18B20 temperature sensor (NUCLEO-F401RE board )

  in Other Boards • 6 years, 7 months

  

  Hi @Gordon,
  maybe there is a misunderstanding because I did not explain it well.
  This is your code that ignores the CRC in recovering \ convert the temperature from the device.
  What is not 100% clear to me is what piece of "my code" should be merged with this one kindly suggested by you.
  Until now, I have used the "hello world" example that is shown in the DS18B20 sensor page (http://www.espruino.com/DS18B20)
  Alternatively, I have tried the OneWire code example to send raw commands to the device (retrieved from the relevant page: http://www.espruino.com/OneWire)

  Could you please clarify which of the two "pieces" should I use?

  Thanks in advance for your feedback...

• Problem with the DS18B20 temperature sensor (NUCLEO-F401RE board )

  in Other Boards • 6 years, 7 months

  

  Hello all,
  many thanks for the tips!
  @Gordon: I have not yet tried the code that ignores the CRC verification. But I'm going to try...
  Could you please clarify which "piece of code" I need to merge with the code you suggested?

  @Wilberforce: the DS18B20 sensor I'm using is cabled with 1 m cable.
  Since I don't want to leave anything not attempted, I will try the resistor values you suggest if the test suggested by Gordon is not OK ...

• Problem with the DS18B20 temperature sensor (NUCLEO-F401RE board )

  in Other Boards • 6 years, 7 months

  

  Hello all,
  unfortunately, the suggested procedure does not seem to give clues for now.
  I tried the configuration and the piece of code suggested by using different values of the resistors in my possession (200R, 470R, 680R, 1K, 4.7K, 10K) without triggering the "watch fired" message (the message appears iteratively, as expected, only by removing the resistor leaving the pin floating).
  The "sentinel pin" (A1) mode has been configured as:

  • input
    
  • input_pulldown
    
    

  Note that also the "native application" continues to work properly, even when connecting the resistor between the sensor power pin and 3.3V power line supplied by the module, except when the connected resistor is 10K.
  In this latter case, the converted temperature values are clearly incorrect (but return good immediately after the resistor is removed or replaced with a smaller one among those listed).
  This type of resistor values seems to undermine the sensor acquisition and conversion capability...

• Problem with the DS18B20 temperature sensor (NUCLEO-F401RE board )

  in Other Boards • 6 years, 8 months

  

  Thank you very much for your suggestion!
  For me it is correct to investigate in this direction (in the past I have never experienced any issue related to "poverty" of the power supply contacts).
  For information, using the "native" implementation and the same board \ connections, the temperature sensor also works at 5V without problems (even with Arduino the 5V is OK).
  With Espruino instead I get the same failure unfortunately:

  Temp is null°C
  Temp is null°C
  Temp is null°C
  

  I hope to give the first results as soon as possible ...
  Stay tuned!

  Regards

• Problem with the DS18B20 temperature sensor (NUCLEO-F401RE board )

  in Other Boards • 6 years, 8 months

  

  Hi Gordon, allObjects,
  many thanks again for the feedabck, as usual you are a "wealth of information".
  I try to start from the last suggestion (which gives me many cues for action) making the following simple experiment.

  The fairly simple connections are made through a breadboard; explicitly removing the cable on the power line connected with 3.3V pin on the Nucleo board I can still read the serial number via Espruino (this is for me quite surprising since I had the same idea of @allObjects concerning power supply management)
  Same behaviour for the other "native" implementation where I get the serial number correctly but, subsequently, the sensor always read 85 ° C from the scratchpad memory which, according to the device user manual, represents the value of the scratchpad at "power up state"
  No subsequent temperature variation is measured \ perceived by the sensor in this configuration.
  Reconnecting the power supply pin (even "on the fly") all goes back to working properly...
  Regards

• Problem with the DS18B20 temperature sensor (NUCLEO-F401RE board )

  in Other Boards • 6 years, 8 months

  

  Unfortunately I do not have another sensor (of the same type), nor the oscilloscope for electric measurements (sigh!).
  Anyway, I will try to get the latter because I don't want to leave the question open!

  However, I agree with your hypothesis, it may be a tolerance problem of the device \ sensor respect to the low-level timings applied by Espruino (if I understand well).

  This leads me to ask a question (for purely cognitive purposes) about how low level operations are organized in Espruino (e.g. for the oneWire interface).
  For example, how does a reset pulse is sent on the OneWire interface?
  Sorry if it's a trivial question maybe, but it's just for better know some details that could explain some difference with the working implementation on the same board...

  The OneWire Class and the DS18B20 sensor module correctly hide these "electrical" aspects and only expose functions to send and receive bytes, initialize the line, get the temperature value etc, etc, ...
  Thanks in advance for the feedback!

  Regards