Hi all,
I have two Motetino with RFM69W 915Mhz radios attached. I'm trying to set the Motetino to sleep with the code I found in the LowPower library shown below. Is there anyway to use the radio RFM69W as external interrupt to wakes up the Motetino from sleep mode? Which means when the RFM69W received data or signal from other radio module, it will wakes up the Motetino. Which pin of the RFM69W I can connect to the Motetino that will does this interrupt function? Thank you for your help and invaluable time.
// **** INCLUDES *****
#include "LowPower.h"
// Use pin 2 as wake up pin
const int wakeUpPin = 2;
void wakeUp()
{
// Just a handler for the pin interrupt.
}
void setup()
{
// Configure wake up pin as input.
// This will consumes few uA of current.
pinMode(wakeUpPin, INPUT);
}
void loop()
{
// Allow wake up pin to trigger interrupt on low.
attachInterrupt(0, wakeUp, LOW);
// Enter power down state with ADC and BOD module disabled.
// Wake up when wake up pin is low.
LowPower.powerDown(SLEEP_FOREVER, ADC_OFF, BOD_OFF);
// Disable external pin interrupt on wake up pin.
detachInterrupt(0);
// Do something here
// Example: Read sensor, data logging, data transmission.
}
Moteino will automatically wake up on any packet received (as long as the radio is left in RX mode).
I don't know much about Motetino ;)
Quote from: Felix on January 22, 2014, 08:28:33 AM
Moteino will automatically wake up on any packet received (as long as the radio is left in RX mode).
I don't know much about Motetino ;)
Thanks for the rely. So what do you mean the radio is left in RX receiving mode? By the time Moteino goes to sleep mode, should I set the RFM69W to sleep? Or keep the radio power on all the time for listening any packets? Please provide me little more details. Thank you
Don't put the radio to sleep, only the Moteino.
You have to call receiveDone() which effectively puts the radio in RX mode. Then you can sleep the Moteino. When a packet is received, D2 is asserted and execution will resume after the moteino sleep() call.
Quote from: Felix on January 22, 2014, 12:43:04 PM
Don't put the radio to sleep, only the Moteino.
You have to call receiveDone() which effectively puts the radio in RX mode. Then you can sleep the Moteino. When a packet is received, D2 is asserted and execution will resume after the moteino sleep() call.
I want to set up a series of moteinos to transmit data over a distance. So let's say the first moteino sends a packet to the second moteino's radio which wakes up the second moteino. Will this data packet be stored in the radio while the moteino is waking up, or is this first packet lost due to the time needed for the second moteino to power up?
If the Moteino is sleeping, and radio in RX, when a packet is received the INT0 interrupt is raised (on D2), the packet is read from the radio's buffer into the library buffer (radio.DATA), and Moteino will resume execution after the "moteino.sleep()" instruction. At that point you are ready to read that radio.DATA packet. But say if another packet would be received before you have a chance to actually read that data, it will overwrite the first packet. So as usual, you should try to check receiveDone() as often as possible when Moteinos is awake, otherwise packets may be lost/overwritten.
So the radio.DATA packet is stored within the radio while the moteino begins it's wake-up process. How large of a packet can radio.DATA hold?
Thank you for the brief response! This is excellent information and is extremely helpful for what I'm doing.
Please see moteino.com and https://github.com/lowpowerlab/rfm69 for more details on the library and capabilities.
Quote from: Felix on January 23, 2014, 04:34:26 PM
Please see moteino.com and https://github.com/lowpowerlab/rfm69 for more details on the library and capabilities.
Is there any way to change the default CS pin for RFM69 to other pins inside the library? I'm trying to connect it to a Arduino Ethernet Shield which is also used pin 10 as SS pin.
I found someone did this with RFM12B, but their libraries are different than what I have for the RFM69W.
http://harizanov.com/2012/04/rfm12b-and-arduino-ethernet-with-wiznet5100-chip/
void setCS(byte newSPISlaveSelect);
Quote from: Felix on January 22, 2014, 12:43:04 PM
Don't put the radio to sleep, only the Moteino.
You have to call receiveDone() which effectively puts the radio in RX mode. Then you can sleep the Moteino. When a packet is received, D2 is asserted and execution will resume after the moteino sleep() call.
I've put the rfm69w to RX mode and then sleep the Moteino. By this method, the system is now using 16.45mA while waiting for packets. Is there anyway I can lower the current? I've also read the document of the rfm69w. There is a listen mode on page 39. Is this same as RX mode? thanks
http://www.hoperf.com/upload/rf/RFM69W-V1.3.pdf
No, you have to be in RX to receive anything.
Listen mode is alternating between sleep and RX. That way you lower the RX current but you're also lowering the RX duty cycle.
Here's what I'm doing to reduce power in my Moteino project:
I have a gateway and one remote Moteino. The remote sleeps for 15 seconds then wakes up and checks a sensor. If the sensors is the same state (i.e. was high, now it's still high) the Moteino does nothing and goes back to sleep. If the state has changed (i.e. was high, now low) the remote transmits this change to the gateway, and after receiving acknowledgement it listens for a few hundred milliseconds (I use 200) for commands from the gateway before going to sleep. Currently the remote listens for commands for wireless programming and changing a few parameters like how often to check the sensor. By only leaving the receiver on for a short time after transmitting data I can have the CPU and radio sleep most of the time and save a lot of power.
If your project allows you to use this technique I recommend it - it's working well for me.
BTW, the example code for wireless programming released by Felix is a push design that requires the target (remote) Moteino to be listening a lot in order to receive the new sketch pushed out by the Python script / gateway. I had to tweak the gateway sketch and the Python program to a pull design where they sit and wait for a transmission from the target remote and then initiate the wireless programming. It took some trial and error but it works pretty good for me.
I will put my code up on Github soon. The code is messy right now so I need to clean it up before release.
All great tips Kris, I see you keep improving my code releases :)
Quote from: KanyonKris on February 19, 2014, 03:17:12 PM
Here's what I'm doing to reduce power in my Moteino project:
I have a gateway and one remote Moteino. The remote sleeps for 15 seconds then wakes up and checks a sensor. If the sensors is the same state (i.e. was high, now it's still high) the Moteino does nothing and goes back to sleep. If the state has changed (i.e. was high, now low) the remote transmits this change to the gateway, and after receiving acknowledgement it listens for a few hundred milliseconds (I use 200) for commands from the gateway before going to sleep. Currently the remote listens for commands for wireless programming and changing a few parameters like how often to check the sensor. By only leaving the receiver on for a short time after transmitting data I can have the CPU and radio sleep most of the time and save a lot of power.
If your project allows you to use this technique I recommend it - it's working well for me.
BTW, the example code for wireless programming released by Felix is a push design that requires the target (remote) Moteino to be listening a lot in order to receive the new sketch pushed out by the Python script / gateway. I had to tweak the gateway sketch and the Python program to a pull design where they sit and wait for a transmission from the target remote and then initiate the wireless programming. It took some trial and error but it works pretty good for me.
I will put my code up on Github soon. The code is messy right now so I need to clean it up before release.
Thank you for the reply and Felix's help. The method you are using might not fits to my project. I'm using about 10 Moteinos with RFM69W to build a long distance transmission line. The first Moteino is sending out packets every 15mins and powered with solar panels. The last (end) Motenio is attached to Raspberry Pi as a gateway for FTP server which is also powered by solar panels. However, all the Moteinos at the middle are battery powered. All they do just routing the packets one by one from the first Moteino and transmit to the gateway Motenio. Power consumption is one of the biggest issue I have for the middle Moteinos.
[1st Moteino] ---> [2nd M] ---> [3rd M]-----------------------> [Last Motenio w/ RPi]
Here are two sleep method I have tried:
First method. set the RFM69W to RX mode and then sleep the Moteino. Once a packet is received, it will pass them to the next Moteino and then go back to sleep mode. This method does the job but since the RFM69W is in the RX mode, it is taking 16mA even the Moteino is in sleep mode.
Second method. Let the RFM69W to listen for packets. Once a packet is received, it will pass them to the next Moteino and then sleep BOTH RFM69W and Moteino for 14mins. Since the first Moteino is sending out packets every 15mins. So there is one minute time gap to prepare for coming packets. It takes only 200uA while they both in sleep mode. However, if there is no packets sending from the previous Moteino after the Moteino and RFM69W wake up from sleep mode, they will stay on all time until a packet is received or the battery is dead.
I'm currently seeking a better solution for this project. Do you have any better ideas? thank you so much for your time.
#include <RFM69.h>
#include <SPI.h>
#include <SPIFlash.h>
#include "LowPower.h"
#define NODEID 2
#define NETWORKID 100
#define GATEWAYID 3
#define FREQUENCY RF69_915MHZ //Match this with the version of your Moteino! (others: RF69_433MHZ, RF69_868MHZ)
#define KEY "thisIsEncryptKey" //has to be same 16 characters/bytes on all nodes, not more not less!
#define LED 9
#define SERIAL_BAUD 115200
RFM69 radio;
bool promiscuousMode = false; //set to 'true' to sniff all packets on the same network
typedef struct {
float temp1; //temperature maybe?
float temp2;
float analog3;
} Payload;
Payload theData;
void setup() {
Serial.begin(SERIAL_BAUD);
delay(10);
pinMode(wakeUpPin, INPUT);
radio.initialize(FREQUENCY,NODEID,NETWORKID);
//radio.setHighPower(); //uncomment only for RFM69HW!
radio.encrypt(KEY);
radio.promiscuous(promiscuousMode);
char buff[50];
sprintf(buff, "\nListening at %d Mhz...", FREQUENCY==RF69_433MHZ ? 433 : FREQUENCY==RF69_868MHZ ? 868 : 915);
//Serial.println(buff);
}
byte ackCount=0;
void loop() {
if(radio.receiveDone()){
getdata();
radio.sleep();
//sleep for 14mins
for(int i = 0; i < 105; i++){
LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);
}
}
}
void Blink(byte PIN, int DELAY_MS)
{
pinMode(PIN, OUTPUT);
digitalWrite(PIN,HIGH);
delay(DELAY_MS);
digitalWrite(PIN,LOW);
}
void getdata(){
if (radio.DATALEN != sizeof(Payload))
Serial.print("Invalid payload received, not matching Payload struct!");
else
{
theData = *(Payload*)radio.DATA; //assume radio.DATA actually contains our struct and not something else
Serial.print(theData.temp1);
Serial.print(" , ");
Serial.print(theData.temp2);
Serial.print(" , ");
Serial.print(theData.analog3);
delay(100);
radio.send(GATEWAYID, (const void*)(&theData), sizeof(theData));
}
Serial.println();
Blink(LED,3);
}
This is a classic problem for meshing wireless networks. Your middle nodes are routers. They will need to stay in RX otherwise your mesh has failure points all over.
There are a few approaches.
One is to reduce the duty cycle as much as you can on the battery operated nodes, then the nodes where power is plenty can try hard to reach those routers (up to the inverse of the duty cycle time - ie if you sleep the routers 900ms and keep them in RX 100ms then end nodes would try 10 times at 100ms intervals, assuming one of the slots will be a hit).
Another approach is to keep the routers solar powered as well, then that simplifies your mesh topology issues, and you can assume 100% duty cycle with much less required redundancy.
I would go with the second approach especially if your deployment will be semi permanent or permanent.
Such a wide spread WSN requires autonomy and redundancy. It will cost you a lot more $ to drive up there to each one to change batteries, even once in a few months. A lot more than a few solar panels, in the long run.
Quote from: Felix on February 19, 2014, 07:49:47 PM
All great tips Kris, I see you keep improving my code releases :)
If I were you I'd hold off calling my hacks "improving" until you've seen my code. :)
xujianningkp, I like Felix's ideas and hope you can use them.
Is there no way you can make the link in one hop with directional antennas on each end? Back in the day I got WiFi to go over a mile with my home-made directional antennas.
Quote from: Felix on February 19, 2014, 09:59:58 PM
Another approach is to keep the routers solar powered as well, then that simplifies your mesh topology issues, and you can assume 100% duty cycle with much less required redundancy.
I would go with the second approach especially if your deployment will be semi permanent or permanent.
Such a wide spread WSN requires autonomy and redundancy. It will cost you a lot more $ to drive up there to each one to change batteries, even once in a few months. A lot more than a few solar panels, in the long run.
I was planning to install small solar panels on each of them. However, All of these middle Moteinos will be install in a forest where the most direct sunlight is blocking by tall trees. I might just add more batteries in parallel to increase the capacities...Thank you for your advise :)
Quote from: KanyonKris on February 19, 2014, 11:54:55 PM
Is there no way you can make the link in one hop with directional antennas on each end? Back in the day I got WiFi to go over a mile with my home-made directional antennas.
The entire system will be installed in a wild life state park where the most area is coved by trees. They don't allow any object (antenna tower) stick into the ground more than 6 inches and those trees are very tall. Otherwise, Ubiquiti Nanostation will be the best solution for long distance transmission..... just plug n' play 8) Thank you so much for your help too :)
Interesting. I wonder what the effect of all the trees, branches, leaves will have on the RF.
Have you already done any testing in that forest setting?
Unless the forest is very dense there will still be plenty of light for some solar panels. You will not need a lot of direct sunlight, and these days the solar cells are very good. Just pick a size of panel that will provide enough to charge a lipo battery for the night and keep everything running during the day. Maybe a small panel like 1-3W should be plenty, just a guess :P
Quote from: Felix on February 20, 2014, 11:00:15 AM
Interesting. I wonder what the effect of all the trees, branches, leaves will have on the RF.
Have you already done any testing in that forest setting?
Unless the forest is very dense there will still be plenty of light for some solar panels. You will not need a lot of direct sunlight, and these days the solar cells are very good. Just pick a size of panel that will provide enough to charge a lipo battery for the night and keep everything running during the day. Maybe a small panel like 1-3W should be plenty, just a guess :P
I will test them with the solar panels and see how long the battery will last for. Thanks for your advise :)
Quote from: KanyonKris on February 19, 2014, 03:17:12 PM
Here's what I'm doing to reduce power in my Moteino project:
I have a gateway and one remote Moteino. The remote sleeps for 15 seconds then wakes up and checks a sensor. If the sensors is the same state (i.e. was high, now it's still high) the Moteino does nothing and goes back to sleep. If the state has changed (i.e. was high, now low) the remote transmits this change to the gateway, and after receiving acknowledgement it listens for a few hundred milliseconds (I use 200) for commands from the gateway before going to sleep. Currently the remote listens for commands for wireless programming and changing a few parameters like how often to check the sensor. By only leaving the receiver on for a short time after transmitting data I can have the CPU and radio sleep most of the time and save a lot of power.
If your project allows you to use this technique I recommend it - it's working well for me.
BTW, the example code for wireless programming released by Felix is a push design that requires the target (remote) Moteino to be listening a lot in order to receive the new sketch pushed out by the Python script / gateway. I had to tweak the gateway sketch and the Python program to a pull design where they sit and wait for a transmission from the target remote and then initiate the wireless programming. It took some trial and error but it works pretty good for me.
I will put my code up on Github soon. The code is messy right now so I need to clean it up before release.
Hi KanyonKris,
I am interested to implement wireless programming on a sleeping moteino. I was struggling with this yesterday but I did not succeed. It seems you have a working code and I am just wondering if it is available now?
Thanks,
Daniel
backdani, my apologies, I forgot about this. I'm pretty busy but I'll see if I can clean up the code and post it.