uen2825
2024年4月18日 16時03分
お世話になっております。
10分間隔でSLEEP状態からRS485受信で起動、LTE接続でサーバーにデータを送っています。
プログラム手順は下記の通りです。
１．RS485で受信、SLEEPから起動
２．LTEの電波受信感度を確認。電波状況が確認できるまで30回ループ、取れなければ電波受信感度0
from mm_dbus_modem import MMModem
mm_modem = MMModem()
Condition = mm_modem.signal_quality()３．サーバーにpingが通るか20回確認。
res = subprocess.run(["ping",host,"-c", "1","-W", "1"],stdout=subprocess.PIPE)
４．サーバー接続、データ（sftp）送信。
今回pingが通らずA6Eをコンソールで確認しました。
１．RS485で受信、SLEEPから起動
２．LTEの電波受信感度は取れました。
３．pingが通らない状況でした。
独自でのログです。良い時はLTE電波感度、pingとも一回で取得できました。
開始時間 受信感度時間：回数 ping時間：回数 2024-04-18 00:50:00:start:00:50:17.605337 LTE:0:00:00.410101 cnt = 1 ping:0:00:00.151562 cnt = 1 << 良い状態 2024-04-18 01:00:00:start:01:00:16.397548 LTE:0:00:01.726669 cnt = 1 ping:00:18.127931 cnt = 21 << 以下悪い状態 2024-04-18 01:10:00:start:01:10:17.494958 LTE:0:00:02.772654 cnt = 1 ping:0:00:17.458737 cnt = 18 2024-04-18 01:20:00:start:01:20:17.219044 LTE:0:00:01.892498 cnt = 1 ping:0:20:19.115315 cnt = 21 2024-04-18 01:30:00:start:01:30:22.003690 LTE:0:00:30.167090 cnt = 30 ping:0:30:52.174347 cnt = 21
simはsorakom plan-Dです。
4/12 夕方～4/16 15:00頃
4/16 17:00～4/18 1:00頃まで動いており、4/18 1:00から止まってしまいました。
A6Eをコンソールからrebootとしてもpingが通らない状態。
mmcli -m 0とコマンド入力するとエラーメッセージを表示し、3回入力したところで勝手にrebootしました。
armadillo:~# mmcli -m 0 error: couldn't find the ModemManager process in the bus armadillo:~# mmcli -m 0 error: couldn't find the ModemManager process in the bus armadillo:~# mmcli -m 0 error: couldn't find the ModemManager process in the bus armadillo:~# U-Boot 2020.04-at21 (Dec 22 2023 - 06:09:25 +0000) CPU: i.MX6ULL rev1.1 at 396 MHz Model: Atmark Techno Armadillo-IoT Gateway A6E Board DRAM: 512 MiB WDT: Started with servicing (10s timeout) PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11 MMC: FSL_SDHC: 0, FSL_SDHC: 1 桒n: mxc_serialt from MMC... OK Out: mxc_serial Err: mxc_serial
再起動後に mmcli -m 0 とコマンド入力したところキチンと情報が出てきて、正常に送信できるようになりました
armadillo:~# mmcli -m 0
--------------------------------
General | path: /org/freedesktop/ModemManager1/Modem/0
| device id: 8d173d232ecf1764e69dc9b8e5d3609493755119
--------------------------------
Hardware | manufacturer: Cinterion
| model: EMS31-J
| firmware revision: REVISION 04.014
| supported: lte
| current: lte
| equipment id: 358009090243816
--------------------------------
System | device: ems31
| plugin: cinterion-ems31
| primary port: ttyCommModem
| ports: ttyCommModem (at), ttyMux1 (at)モデムマネージャーがハングアップしていたということでしょうか？
解決策がありましたらご指導ください。
宜しくお願いいたします。
コメント
uen2825
2024年4月19日 18時34分
吉田様
ありがとうございます。
情報不足申し訳ございません。
> (1) 現象発生時のソフトウェアバージョンと設定内容
バージョン
armadillo:~# cat /etc/sw-versions base_os 3.18.5-at.8 boot 2020.4-at21 extra_os.a6e-gw-container 2.4
connection-recover.conf 使用しておりません
ems31-boot.conf 初期設定のままです
> (2) 残っていましたら、現象発生時の Armadillo 側のログ
問題となったA6Eは近くにありませんのでなんとも・・
ただ同じ10分間隔で処理をしている別のA6Eのログを見ると、発生時の時間帯のログは残っておりませんでした。
uen2825
2024年4月22日 13時08分
吉田様
お世話になります。
夜中に停止してしまいましたので/var/log/message.0のlogを送らせていただきます。
logは4MBありましたので圧縮して添付いたします。
23:50 成功
00:00 失敗
00:10 失敗
00:20 失敗
00:30 成功
00:40 成功
00:50 失敗
01:00 失敗
01:10 失敗
01:20 成功
こちらで何か掴めますでしょうか。
宜しくお願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| messages.zip |
uen2825
2024年6月5日 11時26分
お世話になります。
５月のアップデートにより当初困っていたことは解決いたしました。
ありがとうございます。
LTE接続で問題が発生してしまい、追加で質問させてください。
armadillo:~# cat /etc/sw-versions base_os 3.19.1-at.4 boot 2020.4-at21 extra_os.a6e-gw-container 2.5.3
LTE接続が調子悪くems31のバージョン取得は出来ません
armadillo:~# send-at /dev/ttyMux2 ATI1 echo ems31 open serial: No such device
アップデートしてあるので本来は下記の値です。
armadillo:~# send-at /dev/ttyMux2 ATI1 echo ems31 ATI1 Cinterion EMS31-J REVISION 04.014 A-REVISION 01.001.10
先ほどまでA6Eが正常に動いていたのですが、
ems31-boot.confの設定で
fix_profile="auto" を fix_profile="kddijp"に変更して永続化したところLTE接続が出来なくなってしまいました。WWANの点滅/点灯がしません。
fix_profile="auto"に戻しても直りません。
LTEコネクションを作り直しても同じ状況です。
armadillo:~# mmcli -L error: couldn't create manager: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface “org.freedesktop.DBus.ObjectManager” on object at path /org/freedesktop/ModemManager1
定期的に下記の表示がされます。
armadillo:~# [ 623.991457] Freezing of tasks failed after 20.010 seconds (1 tasks refusing to freeze, wq_busy=0): [ 765.171448] Freezing of tasks failed after 20.009 seconds (1 tasks refusing to freeze, wq_busy=0): [ 1030.141403] Freezing of tasks failed after 20.008 seconds (1 tasks refusing to freeze, wq_busy=0): [ 1172.851387] Freezing of tasks failed after 20.007 seconds (1 tasks refusing to freeze, wq_busy=0):
コンテナ終了の際も正常時と違う終わり方をしています
klogd | * Stopping busybox klogd ... [ ok ] networkmanager | * Stopping networkmanager ...syslog | * Stopping busybox syslog ... [ ok ] [ ok ] udev | * Stopping udev ... [ ok ] cgroups | * cgroups: waiting for podman-atmark (50 seconds) dbus | * dbus: waiting for modemmanager (50 seconds) localmount | * localmount: waiting for modemmanager (50 seconds) root | * root: waiting for modemmanager (50 seconds) sysfs | * sysfs: waiting for podman-atmark (50 seconds) fsck | * fsck: waiting for modemmanager (50 seconds) Terminated cgroups | * cgroups: waiting for podman-atmark (41 seconds) podman-atmark | [ ok ] dbus | * dbus: waiting for modemmanager (41 seconds) localmount | * localmount: waiting for modemmanager (41 seconds) root | * root: waiting for modemmanager (41 seconds) fsck | * fsck: waiting for modemmanager (41 seconds) dbus | * dbus: waiting for modemmanager (32 seconds) [21568]: <msg> caught signal, shutting down... localmount | * localmount: waiting for modemmanager (32 seconds) root | * root: waiting for modemmanager (32 seconds) fsck | * fsck: waiting for modemmanager (32 seconds) dbus | * dbus: waiting for modemmanager (23 seconds) localmount | * localmount: waiting for modemmanager (23 seconds) root | * root: waiting for modemmanager (23 seconds) fsck | * fsck: waiting for modemmanager (23 seconds) dbus | * dbus: waiting for modemmanager (14 seconds) localmount | * localmount: waiting for modemmanager (14 seconds) root | * root: waiting for modemmanager (14 seconds) fsck | * fsck: waiting for modemmanager (14 seconds) dbus | * dbus: waiting for modemmanager (5 seconds) localmount | * localmount: waiting for modemmanager (5 seconds) root | * root: waiting for modemmanager (5 seconds) fsck | * fsck: waiting for modemmanager (5 seconds) dbus | * Stopping System Message Bus ... [ ok ] [21568]: <wrn> [plugin-manager] task 0,ttyMux1: error when checking support with plugin 'cinterion-ems31': (tty/ttyMux1) failed to open port after 4 tries localmount | * Unmounting loop devices
以前も同じ症状が発生し初期状態に戻し対応していましたが、直せる方法や見直しする設定等ございましたらご指導ください。
uen2825
2024年6月5日 16時43分
お世話になります。
同じような内容の投稿があり失礼いたしました。
https://armadillo.atmark-techno.com/forum/armadillo/20252
こちらのフォーラムで
6/4 17：45に吉田様がコメントされた方法で解決いたしました。
ありがとうございました。
uen2825
2024年6月14日 9時20分
お世話になります。
昨日、A6Eの設置場所を変更したところ通信が出来ない状態となってしまいました。
10分毎に通信しています。
9:20まで数日間正常に通信できました
11:30別の場所に設置。おそらく数回のリトライで通信ができました
16:00以降に更に別の場所で通信。通信が全くできなくなってしまいました。WWANのLEDが点滅
下記のコマンドを２つ実行したところ正常になりました
armadillo:~# nmcli down gsm-ttyCommModem armadillo:~# rc-service modemmanager stop armadillo:~# rc-service ems31-boot restart 2 分ほど待つ armadillo:~# nmcli up gsm-ttyCommModem
armadillo:~# rc-service modemmanager stop armadillo:~# rc-service connection-recover stop armadillo:~# rc-service ems31-boot stop armadillo:~# ems31-power-ctrl off armadillo:~# ems31-power-ctrl on armadillo:~# send-at /dev/ttymxc3 AT^SCFG=\"MEopMode/Factory\",\"all\" echo ems31 armadillo:~# reboot
ログを添付いたしますので、ご確認いただけないでしょうか
| ファイル | ファイルの説明 |
|---|---|
| messages.0.txt |
uen2825
2024年6月24日 13時36分
お世話になります。
armadillo:~# cat /etc/sw-versions base_os 3.19.1-at.4 boot 2020.4-at21 extra_os.a6e-gw-container 2.5.3
armadillo:~# send-at /dev/ttyMux2 ATI1 echo ems31 ATI1 Cinterion EMS31-J REVISION 04.014 A-REVISION 01.001.10
解決策不明の為、A6Eを初期状態にして試しました。
10分毎に通信しています。
21日14:20から動かし22日13：10まで連続運転し、通信できない事はありませんでした。
22日13:20から24日7:50まで電源OFF
24日8:00から電源ONしたところ、何度か通信できない事がありました。
8:00 8:10 8:20 8:30 8:40 OK
8:50 9:00 NG
9:10 OK
9:20 9:30 NG
9:40 OK
9:50 NG
10:00 10:10 OK
10:20 NG
10:30 10:40 10:50 11:00 OK 現在の時間、13:30まで続けてOKです。
時間とmessage行を記載しますので見て頂けないでしょうか
9:30(622行) NG
9:40(1189行) OK
9:50(1640行) NG
10:00(2106行) OK
10:10(2554行) OK
10:20(3001行) NG
10:30(3466行) OK
10:40(3915行) OK
10:50(4362行) OK
11:00(4809行) OK
NTPに接続しないようにしています。
同じ設定をしているつもりで、2台（MEEQ(docomo)、soracom(docomo)）はトラブル無く動作中です。
今上手くいっていないのがMEEQ（KDDI）です。
宜しくお願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| messages.txt |
at_mitsuhiro.yoshida
2024年6月25日 13時29分
吉田です。
NG パターンに関して、
「ModemManagerのデバッグログを有効にする方法」
https://armadillo.atmark-techno.com/howto/mm-debug
の手順を実施して modemmanager のデバッグログを含めた
/var/log/message をご提供いただけないでしょうか。
お手数おかけしますが、よろしくお願いします。
uen2825
2024年6月28日 15時19分
吉田様
お世話になります。
あれから中々現象が発生せず、遅くなり申し訳ございませんでした。
logの中で
おそらく1分くらいで終了している時はLTEが接続できた時。
4分近くかかっている場合はLTEが接続できなかった時と思います。
何か掴めますでしょうか
宜しくお願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| messages.txt |
uen2825
2024年7月4日 18時37分
吉田様
ありがとうございます。
バージョンです。
base_os 3.19.2-at.5 boot 2020.4-at24 extra_os.a6e-gw-container 2.5.3
A6E(MEEQ(KDDI))を手元で10分間隔での送信をしておりました。
AT+CSQで電波強度を確認すると14から16が多いです。
7/4 11:30より2kmほど離れた別の場所に付けたところ、初めの2回は正常に通信できましたが
その後何度と通信できない現象が出ています。
AT+CSQで電波強度を見ると25から29でした。うまく通信できないときは0でした。
以前から、別の場所に持って行くと不調となるマシンで、2日ほど通電しないでおくと同じ症状が出る事もありました。
11:30からのログを添付しますので見て頂けないでしょうか
NTPサーバーへの接続は停止してあります。
| ファイル | ファイルの説明 |
|---|---|
| messages.txt |
uen2825
2024年7月17日 10時56分
お世話になります。
10分インターバルでデータ取得、サーバーへアップロードしています。
以下、直近の履歴です
-- 手順 --
1.AT+CSQ コマンドで電界強度取得、取得できるまで1秒間隔で 10回 ループ
2.サーバーへping、pingが通るまで2秒間隔で 20回 ループ
3.SFTP( paramiko ) でデータアップロード
* 6/26 0:00 ～
OS Ver: base_os 3.19.1-at.4
キャリア: soracom(docomo)
電界強度：20-25
動作: SLEEP 及び shutdown の両ﾓｰﾄﾞとも 問題なく動作
* 7/4 12:00 ～
OS Ver: base_os 3.19.2-at.5
キャリア: meeq(KDDI)
電界強度：27 近辺
動作: SLEEP データ欠損多発( 電界強度取得、ping リトライオーバー )
osのバージョンアップに関係？別フォーラムでご回答頂く。
-- 手順 --
1.AT+CSQ コマンドで電界強度取得、取得できるまで1秒間隔で 20回 ループ <-- 回数変更
2.サーバーへping、pingが通るまで2秒間隔で 20回 ループ
3.SFTP( paramiko ) でデータアップロード
* 7/9 14:50 ～ ( A6E,SIM 変更 )
OS Ver: base_os 3.19.1-at.4
キャリア: meeq(KDDI)
電界強度：30 近辺 ( ANT向き変更 )
動作: SLEEP 電界強度を取得できないことが頻繁に発生
* 7/15 21:10 ～
動作: SLEEP 急にATコマンド、pingとも1回で取得できるようになる、アップロード失敗は1回も無い
* 7/16 16:10～
動作: shutdown 電界強度を取得できないことが頻繁に発生
補足：ANTは外部ANTとして「日本アンテナ製 DP-BRO-AD」使用
前回回答で 通信環境の問題では？ といただきましたが、電界強度、7/15 21:10 以降の動作より
通信環境の問題では無いように思います。
meeq(KDDI) は「Armadillo-IoTゲートウェイ動作確認済みSIM一覧」に無いことより、対応できないという事でしょうか。
また他にチェックする箇所等がございましたらご教授お願いいたします。
at_mitsuhiro.yoshida
2024年7月17日 16時47分
吉田です。
> meeq(KDDI) は「Armadillo-IoTゲートウェイ動作確認済みSIM一覧」に無いことより、対応できないという事でしょうか。
2024年7月17日時点で、公式サイトでは LTE-M は × になっております。
https://support.meeq.jp/hc/ja/articles/360004069275-%E5%88%A9%E7%94%A8%…
at_mitsuhiro.yoshida
2024年4月19日 16時43分
吉田です。
お手数ですが、以下の情報をご提供いただけますでしょうか？
(1) 現象発生時のソフトウェアバージョンと設定内容
取得方法は、FAQ「Armadillo-IoT A6E Cat.M1 モデル: LTEモジュールで通信ができないときには？」
https://armadillo.atmark-techno.com/faq/aiotg-a6e-catm1-lte-doesnt-work
最下部にあります「お問い合わせ時に記載して欲しい情報」を参照ください。
以下の情報をご提供ください。
- Armadillo Base OS のバージョン
- LTE 再接続サービス(connection-recover) を使用していてかつ設定を変更しているのであれば、
/etc/atmark/connection-recover.conf の内容
- 変更しているのであれば、/etc/atmark/ems31-boot.conf の内容
(2) 残っていましたら、現象発生時の Armadillo 側のログ
Armadillo 側の /var/log/message に現象発生時のログが残っていましたら、
現象発生前も含めて添付ください。
推測になりますが、原因として考えられるのは、以下のとおりです。
- ModemManager 自体のバグ
- 間欠動作起床時の動作不具合
- LTE 再接続サービスの設定による再起動
LTE 再接続サービス(connection-recover)に関しては、
2024年3月の製品アップデート
https://armadillo.atmark-techno.com/news/20240326/software-update-aiota…
Armadillo Base OS 3.19.1-at.2 にてワークアラウンドを追加していますので、
これで改善する可能性はあります。