Support for openthread send_udp till raspi socat

[tcpipchip]

I hope to make some tests soon. Do you recomenda segger Studio, zephyr platformio ou nrfconnect visual code ?

[wassfila]

@tcpipchip as you see I'm taking advantage of new features of Github to have things better sorted out. Issues are only for bugs related to the source code of the repo, this section of Discussions is appropriate of any related discussion to the repo like this one, I placed it under the category Q&A.
Back to your question, it's not a simple answer because it combines current skills, target skills and available projects you'd like to base your work on.

• What I opted for might be a bit advanced and follows the Zephyr documentation using west from the command line, with that you're free to use any editor of choice, but VSCode has major advantages like multi cursor editing, git integration and others that give it a big advantage.
• platformio is a framework I worked and like with but the reason why I dropped it is that it takes time to get underlaying frameworks to be ported to platformio itself, you'd be permanently ~ 6 M 1y behind releases. But if your target versions run on platformio and you do develop on many targets not only nRF52, then platformio is a very good choice, I have many ESP32 projects with pio https://github.com/ESP32Home
• SES or Segger Embedded Studio have many samples when it comes to nRF SDK itself and might be good for someone who feels more comfortable with IDEs, but for me they're only hiding the complexity and make some things more difficult, so I recommended for quick lessons where students have to focus on the program logic and not on the environment but not for advanced projects unless you want to base your project on something already made with SES
• nrf connect is west and Zephyr based and nRF is contributing to Zephyr so there should not be a difference in the environment, you find more samples sometimes in the nRF connect, which is only a project around Zephyr.
  here two example of project based on Zephyr that shows how you can have a clean versioning and connection with a specific Zephyr version, if you do not do that, then the one that compiles needs to know which version you used and load it by hand which is error prone
• https://github.com/HomeSmartMesh/sdk-hsm-sensortag
• https://github.com/nRFMesh/sdk-uwb-zephyr

When it comes to segger tool, when I want to debug with the generated elf file I simply switch then to OZone
https://www.homesmartmesh.com/docs/frameworks/zephyr/#debug-with-ozone

[tcpipchip]

thanks to the full e-mail :)

I am working with Zephyr NRFCONNECT on VISUAL CODE...

Investigating why not compiling when i use
CONFIG_OPENTHREAD_MASTERKEY="00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff"

thanks again!

[wassfila]

I don't think it's easy to guess for the error without reproducing it and looking at the error message. If you would like to request support in general, it's convenient if you help others by providing a link to a git commit that can reproduce the issue.
here an example
https://github.com/HomeSmartMesh/sdk-hsm-sensortag/blob/15b3c7c2ed6fb304dae89fa50b9e004bac0a1587/samples/openthread_dongle/prj.conf#L30

[tcpipchip]

Yes, but first I am first downloading the newer nrfconnect toolchain
Today looks that internet is too slow

[tcpipchip]

after about 9 hours on computer, got good progress!
Now compiling on Windows (NRFCONNECT ZEPHYR VSCODE)

Those examples, that use

send_udp(message, size);

Just send UDP on IPV6, right ? But need to enter in MESH network to transmit or not ? Or only make a broadcasting to me detect with SOCAT ?

[wassfila]

Correct, keep in mind all examples in that repo are "low power" samples that minimize Radio usage. But actually the Stack does not limit if you send only or receive only, it has smart power management to sleep and poll for rx.
To configure the stack, you really need to deeply understand each Flag or it might not behave as you expect, unless you take a ready sample. See this config section 'Network'
https://github.com/HomeSmartMesh/sdk-hsm-sensortag/blob/15b3c7c2ed6fb304dae89fa50b9e004bac0a1587/samples/openthread_tag_alive/prj.conf#L28

Once your network configured, the rest is not any how different than a normal C socket handling, I used send only for low power
https://github.com/HomeSmartMesh/sdk-hsm-sensortag/blob/15b3c7c2ed6fb304dae89fa50b9e004bac0a1587/samples/openthread_tag_alive/src/main.c#L104

But you should be able to find other examples with receive if needed.

[tcpipchip]

on example openthread_tag_sensors, on initialize i got

[00*** Booting Zephyr OS build v2.7.99-ncs1-1 ***
thread_tags/5EE011F08D862A0C{"alive":0,"voltage":0.333,"light":51.510,"temperature":0.00,"humidity":0.00,"pressure":0.00}
:00:00.002,288] ieee802154_nrf5: nRF5 802154 radio initialized
[00:00:00.106,140] fs_nvs: 8 Sectors of 4096 bytes
[00:00:00.106,140] fs_nvs: alloc wra: 0, fe8
[00:00:00.106,170] fs_nvs: data wra: 0, 0
[00:00:00.112,426] udp_client: CONFIG_NET_IPV6
thread_tags/5EE011F08D862A0C{"alive":1,"voltage":0.333,"light":51.510,"temperature":0.00,"humidity":0.00,"pressure":0.00}
,
.
.
and on udp_client.c

#define CONFIG_PEER_PORT 4243
#if !defined(CONFIG_NET_CONFIG_PEER_IPV6_ADDR)
#define CONFIG_NET_CONFIG_PEER_IPV6_ADDR "ff02::1"
#endif

and at Rasp

pi@raspberrypi:~$ socat UDP6-LISTEN:4243,fork STDOUT
I am not receceiving data...

Some tip to me to continue my study ?

[wassfila]

Yeah I had this very often and it's really hard to get it right without checking the status of each node. You have to make sure the "alive" sample has joined the network.
The most reliable way is wireshark sniffing
https://www.homesmartmesh.com/docs/networks/thread/#wireshark-sniffing

That can show you the joining transactions and then you can see the udp packet on wireshark.
Usually most common issues are

• wrong channel
• wrong master key
• other netwrok paramter
• root cause can be : not erasing the chip and keep using old saved openthread config
• on raspi side : openthread network not started
• node not within reach
• issues with docker host networking
• issues with other adapters or network functions on linux, make sure install is on a fresh new raspi and not one used for otehr network stuff before

[tcpipchip]

maybe my problem that i am using VISUAL CODE NRF, and not WEST line command

[wassfila]

No that is too broad assumption, what you're missing it is systematic verification and validation steps. Debugger, Log, Trace, Sniff,... without that, things run only by chance, and given the complexity of the task, chances become very low.
If you would like a verification with code review and without tests, then I would need an unmodified commit that includes all your environment with description of reproduction steps.

[tcpipchip]

I will mount a nrf52840 sniffer next week! Thanks

[tcpipchip]

In meantime, i replaced the vs code zephyr nrfconnect example by CLI thread udp send and SEGGER nrf52 thread UDP example and got UDP send Communication successfully. Then my problem is figure out the vs code zephyr nrfconnect to work :)
I supposed that is the masterkey PRJ compiler error

[tcpipchip]

the progress
https://nina-b3-openthread.blogspot.com/2022/03/nina-b302-transmitindo-dados-via-udp.html

[tcpipchip]

mounted sniffer

But i will need your help about how to compile without error on Visual Code NRFCONNECT :)

[tcpipchip]

I can already send MIGUEL (segger)

[tcpipchip]

more progress

[tcpipchip]

Hi,
now i am backing to VISUAL CODE + NRFCONNECT

Are you getting success to compile this on ?
https://github.com/HomeSmartMesh/sdk-hsm-sensortag/blob/15b3c7c2ed6fb304dae89fa50b9e004bac0a1587/samples/openthread_tag_alive/src/main.c

Still tryng

[wassfila]

Yes, all samples I posted on my repo are not only compiling and also tested functional, but that sample was made for a special hardware, this one here, not sure how it behaves it tested on a different HW
https://www.homesmartmesh.com/docs/microcontrollers/nrf52/thread_sensortag/

If you're using the official nRF52 usb dongle, then you should rather use samples named with _dongle like this one :
https://github.com/HomeSmartMesh/sdk-hsm-sensortag/tree/main/samples/openthread_dongle

[tcpipchip]

https://nina-b3-openthread.blogspot.com/2022/03/nina-b302-transmitindo-dados-via-udp.html (update)

[wassfila]

Nice blog, congratulations

[tcpipchip]

Hi
About MASTERKEY, i can modify it using Kconfig

About your examples, do you have some similar that one did on Segger Studio...reported in the BLOG
https://nina-b3-openthread.blogspot.com/2022/03/nina-b302-transmitindo-dados-via-udp.html

Can you help me ?

[wassfila]

Unfortunately I cannot read your blog, it's also too long for me. If you have a specific short question, you can post it here and I can answer it. As long as it is related to "support openthread send_udp till raspi socat" you can post here otherwise create a new discussion thread.
Regarding Masterkey, why would you touch the Kconfig and not simply change it in the prj.conf file like here :
https://github.com/HomeSmartMesh/sdk-hsm-sensortag/blob/15b3c7c2ed6fb304dae89fa50b9e004bac0a1587/samples/openthread_dongle/prj.conf#L30

[tcpipchip]

got succes :)

[wassfila]

Excellent, see how much wireshark is valuable to give you eyes in the dark, no one else than a sniffer can see radio wave packets 💯

[tcpipchip]

is there some UDP listen port on grafeno to test ?

[wassfila]

I don't understand the question or what "grafeno" is ? Can you post a link ?
To listen to the UDP port on the raspberry pi, I used socat tool as explained here
https://www.homesmartmesh.com/docs/networks/thread/#udp-test
I did not document how to install it as the package has the same name as the tool
here an example ``sudo apt install socat`
https://www.howtoinstall.me/ubuntu/18-04/socat/

[wassfila]

@tcpipchip I just realized that this discussion was ongoing in the wrong repo, as the nRF52_Mesh does not have any thread or Zephyr sample, we also have been referring to the sdk-hsm-sensortag which is the right one. Unfortunately I cannot transfer this same discussion, as it is a different github organization so I created a new one. It is also good if we make questions smaller and if you can mark the ones answered as answered, that probably will help other people find the same answer easier.
So I'll close this thread link it and continue it here
HomeSmartMesh/sdk-hsm-sensortag#5