Conflict between RFM95W/LMIC and DS18B20 temperature

I connected a DS18B20 to my node. The node runs https://github.com/matthijskooijman/arduino-lmic and works fine. If I load a basic test sketch for the DS18B20 on the same node hardware (so ignoring the RFM95W) it works fine too and I get good temperature readings.

When I merge the two sketches the sensor returns -127.00 which suggest a timing problem. Google suggested that the interrupts used by the LMIC code interfere so I added noInterrupts() and Interrupts() around the read logic, and now the results changed to 0.00.

  noInterrupts(); 
  sensors.requestTemperatures(); // Send the command to get temperatures
  printTemperature(insideThermometer); // Use a simple function to print out the data
  interrupts();

It looks to me that this way there won’t be interference anymore, but it still doesn’t work. Anyone a suggestion where to look next?

sub question: I noticed that apparently it was possible with the old large LMIC library to use a DS18B20 on a pro mini, but I wasn’t able to getting it fit in the available memory. At least not by simply merging the code. Does there happen to be a stripped done Dallastemperature/OneWire library that others use for this?

@TijnOnlijn Hi
I used a Arduino UNO with a Dragino shield (V1.3) and a DS18B20 (with 4k7 resistor) and I had NO problem running the example ttn-abp and the 18B20 code added to it.

I worked on this together with @TijnOnlijn and we managed to solve the issue.
We initially used pin 10 on the Arduino for the DS18B20 and it appeared this was also used by the arduino_lmic but we didn’t connect it to the RFM95W. After switching to pin 9 it worked like a charm.

Am trying with 4 DS18B20 and am able to collect data of 3 and send, but the problem is, the first data is wrong which should be 26.75 I get only 6.75. Code is as below.

sensors.requestTemperatures();

 Serial.print("Temperature of 1st IC is: "); 
 tempC = sensors.getTempCByIndex(0);
 temp = tempC * 100;
 data[0] = temp >> 2;
 data[1] = temp & 0xFF;
 Serial.println(temp);

  Serial.print("Temperature of 2nd IC is: "); 
  tempC = sensors.getTempCByIndex(1);
  temp = tempC * 100;
  data[2] = temp >> 4;
  data[3] = temp & 0xFF;
  Serial.println(temp);

  Serial.print("Temperature of 3rd IC is: "); 
  tempC = sensors.getTempCByIndex(2);
  temp = tempC * 100;
  data[4] = temp >> 6;
  data[5] = temp & 0xFF;
  Serial.println(temp);

  Serial.print("Temperature of 4th IC is: "); 
  tempC = sensors.getTempCByIndex(3);
  temp = tempC * 100;
  data[6] = temp >> 8;
  data[7] = temp & 0xFF;
  Serial.println(temp);

and after the decoding function at TTN

function Decoder(bytes, port) {
var temp0 = bytes[0] << 2|bytes[1];
var temp1 = bytes[2] << 4|bytes[3];
var temp2 = bytes[4] << 6|bytes[5];
var temp3 = bytes[6] << 8|bytes[7];

// Decode an uplink message from a buffer
// (array) of bytes to an object of fields.

// if (port === 1) decoded.led = bytes[0];

return {
Temp0 : temp0/100,
Temp1 : temp1/100,
Temp2 : temp2/100,
Temp3 : temp3/100};
}

I get output as

{
“Temp0”: 7.27,
“Temp1”: 28,
“Temp2”: 28,
“Temp3”: 527.36
}

You should shift (>> and <<) by 8 in all cases. Not 2, 4, 6 and 8. The number of bits to shift depends on the ‘word’ length which is a byte == 8 bits, not on position in the array.

1 Like

Thank you.

You should not use pin 10 (default Slave Select) as in INPUT (even if you define another slave select pin). You can use it as an universal OUTPUT, but then you have to assign it as output before initializing the SPI bus, according to comments in SPI.cpp

void SPIClass::begin() {
  // Set direction register for SCK and MOSI pin.
  // MISO pin automatically overrides to INPUT.
  // When the SS pin is set as OUTPUT, it can be used as
  // a general purpose output port (it doesn't influence
  // SPI operations).
  pinMode(SCK, OUTPUT);
  pinMode(MOSI, OUTPUT);
  pinMode(SS, OUTPUT);
  
  digitalWrite(SCK, LOW);
  digitalWrite(MOSI, LOW);
  digitalWrite(SS, HIGH);
  // Warning: if the SS pin ever becomes a LOW INPUT then SPI 
  // automatically switches to Slave, so the data direction of 
  // the SS pin MUST be kept as OUTPUT.

A post was merged into an existing topic: Measuring internal temp of oysters and mussel