Entwicklung: Temperatur Funk Sensor

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Hast Du da irgeneine Vorkehrung getroffen, dass es bei Dir nicht zu solchen Überschneidungen kommen kann?

    Nein, das machen die RFM Module selber bzw die Sender nutzen ja RFM12B-Lib und da ist das zB über CanSend geregelt dass diese erst etwas los schicken wenn ihre Frequenz frei ist ;)

    Außerdem wird ja die jeweilige NodeID übermittelt und ggf ein ACK angefordert, also ob das gesendete Paket ankam. Der Empfänger greift sich dann nur das Datenpaket von der jeweilige NodeID, ein anderer Sender kann da aufgrund der RFM12B-Lib nicht zwischen funken.

  • Hi,


    ... und da ist das zB über CanSend geregelt dass diese erst etwas los schicken wenn ihre Frequenz frei ist ;)


    naja, das ist jetzt nicht ganz so. CanSend() prüft lediglich den Transmitter-Status.
    Ob die Frequenz frei ist, kann scheinbar nicht überprüft werden ... das war der Grund meiner Frage ;)


    ... Paket ankam. Der Empfänger greift sich dann nur das Datenpaket von der jeweilige NodeID, ein anderer Sender kann da aufgrund der RFM12B-Lib nicht zwischen funken.


    Also auch nichts weiter als die NodeId (ich nehm halt den magic Code) und den CRC. Stimmt - den habe ich noch nicht mit einbezogen, weil mich erst mal interessiert hat, ob ein Mischen der Pakete überhaupt vorkommen kann. Kann es dann wohl ...
    Ich hatte gedacht, Du hättest da evtl. noch eine weitere zündende Idee gehabt.
    Also ... konventionell lösen

    //EDIT: Fiel mir grad noch ein: es gäbe noch die Möglichkeit, mit isCarrier() auf ein Trägersignal zu prüfen. Aber ob das was bringt :s ...
    Nun, gehört schon nicht mehr hierher ... an anderer Stelle dann mehr zum nrf24L01.


    danke erst mal,
    cheers,
    -ds-

  • Nur nochmal eine kurze Rückmeldung bezüglich des Stromverbrauchs:

    - Originaler Sketch von der Startseite: um die 2mA
    - Sketch mit Watchdog: ~ 1,02mA
    - deine überarbeitete Variante (vor dem edit): ~10-12uA
    - nach dem edit: ~4-6uA

    Bitte beachten das ich das mit einem sehr einfachen Multimeter gemessen habe. Dieses zeigt auch nur Werte mit > 1uA +-1% an. Die Werte sind also nicht besonders genau und noch evtl. von weiteren Faktoren wie Toleranz der Bauteile usw. abhängig (und wie sauber ich gelötet hab ;)
    Sie dienen aber auf jeden Fall zur groben Orientierung.

    Vg Andreas

    Einmal editiert, zuletzt von fliesrod (15. Dezember 2014 um 22:03)

  • falls wer die serielle Schnittstelle mit Python lesen möchte...


  • falls wer die serielle Schnittstelle mit Python lesen möchte...

    Wie viel CPU Last wird denn durch deine Variante des Scripts erzeugt?
    (bin unterwegs, kann das nicht testen)

    Der sleep am Ende der Schleife ist aber auch ungünstig - was ist wenn genau in dieser Zeit etwas geschickt wird?

    Auch finde ich fehlen da ein paar Checks, um zB sicher zu stellen das der Port auch geöffnet werden konnte usw

    Klar kann man das so machen - Ich würde das aber lieber wie folgt machen:
    (ungetestet!)

    Spoiler anzeigen

    Das beachtet auch den von meiner add.php erwarteten SecretKey usw und sollte sehr wenig CPU Last erzeugen

    Ungetestet!

  • das funktioniert nicht:

    Code
    data = UART.read(1)          # read one, blocking
    n = UART.inWaiting()         # look if there is more
    if n:
       data = data + UART.read(n) # and get as much as possible


    es wird nicht alles gelesen, das z.B.

    Zitat


    &t=2206


    wird abgeschnitten.

    also das soll abgesendet werden:

    Code
    GET /add?key=23338d373027ce83b1f81b9e9563b629&id=1&v=3019&t=2206


    aber nur das wird ausgelesen:

    Code
    GET /add?key=23338d373027ce83b1f81b9e9563b629&id=1&v=3019


    als würde es auf dieses kaumännische UND reagieren. ich habe es nciht rausgefunden warum das so ist...

    wenn man die 4 Zeilen von oben mit:

    Code
    data = UART.readline()


    ersetzt dann wird alles ausgelesen.

    Habe keine Ahnung von seriellen Schnittstelle...

    Einmal editiert, zuletzt von keulemaster (19. Dezember 2014 um 18:04)

  • :denker: Hm, beim ESP8266 Projekt hat das so problemlos funktioniert :s

    Vielleicht liegt das an der niedrigen Baudrate.. Vielleicht würds schon reichen UART.timeout auf 2 zu stellen, oder noch ein sleep(1) vor dem inWaiting() einzufügen um sicher zu gehen das der Buffer voll genug is :fies:

    Ggf. funktionierts auch wenn man

    Code
    data = UART.read(1)          # read one, blocking
    n = UART.inWaiting()         # look if there is more
    if n:
       data = data + UART.read(n) # and get as much as possible


    so abändern:

    Code
    data = UART.read(1)          # read one, blocking
    n = UART.inWaiting()         # look if there is more
    if n:
       data += UART.read(n) # and get as much as possible


    ...muss ich mal genauer testen wenn ich wieder Zuhause bin...

    Danke fürs Feedback :thumbs1:

  • @alle die sich auskennen :)

    Kann ich mit dieser Platine genau das gleiche machen/programmieren wie bei den hier selbstgebauten? Ich habe leider zuwenig davon gekauft, jetzt ist mir der Aufwand zu hoch wegen 3 Platinen alles zuzukaufen.

    Lol, habe den Link vergessen :;

    http://www.digitalsmarties.net/products/rfm12b-board

    Using Tapatalk

    Einmal editiert, zuletzt von kenci (23. Dezember 2014 um 21:33)


  • meigrafd,

    Danke für den Hinweis. Ich habe mir auch mal zwei von den Sensoren bestellt und gestern bekommen. Ich habe die heute einfach mal analog getestet. Als Sketch habe ich einfach den Sketch den ich bei meinen Bodefeuchtesensoren (Ursprung TMP36 Sketch) verwendet.

    Ich lasse mir jedoch die Daten immer "roh" senden und machen die Auswertungen erst am Empfänger.

    Spoiler anzeigen

    [code=php]
    //----------------------------------------------------------------------------------------------------------------------
    // TinyTX_TMP36 - An ATtiny84 and RFM12B Wireless Temperature Sensor Node
    // By Nathan Chantrell. For hardware design see http://nathan.chantrell.net/tinytx
    //
    // **IMPORTANT** Note that the TMP36 must be fitted in the REVERSE orientation compared to the DS18B20
    // and do not fit a resistor
    //
    // Using the Analog Devices TMP36 temperature sensor
    //
    // Licenced under the Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) licence:
    // http://creativecommons.org/licenses/by-sa/3.0/
    //
    // Requires Arduino IDE with arduino-tiny core: http://code.google.com/p/arduino-tiny/
    //----------------------------------------------------------------------------------------------------------------------

    #include <JeeLib.h> // https://github.com/jcw/jeelib

    ISR(WDT_vect) { Sleepy::watchdogEvent(); } // interrupt handler for JeeLabs Sleepy power saving

    #define myNodeID 10 // RF12 node ID in the range 1-30
    #define network 210 // RF12 Network group
    #define freq RF12_433MHZ // Frequency of RFM12B module

    //#define USE_ACK // Enable ACKs, comment out to disable
    #define RETRY_PERIOD 5 // How soon to retry (in seconds) if ACK didn't come in
    #define RETRY_LIMIT 5 // Maximum number of times to retry
    #define ACK_TIME 10 // Number of milliseconds to wait for an ack

    #define tempPin A0 // TMP36 Vout connected to A0/ATtiny pin 13
    #define tempPower 9 // TMP36 Power pin is connected on pin D9/ATtiny pin 12

    int tempReading; // Analogue reading from the sensor

    //########################################################################################################################
    //Data Structure to be sent
    //########################################################################################################################

    //typedef struct {
    // int temp; // Temperature reading
    // int supplyV; // Supply voltage
    //} Payload;

    //Payload tinytx;

    char msg[26];

    // Wait a few milliseconds for proper ACK
    #ifdef USE_ACK
    static byte waitForAck() {
    MilliTimer ackTimer;
    while (!ackTimer.poll(ACK_TIME)) {
    if (rf12_recvDone() && rf12_crc == 0 &&
    rf12_hdr == (RF12_HDR_DST | RF12_HDR_CTL | myNodeID))
    return 1;
    }
    return 0;
    }
    #endif

    //--------------------------------------------------------------------------------------------------
    // Send payload data via RF
    //-------------------------------------------------------------------------------------------------
    static void rfwrite(){
    #ifdef USE_ACK
    for (byte i = 0; i <= RETRY_LIMIT; ++i) { // tx and wait for ack up to RETRY_LIMIT times
    rf12_sleep(-1); // Wake up RF module
    while (!rf12_canSend())
    rf12_recvDone();
    //rf12_sendStart(RF12_HDR_ACK, &tinytx, sizeof tinytx);
    rf12_sendStart(RF12_HDR_ACK, (uint8_t *)msg, strlen(msg));
    rf12_sendWait(2); // Wait for RF to finish sending while in standby mode
    byte acked = waitForAck(); // Wait for ACK
    rf12_sleep(0); // Put RF module to sleep
    if (acked) { return; } // Return if ACK received

    Sleepy::loseSomeTime(RETRY_PERIOD * 1000); // If no ack received wait and try again
    }
    #else
    rf12_sleep(-1); // Wake up RF module
    while (!rf12_canSend())
    rf12_recvDone();
    //rf12_sendStart(0, &tinytx, sizeof tinytx);
    rf12_sendStart(0, (uint8_t *)msg, strlen(msg));
    rf12_sendWait(2); // Wait for RF to finish sending while in standby mode
    rf12_sleep(0); // Put RF module to sleep
    return;
    #endif
    }


    //--------------------------------------------------------------------------------------------------
    // Read current supply voltage
    //--------------------------------------------------------------------------------------------------
    long readVcc() {
    bitClear(PRR, PRADC); ADCSRA |= bit(ADEN); // Enable the ADC
    long result;
    // Read 1.1V reference against Vcc
    #if defined(__AVR_ATtiny84__)
    ADMUX = _BV(MUX5) | _BV(MUX0); // For ATtiny84
    #else
    ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1); // For ATmega328
    #endif
    delay(2); // Wait for Vref to settle
    ADCSRA |= _BV(ADSC); // Convert
    while (bit_is_set(ADCSRA,ADSC));
    result = ADCL;
    result |= ADCH<<8;
    result = 1126400L / result; // Back-calculate Vcc in mV
    ADCSRA &= ~ bit(ADEN); bitSet(PRR, PRADC); // Disable the ADC to save power
    return result;
    }
    //########################################################################################################################

    void setup() {

    rf12_initialize(myNodeID,freq,network); // Initialize RFM12 with settings defined above
    rf12_sleep(0); // Put the RFM12 to sleep

    //not used 18082014
    //analogReference(INTERNAL); // Set the aref to the internal 1.1V reference

    pinMode(tempPower, OUTPUT); // set power pin for TMP36 to output

    }

    void loop() {

    int temp;

    digitalWrite(tempPower, HIGH); // turn TMP36 sensor on

    delay(10); // Allow 10ms for the sensor to be ready

    bitClear(PRR, PRADC); ADCSRA |= bit(ADEN); // Enable the ADC

    //mod 14082014, 19082014 reuse 10 readings
    tempReading = analogRead(tempPin); // throw away the first reading

    ADCSRA &= ~ bit(ADEN); bitSet(PRR, PRADC); // Disable the ADC to save power

    for(int i = 0; i < 10 ; i++) // take 10 more readings
    {
    tempReading += analogRead(tempPin); // accumulate readings
    }
    tempReading = tempReading / 10 ; // calculate the average

    digitalWrite(tempPower, LOW); // turn TMP36 sensor off

    // double voltage = tempReading * (1100/1024); // Convert to mV (assume internal reference is accurate)

    // double voltage = tempReading * 0.942382812; // Calibrated conversion to mV

    // double temperatureC = (voltage - 500) / 10; // Convert to temperature in degrees C.

    // tinytx.temp = temperatureC * 100; // Convert temperature to an integer, reversed at receiving end
    //tinytx.temp = tempReading;
    temp = tempReading;

    //tinytx.supplyV = readVcc(); // Get supply voltage
    int supplyV = readVcc(); // Get supply voltage
    strcpy(msg,"v=");
    itoa(supplyV,&msg[strlen(msg)],10);
    strcat(msg,"&r=");
    itoa(temp,&msg[strlen(msg)],10);

    rfwrite(); // Send data via RF

    for (byte i = 0; i < 5; i++)
    {
    Sleepy::loseSomeTime(60000); //JeeLabs power save function: enter low power mode for 60 seconds (valid range 16-65000 ms)
    }
    }[/php]

    Bin mir noch nicht ganz sicher warum, bekomme aber zw. Trocken und in Wasser derzeit Werte im Bereich von 480 bis 817.

    2014-12-23 20:52:51 [6 118 61 52 57 49 56 38 114 61 52 56 48][v=4918&r=480] => NodeID: 6 - Value: 480 - Vcc: 4918 [mV]
    ...
    2014-12-23 21:14:35 [6 118 61 52 57 49 56 38 114 61 56 49 55][v=4918&r=817] => NodeID: 6 - Value: 817 - Vcc: 4918 [mV]

    Ist zwar schade das für analog die 5V benötigt werden.
    Andererseits wären ca. 5V für eine Heizung zur schnelleren Abtrockung eh notwendig.

    Ich werde noch mal Tests im Digitalbetrieb machen, um in dort ggf. mit 3,3V und als Regendetektor einzusetzen. Der scheint ja schon bei einem Tropfen auszulösen (und LED geht an).
    Evtl. analog Reed/Switch Sketch um per Interrupt über Regen zu informieren und weniger Batterie zu verbrauchen.

    Mal sehen...

    Und mal schauen ob der langfristig meinen aktuellen Regendetektor und Regendauersensor ersetzen wird/kann (Eigenbau: Platine/Heizung -> umgebauter Funk-Temperatur -> senden an Wetterstation/Software).

  • Guten Tag,

    leider bekomme ich immer eine Fehlermeldung, wenn ich ein Sketch vor dem hochladen auf einen ATTINY84A - PU überprüfe bzw. compiliere.
    Vorweg lade ich immer den Bootloader hoch und versuche, das Sketch-Script dann zu überprüfen bzw. compilieren.

    Hier mal das log:

    Kann mir vielleicht jemand weiterhelfen?

    Vielen Dank!

  • Geh noch mal die Anleitung Schritt für Schritt durch
    - bist du sicher das du das richtige "Board" ausgewählt hast?
    - hast du arduino-tiny-0150-0018.zip geladen?
    - hast du die Anpassungen bezüglich hardware/attiny/ vorgenommen?

    Den Bootloader brauchst du nur ein mal flashen, sofern das erfolgreich ist..


    Ansonsten bitte Deinen Sketch posten



    Kann ich mit dieser Platine genau das gleiche machen/programmieren wie bei den hier selbstgebauten?

    http://www.digitalsmarties.net/products/rfm12b-board

    Jein.
    Das RFM12B-Board hat keinen ATtiny verlötet, wie es aber bei uns oder dem RFM2Pi der Fall ist. Diese Aufgabe muss dann also der PI übernehmen - Man muss also direkt mit dem RFM12B Module kommunizieren, diesen konfigurieren usw.
    Um das zu können muss man ein bestimmtes Kernel-Module einbinden, was ich erst nach mehreren Anläufen hingekriegt und > hier <(Beitrag#873) und > hier <(Beitrag#840) beschrieben habe.

    Ausserdem muss man das Module über beide SPI Channels anschließen, man kann dann also kein weiteres SPI device mehr verwenden. Das ist denk ich der größte Manko.

  • Hallo,

    da ich meine TinyTX3 gerne mit 2 AA Batterien füttern würde und der DHT22 Sensor ja (laut Datenblatt) mindestens 3.0V für den Betrieb benötigt, bin ich auf de Suche nach einem geeigneten Boost-Converter um auf 3.3V zu kommen. Ich habe gesehen, dass meigrafd beim TinyTX4 auf den LTC3525 gesetzt hat, aber für die Sammelbestellung der TinyTX4 Boards mit Boost-Converter bin ich ja nun Lichtjahre zu spät...

    In die engere Wahl habe ich den Pololu NCP1402 oder den U1V10F3 gezogen, wobei letzterer ja den Charme hätte auch step-down zu können, man also auch mit 3 AA Batterien arbeiten könnte. Noch dazu soll der U1V10F3 ja sogar bis 0.3V herunter an den Batterien saugen können. Gibt es zu den Beiden bereits Erfahrungswerte der hier vermuteten Funksensorbastelhorde oder gar eine Empfehlung für einen völlig anderen Boost-Converter?

    Auch dachte ich ursprünglich mal an den Betrieb der Funksensoren mit Eneloop Akkus. Hier wäre ein Boost-Converter, der die Akkus bis zur Tiefentladung leer lutscht, ja eher kontraproduktiv. Hat einer von Euch die Funksensoren im Akkubetrieb laufen?

    Besten Dank für jeden Tipp!

    Einmal editiert, zuletzt von doing (28. Dezember 2014 um 16:48)

  • da ich meine TinyTX3 gerne mit 2 AA Batterien füttern würde und der DHT22 Sensor ja (laut Datenblatt) mindestens 3.0V für den Betrieb benötigt, bin ich auf de Suche nach einem geeigneten Boost-Converter um auf 3.3V zu kommen.

    Laut Tests funktioniert er auch noch bis 2.8V runter aber weniger darf es nicht sein ;)


    In die engere Wahl habe ich den Pololu NCP1402 oder den U1V10F3 gezogen, wobei letzterer ja den Charme hätte auch step-down zu können, man also auch mit 3 AA Batterien arbeiten könnte.

    Das kannst du auch bereits jetzt schon:

    Der ATtiny Chip verträgt maximal 5,5V.
    Das RFM12B Modul verträgt maximal 6V.
    Der LTC3525 boost regulator chip verträgt maximal 5,5V.
    Die anderen Bauteile (Kondensatoren und Spule) vertragen afaik maximal 6V

    Also liegt die Grenze bei maximal 5,5V wegen des ATtiny Chips -> man kann also maximal 3 x AA Batterien (á 1,5V) oder 4 x AA Akkus (á 1,2V) verwenden

    Noch dazu soll der U1V10F3 ja sogar bis 0.3V herunter an den Batterien saugen können.

    Der NCP1402 kann laut Datenblatt auch noch mit bis runter zu 0.3V arbeiten, sofern er mit mehr als 0.8V gestartet ist (turn on / startup). Allerdings sind nur 85% nicht allzusehr effizient... NCP1402 verträgt maximal 6V

    Der U1V10F3 hat ebenso eine eher geringe Effizienz von nur 65%-bis-zu-85% und verträgt maximal 5.5V. Startup Voltage ist bei diesem Module nur 0.5V Vs. 0.8V wie beim NCP1402. Ein weiterer Vorteil wäre durchaus das sowohl StepDown als auch StepUp genutzt werden kann


    Gibt es zu den Beiden bereits Erfahrungswerte der hier vermuteten Funksensorbastelhorde oder gar eine Empfehlung für einen völlig anderen Boost-Converter?

    Ich würd generell einen suchen der möglichst effektiv und somit wenig Verlustleistung hat ;)
    Aber naja, der LTC3525 kam da quasi als einziger in Frage, auch wenn das kein StepDown is..

    Hat einer von Euch die Funksensoren im Akkubetrieb laufen?

    Ja, ich ;)
    Ein Sensor läuft mit 4 x AA Akkus. Aber das es schlimm sein soll Akkus komplett leer zu lutschen ist mir neu - wobei ich dazu gesagt nicht allzu viel Ahnung von Batterien/Akkus usw hab :D

  • Das kannst du auch bereits jetzt schon:
    Das RFM12B Modul verträgt maximal 6V.

    Ich habe die RFM12B bei JeeLabs bezogen und bin an die RFM12BSP v1.0 geraten. Die vertragen, wenn ich richtig nachgelesen habe, nur maximal 3.8V. Sie würden also mit 3 AA Akkus laufen, aber mit 3 AA Batterien hätte ich dann wohl ein Problem. Aus dem Grund kam ich auf den U1V10F3 mit seiner StepDown Fähigkeit.

    Ein fertiges Board mit dem LTC3525 konnte ich bisher leider nicht auftun. Hätte ich es gefunden, dann würde es mein Problem mit dem RFM12BSP und den 3.8V mangels StepDown auch nicht lösen.

    Aber das es schlimm sein soll Akkus komplett leer zu lutschen ist mir neu

    Akkuspezialist bin ich auch nicht, aber bei NiCd Akkus war eine Tiefentladung das Todesurteil. Wie das bei NiMH Akkus mit einer Tiefentladung ist weiß ich leider auch nicht zuverlässig...

    Einmal editiert, zuletzt von doing (28. Dezember 2014 um 21:56)

  • meigrafd

    und

    Zitat

    Ja, nur anders Icon_lol

    Funktioniert trotzdem nicht?


    habs nun ausprobiert...funktioniert nicht.


    dann zu dem LOW_POWER DHT22 ino Script,
    bei mir funzt dieses Script nicht, es wird nichts übertragen oder BAD-CRC das habe ich noch nicht ganz heraus bekommen...
    übertrage ich den standard DHT22 Script aus 2013 von meigrafd ... funzt der DHT22 Sensor wieder.


    dann zu den Step-Up Geschichte...so ein Teil (LTC3525)...kostet ja 4-5 EURO...da kann ich gleich eine günstig LiPo-Akku kaufen und den immer wieder aufladen...ausser es geht einem wirklich extrem um den Platz. Oder?

    Einmal editiert, zuletzt von keulemaster (30. Dezember 2014 um 20:51)


  • dann zu dem LOW_POWER DHT22 ino Script,
    bei mir funzt dieses Script nicht, es wird nichts übertragen oder BAD-CRC das habe ich noch nicht ganz heraus bekommen...
    übertrage ich den standard DHT22 Script aus 2013 von meigrafd ... funzt der DHT22 Sensor wieder.

    Hm, komisch.. Kann ich zZt leider nicht testen da ich grad mein RoPi Projekt dokumentiere..

    dann zu den Step-Up Geschichte...so ein Teil (LTC3525)...kostet ja 4-5 EURO...da kann ich gleich eine günstig LiPo-Akku kaufen und den immer wieder aufladen...ausser es geht einem wirklich extrem um den Platz. Oder?

    Theoretisch ja, allerdings benötigt man dann auch ein spezielles Ladegerät. Aber was viel wichtiger ist: LiPos zeigen bei solchen Knechtungen (Tiefenentladung) eine schleichende Langzeitschädigung. Es kann aber auch gefährlich werden wenn man das ignoriert. Aber auch Temperaturen können gefährlich werden.
    Lies dir dazu unbedingt mal das durch: http://wiki.mikrokopter.de/LiPo-Grundlagen#Handhabung

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!