EFR32FG28B310F1024IM68
サブ GHz と 2.4 GHz の BLE SoC
EFR32FG28B310F1024IM68 には、RM Cortex- M33 コアが搭載されて、専用セキュリティコアが高速暗号化、セキュア・ブート・ローディング、デバッグ・アクセス・コントロールを提供しながら、多くのプロセス機能を提供します。このデバイスは、1024 kB のフラッシュ、256 kB の RAM が搭載し、QFN48 パッケージで提供されています。最大 16 dBm の最大パワー出力と -124.8(4.8 kbps OQPSK @ 915 MHz)dBm の優れた受信感度を誇る EFR32FG28B310F1024IM68 は、サブ GHz の独自アプリケーションのための信頼性のある通信と堅牢な RFリンクと業界最先端のサブ GHz のエネルギー効率を提供します。
仕様
技術文書
ソフトウェアとツール
品質と包装
コミュニティとサポート
仕様
主要仕様
MCU コア
ARM Cortex-M33
|
フラッシュ (kB)
1024
|
RAM (kB)
256
|
||
サブ GHz 対応
あり
|
パッケージ・タイプ
QFN48
|
デジタル I/O ピン
31
|
||
Secure Vault
高
|
MCU コア
ARM Cortex-M33
|
フラッシュ (kB)
1024
|
RAM (kB)
256
|
サブ GHz 対応
あり
|
パッケージ・タイプ
QFN48
|
デジタル I/O ピン
31
|
Secure Vault
高
|
EFR32xG28 Pro キット +20 dBm
EFR32xG28 Pro キット +14 dBm
EFR32xG28 2.4 GHz BLE および +14 dBm 無線基板
EFR32xG28 2.4 GHz BLE および +20 dBm 無線基板
EFR32xG28 エクスプローラー・キット
技術文書
- アプリケーション・ノート (33)
- データ・シート (2)
- データ・ショート (1)
- 正誤表 (1)
- ガイドとマニュアル (20)
- クイック・スタート・ガイド (1)
- リファレンス・マニュアル (1)
- ユーザー・ガイド (18)
- PCNs (3)
- リリース・ノート (78)
- ホワイト・ペーパー (8)
- AN0002.2:EFM32 and EFR32 Wireless Gecko Series 2 Hardware Design Considerationsv1.62/7/2024
- AN0016.2:オシレータ設計上の考慮事項v2.310/10/2023
- AN923.2:EFR32 Series 2 sub_GHz Matching Guidev0.88/13/2023
- AN928.2:EFR32 Series 2 Layout Designv1.58/7/2024
- AN928.2:EFR32 系列 2 布局设计指南v1.411/2/2023
- AN930.2:EFR32 Series 2 2.4 GHz Guidev1.48/7/2024
- AN0948.2:EFM32 and EFR32 Series 2 DC-to-DC Converterv0.66/28/2023
- AN1135:第3世代不揮発性メモリ(NVM3)データ・ストレージを使用v1.48/14/2024
- AN958:カスタム設計のデバッグおよびプログラミング・インターフェイスv0.99/2/2022
- AN958:カスタム設計のデバッグおよびプログ ラミング・インターフェイスv0.69/2/2022
- AN958:自定义设计的调试和编程接口v0.69/2/2022
- AN700.1: Manufacturing Test Guidelines for the EFR32v0.29/2/2022
- AN718:製造テスト概要v0.810/19/2022
- AN0012:多目的入出力v2.048/21/2023
- AN0018.2:供給電圧モニタリングv1.110/27/2023
- AN0057.2:EFx32 Series 2 LCD Driverv1.18/3/2023
- AN0918.2:Gecko Series 1 to Series 2 Compatibility and Migration Guidev0.49/1/2022
- AN1085:Gecko Bootloader を Silicon Labs の Connect と使用するv0.512/13/2023
- AN1119:EFR32を搭載したワイヤレス M-Bus アプリケーションにRAILを使用v1.26/6/2024
- AN1189:Incremental Analog to Digital Converter (IADC)v1.211/22/2023
- AN1244:EFR32 Migration Guide for Proprietary Applicationsv0.512/15/2022
- AN1245:EFP01 Configuration Tool Guidev1.19/1/2022
- AN1358:Using Power Manager Instead of Sleep Driver when Migrating Projects from GSDK 2.xv0.19/1/2022
- AN1392:Detailed Timing Test Results for RAILv2024.12.012/17/2024
- AN1398:EFR32 Coulomb Countingv0.15/3/2023
- AN1401:EFR32xG23 and EFM32PG23 to EFR32xG28 and EFM32PG28 Compatibility and Migration Guidev0.48/3/2023
- AN1409:EFR32xG28 Sub-GHz and 2.4 GHz Dual-Band Requirementsv0.18/23/2023
- AN1421:AEC Qualification vs Automotive Gradev0.15/4/2023
- AN1426:Low-power Lean Watchdog Solution on EFR32 Series 2 Devicesv1.09/29/2023
- AN1492:Clock Manager Migration Guidev0.18/23/2024
- AN902:Building Low Power Networks with the Silicon Labs Connect Stack v2.xv0.512/15/2021
- AN969:Measuring Power Consumption on Wireless Gecko Devicesv0.59/2/2022
- AN972:EFR32 RF 評価ガイドv0.87/18/2023
- EFR32FG28 ワイヤレス SoC ファミリ・データシートv1.111/1/2023
- EFR32FG28 ワイヤレス SoC ファミリ・データ・ショート v0.36/8/2023
- EFR32FG28 正誤表v0.18/3/2023
- QSG168:Proprietary Flex SDK v3.x Quick-Start Guide v0.66/8/2023
- EFR32xG28 Wireless SoC Reference Manual v1.11/30/2024
- UG409:RAILtest User's Guide v4.22/14/2024
- UG103.6:ブートローダの基礎 v2.17/27/2023
- UG115:ASHv3 プロトコル・リファレンス v0.612/15/2021
- UG235.01:Developing Code with Silicon Labs Connect v2.x v0.412/15/2021
- UG235.03:Architecture of the Silicon Labs Connect Stack v2.x v0.512/15/2021
- UG235.07:Energy Saving with Silicon Labs Connect v2.x v0.312/15/2021
- UG235.08:Using the Command Line Interface with Silicon Labs Connect v2.x v0.212/15/2021
- UG235.09:Developing NCP Applications with Silicon Labs Connect v2.x v0.212/15/2021
- UG435.01:About the Connect v3.x User's Guide v0.29/9/2021
- UG435.02:Using Silicon Labs Connect v3.x with IEEE 802.15.4 v0.212/13/2023
- UG435.03:Architecture of the Silicon Labs Connect Stack v3.x v0.19/9/2021
- UG435.05:Using Real-Time Operating Systems with Silicon Labs Connect v3.x v0.312/13/2023
- UG435.06:Bootloading and OTA with Silicon Labs Connect v3.x v0.19/9/2021
- UG435.07:Energy Saving with Silicon Labs Connect v3.x v0.19/9/2021
- UG435.08:Network Co-Processor Applications with Silicon Labs Connect v3.x v0.16/8/2023
- UG460.2:EFR32 Series 2 Long Range Configuration Reference v0.112/13/2023
- UG534:xG28 Dual Band +14 dBm Radio Board User's Guide v1.08/11/2023
- UG535:xG28 Dual Band +20 dBm Radio Board User's Guide v1.08/11/2023
- HomeKit SDK Release Notesv1.4.0.012/15/2022
- Proprietary Flex Release Notesv2.7.10.09/9/2021
- Proprietary Flex Release Notesv2.7.9.09/9/2021
- Proprietary Flex Release Notesv3.5.6.07/3/2024
- Proprietary Flex Release Notesv3.1.1.09/9/2021
- Proprietary Flex Release Notesv3.1.2.09/9/2021
- Proprietary Flex Release Notesv2.6.5.09/9/2021
- Proprietary Flex Release Notes 3.2.0.0v3.2.0.09/9/2021
- Connect Release Notesv4.0.0.012/13/2024
- Proprietary Flex Release Notesv3.7.5.010/22/2024
- Proprietary Flex Release Notesv3.4.2.09/28/2022
- Proprietary Flex Release Notesv3.8.0.06/6/2024
- Proprietary Flex Release Notesv3.5.2.03/10/2023
- Proprietary Flex Release Notesv3.5.1.02/1/2023
- Proprietary Flex Release Notesv3.8.1.07/24/2024
- Proprietary Flex Release Notesv3.0.2.010/9/2020
- Proprietary Flex Release Notesv3.4.0.06/8/2022
- Proprietary Flex Release Notesv3.8.2.09/17/2024
- Proprietary Flex Release Notesv3.7.3.05/3/2024
- Proprietary Flex Release Notesv3.1.0.012/9/2020
- Proprietary Flex Release Notesv3.2.8.09/5/2023
- Proprietary Flex Release Notesv3.6.3.03/13/2024
- Proprietary Flex Release Notesv3.7.2.04/10/2024
- Proprietary Flex Release Notesv2.7.8.010/29/2020
- Proprietary Flex Release Notesv3.3.1.01/28/2022
- Proprietary Flex Release Notesv3.6.2.010/9/2023
- Proprietary Flex Release Notesv3.5.5.01/24/2024
- Proprietary Flex Release Notesv3.4.6.09/14/2023
- Proprietary Flex Release Notesv3.4.4.01/19/2023
- Proprietary Flex Release Notesv2.7.12.09/21/2023
- Proprietary Flex Release Notesv3.3.2.03/10/2022
- Proprietary Flex Release Notesv3.4.3.010/19/2022
- Proprietary Flex Release Notesv3.7.0.012/13/2023
- Proprietary Flex Release Notesv3.2.9.010/25/2023
- Proprietary Flex Release Notesv3.5.0.012/15/2022
- Proprietary Flex Release Notesv3.6.0.06/8/2023
- Proprietary Flex Release Notesv3.4.1.08/16/2022
- Proprietary Flex Release Notesv3.2.7.07/13/2023
- Proprietary Flex Release Notesv3.6.1.07/27/2023
- Proprietary Flex Release Notesv3.7.4.08/12/2024
- Proprietary Flex Release Notesv3.4.5.06/28/2023
- Proprietary Flex Release Notesv3.5.4.08/17/2023
- Proprietary Flex Release Notesv3.7.1.02/14/2024
- Proprietary Flex Release Notesv3.3.0.012/15/2021
- Proprietary Flex Release Notesv3.0.1.010/1/2020
- Proprietary Flex Release Notes 3.2.2.0v3.2.2.09/10/2021
- Proprietary Flex SDK 3.2.3.0 GA Release Notesv3.2.3.010/13/2021
- Proprietary RAIL Release Notesv2.18.0.012/13/2024
- USB Stack Release Notesv1.4.0.012/13/2024
- USB Stack Release Notesv1.1.0.012/15/2022
- USB Stack Release Notesv1.2.3.08/12/2024
- Wi-SUN Release Notesv1.3.2.09/28/2022
- Wi-SUN Release Notesv1.5.2.05/3/2023
- Wi-SUN Release Notesv1.2.1.01/28/2022
- Wi-SUN SDK 1.1.2.0 GA Release Notesv1.1.2.010/13/2021
- Wi-SUN SDK 1.5.1.0 GA Release Notesv1.5.1.03/10/2023
- Wi-SUN SDK Release Notesv1.10.0.04/10/2024
- Wi-SUN SDK Release Notesv1.10.1.05/3/2024
- Wi-SUN SDK Release Notesv1.3.1.08/16/2022
- Wi-SUN SDK Release Notesv1.2.0.012/15/2021
- Wi-SUN SDK Release Notesv1.8.0.012/13/2023
- Wi-SUN SDK Release Notesv1.5.0.02/1/2023
- Wi-SUN SDK Release Notesv1.7.1.010/9/2023
- Wi-SUN SDK Release Notesv1.9.0.02/14/2024
- Wi-SUN SDK Release Notesv1.7.0.07/27/2023
- Wi-SUN SDK Release Notesv1.6.0.06/8/2023
- Wi-SUN SDK Release Notesv1.7.2.03/13/2024
- Wi-SUN SDK Release Notesv1.2.3.03/10/2022
- Wi-SUN SDK Release Notesv1.10.3.010/22/2024
- Wi-SUN SDK Release Notesv1.3.0.06/8/2022
- Wi-SUN SDK Release Notesv2.2.0.09/17/2024
- Wi-SUN SDK Release Notesv2.0.0.06/6/2024
- Wi-SUN SDK Release Notesv1.1.0.07/21/2021
- Wi-SUN SDK Release Notesv2.1.0.07/24/2024
- Wi-SUN SDK Release Notesv2.3.0.012/13/2024
- Wi-SUN SDK Release Notesv1.10.2.08/12/2024
- Wi-SUN SDK Release Notesv1.3.3.010/19/2022
- Wi-SUN SDK Release Notes 1.1.1.0v1.1.1.09/10/2021
- UM006:レッスン 6 - EFM32 エネルギーモードv19/9/2021
- LED 電球にワイヤレス接続を追加する10/10/2023
- 接続ワイヤレス IoT デバイスのバッテリ寿命9/28/2023
- 802.15.4 接続でスマート照明を強化する10/10/2023
- Reed Switch Low-power Switch Detection Code Example5/2/2023
- ワイヤレス IoT プロトコルのセキュリティ・トレードオフとコミッショニング方法9/30/2024
- 適切なワイヤレス・メッシュ・ネットワーク・テクノロジーを選択する9/28/2023
- ワイヤレス SoC 設計における 6 つの隠れたコスト10/10/2023
ソフトウェアとツール
EFR32xG28 Pro キット +20 dBm
EFR32xG28 Pro キット +14 dBm
EFR32xG28 2.4 GHz BLE および +14 dBm 無線基板
EFR32xG28 2.4 GHz BLE および +20 dBm 無線基板
EFR32xG28 エクスプローラー・キット
- RF 範囲計算機5/15/2020
品質と包装
品質保証、環境および包装に関する情報
上記の耐用年数は、この部品番号の優先改訂用です。部品番号改訂の完全リストについては、下の検索ボタンを使用してください。
供給継続のための継続的なコミットメントの一環として、サプライチェーンの調整、製品の改善、市場の状況、または同様のビジネス業務上や技術的な問題により、Silicon Labs が必要であると判断した場合、Silicon Labs はピンと互換性があり、機能的に同等の代替製品を提供することがあります。
ビジネス、技術またはその他の理由で Silicon Labs が妥当とする采配を超えた場合、Silicon Labs は、製品を製造中止する必要があると判断し、通知から 6 か月で最後の注文をおこない、通知から 12 か月で最後の出荷をおこなう旨を伝える EOL 通知を発行することをポリシーとしています。本ポリシーは、半導体業界で一般的に使用されている JEDEC 規格 EIA/JESD48 に準拠しています。製品のライフサイクルに必要なサポートを提供します。
Silicon Labsのデバイスの品質、環境、デバイスの構成、テスト結果、出荷、サプライチェーンに関する追加情報を検索し、ダウンロードすることができます。
検索結果には以下が含まれます。
- 製品情報
- 梱包情報
- 品質システム認証
- 財務情報
- 紛争鉱物(CMRT)
- 環境情報
- RoHS 準拠証明書
- REACH 宣言
- 詳細なデバイス構成 (MDDS)
- MCD/FMD
- RoHS 準拠証明書
- 認定データ
- 貿易コンプライアンス:ECC/HTS コード
- サプライチェーン情報
- IPC 1752-2 クラス6 (XML 形式)
- ICP テスト・レポート
- ハロゲンフリー準拠証明書
- PFOS 準拠証明書
- 供給保証書 (長期)
コミュニティとサポート
Time synchronization with RAIL - Example project demonstration
Content
- Motivation
- The Theory
- Realizing in RAIL
- Examples
- Typical use cases
- Further development
Motivation
I used to play quiz game with my friends, but when we needed to determine who was the first, who put his hand after a question arose, we get into disagreement. For this I was long thinking about a simple wireless system, what is able to decide who will be the responder, taking the responsibility (and our annoyance as well) out. This system should consist of one central device and any number of nodes, enhancing the network scalability, and the synchronization process should be simple and quick as well (capable to be done even for every new question), enabling simultaneous synchronization. This task may be done through existing solutions like Bluetooth or Wi-Fi, but I want accuracy in the order of microseconds, to be as precise as possible. RAIL time base is suitable for this, as it is in microseconds. It's not the best example to show the strength of synchronization, but I will cover here in this KBA some other examples.
This KBA presents a solution to synchronize networks containing one Master device and one or more Slave devices.
Application examples
There are many examples around us to everyday use of time synchronization including but not limited to the following.
GPS and other localization examples
Probably the most known application example of time synchronization is GPS (Global Positioning System). The synchronization is necessary to measure distance with wireless devices, as the distance is derived from the amount of time, since we know the velocity of light spreading through the air (vacuum). And if we can measure distance the next step is the positioning or localization.
Multihop network synchronization
If a computer connects to the internet, there is an opportunity right away to synchronize it to the global time (NTP). Since it is a multihop network, the delay from the reference time does increase, so the accuracy decrease with the number of hops.
Similarly, if the task is the scheduling a bunch of sensor nodes spanning a large geographical area it can be solved with time synchronization, where the nodes synchronize their neighbor nodes.
Low duty cycle
If you are not familiar with the term of Low duty cycle (LDC) take a look at this article.
This technology helps to save energy using lower power energy modes with a less accurate timer. There may be need for regular synchronization between the nodes, to minimize the active time along with the consumption, though this process handled automatically due to the communication.
The Theory of Operation
In the context of time synchronization it is good enough for the most application to have one reference time, which is known to all device, and in most cases this is the time of one particular device which dictates the system time. It gives the opportunity to schedule events in a common time base. We will refer to this device, which serves the reference time, as Master, and to the others as Slaves.
The synchronization means that one Slave device tries to estimate the Master's time, and then its operation scheduled in that assumed time base. We intentionally used the 'try' verb, because a synchronization is always inaccurate and requires regular adjustments. Though a simple synchronization can be done very quickly, the hardest part of the process is the evaluation of this inaccuracy, and the (sequential/continuous) correction, especially in a dense network, with a couple of Slave devices.
Time synchronization involves a several new terms which are describing delay times. Without completeness those are:
- Warmup time (including channel access time): the time from assembling packet, through requesting the radio module to send, to the start of the first bit's transmission.
- Transmission time: the time while the packet is on-the-air, from the first bit (end of Warmup time) to the last.
- Propagation time: the time starting from related parts of the packet leave the transmitter and reach receiver (relative: doesn't have beginning nor end).
- Reception time: similarly to the Transmission time, the time while the packet is on-the-air, till the end of the last bit of packet have been totally received.
- Processing time: time to process received packet.
- Settling time: time to set the time base at the receiver to the assumed time base of the transmitter (have not found this time in the literature, but the example application use this).
Using these delay terms and the terms describing difference of two clocking system the inaccuracy can be quantized.
Errors in/during/after synchronization
In terms of Time synchronization two types of error could occur. One is the offset error and the other is the dynamic or slope error (clock drift). Synchronization is nothing more than the elimination of these errors.
The offset error is very straightforward, it is the error measured between two devices right after the synchronization. This kind of error come from the incorrect calculation of delay times. It is a zero-order (constant) error.
The dynamic error is the speed difference between the clocks of the two devices. This is caused by the speed difference of the two oscillator. The dynamic error can be reduced by calibrating the clocking systems to a common reference (e.g. CTune calibration). The quality of this error is in first-order.
These errors might change during the lifetime of a system: as the temperature changes, the oscillators' frequencies change as well. This may be compensable with CTune calibration.
Measuring the errors
The task of synchronizing is very similar to a geometry exercise, finding a straight line in a coordinate system. This task requires a point and a slope or two points in a defined coordinate system. In this metaphor the coordinate system is defined by the "real time" and the Master's time base (assuming the Master device uses a 0ppm clock).
In the figures below the x axis represents the real time, and the y is the (discrete) value of time with the devices' metric (RAIL Time base, which is actually 1μs), the solid line represents the Master's time while the dotted line is the Slave's time.
Offset error compensation
Let's assume first that the slopes are the same (the clocks run at the same speed), therefore we need only a well defined point for the line fitting. With this assumption the offset error can be compensated in the following way:
- Generate an event perceived by the master and slave devices
- Get the event's timestamps on both side (~get to know the coordinate system)
- Share Master's timestamp with the Slave(s) (~get to know the point on the coordinate system)
- Compensate offset error on Slave(s)' side (~place the line on the coordinate system)
The task is to be able to figure out the what is the time on both the Master and the Slave at a given time, using the Slave's time base - It will be different, since they weren't powered up at the same time, thus the counters hold different values.
As a first step it should happen such an event which is perceived on both the Master and the Slave device. It is evident that this event may be a packet transmission and reception, therefore the delay times have to be known. As a result two timestamp generated on each device. Such an event will provide enough information to get the offset error. The clearest way to send a message from the Master, which is received by the Slave(s).
The next step is to share the Master's timestamp with the Slave device(s). It means that Master should send an another message, which holds the previous message's timestamp. From this message, the Slave(s) will know much its local clock differs from the Master's clock - the offset error - and will know more or less what time is it on the other at present (with the initial assumption).
Dynamic error compensation
In the real world there is always some difference between the clock systems. This is where the dynamic error takes place, and we should compensate it as well.
This can be done in a very similar way as we saw it in the previous section: we should repeat the process. This means getting an another point on the coordinate system, and from this information the to get the first-order error (the slope, or we can say that the velocity of the offset error's increase) can be defined and the dynamic error can be eliminated.
This process requires only 3 packet to be sent from a Master device, as the second packet, which holds the first packet's timestamp has it's own timestamp, which can be sent in the third packet.
Once these errors are known, they can be eliminated by calculation (software) or by modifying the clocking system (hardware) to be synchronized.
Implementation in RAIL
We have released an improved version of the time synchronization algorithm in our proprietary_rail GitHub repository, now featured in a fully detailed example application. Check the RAIL Proprietary - Time Synchronization application out!
Possibilities
RAIL supports timestamping for both the transmitted and the received packet. The enum RAIL_PacketTimePosition_t
defines the possibilities timestamp positions. The available positions are:
- the start of the preamble (first preamble bit sent or received)
- end of the syncword (last syncword bit sent or received),
- end of the packet (last bit of the packet sent or received).
In fact, at TX side only the end of the packet will be recorded as timestamp, and the other timestamps calculated relatively from this value. This implies additive error due to dynamic error in case of a very long packet (though it is almost negligible). Furthermore this means that there is no way to timestamp the packet, then send out the timestamp in that same packet.
NOTE: This will change in the future on some devices!
Since we won't use long packets in such an application, and this difference from dynamic error would be eliminated with the offset error compensation, we chose the timestamp position to the end of syncword (though it does not have any benefit).
The synchronization process
This image shows the synchronization process:
The red part is the preamble and the syncword of the packet. The Slave must save the timestamp of first packet's end (T_s) as well as the Master (T_m). The difference between the two timestamp is the propagation time (T_prop). Then in the second packet the Master device should send T_m, which is in its own time base. Finally the Slave device receiving T_m will know the difference between its own and the Master's time base eliminating the offset error, whic is the first step of synchronization.
But then, after a while, the error between the time assumed by the Slave, and the real time according to the Master's time base will differ due to HFXO clock deviation. This can be reduced repeating the previous step and "predicting" the masters new T_m from the last known value. The difference of the actual and the predicted T_m shows whether the Slave clocks are slower or the Master's. That way the slope error can be estimated. The accuracy of the estimation improves with the increasing delay between the synchronizations.
One can add the question: what about the delay times? We did not care about most of them (ones have definite beginning and end), due to the timestamp system of RAIL eliminates them. We didn't care about the propagation time either, since it is less than 1 us (what is the resolution of our timer) if the distance between the two device is less than 300 m.
Explanation of the code
The application is based on the example "simple-rail-with-hal" for BRD4169B and BRD4164A radio boards (EFR32MG14/MG12) which was used with WSTK. The application is using the Command interpreter Plugin, thus "Virtual COM Port" has to be enabled in the hardware configurator. No other modification should be made in the radio and hardware configurator.
The application was extended with two additional packet: One from the Slave with an assumed value (T_predict) to the Master's second packet's timestamp, and with a compensation feedback (T_comp) from the Master, which tells the Salve how accurate the prediction was.
Caution: This is only a demonstration project, we want to show the synchronization process in the simplest way, so our implementation can be improved. Furthermore it contains features assisting debug. Here are some notes what you should avoid in your design.
- Don't use the
RAIL_SetTime()
API in that way, as it is used here. - The blocking delay implementation is not recommended. A timer interrupt routine may be more elegant in your project.
- Starting Master without Slave (or vice versa) will stuck while it won't get any packet. You should reset the device to exit this state.
States and roles
The application operates upon a state machine, equipped with command line interface, GPIO interrupt handlers for push buttons, and with radio event handling functionality. 5 state was implemented for both Master and Slave(s). Those are matching to each other. These are:
- Waiting for start (pushbutton or CLI command),
- Sending/receiving first packet from Master (produce timestamps T_m_1 and T_s_1),
- Sending/receiving second packet from Master (produce T_m_2 and T_s_2 and send/get T_m_1),
- Sending/receiving first packet from Slave (send T_predict for predicting T_m_2),
- Sending/receiving third packet from Master (get T_comp).
A single application has been developed with two roles: there is a run-time variable to select whether a device is Master (default) or Slave.
typedef enum MasterStates {
MASTER_WAIT, MASTER_STATE_SEND_FIRST_PACKET, MASTER_STATE_SEND_SECOND_PACKET,
} MasterStates_t;
typedef enum MasterStates {
MASTER_WAIT, MASTER_STATE_SEND_FIRST_PACKET, MASTER_STATE_SEND_SECOND_PACKET,
} MasterStates_t;
typedef enum Role {
ROLE_MASTER, ROLE_SLAVE
} Role_t;
...
static Role_t role = ROLE_MASTER;
The CLI commands
The application implements 5 cli commands:
cliSetRole
selects between Master (0) and Slave (1) roles,cliStart
starts a synchronization process (if the argument is 1),cliSetCtune
sets the CTune value (second argument); if the first argument is 0 the second argument will be used as CTune, if 1 the second argument will be saved to the User Page first, if 2 the CTune value will be fetched from the User Page and the second argument will not take any effect,cliGetTime
prints the current time,cliGetVal
prints one of the timestamps or calculations (for debug use only).
The interrupt handler routines
The interrupt handling routines are mostly setting flags which are monitored in the main loop.
static volatile bool sent = false;
static volatile bool received = false;
static volatile bool start = false;
The left pushbutton (PB1) does exactly the same thing as cliStart
command does, while the right (PB0) operates as cliGetTime
.
void gpioCallback(uint8_t pin) {
if (pin & 0x01) {
start = true;
} else {
RAIL_Time_t t = RAIL_GetTime();
printf("time %d\n", t);
}
}
The enabled radio events are the RX and TX related ones. Only for the successful events are handled in this application, RAIL_EVENT_TX_PACKET_SENT
and RAIL_EVENT_RX_PACKET_RECEIVED
. Every packet transmission and reception refreshes the timestamp value bound to the syncword's last bit.
static volatile RAIL_PacketTimeStamp_t timeStamp;
...
RAIL_Events_t events = (RAIL_EVENTS_TX_COMPLETION | RAIL_EVENTS_RX_COMPLETION);
RAIL_ConfigEvents(railHandle, events, events);
...
void RAILCb_Generic(RAIL_Handle_t railHandle, RAIL_Events_t events) {
if (events & RAIL_EVENT_TX_PACKET_SENT) {
// Set flag for the main loop
sent = true;
RAIL_TxPacketDetails_t packetDetails = { .timeSent = timeStamp .isAck = false };
RAIL_GetTxPacketDetails(railHandle, &packetDetails);
timeStamp = packetDetails.timeSent;
// Don't print in the event handler! We do that for demonstration only.
printf("packet sent\n");
}
if (events & RAIL_EVENT_RX_PACKET_RECEIVED) {
// Set flag for the main loop
received = true;
// Get the newest packet's information from RX FIFO
RAIL_RxPacketInfo_t packetInfo;
RAIL_RxPacketHandle_t packetHandle = RAIL_RX_PACKET_HANDLE_NEWEST;
RAIL_GetRxPacketInfo(railHandle, packetHandle, &packetInfo);
// Set the position of the packet where the timestamp should be acquired,
// and the packet's length to calculate it correctly
timeStamp.timePosition = RAIL_PACKET_TIME_AT_PACKET_END;
timeStamp.totalPacketBytes = packetInfo.packetBytes;
RAIL_RxPacketDetails_t packetDetails = { .timeReceived = timeStamp };
RAIL_GetRxPacketDetails(railHandle, packetHandle, &packetDetails);
RAIL_CopyRxPacket(rxPacket, &packetInfo);
RAIL_ReleaseRxPacket(railHandle, packetHandle);
timeStamp = packetDetails.timeReceived;
RAIL_ResetFifo(railHandle, false, true);
// Don't print in the event handler! We do that for demonstration only.
printf("packet received %d\n", timeStamp.packetTime);
}
}
Manual calibration
In this section we will present how the application works.
After flashing the binary to two device we connected their serial ports to a PC. In the serial terminal we should only issue a setRole 1
command to select the slave device. Push the PB1 first on the slave (this will enable RX) and then on the master (send the first message). After some milliseconds the two device will be synchronized.
We can prove that the the devices are synchronized by getting the current time from both device in the same time. This can be done with pushing PB0, while the two GPIO lines are connected. The button's line can be found at the seventh pin of the external pin header connector on the WSTK (using the BRD4169B radio boards).
I pushed PB0 per ~1 second, and the two terminal windows printed the following timestamps (in microseconds):
The first time pair shows that the slave counts 3 more us than the master device, and in ~29 seconds the difference increased to 16 us. It means that the slave's clock ran faster causing 1 us drift per ~2.25 second (slope error).
Adjusting CTune (with the SetCtune
command) this kind of error can be minimized (increasing on the slave to slow down, or decreasing on the master to speed up the oscillator).
This accuracy is now good enough for my quiz application.
Effects of incorrect layout design
1. Introduction
The purpose of this KBA is to explore the effects of certain changes to the layout of a radio board (specifically the xG28). Before moving on to the results care needs to be taken into how the measurements were performed. The frequencies used for this investigation are both 868 MHz and 2.4Ghz with an output power of 14 dBm and 10 dBm respectively.
Figure 1. Unmodified xG28 Board
1.1 Tx Conducted
Both Tx and Rx conducted measurements were carried out where the Tx measurement consists of connecting the DUT (Device Under Test) to a spectrum analyzer and reading out the fundamental and harmonic power levels at max Tx power. The cable attenuation that is connecting the DUT to the spectrum Analyzer is then measured and the results are compensated. It should be noted that only one frequancy was checked on the device and so the effects across whole frequency bands were not investigated.
Figure 2. TX conducted measurement setup
1.2 Rx conducted
On the Rx side two measurements were considered, the sensitivity measurement and a blocking measurement. In the sensitivity measurement the DUT is connected to a signal generator which generates a packet of known sequence and sends this packet to the device placed in an isolation box. The power level of the generator is then gradually decreased until it reaches a defined packet error threshold (usually around 10 %). The power level of the generator at this threshold is called the sensitivity.
Figure 3. RX conducted measurement setup
A crude blocking was measured to see the effects of a sub-GHz transmission on the 2.4 GHz reception. A generator was connected to the sub-GHz input which produced a constant 0 dBm signal, simultaneously another generator was connected to the 2.4Ghz path. During the measuremet, the power level of this generator would gradually be decreased until the 10% PER limit, this was then recorded as the isolation of the device.
Figure 4. RX conducted blocking measurement setup
1.3 Tx Radiated
For some designs the radiated performance was observed. To do this the DUT was placed in an anechoic chamber on a rotating pillar. The chamber is then sealed, and the device transmits a continuous wave at the desired frequency, while the pillar is rotated. There is another antenna in the chamber which receives said signal and feeds it to a spectrum analyzer. Another parameter which is checked for some DUTs is the effects the changes in the layout have on the antenna pattern.
Figure 5. Radiated measurement setup
2. Layout design
Moving onto the designs, the goal of each layout design is to minimize the changes to one or more concepts and observe the effects on the performance. The measurements stated above were also performed on an unchanged xG28 board, although it must be stated that these measurements were performed in a non-ideal environment and thus are not equivalent to validation or datasheet values. The purpose of the measurement was purely to observe any performance changes corresponding to changes in the layout.
2.1 Modified matching keep out
In this design the keep-out between the matching components and the top layer ground was decreased.
Figure 7. Keep-out modified board
This theoretically should lead to an increase in harmonics and lower output power and from the measured data this seems to be the case:
2.1.1 Sub gig Tx Conducted:
Figure 8. 868 MHz Keep-out modified Tx (Blue) vs Unmodified board (Red)
2.1.2 2.4GHz Tx Conducted:
Figure 9. 2.4GHz Keep-out modified Tx (Blue) vs Unmodified board (Red)
2.1.3 Sub gig Rx Conducted:
Figure 10. 868MHz Keep-out modified board RX (Blue) vs Unmodified board (Green)
2.1.4 2.4GHz Rx Conducted:
Figure 11. 2.4GHz Keep-out modified board RX (Blue) vs Unmodified board (Green)
From these results, we can see that the change in the keep-out had a noticable effect on the sub-GHz network, as shown by the detuned matching (that results in lower fundamental and higher harmonic output powers). However, it can also be seen that this effect is highly frequency dependent, as the 2.4 GHz network doesn't show as big of a change in performance.Another reason for the discrepancy of the sub-GHz from the 2.4 GHz results may be due to the fact that the 2.4 GHz is operating at 10 dBm while the sub-GHz operates at 14dBm . What this means is that the sub-GHz electromagnetic field is stronger and thus will couple more effectively to the top layer ground thus changing the impedance in a greater manner.
The reason why this happens is due to changes in impedance, coming from coupling between metallic surfaces. At high frequencies there is a capacitive effect with the ground as the trace effectively transforms into a capacitor and when the distance between the trace and the ground changes the impedance changes as well. This change can lead to detuning in the matching.
Figure 12. Coupling with a vertical cut (top) and from a top down view with parasitic effects(bottom).
2.2 Stackup changed
In this board the stackup was changed, the grounding under the RF trace was completely removed. This demonstrates two concepts, the effect an increase in dielectric height can have and the results of the removal of the ground layer. The grounding layer, while also important in the matching, also plays a big role in harmonic performance and the change in the dielectric could lead to detuning the matching in a similar fashion to the keep out.
Figure 13. Stackup modified board
2.2.1 Sub-GHz Tx Conducted:
Figure 14. 868 MHz Stackup modified Tx (Blue) vs Unmodified board (Red)
2.2.2 2.4GHz Tx Conducted:
Figure 15. 2.4 GHz Stackup modified Tx (Blue) vs Unmodified board (Red)
2.2.3 Sub-GHz Rx Conducted:
Figure 16. 868MHz Stackup modified board RX (Blue) vs Unmodified board (Green)
2.2.4 2.4GHz Rx Conducted:
Figure 17. 2.4GHz Stackup modified board RX (Blue) vs Unmodified board (Green)
Figure 18. Blocking of Stackup modified board RX (Blue) vs Unmodified board (Green)
2.2.5 Sub gig Tx Radiated:
Figure 19. 868 MHz Stackup modified boards Tx power and Harmonics (top) and a comparison of the power to an unmodified board (bottom)
2.2.6 2.4GHz Tx Radiated:
Figure 20. 2.4 GHz Stackup modified board's Tx power and Harmonics (top) and a comparison of the power to an unmodified board (bottom)
2.2.7 2.4GHz Radiation pattern:
Figure 21. 2.4 GHz antenna pattern of Stackup modified (top) and an unmodified board (bottom)
As can be seen these changes have led to higher harmonics and decreased output power. As with the keep-out there is also coupling from the trace to the ground plane. Another issue with this removal of ground is that the ground plane plays a key role in harmonic performance as seen in the measurements.
Figure 22. Coupling to ground layer
2.3 RF path routed to bottom layer
In a design where there are space constraint placing some components to other side of the board is common. However, care must be taken in regards to the RF Path and it is not recommended to route the RF path to other layers.
Figure 23. RF bottom layer modified board
2.3.1 Sub gig Tx Conducted:
Figure 24. 868 MHz RF Bottom modified Tx (Blue) vs Unmodified board (Red)
2.3.2 2.4GHz Tx Conducted:
Figure 25. 2.4 GHz RF Bottom modified Tx (Blue) vs Unmodified board (Red)
2.3.3 Sub gig Rx Conducted:
Figure 26. 868MHz RF Bottom modified board RX (Blue) vs Unmodified board (Green)
2.3.4 2.4GHz Rx Conducted:
Figure 27. 2.4GHz RF Bottom modified board RX (Blue) vs Unmodified board (Green)
The results show the effects of routing the RF trace. When routing to other layers, vias must be used and these vias also introduce some changes in the impedance in the path and this will lead to the results observed.
2.4 Small grounding
In some designs a smaller board may be necessary however in regards to Silicon Labs recommended designs simply changing the size of the board may not be enough and some redesign may be necessary. One big problem in smaller designs is that the ground will be significantly reduced, this could lead to similar results of the removed ground board as well as some issues in regards to the antenna efficiency as this is dependent on the grounding.
Figure 28. Small grounding modified board
2.4.1 Sub-Ghz Tx Conducted:
Figure 29. 868 MHz Small Grounding modified Tx (Blue) vs Unmodified board (Red)
2.4.2 2.4GHz Tx Conducted:
Figure 30. 2.4 GHz Small Grounding modified Tx (Blue) vs Unmodified board (Red)
2.4.3 Sub-GHz Rx Conducted:
Figure 31. 868MHz Small Grounding modified board RX (Blue) vs Unmodified board (Green)
2.4.4 2.4GHz Rx Conducted:
Figure 32. 2.4GHz Small Grounding modified board RX (Blue) vs Unmodified board (Green)
Figure 33. Blocking Small Grounding modified board RX (Blue) vs Unmodified board (Green)
2.4.5 Sub-Ghz Tx Radiated:
Figure 34. 868 MHz Small grounding modified boards Tx power and Harmonics (top) and a comparison of the power to an unmodified board (bottom)
2.4.6 2.4GHz Tx Radiated:
Figure 35. 2.4 GHz Small Grounding modified boards Tx power and Harmonics (top) and a comparison of the power to an unmodified board (bottom)
2.4.7 2.4GHz Radiation pattern:
Figure 36. 2.4 GHz antenna pattern of Small grounding modified (top) and an unmodified board (bottom)
The measurements show significant effects on the onboard antenna. For this measurement, only the 2.4 GHz frequency band was tested as this is a PCB antenna that is recommended for use by Silicon Labs.
2.5 Matching spread
As seen in previous measurements the matching can be sensitive to changes in impedance through slight changes to the PCB, one other important factor is how close together the matching components are to one another.
Figure 37. Spread matching modified board
2.5.1 Sub-GHz Tx Conducted:
Figure 38. 868 MHz Spread matching modified Tx (Blue) vs Unmodified board (Red)
2.5.2 2.4GHz Tx Conducted:
Figure 39. 2.4 GHz Spread matching modified Tx (Blue) vs Unmodified board (Red)
2.5.3 Sub-GHz Rx Conducted:
Figure 40. 868MHz Spread matching modified board RX (Blue) vs Unmodified board (Green)
2.5.4 2.4GHz Rx Conducted:
Figure 41. 2.4GHz Spread matching modified board RX (Blue) vs Unmodified board (Green)
Moving the components further away not only increases the capacitance along the traces but also the inductance (the inductance changes with the changes in length). Which again changes the impendence of the match leading to a non 50-ohm match which would lead to matching losses.
2.6 Routing under RF trace
One recommendation is to keep a uniform grounding under the RF trace. A reason for this is to keep cross talk to the RF path to a minimum as well as to not detune the 50-ohm match on the system.
Figure 42. Routing modified board
2.6.1 Sub-GHz Tx Conducted:
Figure 43. 868 MHz Routing modified Tx (Blue) vs Unmodified board (Red)
2.6.2 2.4GHz Tx Conducted:
Figure 44. 2.4 GHz Routing modified Tx (Blue) vs Unmodified board (Red)
2.6.3 Sub-GHz Rx Conducted:
Figure 45. 868MHz Routing modified board RX (Blue) vs Unmodified board (Green)
2.6.4 2.4GHz Rx Conducted:
Figure 46. 2.4GHz Routing modified board RX (Blue) vs Unmodified board (Green)
2.6.5 Sub-GHz Tx Radiated:
Figure 47. 868 MHz Routing modified boards Tx power and Harmonics (top) and a comparison of the power to an unmodified board (bottom)
2.6.6 2.4GHz Tx Radiated:
Figure 48. 2.4 GHz Routing modified boards Tx power and Harmonics (top) and a comparison of the power to an unmodified board (bottom)
Unfortunately, the crosstalk effect was not checked against as the traces under the RF path where not communicating as much as in a real-world operation. However, the change in the 50ohm match can be observed. This change is due to the non-uniformity in the plane under the RF path which would change not only the coupling characteristics along the trace but also limits the harmonic suppression ability of the grounding layer.
RX Direct Mode on EFR32xG23
We define RX Direct Mode as when the demodulated data is continuously available as an internal signal within the radio, which is most often quantized to 1 bit (as a 2-level modulation) and wired to a GPIO of the RFIC.
The demodulated data (DOUT) signal can be either synchronous or asynchronous.
Synchronous direct mode means that the radio collects the data from the demodulator after timing recovery by the rate of the local RX data clock. In synchronous direct mode, the RX data clock signal (DCLK) is also available to leverage data sampling.
In asynchronous direct mode, the data collection takes place before bit synchronization. Typically, the data is oversampled in this mode since the radio does not provide the clock signal to synchronize.
The direct mode signals are available on a GPIO via PRS or DBUS interface. However, routing these signals is insufficient for a proper direct mode; the radio can operate in packet mode (i.e., RAIL's packet handling still works), where the synchronous signals are active only after packet detection.
In direct mode use cases, instead of the radio's demodulator, a software performs the frame detection. Therefore, in direct mode applications, the signal detection (i.e., preamble and sync word detections) must be disabled to provide the data continuously by keeping the receiver always active.
In this article we introduce
- the synchronous and
- the asynchronous direct mode, as well as
- the packet mode with DOUT signal.
Use ...
... Synchronous Direct Mode
- When robust signal detection cannot be set up in the radio configuration, however, the frame can be easily detected employing the demodulated bit stream.
- Synchronous direct mode is also appropriate for BER tests.
... Asynchronous Direct Mode
- In channel scanning/protocol learning applications where the frequency or the baud rate is not precisely known.
- In applications where enormous baud rate tolerance is desired.
Note: It is strongly recommended to fully disable the detection system in this operational mode.
... Packet Mode with DOUT Signals
- For auxiliary detection method (e.g., inspect the demodulated data if non-standard preamble patterns are used).
- For debug purposes.
Enable Direct Mode in the Radio Configuration
⚠️ This chapter has been reworked as direct mode support has been added to the Radio Configurator. If you previously added the overrides manually to the
.radioconf
file detailed in an earlier version of this article, you should remove them and follow the guidelines outlined below.
The Radio Configurator supports both asynchronous and synchronous direct mode for the EFR32xG23 platform. To enable direct mode, set the RX Direct Mode
option under the Modem
tile either to SYNC
or ASYNC
according to your needs.
If Direct Mode is enabled the packet-related configuration options will be disabled, as there is no packet handling in Direct Mode.
Note: Saving the
.radioconf
, even outside Simplicity Studio v5, can trigger a radio config regeneration if you keep the project open in the IDE.
Assigning DOUT and DCLK Signals to GPIO Pins
Although, the DOUT and DCLK signals can be consumed internally (i.e., within the MCU) via the PRS module, these signals also can be assigned to any GPIO of the device. The PRS_MODEML_DOUT
and PRS_MODEML_DCLK
PRS signals use the same internal sources as the MODEM.DOUT
and MODEM.DCLK
DBUS signals.
The following code snippet assigns the DOUT and DCLK PRS signals to PC0 and PC1 GPIO pins:
#define DOUT_GPIO_PORT gpioPortC
#define DCLK_GPIO_PORT gpioPortC
#define DOUT_GPIO_PIN 0
#define DCLK_GPIO_PIN 1
/*
Channel 0-5 available on GPIO port A/B
Channel 6-11 available on GPIO port C/D
*/
#define DOUT_PRS_CHANNEL 6
#define DCLK_PRS_CHANNEL 7
// (...)
CMU_ClockEnable(cmuClock_PRS, true);
PRS_ConnectSignal(DOUT_PRS_CHANNEL, prsTypeAsync, PRS_MODEML_DOUT);
PRS_ConnectSignal(DCLK_PRS_CHANNEL, prsTypeAsync, PRS_MODEML_DCLK);
PRS_PinOutput(DOUT_PRS_CHANNEL, prsTypeAsync, DOUT_GPIO_PORT, DOUT_GPIO_PIN);
PRS_PinOutput(DCLK_PRS_CHANNEL, prsTypeAsync, DCLK_GPIO_PORT, DCLK_GPIO_PIN);
GPIO_PinModeSet(DOUT_GPIO_PORT, DOUT_GPIO_PIN, gpioModePushPull, 0);
GPIO_PinModeSet(DCLK_GPIO_PORT, DCLK_GPIO_PIN, gpioModePushPull, 0);
Place this code in the app_init.c
file of an SSv5 project.
You can trace out the DOUT and DCLK signals to GPIOs using the following RAILtest commands:
setdebugsignal <gpio_pin_selection: PC0> CUSTOM_PRS 41 6 // DOUT
setdebugsignal <gpio_pin_selection: PC1> CUSTOM_PRS 41 5 // DCLK
If
RAIL_NEEDS_DOUT_DCLK_WORKAROUND
is set to1
in the debug_ci.c file, the above commands select alternative sources for the DOUT and DCLK signals. Make sure to disable (e.g., force it to0
) this macro if you configure the Direct Mode in the Radio Configurator and you want to use thesetdebugsignal
CLI command to access these PRS signals.
Direct mode RAIL APIs route the DCLK and DOUT signals to GPIOs through the DBUS interface.
For the DBUS routing table, consult with the device's Datasheet.
Note: Although the radio restricts the DBUS signals to PortA and PortB GPIO ports, the PRS signal port availability depends on which PRS channel is used.
Example
This section describes how to test asynchronous direct mode using two EFR32xG23 radio boards.
- Create a RAILtest project for your EFR32xG23 target device.
- Set
RX Direct Mode
toASYNC
in the Radio Configurator and regenerate the config files. - Build the project.
- Download the project to the radio boards.
- Connect a logic analyzer or an oscilloscope to the GPIOs the DOUT signals will be located.
- Issue the following RAILtest CLI commands on the devices:
// TX node:
// transmit a stream signal
setTxStream 1 1
// or transmit packets
tx 0
setdebugsignal <gpio_pin_selection: PC0> CUSTOM_PRS 41 6 // DOUT
// RX node:
setdebugsignal <gpio_pin_selection: PC0> CUSTOM_PRS 41 6 // DOUT
- You can see that the RX device's DOUT signal follows the TX's DOUT. Also, you can see that transmitting packets won't be received on the RX node.