Raytac Corporation, a Nordic-recommended third-party module manufacturer based in Taiwan, today announces the upcoming release of the AN54H20 modules, which are built on the base of Nordic’s nRF54H20 SoC.
The AN54H20 module comes in a 9.8 x 13.8 x 1.8mm (0.37 by 0.53 by 0.07 inches) dimension factor and offers 3 versions of high-performance antennas, including ceramic chip antenna, PCB-mounted antenna, and uFL connector for external antenna. Output power is adjustable up to +10 dBm and data rate is adjustable up to 4Mbps to maximize RF performance.
Powered by multiple processors, AN54H20 modules provide the IoT field with access to a whole set of improved features, including 2MB flash memory/1MB RAM and bigger processing power for more complicated computations. It also enhances protection against security threats, providing developers with protection while building technologically advanced IoT applications.
Hardware wise, AN54H20 inherits nRF54H20’s set of versatile, advanced, and low-power peripherals alongside DMA support, including high-speed USB, CAN-FD controller, 14-bit ADC, 2 x I3C and plenty more. What’s more revolutionary is that AN54H20 brings power efficiency to a whole new level through accurately controlling currency consumptions under various modes, allowing smaller batteries to be implemented in the applications while increasing its life expectancy.
“We see the AN54H20 series as a potential market changer. The compact size gives developers a seamless switch from the previous generation modules to AN54H20, and the remarkable power efficiency and characteristics AN54H20 brings will offer a magnificent effect to the inescapable hot trend of IoT and other various industries.” – Lyon Liu, President of Raytac Corporation.
Welcome to send an inquiry to: service@raytac.com for further discussions.
Edited by Sales Manager: Mr. Tony Yin
Raytac Corporation 勁達國際電子股份有限公司 A company of Abietec Bluetooth & WiFi module maker based on Nordic nRF54, nRF53, nRF52, nRF7002 solution BT5.4 &BT5.3 & BT5.2 & BT5.1 Qualified, FCC/IC/CE/Telec/KC/RCM/SRRC/NCC Pre-Certified.
Developers may be familiar with using ‘\n’ (hex 0x0A) or ‘\r’ (hex 0x0D) as end codes to determine the end of a data packet when writing programs. In the original Nordic SDK example code, ble_app_uart, is to consider the reception of 244 bytes or the presence of ‘\n’ (hex 0x0A) or ‘\r’ (hex 0x0D) as end code as the end of a data packet. The program then sends this received data via BLE to APP.
Developers encountering Raytac AT-Command module for the first time may find it very unfamiliar and be puzzled by the absence of 0x0A or 0x0D end code. You may raise questions about how to receive complete information without relying on these end code? Therefore, we’ll provide explanations for common use cases of AT-Command in both connected and disconnected scenarios:
In the connected condition –
Raytac’s AT-Command module operates in Pass-Through mode. For instance, when the APP sends 0x41 0x42 0x43 (3 bytes) through the module to the MCU, the MCU will receive only 0x41 0x42 0x43 (3 bytes). When APP sends these 3 bytes, there is no need to include the 0x0D end code or 0x0A end code at the end. The same approach applies when the direction of transmission is reversed (i.e., when the MCU sends to the module and then to the APP).
Here, it’s crucial to note that there is a specific consideration for the “Data Interval” (DI) setting between transmitting one data packet and the next. Failure to configure the DI appropriately may result in packet loss and lead to Bluetooth disconnection shortly after data transmission. The recommended DI values vary at different Baud rates, and you can refer to the AT-Command specification for suggested DI values.
As an example, consider Raytac AT-Command module in the scenario of “Mobile App -> Module (MDBT42V-AT) -> MCU,” with a Baud rate of 9600, no flow control, and a data length of 244 bytes. In this case, the DI value for transmitting data must be at least 250ms to prevent packet loss.
In the unconnected condition –
Providing explanations to the Bluetooth module by sending AT commands from the MCU (or Console) is illustrated below. There is no need for 0D or 0A end codes at the end.
AT?NAME
AT+NAMESQ-BT
AT?NAME
Edited by Sales Manager: Ms. Vicky Huang
Raytac Corporation 勁達國際電子股份有限公司 A company of Abietec Bluetooth & WiFi module maker based on Nordic nRF54, nRF53, nRF52, nRF7002 solution BT5.4 &BT5.3 & BT5.2 & BT5.1 Qualified, FCC/IC/CE/Telec/KC/RCM/SRRC/NCC Pre-Certified. Bluetooth Solution: nRF54, nRF5340, nRF52840, nRF52833, nRF52832, nRF52820, nRF52811, nRF52810, nRF52805, nRF51822 WiFi Solution: nRF7002 http://www.raytac.com email:service@raytac.com Tel: +886.2.3234.020
Periodic Advertising with Responses (PAwR) The major new function list 4 key operation as below：
Periodic Advertising with Responses (PAwR) PAwR is a new Bluetooth Low Energy (LE) logical transport that provides a way to perform energy efficient, bi-directional, communication in a large-scale one-to-many topology.
Encrypted Advertising Data This new feature provides a standardized approach to the secure broadcasting of data in advertising packets.
LE GATT Security Levels Characteristic Devices may now indicate the security mode and level required for all their GATT functionality to be available using a new GATT characteristic called LE GATT Security Levels.
Advertising Coding Selection The Host can now specify which of two supported long range coding options are used with LE extended advertising.
Background
The Bluetooth Core Specification defines several concepts that collectively constitute the Bluetooth
data transport architecture. Among these concepts are the Physical Transport, Physical Channel,
Physical Link, Logical Link, and Logical Transport. Certain combinations and configurations are
defined for use in support of different application types, each with particular characteristics relating
to properties such as topology, timing, reliability, power, and channel use. The terms operational
mode or mode of operation are sometimes used informally to refer to the various data transport
architecture configurations.
Advertising Modes and Basic Properties
Specific combinations of these properties are defined together with the circumstances in which
they may be used, in the Bluetooth Core Specification. The selected combination is indicated by the
type(s) of PDU transmitted or by the value of a field called AdvMode, which is present in some PDU
types. Examples of defined combinations include connectable undirected advertising and connectable
and scannable advertising.
Advertising Modes and Basic Properties
Advertising is a form of connectionless communication that, depending on how it is performed, has
various properties that affect the behaviors of the advertising device and other devices that receive
its transmitted advertising packets.
connectable vs. non-connectable
Connectable advertising means that a scanning device may respond to a received advertising packet by transmitting a request to form a connection with the advertising device.
scannable vs non-scannable
Scannable advertising means scanning devices may respond to an advertising packet by transmitting a scan request, asking for more application data from the advertiser.
directed vs. non-directed
When performing directed advertising, packets are addressed to a specific scanning device and will be ignored by other devices. Non-directed advertising packets are not addressed to a specific device and may be processed by any scanning device.
Irregular vs. fixed interval periodic
Advertising can be performed with a precise transmission schedule, and this is known as periodic advertising. Other forms of advertising operate to an irregular schedule. A random delay value between 0 and 10 ms is added to a fixed advertising interval to perturb advertising events in time.
Legacy Advertising
When performing legacy advertising, identical copies of legacy advertising packets are transmitted
on up to three primary advertising channels, one channel at a time and in some pseudorandom
sequence.
The transmission of legacy advertising packets takes place during advertising events. The scheduling
of advertising events is primarily controlled by a link layer timing parameter, advInterval. But
advertising events are made slightly irregular, so persistent collisions with other advertising devices
are avoided. This is achieved by assigning a parameter known as advDelay, a pseudo-random value in
the range of 0 – 10ms, and adding it to the fixed advInterval so that advertising events are perturbed
in time. Below figure illustrates this.
Legacy advertising packets can contain application data in the AdvData field, but scan request packets cannot. Therefore the direction of packet transmissions can be bidirectional, but the transfer of application data using advertising and scan response PDUs is a strictly one-way capability.
Extended Advertising
This use of extended advertising is referred to here as irregular extended advertising.
The LE Periodic Advertising Broadcast (PADVB) logical transport is another form of extended
advertising but is designated a distinct logical transport because it uses regular, fixed-rate timing for
event and packet transmission scheduling.
Irregular extended advertising and periodic advertising both use the 37 general-purpose channels and
the three primary advertising channels.
Irregular Extended Advertising
Irregular extended advertising is comparable with legacy advertising in that some extended
advertising PDU types are only ever transmitted on the primary advertising channels. Their
transmission scheduling is irregular due to the addition of the random advDelay value in the range
of 0 to 10 ms in calculating advertising event times. It differs from legacy advertising in a number of
ways including that distinct PDU types are used. Some of these PDU types are transmitted only on
the primary advertising channels, but may be linked by a pointer field called AuxPtr to others that
are transmitted only on the secondary advertising channels. Larger payloads may be handled by
fragmenting the data and transmitting it in multiple PDUs linked together or chained using AuxPtr in
certain PDU types.
Periodic Advertising (PADVB)
When the periodic advertising (PADVB) logical transport is used, the broadcasting device transmits
packets to a fixed interval, deterministic schedule, and Observer devices can discover the Broadcaster’s transmission schedule and synchronize their scanning to it. This can be accomplished
by acquiring information from the SyncInfo field within an AUX_ADV_IND PDU or by using a
procedure called Periodic Advertising Sync Transfer (PAST).
PAST involves a device passing periodic advertising synchronization parameter values over an LEACL
connection to the Observer. The device passing these details may be the Broadcaster itself or
a third device that acquires the synchronization parameters by scanning for AUX_ADV_IND PDUs
transmitted by the Broadcaster. The procedure avoids the need for the Observer, which may be a
small, power-constrained device, to scan for synchronization data itself, a potentially
expensive operation.
By precisely synchronizing with the Broadcaster’s transmission schedule, the Observer can scan in
the most energy-efficient way.
Periodic advertising involves multiple extended advertising PDU types and all 40 radio channels,
as depicted in Figure below picture. Here we see ADV_EXT_IND PDUs transmitted on the primary advertising channel, with AuxPtr pointing to an associated AUX_ADV_IND PDU transmitted on the secondary channels. This PDU contains the SyncInfo field which contains information that allows an Observer to synchronize its scanning with the periodic transmission of AUX_SYNC_IND PDUs. Note that the
Observer only needs to receive one ADV_EXT_IND PDU to be able to acquire the periodic advertising
synchronization data in the SyncInfo field of a AUX_ADV_IND PDU. Once this has been achieved, it
can proceed to only scan for AUX_SYNC_IND PDUs
AUX_SYNC_IND PDU
The AUX_SYNC_IND advertising PDU type is transmitted at fixed intervals. It is not possible for
Observers to respond to PADVB periodic advertising PDUs and hence this logical transport only
supports unidirectional communication of application data.
Comparing Legacy Advertising and Extended Advertising
Below table summarize some of the important differences between legacy advertising and
extended advertising.
About Periodic Advertising with Responses (PAwR)
Overview
PAwR is similar to periodic advertising (PADVB) in several ways:
PADVB allows application data to be transmitted by one device (the Broadcaster) to one or
more receiving devices (the Observers), forming a one-to-many communication topology. The
same is true of PAwR.
PAwR and PADVB both use a connectionless communication method.
Transmission of advertising packets is periodic with a fixed interval and no random
perturbation of the schedule in both cases.
Observers can establish the periodic transmission schedule used by the Broadcaster from
AUX_ADV_IND PDUs or by using the Periodic Advertising Sync Transfer (PAST) procedure.
PAwR differs from PADVB as follows:
PADVB supports the unidirectional communication of data from a Broadcaster to Observers
only. PAwR Observers can transmit response packets back to the Broadcaster. PAwR provides
a bidirectional, connectionless communication mechanism.
Synchronization information for periodic advertising without responses (PADVB) is contained
within the Sync Info field of AUX_ADV_IND PDUs. Synchronization information for periodic
advertising with responses (PAwR) is contained within the SyncInfo field and in the ACAD field
of AUX_ADV_IND PDUs.
The PADVB Broadcaster schedules transmissions within advertising events. The PAwR
Broadcaster schedules transmissions in a series of events and subevents, and Observers
are expected to have synchronized in such a way as to listen during a specific subevent or
subevents only.
The PAwR Broadcaster may use a transmission time slot to send a connection request (AUX_
CONNECT_REQ) to a specific device and establish an LE-ACL connection with it. PADVB
does not have this capability.
With periodic advertising without responses (PADVB), application data tends to only change
from time to time. PAwR is designed with the expectation that application data will
change frequently.
With PADVB, the same application data is delivered to all Observer devices synchronized to
the same advertising set. With PAwR, different data can be delivered to each Observer device
or set of Observer devices.
Support for the Periodic Advertising Sync Transfer (PAST) procedure is optional with PADVB
but mandatory with PAwR.
Benefits
Bidirectional Connectionless Communication
PAwR supports the bidirectional exchange of application data using connectionless communication,
which was not previously possible with Bluetooth LE.
Scalability
PAwR offers a more scalable way to create a one-to-many topology capable of bidirectional
application data communication than a collection of LE-ACL connections. It is common for no more
than a handful of concurrent LE-ACL connections to be supported by a Central device3 , whereas
bidirectional communication with thousands of devices is possible using PAwR.
Energy Efficiency
Synchronization between the Broadcaster and each Observer takes place at subevent level, meaning
that Observers only scan during a small subset of all Broadcaster transmissions. The subevent
synchronization process involves application logic, so packets received will usually contain data of
relevance to the Observer. This energy-efficient approach means Observer devices could run off
batteries for several years. Section 1.2.3.6 Battery Life illustrates.
Flexible Topologies and Receiver Concurrency
PaWR offers flexibility in terms of the topologies supported. When a PAwR Broadcaster transmits a
packet, it does so in a subevent. The packet is received by all devices synchronized to that subevent,
and this may be a single device, a subset of the complete set of the Observer devices, or all such
devices, depending on the application-layer rules for subevent synchronization.
With PADVB, each advertising set forms a one-to-many topology, and all devices synchronized to an
advertising set receive data at each broadcast.
Applications
PAwR is well-suited to applications that need to send and receive messages between a central hub
device and a large number of other devices in a network. Messages could contain commands or
sensor data values, or other data, as defined by the application layer. The Electronic Shelf Label (ESL)
profile uses PAwR to transport messages containing commands and responses and serves as a good
example of PAwR in use.
PAwR is not intended to be used for products that require a real-time messaging capability. As will
be explained in the Technical Highlights section, PAwR works by periodically transmitting a series of
packets, one after the other in specific time slots known as subevents. Devices are configured so that
they listen during certain subevents only and therefore it is common for there be a delay between
the start of a use case which delivers commands or data to devices across the network, and the
transmission time slot for each device arising. Consequently, a noticeable elapsed time will
sometimes be experienced when sending messages to multiple, unrelated devices. The elapsed time
will vary in magnitude from milliseconds to tens of seconds, depending on details of the use case and
system configuration.
By way of contrast, Bluetooth mesh networking also makes use of a system of messaging for
commands and sensor data. However, Bluetooth mesh offers a near to real-time messaging solution,
with messages sent and responded to more or less immediately. To achieve this though, mesh
devices perform passive scanning with a duty cycle as close to 100 percent as possible and this has
consequences for energy consumption. PAwR devices such as electronic shelf labels operate to a low
duty cycle and therefore perform well in terms of energy efficiency.
Technical Highlights
Events, Sub-events, and Response Slots
Understanding how PAwR partitions and uses time is key to understanding this logical transport.
As with other advertising modes, activity takes place in events which in the case of PAwR are known
as Periodic advertising with responses events (PAwR events). These events occur at fixed intervals,
with no random perturbation in scheduling. An event starts every periodic advertising interval ms.
Each PAwR event consists of several subevents, and it is during subevents that advertising packets
are transmitted. The Host configures the number of subevents per event up to a maximum of 128. A
subevent starts every periodic advertising subevent interval ms. The Host configures the number of
subevents per event and the periodic advertising subevent interval using a Host Controller Interface
(HCI) command called HCI_LE_Set_Periodic_Advertising_Parameters V2 (or later).
See Figure：
In each subevent, the Broadcaster transmits one packet, which usually contains an AUX_SYNC_
SUBEVENT_IND PDU but may instead contain an AUX_CONNECT_REQ PDU. After a delay, known
as the Periodic Advertising Response Slot Delay, a series of time slots are reserved within the same
subevent for receiving responses from Observer devices. Responses to AUX_SYNC_SUBEVENT_IND
PDUs are sent in AUX_SYNC_SUBEVENT_RSP PDUs. The Host configures the number of response
slots required by the HCI command HCI_LE_Set_Periodic_Advertising_Parameters. Figure 6
illustrates the structure of a PAwR subevent.
Channel Selection
Channel selection is accomplished using Channel Selection Algorithm #2, and takes place at each
periodic advertising subevent. Responses to PDUs transmitted in a subevent use the same channel.
This includes AUX_SYNC_SUBEVENT_RSP PDUs sent in response to a AUX_SYNC_SUBEVENT_IND
PDU and AUX_CONNECT_RSP PDUs which are sent in response to AUX_CONNECT_REQ PDUs.
Synchronizing
The process of synchronizing provides the Observer device with the information it needs to efficiently
scan for and receive relevant packets transmitted by the advertising device. In the case of PAwR,
there are three aspects to this:
The Observer needs to know how often periodic advertising with responses events will occur
and when the next such event will occur. This information is provided in a parameter called the
periodic advertising interval and a calculated value known as syncPacketWindowOffset.
The Observer needs information about subevents, including how often they occur and
how many subevents each periodic advertising with responses event accommodates. It also
needs to know certain details relating to the time slots within each subevent reserved for
the transmission of responses. This information is contained within parameters known as
Subevent_Interval, Num_Subevents, Response_Slot_Delay, Response_Slot_Spacing, and
Num_Response_Slots.
Finally, an Observer needs to know which subevent number it should scan for, which
particular response slot it should use, and the access address to use in response
packets transmitted.
Having acquired the event timing information described in (1) and the subevents information in (2),
the Observer has a complete description of the timing parameters and structure of the events and
subevents of the PAwR advertising train. But it is only when it has the information in (3) that it can
schedule its scanning such that it receives only those packets that are expected to contain data of
relevance and can schedule the transmission of response packets.
A) and (2) are dealt with by the PAwR logical transport, as defined in the Bluetooth Core Specification.
There is a choice of two procedures that may be used to obtain this level of synchronization
information. The two procedures are covered in this paper in sections 1.2.3.3.2 Scanning for Periodic
Advertising Synchronization Information and 1.2.3.3.3 Periodic Advertising Sync Transfer (PAST).
B) must be addressed by the application layer and may be defined in an applicable Bluetooth profile
specification. This is covered in section 1.2.3.3.4 Subevent Synchronization and Response
Slot Allocation.
Scanning for Periodic Advertising Synchronization Information
PAwR and PADVB each use a similar procedure for acquiring periodic advertising synchronization
information by scanning. With both PAwR and PADVB, an Observer scans for AUX_ADV_IND packets transmitted on the secondary advertising channels. These PDUs are pointed to by the channel index, offset and PHY information in the AuxPtr field in ADV_EXT_IND PDUs that are transmitted on the primary channels.
AUX_ADV_IND includes the SyncInfo field, which contains the periodic advertising interval value and
some data items from which to calculate a variable called syncPacketWindowOffset. Having acquired
these two values, the Observer can calculate when periodic advertising with responses events will
occur, per (1) in 1.2.3.3.1 General.
PAwR also requires information about subevents and response slots, per (2) in 1.2.3.3.1 General, before it can complete the synchronization procedure. This information is to be found in the same AUX_ ADV_IND PDU from which the periodic advertising interval was obtained but in a new AD type called Periodic Advertising Response Timing Information. The new AD type is transmitted in the Additional Controller Advertising Information (ACAD) field of the AUX_ADV_IND PDU. See below Table.
Periodic Advertising Sync Transfer (PAST)
When using the PAST procedure, sometimes the device passing the synchronization parameters
over the connection will first acquire it by scanning on behalf of the other device. In the case of
PAwR, however, support for PAST is mandatory and so the PAwR Broadcaster can pass the required
synchronization data over an LE ACL connection to the Observer. If this approach is taken, no
scanning for AUX_ADV_IND PDUs is necessary by either device.
The same data items presented in Table 3 are passed over the LE ACL connection in a new PDU type
called LL_PERIODIC_SYNC_WR_IND.
Subevent Synchronization and Response Slot Allocation
Subevent synchronization is concerned with indicating to an Observer device the subevent it should
perform scanning for. One or more Observer devices may be synchronized to the same subevent. An
individual Observer may be synchronized to receive during one or more subevents.
In addition, for an Observer to be able to send a response PDU, it must have some basis for
determining which subevent response slot to use.
Both of these concerns are the responsibility of the application layer. Section 1.2.4 Electronic Shelf
Labels and PAwR explains how the Electronic Shelf Label profile deals with these concerns
by example.
As Table shows, PAwR’s key strengths include the fact that application data communication is bidirectional, flexibility is provided in the choices of topology and receiver concurrency available, and the number of devices that can be communicated with from one Broadcaster is very large (i.e., thousands of devices).
Electronic Shelf Labels and PAwR
Overview of the Electronic Shelf Label Profile
The ESL profile uses both PAwR and connection-oriented interactions to meet its complete set
of requirements. Images, for example, are written to devices over LE ACL connections. But most
commands and responses involve ESL messages transported using PAwR PDUs in subevents.
ESL uses a device addressing scheme which consists of an 8-bit ESL ID and a 7-bit Group ID. The ESL
ID is unique within the group of devices identified by a Group ID. Therefore a network of ESL devices
can include up to 128 groups, each with a maximum of 255 unique ESL devices that are members of
that group. In total, there may be 32,640 ESL devices in a network.
The ESL profile deals with subevent synchronization and response slot allocation as follows:
The PAwR Broadcaster, known as an Access Point (AP) in the ESL profile specification, configures
electronic shelf label devices by writing to various GATT characteristics over an LE ACL
connection. The data written includes the assignment of an ESL Address consisting of an ESL ID
and a Group ID. Group is an ESL profile concept, but its value is also used to indicate the number of
the subevent during which the ESL device should scan.
Response slot allocation happens dynamically. ESL devices receive an array of one or more
commands from the AP in PAwR AUX_SYNC_SUBEVENT_IND PDUs. All commands in a request
packet are addressed to the same ESL Group_ID. But each is addressed to a specific ESL in the
group using its ESL_ID5. The index of the command in the array, counting from 1 for the first
command, determines the response slot to be used. So, for example, having executed the 3rd
command in the request PDU’s array, response slot #3 will be used.
ESL and 1:1 Device Communication
As below figure shows the transmission of PDUs that occur when the AP issues a command addressed to a single electronic shelf label. The diagram illustrates how PAwR acts as a transport for ESL commands and responses, as defined by the profile.
The shelf label to which the ESL command is addressed is a member of ESL group 1. This means that
it is synchronized to PAwR subevent #1. The AP, therefore, formulates the ESL Payload, which can
include an array of one or more commands, each addressed to a specific ESL ID within that same
group, and transmits it as the payload of a PAwR AUX_SYNC_SUBEVENT_IND PDU during PAwR
subevent #1.
ESL and 1:m Device Communication
shows the transmission of PDUs that occur when the AP issues a command addressed to
several shelf labels, each of which is a member of ESL group #1. This is followed by transmitting a
single command addressed to a single device that belongs to ESL group #2.
The first ESL request contains three commands. The request targets three shelf labels belonging to
ESL group #0, so it is formatted and set as the payload of an AUX_SYNC_SUBEVENT_IND PDU and
transmitted in PAwR subevent #0.
All ESL shelf labels that are members of group #0 receive the PDU simultaneously since they are all
synchronized on PAwR subevent #0. The ESL command array contains commands addressed to those
shelf labels in the group that have ID #0, #1, and #n. These three devices process their respective
commands. The device with ID #0 responds with an AUX_SYNC_SUBEVENT_RSP PDU in response
slot 0. The device with ID #1 responds with an AUX_SYNC_SUBEVENT_RSP PDU in response slot 1.
Finally, the device with ID #n responds with an AUX_SYNC_SUBEVENT_RSP PDU in response slot
#2 since the command responded to was the third in the ESL command array. Other devices with
different IDs ignore the request.
Conclusion
Bluetooth Core Specification version 5.4 adds a significant new bidirectional connectionless
capability in PAwR and makes it possible to broadcast confidential data in advertising packets
securely. In addition to these considerable enhancements, applications that use GATT can now offer
a better user experience when dealing with attribute security requirements than before, and devices
can exercise control over an important parameter (S) when using the LE Coded PHY for extended
advertising.
Edited by Sales Manager: Mr. Neo Hsu
Raytac Corporation 勁達國際電子股份有限公司 A company of Abietec Bluetooth & WiFi module maker based on Nordic nRF54, nRF53, nRF52, nRF7002 solution BT5.4 &BT5.3 & BT5.2 & BT5.1 Qualified, FCC/IC/CE/Telec/KC/RCM/SRRC/NCC Pre-Certified. Bluetooth Solution: nRF54, nRF5340, nRF52840, nRF52833, nRF52832, nRF52820, nRF52811, nRF52810, nRF52805, nRF51822 WiFi Solution: nRF7002 www.raytac.com email:service@raytac.com Tel: +886.2.3234.020
Raytac Corporation is excited to extend our warm welcome to you once again at Embedded World 2024, scheduled to be held from April/9/2024 to April/11/2024 at the Nuremberg Exhibition Centre, Germany.
As IoT and Bluetooth Low Energy gain momentum, they emerge as essential catalysts for future development. Following Nordic Semiconductor’s lead in wireless technology, Raytac remains committed to releasing a wide range of modules to meet developers’ needs.
This year, we’re also introducing Wi-Fi modules AN 7002 alongside the nRF 7002 and nRF 54 series modules, so stay tuned for what’s to come.
Based on your requirements, we will showcase more applications of modules at the exhibition, as well as demonstrate how Raytac Corporation can save your time and expenses during the development stage and overall costs.
Raytac Corporation is delighted to invite you joining our team at:
HALL 3 Booth 3-111 M2M Area
To be a part of this dynamic convergence of ideas, innovations, and opportunities.
For more information and details into Raytac Corporation at embedded world 2024 can now be found in the preview of our digital event platform from following link:
After reading through the article of WFA (Wi-Fi Alliance) QuickTrack program, you may try to seek for a seamless option that least effort made for a Wi-Fi certificate.
Raytac Corp. has took this into consideration already!
Raytac Corp. is working on the FlexTrack package as a source product so that end product developer can apply a Derivative program to grant a WFA certificate by leveraging Raytac Corp. WFA source product – NRF5340 & NRF7002 IC combo solution (MDBT53 & AN7002 Module)
Let Raytac Corp. do the work ahead of your request, the FlexTrack program is provided with a fix option, the necessary Wi-Fi compliance & conformance have been done by Raytac Corporation, Raytac Corp. will get a WFA Certificate that you (end product developer) can simply leverage it and apply Derivative program seamlessly for getting your own Wi-Fi certificate ID as long as you’re the member of Wi-Fi alliance.
What benefits you (end product developer) by sticking to Raytac Corp. FlexTrack (Source product) program?
No-Testing required: Raytac Corp. has granted the Wi-Fi certificate ID using source product (MDBT53 & AN7002 Module) , you simply leverage Raytac Corp. Wi-Fi certified ID and apply the solution to your end product when you’re working on the certification process ; No-testing is required.
Faster time-to-market end device (Wi-Fi) : By using Raytac Corp. available WFA source product , you can get through the certification process easily without being in the process of a series of tests as long as you’re the member of Wi-Fi alliance. This helps your Wi-Fi end device get launched at the earliest.
Seamless Connectivity & Least resource required : Without involving in a series of complicate Wi-Fi compliance and conformance test, it delivers the seamless connectivity and the least effort would be took for end product developer to get Wi-Fi certificate ID.
Waive cost on Wi-Fi conformance test: it significantly decreases the cost for your project budget without getting through a series Wi-Fi compliance & conformance test.
If you stick to Raytac Corp. combo solution (source product )- MDBT53 & AN7002 Module, given the Wi-Fi components are pre-certified in the FlexTrack solution, you (end product developer) will be able to use the minimal resource and least effort to get Wi-Fi certificate ID for your Wi-Fi end device.
Which membership level shall be applied in Wi-Fi alliance for being Derivative?
If you agree with Raytac Corp. FlexTrack program and are confident in the Raytac Corp. combo solution(source product )- MDBT53 & AN7002 Module , Wi-Fi Implementer membership would extend this benefit for you. Being the Implementer membership and participate in the Derivative program, this is the perfect option for the budget sensitive company.
In Nordic Semiconductor products, the enhanced APprotect feature has been integrated into the nRF52 series microcontrollers. APprotect (Access Port Protection) is a crucial security feature designed to safeguard the device’s application, compiled code, with read-back protection mechanism, against unauthorized access and modifications. This protection is essential for preventing unauthorized access and software tampering.
Effectively leveraging the improved Approtect feature on nRF52 series microcontrollers to enhance device application security and reliability is a significant concern for current developers and engineers.
This year, Raytac Corporation has launched low-energy Bluetooth modules for the third edition IC nRF52840 APprotection Solution and nRF52832 APprotection Solution.
These modules not only retain the functionalities of the original nRF52840 and nRF52832 low-energy Bluetooth modules but also comprehensively upgrade security by adding the APprotect feature to prevent hackers from accessing and rewriting programs without authorization.
Here is a detailed explanation of the nRF52 third edition low-energy Bluetooth modules by Raytac Corporation:
Raytac Corporation APProtection Bluetooth Module Series:
The encoding principle is to use ‘EN’ after the original model number to represent ‘encrypted’ instead of ‘V2’.
For example, in the nRF52840 series, the Raytac model MDBT50Q-1MV2 has “V2” replaced with “EN” for the third edition, hence the third edition model is named MDBT50Q-1MEN.
MDBT50Q Ceramic Antenna Series:
MDBT50Q-1MEN : Equipped with a ceramic antenna module suitable for long-distance or complex environment wireless transmission.
MDBT50Q-P PCB Antenna Series:
MDBT50Q-P1MEN: Equipped with a PCB antenna module suitable for general environment wireless transmission.
MDBT50Q-DB: An excellent choice for those who want to delve deeper into and conduct more tests with the Nordic nRF52840. This development and debugging board based on the MDBT50Q-1MV2 (ceramic antenna) module has all GPIOs of the module pulled out, facilitating rapid connection to other devices for firmware development and verification using jumper wires.
The same encoding principle applies to the nRF52832 series, and the MDBT42Q series follows suit.
MDBT42Q Ceramic Antenna Series: MDBT42Q-512KEN comes with a ceramic antenna module, suitable for long-distance or complex environment wireless transmissions.
MDBT42Q-P PCB Antenna Series: MDBT42Q-P512KENfeatures a PCB antenna module, suitable for general environment wireless transmissions.
MDBT42Q-U512KEN , designed for external antenna requirements, comes with a u.FL connector module suitable for ultra-long-distance wireless transmissions.
MDBT42Q-DB development board is based on the MDBT42Q-512KV2 (ceramic antenna) module and is designed for development and debugging purposes.
Other Reference Links:
Nordic 3rd Party Modules/Modems(Raytac’s modules are all qualified Nordic 3rd Party Bluetooth low energy module, please go following website for more detailed information.)
Module Appearance: The third edition features an additional black dot in the bottom left corner of the metal shell for easy identification of its purpose.
While the device with readback protection enabled, issuing ERASEALL command is a must and the only method to unlock the device before proceeding with programming.
It is recommended to use nRF_SDK v17.1.0 or later versions to write code for the third edition.
For further clarity on the differences between the second edition IC Bluetooth modules and the third edition IC Bluetooth modules, the following table and links are provided for reference:
Nordic nRF52840 * Supporting BT5 Long Range Feature * Built in USB interface
Raytac nRF52840 module spectrum covers MDBT50Q-1MV2, MDBT50Q-P1MV2 and MDBT50Q-U1MV2 series with Chip Antenna, PCB Antenna and u.FL connector for External Antenna option for selection.
Raytac Corp. is officially a member of Wi-Fi Alliance now!
Before stepping into Wi-Fi module selection and adoption, Wi-Fi regulatory compliance will be essential for you to know.
Let’s dig into the Wi-Fi certification program and investigate the possibility of WFA Qualified Solution (provided by Solution Provider) & WFA certificate (obtained by end product developer).
What benefits you (end product developer) by working with Rayta Corp. (Solution Provider) for QuickTrack program?
Faster time-to-market : By using available WFA Qualified Solution (provided by solution provider) to waive (or partially waive) compliance test criteria/decrease testing days for end product (Wi-Fi Device), shorter development days would be took before product launch.
Reduce test and certification costs: it significantly reduces the cost and certification days for your project with minimal resource by working with Raytac Corp. (Solution Provider) using available WFA Qualified Solution.
Avoid testing redundancies: Raytac Corp. (Solution Provider) has pre-certified the core Wi-Fi architecture and protocols in Wi-Fi module AN7002, the necessary qualification tests has been conducted. You (end product developer) don’t need to test on those same criteria for end product (Wi-Fi Device) if Raytac Wi-Fi module is implemented in your end device.
Allow flexibility of Wi-Fi functionality change: In case those minor change of Wi-Fi feature which is not relates to core/essential/architecture change may be raised someday in the future , QuickTrack program delivers the qualified product base (Source product) and lower cost with conformance test (QuickTrackTool) responding to the minor change. This is especially adaptive for the case end product developer has their own processor (MCU) working with Raytac NRF7002 module.
How QuickTrack certification program works?
QuickTrack certification program shall be completed by 2 different parties, one is solution provider and the other is end product developer.
(Refer to the following image)
As a Solution Provider, Raytac would proceed the essential and fundamental Wi-Fi protocol/compliance test and develop this into a Qualified solution so that end product developer can leverage this solution as a base (Source Product) to obtain a certificate entitled to end product developer.
Please note the conformance check (named QuickTrack Tool) would be required before Wi-Fi alliance certifies the application.
Conformance check (QuickTrack Tool) will be reviewed for the 8 Wi-Fi components.
Chipset
Wi-Fi Component Firmware Version
Driver
RF Architecture
Wi-Fi Component Operation System
Physical Interface
RF Components
Antenna
When you adopt Raytac WFA Qualified solution, the core/essential/architecture components are pre-certified in the solution, in most of cases, no further conformance test is required, you (end product developer) will be granted to obtain the certificate after a couple of days applying process.
Raytac leaves the right to Wi-Fi alliance for the conformance review (run QuickTrackTool).
Which membership level shall be applied in Wi-Fi alliance for being QuickTrack?
If you agree with QuickTrack program and are willing to participate in the partnership as end product developer with Raytac Corp. (solution provider), Implementer membership will be cost effective option for you.
Company like Raytac Corp. served as solution provider or require professional Wi-Fi alliance support, company own/multiple programs oriented or needs tasks management shall refer to the membership of top one – Contributor.
Bluetooth modules typically have options for a 32MHz Internal Oscillator (or some called internal crystal oscillator) and a 32.768KHz External Oscillator. The choice between the two is often influenced by specific application requirements, power consumption, accuracy, and cost considerations. Here are some basic differences between Internal and External Oscillators:
Internal Oscillator: (32MHz)
Function: The internal oscillator is embedded within the module and generates the clock signal for the Bluetooth module. This internal oscillator is typically smaller, lightweight, and reduces dependence on external components.
Advantages: Simplifies design, saves space, and reduces costs.
Disadvantages: Some applications may require higher clock stability, which the internal oscillator may not provide to the desired level of precision.
External Oscillator: (32.768KHz)
Function: An external oscillator is an independent oscillator externally connected to the module, offering higher clock stability and accuracy.
Advantages: Provides higher clock stability, suitable for applications with stricter timing requirements.
Disadvantages: Requires additional components, may occupy more space, and increases costs.
Criteria for choosing Internal or External Oscillator:
If the application has modest clock precision requirements, and cost and space are critical factors, choosing the internal oscillator may be suitable.
If the application demands higher timing precision, an external oscillator should be considered for its enhanced clock stability.
Benefits from switching between external and internal oscillator:
Increased Performance Requirements: If the application’s performance requirements increase, a higher-precision oscillator, such as an external oscillator, may be needed.
Insufficient Clock Stability: If timing stability issues arise during Bluetooth communication, upgrading to an external oscillator can provide better clock stability.
Followings are the instructions we can use to switch between internal oscillator and external oscillator for nRF5 SDK (v17.10) and NCS SDK (v2.5.2).
Keil (Keil μVision) and SES (Segger Embedded Studio) are another method commonly used Integrated Development Environments (IDEs) in the field of embedded systems development.
Choosing to use the internal crystal oscillator requires program modifications. Please refer to the following instructions for making these changes in the Keil and SES development environments.
Raytac Corporation, a globally recognized third-party Bluetooth module supplier endorsed by Nordic Semiconductor, has announced a strategic collaboration with Millennium Semiconductor, a specialized electronic agent, starting from November 2023. The establishment of this partnership aims to jointly expand into the Indian market and provide comprehensive services to customers in different regions. Raytac Corporation has consistently focused on the wireless field, earning a reputation as a leading provider of Bluetooth Low Energy modules with outstanding technological capabilities. Additionally, Raytac offers the latest WiFi + BLE modules and a complete range of solutions from Nordic.
The product lineup includes series such as nRF54, nRF5340, nRF52840, nRF52833, nRF52832, nRF52820, nRF52811, nRF52810, nRF52805, nRF51822, all of which have obtained qualifications for BT5.4, BT5.3, BT5.2, and BT5.1. Furthermore, the nRF7002 represents the first device in our array of distinct Wi-Fi products, seamlessly combining with Nordic’s established ultra-low power technologies. Raytac Corporation’s modules have received Bluetooth (QDID/DID/BQB) and regulatory certifications from various countries and regions, including FCC (USA), CE (Europe), IC (Canada),TELEC (Japan), KC (Korea), SRRC (China), NCC (Taiwan), RCM (Australia/New Zealand), and others.
In addition to delivering excellent performance and transmission distances, Raytac Corporation’s modules are relatively compact in size, offering a diverse range of module series choices. This flexibility empowers developers to design without being constrained by module dimensions. Furthermore, the inclusion of AT Command by Raytac facilitates a quick entry for developers into the realms of Bluetooth and the Internet of Things.
Millennium Semiconductors India Private Limited,
17/18/19, 2nd Floor, Mahalaxmi Heights, Mumbai-Pune Road, Pimpri, Pune 411 018, Maharashtra, INDIA.
When launching new products, there is a requirement for RF testing, and two methods are commonly used:
DTM (Direct Test Mode) and Radio Test.
Nordic’s SDK provides two RF testing programs: DTM (Direct Test Mode) and Radio Test. While both methods can test RF indicators, they have some distinctions. DTM follows the Bluetooth specification’s Direct Test Mode data format (referenced in Bluetooth Core Specification Version 5.2, Vol. 6, Part F.), primarily for Bluetooth certification tests.
On the other hand, Radio Test focuses on the chip’s radio indicators, making it more suitable for FCC and ETSI certifications.
Let’s delve into detailed explanations for DTM and Radio Test programs.
DTM(Direct Test Mode)
The Bluetooth Association offers a feature for testing RF characteristics. Nordic has incorporated DTM firmware into the SDK according to SIG standard documents. Customers only need to modify the Baud Rate and UART TX/RX pins to conduct RF tests.
1. Download and install nRF Connect for desktop software and nRF5 SDK from the Nordic website.
2. Install the Direct Test Mode program in the nRF Connect for desktop software.
3. Extract the SDK package, open the DTM example code from
nRF5_SDK_vxx\examples\dtm\direct_test_mode\ board number\blank, modify TX and RX pins based on the target board’s definitions, then compile.
Download the program to the target board connected to the PC. (Select the appropriate sample code based on the IC/module for testing, referring to the board number below.)
IC P/N
board number
NRF52832
pca10040
NRF52810
pca10040e
NRF52840
pca10056
NRF52811
pca10056e
NRF52833
pca10100
NRF52820
pca10100e
RF testing is performed using UART TX/RX commands. The SDK program defaults to certain positions, but users can modify these two pin positions according to their product design without changing the Baud Rate setting.
UART Pin
nRF51
nRF52
TXD
P0.09
P0.06
RXD
P0.11
P0.08
4. Use nRFConnect DTM for testing by adjusting UART TX/RX pins.
Nordic provides a tool for simpler RF testing, allowing the configuration of radio-related data such as TX power, frequency, TX carrier, and TX modulation carrier through a Command List. It doesn’t include testing for RX sensitivity; if needed, users must either write a program for this test or use DTM for testing.
1. Open from nRF5_SDK_vxx\examples\peripheral\radio_test\board number\blank (Based on the IC/module for testing, referring to the board number below.)
IC P/N
board number
NRF52832
pca10040
NRF52810
pca10040e
NRF52840
pca10056
NRF52811
pca10056e
NRF52833
pca10100
NRF52820
pca10100e
2. This test also utilizes a Command-based approach to send instructions for different parameter tests. Compared to DTM, Radio Test is more flexible, offering a wider range of RF parameters to test. The connection method between the target board and PC, serial port modifications, and the approach with DTM are identical.
3. Use the command-Line interface (CLI) through the serial port to control and test the output power, bitrate, and channel settings of the radio parameters during testing.
Additionally, configure the CLI to enable the 32 MHz high-frequency crystal oscillator.
The application allows setting scanning mode with intervals ranging from 1 millisecond to 99 milliseconds (per 1 millisecond) for each channel.
4. Refer to the Nordic CLI commands documentation for the command testing method.
Raytac Corporation 
