junkfix / esp32-ds18b20

Arduino Library for ESP32 DS18B20 Non Blocking Onewire RMT protocol, no dependencies, minimal
MIT License
22 stars 5 forks source link

Problem with more than 4 sensors? #6

Closed markus-hi closed 5 months ago

markus-hi commented 11 months ago

Hello,

i have tested your library and i am stuck with one problem. If i use more than four sensors, i no longer get correct values or the first sensor is recognized twice:

Message (Enter to send message to 'ESP32 PICO-D4' on 'COM8') New Line 115200 baud load:0x3fff0030,len:1184 load:0x40078000,len:13260 load:0x40080400,len:3028 entry 0x400805e4 0: 0xd100000009238028, 1: 0xc000000008e4b028, 2: 0xc9000000092b9c28, 3: 0x1e0000000966e128, 4: 0xd100000009238028,

The first and the last sensor ID is the same? Do you have any idea what could be the cause?

I'm using Arduino IDE V2.2.1 for Windows. My board is an Espressif Pico Kit v4.

Markus

markus-hi commented 11 months ago

Looks like the sensor IDs repeating, sample with 6 sensors: 😮

0: 0xd100000009238028, 1: 0xc000000008e4b028, 2: 0xc9000000092b9c28, 3: 0x1e0000000966e128, 4: 0xc000000008e4b028, 5: 0xc9000000092b9c28,

htmltiger commented 11 months ago

please post your code. also make sure your have added pull-up resistor, also try it on breadboard as long cables can sometimes corrupt data.

markus-hi commented 11 months ago

It is the original code from your example. I've built everything on a test bread board, the 1-Wire Port is Port 13. It has a pullup with 4,7 k on the 5 V line.

image

htmltiger commented 11 months ago

Is the problem only with search? have you tried using the addresses?

//uint64_t addr[MaxDevs];

uint64_t addr[] = {
0x183c01f09506f428,
0xf33c01e07683de28,
};
markus-hi commented 11 months ago

Have only tried to use the search function. I am using your original code, I have only adapted the pin number. The section with the addresses is commented out.

htmltiger commented 11 months ago

try it

markus-hi commented 11 months ago

This will be difficult because I want to use sensors that are already permanently installed, at the moment these are read out via an older control unit, which works without any problems. Now I wanted to implement a new control system and make the whole thing smarter. But I can't read out the addresses because the routine doesn't work properly. I'll try a different library, maybe that will work.

Thank you!

htmltiger commented 11 months ago

if you have fixed sensors you only need to read the addresses one time

const uint8_t MaxDevs = 4;

uint64_t addr[] = {
    0xd100000009238028,
    0xc000000008e4b028,
    0xc9000000092b9c28,
    0x1e0000000966e128,
};
markus-hi commented 11 months ago

The problem is that I do not get a correct output of the addresses! That's why I can't use the list with the addresses. But I have now connected each sensor individually for testing. The only thing I noticed is that one sensor is not read out correctly and the first byte is wrong: 2: 0x 7 00 00 00 08 c8 51 28,

The first byte should correctly be 07. And whenever this sensor is connected, it no longer works at some point. I have now used different software to better understand the problem. I have flashed this example to the esp32: https://github.com/DavidAntliff/esp32-ds18b20-example This gives me the following output: Find devices: 0 : d100000009238028 1 : c000000008e4b028 2 : c9000000092b9c28 3 : 1e0000000966e128 4 : 0700000008c85128 Found 5 devices

The address is determined correctly here. Can you explain this? I have not changed the hardware, just flashed the other firmware. However, I don't really know whether this is the cause.

markus-hi commented 11 months ago

Or are the leading zeros simply not displayed on the first byte?

htmltiger commented 11 months ago

0x0700000008c85128 0x700000008c85128

both are same

whSwitching commented 8 months ago

same issue when search 3 devices, dev1 and dev3 has same address. all devices data pin pullup with 4.7k to 3v3 and all addresses start with 28 make more sense than end with 28 (not reverse bytes)

junkfix commented 5 months ago

this seems to be fixed in 1.0.7 or try the latest version 2.0.0