gw.send seems to cause interrupts on pin 3 [SOLVED]

[mfalkvidd]

Thanks for your suggestion hek. Sorry for the late reply. I has missed to turn on email notifications on replies to posts I follow.
I'll test disconnecting the IRQ pin and report back.

[mfalkvidd]

Disconnecting the IRQ pin on the NRF does not make a difference, spurious interrupts are registered anyway.

[AWI]

@mfalkvidd Any chance that the radio interferes with the loose interrupt pin? what if change the pull-up or "ground" it. An LDR isn't exactly a "logic" device (but very analog with a loooonnnng rising edge) If the voltage is around the trigger level any noise could trigger interrupts.

[mfalkvidd]

Yes, the LDR is very analog :)
I connected pin2 (IRQ) on the Arduino to ground, but I still get suprious interrupts.
You're probably right about noise around the trigger level. If I cover the LDR so it doesn't register any blinks, I get 0 interrupts regardless if I use the radio or not.

[Yveaux]

@mfalkvidd I just finished an almost identical setup as yours; a powermeter pulse counter using an LDR (on a breakout board with an opamp, in my case).
When the led blinks, the signal from the LDR 'bounces', almost like when pressing/releasing a switch. This happens for both falling/raising edges of the signal.
I found the setting of the pot controlling the level at which the opamp triggers to be very sensitive -- turning it a little more gave me loads of false triggers, or nothing at all.
If you pulse an output pin on each interrupt received and put both signals next to each other on an oscilloscope you can easily see this behavior.
What I did to solve it was add a sort of debouncing mechanism to the interrupt: when an interrupt occurs, and the previous interrupts occurred more than 2ms in the past, then it is a valid interrupt. Otherwise ignore it.

This is my interrupt handler (more or less):

static volatile uint32_t pulseCount = 0;
static volatile unsigned long pulseTs_us = micros();
void irqPulse()     
{ 
  unsigned long now_us = micros();
  // Signal will bounce.
  // We're looking for a falling edge. Assure level is low and previous
  // low edge is more than debouce time in the past.
  if (!digitalRead(PIN_PULSE) && (now_us-pulseTs_us >= 2000))
  {
    pulseTs_us = now_us;
    pulseCount++;
  }
}

If you need help on the sketch I can upload mine, but it needs some rework first.

[mfalkvidd]

Thanks Yveaux, you are probably right.

I am trying to design a node that can operate for at least a year on 2-3 AA-batteries since the energy meter is in a room where I don't have access. I'm afraid the extra wakeups would kill battery life, so I'll probably go for disabling the interrupt while using the radio instead. Missing a blink or two every five minutes isn't that much of a problem.

Glad you were able to help pinpoint the culprit though, thanks!

[Yveaux]

@mfalkvidd said:

operate for at least a year on 2-3 AA-batteries

I doubt if it will run that long when it has to wakeup for every flash of the power led. My power meter pulses 10.000 times per KWh and I consume roughly 20KWh a day (ouch, I know...) so that would wake the ATMega for 200.000 times a day (without debouncing this in hardware it becomes even 10x more or so).
Therefore I decided to power it from mains.

[mfalkvidd]

Mine also pulses 10,000 times per kWh. I "only" average 10kWh per day, but yes it will still be a lot of wakeups.

The meters from all apartments in the building are in the same room. I normally don't have access to that room. The room is dark most of the time (so no use to try solar) and I don't think I'll be allowed to connect anything to mains.

So while this has been a very interesting excercise, I might have to give up. I have acces to per-hour usage through my electricty provider's web portal already, so I might just use that.

[Daniel Oliveira]

@mfalkvidd using a clamp meter inside your apartment is not an alternative? Not as much precise I agree, but you already have the per hour information from the provider maybe you can use some clamp sensors to better find the sours of the consumptions.

[mfalkvidd]

Good idea. I would then have access to mains and I can experiment and adjust hardware and software as often as I need.