New nrf24l01+ smd

[AWI]

@alexsh1 this is what I did. Mount it in the same direction as the original

[alexsh1]

@Yveaux are these much better now? ;)))

[alexsh1]

@AWI Now I see what you mean! Thanks for heads up - really appreciated it. This is the first time I'm dealing with this transceiver in SMD

[Yveaux]

@alexsh1 much less of a challenge :satisfied:

[GertSanders]

@alexsh1 My very narrow board was built and tested today. It works fine, I posted info on the hardware forum.

I must say I feel pity for this sliver of plastic and metal ...

[alexsh1]

@GertSanders said:

@alexsh1 My very narrow board was built and tested today. It works fine, I posted info on the hardware forum.

I must say I feel pity for this sliver of plastic and metal ...

Excellent! I ordered your narrow board a few days ago as I thought it would be very useful.

One thing I can tell for sure - cutters are really well built. They are made in Japan and electrostatic safe. Most important they are not big as the ones I had before.

[Sweebee]

ordered the pro mini shields and I'm not disappointed :) As small as you can get:

[Yveaux]

@Sweebee Very nice indeed!
I'm very surprised btw that you're using 2xAA to power the PIR. Will it work reliably (no false detections), even when the batteries are running out?
I use 2xAA to power Pro Mini + nRF and an extra AA to power the PIR. This way the supply to the PIR will stay > 3V over time.

[Sweebee]

@Yveaux the pirs work fine if you only have interrupts with CHANGE. I don't use a sleep timer. If you wake it up every minute or so its unreliable yes. but only with interrupts from the pir it works fine. I have 10 pirs like this. Oldest one is from march 2015 and still running.

[Yveaux]

@Sweebee Consider yourself lucky then! I have the same issues decribed here when powering using 2xAA.
I ditched the step-up converter as it introduces too much noise and reduces battery life. The 3xAA solution seems to work reliably though.

[alexsh1]

@Sweebee

You have an excellent setup - I ordered those adapter as well at oshpark.
@Yveaux has got a point - I have been struggle to build a reliable PIR on 2xAA batteries. I have just started building it now. 1 year battery life and counting is impressive.

@Sweebee Would you care to share your code? Maybe there is anything there which gives us some clues though I believe this is more a hardware issue.

[Yveaux]

@alexsh1 said:

Would you care to share your code? Maybe there is anything there which gives us some clues though I believe this is more a hardware issue.

Agree. Apparently @Sweebee made modifications to the PIR (mainly to move some capacitors, judging from the photos) but maybe you did some more to improve battery life/stability?

[Sweebee]

I removed the left capacitor since it's not needed in 3.3v hack. And I moved the right one because otherwise it didn't fit into the case.

My sketch:

#include <MySensor.h>
#include <SPI.h>
#include <readVcc.h>

// ********** CONFIG **********************************

    #define NODE_ID AUTO          // ID of node
    #define CHILD_ID 1            // ID of sensor
    #define PIR_PIN 3             // Pin connected to the PIR
    
    #define MIN_V 2000            // empty voltage (0%)
    #define MAX_V 3200            // full voltage (100%)

// ****************************************************

MyMessage msg(CHILD_ID, V_TRIPPED);
MySensor node;

int oldBatteryPcnt;
int sentValue;
int forceSend = 0;

void setup()
{
  node.begin(NULL, NODE_ID, false);
  node.sendSketchInfo("PIR Sensor", "1.2");
  node.present(CHILD_ID, S_MOTION);
  pinMode(PIR_PIN, INPUT);
  digitalWrite(PIR_PIN, HIGH);
}

void loop()
{
  
  // Get PIR
  int value = digitalRead(PIR_PIN); // Get value of PIR
  if (value != sentValue) { // If status of PIR has changed
    resend(msg.set(value), 5); // Send PIR status to gateway
    sentValue = value;
  }

  // Send batterylevel
  sendBattery(); 

  // Sleep until something happens with the sensor
  node.sleep(PIR_PIN-2, CHANGE); 
}

// FUNCTIONS

void sendBattery() // Send battery percentage to GW
{
  forceSend++;
  int batteryPcnt = min(map(readVcc(), MIN_V, MAX_V, 0, 100), 100); // Get VCC and convert to percentage      
  if (batteryPcnt != oldBatteryPcnt || forceSend >= 20) { // If battery percentage has changed
    node.sendBatteryLevel(batteryPcnt); // Send battery percentage to gateway
    oldBatteryPcnt = batteryPcnt; 
    forceSend = 0;
  }
}

void resend(MyMessage &msg, int repeats) // Resend messages if not received by GW
{
  int repeat = 0;
  int repeatDelay = 0;
  boolean ack = false;

  while ((ack == false) and (repeat < repeats)) {
    if (node.send(msg)) {
      ack = true;
    } else {
      ack = false;
      repeatDelay += 100;
    } 
    repeat++;
    delay(repeatDelay);
  }
}

[Yveaux]

@Sweebee Only real difference I see compared to my sketch is that I'm using a timeout when sleeping, so the watchdog stays enabled while sleeping.
According to the datasheet, the AtMega power consumption is roughly 4.7uA vs 0.6uA in powerdown mode with/without watchdog enabled:

This is a significant difference, but when including the PIR & nRF in the total power consumption it is only a small part.

[Maciej Kulawik]

@Sweebee I see in the sketch, that you are enabling internal pull-up on PIR input. This means, that if PIR is not detecting movement and its output is set to zero, this pull-up resistor consumes 60uA (in the best case).

[Sweebee]

@Maciej-Kulawik in my calculations it is 6uA. The pirs use around 15-20 uA in sleep.

[Maciej Kulawik]

@Sweebee Depending on value of these pull-up resistors. I have read that they have about 50k, so with vcc=3v you will get 60u.

[Sweebee]

@Maciej-Kulawik removed the pull-up and they are all working fine :) Don't know why i have added it, in one of my oldest sketches i havent enabled it.