关于单片机红外对射和超声波对射程序编写的疑问

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

帐号		自动登录	找回密码
密码			立即注册