Skip to content
  • MySensors
  • OpenHardware.io
  • Categories
  • Recent
  • Tags
  • Popular
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo
  1. Home
  2. Hardware
  3. Interrupt on recieve radio data

Interrupt on recieve radio data

Scheduled Pinned Locked Moved Hardware
interruptbattery powered
14 Posts 5 Posters 9.9k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • J Offline
    J Offline
    jonnyfishman
    wrote on last edited by
    #1

    Just a quick question, and I'm guessing the answer is a 'No', but is it possible to set the sensor to receive data when using the:

    gw.sleep(INTERRUPT, CHANGE, SLEEP_TIME)

    function ?

    I have a battery powered RFID lock that I would like to trigger remotely as well. I am using gw.sleep to try and increase battery life, but am guessing that to receive data the sensor must be in a constant ready state and not in sleep mode. Is this correct?

    Thanks,
    Jon

    1 Reply Last reply
    0
    • BulldogLowellB Offline
      BulldogLowellB Offline
      BulldogLowell
      Contest Winner
      wrote on last edited by
      #2

      you can certainly use the interrupt to signal the arduino to wake and process accordingly... that is the the intent of the interrupt wake

      1 Reply Last reply
      0
      • hekH Offline
        hekH Offline
        hek
        Admin
        wrote on last edited by
        #3

        I haven't actually tried using the radio interrupt pin to wake sleeping sensors.
        If someone here has some experience of this please report your findings.

        1 Reply Last reply
        1
        • axillentA Offline
          axillentA Offline
          axillent
          Mod
          wrote on last edited by axillent
          #4

          I had played with interrupt from radio
          it should be no issue to use radio interrupt for MCU wake up
          you will need to clear interrupt flags on awake by calling whatHappened http://maniacbug.github.io/RF24/classRF24.html#afb97dc4bdf4d2d84ea44060ac5b4ed89

          pin 2 or 3 should be used for NRF24 IRQ pin
          but with some additional care any pin can be attached by configuring PCINT interrupt

          sense and drive

          1 Reply Last reply
          0
          • D Offline
            D Offline
            dzairo
            wrote on last edited by
            #5

            hmmm.. why you want use irq ?
            save battery ? irq not solve this problem..
            of course irq can wake up mcu (save some power) but radio us still on then not save too much ..
            for example CC1101 have this special function WOR register .. radio itself wake up and listening .. and go sleep if no preamble and address ...
            there is possible do this ..
            set longer period between packet if not received ack . and in another side wake up radio and listening twice this period .. then go sleep..
            if set max transmit to 15 and period set around 100ms then total time is 1.5sec ..

            this is my idea..

            axillentA 1 Reply Last reply
            0
            • D dzairo

              hmmm.. why you want use irq ?
              save battery ? irq not solve this problem..
              of course irq can wake up mcu (save some power) but radio us still on then not save too much ..
              for example CC1101 have this special function WOR register .. radio itself wake up and listening .. and go sleep if no preamble and address ...
              there is possible do this ..
              set longer period between packet if not received ack . and in another side wake up radio and listening twice this period .. then go sleep..
              if set max transmit to 15 and period set around 100ms then total time is 1.5sec ..

              this is my idea..

              axillentA Offline
              axillentA Offline
              axillent
              Mod
              wrote on last edited by
              #6

              @dzairo said:

              save battery ? irq not solve this problem..

              that is a correct point
              for NRF24 to raise interrupt you need to keep it in radio listening
              If I'm remembering right NRF24 is consuming about 12mA while listening

              sense and drive

              1 Reply Last reply
              0
              • D Offline
                D Offline
                dzairo
                wrote on last edited by
                #7

                yes... this is not good point how to save battery ..
                if you want then .. need wake up radio very predefined time .. and listening ..
                but then MCU also have power consumption .. then not good point ..

                but using MySensors .. new features for controller ..
                buffer for packet ..
                node every 1 sec wake up and ask for new command .. if not then return sleep .. if yes then process ..
                gateway .. will hold new packet in special buffer .. if receive request from node then send this packet .. if not then still hold or after predefined time flush packet.

                MySensors have very big potencial . to make very good sensor network..

                1 Reply Last reply
                0
                • axillentA Offline
                  axillentA Offline
                  axillent
                  Mod
                  wrote on last edited by
                  #8

                  it is more question of device design
                  what kind of device we are talking about?

                  sensors usually are working in active mode by sending data on certain predefined events (for example shift in temperature or elapsed time)
                  they will sleep between events and will be not able to receive
                  time to time (not often, for example battery powered zwave devices are initiating pooling each 30 minutes by default) the device can send a request to controller for a parameters updates and will wait for the reply before going sleep

                  if your battery device need by design be always accessible in passive mode (passive means the connection is initiated by third party) it probably means that design is wrong and can be optimized

                  if you still need this way you probably can use push-pull idea most modern gadgets are using (like iphone). This way your device is connecting to the server on a regular basis to ask very short questions "is anything awaiting for me?". Shorter payload - less time for the transmit, less power needed
                  but do not expect the device to work for a long time

                  sense and drive

                  1 Reply Last reply
                  0
                  • J Offline
                    J Offline
                    jonnyfishman
                    wrote on last edited by
                    #9

                    Hi guys, thanks, for the replies and ideas.

                    'axillent', your quite right. I realised this morning that of course I can send a request to the controller for the current values when the user presses the button to turn on the RFID module. This way I can leave the sensor in the sleep setting until it is actually needed.

                    Presumably this is as simple as sending the command:

                    gw.request(CHILD_ID, V_VAR1); - copied from 'EnergyMeterPulseSensor'

                    One thing I'm not sure about is whether the following function is called by gw.request or does it get called from somewhere else (I can't test it at the moment to find out)?

                    void incomingMessage(const MyMessage &message) {
                    if (message.type==V_VAR1) {
                    state = message.getLong();
                    Serial.print("Received state from gw:");
                    Serial.println(state);
                    }
                    }

                    1 Reply Last reply
                    0
                    • hekH Offline
                      hekH Offline
                      hek
                      Admin
                      wrote on last edited by
                      #10

                      Yes, the request-response will be delivered to your callback function.

                      1 Reply Last reply
                      0
                      • J Offline
                        J Offline
                        jonnyfishman
                        wrote on last edited by
                        #11

                        Hi Hek,

                        Thanks for the response. I've set the following (full code is attached but is still quite messy RFID.ino ):

                        gw.begin(incomingMessage);
                        gw.request(CHILD_ID_TEMP, V_TEMP); 
                        

                        and

                        // Manage incoming messages from Gateway 
                        void incomingMessage(const MyMessage &message) {
                        Serial.println("incoming");
                         // We only expect one type of message from controller. But we better check anyway.
                             if (message.type==V_TEMP) {    
                        // Change relay state
                        if (lockStatus != message.getBool() )
                        setLockState(message.getBool(), false); 
                        
                        // Write some debug info
                        Serial.print("Incoming lock status from GW:");
                        Serial.println(message.getBool());
                        } 
                        }//end incomingMessage
                        

                        I'm using Pidome and can see the response being sent back to the node as:

                        05-12-2014 20:10:46: 0;0;3;0;9;send: 0-0-2-2 s=1,c=1,t=0,pt=0,l=4,st=fail:19.1
                        05-12-2014 20:10:45: 0;0;3;0;9;read: 2-2-0 s=1,c=2,t=0,pt=0,l=0:
                        05-12-2014 20:09:28: 0;0;3;0;9;send: 0-0-2-2 s=1,c=1,t=0,pt=0,l=4,st=fail:19.1
                        05-12-2014 20:09:27: 0;0;3;0;9;read: 2-2-0 s=1,c=2,t=0,pt=0,l=0:
                        

                        But in terminal I never see the response (no incoming message displayed). Is there a problem with st failing or is it something wrong with the server response?

                        Thanks,
                        Jon

                        1 Reply Last reply
                        0
                        • hekH Offline
                          hekH Offline
                          hek
                          Admin
                          wrote on last edited by
                          #12

                          Looks like you don't get any ack from the sensor. So it could very well be com problems.

                          1 Reply Last reply
                          0
                          • J Offline
                            J Offline
                            jonnyfishman
                            wrote on last edited by
                            #13

                            Hi Hek,

                            Solved the ack problem, just moved the sensor closer to the GW. I'm now getting a response but its not consistent.

                             //Setup completed
                             RF24 initialized and GW contacted
                             //GW present from other sensors
                             Battery Voltage: send: 2-2-0-0 s=3,c=1,t=38,pt=7,l=5,st=ok:0.1
                             Temperature: send: 2-2-0-0 s=1,c=1,t=0,pt=7,l=5,st=ok:24.7
                             
                             //Triggering the button sends gw.request, the following is output 
                             send: 2-2-0-0 s=2,c=2,t=36,pt=0,l=3,st=ok:1.4
                             
                             //Triggering the button again gets this response
                             read: 0-0-2 s=2,c=1,t=36,pt=0,l=1:0
                             Incoming Radio
                             Alarm Disabled
                             Incoming lock status from GW:0
                             send: 2-2-0-0 s=2,c=2,t=36,pt=0,l=1,st=ok:0
                             
                             //Triggering again
                             read: 0-0-2 s=2,c=1,t=36,pt=0,l=1:0
                             Incoming Radio
                             Alarm Disabled
                             Incoming lock status from GW:0
                             send: 2-2-0-0 s=2,c=2,t=36,pt=0,l=1,st=ok:0
                            

                            I don't understand why the first one always fails, would it be better to trigger the callback manually to pick up a response?
                            Also is it possible to introduce a wait or while loop to prevent the rest of the loop being processed until the GW replies?

                            Thanks,
                            Jon

                            hekH 1 Reply Last reply
                            0
                            • J jonnyfishman

                              Hi Hek,

                              Solved the ack problem, just moved the sensor closer to the GW. I'm now getting a response but its not consistent.

                               //Setup completed
                               RF24 initialized and GW contacted
                               //GW present from other sensors
                               Battery Voltage: send: 2-2-0-0 s=3,c=1,t=38,pt=7,l=5,st=ok:0.1
                               Temperature: send: 2-2-0-0 s=1,c=1,t=0,pt=7,l=5,st=ok:24.7
                               
                               //Triggering the button sends gw.request, the following is output 
                               send: 2-2-0-0 s=2,c=2,t=36,pt=0,l=3,st=ok:1.4
                               
                               //Triggering the button again gets this response
                               read: 0-0-2 s=2,c=1,t=36,pt=0,l=1:0
                               Incoming Radio
                               Alarm Disabled
                               Incoming lock status from GW:0
                               send: 2-2-0-0 s=2,c=2,t=36,pt=0,l=1,st=ok:0
                               
                               //Triggering again
                               read: 0-0-2 s=2,c=1,t=36,pt=0,l=1:0
                               Incoming Radio
                               Alarm Disabled
                               Incoming lock status from GW:0
                               send: 2-2-0-0 s=2,c=2,t=36,pt=0,l=1,st=ok:0
                              

                              I don't understand why the first one always fails, would it be better to trigger the callback manually to pick up a response?
                              Also is it possible to introduce a wait or while loop to prevent the rest of the loop being processed until the GW replies?

                              Thanks,
                              Jon

                              hekH Offline
                              hekH Offline
                              hek
                              Admin
                              wrote on last edited by hek
                              #14

                              @jonnyfishman said:

                              would it be better to trigger the callback manually to pick up a response?

                              No that won't help (as long as you call gw.process() ).

                              1 Reply Last reply
                              0
                              Reply
                              • Reply as topic
                              Log in to reply
                              • Oldest to Newest
                              • Newest to Oldest
                              • Most Votes


                              15

                              Online

                              11.7k

                              Users

                              11.2k

                              Topics

                              113.0k

                              Posts


                              Copyright 2019 TBD   |   Forum Guidelines   |   Privacy Policy   |   Terms of Service
                              • Login

                              • Don't have an account? Register

                              • Login or register to search.
                              • First post
                                Last post
                              0
                              • MySensors
                              • OpenHardware.io
                              • Categories
                              • Recent
                              • Tags
                              • Popular