• I cannot see any issue with the code, and with the hardware connectivity things look right the way you describe. I do though not know how serial numbers should look like... (length seems though to be correct: 64 bits... but is there some crc or checksum bit(s) in it?)

    First, I would try with a different pin.

    You may also try to watch the data pin with another pin and use simple watch or Waveform class... (best is to use a separate board for that to have no interference...

    Another option is to replace the sensor... today's cheapos do not always as shiny as they look... (see this dud... fetched from the mechanical world).

    Both, watch and Waveform use buffers which allow the oneWire to finish his job and then deferred you code can do an analysis. Setup a setWatch (with no / 0 debounce) then fire one wire communication, or setup Waveform for input and then fire one wire communicaiton. Even though you may not capture all info - because the one wire is pretty fast - you may get something, and you may even get timing errors... at least indicator that something is going on with some issue...

  • Hello allObjects,
    thanks a lot for your feedback.
    Before trying the example code with Espruino and the DS18B20 module, I tested the very same configuration (e.g. Nucleo Board + 4.7K Resistor + Sensor) using another "native" program and I get the correct temperature.

    Moreover, the same sensor was also tested using an Arduino board and a sample sketch that use the oneWire protocol commands; I get (and convert) the temperature without problems and read the same serial number of the device as returned by Espruino.

    Based on these results I can not say that the sensor itself is damaged or not working...

    Unfortunately, using Espruino and Nucleo Board I can only read the sensor 64-bit serial code through the function OneWire.search() API.
    According to the DS18B20 device user manual, the retrieved code is correct since the last CRC byte (0x20) is properly calculated.
    The possibility to read such number is for me a clue that, "electrically" the OneWire interface links are fine, but any subsequent attempt to read the device memory (scratchpad) or start a temperature conersion\reading cycle through protocol commands is unsuccessful (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
    >var ow = new OneWire(A0);
    =OneWire { "pin": A0 }
    >device = ow.search()[0]; // search returns an array of device IDs
    ="28ff050b85160520"
    >ow.reset();
    =true
    >ow.select(device);
    =undefined
    >ow.write(0xBE); // Read Scratchpad [BEh]
    =undefined
    >var result = ow.read(9);
    =new Uint8Array([255, 255, 255, 255, 255, 255, 255, 255, 255])
    > 
    

    Definitely I think I'm losing something when, after I get the device serial number (address), I try to pick the device, but, frankly I don't know what the problem is.
    Even leaving the DS18B20 module working, the situation is not better.

    It would be nice to know and deepen the root cause of the problem (otherwise, even by replacing the device, I would remain locked on the first sensor selection)
    Meanwhile I continue with the experiments ...

    Regards

About

Avatar for allObjects @allObjects started