Sleep() with interrupt only works with level "LOW"


  • Hero Member

    Concluding from @Yveaux 's thorough analysis of sleep() in combination with interrupts there is a lot of chatching up to do. My experiments currently (2.1.1.) show a consistent erratic behaviour when using sleep() in conjunction with FALLING/ RISING/ CHANGE. HIGH is not possible with the atmega328 so only LOW remains... (not documented in the API yet). Previously usign CHANGE was common practice in MySensors and 'seemed' to be functioning.
    Unless there is a solution we need to change the API description and examples (i.e motion detector) and create awareness.
    Or are there other ways to get back to our common practice?



  • I've been following that development. And I think it's good that MySensors follows the rules as set by Atmel.

    To be able to use more interrupt pins at the same time I have been looking into pin change interrupts. Those are triggered as the designated pin changes state, either LOW->HIGH or the other way round.

    I think by changing MyHWAVR.cpp (and the comparable files for other hardware) a little, my sensors is capable of using PCI's to wake the node. There is always a negative, and in this case I think its the amount of code needed to see what pin caused the interrupt. The work done by GreyGnome with the EnableInterrupt library shows that very well. The lib is also huge because of the way they use enabling and disabling of the pins with software to emulate the other modes(RISING, FALLING, HIGH and LOW).

    This is not THE solution. It's only one of the ways to be able to use the other modes with a pin.


  • Mod

    @AWI I agree the code & examples need some work on the sleeping topic.
    Following the ATMega specs will indeed only allow to wake on LOW level, while e.g. PIRs will generally produce a HIGH level on motion.
    Ofcourse this can be fixed in hardware, but I'd prefer to first have a look at pinchange ints as @DavidZH suggests.
    I'm not sure if including the suggested library is the way to go; we have to look into that.


  • Hero Member

    @Yveaux Pigheaded as I am... (AVR made some more mistakes in their documentation) .. I got 12 different atmega328p processors from different sources on the test bench (custom, TQFP & DIL, pro-mini 3.3 /5V) and was not able to produce proof of : 0_1490897465883_upload-4a1e7b13-42e2-49bb-b132-1927b9dd669d.
    I got consistent behaviour with using CHANGE, RISING, FALLING and LOW using the SLEEP_FOREVER mode of the low power library.

    "RISING"
    0_1490898088157_upload-3fd4332e-59a0-466c-b5c5-6e33ec8ff117
    and similar for "CHANGE"
    0_1490898242474_upload-f8afe558-13bb-4fd4-a2d8-b6e512c70888
    So "the question": out of spec 😐 - or - invalid spec 😟


  • Mod

    @AWI Nice investigation!
    Just curious: Are the results the same with the MySensors library?


  • Hero Member

    @Yveaux Not really.. since 2.1.1 I'm losing it... 😊 Still in the process of finding differences with the previous version...


  • Mod

    @AWI Could be that Atmel copied the datasheet from the ATMega8. See this topic where the LOW-only wake from sleep seems to be acknowledged for ATMega8, and your findings match theirs for ATMega328.


  • Mod

    @AWI There goes my pleed:

    0_1490901898593_upload-682ef4f5-a21b-4fbe-822c-339d0e3db1a7

    Source: http://gammon.com.au/interrupts

    Back to the drawing board then...


  • Hero Member

    @Yveaux Good find! and good news 😉


  • Mod

    @AWI Took me a day of debugging, datasheet reading and searching the internet, but It looks like I fixed the sleep with external interrupts issues in the MySensors library!
    Main issue was this one: https://github.com/mysensors/MySensors/issues/811
    If an interrupt was pending (if it had been registered before actually sleeping the AVR) it would immediately wake the AVR again, just 2ms after sleeping it. It didn't matter if this interrupt was registered just before calling sleep or 1 hour ago...
    Furthermore https://github.com/mysensors/MySensors/issues/812 and https://github.com/mysensors/MySensors/issues/809 were also fixed, but have minor impact.

    I tested it on a ProMini with ATMega328P @ 8MHz, powered directly by 2xAA battery -- a 'standard' sleeping sensor processor setup.
    I verified sleeping modes LOW, CHANGE, RISING & FALLING to work Ok. This confirms your findings and Nick Gammon's.

    Sidenote: Mode HIGH is mapped onto CHANGE in Arduino ATMega328P port (duh!). The library can therefore not distinguish between the two and will use CHANGE in both situations.

    The bugs are solved in development branch, so please give it a try!



  • @Yveaux

    The new version didn't seem to help with my scenario - a vibration sensor where I only want to send one message per "event". (A vibration detected within a few seconds, or more). Using the default handling:

    switch ( sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, SLEEP_TIME) )
      {
        case MY_WAKE_UP_BY_TIMER:
          sendHeartbeat();
          break;
        case MY_SLEEP_NOT_POSSIBLE:
          Serial.println("Unable to sleep ;-(");
          break;
        default:
          Serial.println("Sending a message with value = 1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!");
          send(msg.set(1));
    
    }
    

    There are always 2 messages sent. This happens even if I add a sleep either before or after the send().

    My workaround has been to add this after the send():

      while (sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, 2000) != MY_WAKE_UP_BY_TIMER ) {
        Serial.println("Clearing interrupts");
      }
    

    I'm not sure the workaround is a good idea - because it may cause other problems. Any other ideas? Or is this correct?

    Thanks!


  • Hero Member

    @Yveaux great work 👍


  • Hero Member

    @ileneken3 Could it be that your sensor is better handled with a RISING or FALLING interrupt? CHANGE fires on both edges. Else post your whole sketch and debug log.


  • Mod

    @ileneken3 for how long did you sleep when trying to use sleep to debounce the interrupt after sending? If you used a number less than 15, could you try with 15 or above? The sleep function does not work very well with small sleep times. or replace that sleep with wait.



  • @AWI

    Tried all suggestions. Here is the whole code:

    /**
       The MySensors dev version
       **/
    #define MY_NODE_ID 89 
    #define MY_PARENT_NODE_ID 88 // Main floor repeater
    #define CHILD_ID 88  // Id of the sensor child
    
    #define MY_RF24_PA_LEVEL RF24_PA_HIGH // Attempt to get radio to work
    #define MY_BAUD_RATE 9600
    #define MY_RADIO_NRF24
    #define MY_DEBUG    // Enables debug messages
    #include <MySensors.h>
    unsigned long SLEEP_TIME = 360000; // 6 minutes between heartbeats
    
    #define DIGITAL_INPUT_SENSOR 3 // The digital input attached to vibration sensor.
    
    // Initialize  message
    MyMessage msg(CHILD_ID, V_TRIPPED);
    
    void setup()
    {
      Serial.begin(9600); // 9600 needed for 1MHZ
    
      pinMode(DIGITAL_INPUT_SENSOR, INPUT);      // sets the motion sensor digital pin as input
      pinMode(DIGITAL_INPUT_SENSOR, INPUT_PULLUP);
    
      wait(100);
      Serial.println("Sending a message with value = 1 to get things started");
      send(msg.set(1));
    }
    
    void presentation()  {
      // Send the sketch version information to the gateway and Controller
      sendSketchInfo("Mailbox Sensor 1Mhz", "1.5");
    
      // Register all sensors to gw (they will be created as child devices)
      present(CHILD_ID, S_MOTION);
    }
    
    void loop()
    {
      // Sleep until woken by sensor, or timeout
      // Tried with FALLING and RISING also.
      switch ( sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, SLEEP_TIME) )
      {
        case MY_WAKE_UP_BY_TIMER:
          Serial.println("Woke up after SLEEP_TIME seconds so sending heartbeat");
          sendHeartbeat();
          break;
        case MY_SLEEP_NOT_POSSIBLE:
          Serial.println("Unable to sleep ;-(");
          break;
        default:
          Serial.println("Sending a message with value = 1 !!!!!!");
          // Tried with sleep(15), sleep(1000), sleep(10000). delay(1000) and wait(4000)
          wait(4000);
    #ifdef SHOULD_NOT_BE_NEEDED
          while (sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, 2000) != MY_WAKE_UP_BY_TIMER ) {
            Serial.println("Clearing interrupts");
          }
    #endif
          break;
      }
    }
    
    

    Here is the debug log:
    0 MCO:BGN:INIT NODE,CP=RNNNA---,VER=2.2.0-beta
    49 TSM:INIT
    65 TSF:WUR:MS=0
    81 TSM:INIT:TSP OK
    114 TSM:INIT:STATID=89
    131 TSF:SID:OK,ID=89
    163 TSM:FPAR
    212 TSF:MSG:SEND,89-89-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    737 TSF:MSG:READ,0-0-89,s=255,c=3,t=8,pt=1,l=1,sg=0:0
    786 TSF:MSG:FPAR OK,ID=0,D=1
    1179 TSF:MSG:READ,88-88-89,s=255,c=3,t=8,pt=1,l=1,sg=0:1
    1245 TSF:MSG:FPAR PREF
    1261 TSF:MSG:FPAR OK,ID=88,D=2
    1294 TSM:FPAR:OK
    1327 TSM:ID
    1343 TSM:ID:OK
    1359 TSM:UPL
    1376 TSF:MSG:SEND,89-89-88-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
    3473 TSM:UPL
    3489 TSF:MSG:SEND,89-89-88-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
    3571 TSF:MSG:READ,0-88-89,s=255,c=3,t=25,pt=1,l=1,sg=0:2
    3637 TSF:MSG:PONG RECV,HP=2
    3670 TSM:UPL:OK
    3686 TSM:READY:ID=89,PAR=88,DIS=2
    3735 TSF:MSG:SEND,89-89-88-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
    3817 TSF:MSG:READ,0-88-89,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
    3899 TSF:MSG:SEND,89-89-88-0,s=255,c=0,t=17,pt=0,l=10,sg=0,ft=0,st=OK:2.2.0-beta
    3997 TSF:MSG:SEND,89-89-88-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:88
    6111 TSF:MSG:SEND,89-89-88-0,s=255,c=3,t=11,pt=0,l=19,sg=0,ft=0,st=OK:Mailbox Sensor 1Mhz
    6225 TSF:MSG:SEND,89-89-88-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.5
    6324 TSF:MSG:SEND,89-89-88-0,s=88,c=0,t=1,pt=0,l=0,sg=0,ft=0,st=OK:
    6406 MCO:REG:REQ
    6422 TSF:MSG:SEND,89-89-88-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
    6504 TSF:MSG:READ,0-88-89,s=255,c=3,t=27,pt=1,l=1,sg=0:1
    6586 MCO:PIM:NODE REG=1
    6602 MCO:BGN:STP
    Sending a message with value = 1 to get things started
    6766 TSF:MSG:SEND,89-89-88-0,s=88,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:1
    6881 MCO:BGN:INIT OK,TSP=1
    6897 MCO:SLP:MS=360000,SMS=0,I1=1,M1=1,I2=255,M2=255
    6963 TSF:TDI:TSL
    6995 MCO:SLP:WUP=1
    7012 TSF:TRI:TSB
    Sending a message with value = 1 !!!!!!
    11059 MCO:SLP:MS=360000,SMS=0,I1=1,M1=1,I2=255,M2=255
    11108 TSF:TDI:TSL
    11141 MCO:SLP:WUP=1
    11157 TSF:TRI:TSB
    Sending a message with value = 1 !!!!!!
    15204 MCO:SLP:MS=360000,SMS=0,I1=1,M1=1,I2=255,M2=255
    15253 TSF:TDI:TSL

    I always get at least two messages, sometimes more.

    Here is the sensor:

    https://www.aliexpress.com/item/normally-closed-type-vibration-sensor-module-Alarm-sensor-module-Vibration-switch-SW-420/32552946060.html?ws_ab_test=searchweb0_0,searchweb201602_1_10065_10130_10068_10136_10137_10138_10060_10062_10141_10056_10055_10054_10059_10099_129_10103_10102_10096_10148_10052_10053_10050_10107_10142_10051_10143_10084_10083_10119_10080_10082_10081_10110_10111_10112_10113_10114_10037_10032_10078_10079_10077_10073_10070_10123_10120_10124-10120,searchweb201603_4,afswitch_1_afChannel,ppcSwitch_5,single_sort_0_default&btsid=ad1187d9-117e-4c3a-b352-613dbf796c4f&algo_expid=761b80f8-c1bc-4235-8891-522e2e83f548-10&algo_pvid=761b80f8-c1bc-4235-8891-522e2e83f548



  • @mfalkvidd

    I did try many combinations of sleep,wait,delay. I always get at least 2 messages sent.
    Below, I posted the code and the debug log.

    Thanks again.


  • Mod

    Remove the MY_PARENT_NODE_ID and set pa_level to min



  • @gohan
    I tried. Unfortunately, it didn't seem to matter with either or both those changes 😞


Log in to reply
 

Suggested Topics

1
Online

11.2k
Users

11.1k
Topics

112.5k
Posts