MTU Throughput test on custom board

RE: MTU Throughput test on custom board

CheMax — Mon, 21 Jan 2019 09:21:24 GMT

Hi,

So, I made minimal changes to the project of the example, namely: I refused to press the button, but just made a call to the desired configuration at the start. That was enough.

Further, several experiments were conducted with this code and obtained the following results:
1. PDK (tester) + PDK (dummy): average 500 kbit\s on distance ~10m;

2. PDK (tester) + Our board (dummy) average 450 kbit\s on distance ~10m;

3. Our dongle (tester) + Our board (dummy) average 80 kbit\s on distance ~3m;

Problem device found! Waiting for an answer with recommendations from Fanstel.

RE: MTU Throughput test on custom board

Kenneth — Wed, 16 Jan 2019 14:44:52 GMT

Sounds like a good plan to try to find if it's dongle or main device that the problematic design here.

If the max range is only 7m, then it is very likely that the problem is poor link budget. So maybe you can also contact module manufacturer and ask them to review your module placement in your design.

If you send both dongle and main device to us we likely can measure the antenna and output power on both boards and provide recommendations.

Best regards,
Kenneth

RE: MTU Throughput test on custom board

CheMax — Wed, 16 Jan 2019 11:44:08 GMT

Yes, we have it. Max range is about 7m.

But we can not understand what the problem is:
1. our production dongle on module BT840 (nrf52840) with apache stack;
2. not quite a good option psb main device (the presence of shield, battery nearby);
Therefore, we want to exclude one option from consideration, replacing it with a proven node (in this case, the PDK).

Well, I will try to replace the board description file with my own. I think in one or two days I will have a test result

RE: MTU Throughput test on custom board

Kenneth — Wed, 16 Jan 2019 09:09:35 GMT

In essence you should only need to modify the board file:

http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.2.0%2Fsdk_for_custom_boards.html&cp=4_0_0_1_5

Have you run any max range on your board and compared with DK?

RE: MTU Throughput test on custom board

CheMax — Wed, 16 Jan 2019 06:34:58 GMT

Hello Kenneth,

Regarding the scheme: tracing was done according to the recommendations of the module manufacturer. The case is currently not taken into account, as it is not ready yet).

The fact that the device in case of error will wait for the new connection interval, we know, thanks to the topics on this forum and the specification 5.0. Not very convenient, but it seems to be done for the sake of small power consumption ...

In our case, even with a small connection interval (10/25/50/100 ms), the situation does not change: traffic is not stable and the average throughput is small. In our case, you need to ensure a stable flow of at least 25 kB / s.

I wanted to know if it is possible to run your demo (ble_app_att_mtu_throughput) on a user card? (i.e. use one PDK nrf52840 as a “master” and a custom board as a “slave”).
Maybe there is a code porting guide? I can do it myself, but I'm afraid I will spend too much time understanding how the project works.

best regards, Max

RE: MTU Throughput test on custom board

Kenneth — Tue, 15 Jan 2019 11:57:07 GMT

Hi,

There is really no code difference that may explain why the throughput is better at short range, the time of flight is speed of light, and the software will not be able to differentiate whether the boards are 1m or 5m apart. Based on this I can not see any code change that may explain your behavior. I think you have a marginal link budget here (maybe some reduction of a few dB due to layout, ground layer, antenna, obstructions, casing or similar..) and when you move the boards away from each other, then you get more influenced by interference source. In specific when you have large packets the risk of packet loss due to interference is increased. Also when you have a 100ms connection interval, if any packet is lost, the peers will wait until next interval before it will proceed, this means that the throughput rapidly is reduced if you have even a small increase in packet loss.

Best regards,
Kenneth