DS18B20

Everything about programming the platform and using the Waspmote API
Franky
Posts: 17
Joined: Wed Nov 23, 2016 8:43 am

Re: DS18B20

Post by Franky » Fri May 19, 2017 8:47 am

Hi,

from my point there is an issue (we currently use API27).
Where it comes from, I don´t know.Here is a mesurement from this Sensor:

https://goo.gl/photos/krkdeVcUokowXeoh6


As you can see, there are times, where measurment works good, an then falls down to -1000.
From my point, it looks like a temperature related issue. the last 2 weeks it got warmer here.

BR Franky

gdmd86
Posts: 3
Joined: Sun Apr 23, 2017 7:54 pm

Re: DS18B20

Post by gdmd86 » Mon May 22, 2017 2:19 pm

After a few days of try and error with different DS18B20 sensors, we found the error on temperature reading (always -1000) was caused by a bug on the WaspUtils.cpp code.

On line 719 the code should be

Code: Select all

flag = WaspRegister &= REG_3V3;


instead of,

Code: Select all

flag = WaspRegister |= REG_3V3;


When we first tried the sensors, we were detecting a power pulse on the osciloscope so we though it was not power related. However, this changed introduced on API 28 was the problem.

libelium-dev
Posts: 27967
Joined: Mon Sep 28, 2009 1:06 pm

Re: DS18B20

Post by libelium-dev » Wed May 24, 2017 11:15 am

Hi,

We have done some tests with the API v028 and it works properly.

Are you working with smart agriculture board? or did you connect the sensor to Waspmote directly?

Regards

gdmd86
Posts: 3
Joined: Sun Apr 23, 2017 7:54 pm

Re: DS18B20

Post by gdmd86 » Wed May 24, 2017 3:16 pm

Hi,

We are using sensors connected directly to the WaspMote. Our test showed the waspmote was not powering the sensor. When we made the change previously mentioned it worked. It also works when using a digital output as VCC for the sensors. So the problem is related to the condition for power on.

When we checked the WaspUtils.cpp we found:

Code: Select all

719  bool flag = WaspRegister |= REG_3V3;
720 
721  if (flag == false)
722  {
723  PWR.setSensorPower(SENS_3V3,SENS_ON);
724  delay(10);
725  }
flag is suppose to indicate whether or not the sensor must be power on. However, by doing a bitwise OR operation (WaspRegister |= REG_3V3) you will always get a value different from false, so the sensors are off.

I guess that in your tests the SENS_3V3 is already on so it does not matter what this part of code does. However, if you try the example program (BS_05_reading_tempDS1820) you will notice the problem, assuming of-course that you are not using parasite power for the sensors.

libelium-dev
Posts: 27967
Joined: Mon Sep 28, 2009 1:06 pm

Re: DS18B20

Post by libelium-dev » Thu May 25, 2017 10:41 am

Hi,

You are right. We have checked what you say in the tests with the sensor connected directly to Waspmote. Previously we tested the DS18B20 sensor attached to the Smart Agriculture Board and the power supply was ON.

We will correct this bug on the next API version. Thank for sharing the solution with us :)

Regards

chriswater
Posts: 33
Joined: Tue May 05, 2015 2:59 pm

Re: DS18B20

Post by chriswater » Thu Jul 20, 2017 11:12 am

Dear all

We observed again the the problem with the -1000 readings from the sensor. I must say that we connected the sensors directly to the Waspmote board using our own circuit board (like the prototyping board).

When running the example script with waspmote-pro-ide-v04-windows it runs perfectly. When compile the same code with latest library and waspmote-pro-ide-v05-windows it fails!

Finally I connected the oscilloscope and checked what is going on. With the latest version the timing is completely to slow. Delays of 8us are around 90us. In the newer API a piece of code was added to the delayMicroseconds() function:

Code: Select all

	// make conversion to simulate a 8MHz clock
	unsigned int us_aux = us;
	
	if( us > 3)
	{
		us_aux*=1.8;
	}
	else
	{
		us_aux*=2;
	}
Unfortunately the multiplication has side effects from my observation. When you replace it with us_aux*=2; (not floating point) or leave it away then it works. To multiply the us value by 1.8 is a good idea, because then the measured delays match perfectly, but unfortunately it failes. Casting the expression to (unsigned int) does not help.

Is there any ATMEL gcc compiler specialist out there that can explain that behaviour?

Kind regards,
Chris

chriswater
Posts: 33
Joined: Tue May 05, 2015 2:59 pm

Re: DS18B20

Post by chriswater » Thu Jul 20, 2017 11:35 am

Dear all

The floating point multiplication needs many CPU cycles and therefore a delay that is multiples of microseconds...
Can someone confirm that?

Cheers,
Chris

libelium-dev
Posts: 27967
Joined: Mon Sep 28, 2009 1:06 pm

Re: DS18B20

Post by libelium-dev » Mon Jul 24, 2017 11:34 am

Hi chriswater,

Did you connect the sensor to Waspmote or to Smart Agriculture board?

Did you perform the change in the library that gdmd86 said?
On line 719 the code should be

Code: Select all

flag = WaspRegister &= REG_3V3;
instead of,

Code: Select all

flag = WaspRegister |= REG_3V3;
Regards

chriswater
Posts: 33
Joined: Tue May 05, 2015 2:59 pm

Re: DS18B20

Post by chriswater » Mon Jul 24, 2017 1:23 pm

Dear libelium-dev

My issue was not the supply of the sensor, that is fine. I observed a serious issue with the timing on the One-wire bus after I switched my projects from Wasmode IDE 4 to Waspmode IDE 5 with latest libraries.

Please check the function delayMicroseconds() in the wiring.c. From my point of view it can not work when there is a floating point multiplication within the code. That seems to had been changed in one of the newer API releases and is independant from connecting the sensor directly or using the Agriculture board.

Best regards

libelium-dev
Posts: 27967
Joined: Mon Sep 28, 2009 1:06 pm

Re: DS18B20

Post by libelium-dev » Tue Jul 25, 2017 10:14 am

Hi,

There was a change inside WaspOne Wire library from API v023 to API v025. We changed the microseconds delay inside read_bit function.
API v023

Code: Select all

uint8_t WaspOneWire::read_bit(void)
{
	IO_REG_TYPE mask=bitmask;
	volatile IO_REG_TYPE *reg IO_REG_ASM = baseReg;
	uint8_t r;

	noInterrupts();
	DIRECT_MODE_OUTPUT(reg, mask);
	DIRECT_WRITE_LOW(reg, mask);
	delayMicroseconds(2);
	DIRECT_MODE_INPUT(reg, mask);	// let pin float, pull up will raise
	delayMicroseconds(7);
	r = DIRECT_READ(reg, mask);
	interrupts();
	delayMicroseconds(45);
	return r;
}
API v025

Code: Select all

uint8_t WaspOneWire::read_bit(void)
{
	IO_REG_TYPE mask=bitmask;
	volatile IO_REG_TYPE *reg IO_REG_ASM = baseReg;
	uint8_t r;

	noInterrupts();
	DIRECT_MODE_OUTPUT(reg, mask);
	DIRECT_WRITE_LOW(reg, mask);	
	delayMicroseconds(1);
	DIRECT_MODE_INPUT(reg, mask);	// let pin float, pull up will raise
	delayMicroseconds(5);
	r = DIRECT_READ(reg, mask);
	interrupts();
	delayMicroseconds(50);
	return r;
}
Please try to configure the same microsecond delay as the API v023. Does it work?

Regards

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest