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+CESQERROR

電波品質は以下から取得する。

  • AT+QENG="servingcell"
  • AT+QCSQ
  • AT+QRSRP
  • AT+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"QCAINFOQNWINFOCEREG?QCSQCGPADDRCGCONTRDP を使えば、実用上必要な情報はほぼ取得できる。

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",5ERROR となったため、本個体/ファームでは非対応と判断する。


現在値確認

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 コマンド用ポートは環境により変わる可能性があるため、実機では ATOK が返るポートを確認する。

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 が usb0eth1 として見える。

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-3
    • ffs.adb
    • mass_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時にクロック出力状態の場合、不安定になるケースが見られたので修正しています。