0

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){
    timespec_get(&rec[n++],TIME_UTC);
    prevx=x;
  }
}

int main(int argc, char **argv){
  //initialize
  wiringPiSetup();
  wiringPiISR(PORT,INT_EDGE_BOTH,&ISR);

  //give some time to receive message
  delay(5000);

  //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;
    printf("%d:\t%d\n",m,t);
  }
  //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 '17 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 '17 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 '17 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 '17 at 10:31
  • @joan Ok, I think I have a better picture of what is going on. Thanks a lot! – jorjan Apr 13 '17 at 10:52
0

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 '17 at 10:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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