Conflicts in Tx data (Thread:CLI)

RE: Conflicts in Tx data (Thread:CLI)

Hidemaru — Tue, 19 Dec 2023 03:19:36 GMT

Thanks for your reply.
I understand that adding a delay as you have advised would solve the problem.
However, I would like to understand the cause of this problem.
Due to my limited knowledge, I could not clearly identify the source code directly involved in the operation of sending messages and echoes to the console.
Therefore, I am also not certain that there is no function involving printk(or LOG_***, etc.).
I would like to know where to find the source code directly involved in the operation of sending messages and echoes to the console.
Besides the "cli_output.cpp" and "cli_output.hpp" files, are there any other files I should check?
Any hints or information you can give me would be appreciated.
Sorry to repeat the same question.

RE: Conflicts in Tx data (Thread:CLI)

AHaug — Mon, 18 Dec 2023 14:15:35 GMT

Hi,

Lets revert back a couple of steps.

The issue you're seeing is most likely due to there being too much traffic causing the messages to overlap, which is what I wanted to resolve by changing everything from printk to logging. You've stated that there are no functions containing printk, so I guess the issue is not there.

Could you try to add https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/kconfig/index.html#CONFIG_LOG_MODE_DEFERRED and see if this helps, and/or to add some delay to reduce the congestion of the messages?

Kind regards,
Andreas

RE: Conflicts in Tx data (Thread:CLI)

Hidemaru — Mon, 18 Dec 2023 07:53:42 GMT

Thanks for the advice.
I would like to reply regarding (1).
I checked the cli_output.cpp and cli_output.hpp files included in the "Openthread CLI sample" for source code that sends echoes or messages to the PC.
I thought there might be functions containing "printk", but could not find any.
For example, I think the "OutputLine" function would be applicable, but my knowledge is very limited, and I could not find the contents of the source code for these functions.
Can you please advise me where I should check?

RE: Conflicts in Tx data (Thread:CLI)

AHaug — Fri, 15 Dec 2023 14:45:45 GMT

Hi,

[quote user="Hidemaru"](1) In Thread:CLI, I cannot find the source code that sends the echo or message to the PC.
Therefore, I do not know where to modify printk/logging.
Could you please tell me which source code is applicable?[/quote]

Could you state to me what you've done and where you've looked?

[quote user="Hidemaru"](2) If I build Thread:CLI using the following (overlay-logging.conf), will it use "logging"?[/quote]

I'm not sure what you refer to here. Did you you enable the logging message the same way as it is done in lesson 3?

The overlays you're referring to is the snippets that is referred to here https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/openthread/cli/README.html#snippets

Kind regards,
Andreas

RE: Conflicts in Tx data (Thread:CLI)

Hidemaru — Wed, 13 Dec 2023 10:10:06 GMT

Thanks for the advice.
I have two questions.
(1) In Thread:CLI, I cannot find the source code that sends the echo or message to the PC.
Therefore, I do not know where to modify printk/logging.
Could you please tell me which source code is applicable?

(2) If I build Thread:CLI using the following (overlay-logging.conf), will it use "logging"?

However, when I build Thread:CLI with "overlay-logging.conf", the echoes and messages overlap.

This problem is not improved.

RE: Conflicts in Tx data (Thread:CLI)

AHaug — Tue, 12 Dec 2023 09:06:56 GMT

No worries, this lesson in the NCS academy course should show you the difference between printk and logging as well as teach you how to use them https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/lessons/lesson-3-printing-messages-to-console-and-logging/

Kind regards,
Andreas

RE: Conflicts in Tx data (Thread:CLI)

Hidemaru — Mon, 11 Dec 2023 14:53:05 GMT

Thanks for your reply.

Sorry, I do not know how to configure printk / logging.
Is it set in " prj.conf "?
Please let me know how to configure it.

RE: Conflicts in Tx data (Thread:CLI)

AHaug — Mon, 11 Dec 2023 13:59:13 GMT

Hi,

Apologies for the long wait time. It took longer than expected to find someone to discuss this with

Could you verify if you're using printk or logging for this? If you're using printk could you try to use the logging module instead? It looks like the overlapping is caused by either timing or printk related issues

Kind regards,
Andreas

RE: Conflicts in Tx data (Thread:CLI)

Hidemaru — Mon, 11 Dec 2023 08:11:41 GMT

Do you need any more information than what I have already replied to?

The device that receives a message (AAAAAA) from Decive-00 sends a message (BBBBBBBBB) to Device-00 at irregular timing.

Therefore, I assume that in Decive-00, there may be a conflict between sending an echo and sending a received message.

A device that receives a message (AAAAAA) from Decive-00 can resend the message if necessary. However, I would like to solve this problem fundamentally.

RE: Conflicts in Tx data (Thread:CLI)

Hidemaru — Wed, 06 Dec 2023 14:14:51 GMT

Thanks for your reply.

The configuration and operation of the evaluation device is described below.

I have 6 sets of evaluation devices with nrf52840 module and PC connected one-to-one by uart.

The IP address of each evaluation device is as follows.

Device-00: ???

Device-01: fe80:0:0:0:8425:5ad8:6f13:2523

Device-02: fe80:0:0:0:347b:f155:f16b:cc06

Device-03: fe80:0:0:0:dc95:61d8:a2c5:648c

Device-04: fe80:0:0:0:74ca:ef31:7d2f:f59f

Device-05: fe80:0:0:0:2851:8c5d:2f8e:b62c

The PC connected to Device-00 operates as follows using the evaluation program.

- The PC sends the message (AAAAAA) to Device-01.

- The PC sends a message (AAAAAA) to Device-02 immediately after confirming that it has received an echo of the send message command.

- If the PC does not receive the echo, it sends a message to Device-02 after 1 second.

- In the same process, the PC sends message (AAAAAA) to Devices-03, -04, and -05 in turn.

The Device that receives the message (AAAAAA) from Device-00 sends the message (BBBBBBBBB) to Device-00.

The following is what is displayed on the terminal of Device-00.

"PC>>MO" indicates data sent from PC to nrf52840 module.

"MO>>PC" indicates data sent from the nrf52840 module to the PC.

PC>>MO: ot udp send fe80:0:0:0:8425:5ad8:6f13:2523 1212 AAAAAA\r\n

MO>>PC: ot udp send fe80:0:0:0:8425:5ad8:6f13:2523 1212 AAAAAA\r\nDone\r\r\n\x1b[1;32muart:~$ \x1b[m    

PC>>MO: ot udp send fe80:0:0:0:347b:f155:f16b:cc06 1212 AAAAAA\r\n

MO>>PC: \x1b[8D\x1b[J9 bytes from \x1b[1;32muart:~$ \x1b[m\x1b[8D\x1b[Jfe80:0:0:0:8425:5ad8:6f13:2523\x1b[1;32muart:~$ \x1b[m\x1b[8D\x1b[J 1212 
　　　　\x1b[1;32muart:~$ \x1b[mot udp send fe80:0:0:0:347b:f155:f16b:cc06 1212 AAAAAA\r\nBBBBBBBBB\r\r\nDone\r\r\n\x1b[1;32muart:~$ \x1b[m

MO>>PC: \x1b[8D\x1b[J9 bytes from \x1b[1;32muart:~$ \x1b[m\x1b[8D\x1b[Jfe80:0:0:0:347b:f155:f16b:cc06\x1b[1;32muart:~$ \x1b[m\x1b[8D\x1b[J 1212 
　　　　\x1b[1;32muart:~$ \x1b[m\x1b[8D\x1b[JBBBBBBBBB\x1b[1;32muart:~$ \x1b[m\x1b[8D\x1b[J\r\r\n\x1b[1;32muart:~$ \x1b[m

PC>>MO: ot udp send fe80:0:0:0:dc95:61d8:a2c5:648c 1212 AAAAAA\r\n

MO>>PC: ot udp send fe80:0:0:0:dc95:61d8:a2c5:648c 1212 AAAAAA\r\nDone\r\r\n\x1b[1;32muart:~$ \x1b[m

PC>>OT: ot udp send fe80:0:0:0:74ca:ef31:7d2f:f59f 1212 AAAAAA\r\n

MO>>PC: ot udp send fe80:0:0:0:74ca:ef31:7d2f:f59f 1212 AAAAAA\r\nDone\r\r\n\x1b[1;32muart:~$ \x1b[m

PC>>MO: ot udp send fe80:0:0:0:2851:8c5d:2f8e:b62c 1212 AAAAAA\r\n

MO>>PC: \x1b[8D\x1b[J9 bytes from \x1b[1;32muart:~$ \x1b[m\x1b[8D\x1b[Jfe80:0:0:0:dc95:61d8:a2c5:648c\x1b[1;32muart:~$ \x1b[m\x1b[8D\x1b[J 1212 
　　　　\x1b[1;32muart:~$ \x1b[m\x1b[8D\x1b[JBBBBBBBBB\x1b[1;32muart:~$ \x1b[m\x1b[8D\x1b[J\r\r\n\x1b[1;32muart:~$ \x1b[m

MO>>PC: ot udp send fe80:0:0:0:2851:8c5d:2f8e:b62c 1212 AAAAAA\r\nDone\r\r\n\x1b[1;32muart:~$ \x1b[m

MO>>PC: \x1b[8D\x1b[J9 bytes from \x1b[1;32muart:~$ \x1b[m\x1b[8D\x1b[Jfe80:0:0:0:74ca:ef31:7d2f:f59f\x1b[1;32muart:~$ \x1b[m\x1b[8D\x1b[J 1212 
　　　　\x1b[1;32muart:~$ \x1b[m\x1b[8D\x1b[JBBBBBBBBB\x1b[1;32muart:~$ \x1b[m\x1b[8D\x1b[J\r\r\n\x1b[1;32muart:~$ \x1b[m

MO>>PC: \x1b[8D\x1b[J9 bytes from \x1b[1;32muart:~$

The data in lines 7 and 8 have overlapping a message and an echo.

The correct data is as follows.

MO>>PC: \x1b[8D\x1b[J9 bytes from \x1b[1;32muart:~$ \x1b[m\x1b[8D\x1b[Jfe80:0:0:0:8425:5ad8:6f13:2523\x1b[1;32muart:~$ \x1b[m\x1b[8D\x1b[J 1212 　
　　　　\x1b[1;32muart:~$ \x1b[m\x1b[8D\x1b[JBBBBBBBBB\x1b[1;32muart:~$ \x1b[m\x1b[8D\x1b[J\r\r\n\x1b[1;32muart:~$ \x1b[m

MO>>PC: ot udp send fe80:0:0:0:347b:f155:f16b:cc06 1212 AAAAAA\r\nDone\r\r\n\x1b[1;32muart:~$ \x1b[m

How can I fix " Thread:CLI " to solve this problem?

RE: Conflicts in Tx data (Thread:CLI)

AHaug — Tue, 05 Dec 2023 09:26:22 GMT

Hi,

Apologies for the long response time.

Could you post a screen shot showing what you see and what you expect to see in your terminal?
The two transmissions may be in conflict in this case due to the radio being busy with transmitting its previous command while you expect it to receive Could you verify if this is behavior you see in the CLI sample with modifications you've implemented?
Do you retransmit the message from the evaluation device that overlaps with the message sent to the PC? If so, could you try to increase the interval in between the retransmits

Kind regards;
Andreas