Serial Comms and Crystals

[Scampy]

OK seems to of been a hardware issue. Replaced the sensor and now get a value on the lcd. The program is giving a reading of 870.4 - how would I turn this into a percentage

[Tabsoft]

Just to get a sense of the raw data collected, perhaps you can change your "main" subroutine to the follow and post the results output on the LCD?

main:
 gosub read_dht
 'LCDOut $FE,$94,"rh ",#hum/10,".",dec1 hum//10
 lcdout $FE, $94, hex2 dht(0), " ", hex2 dht(1), " ",hex2 dht(2), " ", hex2 dht(3), " ", hex2 dht(4)
 pause 4000
 goto main

[Scampy]

LCDOut $FE,$94,"rh ",#hum/10,".",dec1 hum//10 this gives a value of 870.4

lcdout $FE, $94, hex2 dht(0), " ", hex2 dht(1), " ",hex2 dht(2), " ", hex2 dht(3), " ", hex2 dht(4) produces 38 00 16 00 22

[Scampy]

In one of the other examples I've tested it has the following statement

humid=dht[31]*128+dht[30]*64+dht[29]*32+dht[28]*16+dht[27]*8+dht[26]*4+dht[25]*2+dht[24]*1

Using
lcdout $FE,$C0,"Humidity = ",#humid,"% " gives the humidity as a percentage.

Just trying to apply this to Richards code to get the same result

[Tabsoft]

Not using the DHT11 sensor, what is the temperature around your test rig?

[Tabsoft]

As I read the datasheet for the DHT11 a few of things jump out.
1. The resolution for the Humidity is 1%
2. The resolution for the Temperature is 1 degC.

The datastream is 40 bits long.
8bit integral RH data + 8bit decimal RH data + 8bit integral T data + 8bit decimal T data + 8bit check sum.
The algorithm you are implementing stores the bitstream into the dht array like this.
dht[4] = integral RH data
dht[3] = decimal RH data
dht[2] = integral T data
dht[1] = decimal T data
dht[0] = checksum

So the Hex data values you showed earlier "38 00 16 00 22" should be this
dht[0] = checksum = $38 (56 decimal) $00 + $16 + $00 + $22
dht[1] = decimal T data = $00 (this is the decimal portion of the Temperature, which will always be 0)
dht[2] = integral T data = $16 (22 decimal)
dht[3] = decimal RH data = 00 (this is the decimal portion of the Humidty, which will always be 0)
dht[4] = integral RH data = $22 (34 decimal)

I believe you do not need to perform any calculations to convert the RH data to a percentage.
That is what is giving you the strange results.
The calculation "#hum/10" is taking the hum variable and dividing it by 10.
The issue as I see it is that using the hum variable is not necessary and giving you the incorrect values.
PBP treats word variables as Little Endian numbers meaning the low order byte is stored first then the high order byte.
So when hum = _dht+3 and hum is declared as a word, PBP is looking at dht[3] & dht[4] as the word variable hum.
This would be $00 $22, but since we are looking at Little Endian numbers PBP will use dht[4] as the high byte and dht[3] as the low byte.
This makes hum = $2200 (8704 dec), which will result in 870 decimal when you divide 8704 by 10 and a result of 4 with 8704 // 10.
Making your output equal 870.4 as you say.

For the RH percentage you simply need to display the value in dht[4], something like this.
lcdout $FE, $94, dec dht[4], "%"
You do not need the ".",dec1 stuff since the DHT11 does not report a decimal place for RH or Temperature because of the resolution of the sensor.

As for the Temperature, if you are going to just use it as a Celsius number, there is no need for any calculation or conversion either.
Just simply display the value in dht[2]. E.g. lcdout $FE, $94, dec dht[2].

Hope this helps.

[richard]

looks like the dht11 only has a 8 bit range for rh an t so the display needs to be
LCDOut $FE,$94,"rh ",#hum/100
or
LCDOut $FE,$94,"rh ",#dht[4]

my fault I stopped reading the dht11 data sheet when I saw the 40 bit timings were the same as a dht22 , I have no dht11 to test with

[richard]

just an observation but the fineoffset wh1081 weather station that I have uses a dht11 and its readings vary greatly from those of the dht22 right next to it . somehow I think the dht11 is not very accurate

[Scampy]

Guys thanks for your continued input.

using the #hum/100 gives 87% as the value, which to me seems rather humid, especially when the indoor humidity according to my maplins weather station says it's 51%. As a comparison I tried the following code which uses the pause and pulsein statements to read the chip

ASM 
  __CONFIG    _CONFIG1H, _OSC_HS_1H
  __CONFIG    _CONFIG2L, _PWRT_ON_2L  
  __CONFIG    _CONFIG2H, _WDT_ON_2H & _WDTPS_512_2H
  __CONFIG    _CONFIG3H, _MCLRE_ON_3H & _LPT1OSC_OFF_3H & _PBADEN_OFF_3H  
  __CONFIG    _CONFIG4L, _LVP_OFF_4L & _XINST_OFF_4L
ENDASM


'*******************************************************************************
' LCD (20 x 4) set up
'*******************************************************************************

DEFINE LCD_DREG  PORTB                  ' LCD Data port
DEFINE LCD_DBIT  0                      ' starting Data bit (0 or 4)
DEFINE LCD_EREG  PORTB                  ' LCD Enable port
DEFINE LCD_EBIT  5                      '     Enable bit  (on EasyPIC 5 LCD)
DEFINE LCD_RSREG PORTB                  ' LCD Register Select port
DEFINE LCD_RSBIT 4                      '     Register Select bit   (on EasyPIC 5 LCD)
DEFINE LCD_BITS  4                      ' LCD bus size (4 or 8 bits)
DEFINE LCD_LINES 4                      ' number of lines on LCD
DEFINE LCD_COMMANDUS 2000               ' Command delay time in us 
DEFINE LCD_DATAUS 50                    ' Data delay time in us 

'*******************************************************************************
' Defines Statements
'*******************************************************************************

DEFINE  OSC 20                          ' 18F4520 / 18F2520, 20mhz crystal
ADCON1 = $0F
clear    

'*******************************************************************************
'Analog and Comparator settings
'*******************************************************************************

ADCON0 = %00000000                      'AD converter module disabled
ADCON1 = %00001111                      'All Digital
ADCON2 = %00000000
CMCON = 7                               'Disable Comparators

'*******************************************************************************
'Port and Register settings  (interrupts)
'*******************************************************************************
    
TRISA  = %00010111              
TRISB  = %00000011               
T0CON  = %11000111

T1CON = %00000001                               ; free-running, 1:1 prescaler
TMR1H = %11111111
TMR1L = %11111011


'*******************************************************************************

LCDOUT $FE,1:FLAGS=0:PAUSE 250:LCDOUT $FE,1:PAUSE 250 ' Initialize LCD

'*******************************************************************************

dht var byte[32]
humidite var byte
haut var byte
bas var byte
temp var byte
x var byte
dht11 var portA.1

'*******************************************************************************
start:
TRISA.1 = 0 '
high dht11
pause 2000 ' wait 2 sec
low dht11 : pause 18' send 20ms low
high dht11 : pauseus 30 ' send 40us hi
TRISA.1 = 0
PulsIn PORTA.1, 1, haut
if haut < 15 then goto start
for x = 31 to 0 step-1
PulsIn PORTA.1, 1, dht[x] ' 1
next x
For x = 31 to 0 step-1
if dht(x)>=9 and dht(x)<=21 then dht(x)=0 'if pulsewidth between 20 and 40uS then read as '0'
if dht(x)>=29 and dht(x)<=41 then dht(x)=1 'if pulsewidth between 60 and 80uS then read as '1'
next x
humidite=dht[31]*128+dht[30]*64+dht[29]*32+dht[28]*16+dht[27]*8+dht[26]*4+dht[25]*2+dht[24]*1
temp=dht[15]*128+ dht[14]*64+dht[13]*32+dht[12]*16+dht[11]*8+dht[10]*4+dht[9]*2+dht[8]*1
lcdout  $FE,1 
lcdout  $FE,$C0,"Humidite = ",#humidite,"% "
lcdout  $FE,$80,"Temperature = ",#temp,$DF,"C"
goto start

This gives 174c in our living room, with the humidity fluctuating between three values of 24%, 144% and 152%. Clearly there is something wrong with the hardware. I'm using a new solderless breadboard so I'll look at hard wiring the sensor and see if that helps, even though the connections between the Easypic board and sensor are next to each other

[Tabsoft]

Richard,

I don't think #hum/100 will give the correct result.
Since I. This example hum=8704 ($2200), 8704/100=87 ($57).

The correct result should be 34 ($22).
He just needs to use dht[4]
Or
To use a division calculation with hum it should be #hum/256.
This will right shift 8704 ($2200) 8 bits resulting in 34 ($22).

[Scampy]

Richard,

I don't think #hum/100 will give the correct result.
Since I. This example hum=8704 ($2200), 8704/100=87 ($57).

The correct result should be 34 ($22).
He just needs to use dht[4]
Or
To use a division calculation with hum it should be #hum/256.
This will right shift 8704 ($2200) 8 bits resulting in 34 ($22).

Dividing hum by 256 gives a reading of 35 on the LCD. The values for dht(1) to (5) are 39 00 16 00 23

I'm still not satisfied the sensor is working right, and this is the second one I've tried