嗨，我们放弃了尝试使用MIWI栈一段时间前，现在正在使用我们自己的。数据传输/接收错误处理明显改善，但现在至少有一个左边有一个潜在的硬件问题的签名。首先是硬件；我们使用MX32加上MRF24J40MD。接收模式默认是正常的，用CRC校验。在没有其他活动的情况下，事情看起来很好，但是当有其他交通工具时，问题就出现了。大部分时间，这是超过100K包，传输处理正确。是的，我们遇到媒体繁忙，并重新传输。没问题。这是所有的期望。每一次难得的机会，一个包收到的B1（位15-8）的帧格式描述符有一个或多个位损坏。注意，我们使用短地址和泛ID执行。发送缓冲区包含正确的数据，除了B1以外，所有接收到的数据都是正确的。奇怪的是，总的数据包长度总是正确的，即使帧格式被损坏来指示长的源/目的地地址。一旦信道上的其他流量被删除/不存在，事情就再好了。我在这个论坛搜索了类似的东西，但一无所获……将戳到TH。E问题多一点，但最终可能不得不写一个SW检查收到的包。可能添加我们自己的CRC和下降传入包错配…干杯！ 以上来自于百度翻译 以下为原文 Hi,We gave up on trying to use the MiWi stack some time ago, and are now using our own. Data transmission/reception error handling has improved markedly, but there now appears to be at least one left which has the signature of a potential hardware problem. First the hardware; we use an MX32 uP with MRF24J40MD. The reception mode is left at default, which is Normal and with CRC check enforced. Without other activity on the chosen channel, things appear to work fine, but problems come around when there's other traffic. Most of the time, that is more than 100k packages, transmissions are handled correctly. Yes, we encounter media busy, and re-transmits. No problem there. That's all expected. Every once in a rare chance, a packet is received with B1 (bits 15-8) of the FrameFormat descriptor having one or more bits corrupted. Note; we use short addresses and PAN ID is enforced. The transmit buffer contains the correct data, and all received data appears to be correct except for B1. Oddly enough, the total packet length is always correct, even if the FrameFormat was corrupted to indicate a long source/destination address. Once other traffic on the channel is removed/absent, things work fine again. I searched this forum for something like this, but found nothing... Will poke at the problem a bit more, but will probably end up having to write a SW check on received packages. Possibly adding our own CRC and drop incoming packages on mismatch... Cheers!
2019-04-04 16:22
