Det där med coolheten var ironiskt, men å andra sidan så kan man inte säga bara för att man själv känner till en sak att alla andra också känner till den.
Att watchdoggen i en övrigt nedstängd pic mång-mång-mångdubblar strömförbrukningen är nog inte allmännt känt skulle jag tro. Jag tittade på ett 628 datasheet jag hade på burken jag sitter vid och "base current" är 20 nA och deltat för wdt påslaget är 9 uA. Det ör 450 ggr skillnad (under förutsättning att resten av cpu'n är avstängt och inga strömtjuvar finns på utportarna)
Om du är nöjd med din strömförbrukning som du har i dag så är ju allt jättebra. Det finns då ingen anledning att försöka pilllra pillra bort ännu mer förbrukning. Det är minst lika viktigt att veta när man ska _sluta_ optimera något som att veta _hur_ man optimerar det.
Nu har jag ingen aning om vilka radiomoduler du använder och hur lång uppstartstid du har på dom och om du även ska ta emot nåt från den andra sidn ifall ett utsänt paket har försvunnit på vägen eller inte. Men rent instinktivt låter det lite kort med 10 mS för att starta en radiomodul från scratch , låta den stabilisera sig och sända ett meddelande. Men det kanske fungerar - the datasheet knows the truth . förhoppningsvis.
Sleep mode på en PIC 16F628 - *Fungerar*
Utan WDT så måste det till någon extern "wake-krets", och den strömmen
måste läggas till.
Sen är det intressant att se ett en nanoWatt processor (F88 i detta fall)
ligger på ca 35 uA vid 32Khz INTOSC, d.v.s *utan* att använda SLEEP.
Att jämföra med 9 uA i SLEEP med WDT igång på F628. Inte så
jäkla stor skillnad. Och då har man processorn igång och kan
reagera i real-tid om det händer något oförutsätt.
Man kan direkt i koden switcha mellan 32 Khz och "full fart" (vilket inte
måste vara 8 Mhz, utan bara tillräckligt snabbt för att hantera sensorer
och RF modul).
Man kan även switcha processorn till 32Khz så snart den väntar på
t.ex svar från en sensor eller "uppstart" av RF modulen, alltså
oftare än vad man annars hade kört SLEEP. Processorn behöver
så att säga inte "vänta" i full fart...
Sen är det precis som matseng säger, det finns en gräns där vidare
trimning mest är av akademiskt intresse (men minst lika roligt!)...
måste läggas till.
Sen är det intressant att se ett en nanoWatt processor (F88 i detta fall)
ligger på ca 35 uA vid 32Khz INTOSC, d.v.s *utan* att använda SLEEP.
Att jämföra med 9 uA i SLEEP med WDT igång på F628. Inte så
jäkla stor skillnad. Och då har man processorn igång och kan
reagera i real-tid om det händer något oförutsätt.
Man kan direkt i koden switcha mellan 32 Khz och "full fart" (vilket inte
måste vara 8 Mhz, utan bara tillräckligt snabbt för att hantera sensorer
och RF modul).
Man kan även switcha processorn till 32Khz så snart den väntar på
t.ex svar från en sensor eller "uppstart" av RF modulen, alltså
oftare än vad man annars hade kört SLEEP. Processorn behöver
så att säga inte "vänta" i full fart...
Sen är det precis som matseng säger, det finns en gräns där vidare
trimning mest är av akademiskt intresse (men minst lika roligt!)...
Ja det råder ju inget tvivel om att det finns lämpligare PIC att välja till ett batteridrivet projekt som detta.
Jag har räknat lite på förbrukningen och om jag använder mig av exempelvis 1800mAh batterier så kan jag teoretiskt köra PIC med RF och tempsensor SMT160-30 i många dygn (fick det till 14 dygn under ideala förhållanden) utan sleep läge innan batterierna är helt slut.
Om jag däremot låter PIC sova och vakna vid 2 min intervaller så lär det bli många veckors drift på det hela.
Detta är ju en bra bit bättre än mina förväntningar!
För att trimma ännu mer (gillar att optimera
)så funderar jag på att låta temp övervakningen logga värde i minnet och sedan sända över dem via RF var 15-30 minut istället. 
Jag har räknat lite på förbrukningen och om jag använder mig av exempelvis 1800mAh batterier så kan jag teoretiskt köra PIC med RF och tempsensor SMT160-30 i många dygn (fick det till 14 dygn under ideala förhållanden) utan sleep läge innan batterierna är helt slut.
Om jag däremot låter PIC sova och vakna vid 2 min intervaller så lär det bli många veckors drift på det hela.
Detta är ju en bra bit bättre än mina förväntningar!
För att trimma ännu mer (gillar att optimera
)så funderar jag på att låta temp övervakningen logga värde i minnet och sedan sända över dem via RF var 15-30 minut istället. 
