關于單片機紅外對射和超聲波對射程序編寫的疑問

ID:944755 · 發表于 2021-7-25 15:56

大家好，第一次發帖求助，因為這個問題不知道該怎么問，所以會寫很長一段描述，請見諒…

目標：

簡單來說就是做成紅外對射，超聲波對射，距離顯示誤差可以在±10mm之間。發射端發射紅外，接收端接收到紅外后，兩者差不多同時發射超聲波，接收端能接收到發射端發射的超聲波。

材料：

接收端：12MHz的stc89C52單片機開發板一個，VS838一個，SR-04一個，LCD1602一個

發射端：11.0592MHz的stc89C52RC開發板一個，紅外發射模塊（無晶振）一個，SR-04一個

前提：

1.SR-04在Trig端提供10us左右高電平后，自動開啟模塊內部定時器，在接收完超聲波后，內部定時器結束計時并通過Echo端發送內部定時器所獲取時間的高電平，高電平持續時間即為超聲波來回一次的時間。

2.因為暫時缺設備，無法確定硬件是否有問題。所以只能先假設硬件都沒問題…

為了找到能差不多同步發送超聲波的時間點，發射端用keil4測從紅外程序到超聲波發射前所用時間。接收端則用計時器多次統計這段時間后取平均值。然后根據兩者時間差求得補償值。

使用C語言寫的，補償已經考慮到晶振、進入外部中斷前的語句時間、函數調用和退出。

之前把接收端的程序稍微修改下變成發射端程序后，我也是這么計算補償的，結果大致符合要求。但是發射端單獨寫就出現這個問題了。

發射端：約68620us

接收端：約68654us

5(進程序)+12(堆棧)+ 68571(取測得最大值)+1(TR1=0)+12(退棧)+5(再進程序)+12(再堆棧)+12(再退棧)+7(irflag判斷前幾句)+1(irflage=0)+13(timer_init)+3(distance=0)

（既然測得的最大值的補償都無法滿足，那平均值的補償就更沒有意義了）

在發射端添加補償+34us后，接收端顯示的距離還是小。

實際距離,mm	LCD顯示,mm
100	20,34
150	88,94
200	156,162
250	196,204
300	244,250

如果根據數據顯示的，直接再多補償+50mm，差不多額外+148us那顯示可以正常。

問題：

1.是因為對超聲波模塊的理解有問題嗎？

2.是因為程序哪里沒有考慮到才引起的這個額外補償嗎？

發射和接收程序見附件:

help.rar (84.29 KB, 下載次數: 10)

ID:123289 · 發表于 2021-7-26 09:55

1、看了，還不知道你問題的是什么問題？
2、【兩者差不多同時發射超聲波】收發雙方都發超波嗎？
3、你的【目標】不是已實現了嗎？該發的發了，該收的收了。
【發射端發射紅外，接收端接收到紅外后，兩者差不多同時發射超聲波，接收端能接收到發射端發射的超聲波。】
4、你提供的表中，我算了一下，用本次值 - 上次值，
分別是：68.600，67.222，40.042，48.046
同樣相差50mm，但顯示之差卻不同。
建議：先不要補償，單獨驗證：同樣相差50mm，結果差值是否一樣？如果不一樣就必須有一個規律，否則就不用再做了，永遠做不準。

ID:944755 · 發表于 2021-7-28 22:45

yzwzfyz 發表于 2021-7-26 09:55
1、看了，還不知道你問題的是什么問題？
2、【兩者差不多同時發射超聲波】收發雙方都發超波嗎？
3、你的 ...

首先感謝您的回復。
其次表示抱歉，我還以為沒人回復才沒收到消息或者提醒。

先回答您第二個問題：
我超聲波的對射是通過接收端是把SR-04的發射口擋住，發送端把另個一個SR-04接收口擋住實現的。但這個模塊要從Echo得到高電平的前提是自身Trig高電平維持10us左右。所以才會有發射端和接收端同時寫了Sonar_Send()。發射端是真正的發射超聲波，接收端只是為了讓接收端能觸發Echo，使它可以輸出高電平。

表中的LCD顯示這一列可能讓您誤解了。那是兩個值，22和34，測得的大多數情況下是在這兩個值跳。

   一開始，我并沒有加任何補償直接運行，于是得到了表中LCD顯示值。
   那我想可能是發射端（從紅外發射到Sonar_Send()之前）和接收端（從紅外接收到Sonar_Send()之前）時間差太多，使得無法同步Sonar_Send()，才導致距離顯示小的問題。
   于是根據上面計算的時間得到補償，并加在發射端中，結果和沒有補償值得到的顯示距離一樣。如果根據顯示的值，在原本補償的基礎上再加+50mm的補償，那確實可以得到。

所以，我的問題就是，為什么會有這額外的補償？先假設硬件本身沒問題，是我程序哪里沒有考慮到？

ID:844772 · 發表于 2021-7-29 11:05

firm 發表于 2021-7-28 22:45
首先感謝您的回復。
其次表示抱歉，我還以為沒人回復才沒收到消息或者提醒。

是挺有意思的，一開始還以為是溫度造成的呢。總之，我覺得，如果發射端補償，必須在接受端發出信號后，而發射端發出紅外后，發出超生前補償，才會有效。我感興趣的是148us的構成？不過你這么玩，系統延時都超過了實際計時時間，可能很難找到延時原因。

ID:944755 · 發表于 2021-7-30 23:24

glinfei 發表于 2021-7-29 11:05
是挺有意思的，一開始還以為是溫度造成的呢。總之，我覺得，如果發射端補償，必須在接受端發出信號后，而 ...

感謝您的回復，看到您的第一句，確實可以改進程序中一些問題了。

先說結論：額外補償的誤差在重新調整后減少了大約10us，變為額外補償132us。

1.當初寫的時候為了減少代碼和內存，(340m/s-->0.34mm/us)時間轉為距離的函數拆成多段乘除法處理了。
這就導致了第一層誤差。現在直接用 time * 34 /100寫了。
2.聲速溫度的問題沒有考慮到，當默認340考慮了。
這就導致第二層誤差。現在以30度，聲速350m/s處理。
總的可以減少大約10us。不過還是和之前測試一樣得額外補償+50mm(即+132us)

總之，我覺得，如果發射端補償，必須在接受端發出信號后

您這句話我不太明白...接收端發出哪個信號后？接收端的Sonar_Send?還是Sonar_Receive?
我來解釋一下我怎么寫的吧。接收端在沒有紅外前，在main里循環。發射端在按鍵按下后發送紅外，此時接收端中斷開啟，開始接受紅外數據，等全部接收完之后返回主程序，并初始化超聲波用計時器，然后運行Sonar_Send。而接收端在紅外發送完畢之后延時，等待接收端運行到Sonar_Send前，然后幾乎同時啟動Sonar_Send。

148us的構成

:
50mm--[0.34mm/us]-->148us

帳號		自動登錄	找回密碼
密碼			立即注冊

欧美极品高清xxxxhd,国产日产欧美最新,无码AV国产东京热AV无码,国产精品人与动性XXX,国产传媒亚洲综合一区二区,四库影院永久国产精品,毛片免费免费高清视频,福利所导航夜趣136

關于單片機紅外對射和超聲波對射程序編寫的疑問