代码之家 › 专栏 › 技术社区 › Chathuranga Chandrasekara

“投票”的最佳方式是什么?

microcontroller communication algorithm

Chathuranga Chandrasekara · 技术社区 · 16 年前

这个问题与微控制器编程有关,但任何人都可以提出一个处理这种情况的好算法。

我有一个中央控制台和一组远程传感器。中央控制台有一个接收器,每个传感器有一个发射器以相同的频率工作。所以我们只能实现单工通信。

由于发射器的工作频率相同,我们不能让两个传感器同时向中央控制台发送数据。

现在我要对传感器进行编程,以执行一些“轮询”。中央控制台应该了解传感器的存在(每个传感器是否响应)

我能想象好几种方法。

在每个传感器的轮询消息之间使用相同的间隔,并随机启动传感器。所以它们不会同时传输。
使用一些圆机制。传感器1在5秒开始轮询,第二个在10秒开始轮询,等等。方法1的更正式版本。

最大数据传输速率约为4800 bps,因此我们也需要考虑这一点。

有人能想象一种减少通信链路使用的好方法来解决这个问题吗?请注意,如果需要,我们可以为每个传感器使用不同的轮询间隔。

5 回复 | 直到 16 年前

Antti Huima 16 年前

我假设你所描述的是传感器和中央单元连接到一个总线上,一次只能传递一条信息。

处理这种情况的一种正常方法是进行碰撞检测。就我所知,这就是以太网的工作原理。您尝试发送消息,然后尝试检测冲突。如果检测到碰撞,请等待随机数量(断开连接),然后重新传输,当然还要再次进行碰撞检查。

如果你不能检测到碰撞,不同的传感器可能有不同的质数的轮询间隔。这将保证每个传感器都有专用的插槽来成功轮询。当然还会有碰撞,但不需要检测到。下面是素数5、7和11的示例:

 ----|----|----|----|----|----|----|----| (5)
 ------|------|------|------|------|----- (7)
 ----------|----------|----------|-:----- (11)
                                   * COLLISION

值得注意的是,不管传感器是“同相”还是“异相”启动。

Peter Loron 16 年前

我认为你需要研究一个碰撞检测系统(LA以太网)。如果你有基于时间的同步,你依赖于控制台上的时钟和传感器,它们永远不会偏离同步。如果它们连接到一个外部的可靠时间基准,或者您花费在每一个上都有一个电池支持的RTC(昂贵),这可能是正常的。

mcdowella 16 年前

考虑使用现有协议的全部或部分,除非协议设计本身就是一个终点——除了节省时间之外,您还可以减少协议具有导致罕见的不可恢复错误的竞争条件的可能性。

在这种情况下,很多协议都会让传感器保持安静,直到主设备明确要求它们输入当前值。这使得它很容易避免碰撞,并且如果它认为丢失了一个包,或者如果它比其他传感器更感兴趣保持最新,那么它可以很容易地请求重新传输。这甚至可能比基于碰撞检测的系统提供更好的性能,尤其是当来自主系统的命令比传感器响应短得多时。如果你最后得到的是类似于Alohanet的东西(见 http://en.wikipedia.org/wiki/ALOHAnet#The_ALOHA_protocol )您会发现,在不经常传输和发生太多冲突之间的权衡迫使您使用少于50%的可用带宽。

vgru 16 年前

是否可以为每个传感器分配一个唯一的地址?

在这种情况下,您可以实现主/从协议(如 Modbus 或类似),所有设备共享相同的通信链路:

主设备是唯一可以启动通信的设备。它可以通过向所有从机广播其地址,分别轮询每个传感器(逐个)。
只有被寻址的从设备才会应答。
如果在一段时间(超时)后没有响应,则设备不可用,主设备可以轮询下一个设备。

参见: List of automation protocols

Stephen Friederichs 16 年前

几年前我在一些ZigBee系统工作过。它只有两个传感器,所以我们只是用不同的等待时间硬编码它们,让它们总是响应请求。但是,由于Zigbee有系统,因此我们考虑了以下方面:

从控制台上的公告开始:“嘿,大家,我们建立一个网络!” 节点都试图用“我是硬件地址X,可以加入吗?” 一开始这很疯狂,但是有一些随机的重试时间,最终控制台会响应所有节点:“是的,硬件地址X,你可以加入。您是节点Y,从收到数据请求时起,您将有Z毫秒的等待时间。

那就简单了。每当控制台请求数据时,节点依次响应。假设所有数据的传输所花费的时间小于所设置的轮询周期。最好不要承认这些信息。如果控制台没有响应,那么当另一个节点正试图发送数据时,节点很可能会尝试重新传输,这会使两个节点都陷入混乱。然后雪球就彻底失败了…