I want to retrieve the exact times of all 0x00 operations from Data:0X22 to Data:0xc2 using the logic analyzer. Below is my code.

[mayjack0312]

This issue is still a timing logic problem.
My code is as follows:

#include <OneWire.h>
#include <DallasTemperature.h>

#define ONE_WIRE_BUS 2

OneWire oneWire(ONE_WIRE_BUS);

DallasTemperature sensors(&oneWire);

void setup() {
  Serial.begin(9600);
  sensors.begin();
}

void loop() {
  int deviceCount = sensors.getDeviceCount();

  for (int i = 0; i < deviceCount; i++) {
    unsigned long startTime = micros();

    sensors.requestTemperaturesByIndex(i);

    float temperatureC = sensors.getTempCByIndex(i);

    unsigned long endTime = micros();

    float duration = (endTime - startTime) / 1000.0;

    Serial.print("传感器 ");
    Serial.print(i);
    Serial.print(" 温度: ");
    Serial.print(temperatureC);
    Serial.print(" °C, 读取时间: ");
    Serial.print(duration, 3);
    Serial.println(" 毫秒");

    delay(1000);
  }

  delay(5000);
}

The current measurement results include the start and stop commands, but I only want the times for the Data:0x00 operations in the middle section of the loop.

[RobTillaart]

This is not a library problem.

If you only want the middle section, just put you start and end timing around the getTempC() part.

If you need to dig deeper, you have to measure the underlying oneWire calls.

Definitely outside this library.

Just curious, what do you want to achieve with these measurements?

[mayjack0312]

This is not a library problem.

If you only want the middle section, just put you start and end timing around the getTempC() part.

If you need to dig deeper, you have to measure the underlying oneWire calls.

Definitely outside this library.

Just curious, what do you want to achieve with these measurements?

Following the new question in the post below

After delving deeper and studying, I found that it is not that easy to achieve.

cpetrich/counterfeit_DS18B20#38

The main goal is to achieve batch detection of the relevant data in the table below.

[RobTillaart]

The main goal is to achieve batch detection of the relevant data in the table below.

The milliseconds conversion time is no problem for microprocessors.
To get accurate timing in the microsecond level you need a processor with a very fast IO and clock e.g. ESP32.
For sub-microsecond measurements, you have to look at a red-pitaya or so.

My assumption is that a ESP32 at 240 MHz will be capable of measuring these values with reasonable repeatability and accuracy. An Arduino UNO or MEGA at 16 MHz has a micros resolution of 4 us so it can not measure below 50 us (unless an error of ~10% is acceptable).

So your setup should involve at least 2 processors.

• one that interacts with the DS18B20 and sends a variety of commands including temperature measurements etc.
• The second processor (ESP32) monitors the signals on the oneWire bus and analyzes them.
• The second triggers the first one to start a test e.g. a byte over serial indicating which test to do)
• The first one signals the second sensor that it is ready with a test step (same byte over Serial)
• The second needs to handle time out of the running test.
• The second processor does the test e.g. 100 times to get an estimate of the mean and standard deviation of the timing.

Not trivial but certainly doable.

[mayjack0312]

The main goal is to achieve batch detection of the relevant data in the table below.

The milliseconds conversion time is no problem for microprocessors. To get accurate timing in the microsecond level you need a processor with a very fast IO and clock e.g. ESP32. For sub-microsecond measurements, you have to look at a red-pitaya or so.

My assumption is that a ESP32 at 240 MHz will be capable of measuring these values with reasonable repeatability and accuracy. An Arduino UNO or MEGA at 16 MHz has a micros resolution of 4 us so it can not measure below 50 us (unless an error of ~10% is acceptable).

So your setup should involve at least 2 processors.

• one that interacts with the DS18B20 and sends a variety of commands including temperature measurements etc.
• The second processor (ESP32) monitors the signals on the oneWire bus and analyzes them.
• The second triggers the first one to start a test e.g. a byte over serial indicating which test to do)
• The first one signals the second sensor that it is ready with a test step (same byte over Serial)
• The second needs to handle time out of the running test.
• The second processor does the test e.g. 100 times to get an estimate of the mean and standard deviation of the timing.

Not trivial but certainly doable.

Thank you for the insights. I hadn't considered the processor performance issues before. It looks like I'll have to keep working with the ESP32.