Ds18s20 not recognised by EmonTX

Zippair · 31 October 2022 18:56

Hi,

I have a problem with my EmonTX3, (HW3.45). I connected a ds18b20, but it can’t find it. Temp enabled via serial port (t0 1), and can read the address of the ds18b20 (0x10, 0x1B, 0x2A, 0x88, 0x00, 0x08, 0x00, 0xAE) with an adruino, and this ino can see too: emontx2/emontx_lowpower_temperature.ino at master · openenergymonitor/emontx2 · GitHub

Please, help me, what can I do?

dBC · 31 October 2022 22:30

That first byte in the UID (0x10) tells you it’s a DS18S20 rather than a DS18B20 (I fixed the title of this thread for you). A DS18B20 has 0x28 in that byte.

Anything built on the standard Arduino Dallas temp sensors stuff supports a bunch of similar sensors:

github.com

milesburton/Arduino-Temperature-Control-Library/blob/master/DallasTemperature.cpp#L70


      
          #if REQUIRESALARMS
          	setAlarmHandler(NO_ALARM_HANDLER);
          #endif
          	useExternalPullup = false;
          }
          
          
DallasTemperature::DallasTemperature(OneWire* _oneWire) : DallasTemperature() {
          	setOneWire(_oneWire);
          }
          
          
bool DallasTemperature::validFamily(const uint8_t* deviceAddress) {
          	switch (deviceAddress[DSROM_FAMILY]) {
          	case DS18S20MODEL:
          	case DS18B20MODEL:
          	case DS1822MODEL:
          	case DS1825MODEL:
          	case DS28EA00MODEL:
          		return true;
          	default:
          		return false;
          	}

Stuff using EmonLibCM requires it to be precisely a DS18B20 (i.e. 0x28):

github.com

openenergymonitor/EmonLibCM/blob/master/emonLibCM.cpp#L1236


      
          byte scratchpad[3];
          scratchpad[0] = 0;                              // low alarm
          scratchpad[1] = 0;                              // high alarm
          scratchpad[2] = temperatureResolution;          // resolution
          
          
for(byte j=0; j<temperatureMaxCount; j++)
              temperatures[j] = UNUSED_TEMPERATURE;        // write 'Sensor never seen' marker to temperatures array
          oneWire.reset_search();
          numSensors = 0;
          while (oneWire.search(deviceAddress)) 
              if (deviceAddress[0] == DS18B20SIG)
                  numSensors++;
          if (keepAddresses && temperatureSensors[0][0] != 0x00)
          {
              numSensors = temperatureMaxCount;
              for (numSensors = temperatureMaxCount; numSensors > 0; numSensors--)
              {
                  if (temperatureSensors[numSensors-1][0] == DS18B20SIG)       // signature of a DS18B20, so a pre-existing sensor
                      break;
              }
          }

If you’re handy with C programming and the tools, I don’t think it would be too difficult to add in support for both.

borpin · 1 November 2022 07:23

@Robert.Wall @TrystanLea, could we support other sensors?

Zippair · 1 November 2022 08:13

Thanks your quick reply. Unfortunately i am not a programmer, so I have to buy some ds18b20 (ds18s20 was in my stock).

borpin · 1 November 2022 08:15

I was asking that question of the 2 people I tagged! However, it won’t happen immediately.

Zippair · 1 November 2022 08:30

Oh Sorry, Brian, I only read the first answer, a can wait the experts answer. many thanks your support.

TrystanLea · 1 November 2022 09:18

Hello @Zippair would you happy to try making a modification to the code to see if you can get it to work? It may just be a matter of removing the line @dBC highlighted above? But you would also need to compile and upload the code. The device type was likely hard coded here for DS18B20SIG to avoid other potential incompatibilities… It might be more hassle than it’s worth for you to explore this so feel free if you prefer to switch the sensors for DS18B20’s.

I dont know enough about the different type of one wire sensor variants and implications of expanding the available list to comment at this point so it would need to a bit of investigation and testing to see if this is something that could be expanded.

Zippair · 1 November 2022 09:37

Hello @TrystanLea. If i have to remove this line:
if (deviceAddress[0] == DS18B20SIG) from EmonLibCM, probably i can do it. Compiling and uploading will work, i hope.
Is it needed to modify the Dallas temperature.cpp?

Zippair · 1 November 2022 10:27

I removed the line from EmonLibCM, and it works! I need to calibrate it, because is shows 2,9C when the temp is about 22C, but i can calibrate it in emonHub config.
Many thanks the quick support, gentlemans!

rupert · 1 November 2022 10:40

Perhaps this app note might be of some help …

TrystanLea · 1 November 2022 11:34

That’s great! any ideas for why the calibration was needed? do you think thats a software issue?

rupert · 1 November 2022 12:38

From a quick look, and with apologies for any blunders …

I think the emonTx3 reads the temperature sensor with 11 bit resolution.

From the app note I think the DS18S20 has some differences to the DS18B20:

The temperature registers of the DS18B20 and DS18S20 are weighted differently.
The DS18S20 by default returns a 9 bit result, and you have to read two extra registers and do some sums to get 11 bit resolution.
The DS18S20 conversion time is always 750mS, irrespective of the resolution.

So I’m not sure how easy it is to get the right answer from a DS18S20!

TrystanLea · 1 November 2022 13:08

Thanks @rupert

Robert.Wall · 1 November 2022 13:09

My two-penn’orth is the DS18B20 is the only one stocked by Megni, the OEM Shop, and it’s the only one available for me to test. If someone wants to send me a few samples of each that they want to see the library made to work with, I’m sure @TrystanLea will forward them. Until then, the library documentation makes it quite clear that ONLY the DS18B20 is catered for.

And due to various pressures and commitments, I won’t be able to do anything any time soon.

TrystanLea · 1 November 2022 13:14

@Robert.Wall no expectation to incorporate this soon, just interested to see if @Zippair can get this working satisfactorily for his requirements locally on his system. If we know it works and what the modifications are then we can consider longer term it’s inclusion as an option or just forward people to this thread if this requirement crops up again

dBC · 1 November 2022 21:19

We know @Zippair 's sensor works with sketches using the Arduino Dallas library so that’s probably a good place to turn. It appears they’ve done a thorough job of highlighting all the differences (just grep for DS18S20MODEL to find all the places they’ve needed to treat it differently).

With regards the temperature reading:

github.com

milesburton/Arduino-Temperature-Control-Library/blob/master/DallasTemperature.cpp#L688


      
          		fpTemperature = (((int32_t) scratchPad[TEMP_MSB]) << 11)
          		                | (((int32_t) scratchPad[TEMP_LSB] & 0xFC) << 3)
          		                | neg;
          	} else {
          		fpTemperature = (((int16_t) scratchPad[TEMP_MSB]) << 11)
          		                | (((int16_t) scratchPad[TEMP_LSB]) << 3)
          		                | neg;
          	}
          
          
	/*
          	 DS1820 and DS18S20 have a 9-bit temperature register.
          
          
	 Resolutions greater than 9-bit can be calculated using the data from
          	 the temperature, and COUNT REMAIN and COUNT PER °C registers in the
          	 scratchpad.  The resolution of the calculation depends on the model.
          
          
	 While the COUNT PER °C register is hard-wired to 16 (10h) in a
          	 DS18S20, it changes with temperature in DS1820.
          
          
	 After reading the scratchpad, the TEMP_READ value is obtained by
          	 truncating the 0.5°C bit (bit 0) from the temperature data. The