I'm trying to control nexa units with RF-modules connected to a raspberry pi and have written a little program in C to sniff the transmitted message from the nexa remote control. The software uses an interrupt triggered on both rising and falling edges. What puzzles me is that while I expect 660 invocations of the ISR, it's usually several hundred thousand calls (sometimes more than a million). I do detect 660 bits or thereabouts, if I compare the state with the previously state and only register the time when the state is changing. If I run the program without sending a message from the remote there is zero bits and zero ISR-calls, unless I have the WIFI-dongle close to the RF-module. So I assume that WIFI interfere with the RF-signal. Also, the receiving module is powered with 3V3, though it is labeled with 5V. My question is: can an interrupt be generated on the falling edge and the port still be in a high state and vice versa?

#include <time.h>
#include <stdio.h>  
#include <stdlib.h>
#include <stdbool.h>
#include <string.h>
#include <wiringPi.h>

#define PORT 4
#define MAX_T 100
#define BUF_SIZE 1000

static struct timespec rec[BUF_SIZE];
volatile static int n=0;
volatile static int prevx=0;
volatile static int tot=0;

void ISR(){
  tot++;//count the number of calls

  //read port and if port has changed state, record time
  int x=digitalRead(PORT);
  if(n<BUF_SIZE && x!=prevx){

int main(int argc, char **argv){

  //give some time to receive message

  //print bit# and duration in microseconds
  for(int m=1;m<n;m++){
    long t = (rec[m].tv_sec-rec[m-1].tv_sec)*1000000+(rec[m].tv_nsec-rec[m-1].tv_nsec)/1000;
  //print total nmber of bits and calls
  printf("number of bits: %d, number of calls:%d\n",n,tot);

  return 0;
  • No. Spurious triggers by poor hardware design are. Post detail of what is generating the interrupts. PS try editing your post into paragraphs - this stream-of-consciousness style id difficult to read.
    – Milliways
    Apr 12, 2017 at 23:31
  • Your logic is faulty. The ISR is called many microseconds since the edge was triggered. The value you get from a digitalRead() in the ISR is in effect random.
    – joan
    Apr 13, 2017 at 3:51
  • @joan So when the receiver transitions from LOW to HIGH it will generate a short burst of interrupts, but when the different invocations of ISR reads the port, it has settled to HIGH? Because the values seem pretty consistent with what I expect. It is a stream of consecutive HIGHs and LOWS (1111110000001111...) of right duration. It's just that I thought it would look like '101' instead of '1111110000001111'.
    – jorjan
    Apr 13, 2017 at 10:11
  • You need to be aware that the time from the interrupt edge happening to your userland process running the ISR code is 50µs+ (usually between 50-100µs, sometimes milliseconds). That's fine if your edges are much further apart. However the edges from the hobby 433MHz receivers I use are often only a few microseconds apart so may not even be seen by Linux while you are handling the previous interrupt (Linux only handles one more GPIO interrupt until the previous interrupt is handled by userland). Look at the signals with a logic analyser or piscope to gain a clearer understanding.
    – joan
    Apr 13, 2017 at 10:31
  • @joan Ok, I think I have a better picture of what is going on. Thanks a lot!
    – jorjan
    Apr 13, 2017 at 10:52

2 Answers 2


The radio receiver will be using AGC (Automatic Gain Control) to hunt for a signal and will be potentially generating hundreds of thousands of interrupts per second until a signal is actually transmitted.

I suggest you view the signal with piscope to get an idea.

For a resource efficient way of reading RF codes I suggest you look at the C and Python examples at http://abyz.me.uk/rpi/pigpio/examples.html#index_433mhz_keyfob_rx/tx

  • for further explanation, see joan's comments above
    – jorjan
    Apr 13, 2017 at 10:54

Had this problem earlier this year, got the tip from a guy at dwdev to do a "Sudo apt update -y" and a "sudo apt upgrade -y"

  • As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – Community Bot
    May 18 at 18:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.