この辞書は、Skyworks (Silicon Labs) Si47XX PROGRAMMING GUIDE AN332 を基に、Google AI (Gemini) の協力を得て作成しています。
1 コマンド 0x24. FM_RDS_STATUS 概要
このコマンドは、主に欧米のFM放送で広く使われているRDS(Radio Data System)、および日本の「見えるラジオ」等で使われていたDARC等に類似したデータ放送システム(※Si4735がネイティブ対応するのは主に欧米のRBDS/RDS規格)のデータ受信状態を取得・制御するための最重要コマンドです。日本国内の一般的なFM放送局から局名やテキストデータを取得することは基本的にできません。4.1.4日本国内での利用における注意点(補足)参照下さい
現在のチャンネルのRDS情報を返し、RDS FIFOからエントリを読み取ります。
RDS情報には、同期ステータス、FIFOステータス、グループデータ(※ブロックA、B、C、D)、および修正されたブロックエラーが含まれます。
※RDSは1つのグループが A, B, C, D という4つの16ビット(2バイト)ブロックで構成されます。
このコマンドは、ARG1のINTACKビットがセットされている場合、RDSINT割り込みビットをクリアします。
また、MTFIFOがセットされている場合は、RDS受信FIFO全体をクリアします(FIFOはFM_TUNE_FREQまたはFM_SEEK_START実行中は常にクリアされます)。
次のコマンドを安全に送信できる状態になると、CTSビット(およびオプションの割り込み)がセットされます。
このコマンドは、電源投入モードのときのみ送信できます。
FIFOサイズは、FMRXコンポーネント2.0以降では25グループ、FMRXコンポーネント1.0では14グループです。
注:
1. FM_RDS_STATUSは、FMRXコンポーネント2.0以降でサポートされています。
2. FMRXコンポーネント2.0ではMTFIFOはサポートされていません。
対応機種:Si4705/06、Si4731/32/35
コマンド引数:1個
応答バイト数:12バイト
2 コマンドパラメータ
2.1 パラメータリスト
| Bit | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 |
|---|---|---|---|---|---|---|---|---|
| CMD | 0 | 0 | 1 | 0 | 0 | 1 | 0 | 0 |
| ARG1 | 0 | 0 | 0 | 0 | 0 | STATUSONLY | MTFIFO | INTACK |
| ARG | Bit | Name | Function |
|---|---|---|---|
| 1 | 2 | STATUSONLY | ステータスのみ。 RDS FIFOからデータを削除するかどうかを判定します。 0 = BLOCKA、BLOCKB、BLOCKC、BLOCKD、およびBLEには、RDS FIFO内で最も古いデータが含まれます。 1 = BLOCKAには、現在の周波数で受信した最後の有効なブロックAデータが含まれます。 BLOCKBには、現在の周波数で受信した最後の有効なブロックBデータが含まれます。 BLEには、BLOCKAおよびBLOCKBのデータのビットエラーが示されます。 |
| 1 | 1 | MTFIFO | FIFO空 0 = FIFOが空でない場合、最も古いFIFOエントリを読み取って削除します。 1 = RDS受信FIFOをクリアします。 |
| 1 | 0 | INTACK | 割り込み応答 0 = RDSINTステータスを保持します。 1 = RDSINTをクリアします。 |
2.2 パラメータ
2.2.1 STATUSONLY(Status Only)
目的
RDSのデータバッファ(FIFO)からデータを消費(ポップ)せずに、ステータスのみを読み取ること。
解説
このビットを 1 にすると、IC内部のRDS受信バッファに溜まっているメッセージデータを削除(消費)することなく、現在の同期状態やバッファの蓄積量(RDSFIFOUSED)などの「状態」だけを安全にチェックできます。
0 に設定した場合は、コマンド実行と同時に最も古いRDSデータブロックがバッファから読み出され、バッファが一つ空きます。
0 に設定した場合は、コマンド実行と同時に最も古いRDSデータブロックがバッファから読み出され、バッファが一つ空きます。
2.2.2 MTFIFO(Empty/Clear FIFO)
目的
IC内部のRDS FIFOバッファを強制的にすべて空(クリア)にすること。
解説
このビットを 1 にしてコマンドを送信すると、バッファ内に残っている未読のRDSデータがすべて破棄されます。
選局(チューニング)を他の周波数に変更した直後など、前の放送局の古いRDSデータが混ざるのを防ぐために、バッファをリセットする目的で使用します
選局(チューニング)を他の周波数に変更した直後など、前の放送局の古いRDSデータが混ざるのを防ぐために、バッファをリセットする目的で使用します
2.2.3 INTACK(Interrupt Acknowledge)
目的
RDSに関連する割り込みステータス(フラグ)をクリア(承認)すること。
解説
このビットを 1 に設定して送信すると、後述する応答パラメータ内の割り込みヒントフラグ(RDSNEWBLOCKB, RDSRECV などの ~INT や ~RECV と付く通知用フラグ)がすべて 0 にリセットされます。
ホストマイコン側でRDS割り込みを検知した後にフラグをクリアし、次のデータ受信に伴う割り込みを受け付けられるようにするために使用します。
ホストマイコン側でRDS割り込みを検知した後にフラグをクリアし、次のデータ受信に伴う割り込みを受け付けられるようにするために使用します。
3 応答パラメータ
3.1 パラメータリスト
| Bit | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 |
|---|---|---|---|---|---|---|---|---|
| STATUS | CTS | ERR | X | X | RSQINT | RDSINT | X | STCINT |
| RESP1 | X | X | RDSNEWBLOCKB | RDSNEWBLOCKA | X | RDSSYNCFOUND | RDSSYNCLOST | RDSRECV |
| RESP2 | X | X | X | X | X | GRPLOST | X | RDSSYNC |
| RESP3 | PILOT | RDSFIFOUSED | ||||||
| RESP4 | PILOT | BLOCKA[15:8] | ||||||
| RESP5 | PILOT | BLOCKA[7:0] | ||||||
| RESP6 | PILOT | BLOCKB[15:8] | ||||||
| RESP7 | PILOT | BLOCKB[7:0] | ||||||
| RESP8 | PILOT | BLOCKC[15:8] | ||||||
| RESP9 | PILOT | BLOCKC[7:0] | ||||||
| RESP10 | PILOT | BLOCKD[15:8] | ||||||
| RESP11 | PILOT | BLOCKD[7:0] | ||||||
| RESP12 | BLEA[1:0] | BLEB[1:0] | BLEC[1:0] | BLED[1:0] | ||||
| RESP | Bit | Name | Function |
|---|---|---|---|
| 1 | 5 | RDSNEWBLOCKB | RDS 新規ブロック B。 1 = 有効なブロック B データを受信しました。 |
| 1 | 4 | RDSNEWBLOCKA | RDS 新規ブロック A。 1 = 有効なブロック A データを受信しました。 |
| 1 | 2 | RDSSYNCFOUND | RDS 同期が見つかりました。 1 = RDS 同期が見つかりました。 |
| 1 | 1 | RDSSYNCLOST | RDS 同期が失われました。 1 = RDS 同期が失われました。 |
| 1 | 0 | RDSRECV | RDS を受信しました。 1 = FIFO が RDSFIFOCNT で設定された最小グループ数まで満たされました。 |
| 2 | 2 | GRPLOST | グループが失われました。 1 = FIFO オーバーランにより、1 つ以上の RDS グループが破棄されました。 |
| 2 | 0 | RDSSYNC | RDS 同期。 1 = RDS は現在同期されています。 |
| 3 | 7:0 | RDSFIFOUSED | RDS FIFO が使用されています。 RDS FIFOに残っているグループ数(空の場合は0)。0以外の場合、 BLOCKA~BLOCKDには最も古いFIFOエントリが格納され、RDSFIFOUSEDはRDS_FIFO_STATUSの次回の呼び出し時に1ずつ減少します(その間にRDSデータが受信されていないことを前提とします)。 |
| 4 | 7:0 | BLOCKA[15:8] | RDSブロックA。 STATUSONLYが0の場合、ブロックAグループには最も古いFIFOエントリのデータが格納されます。STATUSONLYが1の場合、ブロックAの最後の有効なデータが格納されます(Si4706-D50、Si4705/31/35-D50以降、およびSi4732のみ)。 |
| 5 | 7:0 | BLOCKA[7:0] | |
| 6 | 7:0 | BLOCKB[15:8] | RDS同期が失われました。 1 = RDS同期が失われました。 RDSブロックB。 STATUSONLYが0の場合、ブロックBグループのデータは最も古いFIFOエントリから取得されます。 STATUSONLYが1の場合、ブロックBの最後の有効なデータが使用されます(Si4706-D50、Si4705/31/35-D50以降、およびSi4732のみ)。 |
| 7 | 7:0 | BLOCKB[7:0] | |
| 8 | 7:0 | BLOCKC[15:8] | RDSブロックC。 ブロックCは、最も古いFIFOエントリからデータをグループ化します。 |
| 9 | 7:0 | BLOCKC[7:0] | |
| 10 | 7:0 | BLOCKD[15:8] | RDSブロックD。 ブロックDは、最も古いFIFOエントリからデータをグループ化します。 |
| 11 | 7:0 | BLOCKD[7:0] | |
| 12 | 7:6 | BLEA[1:0] | RDSブロックAの訂正済みエラー。 0 = エラーなし。 1 = 1~2ビットのエラーを検出し、訂正しました。 2 = 3~5ビットのエラーを検出し、訂正しました。 3 = 訂正不能。 |
| 12 | 5:4 | BLEB[1:0] | RDSブロックBの訂正済みエラー。 0 = エラーなし。 1 = 1~2ビットのエラーを検出し、訂正しました。 2 = 3~5ビットのエラーを検出し、訂正しました。 3 = 訂正不能。 |
| 12 | 3:2 | BLEC[1:0] | RDSブロックCの訂正済みエラー。 0 = エラーなし。 1 = 1~2ビットのエラーを検出し、訂正しました。 2 = 3~5ビットのエラーを検出し、訂正しました。 3 = 訂正不能。 |
| 12 | 1:0 | BLED[1:0] | RDSブロックDの訂正済みエラー。 0 = エラーなし。 1 = 1~2ビットのエラーを検出し、訂正しました。 2 = 3~5ビットのエラーを検出し、訂正しました。 3 = 訂正不能です。 |
3.2 パラメータ
応答の先頭パラメータ
応答(STATUSバイト)に含まれる各ビット(CTS, ERR, RSQINT, RDSINT, STCINT)は、「デバイスの現在の処理状態」や「各種割り込み(通知)の発生」をホストMCUに知らせる目的で設計されています。
STATUSバイトの信頼性:Si4735の仕様上、いくつかのコマンド送信時に返ってくるSTATUSバイトでは、CTS以外の割り込みビット(RSQINT, RDSINT, STCINTなど)がリアルタイムに更新されない場合があります。
正しい確認方法:正確な割り込みステータスを確認したい場合は、STATUSバイトを直接過信するのではなく、専用の割り込み確認コマンド(例:GET_INT_STATUS (0x14) コマンドなど)を明示的に発行して最新の状態を読み出すのが一般的なセオリーとなっています。
その他解説
正しい確認方法:正確な割り込みステータスを確認したい場合は、STATUSバイトを直接過信するのではなく、専用の割り込み確認コマンド(例:GET_INT_STATUS (0x14) コマンドなど)を明示的に発行して最新の状態を読み出すのが一般的なセオリーとなっています。
RESP12:BLEx ブロック・ブロックエラー補正・検出インジケータ(BLE)
各ブロックデータの「受信品質・信頼度」を表す2ビットのエラーカウントです。
各ブロックデータの「受信品質・信頼度」を表す2ビットのエラーカウントです。
$00$ (0): エラーなし。データは100%信頼できます。
$01$ (1): 1〜2ビットのエラーがあり、IC内部のECC(誤り訂正)によって完全に修正された。データは使用可能です。
$10$ (2): 3〜5ビットのエラーがあり、修正された可能性があるが信頼性は低い。実装によっては破棄を推奨します。
$11$ (3): 修正不可能な致命的エラー。データは壊れているため、必ず破棄する必要があります。
$01$ (1): 1〜2ビットのエラーがあり、IC内部のECC(誤り訂正)によって完全に修正された。データは使用可能です。
$10$ (2): 3〜5ビットのエラーがあり、修正された可能性があるが信頼性は低い。実装によっては破棄を推奨します。
$11$ (3): 修正不可能な致命的エラー。データは壊れているため、必ず破棄する必要があります。
3.2.1 CTS(Clear to Send)
目的:
デバイスが次のコマンドを受け付けられる状態かどうかを判定する。
解説:
最も重要なビットです。Si4735が前のコマンドの処理を完了し、「次のコマンドを送信しても安全(送信可)」になると1にセットされます。
0の間はデバイスが内部処理中(ビジー)であるため、ホストMCUは次のコマンド送信を待機する必要があります。
0の間はデバイスが内部処理中(ビジー)であるため、ホストMCUは次のコマンド送信を待機する必要があります。
3.2.2 ERR(Error)
目的:
直前に送信したコマンドが正常に実行されたか、エラーが発生したかを判別する。
解説:
コマンドの引数(引数の値が範囲外など)や、無効なコマンドが送られた場合に1にセットされます。
ホスト側のプログラムで例外処理や再試行(リトライ)を行うために使用します。
ホスト側のプログラムで例外処理や再試行(リトライ)を行うために使用します。
3.2.3 RSQINT(Received Signal Quality Interrupt)
目的:
受信信号の品質(電界強度RSSIやSNRなど)が、あらかじめ設定した閾値を超えた(または下回った)ことを通知する。
解説:
「受信品質の変化」をトリガーに処理を行いたい場合に使用します。
例えば、現在のチャンネルの電波が急激に弱くなったことを検知して自動で再スキャンをかける、といった機能を実装する目的で利用されます。
例えば、現在のチャンネルの電波が急激に弱くなったことを検知して自動で再スキャンをかける、といった機能を実装する目的で利用されます。
3.2.4 RDSINT(Radio Data System Interrupt)
目的:
RDS(文字情報などのデータ放送)のデータバッファ(FIFO)に新しいデータが格納されたことを通知する。
解説:
FM放送などで送られてくる「RDS/RBDSデータ(番組名や楽曲情報など)」を受信した際に1になります。
ホストMCUはこのビットを見てからデータを読み出す(FM_RDS_STATUS コマンドを発行する)ことで、無駄な空読みを防ぎ効率的にテキストデータを取得できます。
ホストMCUはこのビットを見てからデータを読み出す(FM_RDS_STATUS コマンドを発行する)ことで、無駄な空読みを防ぎ効率的にテキストデータを取得できます。
3.2.5 STCINT(Seek/Tune Complete Interrupt)
目的:
選局(Tune)操作または自動選局(Seek)操作が完了したことを通知する。
解説:
周波数を変更するコマンド(FM_TUNE_FREQ や FM_SEEK_START など)は内部処理に時間がかかります。
デバイスが「目的の周波数への同調、または次の放送局の検知を完了した」時点でこのビットが1になります。
選局完了のタイミングを正確に把握する目的で使用します。
デバイスが「目的の周波数への同調、または次の放送局の検知を完了した」時点でこのビットが1になります。
選局完了のタイミングを正確に把握する目的で使用します。
3.2.6 RDSNEWBLOCKB(RDS New Block B Interrupt)
目的:
ブロックBのデータが新しく更新されたことを通知する。
解説:
RDSのグループ識別や番組タイプ(PTY)が含まれる最重要ブロック「B」が新しく受信された際、割り込みを発生させるインジケータです。
3.2.7 RDSNEWBLOCKA(RDS New Block A Interrupt)
目的:
ブロックAのデータが新しく更新されたことを通知する。
解説:
主に基本識別子(PIコード:番組識別)が含まれるブロックAが受信されたことを通知します。
3.2.8 RDSSYNCFOUND(RDS Sync Found Interrupt)
目的:
RDSの同期に成功(ロック)した瞬間を通知する。
解説:
受信信号からRDSのデータストリーム(同期ワード)が正しく検出され、データ解析が可能になった瞬間に 1 になります。
3.2.9 RDSSYNCLOST(RDS Sync Lost Interrupt)
目的:
RDSの同期が外れてしまった(ロストした)ことを通知する。
解説:
電波の悪化などでRDSデータが途切れ、データのデコードができなくなった瞬間に 1 になります。
3.2.10 RDSRECV(RDS Received Interrupt)
目的:
RDSのバッファ(FIFO)に新しいデータが格納されたことを通知する。
解説:
FIFOに設定された一定量、あるいは最低1グループ分のデータが新しくバッファに届き、マイコンが読み出せる状態になったことを意味します。
3.2.11 GRPLOST(Group Lost)
目的:
内部バッファが溢れ(オーバーフロー)、RDSデータが消失したことを示す。
解説:
ホストマイコン側のデータ読み出し処理が追いつかず、内部のFIFOバッファが満杯の状態で新しいデータが届いたために、古い(あるいは新しい)データが上書き破棄された場合に 1 になります。
3.2.12 RDSSYNC(RDS Synchronized)
目的:
現在、RDSデータと正しく同期できているかのリアルタイム状態を示す。
解説:
1 であれば現在進行形でRDSデータが正常に同期・受信されています。0 の場合は同期が取れておらず、後述するBLOCKデータは信頼できません。
3.2.13 RDSFIFOUSED(RDS FIFO Used)
目的:
内部のRDS FIFOバッファに何個のブロック(またはグループ)が蓄積されているかの数を示す。
解説:
マイコンはこの数値を読み取ることで、バッファから何回データを連続して引き抜ける(STATUSONLY=0 で読み出せる)かを判断できます。
3.2.14 BLOCKA[15:8],BLOCKA[7:0](RDS Block A Data (High / Low Byte))
目的:
RDSグループの第1ブロック(16ビット)のデータ。
解説:
主にPIコード(Program Identification:番組識別コード)が格納されており、どの局を受信しているかを識別します。
3.2.15 BLOCKB[15:8],BLOCKB[7:0](RDS Block B Data (High / Low Byte))
目的:
RDSグループの第2ブロック(16ビット)のデータ。
解説:
グループタイプ(A/B構造など)、PTY(Program Type:ニュース、ロック等のジャンル)、トラフィック情報フラグなどが含まれる、データ解析の要となるブロックです。
3.2.16 BLOCKC[15:8],BLOCKC[7:0](RDS Block C Data (High / Low Byte))
目的:
RDSグループの第3ブロック(16ビット)のデータ。
解説:
グループタイプに応じて中身が変わります。AF(Alternative Frequencies:同一番組の代替周波数リスト) や、ラジオテキストの一部が格納されます。
3.2.17 BLOCKD[15:8],BLOCKD[7:0](RDS Block D Data (High / Low Byte))
目的:
RDSグループの第4ブロック(16ビット)のデータ。
解説:
主に PS(Program Service name:局名表示用文字(8文字まで)) や、ラジオテキストの残りのデータが格納されます。
3.2.18 BLEA[1:0](Block Error Rate Indicator - Block A)
目的:
ブロックAデータのエラー検出および修正状況を示す。
解説:
$00$ (0): エラーなし。データは100%信頼できます。
$01$ (1): 1〜2ビットのエラーがあり、IC内部のECC(誤り訂正)によって完全に修正された。データは使用可能です。
$10$ (2): 3〜5ビットのエラーがあり、修正された可能性があるが信頼性は低い。実装によっては破棄を推奨します。
$11$ (3): 修正不可能な致命的エラー。データは壊れているため、必ず破棄する必要があります。
$01$ (1): 1〜2ビットのエラーがあり、IC内部のECC(誤り訂正)によって完全に修正された。データは使用可能です。
$10$ (2): 3〜5ビットのエラーがあり、修正された可能性があるが信頼性は低い。実装によっては破棄を推奨します。
$11$ (3): 修正不可能な致命的エラー。データは壊れているため、必ず破棄する必要があります。
3.2.19 BLEB[1:0](Block Error Rate Indicator - Block B)
目的:
ブロックBデータのエラー検出および修正状況を示す。
解説:
$00$ (0): エラーなし。データは100%信頼できます。
$01$ (1): 1〜2ビットのエラーがあり、IC内部のECC(誤り訂正)によって完全に修正された。データは使用可能です。
$10$ (2): 3〜5ビットのエラーがあり、修正された可能性があるが信頼性は低い。実装によっては破棄を推奨します。
$11$ (3): 修正不可能な致命的エラー。データは壊れているため、必ず破棄する必要があります。
$01$ (1): 1〜2ビットのエラーがあり、IC内部のECC(誤り訂正)によって完全に修正された。データは使用可能です。
$10$ (2): 3〜5ビットのエラーがあり、修正された可能性があるが信頼性は低い。実装によっては破棄を推奨します。
$11$ (3): 修正不可能な致命的エラー。データは壊れているため、必ず破棄する必要があります。
3.2.20 BLEC[1:0](Block Error Rate Indicator - Block C)
目的:
ブロックCデータのエラー検出および修正状況を示す。
解説:
$00$ (0): エラーなし。データは100%信頼できます。
$01$ (1): 1〜2ビットのエラーがあり、IC内部のECC(誤り訂正)によって完全に修正された。データは使用可能です。
$10$ (2): 3〜5ビットのエラーがあり、修正された可能性があるが信頼性は低い。実装によっては破棄を推奨します。
$11$ (3): 修正不可能な致命的エラー。データは壊れているため、必ず破棄する必要があります。
$01$ (1): 1〜2ビットのエラーがあり、IC内部のECC(誤り訂正)によって完全に修正された。データは使用可能です。
$10$ (2): 3〜5ビットのエラーがあり、修正された可能性があるが信頼性は低い。実装によっては破棄を推奨します。
$11$ (3): 修正不可能な致命的エラー。データは壊れているため、必ず破棄する必要があります。
3.2.21 BLED[1:0](Block Error Rate Indicator - Block D)
目的:
ブロックDデータのエラー検出および修正状況を示す。
解説:
$00$ (0): エラーなし。データは100%信頼できます。
$01$ (1): 1〜2ビットのエラーがあり、IC内部のECC(誤り訂正)によって完全に修正された。データは使用可能です。
$10$ (2): 3〜5ビットのエラーがあり、修正された可能性があるが信頼性は低い。実装によっては破棄を推奨します。
$11$ (3): 修正不可能な致命的エラー。データは壊れているため、必ず破棄する必要があります。
$01$ (1): 1〜2ビットのエラーがあり、IC内部のECC(誤り訂正)によって完全に修正された。データは使用可能です。
$10$ (2): 3〜5ビットのエラーがあり、修正された可能性があるが信頼性は低い。実装によっては破棄を推奨します。
$11$ (3): 修正不可能な致命的エラー。データは壊れているため、必ず破棄する必要があります。
4 その他
4.1 Google AI (Gemini) の見解
0x24(FM_RDS_STATUS)コマンドは、FMデータ放送(RDS)の同期状態、データエラー(BLE)、および4つのデータブロック(A〜D)を包括的に管理・取得するためのコマンドです。
エラーカウント(BLE)の監視と、バッファの管理(MTFIFO / STATUSONLY)を適切に行うことで、文字化けのない安定したFMデータ受信機を実装することが可能になります。
エラーカウント(BLE)の監視と、バッファの管理(MTFIFO / STATUSONLY)を適切に行うことで、文字化けのない安定したFMデータ受信機を実装することが可能になります。
4.1.1 STATUSONLY を使った効率的なポーリング制御
マイコンの処理ループ内で、毎回データを消費しながら 0x24 を呼ぶと、パケットの同期が崩れた際に不正なデータをごちゃ混ぜに読み込んでしまう原因になります。
まず STATUSONLY = 1 で呼び出し、RDSSYNC = 1(同期中)かつ RDSFIFOUSED > 0(データあり)であることを確認してから、 STATUSONLY = 0 に切り替えて実際の BLOCK データを引き抜くアルゴリズムにすることで、無駄なデータ処理とデコードバグを劇的に減らすことができます。
まず STATUSONLY = 1 で呼び出し、RDSSYNC = 1(同期中)かつ RDSFIFOUSED > 0(データあり)であることを確認してから、 STATUSONLY = 0 に切り替えて実際の BLOCK データを引き抜くアルゴリズムにすることで、無駄なデータ処理とデコードバグを劇的に減らすことができます。
4.1.2 BLE(ブロックエラー)を無視したテキスト処理は厳禁
RDSで受信した局名(PS)やラジオテキスト(RT)を液晶ディスプレイ等に表示する際、BLEA 〜 BLED のチェックを怠ると、画面に文字化け(ゴミ文字)が高頻度で混入します。
美しいUIを作るためには、該当ブロックの BLE の値が $00$ または $01$ のときのみデータを配列に格納し、$10$ や $11$ のときはそのブロックのデータを無視して「前回の正しいデータを維持する」というフィルタリングを必ず実装してください。
美しいUIを作るためには、該当ブロックの BLE の値が $00$ または $01$ のときのみデータを配列に格納し、$10$ や $11$ のときはそのブロックのデータを無視して「前回の正しいデータを維持する」というフィルタリングを必ず実装してください。
4.1.3 周波数切り替え時の MTFIFO 必須処理
ユーザーが選局ボタンを押して周波数を変えた際、古い選局のRDSデータがSi4735の内部バッファに残っている場合があります。
これを行わないと、新しい周波数に変えた瞬間に「一瞬だけ前の局の局名が表示され、すぐに新しい局名に書き換わる」という不自然な挙動が起きます。
チューニングコマンド(0x20: FM_TUNE_FREQ)を発行した直後は、必ず MTFIFO = 1 を含めた 0x24 コマンドを一度実行し、バッファを完全に大掃除する設計にしてください。
これを行わないと、新しい周波数に変えた瞬間に「一瞬だけ前の局の局名が表示され、すぐに新しい局名に書き換わる」という不自然な挙動が起きます。
チューニングコマンド(0x20: FM_TUNE_FREQ)を発行した直後は、必ず MTFIFO = 1 を含めた 0x24 コマンドを一度実行し、バッファを完全に大掃除する設計にしてください。
4.1.4 日本国内での利用における注意点(補足)
Si4735が対応しているRDS規格は、欧米を中心とした国際規格です。
日本国内のFM放送で運用されている「文字多重放送(DARC等)」とは物理層・コーデックの仕様が異なるため、日本国内の一般的なFM放送局から局名やテキストデータを取得することは基本的にできません (※コミュニティFMの一部や実証実験、FM補完放送(ワイドFM)の一部でRDSが稀に重畳されているケースを除く)。
実験を行う際は、海外の放送環境か、自作のFMトランスミッター等からRDS信号をインジェクションしてテストすることをおすすめします。
日本国内のFM放送で運用されている「文字多重放送(DARC等)」とは物理層・コーデックの仕様が異なるため、日本国内の一般的なFM放送局から局名やテキストデータを取得することは基本的にできません (※コミュニティFMの一部や実証実験、FM補完放送(ワイドFM)の一部でRDSが稀に重畳されているケースを除く)。
実験を行う際は、海外の放送環境か、自作のFMトランスミッター等からRDS信号をインジェクションしてテストすることをおすすめします。
