Some questions during the development of a DF project using the nRF52833DK

[Zihao]

Some questions during the development of a DF project using the nRF52833DK:

1. Will excessive serial output affect the performance of the microcontroller? For example, I am using Putty, and initially, the microcontroller seems to execute tasks normally. However, after some time, it becomes difficult to re-establish the connection. Could this be related to the Putty console getting stuck due to too much information being printed?

2. Does the performance of the microcontroller relate to the performance of the computer receiving the serial information? For example, will the microcontroller perform better when connected to a new computer compared to a seven-year-old unmaintained computer?

3. During the execution of the DF process, I found an issue: when setting antenna_patterns to antennas 1, 2, 3, 4 (with antenna 1 being the first antenna, that is, the communication antenna), the connection estiablishing is more efficient when antennas 1 and 2 form an acute angle with the direction of the signal source. Conversely, when antennas 1 and 2 form an obtuse angle with the direction of the  of the signal source, establishing the connection costs a long time.

My entire workflow shouldn't have any major issues I think, since I can get seemingly correct AoA and AoD using the MUSIC algorithm. I am just puzzled by these three points as I am somewhat new to this. I hope to get some answers!

[tesc]

Hi,

Will excessive serial output affect the performance of the microcontroller?

No, in general the device should not get performance degradation regardless of what equipment is connected in the other end of a serial connection. If you use hardware flow control and the other device stops accepting data over the serial connection, then more data will get buffered (depending on buffer size for the serial connection), and API calls for sending data over the serial connection may block or fail if the buffer gets full. This will not affect other parts of the microcontroller.

Does the performance of the microcontroller relate to the performance of the computer receiving the serial information? For example, will the microcontroller perform better when connected to a new computer compared to a seven-year-old unmaintained computer?

The microcontroller runs at the same clock speed regardless of other devices connected over serial. What you might experience is if the other device does not consume the data quickly enough you may be unable to queue or send data over that serial connection, but all other processes on the microcontroller should operate as usual. The only thing to be aware of is if you have blocking serial API calls, in which case code flow will not continue (for that particular thread) until it unblocks. Please note that higher priority tasks and interrupts will still run as normal.

During the execution of the DF process, I found an issue: when setting antenna_patterns to antennas 1, 2, 3, 4 (with antenna 1 being the first antenna, that is, the communication antenna), the connection estiablishing is more efficient when antennas 1 and 2 form an acute angle with the direction of the signal source. Conversely, when antennas 1 and 2 form an obtuse angle with the direction of the  of the signal source, establishing the connection costs a long time.

Establishing a connection should not differ significantly depending on antenna angles, unless the antennas are highly directional. If the antennas are directional then signal strength may be weak in some directions, which may lead to longer time to connect (or in extreme cases unability to connect) in certain directions.

If the other device is close to the plane of the antenna array, then you may see degraded quality of the direction measurement due to physical and mathematical constraints. That is, if for instance if the antenna array is mounted to a wall and the other device is also mounted to the same wall. For good measurements the device should then be somewhat out from the wall to get a better angle to the antenna array.

Regards,
Terje

[Zihao]

OK, thanks for the reply, which is really helpful. Still, I have two more questions.

1、You said, "What you might experience is if the other device does not consume the data quickly enough you may be unable to queue or send data over that serial connection, but all other processes on the microcontroller should operate as usual." So does the XCOM or Putty consume the data quickly enough? Maybe this is out of the scope of Nordic, but I am really confused. If what I've said is naive I'm sorry, I am really new to embedded system. 

2、I don't know the reason why my Putty console is getting stuck. If Putty considers the issue of too much information being printed, then could it be a problem with my microcontroller code? I am just using the "printk" code in my nRF52833 now. Does this cause any trouble?

Thanks again!

[tesc]

Hi,

Zihao said:

So does the XCOM or Putty consume the data quickly enough?

Yes. Such applications should not have any issues with serial throughput.

Zihao said:

Maybe this is out of the scope of Nordic, but I am really confused. If what I've said is naive I'm sorry, I am really new to embedded system.

No worries! Those are very resonable questions when new to the topic.

Zihao said:

I don't know the reason why my Putty console is getting stuck. If Putty considers the issue of too much information being printed, then could it be a problem with my microcontroller code? I am just using the "printk" code in my nRF52833 now. Does this cause any trouble?

There is no such thing in PuTTY as "too much information". Some terminal emulators lets you manually toggle hardware flow control, which means you can manually block the serial connection on the PC side, but that would require manual operation (and would not happen automatically.) I am not sure if PuTTY have that functionality, though. However, this is sidetracking, and has nothing to do with the issues that you are seeing.

The issues you are seeing are most likely caused by the nRF not sending, and not by the PC side not properly receiving. It could be an issue with the code, yes. Use of printk should not be an issue in and of itself, there must be something else which is the problem.

From what I understand, you are able to connect over UART, and get normal logs in the beginning, but after some time you stop receiving more data over the UART connection, and the terminal (PyTTY in this case) seems to just hang? And the PyTTY application itself is not frozen, the menus are fully functional etc., but just no more data coming? And PyTTY does not report disconnection either?

Regards,
Terje

[Zihao]

Thank you for the reply, it has really clarified things for me!

Yes, today I found a logical issue in the code running on the nRF52833, which indeed caused no more data to be sent over time. After correcting it, my PuTTY appears to be working normally, and the nRF52833 is functioning correctly as well. Thank you again for your help!