Inhaltsverzeichnis
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
Links:
Ping-Tests mit Contiki 3.0 und aktiviertem ContikiMAC
