pulseIn(pin, HIGH) liefert 0

[miq19]

Ich hätte da gerne mal wieder etwas Unterstützung...

Ich lese mit einem ESP8285 in einer Steckdose einen Strommesschip vom Typ BL-0937 aus. Der gibt Strom und Spannung in Form einer Pulslänge an einem Pin aus. Laut Datenblatt (PDF) wird dabei immer ein HIGH-Puls von 38µs und darauf folgend ein LOW-Puls variabler Länge gesendet. Aus der Summe ergibt sich eine Frequenz (1/Zeit), die dann Volt oder Ampere angibt.

Ich lese bisher die LOW-Zeit mit 'pulseIn(CF_PIN, LOW, 1000000);', addiere die 38 darauf und arbeite damit weiter. Das klappt eigentlich, nur sind mir dabei Differenzen zwischen verschiedenen BL-0937 aufgefallen, zum Beispiel liegt die Spannung an der selben Leitung bei einem Chip bei 230V, bei einem anderen aber bei 217V, der dritte zeigt 222V usw.

Jetzt wollte ich mal messen, ob der HIGH-Puls wirklich bei allen 38µs lang ist und habe mir diese Funktion geschrieben:

Code:

unsigned long int getHighPulseLength() {
  const uint8_t repeats(20);
  uint8_t cnt = 0;
  unsigned long int pls = 0;
  unsigned long int tmp = 0;

  for (uint8_t i = 0; i < repeats; ++i) {
    pls = pulseIn(CF_PIN, HIGH, 1000000);
    if (pls) {
      tmp += pls;
      cnt++;
    }
  }
  if (cnt) {
    return tmp / cnt;
  } else {
    return 0;
  }
}

Jetzt liefert die immer 0, und ich verstehe nicht, warum.

Bei 230V ist die Pulslänge laut Specs ca. 690µs inkl. der 38µs. Wenn ich also sogar bis zu 1000000µs beim pulseIn() warte, müsste mindestens ein Puls zu finden sein.

Da die Leserei des LOW-Pulses im Prinzip ja funktioniert, MUSS ein HIGH-Puls vorbeigekommen sein, sonst könnte man ihn ja gar nicht bestimmen.

Verstehe ich pulseIn() vielleicht nicht richtig?

[biologist]

Bin mir nicht ganz sicher aber vermute, dass du den return-Wert casten muss.

[miq19]

(14.01.2021 14:40)biologist schrieb:  Bin mir nicht ganz sicher aber vermute, dass du den return-Wert casten muss.

Bringt leider nichts, habe ich gerade versucht.

Ich habe auch mal eine Variante mit Zählen der HIGH-Impulse in einer vogegebenen Zeit versucht, á la

Code:

volatile unsigned long int tick;
void cntTick() { tick++; }
...
setup() {
...
  attachInterrupt(digitalPinToInterrupt(CF1_PIN), cntTick, RISING);
...
unsigned long int getHighTicks() {
  unsigned long int pls = 0;

  cli();
  tick = 0;
  sei();
  // count for 100 msec
  delay(100);
  cli();
  unsigned long pls = cnt;
  sei();
  return pls;
}

Das crasht leider schon beim 'attachInterrupt()'...

[Tommy56]

Die ISR muss in einem speziellen Speicherbereich liegen.
Zumindest für den 8285 kann ich nur vermuten, dass der wie der 8286 angesprochen wird.

Gruß Tommy

[miq19]

(14.01.2021 15:10)Tommy56 schrieb:  Die ISR muss in einem speziellen Speicherbereich liegen.
Zumindest für den 8285 kann ich nur vermuten, dass der wie der 8286 angesprochen wird.

Gruß Tommy

Danke! Das lässt zumindest den Interrupt ohne Absturz laufen. Will mal sehen, wohin ich damit komme...

[miq19]

Ich bekomme jetzt die gleichen gestreuten Ergebnisse wie vorher mit pulseIn(), was auf einen Grund in der Beschaltung des BL0937 hindeuten würde. Da sind Spannungsteiler vorgeschaltet, für die Spannungsmessung z.B. (2 * 1MOhm) / 1kOhm. Ich vermute mal, dass die Chinaware, die ich da vor mir habe, keinen besonderen Wert auf Genauigkeit der verwendeten Widerstände legt und es deshalb da Varianz gibt. Isso.

[Tommy56]

Wenn es nur das Widerstandsverhältnis ist, dann ist der Fehler konstant und Du kannst ihn exemplarabhängig rausrechnen.

Gruß Tommy

[miq19]

(14.01.2021 16:34)Tommy56 schrieb:  Wenn es nur das Widerstandsverhältnis ist, dann ist der Fehler konstant und Du kannst ihn exemplarabhängig rausrechnen.

Gruß Tommy

Ja, davon gehe ich aus.

Danke!