Serial Comms and Crystals

[richard]

expected dht response to start signal

[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

[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).