• State Verified Answer
  • Replies 4 replies
  • Subscribers 88 subscribers
  • Views 802 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 263617
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Thread MAC errors

krbvroc1

I have setup a small thread network (1 FTD Router, 1 Border Router, 2 MTD Dongles) using the Nordic provided RaspPi border router image.

I have been attempting to get Thread based OTA DFU updates. I am finding a 450KB image is taking from 12 - 35 minutes.

Running wireshark on the RaspPi, I notice a fairly frequent retranmission even though wireshark sees the response. Each time this happens the IoT CoAP stack pauses 5 seconds.

As you can see from the snippet below - the RaspPi did reply with the ACK. Yet it would appear the DFU target did not process that ACK.

While trying to troubleshoot this, I have noticed on the nrf52 devices, using the 'counters mac' CLI command that RxTotal -> RxErrFcs increases quite a bit.

Example: During the DFU - RxUnicast: 6864 / RxErrFcs: 283 which is about 4% FCS rate.

I also notice on the RaspPi border router the command 'wpanctl get Thread:NeighborTable:ErrorRates' shows a high FrameErrRate - many times between 10-30%.

I am not sure what to look at next to determine what is going on.

Parents
  • 0

    Hello,

    Would it be possible to upload the sniffer trace that your screenshot comes from?

    BR,

    Edvin

  • +1 in reply to Edvin

    After further troubleshooting, the high frame error rate and wireshark retransmission relate to a nearby Logitech Bluetooth Dongle used by my wireless headset.

    Do you have any info on what a typical thread OTA DFU speed should be so I have a baseline / expectation? I do see in the Nordic background DFU code there is a random delay of 0 .. 128ms added per block, so that is one bottleneck.

    Also is there a way to reduce the 5 second retransmission timeout for the DFU process? From the wireshark you can see all retransmissions are done in under 50msecs.

  • 0 in reply to krbvroc1

    I am not sure of the figures, but I know that the DFU in our low power network protocols are very (!) slow. The reason for this is that the packets should reach all relevant nodes in the network, and it needs to have time for retransmissions. The sender (DFU Master) is not aware of any delays that occurs within the network (retransmissions), which is why it is kind of slow.

    The advantage of these network DFU protocols is that it can update a large number of nodes at the time. E.g. if you have a room with 100 light bulbs, they will all be updated at the same time. In addition, the old application is running while the application is being updated. So in general, the need for a fast DFU is not that large. If you want to test different firmwares during development, you should definitely just use a programmer.

    Best regards,

    Edvin

Reply
  • 0 in reply to krbvroc1

    I am not sure of the figures, but I know that the DFU in our low power network protocols are very (!) slow. The reason for this is that the packets should reach all relevant nodes in the network, and it needs to have time for retransmissions. The sender (DFU Master) is not aware of any delays that occurs within the network (retransmissions), which is why it is kind of slow.

    The advantage of these network DFU protocols is that it can update a large number of nodes at the time. E.g. if you have a room with 100 light bulbs, they will all be updated at the same time. In addition, the old application is running while the application is being updated. So in general, the need for a fast DFU is not that large. If you want to test different firmwares during development, you should definitely just use a programmer.

    Best regards,

    Edvin

Children
No Data
Related