Übersetzungen dieser Seite:

Contiki-3.0 AVR Optimierung

Da in den letzten Jahren die AVR Plattform im Contiki-OS nicht die höchste Priorität hatte, haben sich einige Proleme mit dem Contki Mac Layer eingeschlichen. (Stand 17. Oktober 2016)

Software: Contiki-OS Branch: Master b8d753d35ec4c2bbc05ace2aa0615ddaff0bb394

Software: OSD-Contiki Branch: Master 47760c57e60115852ff7dbb48d4d5197abef1701

Ziel

Das Merkurboard soll mit 2x AA Batterien (3Ah) mindestens 1 Jahr betrieben werden können. Als Referenz wird wird das Beispiel Arduino-Merkurboard gewählt.

Software: OSD-Contiki Branch: Master

Stromverbrauch

Der Stromverbruch wird mit einem Agilent U1272A mit Hilfe der Avarage Funktion gemessen. Die Messdauer beträgt 15 min.

Versuch 1:

  • Contiki MAC Layer ON
  • CPU Sleep ON
  • Enable always 2sec → 1/8s CPU ON (16)
  • Routing Node ON
  • Dutycycle 8 Hz
  • Debug Serielle ON

Merkurboard ATmega256rfr2

Stromverbrauch: 539uA

Das entspricht bei 3Ah Batterien einer Laufzeit von 5566 Stunden also 231 Tagen oder 7,7 Monate

Merkurboard ATmega128rfa1

Stromverbrauch: 550uA

Das entspricht bei 3Ah Batterien einer Laufzeit von 5405 Stunden also 225 Tagen oder 7,3 Monate

  • Contiki MAC Layer ON
  • CPU Sleep ON
  • Enable always 3sec → 1/8s CPU ON (24)
  • Routing Node ON
  • Dutycycle 8 Hz
  • Debug Serielle ON

Merkurboard ATmega256rfr2

Stromverbrauch: ?uA

Das entspricht bei 3Ah Batterien einer Laufzeit von ? Stunden also ? Tagen oder ? Monate

Merkurboard ATmega128rfa1

Stromverbrauch: 443uA

Das entspricht bei 3Ah Batterien einer Laufzeit von 6772 Stunden also 282 Tagen oder 9,4 Monate

  • Contiki MAC Layer ON
  • CPU Sleep ON
  • Enable always 4sec → 1/8s CPU ON (32)
  • Routing Node ON
  • Dutycycle 8 Hz
  • Debug Serielle ON

Merkurboard ATmega256rfr2

Stromverbrauch: ?uA

Das entspricht bei 3Ah Batterien einer Laufzeit von ? Stunden also ? Tagen oder ? Monate

Merkurboard ATmega128rfa1

Stromverbrauch: 404uA

Das entspricht bei 3Ah Batterien einer Laufzeit von 7426 Stunden also 309 Tagen oder 10,3 Monate

  • Contiki MAC Layer ON
  • CPU Sleep ON
  • Enable always 5sec → 1/8s CPU ON (40)
  • Routing Node ON
  • Dutycycle 8 Hz
  • Debug Serielle ON

Merkurboard ATmega256rfr2

Stromverbrauch: ?uA

Das entspricht bei 3Ah Batterien einer Laufzeit von ? Stunden also ? Tagen oder ? Monate

Merkurboard ATmega128rfa1

Stromverbrauch: 368uA

Das entspricht bei 3Ah Batterien einer Laufzeit von 8152 Stunden also 339 Tagen oder 11,3 Monate

  • Contiki MAC Layer ON
  • CPU Sleep ON
  • Enable always 6sec → 1/8s CPU ON (48)
  • Routing Node ON
  • Dutycycle 8 Hz
  • Debug Serielle ON

Merkurboard ATmega256rfr2

Stromverbrauch: ?uA

Das entspricht bei 3Ah Batterien einer Laufzeit von ? Stunden also ? Tagen oder ? Monate

Merkurboard ATmega128rfa1

Stromverbrauch: 337uA

Das entspricht bei 3Ah Batterien einer Laufzeit von 8902 Stunden also 370 Tagen oder 12,36 Monate

Versuch 2:

  • Contiki MAC Layer ON
  • CPU Sleep ON
  • Always 2sec → 1/8s CPU wakeup OFF
  • Routing Node ON
  • Dutycycle 8 Hz
  • Debug Serielle ON

Achtung: Dieser Mode ist gefährlich und nur dann empfehlenswert wenn alle Berechnungen in der Coap Resource abgehandelt werden.

Merkurboard ATmega256rfr2

Stromverbrauch: 235uA

Das entspricht bei 3Ah Batterien einer Laufzeit von 12766 Stunden also 532 Tagen oder 17,7 Monate also 1,48 Jahre

Merkurboard ATmega128rfa1

Stromverbrauch: 237uA

Das entspricht bei 3Ah Batterien einer Laufzeit von 12658 Stunden also 527 Tagen oder 17 Monate also 1,47 Jahre

Bugfixes

Die Sleepzeit im Dutycycle wird falsch berechnet. Dadurch wird in einem zufälligem Raster nach einem Sendesignal gesucht und nicht im gewünschtem Raster 1/8 Hz

contikimac.c

Zeile 506

      static uint8_t sleepcycle;
      if((sleepcycle++ < 16) && !we_are_sending && !radio_is_on) {
--        rtimer_arch_sleep(RTIMER_NOW() - cycle_start);
++        rtimer_arch_sleep(cycle_start - RTIMER_NOW());
      } else {
        sleepcycle = 0;
        schedule_powercycle_fixed(t, cycle_start);
        PT_YIELD(&pt);
      }

Nach längeren Sleep Zyklen kommt das System durcheinander. Nach Entfernung der Codezeilen funktioniert es.

Zeile 482:

      if(NETSTACK_RADIO.pending_packet()) {
          break;
        }

--        schedule_powercycle(t, CCA_CHECK_TIME + CCA_SLEEP_TIME);
--        PT_YIELD(&pt);
++        schedule_powercycle(t, CCA_CHECK_TIME + CCA_SLEEP_TIME);
++        PT_YIELD(&pt);
      }
      if(radio_is_on) {
        if(!(NETSTACK_RADIO.receiving_packet() ||
             NETSTACK_RADIO.pending_packet()) ||

Deaktivieren von Fastsleep (gehört nochmals überprüft)

Fastsleep ist ein Mechanismus von ContikiMac, um das Funkmodul noch schneller schlafen zu legen, wenn keine, für die Sensor-Node, relevanten Daten empfangen werden. Fastsleep lässt sich deaktivieren, in dem man die Zeile #define WITH_FAST_SLEEP 0 in der Datei platform/osd-merkur-128/contiki-conf.h und platform/osd-merkur-128/contiki-conf.h einfügt.

Anpassen der Konstante RF230_CONF_CCA_THRES

Ohne Änderungen im Code, prüft Contiki anhand eines Schwellwerts, ob es Daten zu empfangen gibt. Dieser Schwellwert kann über die Konstante RF230_CONF_CCA_THRES angepasst werden. Die Konstante ist standardmäßig nicht gesetzt, dann wird -77 für den Wer der Konstante angenommen (siehe Code der Funktion rf230_cca() in cpu/avr/radio/rf230bb/rf230bb.c). Die Konstante wurde mit dem Wert -90 in der Datei project-konf.h der Sensor-Node definiert. Das Ergebnis der Tests fiel danach viel besser aus

Überschrift


de/projekte/contiki3-avr-optimierung.txt · Zuletzt geändert: 2016/10/18 11:14 von harald42