Quectel RM520F-GL 接続情報取得ATコマンド評価メモ
評価対象
| 項目 | 値 |
|---|---|
| メーカー | Quectel |
| モジュール | RM520F-GL |
| Revision | RM520FGLBAR03A01M4G |
| QGMR | RM520FGLBAR03A01M4G_01.200.01.200 |
| IMEI | <REDACTED> |
| SIM状態 | READY |
| CFUN | 1 |
| 評価SIM | povo.jp |
| 登録PLMN | 44051 |
| 表示キャリア | KDDI |
概要
Quectel RM520F-GLで、serving cell情報、CA情報、接続中バンド、PDP/IP情報を取得するATコマンドを評価した。
今回の実機・ファームウェアでは、LTE接続情報取得に必要な主要コマンドは概ね利用可能だった。
特に以下のコマンドが有用。
| 用途 | 推奨コマンド |
|---|---|
| モジュール/FW確認 | ATI, AT+CGMR, AT+QGMR |
| キャリア/PLMN確認 | AT+COPS?, AT+QSPN |
| LTE登録状態確認 | AT+CEREG? |
| 5G登録状態確認 | AT+C5GREG? |
| 現在RAT/バンド確認 | AT+QNWINFO |
| Serving cell詳細 | AT+QENG="servingcell" |
| Neighbor cell | AT+QENG="neighbourcell" |
| CA構成 | AT+QCAINFO |
| 電波品質 | AT+QCSQ, AT+QRSRP, AT+QSINR |
| PDP/IP確認 | AT+CGATT?, AT+CGDCONT?, AT+CGACT?, AT+CGPADDR, AT+CGCONTRDP |
| エラー/拒否理由 | AT+CEER, AT+QNETRC |
実機情報確認
ATI
実行結果:
ATI Quectel RM520F-GL Revision: RM520FGLBAR03A01M4G OK
AT+CGMI
AT+CGMI Quectel OK
AT+CGMM
AT+CGMM RM520F-GL OK
AT+CGMR
AT+CGMR RM520FGLBAR03A01M4G OK
AT+QGMR
AT+QGMR RM520FGLBAR03A01M4G_01.200.01.200 OK
AT+GSN
AT+GSN <IMEI_REDACTED> OK
AT+CPIN?
AT+CPIN? +CPIN: READY OK
AT+CFUN?
AT+CFUN? +CFUN: 1 OK
キャリア / PLMN確認
数値PLMN表示に変更
AT+COPS=3,2 OK
AT+COPS?
AT+COPS? +COPS: 0,2,"44051",7 OK
読み取り:
| 項目 | 値 |
|---|---|
| モード | 0 |
| 表示形式 | 2 |
| PLMN | 44051 |
| AcT | 7 |
44051 は KDDI / au 系のPLMN。
AcT 7 は LTE / E-UTRAN 接続を示す。
AT+QSPN
AT+QSPN +QSPN: "KDDI","KDDI","KDDI",0,"44051" OK
読み取り:
| 項目 | 値 |
|---|---|
| SPN | KDDI |
| 表示名 | KDDI |
| PLMN | 44051 |
登録状態確認
AT+CREG?
AT+CREG? +CREG: 0,3 OK
CS登録は拒否または未使用相当。
データ通信評価では CEREG を主に見る。
AT+CGREG?
AT+CGREG? +CGREG: 0,0 OK
GPRS系の登録状態は未登録表示。
LTE接続評価では CEREG を主に見る。
AT+CEREG?
初期状態:
AT+CEREG? +CEREG: 0,1 OK
詳細表示有効化:
AT+CEREG=2 OK
詳細表示後:
AT+CEREG? +CEREG: 2,1,"<TAC_REDACTED>","<CELL_ID_REDACTED>",7 OK
読み取り:
| 項目 | 値 |
|---|---|
| n | 2 |
| stat | 1 |
| TAC | <REDACTED> |
| Cell ID | <REDACTED> |
| AcT | 7 |
stat=1 は登録済み。
AcT=7 は LTE / E-UTRAN。
AT+C5GREG?
初期状態:
AT+C5GREG? +C5GREG: 0,0 OK
詳細表示有効化:
AT+C5GREG=2 OK
詳細表示後:
AT+C5GREG? +C5GREG: 2,0 OK
読み取り:
| 項目 | 値 |
|---|---|
| n | 2 |
| stat | 0 |
5GSには未登録。
今回の評価時点では5G SA接続ではない。
現在RAT / バンド確認
AT+QNWINFO
AT+QNWINFO +QNWINFO: "FDD LTE","44051","LTE BAND 1",100 OK
読み取り:
| 項目 | 値 |
|---|---|
| RAT | FDD LTE |
| PLMN | 44051 |
| Band | LTE Band 1 |
| EARFCN | 100 |
現在は LTE Band 1 に接続している。
5G NSA/SA情報は出ていないため、この時点ではNR接続は成立していない。
Serving cell情報
AT+QENG="servingcell"
AT+QENG="servingcell" +QENG: "servingcell","NOCONN","LTE","FDD",440,51,<CELL_ID_REDACTED>,<PCI_REDACTED>,100,1,5,5,<TAC_REDACTED>,-91,-8,-61,18,12,-,- OK
読み取り:
| 項目 | 値 |
|---|---|
| 状態 | NOCONN |
| RAT | LTE |
| Duplex | FDD |
| MCC | 440 |
| MNC | 51 |
| Cell ID | <REDACTED> |
| PCI | <REDACTED> |
| EARFCN | 100 |
| Band | LTE Band 1 |
| UL bandwidth | 5 |
| DL bandwidth | 5 |
| TAC | <REDACTED> |
| RSRP | -91 dBm |
| RSRQ | -8 dB |
| RSSI | -61 dBm |
| SINR | 18 dB |
| CQI | 12 |
NOCONNについて
NOCONN はネットワーク未登録という意味ではなく、RRC Connectedではない待機状態を示すものと考えられる。
データ通信中に再取得すると CONNECT 側に変化する可能性がある。
登録状態そのものは AT+CEREG? で確認する。
今回の結果では以下の通りLTE登録済み。
+CEREG: 2,1,"<TAC_REDACTED>","<CELL_ID_REDACTED>",7
Neighbor cell情報
AT+QENG="neighbourcell"
AT+QENG="neighbourcell" +QENG: "neighbourcell intra","LTE",100,<PCI_REDACTED>,-8,-91,-61,-,-,-,-,-,- +QENG: "neighbourcell intra","LTE",100,<PCI_REDACTED>,-20,-109,-76,-,-,-,-,-,- +QENG: "neighbourcell inter","LTE",1300,<PCI_REDACTED>,-8,-90,-73,-,-,-,-,- OK
読み取り:
| 種別 | RAT | EARFCN | PCI | RSRQ | RSRP | RSSI |
|---|---|---|---|---|---|---|
| intra | LTE | 100 | <REDACTED> |
-8 | -91 | -61 |
| intra | LTE | 100 | <REDACTED> |
-20 | -109 | -76 |
| inter | LTE | 1300 | <REDACTED> |
-8 | -90 | -73 |
EARFCN 1300 は後述の QCAINFO に出ているSCCと一致している。
CA情報
AT+QCAINFO
AT+QCAINFO +QCAINFO: "PCC",100,100,"LTE BAND 1",1,<PCI_REDACTED>,-91,-8,-63,16 +QCAINFO: "SCC",1300,100,"LTE BAND 3",1,<PCI_REDACTED>,-90,-8,-73,0,0,-,- OK
読み取り:
| 種別 | EARFCN | Band | PCI | RSRP | RSRQ | RSSI | SINR |
|---|---|---|---|---|---|---|---|
| PCC | 100 | LTE Band 1 | <REDACTED> |
-91 | -8 | -63 | 16 |
| SCC | 1300 | LTE Band 3 | <REDACTED> |
-90 | -8 | -73 | 0 / 不明 |
今回の接続は LTE Band 1 + LTE Band 3 のCA構成。
| 項目 | 値 |
|---|---|
| PCC | LTE Band 1 / EARFCN 100 |
| SCC | LTE Band 3 / EARFCN 1300 |
| CA | 有効 |
| NR carrier | なし |
電波品質取得
AT+CSQ
AT+CSQ +CSQ: 24,99 OK
CSQ はRSSI中心の古典的な指標。
LTE/5G評価では補助扱い。
AT+CESQ
AT+CESQ ERROR
今回のRM520F-GL実機では AT+CESQ は利用不可。
実装では使わない方針でよい。
AT+QCSQ=?
AT+QCSQ=? +QCSQ: "NOSERVICE","WCDMA","LTE","NR5G" OK
LTE/NR5Gの種別には対応している。
AT+QCSQ
AT+QCSQ +QCSQ: "LTE",-64,-92,16,-10 OK
LTE時の読み取り:
| 項目 | 値 |
|---|---|
| RAT | LTE |
| RSSI | -64 dBm |
| RSRP | -92 dBm |
| SINR | 16 dB |
| RSRQ | -10 dB |
QENG="servingcell" や QCAINFO と概ね整合する。
AT+QRSRP
AT+QRSRP +QRSRP: -91,-140,-140,-140,LTE OK
読み取り:
| 項目 | 値 |
|---|---|
| RSRP #1 | -91 dBm |
| RSRP #2 | -140 dBm |
| RSRP #3 | -140 dBm |
| RSRP #4 | -140 dBm |
| RAT | LTE |
第1値のみ有効値に見える。
-140 は未使用または無効値として扱う。
AT+QSINR
AT+QSINR +QSINR: 17,-32768,-32768,-32768,LTE OK
読み取り:
| 項目 | 値 |
|---|---|
| SINR #1 | 17 dB |
| SINR #2 | -32768 |
| SINR #3 | -32768 |
| SINR #4 | -32768 |
| RAT | LTE |
第1値のみ有効値に見える。
-32768 は未使用または無効値として扱う。
PDP / IP接続状態
AT+CGATT?
AT+CGATT? +CGATT: 1 OK
PS attach済み。
AT+CGDCONT?
AT+CGDCONT? +CGDCONT: 1,"IPV4V6","povo.jp","<IPV6_ZERO_ADDRESS>",0,0,0,0,,,,,,,,,"",,,,0 +CGDCONT: 2,"IPV4V6","","<IPV6_ZERO_ADDRESS>",0,0,0,0,,,,,,,,,"",,,,0 +CGDCONT: 3,"IPV4V6","IMS","<IPV6_ZERO_ADDRESS>",0,0,0,0,,,,,,,,,"",,,,0 +CGDCONT: 4,"IPV4V6","sos","<IPV6_ZERO_ADDRESS>",0,0,0,1,,,,,,,,,"",,,,0 +CGDCONT: 5,"IPV4V6","xcap","<IPV6_ZERO_ADDRESS>",0,0,0,0,,,,,,,,,"",,,,0 +CGDCONT: 6,"IPV4V6","povo.jp","<IPV6_ZERO_ADDRESS>",0,0,0,0,,,,,,,,,"",,,,0 OK
CID 1 と CID 6 に povo.jp が設定されている。
CID 3 は IMS。
AT+CGACT?
AT+CGACT? +CGACT: 1,1 +CGACT: 2,0 +CGACT: 3,1 +CGACT: 4,0 +CGACT: 5,0 +CGACT: 6,0 OK
読み取り:
| CID | Active | APN |
|---|---|---|
| 1 | 1 | povo.jp |
| 2 | 0 | 空 |
| 3 | 1 | IMS |
| 4 | 0 | sos |
| 5 | 0 | xcap |
| 6 | 0 | povo.jp |
CID 1 の povo.jp と CID 3 の IMS がactive。
AT+CGPADDR
AT+CGPADDR +CGPADDR: 1,"<IPv4_REDACTED>","<IPv6_REDACTED>" +CGPADDR: 2,"0.0.0.0","<IPV6_ZERO_ADDRESS>" +CGPADDR: 3,"<IMS_IPv6_REDACTED>" +CGPADDR: 4,"0.0.0.0","<IPV6_ZERO_ADDRESS>" +CGPADDR: 5,"0.0.0.0","<IPV6_ZERO_ADDRESS>" +CGPADDR: 6,"0.0.0.0","<IPV6_ZERO_ADDRESS>" OK
CID 1 のメインデータ通信用アドレス:
| 項目 | 値 |
|---|---|
| IPv4 | <REDACTED> |
| IPv6 | <REDACTED> |
IPv6はAT応答上ではドット区切り10進表記で返る。
公開用資料では、実際のIPv4/IPv6アドレスは伏せる。
AT+CGCONTRDP
AT+CGCONTRDP +CGCONTRDP: 1,5,"povo.jp","<IPv4_REDACTED>","<IPv6_REDACTED>", "<GATEWAY_OR_PREFIX_REDACTED>","<DNS1_IPv4_REDACTED>" "<DNS1_IPv6_REDACTED>","<DNS2_IPv4_REDACTED>" "<DNS2_IPv6_REDACTED>" +CGCONTRDP: 3,6,"IMS","<IMS_IPv6_REDACTED>", "<IMS_GATEWAY_OR_PREFIX_REDACTED>",,,"<IMS_DNS1_IPv6_REDACTED>","<IMS_DNS2_IPv6_REDACTED>" OK
CID 1 の読み取り:
| 項目 | 値 |
|---|---|
| CID | 1 |
| Bearer ID | 5 |
| APN | povo.jp |
| IPv4 | <REDACTED> |
| IPv6 | <REDACTED> |
| Gateway / prefix系 | <REDACTED> |
| DNS1 IPv4 | <REDACTED> |
| DNS2 IPv4 | <REDACTED> |
| DNS1 IPv6 | <REDACTED> |
| DNS2 IPv6 | <REDACTED> |
公開用資料では、IPアドレス、IPv6 prefix、DNSアドレスは伏せる。
エラー / ネットワーク拒否理由
AT+CEER
AT+CEER +CEER: Requested service option not subscribed OK
直近の失敗理由として Requested service option not subscribed が残っている。
ただし、現状では以下の状態。
AT+CEREG?は登録済みAT+CGATT?は attach済みAT+CGPADDRでIP取得済みAT+QNETRCは 0
そのため、現在のメインデータ通信異常とは限らない。
IMS、sos、xcap、または未契約サービスへの試行履歴が残っている可能性がある。
AT+QNETRC
AT+QNETRC +QNETRC: 0 OK
ネットワーク拒否状態ではない。
コマンド対応状況まとめ
| コマンド | 対応 | 実機結果 | 備考 |
|---|---|---|---|
ATI |
OK | RM520F-GL / RM520FGLBAR03A01M4G | 基本情報取得 |
AT+CGMI |
OK | Quectel | メーカー取得 |
AT+CGMM |
OK | RM520F-GL | 型番取得 |
AT+CGMR |
OK | RM520FGLBAR03A01M4G | FW revision取得 |
AT+QGMR |
OK | RM520FGLBAR03A01M4G_01.200.01.200 | 詳細FW取得 |
AT+GSN |
OK | IMEI取得可 | 公開時は伏せる |
AT+CPIN? |
OK | READY | SIM状態確認 |
AT+CFUN? |
OK | 1 | RF機能状態確認 |
AT+COPS=3,2 |
OK | 数値PLMN表示に変更 | 評価前に設定推奨 |
AT+COPS? |
OK | 44051 / AcT 7 | LTE登録 |
AT+QSPN |
OK | KDDI / 44051 | SPN/RPLMN取得 |
AT+CREG? |
OK | 0,3 | CS登録は拒否/未使用相当 |
AT+CGREG? |
OK | 0,0 | GPRS系は未登録表示 |
AT+CEREG? |
OK | LTE/EPS登録、TAC/CI取得可 | TAC/Cell IDは公開時に伏せる |
AT+C5GREG? |
OK | 5GS未登録 | |
AT+QNWINFO |
OK | FDD LTE / 44051 / LTE BAND 1 / 100 | 現在RAT/バンド取得 |
AT+QENG="servingcell" |
OK | LTE serving cell詳細取得可 | Cell ID/TAC/PCIは公開時に伏せる |
AT+QENG="neighbourcell" |
OK | LTE intra/inter neighbor取得可 | PCIは公開時に伏せる |
AT+QCAINFO |
OK | PCC B1 + SCC B3 | PCIは公開時に伏せる |
AT+CSQ |
OK | 24,99 | 補助 |
AT+CESQ |
ERROR | - | このFWでは利用不可 |
AT+QCSQ=? |
OK | NOSERVICE/WCDMA/LTE/NR5G | |
AT+QCSQ |
OK | LTE RSSI/RSRP/SINR/RSRQ取得可 | 簡易品質表示に有用 |
AT+QRSRP |
OK | RSRP取得可 | |
AT+QSINR |
OK | SINR取得可 | |
AT+CGATT? |
OK | 1 | PS attach済み |
AT+CGDCONT? |
OK | CID 1 povo.jp / CID 3 IMS 等 | PDP定義取得 |
AT+CGACT? |
OK | CID 1,3 active | PDP active状態取得 |
AT+CGPADDR |
OK | IPv4/IPv6取得可 | IPアドレスは公開時に伏せる |
AT+CGCONTRDP |
OK | APN/IP/DNS取得可 | IP/DNSは公開時に伏せる |
AT+CEER |
OK | Requested service option not subscribed | 直近履歴の可能性 |
AT+QNETRC |
OK | 0 | 拒否なし |
実装方針
RM520F-GLのステータス表示・監視実装では、以下を主軸にする。
AT+COPS=3,2 AT+COPS? AT+QSPN AT+CEREG=2 AT+CEREG? AT+C5GREG=2 AT+C5GREG? AT+QNWINFO AT+QENG="servingcell" AT+QENG="neighbourcell" AT+QCAINFO AT+QCSQ AT+CGATT? AT+CGACT? AT+CGPADDR AT+CGCONTRDP AT+CEER AT+QNETRC
表示項目と取得元
| 表示項目 | 取得元 |
|---|---|
| モジュール型番 | ATI, AT+CGMM |
| FW | AT+QGMR, AT+CGMR |
| SIM状態 | AT+CPIN? |
| キャリア名 | AT+QSPN |
| PLMN | AT+COPS?, AT+QSPN, AT+QENG="servingcell" |
| 登録状態 | AT+CEREG?, AT+C5GREG? |
| RAT | AT+QNWINFO, AT+QENG="servingcell", AT+QCSQ |
| LTE/NRバンド | AT+QNWINFO, AT+QENG="servingcell", AT+QCAINFO |
| Cell ID | AT+CEREG?, AT+QENG="servingcell" |
| TAC | AT+CEREG?, AT+QENG="servingcell" |
| PCI | AT+QENG="servingcell", AT+QCAINFO |
| EARFCN | AT+QNWINFO, AT+QENG="servingcell", AT+QCAINFO |
| CA構成 | AT+QCAINFO |
| RSRP | AT+QENG="servingcell", AT+QCSQ, AT+QRSRP |
| RSRQ | AT+QENG="servingcell", AT+QCSQ |
| RSSI | AT+QENG="servingcell", AT+QCSQ |
| SINR | AT+QENG="servingcell", AT+QCSQ, AT+QSINR |
| CQI | AT+QENG="servingcell" |
| IPv4/IPv6 | AT+CGPADDR, AT+CGCONTRDP |
| DNS | AT+CGCONTRDP |
| Network reject | AT+QNETRC |
| 直近エラー | AT+CEER |
公開時に伏せるべき情報
公開用ログでは、以下の情報は伏せる。
| 種別 | 例 | 理由 |
|---|---|---|
| IMEI | AT+GSN の応答 |
端末固有番号 |
| Cell ID | CEREG, QENG のCell ID |
接続位置推定につながる |
| TAC | CEREG, QENG のTAC |
エリア推定につながる |
| PCI | QENG, QCAINFO, neighbourcell のPCI |
セル推定につながる場合がある |
| IPv4 | CGPADDR, CGCONTRDP |
セッション/接続情報 |
| IPv6 | CGPADDR, CGCONTRDP |
prefixから接続情報が分かる場合がある |
| DNS | CGCONTRDP |
通信事業者情報としては公開情報に近いが、ログ公開時は伏せるのが無難 |
| IMS用アドレス | CGPADDR, CGCONTRDP のIMS CID |
端末・網側制御情報に近いため伏せる |
一方で、以下は公開しても比較的問題が少ない。
| 種別 | 例 |
|---|---|
| モジュール型番 | RM520F-GL |
| FW revision | RM520FGLBAR03A01M4G_01.200.01.200 |
| キャリア名 | KDDI |
| PLMN | 44051 |
| APN名 | povo.jp |
| RAT | LTE / NR5G |
| Band | LTE Band 1 / LTE Band 3 |
| EARFCN / NR-ARFCN | 100 / 1300 など |
| RSRP/RSRQ/RSSI/SINR | 電波品質値 |
| CA構成 | PCC/SCC, Band構成 |
注意点
CREG / CGREGよりCEREGを見る
LTE/5Gデータ通信の評価では、AT+CREG? や AT+CGREG? より AT+CEREG? を主に見る。
今回も以下のように、CREG / CGREG だけを見ると未登録や拒否に見える。
+CREG: 0,3 +CGREG: 0,0
一方で CEREG は登録済み。
+CEREG: 2,1,"<TAC_REDACTED>","<CELL_ID_REDACTED>",7
NOCONNは圏外ではない
AT+QENG="servingcell" の NOCONN は圏外や未登録という意味ではなく、RRC Connectedではない待機状態と考える。
登録状態は AT+CEREG? で判断する。
CESQは使わない
今回のRM520F-GLでは AT+CESQ は ERROR。
電波品質は以下から取得する。
AT+QENG="servingcell"AT+QCSQAT+QRSRPAT+QSINR
QENGを主、QCSQを簡易表示に使う
AT+QENG="servingcell" は情報量が多く、Cell ID、PCI、EARFCN、Band、TAC、RSRP、RSRQ、RSSI、SINR、CQIをまとめて取得できる。
AT+QCSQ は簡易表示には使いやすいが、cell情報は取れない。
QCAINFOでCA構成を見る
AT+QNWINFO だけでは現在の主バンドしか見えない。
CA構成を見る場合は AT+QCAINFO が必要。
今回の評価では、QNWINFO は Band 1 のみを表示したが、QCAINFO により Band 1 + Band 3 のCAであることが確認できた。
CEERは現在状態とは限らない
AT+CEER は直近の失敗理由を返すため、現在のメイン通信状態と一致しない場合がある。
今回も Requested service option not subscribed が返っているが、データ通信自体は登録済み・attach済み・IP取得済みだった。
現在の拒否状態は AT+QNETRC を併用して判断する。
今回の評価結果まとめ
今回のRM520F-GL実機では、povo / KDDI網において以下の状態だった。
| 項目 | 結果 |
|---|---|
| 登録状態 | LTE/EPS登録済み |
| 5G SA | 未登録 |
| RAT | FDD LTE |
| PLMN | 44051 |
| キャリア | KDDI |
| Serving band | LTE Band 1 |
| PCC | LTE Band 1 / EARFCN 100 |
| SCC | LTE Band 3 / EARFCN 1300 |
| CA | 有効 |
| RSRP | 約 -91 dBm |
| RSRQ | 約 -8 dB |
| RSSI | 約 -61〜-64 dBm |
| SINR | 約 16〜18 dB |
| IPv4 | <REDACTED> |
| IPv6 | <REDACTED> |
| DNS | 取得済み |
| Network reject | なし |
LTE接続情報取得用途では、QENG="servingcell"、QCAINFO、QNWINFO、CEREG?、QCSQ、CGPADDR、CGCONTRDP を使えば、実用上必要な情報はほぼ取得できる。
Quectel RM520F-GL + 5G HEE の RC / MBIM / ECM / RNDIS 切り替えメモ
概要
Quectel RM520F-GL を 5G HEE(USB + RTL8125 変換基板)で使用する場合、主に次の接続モードを切り替えて利用できる。
- RC mode / RJ-45 / RTL8125
- USB MBIM
- USB ECM
- USB RNDIS
- USB QMI/RMNET
本環境では、初期状態は RC mode / RJ-45接続 だった。
USB MBIM への切り替えを実施し、Windows 11 で接続できることを確認済み。
NCM については AT+QCFG="usbnet",5 が ERROR となったため、本個体/ファームでは非対応と判断する。
現在値確認
AT+QCFG="usbnet" AT+QCFG="data_interface" AT+QCFG="pcie/mode" AT+QCFG="usbspeed"
確認例:
AT+QCFG="usbnet" +QCFG: "usbnet",0 OK AT+QCFG="data_interface" +QCFG: "data_interface",1,0 OK AT+QCFG="pcie/mode" +QCFG: "pcie/mode",1 OK AT+QCFG="usbspeed" +QCFG: "usbspeed","312" OK
この状態は以下を意味する。
usbnet=0 USB側の保存値は QMI/RMNET 系 data_interface=1,0 データ経路は PCIe 側、AT/診断系は USB 側 pcie/mode=1 PCIe RC mode
つまり、実際のデータ通信は USB ではなく、PCIe RC mode 経由で RTL8125 / RJ-45 側に出ている状態。
usbnet の値
RM520系でよく使われる usbnet 値は以下。
| 値 | モード | 備考 |
|---|---|---|
0 |
QMI / RMNET | Linux / OpenWrt で QMI 管理する場合 |
1 |
ECM | USB Ethernet 風の接続 |
2 |
MBIM | Windows 10/11、Linux ModemManager 向け |
3 |
RNDIS | 非推奨。検証用途程度 |
5 |
NCM | 本環境では ERROR。非対応 |
本環境での確認結果:
AT+QCFG="usbnet",5 ERROR
したがって、本環境では NCM は使用不可。
data_interface の意味
AT+QCFG="data_interface",0,0
USB側にデータ経路を戻す。
AT+QCFG="data_interface",1,0
PCIe側にデータ経路を出す。 5G HEE の RC mode / RTL8125 / RJ-45 接続ではこちらを使う。
pcie/mode の意味
AT+QCFG="pcie/mode",0
PCIe EP mode。
AT+QCFG="pcie/mode",1
PCIe RC mode。 5G HEE の RJ-45 接続ではこちらを使う。
反映方法
USBモードの切り替えは AT+CFUN=1,1 で反映される場合もある。
AT+CFUN=1,1
ただし、RC mode / PCIe / RTL8125 を絡める場合は、ソフトリセットだけでは不安定になる可能性がある。 モード変更後は、モジュールまたは変換基板ごと電源断 → 再投入 が安全。
各モードへの切り替え
RC mode / RJ-45 / RTL8125 へ切り替え
5G HEE の RJ-45 ポートで通信するモード。
AT+QCFG="data_interface",1,0 AT+QCFG="pcie/mode",1 AT+QCFG="usbnet",0 AT+QETH="eth_driver","r8125" AT+QMAPWAC=1
その後、電源断 → 再投入。
確認:
AT+QCFG="data_interface" AT+QCFG="pcie/mode" AT+QCFG="usbnet"
期待値:
+QCFG: "data_interface",1,0 +QCFG: "pcie/mode",1 +QCFG: "usbnet",0
RJ-45 側の接続先では、通常の Ethernet 接続として見える。
USB MBIM へ切り替え
Windows 11 で確認済みのUSB接続モード。 USB接続で使う場合の本命。
AT+QCFG="data_interface",0,0 AT+QCFG="pcie/mode",0 AT+QCFG="usbnet",2
その後、電源断 → 再投入。
確認:
AT+QCFG="data_interface" AT+QCFG="pcie/mode" AT+QCFG="usbnet"
期待値:
+QCFG: "data_interface",0,0 +QCFG: "pcie/mode",0 +QCFG: "usbnet",2
Windows 11 では MBIM デバイスとして認識され、モバイルネットワークとして接続できる。
USB ECM へ切り替え
USB Ethernet 風に見せるモード。
AT+QCFG="data_interface",0,0 AT+QCFG="pcie/mode",0 AT+QCFG="usbnet",1
その後、電源断 → 再投入。
確認:
AT+QCFG="usbnet"
期待値:
+QCFG: "usbnet",1
Linux / OpenWrt では ECM 用ドライバが必要になる場合がある。
OpenWrt例:
opkg install kmod-usb-net-cdc-ether
USB RNDIS へ切り替え
RNDIS は利用可能な場合があるが、現在では非推奨。 常用せず、検証用途に留める。
AT+QCFG="data_interface",0,0 AT+QCFG="pcie/mode",0 AT+QCFG="usbnet",3
その後、電源断 → 再投入。
確認:
AT+QCFG="usbnet"
期待値:
+QCFG: "usbnet",3
注意点:
- Windows 11 では RNDIS は積極的に使わない方がよい
- USBインターフェース構成が変わり、ATポートの番号が変わる場合がある
- 既存のCOMポート番号、udev設定、OpenWrtのインターフェース名が変わる可能性がある
USB QMI / RMNET へ切り替え
Linux / OpenWrt で QMI 管理したい場合のモード。
AT+QCFG="data_interface",0,0 AT+QCFG="pcie/mode",0 AT+QCFG="usbnet",0
その後、電源断 → 再投入。
確認:
AT+QCFG="usbnet"
期待値:
+QCFG: "usbnet",0
OpenWrt例:
opkg install kmod-usb-net-qmi-wwan uqmi
相互移行パターン
RC mode から USB MBIM へ
AT+QCFG="data_interface",0,0 AT+QCFG="pcie/mode",0 AT+QCFG="usbnet",2
電源断 → 再投入。
RC mode から USB ECM へ
AT+QCFG="data_interface",0,0 AT+QCFG="pcie/mode",0 AT+QCFG="usbnet",1
電源断 → 再投入。
RC mode から USB RNDIS へ
AT+QCFG="data_interface",0,0 AT+QCFG="pcie/mode",0 AT+QCFG="usbnet",3
電源断 → 再投入。
USB MBIM から RC mode へ
AT+QCFG="data_interface",1,0 AT+QCFG="pcie/mode",1 AT+QCFG="usbnet",0 AT+QETH="eth_driver","r8125" AT+QMAPWAC=1
電源断 → 再投入。
USB ECM から RC mode へ
AT+QCFG="data_interface",1,0 AT+QCFG="pcie/mode",1 AT+QCFG="usbnet",0 AT+QETH="eth_driver","r8125" AT+QMAPWAC=1
電源断 → 再投入。
USB RNDIS から RC mode へ
AT+QCFG="data_interface",1,0 AT+QCFG="pcie/mode",1 AT+QCFG="usbnet",0 AT+QETH="eth_driver","r8125" AT+QMAPWAC=1
電源断 → 再投入。
推奨構成
RJ-45で使う場合
RC mode / RTL8125
5G HEE基板のRJ-45を使うならこの構成が本命。
利点:
- ホスト側からは普通のEthernetに見える
- USBモデムドライバに依存しにくい
- ルータやPCとの接続が単純
Windows 11でUSB接続する場合
MBIM
本環境でWindows 11接続確認済み。
AT+QCFG="data_interface",0,0 AT+QCFG="pcie/mode",0 AT+QCFG="usbnet",2
OpenWrt / LinuxでUSB接続する場合
優先順位は以下。
MBIM QMI/RMNET ECM RNDIS
RNDISは非推奨。
確認コマンドまとめ
モデム側
AT+QCFG="usbnet" AT+QCFG="data_interface" AT+QCFG="pcie/mode" AT+QCFG="usbspeed" AT+QETH="eth_driver"
Linux / OpenWrt側
dmesg | grep -iE 'qmi|mbim|cdc|ecm|rndis|ncm|usb' ip link lsusb lsusb -t
Windows側
- デバイスマネージャー
- ネットワークアダプター
- モバイルネットワーク
ncpa.cpl
注意点
NCMは本環境では非対応
AT+QCFG="usbnet",5 ERROR
そのため、NCMは選択肢から外す。
RNDISは非推奨
RNDISは古いUSB Ethernet互換モード。 Windows 11や今後の環境では積極的に使わない。
利用する場合も検証用途に留める。
RC mode絡みは電源断を推奨
AT+CFUN=1,1 で反映される場合もあるが、PCIe RC / RTL8125絡みでは不安定になることがある。
モード切り替え後は、以下を推奨する。
ATコマンド投入 ↓ OK確認 ↓ モジュールまたは変換基板ごと電源断 ↓ 再投入 ↓ AT+QCFG? で確認
ATポートが変わる可能性
USBモードを切り替えると、USBインターフェース構成が変わる。
その結果、ATポートのCOM番号や /dev/ttyUSBx が変わる場合がある。
切り替え後にATポートが見えなくなった場合は、以下を確認する。
dmesg | grep -i tty ls /dev/ttyUSB* ls /dev/ttyACM*
WindowsではデバイスマネージャーでCOMポートを確認する。
実績メモ
初期状態
AT+QCFG="usbnet" +QCFG: "usbnet",0 AT+QCFG="data_interface" +QCFG: "data_interface",1,0 AT+QCFG="pcie/mode" +QCFG: "pcie/mode",1
状態:
RC mode / RJ-45 / RTL8125
NCM確認
AT+QCFG="data_interface",0,0 OK AT+QCFG="usbnet",5 ERROR
結果:
NCM非対応
MBIM確認
AT+QCFG="data_interface",0,0 AT+QCFG="pcie/mode",0 AT+QCFG="usbnet",2
結果:
Windows 11で接続確認済み
SIM7670G 関連の調査メモ
概要
SIM7670G-MNGV を USB 接続で OpenWrt / Linux から利用するための接続設定・確認結果をまとめる。
本ナレッジでは、AT コマンドによる MQTT 等のモジュール内機能ではなく、USB ネットワークデバイスとしてホスト側 OS から通信する構成を対象とする。
主な確認対象は以下。
- USB 接続時のネットワーク IF
- RNDIS / ECM モード
- APN / PDP コンテキスト設定
- モデム内 NAT の有効 / 無効
- OpenWrt での DHCP 取得
- GNSS / NMEA 出力
- SIM / キャリアによる GNSS 挙動差
確認環境
モジュール
- SIMCOM SIM7670G-MNGV
- USB 接続
- USB ID:
05c6:9330
確認済みファームウェア
例:
AT+CGMR 2388B03SIM767XM5A_M ATI SIM767XM5_B03V01_250619
更新後の例:
AT+SIMCOMATI Manufacturer: SIMCOM INCORPORATED Model: SIM7670G-MNGV Revision: 2388B04SIM767XM5A_M SIM767XM5_B04V01_251105 IMEI: xxxxxxxxxxxxxxx
USB インターフェース構成
USB 接続時、ホスト側には以下のような IF が見える。
- RNDIS / ECM 用ネットワーク IF
複数の CDC ACM シリアルポート
- 例:
/dev/ttyACM0~/dev/ttyACM3
- 例:
GNSS の NMEA 出力は、手元環境では /dev/ttyACM3 で確認した。
AT コマンド用ポートは環境により変わる可能性があるため、実機では AT に OK が返るポートを確認する。
echo -e "AT\r" > /dev/ttyACM0
または atinout / microcom / minicom 等で確認する。
APN / PDP コンテキスト設定
APN を設定する。
例: povo
AT+CGDCONT=1,"IPV4V6","povo.jp" OK
例: mineo
AT+CGDCONT=1,"IP","mineo.jp" OK
PDP コンテキストを有効化する。
AT+CGACT=1,1 OK
IP アドレスを確認する。
AT+CGPADDR=1 +CGPADDR: 1,"xxx.xxx.xxx.xxx" OK
USB ネットワークモード
SIM7670G では、USB ネットワークモードを切り替えて利用できる。
RNDIS モード
AT$MYCONFIG="usbnetmode",0 OK
RNDIS モードでは、ホスト側に RNDIS ネットワーク IF として認識される。
OpenWrt 側では udhcpc により DHCP 取得する。
例:
udhcpc -i usb0
手元環境では、RNDIS モード時に 10.39.x.x/8 のようなアドレスが割り当てられた。
ECM モード
AT$MYCONFIG="usbnetmode",1 OK
ECM モードでは、ホスト側に USB Ethernet 系の IF として認識される。
OpenWrt / Linux からは、RNDIS より扱いやすい場合がある。
例:
udhcpc -i eth1
手元環境では、ECM モード時に 100.97.23.54/8 のようなアドレスが割り当てられた。
自動ダイヤル設定
USB ネットワーク IF で DHCP を有効にするため、以下を設定する。
AT+DIALMODE=0 OK
この設定により、ホスト側で USB ネットワーク IF に対して DHCP を実行する構成になる。
モデム内 NAT の有効 / 無効
SIM7670G では、USB ネットワーク側に対してモデム内 NAT を有効にするモードと、網側から取得した IP をホスト側へ割り当てるモードを切り替えられる。
デフォルト: モデム内 NAT 有効
AT+USBNETIP=0 OK
この状態では、モデム内 NAT が有効になる。
OpenWrt をルータとして使う場合、以下のように NAT が多段化しやすい。
携帯網側 CGNAT ↓ SIM7670G モデム内 NAT ↓ OpenWrt の NAT ↓ LAN クライアント
この場合、CGNAT + モデム NAT + OpenWrt NAT により 3 重 NAT になる可能性がある。
NAT スルー: 網側 IP をホストへ割り当て
AT+USBNETIP=1 OK
AT+USBNETIP=1 は、モデム内 NAT を無効にし、網側から取得した IP を USB ネットワーク IF 側へ割り当てるモードに変更する。
OpenWrt をルータとして使う場合は、余計な NAT を減らせるため、この構成が望ましい。
推奨構成:
携帯網側 CGNAT ↓ SIM7670G ↓ OpenWrt の WAN IF ↓ OpenWrt の NAT ↓ LAN クライアント
OpenWrt での接続例
ネットワーク IF 確認
ip link
または
dmesg | grep -iE 'rndis|cdc|ecm|usb|eth'
USB ネットワーク IF が usb0 や eth1 として見える。
DHCP 取得
udhcpc -i usb0
または
udhcpc -i eth1
取得後、IP を確認する。
ip addr show usb0 ip route
疎通確認。
ping -c 3 8.8.8.8 ping -c 3 example.com
DNS が未設定の場合、IP への ping は通るが名前解決に失敗する。
接続確認用 AT コマンド
基本情報
AT OK
ATI
AT+SIMCOMATI
AT+CGMR
SIM / 登録状態
AT+CPIN?
AT+CREG?
AT+CGREG?
AT+CEREG?
例:
AT+CEREG? +CEREG: 0,1 OK
0,1 はホーム網で登録済みを示す。
接続状態・電波状態
AT+CPSI?
例:
+CPSI: LTE,Online,440-51,<redacted>,<redacted>,<redacted>,EUTRAN-BAND41,41040,5,5,18,44,26,15
このコマンドで以下のような情報を取得できる。
- RAT
- Online / NO SERVICE
- PLMN
- Band
- EARFCN
- 帯域幅
- RSRP
- RSRQ
- RSSI
- SNR
SIM7670G の簡易ステータス取得には AT+CPSI? がかなり有用。
GNSS / NMEA
GNSS 有効化
AT+CGNSSPWR=1 OK
GNSS 情報確認
AT+CGNSSINFO
Fix できている場合、緯度経度等が返る。
NMEA 設定確認
AT+CGNSSNMEA?
NMEA 出力ポート
手元環境では、NMEA は以下で確認した。
/dev/ttyACM3
確認例:
cat /dev/ttyACM3
Fix できると、以下のような NMEA センテンスが流れる。
$GNRMC,... $GNGGA,... $GNGSA,... $GPGSV,...
GNSS アンテナ
確認した構成:
- LTE アンテナと GNSS アンテナは分離
- アクティブ GPS アンテナ使用
- GNSS_ANT 側に給電あり
- 窓外 50 cm 程度にアンテナを出して確認
- ケーブル長 約 3 m
1 台目のモジュールでは GNSS が捕捉できず、2 台目では同構成で NMEA 出力を確認できた。
そのため、GNSS が出ない場合は設定だけでなく、モジュール個体差・故障も疑う。
SIM / キャリアによる GNSS 挙動差
手元環境では、GNSS / NMEA 出力に SIM・網依存と思われる差があった。
確認結果
| SIM / 網 | GNSS / NMEA |
|---|---|
| povo2.0 / au | OK |
| mineo / au | OK |
| IIJmio A / au | OK |
| Docomo 公式データプラン SIM | OK |
| IIJmio D / Docomo MVNO | NG |
| SIM なし | NG |
補足
Docomo 公式データプラン SIM では、ネットワークへアタッチしていない状態でも GPS 出力できた。
一方、IIJmio D プランでは GNSS 出力ができなかった。
SIM ホットスワップや AT+CRESET では改善せず、SIM を入れ替えた場合はパワーサイクルが必要だった。
AGPS 関連
以下のコマンドは手元環境では使用できなかった。
AT+CGNSSAGPS=? ERROR
AT+CGNSSAGPS? ERROR
以下は応答あり。
AT+CGNSSCMD=? +CGNSSCMD: "CmdString" OK
このため、SIM7670G-MNGV の手元ファームウェアでは、一般的な AT+CGNSSAGPS による AGPS ON/OFF 制御は利用できない可能性がある。
接続時の推奨設定例
OpenWrt で SIM7670G を USB WAN として使う場合の基本方針。
推奨
AT+CGDCONT=1,"IPV4V6","<APN>" AT+DIALMODE=0 AT+USBNETIP=1 AT$MYCONFIG="usbnetmode",1
理由:
- ECM の方が Linux / OpenWrt では扱いやすい
AT+USBNETIP=1によりモデム内 NAT を無効化できる- OpenWrt 側で WAN として扱いやすい
- NAT 多段化を抑制できる
RNDIS を使う場合
AT$MYCONFIG="usbnetmode",0
Windows 互換性を重視する場合は RNDIS が扱いやすい場合がある。
ただし、OpenWrt / Linux では ECM の方が素直な構成になりやすい。
トラブルシュート
USB IF が見えない
dmesg
lsusb
ip link
ls /dev/ttyACM*
を確認する。
AT ポートが分からない
複数の /dev/ttyACM* に対して AT を送信し、OK が返るポートを探す。
DHCP で IP が取れない
以下を確認する。
AT+DIALMODE=0 AT+CGDCONT? AT+CGACT? AT+CGPADDR=1
ホスト側では以下を確認する。
ip link udhcpc -i <IF名> ip addr ip route
IP は取れるが外に出られない
以下を確認する。
ip route cat /etc/resolv.conf ping -c 3 8.8.8.8 ping -c 3 example.com
IP 宛 ping が通り、名前解決だけ失敗する場合は DNS 設定の問題。
GNSS が出ない
確認ポイント:
AT+CGNSSPWR=1を実行したか- NMEA 出力ポートが正しいか
/dev/ttyACM3以外も確認したか- アクティブ GPS アンテナに給電されているか
- 屋外または窓際で確認しているか
- SIM を変えた場合にパワーサイクルしたか
- IIJmio D など特定 SIM / 網でのみ失敗していないか
- モジュール個体不良の可能性はないか
現時点の結論
SIM7670G-MNGV は、USB 接続で OpenWrt / Linux から RNDIS または ECM のネットワーク IF として利用できる。
OpenWrt で USB WAN として使う場合は、以下の構成が最も扱いやすい。
ECM モード + AT+DIALMODE=0 + AT+USBNETIP=1
これにより、ホスト側では通常の Ethernet 系 IF として DHCP 取得し、OpenWrt の WAN として扱える。
GNSS については、NMEA 出力自体は可能だが、SIM / キャリア / 網によって挙動差がある。特に手元環境では、IIJmio D プランのみ GNSS 出力ができず、au 系 SIM や Docomo 公式 SIM では出力できた。
そのため、SIM7670G を GNSS ロガー用途でも使う場合は、通信可否だけでなく、実際に使用する SIM で NMEA が出るかを事前に確認する必要がある。
Fibocom FM350-GL 接続確認メモ
概要
Fibocom FM350-GL を M.2 → USB 変換ボード経由で接続し、USB 接続時に Windows / Linux からどのように扱えるかを確認した。
当初は USB 接続のみでは MBIM モデムとして認識できず、一般的な WWAN モデムとしては扱いにくいと判断していた。
その後、Windows では fibocom-connect-fm350 を使用することでネットワーク設定まで完了し、インターネット到達を確認できた。
Linux でも、AT コマンドで取得した IP 情報を ip コマンドで手動設定することで、インターネット到達を確認できた。
現時点の結論として、FM350-GL は一般的な MBIM / QMI モデムのようにそのまま扱えるわけではないが、Windows / Linux ともに手動または専用ツールを使えば USB 接続経由で通信可能と判断する。
使用構成
- モジュール: Fibocom FM350-GL
- 接続方法: M.2 → USB 変換ボード
ホスト側:
- Windows
- Linux / OpenWrt 系環境
接続状態:
- USB のみ引き出し
- PCIe 接続は未評価
変換ボード:
- RTL8125 搭載ボードを使用
USB 接続時に見えたインターフェース
USB 接続時、ホスト側には複合 USB デバイスとして認識された。
確認できたインターフェースは以下。
iInterface 3 RNDIS Communication Interface iInterface 4 RNDIS Data Interface iInterface 6 USB COM Port iInterface 7 USB COM Port iInterface 8 USB COM Port
Linux 側では複数の ttyUSB が生成された。
/dev/ttyUSB0 /dev/ttyUSB1 /dev/ttyUSB2 /dev/ttyUSB3 /dev/ttyUSB4 /dev/ttyUSB5 /dev/ttyUSB6
AT コマンド応答が取れた AT ポートは以下。
/dev/ttyUSB3
内部 OpenWrt / ADB について
USB 接続時、ADB でモジュール内部へアクセスできた。
FM350-GL内部では OpenWrt ベースの環境が動作していた。
確認された特徴は以下。
- OpenWrt 19.07-SNAPSHOT 系
- Linux 4.19.205
- aarch64
USB Gadget 構成
acm.gs0-3ffs.adbmass_storage
/dev/ccci_*系デバイス多数ubusに modem / pdn 関連のオブジェクトあり
内部 OS 上には modem_pdn などの ubus オブジェクトが存在した。
例:
ubus call modem_pdn status '{"apn":"mineo.jp"}'
応答として status: 0 などは返るが、通常の USB MBIM / QMI モデムとしてそのままホスト OS から制御できる構成ではなかった。
RNDIS 接続について
USB 接続時、RNDIS インターフェースとして認識された。
ホスト側からは RNDIS ネットワークインターフェースが見える。
モジュール内部側では ccmni0 が存在し、以下のようなアドレスが付与されていた。
ccmni0: 100.84.228.129/8
初期確認では、内部 OpenWrt 側の iptables NAT 設定が確認できず、ホスト側へ素直にモバイル回線を NAT / ルーティングする構成には見えなかった。
ただし追加検証により、Windows / Linux ともに適切な設定を行えば、RNDIS 相当のネットワークインターフェース経由でインターネット到達できることを確認した。
Windows での接続確認
Windows では、以下の GitHub プロジェクトを使用することで接続できた。
https://github.com/prusa-dev/fibocom-connect-fm350
このツールを使用することで、FM350-GL のネットワーク設定まで完了し、Windows からインターネット到達を確認できた。
確認結果としては以下。
- Windows から FM350-GL を USB 接続
- RNDIS / USB COM Port が認識される
fibocom-connect-fm350を使用- ネットワーク設定が完了
- インターネット到達を確認
このため、Windows では標準の MBIM デバイスとして扱うのではなく、専用ツールでモジュール側の接続制御とホスト側ネットワーク設定を行う形になる。
Linux での接続確認
Linux では、AT コマンドで取得した IP 情報をホスト側のネットワークインターフェースに手動設定することで、インターネット到達を確認できた。
確認結果としては以下。
- Linux から FM350-GL を USB 接続
- RNDIS 相当のネットワークインターフェースが出現
- AT コマンドで IP 情報を取得
- 取得した IP を
ipコマンドでホスト側インターフェースへ割り当て - ルーティング設定後、インターネット到達を確認
想定される流れは以下。
1. AT ポートを確認する 2. APN / PDP コンテキストを設定する 3. 接続状態を確認する 4. AT コマンドで割り当て IP を取得する 5. Linux 側の RNDIS インターフェースへ IP を設定する 6. default route を設定する 7. DNS を設定する 8. インターネット到達を確認する
Linux では DHCP で自動的にホスト側へ設定が降ってくる構成ではなく、モジュールから取得した情報をホスト側に反映する必要がある。
Linux 側の設定イメージ
実際のインターフェース名や IP は環境ごとに異なるため、以下は考え方の例。
ip link
RNDIS 相当のインターフェースを確認する。
例:
usb0 enxXXXXXXXXXXXX
AT コマンドで取得した IP を割り当てる。
ip addr add <取得したIP>/<prefix> dev <interface> ip link set <interface> up
default route を設定する。
ip route add default via <gateway> dev <interface>
DNS を設定する。
resolvectl dns <interface> <DNSサーバ>
または環境に応じて /etc/resolv.conf や NetworkManager 側で設定する。
到達確認。
ping -c 3 8.8.8.8 ping -c 3 google.com
MBIM モードについて
FM350-GL を USB 接続で MBIM モードに変更できるか確認した。
関連コマンドとして AT+GTUSBMODE を確認したが、利用可能なモードは 40 / 41 系のみで、期待した MBIM 構成には変更できなかった。
そのため、現時点では以下の判断。
- USB 接続のみでは標準的な MBIM モデムとしては扱えない
- Windows 標準の WWAN / MBIM 接続方式にはそのまま乗らない
- Linux の ModemManager / NetworkManager だけで完結する構成ではない
- ただし、専用ツールまたは手動設定により通信自体は可能
GNSS / GPS 確認
GPS / GNSS 関連の AT コマンドを確認した。
試行したコマンド例。
AT+CGPS? AT+GPS? AT+FGGPS?
結果はいずれも以下のようなエラー。
+CME ERROR: 100
また、以下も確認した。
AT+EGMSS?
応答。
+EGMSS: 0,"",0,0,0 OK
AT+EGMSS=? については OK は返るが、具体的な設定候補や有効な GNSS 出力にはつながらなかった。
確認時点では、USB 接続のみの構成で GNSS / NMEA 出力は確認できていない。
確認済み AT コマンド
AT ポート確認
AT ポートは以下で応答を確認。
/dev/ttyUSB3
GPS 系
AT+CGPS? AT+GPS? AT+FGGPS?
結果。
+CME ERROR: 100
EGMSS
AT+EGMSS?
結果。
+EGMSS: 0,"",0,0,0 OK
AT+EGMSS=?
結果。
OK
USB モード
AT+GTUSBMODE
確認結果として、MBIM に切り替えられるような選択肢は見つからず、40 / 41 系のみ確認。
成功構成
Windows
FM350-GL ↓ USB Windows ↓ fibocom-connect-fm350 ↓ ネットワーク設定完了 ↓ インターネット到達成功
Linux
FM350-GL ↓ USB Linux ↓ AT コマンドで IP 情報取得 ↓ ip コマンドで手動割り当て ↓ default route / DNS 設定 ↓ インターネット到達成功
失敗または未確認の構成
MBIM
標準 MBIM モデムとしての利用は未成功。
FM350-GL ↓ USB Windows / Linux 標準 MBIM ↓ 未成功
ModemManager 自動接続
Linux の ModemManager / NetworkManager による一般的なモバイルブロードバンド接続は未確認または未成功。
FM350-GL ↓ USB ModemManager / NetworkManager ↓ 自動接続は未確立
GNSS / NMEA
USB 接続状態での GNSS / NMEA 出力は未確認。
AT+CGPS? AT+GPS? AT+FGGPS? ↓ +CME ERROR: 100
AT+EGMSS? ↓ +EGMSS: 0,"",0,0,0
注意点
FM350-GL は、一般的な USB LTE/5G モデムのように MBIM / QMI / ECM で素直に見えるモジュールではない。
USB 接続時は、RNDIS / ADB / USB COM Port を組み合わせた独自寄りの構成になる。
そのため、OS 標準のモバイルブロードバンド接続機能だけで扱うのではなく、以下のいずれかが必要になる。
Windows:
fibocom-connect-fm350のような専用ツールを使う
Linux:
- AT コマンドで接続状態や IP 情報を取得する
- 取得した IP 情報を
ipコマンドで手動設定する - 必要に応じて route / DNS を設定する
また、USB 接続だけでは GNSS 機能が露出していない可能性がある。
現時点の判断
初期確認では、USB 接続のみの FM350-GL は 5G モデムとして実用しにくいと考えていた。
しかし追加検証により、以下を確認した。
- Windows では
fibocom-connect-fm350によりインターネット到達成功 - Linux では AT コマンドで取得した IP を
ipコマンドで割り当てることでインターネット到達成功
したがって、現時点では以下の判断に更新する。
FM350-GL は USB 接続のみでも通信可能。 ただし、標準的な MBIM / QMI モデムとしてではなく、RNDIS + AT 制御 + 手動ネットワーク設定、または専用ツールによる接続が必要。
今後の確認ポイント
今後、評価を進める場合の確認ポイントは以下。
- Linux での接続手順のスクリプト化
- AT コマンドで取得する IP / gateway / DNS 情報の整理
- DHCP で自動配布できるかの確認
- NetworkManager への統合可否
- ModemManager で扱える余地があるか
- OpenWrt で hotplug / netifd に組み込めるか
- Windows での
fibocom-connect-fm350の動作条件整理 - PCIe 接続時の挙動確認
- GNSS / NMEA 出力の再確認
結論
Fibocom FM350-GL は、M.2 → USB 変換ボード経由の USB 接続では、標準的な MBIM モデムとしては扱えなかった。
一方で、Windows では fibocom-connect-fm350 を使用することでネットワーク設定まで完了し、インターネット到達できた。
Linux でも、AT コマンドで取得した IP 情報を ip コマンドで手動設定することで、インターネット到達できた。
そのため、FM350-GL は USB 接続のみでも通信利用は可能。 ただし、一般的な MBIM / QMI モデムのような自動接続ではなく、専用ツールまたは手動設定を前提に扱う必要がある。
GNSS / GPS については、現時点では USB 接続状態で有効な NMEA 出力を確認できていない。
更新再開について
流行り病も落ち着き趣味の開発をぼちぼち再開してきたのでメモ更新再開します。 ただ、可処分時間の関係で調査結果をchat gptに食わせてまとめるようになったので、AI臭い文書が苦手な人はごめんね。 実際の調査自体は手を動かしてるんだけど、ナレッジとしてまとめる時間を節約したいためこのスタイルで更新していきます。
タグに「AIによる作業要約」と書いてるので目印にしてください。
実際のソフトウェア開発もcodexのAIエージェント開発を中心にコアロジックのみ手書きのようなスタイルにすることで、なんとかソフトウェアがまた作れるようになってきました。 本業がまだAIエージェント開発では厳しいところもあって、時間の取れない趣味の開発から移行することになった感じです。
Raspberry Pi Zeroでmpd_gui改を動かす手順
拙作のVolumio2特化対応したmpd_gui改をRaspberry Pi Zeroで動かす手順の紹介です。
blue-7さんの公開されているLCDにmpd/volumioの曲名情報を表示するアプリmpd_gui(mpd or volumio対応)をカスタムしたものになります。
現時点ではWaveShare 1.3" 240x240 LCD HATとRaspi DAP Base(じんそんさんよりリリース予定)に対応しています。WaveShare 1.3" 240x240 LCD HATはI2S信号ラインとキーの配線がぶつかってるた2か所カット・ジャンパーの必要があります。
mpd_gui改の変更点とか
- Volumio2とSocket.ioで通信
- CPU負荷を多少低減
- メニューシステムの追加
- キュー、プレイリスト、ミュージックライブラリの操作を追加
- Alsa Mixer制御を追加(デジフィルなどDACの設定変更用)
- LCD Sleep機能の追加(一定時間無操作でSPI通信をOFF)
現時点での制約事項など
- volumio2のみ対応です。(将来的にはmpdにも対応はしたい)
- GPIOは5ボタンまで対応
- dtoverlayの変更はできません
- volumio-2.513-2018-12-07-pi.imgで動作確認しました
WaveShare液晶の改造
- KEY1とJoystick DownがI2S信号とぶつかってるので配線カットして下記のポートに繋ぎ変えてください
- KEY1 P21 -> P17
- Joystick Down P19 -> P22
build手順
準備(prepare)
sudo apt update sudo apt install build-essential cmake libboost-system-dev libboost-date-time-dev libboost-random-dev libssl-dev raspi-config libcv-dev libopencv-dev opencv-doc fonts-takao-gothic libtag1-dev libcurl4-openssl-dev git clone --recurse-submodules https://github.com/socketio/socket.io-client-cpp.git cd socket.io-client-cpp cmake ./ make clean make cd .. git clone https://github.com/tkztkztkz/NanoPi-NEO.git cd NanoPi-NEO/ git checkout SUPPORT_VOLUMIO
ビルド例 WaveShare IPS 1.3 240x240 KEYボタンを3ボタンとして使用
make -f makefile.rpiz DISPTYPE="-DDISPLAY_13IPS240240_RPI -DGPIO_BUTTON_POLARITY_INVERT -DGPIO_BUTTON_PREV=17 -DGPIO_BUTTON_NEXT=20 -DGPIO_BUTTON_PLAY=16" TARGET=mpd_gui
ビルド例 WaveShare IPS 1.3 240x240 ジョイスティックを5ボタンとして使用
make -f makefile.rpiz DISPTYPE="-DDISPLAY_13IPS240240_RPI -DGPIO_BUTTON_POLARITY_INVERT -DGPIO_5BUTTON -DGPIO_BUTTON_PREV=5 -DGPIO_BUTTON_NEXT=26 -DGPIO_BUTTON_PLAY=13 -DGPIO_BUTTON_UP=6 -DGPIO_BUTTON_DOWN=22" TARGET=mpd_gui
ビルド例 Raspi DAP Base
make -f makefile.rpiz DISPTYPE="-DDISPLAY_RASPI_DAP_BASE -DGPIO_BUTTON_POLARITY_INVERT -DGPIO_5BUTTON -DGPIO_BUTTON_PREV=24 -DGPIO_BUTTON_NEXT=26 -DGPIO_BUTTON_PLAY=5 -DGPIO_BUTTON_UP=27 -DGPIO_BUTTON_DOWN=22" TARGET=mpd_gui
設定変更 SPIの有効化
- raspi-config
Interfacing Option -> P4 SPI -> Yes
起動手順
mpd_guiを/usr/local/binにコピーして実行権限を付けたうえで、下記のコマンドを/etc/rc.localあたりに放り込んでください。
ビルド例 WaveShare IPS 1.3 240x240 ジョイスティックを5ボタンとして使用
gpio -g mode 5 up gpio -g mode 26 up gpio -g mode 13 up gpio -g mode 6 up gpio -g mode 22 up /usr/local/bin/mpd_gui &
WaveShare IPS 1.3 240x240 KEYボタンを3ボタンとして使用
gpio -g mode 17 up gpio -g mode 20 up gpio -g mode 16 up /usr/local/bin/mpd_gui &
Raspi DAP Base
gpio -g mode 24 up gpio -g mode 26 up gpio -g mode 5 up gpio -g mode 27 up gpio -g mode 22 up /usr/local/bin/mpd_gui &
操作方法
- PREV/PLAY/NEXTは、前曲・再生開始停止・次曲
- UP/DOWNで音量を変更
- PREV/NEXT長押しで音量を連続的に変更
- PLAY長押しでメニューに入ります。長押しでメニューから抜けます
Si5351A Linuxドライバの解析メモ
ドライバの実装仕様
- Linux KernelのCommon Clk Frameworkに則り実装
- Si5351シリーズに対応。最大8ch出力できる。
- 今回はSi5351A 10-MSOP品を制御対象としているの3chでの使い方に絞ってます
- 8ch出力時のclkout6/7のDivider制約にも対応していそう
- dtsでクロックツリーを記述できる(各clkoutのクロックソースなど)
- clocks にリファレンスクロックを指定。clocksは別途fixed-clockで定義しておき参照する。
- silabs,pll-sourceはPLLのソースを指定
- 0でXTAL
- 1でClkin(Variant_Cのみ)
- silabs,multisynth-sourceはMultiSynthのソースを指定
- 0でPLLA
- 1でPLLB or VCXO(Variant_Cのみ)
- silabs,clock-sourceはclkoutにどのMultiSynthをソースにするか指定。
- 0で自動的にclkoutのソースをMultiSynthに結び付ける。clockout_Nに対してMultiSynth_Nを割あてる。
- 1でclkout1-3のソースをMultiSynth_0に結び付け、clkout5-7のソースをMultiSynth_4に結び付ける。clkout0,4には無効
- 2でclkoutのソースをxtalに結び付ける
- 3でclkoutのソースをclkinに直結。Variant_Cのみ有効
- silabs,pll-master 指定したclkoutにPLLの再設定を許可する
- この指定のあるclkoutに周波数設定を行ったとき、PLL設定周波数を算出・設定する。
- silabs,drive-strength Drive Strength指定可(2,4,6,8mA)
- silabs,disable-state Disable State指定可(LOW/HIGH/Hi-Z/Never)
- clock-frequency clkoutの周波数初期値を設定
dts設定方法
- dtsの例
/ {
clocks {
/* 25MHz reference crystal */
ref25: oscillator {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <25000000>;
};
};
};
&i2c0 {
status = "okay";
si5351: clock-generator {
compatible = "silabs,si5351a-msop";
reg = <0x60>;
#address-cells = <1>;
#size-cells = <0>;
#clock-cells = <1>;
/* connect xtal input to 25MHz reference */
clocks = <&ref25>;
clock-names = "xtal";
/* connect xtal input as source of pll0 and pll1 */
silabs,pll-source = <0 0>, <1 0>;
clkout0 {
reg = <0>;
silabs,drive-strength = <8>;
silabs,multisynth-source = <0>;
silabs,clock-source = <0>;
silabs,pll-master;
silabs,disable-state = <2>;
clock-frequency = <22579200>;
};
clkout1 {
reg = <1>;
silabs,drive-strength = <8>;
silabs,multisynth-source = <0>;
silabs,clock-source = <0>;
silabs,disable-state = <2>;
clock-frequency = <2822400>;
};
clkout2 {
reg = <2>;
silabs,drive-strength = <8>;
silabs,multisynth-source = <0>;
silabs,clock-source = <0>;
silabs,disable-state = <2>;
clock-frequency = <44100>;
};
};
};
使い方
- pll-masterを付加したclkをclk_set_rateすると、PLLまで設定が走る
- pll-masterが無いclkはclk_set_rateすると、そのときのPLL rateからMultiSynthとR Divで誤差の小さくなるクロックを作る
- このdtsの場合clkout0 -> clkout1/2の順で設定する必要がある
- clkout0にmclkを。clkout1にbclk,clkout2にlrclkを割り当てた。
- clock-cells = <1>なので下記のように参照する。2番目の値がclkoutのreg値を指す
clocks = <&si5351 0>, <&si5351 1>, <&si5351 2>;
備考
- 最初のクロック設定で正しく設定しているのにクロックが出ない場合
- 初回のPLL設定シーケンスに問題がありそう
- device-treeに何でも良いので初期クロック(clock-frequency)を書いておくことで回避可能です
- NEO2用Audio Kernelでは下記2点の修正を加えています
- xtal_cl設定機能
- device treeより水晶の容量負荷を変更できるようにしています
- driver init時にクロック出力をPowerDownに設定
- driver init時にクロック出力状態の場合、不安定になるケースが見られたので修正しています。
- xtal_cl設定機能