[参考译文] CC8520：多个网络之间的干扰

谢谢、这绝对是其中一个。

根据我的理解、本视频中不使用时隙对齐母版。 您能否解释一下为什么在本演示中不需要它们、以及如何通过调整主控时隙来改善这种情况？ TX 和 Rx 之间的距离是否比此处所示的几英尺更远？

在我的应用程序中、我认为协议从机更可能会卡在另一个从机、而协议主机更可能卡在另一个主机。 主器件往往彼此相隔较远、而从器件是无线麦克风、因此它们可以非常靠近。 如果我实施时隙对齐主站、这是否会有效地对齐协议从站的传输、以便它们不会相互干扰？ 我知道 Paen 和 LNAEN 信号的长度并不总是相同的、因此我不确定这是否会导致协议从器件未对齐、即使协议主器件已对齐。

谢谢、
Arthur

尊敬的 Arthur：

在您解释为无线麦克风时隙对齐的设置中、主设备还应有效地对齐从设备的传输。 这是因为从主器件传输的数据包大小在您的设置中的每个主器件上应该是恒定的并且相等(也许只有一个 ACK)、也有效地对齐从器件的数据。

在视频方面、我恐怕我不知道您的问题的答案、即为什么时隙对齐的主控器在该设置中不需要以及可以移动多远的 TX 和 Rx。

此致、
R.M.

尊敬的 R.M.：

您能否尝试解释数据表中的相邻信道/备用信道选择性等规格与用户手册图37中所示的干扰问题有何关系？  数据表中的选择性规格仅扩展至+/-8MHz (43dB)、但我对两个非同步 PurePath 器件在2.4GHz 频谱相对端的频率下运行时的选择性感兴趣。   

例如、我知道、在3英尺的距离处、我的器件报告的 RSSI 为-15dBm。  因此、由于最坏情况干扰的时序未对准、并且在通道1上使用-15dBm 作为干扰信号电平、如果在 RSSI 为(-15-43)=-58dBm 或更高、我应该希望仍然在通道3上接收到所需的信号。  如果所需的信号位于通道4-18上、我应该能够在更弱的 RSSI 接收到它、但我不知道这些电平会是多少、因为数据表中未指定这些电平。  

这些数字可能不准确、但如果我严重误解、您能纠正我吗？

谢谢、
Arthur

大家好、这个问题被标记为"TI 认为已解决"、但我仍在等待6月5日发布的回复。

谢谢、

Arthur

尊敬的 Arthur：

我认为您根据 AppNote 进行的分析是正确的  

根据您的示例、我假设您对2Mbps 模式感兴趣。 应用手册显示了2Mbps 和5Mbps 选择性数值、而数据表仅显示5mbps 选择性数值。 我还注意到、数据表和应用手册的差异为1dB。 (数据表将取代 AppNote)。 正确的是、数据表和应用手册仅显示+/-4MHz 和+/-8MHz 选择性值。

在您的案例中

[]接口：信道1 (距离信号8MHz)，-15dBm

[]信号：通道3，-58dBm

这符合选择性标准、即允许在8MHz 之外存在43dB 较大干扰的射频器件、并且能够接收信号。 (根据应用手册)

您是否遇到无法接收信号的情况、例如、-15dBm 干扰源正在发挥作用？

此致、

－Gunter

Gunter、

我之前没有看过这份应用手册、但它非常有用、谢谢！

在我的应用中、如果我在示波器上观察并等待两个网络的 PA_EN 信号的相位未对齐(主器件相隔3ft、从器件相隔3ft、从器件与主器件相隔20ft)、那么似乎我将始终在短距离内获得音频压降。  如果没有干扰、则系统的视线范围约为1000英尺、压降极小或无压降、因此干扰设备的影响非常显著。  这两个网络似乎无法避免相互干扰、例如一个网络进入高频带、另一个网络进入低频带。  2Mbps 是我的无线数据速率。   

我试图得出结论、干扰效应的严重程度是否与预期水平有关、或者我的具体实施是否存在某些缺陷。

谢谢、

Arthur

Gunter、

对于应用手册中的表4、我希望看到它记录了主设备和从设备之间的距离以及使用的比特率和 TX 功率。  随着链路预算的增加、PPW 可以容忍更多的干扰、这是我在实际测试中得出的结论。  您认为可以找到此信息吗？

谢谢、

Arthur  

我需要询问计时同步是如何工作的，我是否可以从 CPU 中转换该信号，以便对齐无法通过电线物理连接的 PPW 系统。  我需要知道调节同步信号的敏感性、它的周期是时隙持续时间的2倍而不是1倍、如果同步信号从时序从器件消失、在哪个点音频会中断。

每当音频片丢失时、我希望随机延迟时序从器件的传入对齐信号、当音频工作正常时、我将其单独保留。  通过这种方式、我们可能会偶然发现附近两个 PPW 网络的正确对齐方式。

你(们)好

首先、您是否了解了 Arthur 关于典型系统中干扰源通道选择性和容差的问题的最新信息。 我们需要这个答案的原因是、我们需要知道 Arthur 应该看到什么预期的系统性能。

然后、我们可以其次解决同步问题。

此致、

－Gunter

尊敬的 Arthur：

关于通道选择性、除了数据表中已有的内容之外、很难在此处提供一个良好的量化数字。 通常、当多个 PPW 网络彼此靠近运行时、您可能会遇到一些问题、因为通道非常宽。 当网络检测到相互干扰并分离到高通道和低通道以避免相互干扰时、只有当主通道遇到干扰时、这才有效。 这样做的原因是、只有主器件在发送之前执行 LBT 例程、而从器件不执行。 如果从器件与另一个从器件发生干扰、主器件将不知道这一点。

至于计时同步功能、如果您需要、CPU 可能会对其进行欺骗、因为它是正常的 H/L 信号。 在这种情况下、我建议您按照用户指南中的说明、研究信号在主用例->主用例中的工作方式、并将其用作欺骗尝试的基础。

至于 "我需要知道调节同步信号的灵敏度、为什么它的时隙持续时间是时间的2倍而不是1倍、以及如果同步信号从时序从器件消失、在什么时间点音频会中断。" 您能不能为我详细说明一下这一点，因为我不确定我完全理解您在这里所指的内容。

我认为、在确定通道是否正常时、LBT 并不是唯一的因素。  我认为在这种情况下、如果从设备正在干扰该通道、则应将错误率标记为"不好"。  你说的不是这样吗？

您在最后一段中的问题-我需要处理欺骗性计时信号。  我观察到我的定时主控信号的周期为5.5ms (我的时隙为2.75ms 的2倍)。  如果网络运行良好、我想为其时序从器件提供一个周期为5.5ms 的同步信号。  如果运行不好、我想给它一个周期为5.49ms 的同步信号。  系统是否能够承受这种情况？

M-W、

回到原来的问题、您是否说如果从站物理上靠近并相互干扰、但主站物理上不接近、那么两个 PPW 网络在频率上不会相互避免？  那么、如果主器件彼此接近、PPW 网络将在频率上相互避免？  从先前关于这篇文章的选择性讨论中我们知道、网络必须由两个以上的通道隔开、以免产生干扰。

我看不到用户指南中给出的同步时序。  我在其中一个网络配置为计时主机的情况下测量了同步计时。  占空比不是50%。  占空比根据从设备(麦克风)是否连接到网络而有所不同。  我要附加这些内容。  绿色轨迹线是计时主器件生成的计时同步信号、蓝色轨迹线是计时主器件自己的 PA_EN 信号。

如果我按照我在6月14日发布的帖子中的要求略微增加或减少同步信号的周期、网络将会发生什么情况？

尊敬的 Arthur：

首先、似乎我在同步信号上错了、信号的下降侧沿似乎是标志时隙开始的原因(当主器件开始准备下一个时隙时、信号变为高电平)。 它也仅为每个其他时隙生成。

如果增大/减小需要测试的信号、会发生什么情况、但建议是使所有主器件/从器件及时完全同步(主器件/从器件同时执行 TX)。

为了避免这种情况、主器件现在知道从器件不响应的原因(可能只是被关闭)、所以这是正确的。 可以动态调整通道映射、这意味着您在主机处理器端可以决定在通道周围移动、以避免使用其他器件。 由于只有主器件执行避让例程、切换系统中主器件/从器件的角色可能会有所裨益、因为主器件->从器件通信更可靠。 如果可能、它还有助于使用5Mbps 模式、因为这将使系统重试次数几乎增加一倍。