nakayama244
2023年6月10日 17時01分
LTE通信を使用してサーバにデータを送信するのですが
通信状況が安定せず、接続できたりできなかったりします。
接続ができていないときに以下のコマンドを実行しました。
mmcli -b 0
status のconnected がnoになっていました。
このような状態になったとき
電波状況が原因なのか、ハードウェアの問題なのか
切り分けるための方法をご教授ください。
| ファイル | ファイルの説明 |
|---|---|
| LTEパラメータ.png | mmcli 実行結果 |
コメント
nakayama244
吉田様
回答ありがとうございます。
> (1) 設置箇所の電波品質を確認ください
> LTE 接続後、mmcli -m 0コマンドで表示される Signal Quality の
> 値が 20 など低い場所では接続状態が不安定になる可能性があります。
こちらの方法で電波強度を確認してみます。
> (3) Armadillo-IoT ゲートウェイ A6E Cat.M1 モデルをご利用であれば、
> Cat.M1 モデルは間欠動作を前提しているため、標準状態では LTE 再接続サービスを
> 有効にしておりません。
> Cat.M1 モデルを間欠動作ではなく連続で LTE 通信を実施する使用方法で
> ご利用の場合は、LTE 再接続サービスを有効にすることもご検討ください。
> 有効にする手順は製品マニュアル「LTE 再接続サービス」の章を参照ください。
現在、この設定を有効にしており
設定時間をデフォルトの120->600に変更しています
そして、端末の再起動も両方有効にしています。
設定どおり１０分で再起動をしていました。
また、この設定をする前に確認したのですが
データ送信が途切れていた時にWWANのランプが消灯していました。
マニュアルによるとSIMを認識していない、またはモデムを認識していないとありますが
起動中に認識を喪失することがあるのでしょうか。
また、再起動したときたまにWWANのランプが点灯しないことがあります。
> (4) また、LTE 再接続サービスを既に有効にしている場合は、
> 設定ファイルの PING_DEST_IP が指定している IP アドレスが
> ping の通る IP アドレスであるかの確認をお願いします。
IPアドレス限定でしょうか。
現状デフォルトの8.8.8.8に設定しています。
送信先をデータ送信先のサーバに設定する場合には
ドメイン名などを設定できるでしょうか。
「xxxx.com」など
at_mitsuhiro.yoshida
吉田です。
> また、この設定をする前に確認したのですが
> データ送信が途切れていた時にWWANのランプが消灯していました。
> マニュアルによるとSIMを認識していない、またはモデムを認識していないとありますが
> 起動中に認識を喪失することがあるのでしょうか。
>
> また、再起動したときたまにWWANのランプが点灯しないことがあります。
申し訳ありません。
SIM が挿入されている状態で、LTE 未接続状態でも WWAN LED が消灯になるパターンが
存在しておりました。今後のアップデートで修正いたします。
ご指摘ありがとうございます。
> IPアドレス限定でしょうか。
> 現状デフォルトの8.8.8.8に設定しています。
> 送信先をデータ送信先のサーバに設定する場合には
> ドメイン名などを設定できるでしょうか。
> 「xxxx.com」など
LTE 網にて名前解決ができるのであれば ping の通るドメイン名を PING_DEST_IP に指定する事が可能です。
事前に LTE を接続した状況で、
Cat.1 モデルであれば
[armadillo~ #] ping -i usb0 ドメイン名
Cat.M1 モデルであれば
[armadillo~ #] ping -i ppp0 ドメイン名
が OK であることをご確認の上設定と検証をお願いします。
nakayama244
吉田様
ご回答ありがとうございます。
㎜cli -m 0 を実行して
アンテナをそのまま測定したときの Signal Qualityと
外して測定したときの Signal Qualityが同じ数値で
77%(cached) となっていますが、正常な動作でしょうか。
最初の質問にある mmcli -b 0 を実行して
status のconnected がno の状態でも
コンテナ内のpythonプログラムは通信ができて
データ送信を続けていたのですが
これは通信には関係ないパラメータでしょうか。
LTEの通信が短いと10分くらいでサーバとの接続が切れます。
現在、再接続サービスの端末再起動で自動復帰はしているのですが
接続が切れる根本的な原因を特定して対策したいと思っています。
端末自身の動作ログなど取得して調査を行う手順などありましたら
ご教授お願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| mmcli.png | アンテナを付けてのSignal Qualityと 外して測定したときの値、status connectedの状態 |
at_mitsuhiro.yoshida
吉田です。
> ㎜cli -m 0 を実行して
> アンテナをそのまま測定したときの Signal Qualityと
> 外して測定したときの Signal Qualityが同じ数値で
> 77%(cached) となっていますが、正常な動作でしょうか。
Cat.M1 モデルですと、省電力制御のため電波品質を更新するタイミングが
LTE 接続時程度しかないためその時の値 (cached) を表示している可能性があります。
Cat.1 モデルでしたら周期的に更新しております。
77% (recent) と (recent) がついていますと最近の値となります。
> 最初の質問にある mmcli -b 0 を実行して
> status のconnected がno の状態でも
> コンテナ内のpythonプログラムは通信ができて
> データ送信を続けていたのですが
> これは通信には関係ないパラメータでしょうか。
いいえ、 bearer が接続した状態にならないと LTE の IP 通信もできません。
> LTEの通信が短いと10分くらいでサーバとの接続が切れます。
> 現在、再接続サービスの端末再起動で自動復帰はしているのですが
> 接続が切れる根本的な原因を特定して対策したいと思っています。
まずは、再接続サービスの PING_DEST_IP の値を
ping 導通可能な値に設定して確認いただけますでしょうか。
nakayama244
>> マニュアルによるとSIMを認識していない、またはモデムを認識していないとありますが
>> 起動中に認識を喪失することがあるのでしょうか。
> SIM が挿入されている状態で、LTE 未接続状態でも WWAN LED が消灯になるパターンが
> 存在しておりました。今後のアップデートで修正いたします。
> ご指摘ありがとうございます。
この件について
起動中と書いてしまい認識があっていないかもしれないので補足します。
これは、運転しているとき（LTE接続して通信もしていた）にLEDが途中で消えていたというものです。
そのような場合でもLEDが消灯になることがあるでしょうか。
katoh007
> SIM が挿入されている状態で、LTE 未接続状態でも WWAN LED が消灯になるパターンが
> 存在しておりました。今後のアップデートで修正いたします。
質問の補足ですが、WWAN LEDが点灯（ON）の状態は、言わば
「SIMの認識を終え、LTE通信制御の準備が整いました。いつでも通信を開始してください。」
の意味と解釈しております。
そこで、一旦ハンドシェイクが確立された状態に於いて、LEDが消灯する事象が起こる原因を知りたく
お問い合わせしている次第です。
ご回答がいまひとつ理解できないでおります。
> SIM が挿入されている状態で、LTE 未接続状態でも WWAN LED が消灯・・・
これは当然の振る舞いのように思うからです。
或いは当回答の意味は、当該パターンの存在を失念していたため、
現行Ver.ではLTE確立前にLEDが点灯してしまっている、ということでしょうか？
そのためアップデート修正？
改めてご回答をお願い致します。
ただいま同現場にて本機を３台運用しているのですが、３台の電波環境は各々異なるものの
２台は良好であり、１台のみが当現象となり困っている次第です。
mmcliにて調査をしました。
signal quality〝77～90（recent）〟とEXCELLENTな状態です。
A6Eでは〝cashed〟は自動更新されないとのことから、複数回の電源再起動をすることで確認しております。
なおこの間、いずれもstatusのconnectedが〝no〟であることも気になっており、しかしデータはLTE経由で
取得できているのです。no/yesがバタバタ繰り返すような挙動があるのでしょうか？
１台のみに現れる現象ということでもあり、ハードウェア固有の現象（不具合）の可能性はないでしょうか？
ご回答のほど宜しくお願い致します。
at_mitsuhiro.yoshida
吉田です。
> 或いは当回答の意味は、当該パターンの存在を失念していたため、
> 現行Ver.ではLTE確立前にLEDが点灯してしまっている、ということでしょうか？
WWAN の LED は mmcli コマンドにて 10 秒周期に状態を確認して変更しております。
connected の状態が継続する場合は ON のままとなります。
現状の制御では "registered" と "connecting" の状態であれば、LED を点滅しておりますが、
それ以外の状態 "searching" などの場合にも消灯となります。
製品マニュアルに記載した仕様として、LED の消灯は
「SIM 未検出または認識中、または LTE モデム未検出」
の場合に消灯ですので、その仕様に合わせた修正を行います。
> ただいま同現場にて本機を３台運用しているのですが、３台の電波環境は各々異なるものの
> ２台は良好であり、１台のみが当現象となり困っている次第です。
>
> mmcliにて調査をしました。
> signal quality〝77～90（recent）〟とEXCELLENTな状態です。
> A6Eでは〝cashed〟は自動更新されないとのことから、複数回の電源再起動をすることで確認しております。
ご確認ありがとうございます。
Cat.M1 モデルをご利用と理解しました。
> なおこの間、いずれもstatusのconnectedが〝no〟であることも気になっており、しかしデータはLTE経由で
> 取得できているのです。no/yesがバタバタ繰り返すような挙動があるのでしょうか？
bearer が未接続の状態で LTE 通信が出来ることが想定していない動作となっております。
bearer 接続後、ppp の確立を行って LTE の IP 通信が可能となります。
大変お手数ですが、以下の手順にて ModemManager のデバッグログを有効にした状態で、
https://armadillo.atmark-techno.com/howto/mm-debug
現象を再現させた /var/log/messages を添付いただけませんでしょうか。
nakayama244
吉田様
> 大変お手数ですが、以下の手順にて ModemManager のデバッグログを有効にした状態で、
> https://armadillo.atmark-techno.com/howto/mm-debug
> 現象を再現させた /var/log/messages を添付いただけませんでしょうか。
現在、問題になっている端末が手元に無いので
手元にある同機種の方で設定を変更し
デバッグログを出力しました。
手物の端末では異常が出ていないと思うのですが
こちらのログ出力でよいかどうか確認して頂けないでしょうか。
良ければ異常の端末にも同様の方法で設定を施そうと思っています。
| ファイル | ファイルの説明 |
|---|---|
| messages.zip | /var/log/messages デバッグログ有効化 |
at_mitsuhiro.yoshida
nakayama244
吉田様
ご確認ありがとうございました。
> お手数おかけします、このログで間違いありません。
>
> 追加で可能であれば、確認いただければと思う事項をあげておきます。
> 同一現場の 3 台中 1 台の接続状況がよくないとのことですが、
> - 3 台は、どの程度距離が離れていますでしょうか。
> - 3 台の場所を入れ替えると現象は変わりますでしょうか。
> - 3 台の /etc/atmark/ems31-boot.conf の設定は同一でしょうか。
3台のems-boot.confは同じと思いますが、念のため確認いたします。
また、今回取得したログの中に以下のように
Modem hangup と出ていますが、こちらについては問題ないでしょうか。
Jun 16 22:31:14 armadillo daemon.notice pppd[1926]: Modem hangup
Jun 17 02:31:15 armadillo daemon.notice pppd[10681]: Modem hangup
Jun 17 06:31:18 armadillo daemon.notice pppd[19285]: Modem hangup
Jun 17 10:28:53 armadillo daemon.notice pppd[27860]: Modem hangup
Jun 17 14:26:14 armadillo daemon.notice pppd[3957]: Modem hangup
Jun 17 18:23:24 armadillo daemon.notice pppd[12435]: Modem hangup
Jun 17 22:23:23 armadillo daemon.notice pppd[20899]: Modem hangup
Jun 18 02:21:13 armadillo daemon.notice pppd[29461]: Modem hangup
Jun 18 06:21:15 armadillo daemon.notice pppd[5571]: Modem hangup
Jun 18 10:21:51 armadillo daemon.notice pppd[14146]: Modem hangup
Jun 18 14:18:24 armadillo daemon.notice pppd[22742]: Modem hangup
Jun 18 18:16:13 armadillo daemon.notice pppd[31182]: Modem hangup
Jun 18 22:14:04 armadillo daemon.notice pppd[7284]: Modem hangup
Jun 19 02:11:14 armadillo daemon.notice pppd[15773]: Modem hangup
Jun 19 06:11:14 armadillo daemon.notice pppd[24240]: Modem hangup
at_mitsuhiro.yoshida
takanori_shimizu
> 吉田です。
>
> > また、今回取得したログの中に以下のように
> > Modem hangup と出ていますが、こちらについては問題ないでしょうか。
> >
> > Jun 16 22:31:14 armadillo daemon.notice pppd[1926]: Modem hangup
>
> はい hangup は電話を切ったという意味で LTE 通信終了時にも表示されます。
吉田様
nakayamaと同じ会社の者です。
上記、質問の続きで以下について教えてください。
①HTTP通信でLTE接続（SIMカード）により、10秒周期にクラウドサーバーへデータを送信しています。
hangupでLTE通信が終了されるのは、armadilloの通信処理の仕様でしょうか？
SIMカードの仕様でしょうか？
デバッグログから分かりますでしょうか？
②hangupがログ出力されてから、データを送り始めるまでに9分近くかかっているように見受けられますが
認識として合っているでしょうか？
これは、SIMを認識するまでの時間とdocomo回線が接続されるまでに時間がかかっているのでしょうか？
デバッグログの見方を教えてください。
Jun 16 22:31:14 armadillo daemon.notice pppd[1926]: Modem hangup
Jun 16 22:40:33 armadillo daemon.debug [1732]: [1686922833.680995] [modem0/ttyCommModem/at] <-- '+CEREG: 1,"168A","02B15303",7'
at_mitsuhiro.yoshida
吉田です。
先程いただいたログは、modemmanager のデバッグログが
出力されているかどうかを確認する為にいただいたものですので、
内容の詳細は確認しておりません。
> nakayamaと同じ会社の者です。
> 上記、質問の続きで以下について教えてください。
> ①HTTP通信でLTE接続（SIMカード）により、10秒周期にクラウドサーバーへデータを送信しています。
> hangupでLTE通信が終了されるのは、armadilloの通信処理の仕様でしょうか？
> SIMカードの仕様でしょうか？
> デバッグログから分かりますでしょうか？
Jun 17 02:31:15 armadillo daemon.notice pppd[10681]: Modem hangup
のログの通り、pppd が出力しているログです。
> ②hangupがログ出力されてから、データを送り始めるまでに9分近くかかっているように見受けられますが
> 認識として合っているでしょうか？
hangup された時点で LTE は切断しておりますので、
その後でデータ―通信が出来ることはないです。
> これは、SIMを認識するまでの時間とdocomo回線が接続されるまでに時間がかかっているのでしょうか？
> デバッグログの見方を教えてください。
>
> Jun 16 22:31:14 armadillo daemon.notice pppd[1926]: Modem hangup
これは LTE の ppp 通信が切断された、ということになります。
> Jun 16 22:40:33 armadillo daemon.debug [1732]: [1686922833.680995] [modem0/ttyCommModem/at] <-- '+CEREG: 1,"168A","02B15303",7'
これは、ネットワーク登録がされたことを示すログです。
ネットワーク登録 → 接続動作 → ppp 接続状態となります。
ネットワーク登録は LTE の接続を実施しなくても、以前にネットワーク登録が出来ていれば LTE モジュールが自動的に実施します。
いただいたログの中では再接続サービス (connection-recover) が動作していないので、
別なソフトウェアなどで LTE 接続を制御されていると推測します。
nakayama244
吉田様
17時03分から7時16分頃に端末の通信がしばらく途切れていました。
その時のvar/log/messagesのログを取得しました。
ログの解析お願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| messages.zip | var/log/messagesログ |
nakayama244
nakayama244
at_mitsuhiro.yoshida
吉田です。
ログを確認しました、確かに短時間で切断する回数が多くみえます。
なんらかの要因で LTE の接続が出来ていないことが多く、再接続を繰り返しています。
再接続自体も失敗していることが多いです。
以前にもお聞きした可能性があるかもしれませんが、
この Armadillo-IoT ゲートウェイ A6E を違う場所で使用しても同様の状況でしょうか？
大変お手数ですが、ソフトウェア Armadillo Base OS を最新に更新されて、
違う SIM カード・違う場所でも同様の状況であれば、
故障かなと思ったら
https://armadillo.atmark-techno.com/faq/troubleshooting-aiota6e
を参考に交換などのご検討をお願いします。
nakayama244
at_mitsuhiro.yoshida
2023年6月12日 9時13分
吉田です。
接続はできているとのことで H/W の異常や設定の不備は考えにくいです。
どの程度の期間で切断されるかが不明ですので一般的な確認事項を記載します。
(1) 設置箇所の電波品質を確認ください
LTE 接続後、mmcli -m 0コマンドで表示される Signal Quality の
値が 20 など低い場所では接続状態が不安定になる可能性があります。
(2) 長時間連続して接続している場合、ご契約の料金プランによっては
一定時間経過後一度切断されることがあります。
ご契約のプロバイダにご確認ください。
(3) Armadillo-IoT ゲートウェイ A6E Cat.M1 モデルをご利用であれば、
Cat.M1 モデルは間欠動作を前提しているため、標準状態では LTE 再接続サービスを
有効にしておりません。
Cat.M1 モデルを間欠動作ではなく連続で LTE 通信を実施する使用方法で
ご利用の場合は、LTE 再接続サービスを有効にすることもご検討ください。
有効にする手順は製品マニュアル「LTE 再接続サービス」の章を参照ください。
(4) また、LTE 再接続サービスを既に有効にしている場合は、
設定ファイルの PING_DEST_IP が指定している IP アドレスが
ping の通る IP アドレスであるかの確認をお願いします。