Ultralowpower Wireless Temperatur Sensor Attiny85 oder 328?

International Deutsch
1

Hallo zusammen

Ich bin gerade dabei kleine Funksensoren zu konstruieren. Wichtig ist mir dabei vor allem, dass sie mit Akku >1Jahr laufen und die Daten per Funk versenden.

Als Funkmodule nutze ich die nRF24L01+, da günstig und extrem Sparsam im PowerDown Modus (900nA).
Als Stromquelle soll ein 18650 Akku zum Einsatz kommen, da relativ kompakt und hoffentlich mit >2Ah mehr als genügend Saft...

Als TemperaturSensor nutze ich einen DHT22, ev. wird es noch Sensoren geben die mit DS18b20 laufen, da Hydrometer nicht benötigt wird.

Den Code für die Übertragung steht bereits, es werden aktuell 6Bytes übertragen
-> byte 1 = sensorID byte2 = sensorTyp byte3 = sensor1byte1 byte4= sensor1byte2, byte4 = sensor2byte1, byte 5 = sensor2byte2, byte6 = 0xFF, da der RF24 das letzte byte irgend wie immer nur "halb" empfängt".

Soweit so gut.

Nun stellten sich mir aber ein paar Fragen. Eigentlich habe ich für das Projekt extra Attiny85 uCs gekauft, da diese extrem wenig Strom brauchen im PowerDown Modus. Mit dem RF24 + DHT22 bin ich aber schon am ende mit den IOs und könnte die Sensoren so später nicht noch erweitern um z.B. einen Taster zustand zu übermitteln.

Durch recherchen habe ich nun herausbekommen, dass man auch einen Atmega 328 mit ca. 1uA betreiben kann im PowerDown Modus. Das würde wohl locker für ein Jahr reichen mit einem 18650 Akku, da die Daten eh maximal 1x pro Minute übertragen werden sollen.
Der Vorteil am 328er liegt halt darin, dass man viel mehr IOs hat und später auch noch ein Taster oder ev. Display anschliessen könnte für gewisse Sensoren und die RF24 Lib, sowie DHT22 läuft darauf natürlich schon 1A und man müsste nicht alles von "vorne" bauen.

Bei den Tests die ich gefunden habe die mit <1uA liefern war der Atmega immer im 8Mhz Modus mit 3.3V betrieben. Ich konnte aber nicht ausfindig machen wie weit nach oben man mit der Spannung da maximal gehen kann. Kann so ein 18650 mit Max 4.2V angeschlossen werden oder ist das schon zu viel wenn man den uC im 8Mhz Modus laufen lässt? Einen StepDown möchte ich unbedingt vermeiden da einfach viel zu viel verbrauch...
Für das RF24 Modul brauch ich aber eh zwingend <3.5V, somit werde ich zwischen RF24 und Batterie wohl eine Diode anbringen, aber nur für den RF24.

Was meint ihr Macht es Sinn einen Atmega328 zu verwenden oder sollte ich das ganze doch mit dem Attiny umsetzen?

2

Du hast Dir die Antwort eigentlich selbst gegeben: nimm den 328 weil Du sonst zu wenig IOs hast.
Der läuft auch mit 4,2 Volt, das ist nicht das Problem. Alles schlafen zu legen ist da die höhere Hürde.

3

aargau:
Ich konnte aber nicht ausfindig machen wie weit nach oben man mit der Spannung da maximal gehen kann.

Eine höhere Spannung bei einer bestimmten Frequenz ist kein Problem. Generell geht es da eher darum die maximale Frequenz für eine bestimmte Spannung zu finden oder die minimale Spannung für eine Frequenz.

Siehe auch hier:

4

Serenifly:
Eine höhere Spannung bei einer bestimmten Frequenz ist kein Problem. Generell geht es da eher darum die maximale Frequenz für eine bestimmte Spannung zu finden oder die minimale Spannung für eine Frequenz.

Siehe auch hier:
Gammon Forum : Electronics : Microprocessors : Power saving techniques for microprocessors

Die Seite scheint allgemein ziemlich informativ zu sein, auch wie man den tiefen Verbrauch erreicht, muss ich mir gleich bookmarken und genauer durchlesen.

Klaus_ww:
Du hast Dir die Antwort eigentlich selbst gegeben: nimm den 328 weil Du sonst zu wenig IOs hast.
Der läuft auch mit 4,2 Volt, das ist nicht das Problem. Alles schlafen zu legen ist da die höhere Hürde.

Okay, wenn das mit der Spannung kein Problem ist, dann werde ich das wohl so versuchen, werde da eh erst Messungen machen müssen um zu sehen wie es aussieht. Der Attiny ist halt einfach eh etwas schwieriger, auch zum Entwickeln und Debuggen da kein HW Serial vorhanden.

Der 328 bringt wohl wirklich "nur" Vorteile, dann habe ich mehr als genug IOs um das ganze später auch noch zu erweitern.

Überlege mir gerade wie ich die Übertragung am besten anpasse um später nicht wieder alle Sensoren neu flashen zu müssen wenn ich mal noch "mehr" Daten übertragen möchte.

Meine 1. Idee wäre gewesen max 8Byte, aber unabhängig "was" übertragen wird:

Byte1 = NodeID

Byte2 = SensorTyp
Byte3 = SensorByte1
Byte4 = SensorByte2

Byte5 = SensorTyp
Byte6 = SensorByte1
Byte7 = SensorByte2

Byte8 = 0xFF

So könnte man auch mal nur ein Sensor übertragen und die restlichen Bytes einfach Leer lassen, da die Auswertung auf der anderen Seite anhand des SensorTyp gemacht wird, also z.b. 0x01 für Temperatur 0x02 für Hydro, 0x03 für Spannung oder was auch immer.

Oder gibt es da ev. bessere Ansätze um das ganze "Zukunftssicher" zu übertragen?

5

Meine 1. Idee wäre gewesen max 8Byte, aber unabhängig "was" übertragen wird:

...
Byte 8 : FF

Wenn du schon kein Parity bit spendieren willst, mach wenigstens eine checksumme ans Ende.

Deine Beobachtung, dass das letzte Byte vermurkst ist ("da der RF24 das letzte byte irgend wie immer nur "halb" empfängt") wundert mich übrigens. Legt der Sender sich schon schlafen, bevor er fertig ist ?

aargau:
Wichtig ist mir dabei vor allem, dass sie mit Akku >1Jahr laufen ...

Dumme Frage:
Gibt es inzwischen Akkus mit so geringer Selbstentladung, dass sie >1 Jahr halten ?

6

Dumme Frage:
Gibt es inzwischen Akkus mit so geringer Selbstentladung, dass sie >1 Jahr halten ?

Litium-Ionen-Akkus haben heute bei 20°C eine Selbstentladung < 2% pro Monat

7

Ich verstehe aber trotzdem nicht wieso Du einen Akku nehmen willst und nicht eine Batterie.
Grüße Uwe

8

Naja bei den Batterien ist die Spannung halt etwas problematisch. Wenn ich zwei AA oder AAA Batterien nehme habe ich zwar die 3V, aber die dürften ja dann recht schnell sinken und somit ggf. für den Arduino schon recht knapp werden. Eine 18650 Zelle hat halt immer mehr als genug Spannung bzw. ist schon "tot" bevor sich der uC verabschieded.

@michael_x: Checksumme sollte es ja nicht brauchen, die RF24 Module sollten doch selber die Pakete prüfen und wenn was korrupt ist kommt ein neuer Sendeversuch.
Da der Empfänger das Paket ja mittels Ack bestätigt kann ich mir leider ein zu frühes schlafen auch nicht vorstellen. Anstelle von 8Bit (1111 1111) erhalte ich jeweils nur 4Bit 1111 zurück. Ich vernwende die RF24 Lib, mit originalem Code scheint nichts verloren zu gehen, auch nicht wenn ich nur ein float übertrage... Kann es mir irgend wie auch nicht erklären was da falsch läuft.

9

die RF24 Module sollten doch selber die Pakete prüfen und wenn was korrupt ist kommt ein neuer Sendeversuch.

Und wo kommt dann ein halbes Byte als geprüft her ?
Ich bin ja Laie, aber was ich jetzt über RF24 gelesen habe, sagt mir, dass nur ganze Bytes übertragen werden können? Ansonsten hast du natürlich recht...

10

Ich kann es mir auch nicht erklären, irgend wo wird das teil wohl verschluckt, nicht richtig gespeichert oder beim senden oder empfangen nicht verarabeitet. Ich habe eigentlich nur das beispiel Script angepasst und nichts komplett neu erfunden.

Sieht so aus:

Sender:

  radio.setRetries(15,15);
  radio.setChannel(10) ;
  radio.setPayloadSize(8) ;
  radio.setDataRate( RF24_250KBPS ) ; 
// ... loop: 
radio.powerUp() ; 
sendData() ; 
delay(10000 ) ; 
// sendData():
 uint8_t sData[6] ;

  // Sensor auslesen
  if (dht.read())
  {
  bool ok = radio.write( &sData, sizeof(sData) );

    if (ok)
      Serial.print("OK \t") ;
    else
      Serial.print("Failed :-( \t") ;

    int i;
    for (i = 0; i < 7; i = i + 1) {
      Serial.print(sData[i], BIN);
      Serial.print("*") ;
    }
    Serial.println() ;
  } else   {
    Serial.print("error" ) ;
  }
}

Empfänger:

//... loop:
uint8_t sData[6] ;
 
    if ( radio.available() )
    {

      bool done = false;
      while (!done)
      {
        done = radio.read( &sData, sizeof(sData) );
	delay(20);
      }

int i;
for (i = 0; i < 7; i = i + 1) {
  Serial.print(sData[i],BIN);
  Serial.print(" ") ; 
}
     Serial.println() ; 

    }

Edit: Auf dem Sender wirft Serial die Bits korrekt aus

11

Müssten die nicht zumindest gleichgroß sein?

radio.setPayloadSize(8);     !=      uint8_t sData[6];