time difference between two pins going high

[hobby_85]

Hi, i need to accurately measure the time difference it takes for two pins on my PIC 16F690 to go high. Basically what i intend to do is use the time difference to measure the distance between two points. A source sends out an RF and a ultrasonic pulse at the same time, and because US signals lag RF signals by a bit, i should get a time difference.

anyway, i have written code but the problem i have is i keep getting two sets of values for each distance. so lets say im 1.2m away, i get 11.6m or 19.05m. when im 2.4m, i get 12.8m or 20.2m. Basically for any distance away, i keep getting two answers. if i got just one, i could possibly add a 'hack' to my code to fix it, but since im getting two answers, i dont know what to do. I know its not accurate, not anyway near accurate even, but im only trying to solve the 2 answers problem for now.

ive attached my code. please please please, any help/suggestions/advice would be great. thanks all

#include <16F690.h>
#fuses INTRC, NOWDT, NOPROTECT, BROWNOUT, PUT, HS
#use delay(clock = 4000000)
#use rs232(baud=19200, xmit=PIN_B7, rcv=PIN_B5)

   int16 ctr;
   int tripped;
   int tripped1;
   long value;
   int  counter;
   float distance;
   int16 ctr1;

#int_CCP1
void  CCP1_isr(void)
{
   value = CCP_1;
   value = value + (counter * 65536);
   tripped=1;
   disable_interrupts(INT_CCP1);
}

#int_TIMER1
void  TIMER1_isr(void)
{
   counter = counter + 1;
}

void main()
{
 
   setup_adc_ports(NO_ANALOGS|VSS_VDD);
   setup_timer_1(T1_INTERNAL|T1_DIV_BY_8);
   enable_interrupts(GLOBAL);
   setup_ccp1(CCP_CAPTURE_RE);
           
   for(;;){
   
        contact_slave3(); //After this, PINC1 should go high, followed closely by PINC5
     
      for (ctr=0;ctr<65535;ctr++) {     //Wait for PINC1 to go high until timeout
         if(input(PIN_C1)) {
            set_timer1(0);              //set timer value to 0, start counting
            enable_interrupts(INT_TIMER1);
            counter=0;
            ctr=1;                      //PINC1 went high, set ctr=0, break
            break;
         }
      }
     
      if (ctr==1){                                    //at this point, C1 went high, start timer and wait for C5 to go high       
       
        enable_interrupts(INT_CCP1);                  //wait for rising edge of pinC5 until timeout       
              for (ctr1=0;ctr1<10000;ctr1++) {
                           
                  if(tripped) {
                 
                     delay_ms(200);                           
                     printf("TDOA is: %Lu us\r\n",value);                             
                     distance = (value) * (0.000008) * (348.4);
                     printf("Distance is:%f meters\r\n", distance);
                     tripped=0;
                     distance=0;
                     value=0;
                     tripped1 = 1;
                     break;
                  }
              }
             
            if (tripped1 == 0){
            printf("\r\nNO US DETECTED\r\n");
            tripped1=0;
           
            }
           
      }
      else{                             //PINC1 did not go high, error
        printf("\r\nSlave Node 3 RF signature not found\r\n");
       
      }
     
delay_ms(1000);
tripped = 0;
tripped1 = 0;
counter=0;

   }
   
   
}

 

[ChrisC]

Have you confirmed that the transmitting device really is sending both signals at the same time?

Also, what are the TDOA values you're seeing for these two measurement distances?

 

[hobby_85]

Have you confirmed that the transmitting device really is sending both signals at the same time?

Also, what are the TDOA values you're seeing for these two measurement distances?

Hey, thanks for the reply.

To answer your question, yes i have checked to see if the two signals leave the transmitter at the same time. It seems to do so. However, even if there is a slight lag in terms of one signal leaving slightly after the other, the receiving device should be able to consistently get the same lag right? the problem im getting is that for every distance, i get two consistent answers. take for example if i stand 1 meter away, i keep getting either 116514 counts or 119190 counts (or very near around them both). they calculate to become either 324.73meters or 332.20 meters. now i know they are way way way off, but if i keep getting one results, i can make an adjustment to the timer count so i get a reasonable answer. but i just cant figure out why i keep getting two answers for each one.

likewise, for 2m apart, i get:
either 119553, 333.22 meters or
325.79 meters or 116891 counts

notice that the receiver is picking up the 1 meter difference betwen well. infact, its spot on. but i dont know why 2 different answers, and why so huge?

Furthermore, the timer count difference is almost always the same for any distance: around 2663 counts

thnkas

 

[ChrisC]

To answer your question, yes i have checked to see if the two signals leave the transmitter at the same time. It seems to do so. However, even if there is a slight lag in terms of one signal leaving slightly after the other, the receiving device should be able to consistently get the same lag right?

Yes, if the lag is then consistent for all transmissions - my earlier question should perhaps have been better worded as:

Do both signals leave the transmitter with a consistent fixed delay (including none at all) between them?

I'm just thinking that, depending on how the transmitter device triggers the radio and usound emitters, there may be scope for variance in the delay between the two trigger signals being generated, and depending on how the emitter hardware works, there may then be a further variance in the delay between the emitter receiving a valid transmit signal and actually emitting something - e.g. if one or both of the emitters can only start to transmit in discrete time slots rather than immediately.

take for example if i stand 1 meter away, i keep getting either 116514 counts or 119190 counts (or very near around them both).

If the source code you posted originally is the same code you're running now, then I'm not sure how you're getting values this high. From your code, it appears that:

* The PIC is clocked at 4MHz, giving you an instruction clock of 1MHz.

* T1 is being clocked from the internal source (i.e. the instruction clock), with a prescaler of 1/8, giving a T1 clock of 125KHz and a T1 tick period of 8us.


So, if that's correct, and if we assume the RF signal arrives instantaneously, then for a 1m distance we'd have a 1/330 = 3.03ms delay before the ultrasound signal arrives, and thus the total number of T1 ticks we'd expect to receive is in the 378-379 region.


Hmm, here's a thought... given that the 330ish metre results you're actually getting correspond to a flight time of near enough 1s for the ultrasound signal, what happens to the TDOA and distance values if you change the delay_ms() call at the end of the main loop so that the receiver waits 2000ms between each loop iteration?

 

[nancyn31]

if you are working in frequancy tym domain then incease th frewquancy tym will be automatically decrease.

 

[hobby_85]

Sorry about the delay in replying. Just thought id put the things aside and come back to it. unfortunately the trick didnt work.

Do both signals leave the transmitter with a consistent fixed delay (including none at all) between them?

Well, the signals are meant to be leaving the transmitters at the same time. I have attached my code if you need to have a look. I havent put in a delay, but i might add one and see how it goes.

So, if that's correct, and if we assume the RF signal arrives instantaneously, then for a 1m distance we'd have a 1/330 = 3.03ms delay before the ultrasound signal arrives, and thus the total number of T1 ticks we'd expect to receive is in the 378-379 region.

agreed. Im not sure why its picking something this high. I know there has to be some kind of 'adjustment' made though. while the rf signal comes in straight to the microcontroller, the usound signal has to be amplified and then goes through a comparator. that might explain a bit of the delay. im just now sure if it actually takes that long though. (2 opamps and 1 comparator)

Hmm, here's a thought... given that the 330ish metre results you're actually getting correspond to a flight time of near enough 1s for the ultrasound signal, what happens to the TDOA and distance values if you change the delay_ms() call at the end of the main loop so that the receiver waits 2000ms between each loop iteration?

ive tried 5000ms between each loop iteration, still no change. still get 2 consistant results. im not sure if mentioned, but the number of timer counts between the two results are always around the same, about 2700.

heres my transmitter code. PINC5 is the CCP pin on my pic, releasing a 40khz wave.

#include <16F690.h>

#fuses INTRC, NOWDT, NOPROTECT, BROWNOUT, PUT 
#use delay(clock = 4000000)


void send_msg_master(){

   setup_ccp1(CCP_PWM);                            // Configure CCP1 as a PWM
   setup_timer_2(T2_DIV_BY_1,25,1);            // 40000 Hz     
   set_pwm1_duty(13);                              // 50% duty cycle on pin C5
   output_low(PIN_C7);                             //enable RF signal

   
   delay_ms(500);                                  //send for 500 ms
   
   output_high(PIN_C7);                            //disable RF signal
   setup_ccp1(CCP_OFF);                            //disable US signal                           

}

void main()
{


      set_tris_a(0b00000000);
      set_tris_b(0b00000000);
      set_tris_c(0b00000100);
      setup_adc_ports(NO_ANALOGS);     //Port A/C all digital outputs
      

   for(;;){

     output_high(PIN_C7);              //disable RF output signal
     setup_ccp1(CCP_OFF);              //disable US output signal 
     output_low(PIN_C3);               //turn off at start LED

      if(input(PIN_C2) == 1){          //RF message detected, reply by sending US and RF together
          
          send_msg_master();           //send message to master
          blink_led();                        //ACK sent message
     
      }

   }
   
}

Added after 2 minutes:

if you are working in frequancy tym domain then incease th frewquancy tym will be automatically decrease.

im not sure what you mean. i know increasing the frequency decreases the time.

 

[ChrisC]

the usound signal has to be amplified and then goes through a comparator. that might explain a bit of the delay. im just now sure if it actually takes that long though. (2 opamps and 1 comparator)

I suppose you could have inadvertently created a delay line, but most likely all you've done is add a few hundred ns of delay, which is inconsequential for this application.

im not sure if mentioned, but the number of timer counts between the two results are always around the same, about 2700.

Yeah, I'd noticed that too...

heres my transmitter code.

Clutching at straws here, what happens if you change the 500ms transmit time?


Have you run the receiver code in the MPLAB simulator to check that the T1 interrupt is firing every 524.288 ms as expected, and that if you manually set C5 high after 3ms of simulator time following C1 going high (i.e. to mimic a 1m range test) you get the same TDOA value as on the actual hardware?

It looks like you're using the CSS compiler which I don't have here, otherwise I'd have tried recompiling your code myself - I could try rewriting it for the Hitech compiler, but that'd mean trying to emulate the CCS supplied functions, and I'd need to know exactly what effect they had on the hardware...