SX28 Edge Detection

Comments

• Bean Posts: 8,129

  2009-02-27 13:15 edited 2009-02-27 13:15

  Brody,
  · It is probably the noise that is causing false edges to be detected.
  
  · In TTL mode the threshold level is 1.4V. So for the short amount of time that the signal is going from 0 to 5 (or 5 to 0) and is at the 1.4V level any amount of noise will be seen as a bunch of edges.
  
  · The Schmitt trigger mode is the way to avoid this.
  
  · Also the gain in the op-amp circuit is probably causing the noise to be amplified too. If you could run the SX at 3.3V you could avoid using the op-amp, but that still may not solve the problem. Maybe you could use a schmitt triggered gate instead ?
  
  · If you could post you code we might be able to give a better solution.
  
  Bean.
  
  ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  There is a fine line between arrogance and confidence. Make sure you don't cross it...
  
  
  
  Post Edited (Bean (Hitt Consulting)) : 2/27/2009 1:28:34 PM GMT
• Brody Posts: 9

  2009-02-27 19:49 edited 2009-02-27 19:49

  I have been monitoring the inputs on a o-scope and there really isn't much noise, which is the perplexing part. Either way, I will try a different buffer configuration. I'll build a Schmidt trigger and replace the op amp with that.
  
  Here is the code. It should be noted that I am using the PWM from the RC receiver as the inputs for both RB.0 and RB.1. The idea was to have one port for rising edge and one for falling. Maybe it would be better to use one port and continuously change its edge direction at run time? Thanks
  
  

          reset Start
  
  ;------------------------------ VARIABLES ------------------------------
              
          scale    EQU     $0A
          inWidth    EQU    $0C
          counter    EQU    $0D
          Cycles    EQU    $0E
          PulseST EQU    $0F
  
  ;---------------------------- DEBUG SETTINGS ---------------------------
  
          FREQ     4_000_000
          WATCH   $08,8,UBIN;
          WATCH    counter,8,UBIN
          WATCH    Cycles,8,UBIN
          WATCH     inWidth,8,UDEC
          WATCH   PW,8,UDEC;
          
      
          org 8
  PW              ds 1;
  PER        ds 1;
  
          
          org 0
  isr                
          inc counter
          CSNE PulseST,#%00000001;Check if on a positive pulse
          inc Cycles
          mov PW, inWidth;
          mov scale, inWidth;
          RR PW;
          AND PW,#%01111111;
          RR scale;
          RR scale;
          AND scale,#%00111111;
          ADD PW, scale;
          SUB PW, #45;
          
          
  continue    CJNE counter,PW,checkPER;
          xor ra.0,#0011;
  checkPER    CJAE counter, PER, newPER;
          mov w,#-55; 
          retiw;
  
  newPER        clr counter
          mov ra.0,#0001;
          mov w,#-55; 
          retiw;
          
  
  Start        clr Cycles;
          MODE $0A; Set mode to allow for edge config
          MOV  !rb,#%11111110; RB0 set to rising, RB1 set to falling
          MODE $0C
          MOV  !rb,#%11111100;
          MODE $0F;Set Direction Config for Ports
          MOV  !ra,#%0000;     All RA are output. 
          MOV  !rb,#%00000011; RB.0 and RB.1 are input. Set rest to output
          mov ra,#%0001; 
          mov !option,#$88; 
          mov PW,#$01;
          mov PER,#68;
          clr scale;
          clr counter;
          clr PulseST;
          
  loop            MODE $09    
          MOV !rb,#%00000000
          MOV $0B,W
          CSNE $0B, #%00000001;
          CALL RiseDetect
          CSNE $0B, #%00000010;
          CALL FallDetect;
          clr W
          jmp loop
  
  RiseDetect    MOV PulseST,#%00000001;
          ret
  
  FallDetect      CJBE Cycles,#50,contFall;
          CJAE Cycles,#150,contFall;
          MOV inWidth, Cycles;
  ContFall    CLR Cycles;
          CLR PulseST;
          ret;
  
  
• Brody Posts: 9

  2009-02-27 20:13 edited 2009-02-27 20:13

  I just pulled out a function generator and simulated the RC receiver output. I confirmed my suspicion: If the rising or falling edge time is too slow, the SX28 won't respond to it in CMOS or TTL mode. Noise doesn't seem to be the issue. I think the key here is to get a high slew rate op-amp or similar.
  
  But any input on cleaning up my code would be appreciated too. This piece will be a two motor driver that differentially controls a pair of motors. It will respond off two RC inputs.
• mojorizing Posts: 249

  2009-02-27 20:17 edited 2009-02-27 20:17

  Are you using a common ground between recvr and SX?
  
  ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  Bad spellers of the world untie!
• Brody Posts: 9

  2009-02-27 21:27 edited 2009-02-27 21:27

  ^^^^
  Yes I am.
• mojorizing Posts: 249

  2009-02-28 04:55 edited 2009-02-28 04:55

  I'm not convinced your problem is due to the SX inability to trigger on a slow slew rate; however, I can't prove that right now because I'm travelling now and away from my sig. gen.· Were you inputting a sawtooth wave?
  
  What I can suggest is to download this http://forums.parallax.com/showthread.php?p=541621·into your SX and input the same signal that fails with your code.· This code is Gunther's dual pulse stretching app. which ouputs a 8ms. pulse after detecting an input pulse.· It uses similar code to yours, but doesn't ouput a proportional pulse.
  
  let us know what you find.
  
  Kevin
  
  
  
  
  
  ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  Bad spellers of the world untie!
• Brody Posts: 9

  2009-03-03 18:45 edited 2009-03-03 18:45

  No sawtooth wave. I used an Agilent Function Generator and ran a 44Hz square wave into the inputs. Then I varied the rise and fail times until the SX stopped detecting the signal.
  
  On one hand, the results don't make sense because a change to 0 to 1 or 1 to 0 is still an edge. However it may make sense since I am not sure of the specific architecture of the SX. It also may have been due to me splitting the signal to two inputs. I modified my program to use only one input. I change the edge detection now during runtime. I will report if the issue still exists with a non-split input.