Feuchtesensor liefert seltsame Werte.

Gast #3367911
Lesenswert?

Hallo Community,

ich habe da einen DHT22 Feuchtesensor den ich auslesen möchte. Die 
ersten "Versuche" funktionieren zwar soweit das überhaupt etwas 
angezeigt wird... allerdings sind die Werte mehr als merkwürdig.

Ausgangssituation:
- Atemga328p auf Olimex Starter-Board.
- DHT22 Sensor an VCC & GND. Sensorleitung angeschlossen an ICP1
- Meine Werte lasse ich mir zu testzwecken bis zur 14 "High-Flanke" auf
  einem LCD anzeigen.
- alle Variablen in / aus der ISR sind als static volatile uint16
  deklariert.
1
// ICP1 Konfiguration wird in meiner main einmalig aufgerufen
2
void Input_Capture_Init(void) // DHT22 ICP1 input configuration
3
{
4
  TCCR1B  |=  (1<<CS10) | (1<<CS11); // PreSc 64
5
  TIMSK1  |=  (1<<ICIE1) ; // Enable ICP1 interrupt
6
  TCCR1B  |=  (1<<ICES1); // ICP1 sensing rising edges
7
}
8

9

10
// Sensor Startsignal befindet sich in der main while Schleife
11
void DHT22StartSignal(void) // Start RHSensor
12
{
13
  if (timer3 == 150) // each 2 seconds
14
  {    
15
    DDRB  |=  (1<<PB0); // PB0 to Output
16
 
17
    PORTB &=~ (1<<PB0); // PB0 is LOW
18

19
    PORTB |=  (1<<PB0); // PB0 is HIGH  
20

21
    DDRB  &=~ (1<<PB0); // PB0 to Input
22
    PORTB |=  (1<<PB0); // turn On the Pull-up on ICP1
23
    timer3 = 0;       
24
  }
25
}
26

27
meine ISR an ICP1
28
ISR (TIMER1_CAPT_vect) // ICP1 sensing high edges for DHT22 Sensor
29
{  
30
  if (PinCount <= 13)
31
  {
32
  if (TCCR1B & (1<<ICES1)) // ICP1 sensing HIGH
33
   {
34
         HighEdge = ICR1;                   
35
    TCCR1B &=~ (1<<ICES1); // ICP1 set to sense LOW
36
  }
37
  else if (!(TCCR1B & (1<<ICES1))) // ICP1 sensing LOW
38
  {
39
     SignalHighWidth[PinCount] = ICR1 - HighEdge;
40
     TCCR1B |=  (1<<ICES1); // ICP1 set to sense HIGH
41
     PinCount++;
42
  }
43
  }
44
  else TIMSK1 &=~ (1<<ICIE1); // Disable ICP1 interrupt
45
}
Als Ausgabe erhalte ich auf dem LCD für die ersten 14 HIGH Pulslängen 
folgendes:
76 25 8 8 9 9 8 8 23 8 23 8 23 8

Wenn ich mich da nicht verrechnet haben sollte würde das in µs 
ausgedrückt
in etwa 24 7,8 2,5 2,5 2,8 etc... bedeuten.

Laut Datenblatt sollen 0en 26µs lang sein und 1en 70µs. Irgendwo is da 
doch der Wurm drin :/


"Falls" jemand sich die Mühe macht und mir sagen könnte ob denn meine 
grundsätzliche Überlegung richtig bzw. falsch ist wäre ich sehr dankbar.



Gruß & Danke
µc
Gast #3367975
Lesenswert?

Sorry die wichtigsten Infos habe ich vergessen..

- getaktet ist der Atmega über nen externen 20Mhz Quartz
- laut Datenblatt werden vom DHT22 Feuchtesensor 40bit Daten NACH dem
  Startsignal geschickt. Die Daten kommen als High Signal am ICP1 an.
  Anhand der High-Länge werden Nullen & Einsen erkannt. Ist das 
Highsignal
  26µs lang ist es eine Null. Bei einem Highsignal von 70µs ist es eine 
1.
- Ich werte testweise nur die ersten eingehenden 14bit (High-Signale) 
aus.
  Von diesen ersten 14bit stammen die ersten beiden Highsignale aus 
meiner
  DHT22StartSignal() Funktion.
- es verblieben also 12 "bits" in denen die ersten 8 bit sein sollten 
die
  laut Datenblatt zum Feuchtegehalt gehören.


Gruß
µC
#3368412
Lesenswert?

µC schrieb:


> Als Ausgabe erhalte ich auf dem LCD für die ersten 14 HIGH Pulslängen
> folgendes:
> 76 25 8 8 9 9 8 8 23 8 23 8 23 8
>
> Wenn ich mich da nicht verrechnet haben sollte

Du hast dich verrechnet

> würde das in µs
> ausgedrückt
> in etwa 24 7,8 2,5 2,5 2,8 etc... bedeuten.
>
> Laut Datenblatt sollen 0en 26µs lang sein und 1en 70µs.

Deine gemessenen Werte passen sogar ziemlich gut
Gast #3368608
Lesenswert?

Hallo KHB,

erstmal Danke das Du geantwortet hast... Hatte schon die Befürchtung das 
der Beitrag von mir dann doch ZU unübersichtlich ist.

Ich komme leider nicht wirklich auf meinen Rechenfehler.. Kannst Du mir 
da irgendwie weiterhelfen?


Gruß & Danke
µC
#3368620
Lesenswert?

µC schrieb:

> Ich komme leider nicht wirklich auf meinen Rechenfehler.. Kannst Du mir
> da irgendwie weiterhelfen?

Bei 20Mhz und einem Vorteiler von 64, dauert 1 Timertick wie lange?
1
20000000 / 64 =  312500   <- das ist die effektive Zählrate des Timers
2

3
1 Tick dauert daher  1 / 312500 = 0.0000032 Sekunden
Jetzt hast du aber nicht 1 Timertick gemessen, sondern zb 23. Die dauern 
daher wie lange?
1
23 * 0.0000032 = 0.0000736
das sind 73.6µs. Passt recht gut zu den vorgegebenen 70µs

Du hast auch 8 Timerticks gemessen. Das sind dann
1
8 * 0.0000032 = 0.0000256
oder eben 25.6µs, was wiederrum recht gut zu den 26µs aus der Vorgabe 
passt. Das die Zahlen nicht ganz stimmen - geschenkt - bei einem 
Vorteiler von 64 ist das auch nicht zu erwarten.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren