Raytac Corporation is proud to announce that our application for Wi-Fi Alliance (WFA) certification on the AN7002Q series(based on Nordic's nRF7002 IC) has been successfully approved. This achievement reinforces our commitment to providing high-quality, reliable, and standard-compliant wireless solutions. By leveraging this certification, our modules ensure seamless interoperability, enhanced security, and superior performance for a wide range of IoT applications.
Advantages of Using Raytac Modules with WFA Certification:
Reliable and Secure Connectivity – Ensures seamless communication with other Wi-Fi-certified devices while meeting industry-leading security standards for stable and secure data transmission. Faster Time-to-Market – Pre-certified modules simplify compliance processes, reducing development time. Global Market Access – Certification helps meet regulatory requirements in multiple regions, expanding business opportunities. Significant Cost-Saving – Compared to the chip-on-board approach, using Raytac’s Wi-Fi module allows direct access to the Derivative programs(please click here for more descriptions), leveraging Raytac’s CID to minimize certification costs and save time-to-market.
To learn more about Wi-Fi certifications and Wi-Fi + BLE applications, feel free to contact us anytime at service@raytac.com.
Edited by Account Manager: Ms. Mandy Chao
Raytac Corporation 勁達國際電子股份有限公司 A Bluetooth, Wi-Fi, and LoRa Module Maker based on Nordic nRF54; nRF53: nRF52; nRF51; nRF7002 Semtech Specification: SX1262
Recently we have received the FAQ: how to write MAC address into the OTP memory of AN7002Q-P Wi-Fi module? In this article, we’ll get this question explained to give customers a more smooth experience using the AN7002Q-nRF5340 Demo Board(AN7002Q-DB-5340).
Is there an existing Wi-Fi MAC address in the AN7002Q part on the DevKit?
Currently, the AN7002Q module on Raytac’s AN7002Q-DB-5340 board isn’t loaded with a Wi-Fi MAC address.
When running Wi-Fi Scan code/Station code/Shell code…etc. on NCS v2.6.0 (and later versions), the AN7002Q module must have a programed Wi-Fi MAC address to function properly.
Therefore, it’s necessary to follow the below process: 1. Program the original Wi-Fi radio test code (..\nrf\samples\wifi\radio_test) into the MDBT53 section, 2. Then write the Wi-Fi MAC address in to the AN7002Q section via command.
After this, program the original Wi-Fi Scan code/Station code /Shell code … into the 5340, and it will function properly.
*Raytac will assign 2 MAC addresses(for both 2.4GHz & 5GHz) to every AN7002Q module. *If customers don't have MAC addresses for DevKit development yet, please reach out to service@raytac.com
Scenario: Following error occurred when building the SCAN example code, flash it onto the AN7002Q-DB-5340 board, and run the test.
Solution:
When running Wi-Fi scan code on NCS v.2.6.0 or later version, the OTP memory in the AN7002Q module must have a Wi-Fi MAC address programmed in for the Wi-Fi scan functionality to work properly.
(Note: OTP is a One-Time programmable memory, which means the value can only be written once. The customer must aware of this before performing the OTP operation.)
1. Program the original Wi-Fi radio test code (..\nrf\samples\wifi\radio_test) into the MDBT53 section, then manually input and execute the following OTP read command.
wifi_radio_ficr_prog otp_read_params
If you see both MAC0 and MAC1 display a value of 0xFF, as shown in above, it means that you haven’t written the Wi-Fi MAC address into the AN7002Q’s OTP.
2. Manually issue the OTP write command to write the Wi-Fi MAC address into the OTP.
After you complete the above, use the OTP read command in below to check if the Wi-Fi MAC address value was written. The MAC0 and MAC1 should display the value you’ve input from the OTP write command.
wifi_radio_ficr_prog otp_read_params
3. Program the original Wi-Fi SCAN code back into the MDBT53, the Wi-Fi scan functionality should work properly.
To help you quickly get started with Raytac’s AN7002 Wi-Fi module and nRF5340 module, here’s a simple guide on how to set up the development and programming environment using AN7002Q-nRF5340 Demo Board(AN7002Q-DB-5340)and nRF5340 DK.
This article will cover the 4 sections below: 1. Hardware setup 2. Software Development Kit and Environment setup 3. Programming/Development 4. Flashing/Uploading firmware
Thread Group（https://www.threadgroup.org/）Founded on July 15, 2014 by Apple, Amazon, Google and six companies member. As a non-profit organization, Thread Group focuses on promoting the application of Thread in the field of Internet of Things, training developers and consumers, introducing thread technology and its advantages, and providing strict product certification tests to ensure the optimized user experience.
What is Thread?
Thread is a secure wireless mesh networking protocol. Thread solving new needs that in building a network of smart home products. Thread is based on 6LoWPAN of structure, making full use of open standards and IPv6 technology. Compared with other wireless standards, Thread has many technical advantages: safe and reliable, no single point connection failure in network, more simple connection, and low power consumption. Product developers and consumers can easily and securely form more than 250 devices into a low-power wireless Mesh network through Thread, and each device in the network can connect to the Internet and access cloud services. The Thread protocol stack is an open standard built on a series of existing standards of the Institute of Electrical and Electronics Engineers (IEEE) and the Internet Engineering Task Force (IETF), rather than a new standard (see the figure below).
Figure 1. Overview of the Thread protocol stack
General characteristics of Thread
The Thread protocol stack supports IPv6 addresses, and it can realize low-cost bridging with other IP networks. It is the best choice for low-power/battery-powered operation and communication between wireless devices. The Thread protocol stack is designed for smart home and business applications based on IP networks and can be matched with various application layers on the protocol stack.
The general characteristics of the Thread protocol stack are as follows:
• Simple and convenient network installation, start-up, and operation: Thread protocol stack supports various network topologies. It can be installed via smartphone, tablet or computer, and the installation is simple and convenient. Product installation codes ensure that only authorized devices can join the network. When arise out of routing problems, simple protocols for building and joining networks enable the system to configure itself and fix those problems.
• Security: Devices cannot join the network unless authorized, and all communications are encrypted and protected. Security protection can be used at the network layer as well as at the application layer. All Thread networks are encrypted with an authentication scheme and Advanced Encryption Standard (AES). The Thread network is more secure than any other wireless network the Thread Group has evaluated.
• Can accommodate the needs of home networks of various sizes: The number of devices in different home networks varies greatly, ranging from a few to hundreds. Network layer design aims to optimize network operation for its intended use.
• Applicable to large commercial networks: For large commercial networks, a single Thread network is not enough to meet the requirements of all applications, systems and networks. The Thread domain model allows scaling up to 10,000 Thread devices in a single deployment, achieved through the combined use of different connectivity technologies (Thread, Ethernet, Wi-Fi, etc.).
• Two-way communication for service discovery and connection: Multicast and broadcast are inefficient for wireless mesh networks. For communication with the outside world of the Mesh network, Thread provides a communication registration service, and the device can register whether it is available and whether it can provide communication services, and the client can use unicast queries to find registered services.
• Wide coverage: The coverage of a typical Thread device is usually sufficient for the average household. A design with a power amplifier can greatly improve coverage. In the physical layer (PHY), the distributed spread spectrum technology can better improve the anti-interference ability. For commercial networks, the Thread domain model allows multiple Thread networks to communicate with each other through the backbone network, so it can be expanded to cover multiple Mesh subnets.
•Designed with no single point of failure: The Thread protocol stack is designed to operate safely and reliably, even in the event of a single device failure or absence. Thread devices can also incorporate IPv6-based links (such as Wi-Fi and Ethernet) into the topology to reduce the possibility of multiple Thread partitions. This allows Thread devices to take advantage of the higher throughput, greater channel capacity and wider coverage of these infrastructure links, while still supporting low-power devices.
• Low Power Consumption: Devices communicate efficiently and have an expected lifetime of several years under normal battery usage, resulting in an improved user experience. With the right duty cycle, the device can typically run for years on AA-size batteries.
• Cost-effective: Compatible chipsets and software stacks from multiple vendors are priced for mass deployment and designed for ultra-low power consumption.
Thread home network architecture
Users communicate with the home Thread network via Wi-Fi on their home area network (HAN) or from their own device (smartphone, tablets or computer) using a cloud-based application. The figure below illustrates the main device types in the Thread network architecture.
Figure 2. Thread home network architecture
• Border Router: supports the network connection between the 802.15.4 network and other adjacent physical layers (Wi-Fi, Ethernet, etc.). The border router provides services for devices in the 802.15.4 network, including routing services and service search in the case of offline operation. There can be one or more border routers in a Thread network.
• Leader: located in the Thread network, responsible for managing the allocation and registration of router IDs, and accepting requests from terminal devices (REEDs) that meet the requirements of routers to become routers. The Leader decides which devices should be routers, and, like all routers in the Thread network, the Leader can also have sub-devices. Leader also assigns and manages router addresses through CoAP (Constrained Application Protocol). However, all information contained in the Leader is also stored in other Thread routers. Therefore, if the Leader fails or loses connection to the Thread network, another Thread router can be elected as the Leader without user intervention.
• Thread Router: Provides routing services for network devices. Thread routers also provide joining and security services for devices attempting to join the network. Thread routers cannot sleep and can also be REED by downgrading their functionality.
• REED: It can be a Thread router or a Leader, but not necessarily a border router with special attributes (such as multiple interfaces). Depending on the network topology or other specific circumstances, REED cannot be a router. REED does not relay messages, nor does it provide joining or security services to other devices on the network. If necessary, the network manages router-eligible devices and upgrades them to routers without user intervention.
• End Device: The end device that does not meet the router conditions can be FED (full end device) or MED (minimum end device). The MED does not need to be synchronized with the parent device to communicate.
• Sleepy End Device (SED): communicates only through the Thread router parent device and cannot relay messages for other devices.
• Synchronous Sleeping End Device (SSED): A type of Sleeping End Device that uses CSL in IEEE 802.15.4-2015 to keep synchronized with a parent device without using regular data requests.
Thread business network architecture
The Thread business networking model takes the same major device types as home networking and introduces new concepts. Users communicate with the business network through devices (smartphones, tablets, or computers) via Wi-Fi or the corporate network. The following figure illustrates the business network topology.
Figure 3. Thread business network architecture
Concept of business network architecture:
• The Thread domain model supports seamless integration of multiple Thread networks, and also supports seamless connection with non-Thread IPv6 networks. The main advantage of the Thread domain is that the device can flexibly join the available Thread network configured with the public Thread domain to a certain extent, and when the network scale expands or the data volume expands, this will reduce the manual planning of the network or reduce the cost of High costs for manual reconfiguration.
• Backbone Border Router (BBR) is a kind of border router used in commercial networks, it can promote the synchronization of Thread domains in multiple network sagments, and allow large-scale multicast transmission in and out of each individual network in the Thread domain. Thread networks that are part of a larger domain must have at least one "primary" BBR, and can have multiple "secondary" BBRs for failsafe redundancy. Each BBR communicates with each other through the backbone network connecting all Thread networks.
Figure 4. Thread domain model
no single point of failure
The Thread protocol stack is designed to avoid single points of failure. Although there are many devices in the system that perform special functions, the Thread network enables these devices to be replaced without affecting the network or the continued operation of the devices. For example, if a dormant end device needs a parent device to communicate, then that parent device becomes a single point of failure for communication. However, in a Thread network, a dormant end-device can choose another parent when its parent is unavailable. And this conversion process is invisible to the user.
Although the Thread system adopts a no-single-point-of-failure design, in some topologies, individual devices do not have backup functions. For example, in a system configured with a single border router, if the border router loses power, there is no way to fail over to the backup border router. In this case, the border router must be reconfigured.
With Thread Specification 1.3.0, border routers that share infrastructure links can facilitate designs with no single point of failure across media such as Wi-Fi or Ethernet by leveraging Thread Radio Encapsulation Links (TREL). With this function, the possibility of forming Thread partitions across links is reduced.
Bluetooth Core Specification 5.4 released in 2023 introduces four significant capabilities to the existing specifications.
1. Periodic Advertising with Response(PAwR)
PAwR is one of the key feature. Prior to Bluetooth 5.4, connectionless bidirectional communication is not possible. PAwR now allows bidirectional transfer of data in connectionless mode between a single central device and a large number of multiple devices (up to 32,640) in a star network topology.
2. Encrypted Adverting Data (EAD)
EAD provides a standardized approach to the secure broadcasting of data in advertising packets and enables the encrypted data over-the-star network to be decrypted only by devices that have shared the key material previously. This security feature protects PAwR communications to safeguard against data tampering, human error, and data leaks.
3. LE GATT Security Levels Characteristic(SLC)
When a GATT Client attempts to access a server attributes (characteristics, descriptors), attributes permissions are checked. If permissions are insufficient, the access is denied and all GATT features will not work properly. With SLC, the client can upgrade its security level to reattempt access of the previous failed operation. SLC enables devices to identify the security mode and level for all their GATT functionality.
4. Advertising Coding Selection
For LE Coded PHY, a Forward Error Correction (FEC) algorithm is used which results in significantly longer transmission distances. FEC parameter (S) uses one of two values (S=2 or S=8) and controls how much data is made to fix errors and how much Bluetooth range may be achieved. Prior to Bluetooth 5.4, specifying the value of the S coding parameter was not impossible. Bluetooth 5.4 allows the host to specify the value of the coding parameter S (S=2 or S=8) when the LE Coded PHY is selected for use with extended advertising.
Main beneficiary market of Bluetooth 5.4
The combination of these features enables ultra-low power, efficient radio usage and secure star networks that can be deployed in large scale ESL (Electronic Shelf Labels) and sensor applications with transferring a small amount of data. Devices accept slightly longer advertising-delay to exchange an extended battery life. It’s easy to see the retail industry as well as the market for ESL and shelf sensors will benefit greatly. ESL are devices that display pricing information for product on retail store shelves. They use small electronic paper displays powered by batteries and can replace traditional paper labels. Besides, ESL use wireless technology and a central hub device to transmit data, allowing retailers to automate pricing and replace traditional manual processes, and creating more efficient in-store operations.
Edited by Account Manager: Ms. Gracie Chuang
Raytac Corporation 勁達國際電子有限公司 A Bluetooth & WiFi module maker based on Nordic nRF53, nRF52, nRF70 solution www.raytac.com email: service@raytac.com Tel: +886.2.3234.0208
As the chipset of nRF5340 is built by Dual Core structure (net core and application core), we need to proceed the coding and compiling process individually to net core & application core.
After the coding and compiling process done, we could get the separate zephyr.hex file respectively which are used for BLE module FW.
Firmware Development Steps : Code Building / Compiling
Case Study :
NON-Audio Project
nRFConnect SDK V2.1.2
Nordic Example code -“hci_rpmsg” & “peripheral_uart”
Nordic example code of “hci_rpmsg” extracted for coding and we will get zephyr.hex file for net core
Nordic example code of “peripheral_uart” extracted for coding and we will get zephyr.hex file for application core
Step 1. Net core Layer
1a) Activate “Open VS Code” IDE in NCS V2.1.2
1b) Select “Add an existing application” and extract “hci_rpmsg” file moving forward
1c) Click “Add Build Configuration” icon
1d) Select “nrf5340dk_nrf5340_cpunet” and check Nordic boards, then Execute “Build Configuration”
1e) zephyr.hex file is successfully generated for net core layer if the coding process is properly executed
Step 2. Application core Layer:
2a) Activate “Open VS Code” IDE in NCS V2.1.2
2b) Select “Add an existing application” and extract “peripheral_uart” file moving forward
2c) Click “Add Build Configuration” icon
2d) Select “nrf5340dk_nrf5340_cpuapp” and check Nordic boards, then Execute “Build Configuration”
2e) zephyr.hex file is successfully generated for application core layer if the coding process is properly executed
Find more nRF5340 module development resources in below link
.png "Periodic Advertising with Response(PAwR)")
.png "Encrypted Adverting Data (EAD)")
