Interfacing HC-SR04 Ultrasonic Sensor with PIC16F877A

Thread Starter

Lambo Av

Joined Apr 24, 2019
63
Good morning, world!

I am currently doing this project where I need to display the distance of the obstacle from the HC-SR04 Ultrasonic Sensor on an LCD1602 based on this website below
"https://circuitdigest.com/microcont...ing-ultrasonic-sensor-hc-sr04-with-pic16f877a"
However, the sensor could not detect anything and kept displaying a distance range of 60 to 70cm, no matter how near or far the obstacle is.
Then I changed a bit of the coding which can be found in a word file "sr04code.docx".
Still, the sensor could not detect the distance, showing 000
1572080911844.png

Any idea where did I go wrong in the coding? Any help will be welcomed and Thank you
 

Attachments

Thread Starter

Lambo Av

Joined Apr 24, 2019
63
hi Lambo.
Have you confirmed with an Oscilloscope that the TX and RX signals are as expected.?, on the SR04
E
Hi, Eric. I will be confirming it soon since I do not have any with me. I will confirm it with reference to this link, am I at the right path? "
"
BTW, is there a way to confirm it in Proteus 8 as well? I would like to see the simulation as well as seeing the actual result. Thanks
 

jpanhalt

Joined Jan 18, 2008
11,087
microseconds.
Did you mean distance of the obstacle and the sensor or the "distance" as in the LCD?
What I meant was whether the counts or microseconds* change when you move the target distance. There are two steps:
1) Get counts to/from target
2) Calculate distance

If the counts change with distance to target, then the problem is a calculation error. If the counts do not change, then there is at least an error in getting the counts.

*One count = 0.8 us, so the conversion is quite simple.
 

Thread Starter

Lambo Av

Joined Apr 24, 2019
63
"What I meant was whether the counts or microseconds* change when you move the target distance. "
Nope, it doesn't

But in the code, the "time_taken = time_taken * 0.8;" is already included, so is the line has an error in programming? If yes, may I know what is it?

And I noticed
t1 = (time_taken/1000)%10;
t2 = (time_taken/1000)%10;

could t1 be (time_taken/10000)%10;? (missing zero)
Thanks
 

jpanhalt

Joined Jan 18, 2008
11,087
I just reviewed the datasheet and link for the HC-SR04 and there are several inconsistencies.

The transmitter emits an US wave at a frequency of 40Hz, this wave travels through the air and gets reflected back when it senses an object.
That is really a low frequency. Even the manufacturer's datasheet gives two values, 40 Hz and 40 kHz. Some sources say 4 MHz. With your oscilloscope, what frequency are you seeing? My guess: 40 kHz, because 40 Hz = 25 ms = 858 cm/cycle. That could cause problems.

Now we know the time taken for this wave to get reflected and come back and the speed of the US wave is also universal (3400cm/s)
The speed of sound is roughly 340 m/s (1000 ft/sec). Some of the projects use 343 m/s = 34300 cm/s. I haven't reviewed the math in your program, but that could make a difference.
 

Thread Starter

Lambo Av

Joined Apr 24, 2019
63
I just reviewed the datasheet and link for the HC-SR04 and there are several inconsistencies.


That is really a low frequency. Even the manufacturer's datasheet gives two values, 40 Hz and 40 kHz. Some sources say 4 MHz. With your oscilloscope, what frequency are you seeing? My guess: 40 kHz, because 40 Hz = 25 ms = 858 cm/cycle. That could cause problems
I connected to a function generator and supplied it with 50Hz, will that cause an error?
 

jpanhalt

Joined Jan 18, 2008
11,087
"What I meant was whether the counts or microseconds* change when you move the target distance. "
Nope, it doesn't

But in the code, the "time_taken = time_taken * 0.8;" is already included, so is the line has an error in programming? If yes, may I know what is it?

And I noticed
t1 = (time_taken/1000)%10;
t2 = (time_taken/1000)%10;

could t1 be (time_taken/10000)%10;? (missing zero)
Thanks
1) Have you set the detector up by itself and observed a change, like the video showed?

2) With a 20 MHz crystal as used in the project, each instruction cycle is 0.2 us. Assuming Timer1 runs at the instruction cycle (that's a setting you can change) with a 1:4 prescale, each count = 0.8 us. So multiplying Timer1 counts by 0.8 seconds/count will give the correct time.
 

Thread Starter

Lambo Av

Joined Apr 24, 2019
63
1) Have you set the detector up by itself and observed a change, like the video showed?

2) With a 20 MHz crystal as used in the project, each instruction cycle is 0.2 us. Assuming Timer1 runs at the instruction cycle (that's a setting you can change) with a 1:4 prescale, each count = 0.8 us. So multiplying Timer1 counts by 0.8 seconds/count will give the correct time.
1. Yes, I did, however I did not get the results wanted. It showed only me a small range of reading as seen in the photo I attached

2. I used an 8MHz crystal. So , I guess I need to multiple Timer1 to 2us to give me the correct time? If I am wrong, do guide me, thanks.
 

Thread Starter

Lambo Av

Joined Apr 24, 2019
63
Who wrote the code? Is it a verbatim copy from the original?
The one in the website is original while the one in word file is slightly edited with
int time_taken_int =0;
int distance_int = 0;

Edit: I am using 8MHz so it is #define _XTAL_FREQ 8000000, sorry about that
 

jpanhalt

Joined Jan 18, 2008
11,087
1. Yes, I did, however I did not get the results wanted. It showed only me a small range of reading as seen in the photo I attached

2. I used an 8MHz crystal. So , I guess I need to multiple Timer1 to 2us to give me the correct time? If I am wrong, do guide me, thanks.
1) I don't know what to suggest, as I have never used that module. When I have had modules that gave an output like that (e.g., an accelerometer), I tested them in an analog fashion, as in the video, to get a feeling for how they worked.

2) At 8 MHz (0.5 us/count), I would either change the prescale to 1:2 or 1:1. 1:2 will be like using a 16 MHz crystal you will have more range (maybe) but less resolution. With 1:1 you will have a little better resolution (0.5 us vs. 0.8 us), but at longer ranges, your counter may overflow. You can fix that ins code, but at this point, I would not suggest doing that.
 
Top