My Blog

NOAA-18の受信状態が悪いのかと思っていたら（Sバンド）送信機不良で運用停止になったことを教えていただきました（軌道変更も不可でスペースデブリになるらしい）

更にNOAA-15・19も，6/16 18:00UTCに運用停止になるようです

https://www.ospo.noaa.gov/operations/poes/status.html

既に止まっているようにも思えます

残念ですが，しかたないですね

後継として「Sumomi NPP」が運用されているのですが・・・厳しそう

（2025.6.15）

既に停止したのかと思っていたら，受信用のソフトウェアが途中で止まり受信データが完了していないためエンコード不良となっていた

まもなく停止となるがアップグレードを実施したところシステムダウン

高湿度による不具合か？→ 去年から湿度調整用に炭を入れていたおかげか水気はなく問題なし

μSDカードを取り出してメンテシステムにて復旧

アップグレードの際に途中でダウンしてシステムがsshでログインできない程に破壊されていたためコンソールで実施

（ついでに別件追加）

実は６月に入って不具合が多発していた

１．NOAAシステムの太陽電池充電器の不良

リセットの順序があるので注意

①太陽電池ケーブルを外す

②バッテリーケーブルを外して接続（リセット）

③太陽電池ケーブルを接続

２． ルータの電源端子破損

無線LANに異常があるようだったので電源ケーブルを外してリセットしようとしたところ電源端子が破損して通電しなくなった

無線LANと兼用で内部セグメント（別にDMZとなりうるセグメントはあるがポート制限し機器は未接続）を構成しているため動作しなくなると全て通信できなくなる

なので緊急復旧

設置場所の関係から電源を延長しなければならず，特殊な形状の端子を購入して作製していため同じ構成での復旧は困難で，コンセントーACアダプタの方を延ばして対応

オス側はACアダプタ接続の物で良かったが，メス側には破損したパーツが残っており無理やり押し込んでいる

ルータも冗長構成にしておかないと不味いことになりそうだ

３．NOAAシステムダウン

今回のダウン前のNOAA-18運用停止前にもダウンしていた

この時は電源リセットで復旧したのだが関連性があるのではないかと思われる

まずはμSDカードをddで全バックアップしておいてμSDカードの書き込み不可でないことを確認しバックアップシステムで起動してみる

HDMI接続で起動してみると・・・

画面が進み過ぎで最後の結果しか判らず，何かが読めないように観えるがそれが何なのか判別できない

なのでコンソール出力をチェックするためシリアル接続

U-Boot SPL 2021.10-armbian (Aug 30 2022 - 06:52:13 +0000)
DRAM: 1024 MiB
.
.
.
## Flattened Device Tree blob at 4fa00000
 Booting using the fdt blob at 0x4fa00000
 Loading Ramdisk to 4938a000, end 49fffd8a ... OK
 Loading Device Tree to 0000000049317000, end 0000000049389fff ... OK

Starting kernel ...

IPLは正常でカーネル起動後「login:」となるところが，ここで止まるのでファイルシステムの異常が考えられる

μSDカードをArmbianでマウントして中身を確認

$ sudo mount /dev/sdb1 /mnt
mount: /mnt: mount(2) system call failed: Structure needs cleaning.
$

ところがマウント不可なので，しかたなくfdckで修正を実施

$ sudo fsck /dev/sdb1
fsck from util-linux 2.37.2
e2fsck 1.46.5 (30-Dec-2021)
ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
fsck.ext4: Group descriptors look bad... trying backup blocks...
armbian_root was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 7 has illegal block(s). Clear<y>? yes
Illegal block #5088 (4290772992) in inode 7. CLEARED.
Illegal block #5089 (4294967295) in inode 7. CLEARED.
Illegal block #5090 (4294967295) in inode 7. CLEARED.
Illegal block #5091 (4294967295) in inode 7. CLEARED.
Illegal block #5092 (4294967295) in inode 7. CLEARED.
Illegal block #5093 (4294967295) in inode 7. CLEARED.
Illegal block #5094 (4294967295) in inode 7. CLEARED.
Illegal block #5095 (4294967295) in inode 7. CLEARED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: +(1211030--1211263)
Fix<y>? yes
Free blocks count wrong for group #0 (13461, counted=14561).
Fix<y>? yes
Free blocks count wrong for group #1 (7476, counted=14962).
Fix<y>? yes
Free blocks count wrong for group #2 (9650, counted=12460).
Fix<y>? yes
.
.
.
Free blocks count wrong for group #10 (1502, counted=1873).
Fix ('a' enables 'yes' to all) <y>? yes
Free blocks count wrong for group #11 (7528, counted=4604).
Fix<y>? yes
.
.
.
Free blocks count wrong for group #68 (1038, counted=7812).
Fix<y>?
armbian_root: e2fsck canceled.

armbian_root: ***** FILE SYSTEM WAS MODIFIED *****

$

結構酷いようなので途中で止めてauto yesで再実施

$ fsck -y /dev/sdb1
fsck from util-linux 2.37.2
e2fsck 1.46.5 (30-Dec-2021)
armbian_root was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #68 (1038, counted=7812).
Fix? yes

Free blocks count wrong for group #69 (2334, counted=26287).
Fix? yes
.
.
.
Directories count wrong for group #128 (1, counted=0).
Fix? yes

Free inodes count wrong (2074853, counted=2072197).
Fix? yes


armbian_root: ***** FILE SYSTEM WAS MODIFIED *****
armbian_root: 93659/2165856 files (0.9% non-contiguous), 4163715/7556096 blocks

$ fsck -y /dev/sdb1
fsck from util-linux 2.37.2
e2fsck 1.46.5 (30-Dec-2021)
armbian_root: clean, 93659/2165856 files, 4163715/7556096 blocks
$ sudo mount /dev/sdb1 /mnt

マウントは可能になる

$ ls -l /mnt
total 2880
lrwxrwxrwx 1 root root 7 8月 26 2022 bin -> usr/bin
drwxr-xr-x 3 root root 4096 11月 1 00:20 boot
-rw------- 1 root root 3993600 8月 31 2022 core.1525
drwxr-xr-x 2 root root 4096 8月 31 2022 dev
drwxr-xr-x 123 root root 12288 11月 1 00:20 etc
drwxr-xr-x 3 root root 4096 9月 27 2022 home
lrwxrwxrwx 1 root root 7 8月 26 2022 lib -> usr/lib
drwx------ 2 root root 16384 8月 31 2022 lost+found
drwxr-xr-x 2 root root 4096 8月 26 2022 media
drwxr-xr-x 2 root root 4096 8月 26 2022 mnt
drwxr-xr-x 2 root root 4096 8月 26 2022 opt
drwxr-xr-x 2 root root 4096 8月 26 2022 proc
drwx------ 7 root root 4096 6月 9 22:02 root
drwxr-xr-x 3 root root 4096 8月 31 2022 run
lrwxrwxrwx 1 root root 8 8月 26 2022 sbin -> usr/sbin
drwxrwxr-x 2 root root 4096 8月 31 2022 selinux
drwxr-xr-x 5 root root 4096 10月 10 2022 srv
drwxr-xr-x 2 root root 4096 4月 18 2022 sys
drwxrwxrwt 2 root root 4096 8月 31 2022 tmp
drwxr-xr-x 11 root root 4096 8月 26 2022 usr
drwxr-xr-x 12 root root 4096 9月 27 2022 var
$ sudo file /mnt/core.1525
/mnt/core.1525: ELF 64-bit LSB core file, ARM aarch64, version 1 (SYSV), SVR4-style,
 from '/sbin/init', real uid: 0, effective uid: 0, real gid: 0, effective gid: 0,
 execfn: '/sbin/init', platform: 'aarch64'

$

ルートの構成は問題ないようだが中身がどうかは不明

日付は古いがcoreファイルがあったので確認するとinitの異常が過去に起きていたようだ

再度バックアップシステムで起動

Starting kernel ...

[ 8.834251] pps-gpio pps@0: failed to map GPIO to IRQ: -22
[ 9.353592] jack: irq plug-in

Armbian 24.2.1 jammy ttyS0

pine64a login: root
パスワード:
 ____ _ __ _ _
| _ \(_)_ __ ___ / /_ | || |
| |_) | | '_ \ / _ \ '_ \| || |_
| __/| | | | | __/ (_) |__ _|
|_| |_|_| |_|\___|\___/ |_|

Welcome to Armbian 24.2.1 Jammy with Linux 6.6.16-current-sunxi64

System load: 30% Up time: 0 min
Memory usage: 18% of 919M IP: 192.168.24.33
CPU temp: 35°C Usage of /: 55% of 29G
RX today: 58.9 KiB

.
.
.

root@pine64a:~# shutdown -h now
[ 84.686546] reboot: Power down

※）GPIOのエラーは非接続ため発生している

正常に起動したのでNOAA受信システムに戻して再起動，午後からのNOAA受信できるようにして，しばらくは動作観察となる

ファイルシステム異常の原因は不明だが，fsckで復旧したのはラッキーであった

天候が良くないので今朝のNOAA画像を確認しようとしたら先日から動作していなかった

SSHが反応しないのでシステムダウン発生の模様，どうやら15日のシステム再起動で起動しなかったようだ

遠隔による再起動で復旧しないためμSDカードの異常も考えられる

天候が良くないので先にμSDカードを取り外した

調査するための準備もあるため確認は保留中

LNAの変更で改善されないようなのでバンドパスフィルターを確認

ケースがボロボロなので触ると破壊してしまうと思い避けていた（ポリプロピレン，ポリエチレンは紫外線に弱い）

今回は駄目ならアンテナごと交換するため破壊しても良いので（それでも）慎重に開けてみると・・・

錆てた（あっさり）

防水と下から排水するよう開けていたのだけど，錆の箇所から考えると甘かったようだ（ラップで包んでおけば良かった）

とりあえずは対策として直結にする

ゲインダウンが減るので受信機のゲインは最大指定からオートに変更

表面だけに見えるが中身もヤバそう（ネジが錆ていて簡単には開きそうにない）

この対策を施したのが29日の10:00前で，先日の２つ目（NOAA19 10:00移行の分）から適用となる

直後の結果は良好になったが午後の画像が妙なので音を聴いてみたところアマチュア局が混信していたことが判明

過去だと24日にも混信していたのとアマチュア局のキャリアが無い時はNOAAの受信ができていることで28日からの対応による影響ではないと考える

混信は近所にあるアマチュア局であることを突き止め「警告」しに行ったのだが，まともに取り合わないようなので「四国総合通信局（旧電波監理局）」へ相談

本来アマチュア局でTVI，BCIなど電波障害が発生した場合は直ちに電波の発射を停止しなけれならない義務がある

少なくとも調査するなど準ずる行動をとらないとならない

ルールを厳守できない無線局は消えるべきだ

（追加）

10/28に「四国総合通信局」から調査結果の電話があったが都合で出れなかったので折り返したところ担当不明で確認できなかった

再度連絡すると言われたが，最近は発生していないので重要でないなら連絡不要にした

追加の連絡が無いので，おそらく混信の確認はできなかったと思われる