This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

HCSR 04 Ultrasonic Problem

Other Parts Discussed in Thread: MSP430G2452

Hi I write a code. But it didnt work. Led is burning and burning out not with range.

Where is the problem

#include "msp430g2452.h"
#define tr BIT0
#define ec BIT1
#define led BIT6
int range=0;
void main( void )
{
       WDTCTL = WDTPW + WDTHOLD; //watchdog stop
       DCOCTL=CALDCO_1MHZ;  //frequency setup
       BCSCTL1=CALBC1_1MHZ;     
        P1DIR = tr+led;
        P1OUT=0x00;   //all are zero
      for(;;)
 {
     P1OUT^=tr;                       //Trigger is on for 10 us
     __delay_cycles(10);
     P1OUT^=tr;
   if(P1IN&ec)
   {
     range++;            //when echo coming range is increasing
   }
   if(range>50)
   {
   P1OUT=led;
   range=0;
   }
   
   __delay_cycles(1000000);    //waiting some
   P1OUT^=led;
}
}
  • Code example for setting bit:

    P1OUT |= BIT;

    Resetting bit:

    P1OUT &= ~BIT;

  • it didnt solve the problem 

  • Selim Erkan Oguz said:
    it didnt solve the problem 

    I did not say it will solve the problem! :D

    Your "problem" is that whole concept of delay/range measurement is wrong. Try to THINK what actually happens, how your code executes, how you measure delay - if measure at all.

  • Ilmars said:
    Try to THINK what actually happens

    It's really the most important part.

  • Selim Erkan Oguz said:
         P1OUT^=tr;                       //Trigger is on for 10 us
         __delay_cycles(10);
         P1OUT^=tr;
       if(P1IN&ec)
       {
         range++;            //when echo coming range is increasing
       }

    You trigger once, then check the echo once and increase (or not) the range count. So depending on distance, the LED will go on either never or after the 50th output pulse. You don't measure the time it takes until the echo arrives. You only check whether there is an echo right after the trigger, and after the 50th positive check you put the LED on.
    Instead: on eeach loop first reset range, then send the trigger. Now loop until the echo comes, increasing 'range' on each loop.
  •  Hi, the problem come from measuring time, internal processor or logic measure time from burst to echo then raise the echo line for a the time needed to travel the distance.

     See here for specs

    so your code can be questionable but if you reset both range and out can work... The worst is never wait the rising edge of echo so:

    Selim Erkan Oguz said:
    #include "msp430g2452.h"
    #define tr BIT0
    #define ec BIT1
    #define led BIT6
    int range=0;
    void main( void )
    {
           WDTCTL = WDTPW + WDTHOLD; //watchdog stop
           DCOCTL=CALDCO_1MHZ;  //frequency setup
           BCSCTL1=CALBC1_1MHZ;     
            P1DIR = tr+led;
            P1OUT=0x00;   //all are zero
          for(;;)
     {
         P1OUT^=tr;                       //Trigger is on for 10 us
         __delay_cycles(10);
         P1OUT^=tr;

    Selim Erkan Oguz said:
     if(P1IN&ec)

       range=0;

      while(!(P1IN&ec))
                ;  // wait till echo is low on measure
      while(P1IN&ec)
       {
         range++;            //when echo pulse  increase range
       }
       if(range>50)
       {
       P1OUT=led;
       range=0;
       }

       
       __delay_cycles(1000000);    //waiting some

       P1OUT^=led;
       P1OUT=0; // cancel all output

    }

    }

    Questionable Wrong Suggested

  • Hi Jens also 50 is under range so it cannot be measured with a secure trigger,  again we don't know which compiler is using and how much cycle are involved on loop, assuming a 3 cycle total delay can be near 150uS.. A better approach can be forever use capture channel with a more higher resolution, IMHO is more better use MSP to send burst then measure echo from transducers.

  • Roberto Romano said:
    A better approach can be forever use capture channel with a more higher resolution,

    Sure. Generating the 'trigger' with a tiemr PWM output and at the same tiem capturing the start (and maybe even end) of the echo by two capture units will be the best way to get reliable, repeatable, jitter-free results. Even for small distances. And independently of any code runtime.

**Attention** This is a public forum