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


  • Mod

    My sketch is detecting led blinks, like http://www.mysensors.org/build/pulse_powerexcept that it is using an LDR instead of the light sensor. The LDR is connected to pin 3 on my Arduino Pro Mini 3.3V which is powered by USB through a FTDI232, using a 1Mohm pull-down resistor.

    When I run the sketch with gw.process and gw.send commented out, all blinks are correctly recorded. (I have a separate Arduino that blinks a led between 1 and 25 times per second, to simulate the energy meter). If I uncomment/activate gw.process and gw.send, I get hundreds or even thousands of extra interrupts.

    This is the output:

                                                                        1 interrupts have occurred, 2328 milliseconds since last report. 154W
    Preset is 1000 Value is ***************************************** 406
    send: 4-4-0-0 s=0,c=1,t=17,pt=7,l=5,sg=0,st=fail:154.0
    find parent
    send: 4-4-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc:
                                                                        2443 interrupts have occurred, 7148 milliseconds since last report. 123038W
    send: 4-4-0-0 s=0,c=1,t=17,pt=7,l=5,sg=0,st=fail:123038.0
                                                                        10 interrupts have occurred, 5052 milliseconds since last report. 712W
    send: 4-4-0-0 s=0,c=1,t=17,pt=7,l=5,sg=0,st=ok:712.0
                                                                        10 interrupts have occurred, 5036 milliseconds since last report. 714W
    send: 4-4-0-0 s=0,c=1,t=17,pt=7,l=5,sg=0,st=fail:714.0
                                                                        10 interrupts have occurred, 5052 milliseconds since last report. 712W
    send: 4-4-0-0 s=0,c=1,t=17,pt=7,l=5,sg=0,st=ok:712.0
                                                                        10 interrupts have occurred, 5026 milliseconds since last report. 716W
    send: 4-4-0-0 s=0,c=1,t=17,pt=7,l=5,sg=0,st=fail:716.0
                                                                        20 interrupts have occurred, 5053 milliseconds since last report. 1424W
    send: 4-4-0-0 s=0,c=1,t=17,pt=7,l=5,sg=0,st=fail:1424.0
                                                                        20 interrupts have occurred, 5052 milliseconds since last report. 1425W
    send: 4-4-0-0 s=0,c=1,t=17,pt=7,l=5,sg=0,st=fail:1425.0
                                                                        31 interrupts have occurred, 5053 milliseconds since last report. 2208W
    send: 4-4-0-0 s=0,c=1,t=17,pt=7,l=5,sg=0,st=fail:2208.0
                                                                        20 interrupts have occurred, 5052 milliseconds since last report. 1425W
    send: 4-4-0-0 s=0,c=1,t=17,pt=7,l=5,sg=0,st=fail:1425.0
                                                                        674 interrupts have occurred, 5052 milliseconds since last report. 48028W
    

    My code is available at https://github.com/mfalkvidd/arduino-energyreader/blob/678e98784a8e2331a3e7eb1e174330972ac97466/energyreader.ino

    Does anyone have any ideas why so many interrupts are generated as soon as I use the radio, or has suggestions on how to troubleshoot this?

    I am using MySensors 1.5 and Arduino IDE 1.6.5.


  • Mod

    I've been unable to find the source of the problem, but decided to just turn off interrupts while using the radio.
    The code change is available at https://github.com/mfalkvidd/arduino-energyreader/commit/32e32285fb2d7acdc3e1864442fe6c7c992b2ee6 if anyone is interested. With this change, no spurious interrupts are registered.


  • Admin

    Strange, what happens if you detach the interrupt (IRQ) pin from the radio to you Arduino?


  • Mod

    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.


  • Mod

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


  • Hero Member

    @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.


  • Mod

    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.


  • Mod

    @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.


  • Mod

    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!


  • Mod

    @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.


  • Mod

    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.



  • @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.


  • Mod

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


Log in to reply
 

Suggested Topics

0
Online

11.4k
Users

11.1k
Topics

112.7k
Posts