Thread network technology - 04 Programming Thread network over API and sending a UDP-package
ฝัง
- เผยแพร่เมื่อ 2 ก.ค. 2024
- Thread is a network technology for wireless networks based on IPv6. It is ideally suited for home automation, Industry 4.0 and wireless sensor-actuator networks. In this video, we program a thread network via an API with the Nordic nRF5 SDK for Thread. For the programming we are using two developer board nRF52840-dk. We setting our own network parameter over the API and sending an UDP-package from one device to another.
You can support me at Patreon:
/ wsnandiot
SourceCode for UDP-example
drive.google.com/file/d/1kkJv...
Developerboard nRF52840-dk:
www.nordicsemi.com/Products/D...
nRF5 SDK for Thread and Zigbee:
www.nordicsemi.com/Products/D...
00:00 Overview
00:19 Hardware nRF52840-dk
00:49 Prepare udp_receive example
03:20 Implementation steps udp_receive example
06:18 Initialization (Logger, Scheduler, App-Timer)
07:35 Thread instance initialization
09:10 Setting network parameter (dataset, PAN ID, channel, master key, ML-prefix)
13:54 Thread network start
15:51 UDP initialization (open, bind, receive handle)
20:18 Compile, transfer and testing udp_receive example
21:19 Prepare udp_send example
23:05 Implementation steps udp_send example
23:50 Implementing udp_send function
25:46 Register button handler
27:10 Compile, transfer and testing udp_send example
28:04 Capture UDP-package with Wireshark
28:53 Outlook (CoAP) - วิทยาศาสตร์และเทคโนโลยี
Sooperub...Really wonderful and Knowledgeable...Thankyou very much....Please do more videos....
I had trouble with the udp_receive board crashing when I powered on the udp_send board. Making the "mySocket" variable in the udp_init() function static appears to resolve the issue for me (i.e., change line 113 in your example code from "otUdpSocket mySocket;" to "static otUdpSocket mySocket;"). Any idea why this might be the case for me?
Not really. mySocket is just a container with the socket information and should be available as long there is a valid reference even in the subfunctions (otUdpOpen, otUdpBind) . otUdpBind also uses mySockAddr. Did you make it static too? Did you try it with the newest Toolchain?
@@wsniot Thank you for the response! No, I did not change anything in any of the subfunctions. I just made mySocket static locally in the udp_init() function. It's really baffling to me, especially since the program crashes after that code should have executed. I turn on the board with udp_receive, verify it's working in Putty, then I turn on the other board (I have tried flashing the second board with both udp_send and udp_receive). At this point the first board crashes and is no longer responsive in Putty. The second board remains active in Putty, however. Add the static keyword to that one variable and everything works perfectly. So bizarre.
I am using v7.10a of Segger Studio and v4.2.0 of the nRF5 SDK for Thread and Zigbee. I also have v17.1.0 of the nRF SDK, and one thought I had was that perhaps there was some cross-pollination with library files, but the .map file looks like it is sourcing everything from the SDK for Thread and Zigbee.
Maybe I should do a clean reinstall and see if it behaves normally. The issue was just so curious I had to know if you had any ideas about what could cause something like that. Anyway, thanks for the great tutorial! It's helped me a lot with understanding how to implement Thread.
@@ryanknepel7970 Would be interesting if the error still occurs if you use the nrf Connect SDK with Zephyr and OpenThread. I would anyway recommend switching for new developing to the nrf Connect SDK since there is no really ongoing anymore from Nordic for the old nrf5 SDK.
@@wsniot Hmm, yeah, I'll see if I can port the code. I'm curious myself. Thanks!
Great Video, thanks a lot, i have problems with the udp initialization this seems not to be working i need to open the udp and bind it manualy, i wanted to download the source code but it requieres logins.
Thx for the comment. I had the wrong settings with the download file. Now it should work.
could you pls tell me how could i connect automatically into previously paired network after disconnected from it?
How did you disconnect from the network? Normal its reconnect after a connection loss by itself. If the device did it by programming, a new initialization (thread_init) should help.
@@wsniot
The scenario is like ,
very first i am paring both the device by pressing the key on device it self(programming is like that only ) and i can see it's connected to the network and communicating fine.
Now,Let power goes down and my device goes off and disconnected from network.
Now , the device should reconnect to the previously pair network when power up again automatically.
How it would be possible?
@@mimoghosh4400 The dataset parameters from the thread network are stored in a non volatile part of the memory on the chip. Even after flashing a new firmware it is still stored as long you are not doing a full erase of the chip before. With the function otDatasetIsCommissioned(myOtInstance) you can even check if there is already a dataset stored.
Here we are sending message via realm mesh Multicast address...how we send messge to a particular device? How we find MLEID of that devicem while sendig UDP mesaage
There are different solutions possible. For one, the MLEID should not change unless the SoC is completely erased. The MLEID can be determined with the CLI command ippaddr. However, this is not so convenient. It is better to send a broadcast request and ask for a response from a specific device (service) and get on this way the MLEID.
Theoretically, a service discovery is also specified in CoAP. However, this is not implemented in OptionThread yet. Here, too, a common solution is to implement a BroadCast discovery for a resource by your own.
Sir you mentioned " send a broadcast request and ask for a response from a specific device(service) ".. Is it ping using ff03::1? If so response is from ML-EID... Then how we can understand our specific device?... If it is not ping can you tell me more about that broadcast message to specific device and how it is implementing?
@@rohithr6462 You just send a normal UDP-Packet on the broadcast address ff03::1 and the payload could be for example "temperature". And the node with a temperature-sensor answer then this message with a unicast-message. The payload can be the own ML-EID, but you also get it in the response details.