Author Topic: Battery powered barrier remote controller  (Read 5796 times)

gurari

  • NewMember
  • *
  • Posts: 48
  • Country: bg
Battery powered barrier remote controller
« on: November 21, 2015, 04:42:32 AM »
Hello guys!
At the entrance of our workshop we have a barrier which the security controlls to manage the incoming/outgoing vehicles. The yard is big and the original remote control lacks range to operate the barrier from longer ditances. So I've decided to make a remote control with great range using moteino with rfm69hw module.
I've decided to use the SwitchMote code for doing that because it is very easy to add mltiple remotes. For the moment I've made minor changes to SwitchMote code so I can pulse the relays controling the barrier electrronics (pulse for open and pulse for close). Also added capabiliti to chose time needed for button to be pessed before the command to be executed - to avoid accidental key presses when the remote is in someones pocket.
For the moment all looks to work perfect - still in test period. The range is awesome. The guys from security will be happy.
The remote will be powered by Li-Po battery because it is easyer to recharge it than replace it.
In average the barrier makes 200 cycles a day.
With 500 mah battery and no power saving techniques aded in the code I can reach more than 500 cycles (still not tried to count the exact ammount) and a day of power in the remote, then I have to recharge it. A day is good enough for the moment. At night the barrier is not operated so the remote will be charged then, but I'm looking for longer life between charges.
My question is can someone help me with optimizing the power consumption? This is my first battery powered project I've ever try to make. I can also add bigger battery. Still not checked what is the range with not high power RFM69 - (i have to produce some moteinos to test)
So any help will be appreciated

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Battery powered barrier remote controller
« Reply #1 on: November 21, 2015, 07:46:01 AM »
Hello guys!
At the entrance of our workshop we have a barrier which the security controlls to manage the incoming/outgoing vehicles. The yard is big and the original remote control lacks range to operate the barrier from longer ditances. So I've decided to make a remote control with great range using moteino with rfm69hw module.
I've decided to use the SwitchMote code for doing that because it is very easy to add mltiple remotes. For the moment I've made minor changes to SwitchMote code so I can pulse the relays controling the barrier electrronics (pulse for open and pulse for close). Also added capabiliti to chose time needed for button to be pessed before the command to be executed - to avoid accidental key presses when the remote is in someones pocket.
For the moment all looks to work perfect - still in test period. The range is awesome. The guys from security will be happy.
The remote will be powered by Li-Po battery because it is easyer to recharge it than replace it.
In average the barrier makes 200 cycles a day.
With 500 mah battery and no power saving techniques aded in the code I can reach more than 500 cycles (still not tried to count the exact ammount) and a day of power in the remote, then I have to recharge it. A day is good enough for the moment. At night the barrier is not operated so the remote will be charged then, but I'm looking for longer life between charges.
My question is can someone help me with optimizing the power consumption? This is my first battery powered project I've ever try to make. I can also add bigger battery. Still not checked what is the range with not high power RFM69 - (i have to produce some moteinos to test)
So any help will be appreciated
Some observations (I'm sure others have ideas to contribute as well):
  • I doubt that you need an HW for this task as the range shouldn't be more than 100feet, I'd expect.
  • for the Barrier:  Use ListenMode as described in the UltraLow power thread.  The Barrier can sleep most of the time (drawing uA power) and only wake up when it gets a 'call' from the remote.
  • For the remote: use pinChangeInterrupt to wake up the remote processor when the button is pushed.  The remote can sleep ALL the time except when sending.
  • Barrier Relay control:  It would be best if you can use a solid state relay rather than a mechanical one because you'll get better current gain with this type of relay.  It will only take a few mA to turn on the relay.  I don't know what type of circuit you're controlling but the newer solid state relays with mosfets are available to control either AC or DC circuits

Tom

gurari

  • NewMember
  • *
  • Posts: 48
  • Country: bg
Re: Battery powered barrier remote controller
« Reply #2 on: November 21, 2015, 02:40:29 PM »
Thank you Tom!
Fast response and good points as always.
1. I also think I don't need the HW version, but I had only these  Moteinos assembled. I have to buy some parts to make some fresh Moteinos.
2. I forgot to mention that the barrier is powered by 220v so I don't have problems with the power for the receiver.
3. The core of my project is the sender unit so thank you for the advice.  When I saw that the life of battery is so short I also thought about using interrupts. Moteinos have two interrupt pins so it's perfect for me. When I go back at home I'll consider if it will be easy for me to change the code of switchmote out I'll write my own code.  I like the features of felix's code.
4. I also thought using some solid state elements in the barrier control but the relays were the things I had on hand. Since the power consumption is not problem for the moment I'll use the relays. Maude in the final version I'll use some ' high tech ' stuff.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Battery powered barrier remote controller
« Reply #3 on: November 21, 2015, 08:30:36 PM »
Nice project, photos would be great :D
I think Tom already gave the best advice so I won't add anything. But nice to see how a stock sketch can be re-purposed for other useful projects.

gurari

  • NewMember
  • *
  • Posts: 48
  • Country: bg
Re: Battery powered barrier remote controller
« Reply #4 on: November 24, 2015, 02:25:47 PM »
Sure I'll add photos to this thread. These days I have more work to do at my workplace than usual so the work over the project is going slower than I want but I think I have good progress. I wrote some lines of code so now the sender is sending commands to the receiver and then sleeps. I'm using pinChangeInterrupts (A0, D7) and for the moment all looks OK. I forgot to put the flash mem to sleep but for now battery still have power - over 30 hours (and not dead) compared to 8-10hours before.
I'm planning to add a future like in SwitchMote - to be able to add new remotes by pressing a third button in the remote or somethig like this.

gurari

  • NewMember
  • *
  • Posts: 48
  • Country: bg
Re: Battery powered barrier remote controller
« Reply #5 on: November 26, 2015, 04:26:50 AM »
Hello,
Some updates ragrding this project :)
The battery powered sender unit is still working with one charge and a lot of key presses. So for the moment I'm very happy with it. The problem now I have to deal with is to debounce the buttons. I almost don't have experience with interrupts especially pin cange interrupts. I'll be very happy if some one can help me and give some directionts what to do next.
this is the code I'm using for the moment for the sender unit:
Code: [Select]
// ***************************************************************************************
// Sample RFM69 sketch for Moteino to illustrate sending and receiving, button interrupts
// ***************************************************************************************
// When you press the button on the SENDER Moteino, it will send a short message to the
// RECEIVER Moteino and wait for an ACK (acknowledgement that message was received) from
// the RECEIVER Moteino. If the ACK was received, the SENDER will blink the onboard LED
// a few times. The RECEIVER listens to a specific token, and it alternates the onboard LED
// state from HIGH to LOW or vice versa whenever this token is received.
// ***************************************************************************************
// Hardware setup:
// ***************************************************************************************
// On the sender, hook up a momentary tactile button to D3 like this:
//          __-__
//        __|   |___
// GND ----> BTN ----> D3 (D11 on MoteinoMEGA)
// Load this sketch on the RECEIVER with NODEID=RECEIVER (adjust in config section below)
// Load this sketch on the SENDER with NODEID=SENDER (adjust in config section below)
// RFM69 library and code by Felix Rusu - felix@lowpowerlab.com
// Get libraries at: https://github.com/LowPowerLab/
// Make sure you adjust the settings in the configuration section below !!!
// **********************************************************************************
// Copyright Felix Rusu, LowPowerLab.com
// Library and code by Felix Rusu - felix@lowpowerlab.com
// **********************************************************************************
// License
// **********************************************************************************
// This program is free software; you can redistribute it
// and/or modify it under the terms of the GNU General   
// Public License as published by the Free Software       
// Foundation; either version 3 of the License, or       
// (at your option) any later version.                   
//                                                       
// This program is distributed in the hope that it will   
// be useful, but WITHOUT ANY WARRANTY; without even the 
// implied warranty of MERCHANTABILITY or FITNESS FOR A   
// PARTICULAR PURPOSE. See the GNU General Public       
// License for more details.                             
//                                                       
// You should have received a copy of the GNU General   
// Public License along with this program.
// If not, see <http://www.gnu.org/licenses/>.
//                                                       
// Licence can be viewed at                               
// http://www.gnu.org/licenses/gpl-3.0.txt
//
// Please maintain this license information along with authorship
// and copyright notices in any redistribution of this code
// **********************************************************************************

#include <RFM69.h>    //get it here: https://www.github.com/lowpowerlab/rfm69
#include <SPI.h>
#include <LowPower.h> //get library from: https://github.com/lowpowerlab/lowpower
#include <SPIFlash.h>
//*********************************************************************************************
// *********** IMPORTANT SETTINGS - YOU MUST CHANGE/ONFIGURE TO FIT YOUR HARDWARE *************
//*********************************************************************************************
#define NETWORKID     100  //the same on all nodes that talk to each other
#define RECEIVER      1    //unique ID of the gateway/receiver
#define SENDER        2
#define NODEID        SENDER  //change to "SENDER" if this is the sender node (the one with the button)
//Match frequency to the hardware version of the radio on your Moteino (uncomment one):
//#define FREQUENCY     RF69_433MHZ
#define FREQUENCY       RF69_868MHZ
//#define FREQUENCY     RF69_915MHZ
#define ENCRYPTKEY    "****************" //exactly the same 16 characters/bytes on all nodes!
#define IS_RFM69HW    //uncomment only for RFM69HW! Remove/comment if you have RFM69W!
//*********************************************************************************************
#define SERIAL_BAUD   115200
#define LED           9 // Moteinos have LEDs on D9

RFM69 radio;
SPIFlash flash(8, 0x1F65);

volatile int kur;

ISR (PCINT1_vect) // what happens with pin A0 press
 {
   kur = 1;
 }  // end of PCINT1_vect

ISR (PCINT2_vect) // what happens with pin D7 press
 {
   kur = 2;
 }  // end of PCINT1_vect

void setup ()
  {

  digitalWrite (A0, HIGH);   // enable pull-up
  digitalWrite (7, HIGH);   // enable pull-up

  Serial.begin(SERIAL_BAUD);
  radio.initialize(FREQUENCY,NODEID,NETWORKID);
#ifdef IS_RFM69HW
  radio.setHighPower(); //only for RFM69HW!
#endif
  radio.encrypt(ENCRYPTKEY);
  char buff[50];
  sprintf(buff, "\nListening at %d Mhz...", FREQUENCY==RF69_433MHZ ? 433 : FREQUENCY==RF69_868MHZ ? 868 : 915);
  Serial.println(buff);
  Serial.flush();
  pinMode(LED, OUTPUT);
 
  // pin change interrupt
  PCMSK1 |= bit (PCINT8);  // want pin A0
  PCIFR  |= bit (PCIF1);   // clear any outstanding interrupts
  PCICR  |= bit (PCIE1);   // enable pin change interrupts for A0 to A5

  PCMSK2 |= bit (PCINT23); // want pin D7
  PCIFR  |= bit (PCIF2);   // clear any outstanding interrupts
  PCICR  |= bit (PCIE2);   // enable pin change interrupts for D0 to D7 
 
  }  // end of setup

void loop ()

  Serial.flush();
  radio.sleep();
  flash.sleep();
  LowPower.powerDown(SLEEP_FOREVER, ADC_OFF, BOD_OFF);
 
  if (!digitalRead(7) || !digitalRead(A0)) { //stupid way to make the button works only when pressed, not when released
    if (kur == 1) {
      radio.sendWithRetry(RECEIVER, "Hi", 2);
      Blink(LED, 40, 2);
    } else if (kur == 2) {
      radio.sendWithRetry(RECEIVER, "Mi", 2);
      Blink(LED, 40, 4);
    }
  }
 
} // end of loop

void Blink(byte PIN, byte DELAY_MS, byte loops)
{
  for (byte i=0; i<loops; i++)
  {
    digitalWrite(PIN,HIGH);
    delay(DELAY_MS);
    digitalWrite(PIN,LOW);
    delay(DELAY_MS);
  }
}


EDIT:

For the moment I came up with a simple solution which for the moment seems to work:

Code: [Select]
  before = millis();
 
  while (!digitalRead(7) || !digitalRead(A0)) {
    //Serial.println("akaciq");
    after = millis();
  }
 
  //Serial.println(after - before);

  if (after - before > debounceTime) {
    Serial.println("ok");
    ok = 1;
  } else {
    ok = 0;
  }
 
  if (ok) {
    if (kur == 1) {
      radio.sendWithRetry(RECEIVER, "Hi", 2);
      Blink(LED, 40, 2);
    } else if (kur == 2) {
      radio.sendWithRetry(RECEIVER, "Mi", 2);
      Blink(LED, 40, 4);
    }
  }
« Last Edit: November 26, 2015, 07:36:31 AM by gurari »

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Battery powered barrier remote controller
« Reply #6 on: November 26, 2015, 10:08:05 PM »
Without a hardware debouncer all you are left with is a software approach where you just keep reading input pin to ensure it stays HIGH for a given time after an initial "settle period" when the bouncing is reasonable to happen. I think your code should work.
See the approach I took in the OLEDMote sample sketch, where I use a hardware interrupt for the debouncing.

gurari

  • NewMember
  • *
  • Posts: 48
  • Country: bg
Re: Battery powered barrier remote controller
« Reply #7 on: November 29, 2015, 02:51:43 AM »
Without a hardware debouncer all you are left with is a software approach where you just keep reading input pin to ensure it stays HIGH for a given time after an initial "settle period" when the bouncing is reasonable to happen. I think your code should work.
See the approach I took in the OLEDMote sample sketch, where I use a hardware interrupt for the debouncing.
Thank you for the reply Felix. I saw your approach, it is also in the WaterMote, but I have to read more about the interrupts and to use them in the best way. For now the code is working so I'll use it this way and when I have more knowledge about interrupts I'll make update on the remote - bosses to see that there is support of the product ;-)
I've uploaded some pictures of the remote sender here - https://drive.google.com/folder/d/0BzaosVyKEtSDN3NPVFB6SUhwYnM/edit
I've installed an activity indicator close to the buttons, mainly to know that the battery isn't dead. Also most of the people love when something is blinking when the button is pressed. There are also two indicators when the battery is charged. One for charging and one for fully charged. I have to put something inside remote to visually disconnect these two indicators because now the two dots are flowing simultaneously. USB charger is working good. I've run a test and after a week of tests (over 400 key presses a day) to fully charge the battery only 516 mwh were needed, which I think it's 1/5 of the battery capacity. This is more than good for me.
Tomorrow when I install and the receiver unit in the barrier I'll post more pictures.

Sergegsx

  • Jr. Member
  • **
  • Posts: 87
  • Country: es
Re: Battery powered barrier remote controller
« Reply #8 on: November 30, 2015, 10:20:02 AM »
Neat !
Post more pictures when you have them ! good to see battery life is so good so far.

gurari

  • NewMember
  • *
  • Posts: 48
  • Country: bg
Re: Battery powered barrier remote controller
« Reply #9 on: December 04, 2015, 04:56:43 PM »
Little update from me. This was the first week of real tests for the Moteino battery powered remote control. After work I measured the power of battery and surprisingly found a value of 4.13v after a week of use. It looks like the live of battery will be very good with relatively high load for the remote. Maybe I have to update the receiver unit to count cycles done ;-) also I uploaded a couple of pictures on the link above.

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Battery powered barrier remote controller
« Reply #10 on: December 05, 2015, 03:08:20 AM »
If you didn't have the LEDs and if you do the power management correctly the battery life should be dominated by the self discharge rate of your battery. For example if you'd use 2x aaa lithium batteries the remote will likely die for reasons other than battery failure and you'd never have to charge.

Let's say you use 50ma for 10ms to send your signal. And 100ms at 4ma to denounce the switch. That's 0.00025 mah per click. At 400 clicks per day this 0.1mah per day. Or 10000 days with 2x aaa. The debouncing could be done smarter - just as example.

This would also be a great application for coin cells. You could have a tiny remote attached to your key chain  :)

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Battery powered barrier remote controller
« Reply #11 on: December 05, 2015, 11:12:03 AM »
I posted the images in an imgur album:







gurari

  • NewMember
  • *
  • Posts: 48
  • Country: bg
Re: Battery powered barrier remote controller
« Reply #12 on: December 08, 2015, 03:36:59 AM »
Cool! Thank you Felix!
So far the project is doing well all seems to be working perfect.
I want to ask the all of you that have experiance with RF communication and especially RFM69 used in this project with Felix's lib: how easy is someone to copy the packets sent from the remote? For example, if I make the same system for my garage door can someone siff what I'm sending and the open my door? I'm using the encryption and all security benefits Felix implemented but I don't really know in depth how the process is working. I'm explaining to me that only the data in the packet is encrypted but the message is always the same so maybe it will be very easy someone to copy it and then to repeat it...
Can someone be very polite and patient to clarify a little bit this situation to me?

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Battery powered barrier remote controller
« Reply #13 on: December 08, 2015, 08:16:57 AM »
<snip>I want to ask the all of you that have experiance with RF communication and especially RFM69 used in this project with Felix's lib: how easy is someone to copy the packets sent from the remote? For example, if I make the same system for my garage door can someone siff what I'm sending and the open my door? I'm using the encryption and all security benefits Felix implemented but I don't really know in depth how the process is working. I'm explaining to me that only the data in the packet is encrypted but the message is always the same so maybe it will be very easy someone to copy it and then to repeat it...
Can someone be very polite and patient to clarify a little bit this situation to me?
If you are sending the same data each time it is relatively easy to sniff and replay. There was a thread that was active a while ago on this subject.  Someone did create a library that added some session key level security.  Search on 'session key' should produce results.

Tom