エントリー

カテゴリー「NOAA」の検索結果は以下のとおりです。

NOAA受信システムの不具合が解決に向かう

3月初旬から発生していたNOAA受信システムの不具合がようやく解決

システム停止不具合

4/11の午後午後から受信不良が発生し次の日にシステム停止していることが判り,リセット(遠隔電源OFF/ONによる)したが復旧せず,H/Wの異常も考えられるがおそらくSDカードが寿命を含め不良となったのではないかと推測

SDカードを外して予備の代替え機でコンソールメッセージを確認するとbootの途中で止まる

メッセージからはディスク異常のようだ

IMG_20240412_140143.jpg

Ubuntuで確認してみるとR/Wマウント不可でR/OマウントしかできないのでSDカードの異常である

IMG_20240412_140155.jpg

最悪は再度システム構築になるが,まずは新しいSDカードへデッドコピーして回復させてみる

$ sudo dd if=/dev/sdc of=dsk.dd bs=1000k
dd: '/dev/sdc' の読み込みエラー: 入力/出力エラーです
14025+1 レコード入力
14025+1 レコード出力
14361694208 bytes (14 GB, 13 GiB) copied, 451.302 s, 31.8 MB/s
$ ls -l
合計 14025096
-rw-r--r-- 1 root root 14361694208 4月 12 14:23 dsk.dd

(再度)
$ sudo dd if=/dev/sdc of=dsk2.dd bs=1000k
30535+1 レコード入力
30535+1 レコード出力
31268536320 bytes (31 GB, 29 GiB) copied, 994.838 s, 31.4 MB/s
$ ls -l
合計 44560780
-rw-r--r-- 1 root root 14361694208 4月 12 14:23 dsk.dd
-rw-r--r-- 1 root root 31268536320 4月 12 14:44 dsk2.dd
hero@Core-i3:/srv/noaa/disk$

(new sd)

$ sudo dd if=noaa_sd.dd of=/dev/sdc bs=10000k
3053+1 レコード入力
3053+1 レコード出力
31268536320 bytes (31 GB, 29 GiB) copied, 1446.44 s, 21.6 MB/s
$

なんとか出来上がったので再度予備機で確認してファイルシステムの異常を修正(丸ごとバックアップしておく)

SDカードを戻すと正常に起動し本日まで問題なく動作

システムの更新が問題だったかと思われたが,どうやらSDカードの異常が原因だったようだ

同時期に発生したため原因の解明に時間が掛かってしまった

受信感度の低下

NOAA画像が生成されない事が多くなった

受信音を聴いてみると受信感度が低下しているようで,アンテナ,ケーブル,バンドパスフィルター,LNA,受信機のどれかに問題があるのだろうが,何故か問題無い時もあるため予想ができない

とりあえずアンテナが風化して老朽化しているのは判っているので新しいアンテナの作製準備は行っている

また受信機を取り出し確認してみたが問題はなく,LNAの電源供給も大丈夫そうであった

IMG_20240408_102036.jpg

が,LNAでの電圧を計測してみると4.7Vであり,まさかと思うが5Vになるように調整しなおしてみた

(調整後のLNA電圧)

IMG_20240408_104119.jpg

(電源制御ボードの出力電圧:後で5.166Vに降圧)

IMG_20240408_104230.jpg

これが当たりで,受信感度の低下による受信不能が少なくなった

LNAの適正電圧幅が狭いのであろうか?

新しいアンテナの作製はパーツが揃っているので行う予定である

NOAA受信システムの不具合

ケース内温度監視異常

2日前にセンサー(BMP280)を入れ替えて測定した気温が,別途測定した気温と同じだったので問題ないと思って様子みていたら,夜間になっても変化しないのでまだ解決していないようだ(ケースに入っていて温度差が少ない季節といっても変化が無いのは異常)

そこでESP8266+BMP280で単体試験を行うことにした

もしこれで正常なら基板のどこかに不具合があると考えられる

IMG_20240402_143637.jpg

テストプログラムを作り動作させたところ正常な気温を計測(指で温めて変化があるのかもチェック)

念のためピンの接続などの変化(必要ないピンのGND接続やアドレス変更)を加えてみたが問題なかった

再度基板を外しセンサーピンの導通確認を行ったところGNDピンの接触不良があるようで結合部分を触れてみると外れていることが判明

IMG_20240402_143546.jpg

これで原因もはっきり判り半田し直して解決

確認用に使用した②のBMP280をそのまま使用することにしたので再度変更

IMG_20240402_143518.jpg

経過は少ないが気温の変動があるので問題なさそうだ

SS20240402_01.png

不規則なシステム停止

4/1のシステムリセット(reboot)は問題なく実行されたことを先日確認

Sleepの復帰異常と同じで何度かのアップデートで問題なくなった感じもある

Sleepモードからの復帰異常

少なくとも一週間はSleepモードから正常に復帰している

NOAA受信感度

音声データから受信感度の良し悪しが受信日や時間によって大きく変化することが判っている

差が激しいので何らかの問題があるとも考えられるのだが原因不明

もう少し安定するように試案を検討中である

ケース内温度監視異常の対処

NOAA受信感度の向上でゲイン調整していたら,調整とは関係ないけどしばらく受信がおかしくなっていたのが本日は回復している

昨日,受信画像が良くないので受信データを聴いてみると受信感度が悪すぎて画像化できなかったことが判り,アンテナの改良が必要なのかと考えていたところである

受信感度の方は今後改良することにして,気温が上がってきたこともあり先に温度監視異常を調査

結果はセンサ(BMP280)の異常で,新しく調達したBMP280に交換することで解決(㉑を使用)

IMG_20240331_154526.jpg

中古のBMP280でもarduinoでの単体確認では正常に温度が得られているのでESP8266の問題も考える必要があったが新品使用で問題なくなったので良しとする

ただ結果的には解決できたが対処過程において問題を発生させあまり宜しくはなかった(おかげでプラスになった事もある)

対処

単体試験するために電源制御ボードを外す

IMG_20240331_133419.jpg

基板上の(裏表)目視点検で問題なし

IMG_20240331_133430.jpg

電源12VなのにXH端子を使用していたのでVH端子を追加し,確認用の電源として12Vバッテリーを繋いだところ動作しない(動作は電源投入で気温が送信されるのが無いことから判断)

おかしいなと思い各所の電源チェックしたところXH端子の12V以外の5V・3.3Vは通電していない

ここで・・・とんでもないことにバッテリーのプラスマイナスを間違えて接続していた事に気付く

やってしまった・・・全部やり直しかとESP8266とBMP280を外し影響範囲の確認に入る(できればESP8266は助かってって欲しいところ)

12Vじゃあ全部飛んだかとESP8266とBMP280への3.3Vを追っていたのだけど回路がない

回路図を追って,あれ?(回路図にミスがあったので今回は修正している),12VはDCDCで5Vにして3.3Vに降圧していたことに気付く

もしかして助かったか?とDCDCのみ交換

IMG_20240331_144754.jpg

DCDCのみ破壊で他は無事だった(ラッキーだ)

(改修した回路図:DCDCの入出力が逆になっていたのと電源関係を判り易くした)

outsideEPower_回路図.png

(注)SCL(IO5-SCK),SDA(IO4-SDI),SDO(=GND:アドレス指定),CSB(非接続でも良し)

気温取得のアルゴリズムも変更して別のESP8266に書き込み交換

(旧)気温を200ms間隔で10回取得して10回分の平均を使う

(新)気温を200ms間隔で10回取得して降順に並び替え中央値を使う

最終的にESP8266も交換することになったが使用していたESP8266は異常ではない

またケースの密閉性が良いためかESP8266の損傷はまったくなかった

NOAA受信システムの不具合確認中

運用開始して1年ちょっと経過

最近発生している不具合と検討したい件があり合間を見て確認しているが時間も掛かりそうなので整理

不規則なシステム停止

次項のSleepモードの件と同じと考えていたがログの解析からシステムダウンが稀に発生している

2024/3/3以降の頻度が高いことからアップデートの影響と考えられる

直接の原因が不明のため,こまめにアップデートを確認している状態

CPUボードの異常も考えられ予備機で確認も予定(もう秋月での在庫が無くなっているので多発するようで別ボードが必要になると辛いな)

Sleepモードからの復帰異常

不規則で夜間運転の時間指定サスペンドが復帰しない

電力供給が行われる昼間のサスペンドは停止中

週2回位で発生しているようだが不規則なため原因不明

現状は朝方に起動チェックを行い停止しているようなら遠隔電源制御で復帰させている

最悪サスペンドしなければ対応可能

ケース内温度監視異常

BMP280の異常と考え交換したが解決せず,制御ボードの再試験が必要なのだが天候の問題で実施できてない

ログを参照すると異常が発生した日は徐々に計測温度が上昇しておりデジタルとしては不可解な現象である

ss20240303.png

温度監視で影響するのはFAN制御であるが,いまのところ高温になることがないため助かっている

BMP280は新規に調達して動作を確認,通番として㉑~㉔を付けた

IMG_20240303_135809.jpg

室内気温:21.9(℃)
室外気圧:1009(hPa)

= 21
TEMP : 24.37 DegC PRESS : 1009.21 hPa HUM : 0.00 %
TEMP : 23.75 DegC PRESS : 1009.29 hPa HUM : 0.00 %
TEMP : 23.27 DegC PRESS : 1009.36 hPa HUM : 0.00 %
TEMP : 22.97 DegC PRESS : 1009.37 hPa HUM : 0.00 %
TEMP : 22.79 DegC PRESS : 1009.29 hPa HUM : 0.00 %

= 22
TEMP : 23.82 DegC PRESS : 1008.90 hPa HUM : 0.00 %
TEMP : 23.37 DegC PRESS : 1009.06 hPa HUM : 0.00 %
TEMP : 22.99 DegC PRESS : 1009.11 hPa HUM : 0.00 %
TEMP : 22.71 DegC PRESS : 1009.09 hPa HUM : 0.00 %
TEMP : 22.53 DegC PRESS : 1009.16 hPa HUM : 0.00 %

= 23
TEMP : 22.91 DegC PRESS : 1010.27 hPa HUM : 0.00 %
TEMP : 22.74 DegC PRESS : 1010.31 hPa HUM : 0.00 %
TEMP : 22.54 DegC PRESS : 1010.35 hPa HUM : 0.00 %
TEMP : 22.41 DegC PRESS : 1010.34 hPa HUM : 0.00 %
TEMP : 22.32 DegC PRESS : 1010.32 hPa HUM : 0.00 %

= 24
TEMP : 23.09 DegC PRESS : 1010.37 hPa HUM : 0.00 %
TEMP : 22.91 DegC PRESS : 1010.35 hPa HUM : 0.00 %
TEMP : 22.80 DegC PRESS : 1010.29 hPa HUM : 0.00 %
TEMP : 22.70 DegC PRESS : 1010.34 hPa HUM : 0.00 %
TEMP : 22.63 DegC PRESS : 1010.32 hPa HUM : 0.00 %
NOAA受信感度の向上

「rtl_fm」より「SDRSharp」や「HDSDR」で受信した方が感度が良いように思われる

なので,改良されているかもしれない最新の「rtl_fm」を使いたいが「sox」との組み合わせでは動作しない(以下)

「sox FAIL formats: can't open input `-': WAVE: RIFF header not found」

※) soxのオプション指定で対処できるのか?試してみたが期待通りにならない (追加:2024.03.24)→ 対処できた(下記)

そこで「rtl_fm」の旧版とソースを比べてみると「-E wav」が無くなっていることが判明

ならばということで最新版に「-E wav」を追加したところ上記のエラーは無くなったがまともな音ではなかった(つまり駄目)

音から判断するにサンプリングレートが異なるようなのだが対処が不明で暫く考えることになる

数日して「sox」がヘッダーを見ても8000Hzでしか受けていないことが判り,「rtl_fm」の出力レートと「sox」の受信レートを指定することで解決

(例)rtl_fm -f 92.6M -s 192k -r 48k -g 48 -p 55 -E wav -E deemp -F 9 - | sox -r 48000 - x.wav rate 11025

ようはオプション指定の意味を理解していなかったってことだ(-s はHWのサンプリングレートで,-r がrtl_fmから出力するサンプリングレートとなる)

→ 「sox」で11025に変換しているのは「rtl_fm」で直接「WXtoimg」が認識できる形式にできないため

ここで新旧rtl_fmを(ぎりぎり受信できる遠距離FM局で)受信確認していみたところ聞き取り易いとか感度の変化は無い

次にステレオ対応で感度が良いらしい「softfm」を試行しようとしたが元が既に閉鎖されていたので派生で障害対応との「ngsoftfm」を試してみる

情報が少ないので開発者の公開サイト(https://github.com/f4exb/ngsoftfm)を参照

$ git clone https://github.com/f4exb/ngsoftfm

$ sudo apt-get install cmake pkg-config libusb-1.0-0-dev libasound2-dev libboost-all-dev

$ sudo apt-get install librtlsdr-dev
$ sudo apt-get install libhackrf-dev
$ sudo apt-get install libairspy-dev
$ sudo apt-get install libbladerf-dev

$ mkdir build
$ cd build
$ cmake ..

$ make -j4

$ sudo make install

しかしライブラリ等の不整合によりコンパイルは以下のとおりエラーとなる

$ make
[ 28%] Built target sfmbase
[ 42%] Built target sfmrtlsdr
[ 57%] Built target sfmhackrf
[ 71%] Built target sfmairspy
Consolidate compiler generated dependencies of target sfmbladerf
[ 78%] Building CXX object CMakeFiles/sfmbladerf.dir/sfmbase/BladeRFSource.cpp.o
In file included from ngsoftfm/include/BladeRFSource.h:26,
from ngsoftfm/sfmbase/BladeRFSource.cpp:29:
ngsoftfm/sfmbase/BladeRFSource.cpp: In constructor ‘BladeRFSource::BladeRFSource(const char*)’:
ngsoftfm/sfmbase/BladeRFSource.cpp:96:54: error: invalid conversion from ‘bladerf_channel’ {aka
‘int’} to ‘bladerf_channel_layout’ [-fpermissive]
96 | if ((status = bladerf_sync_config(m_dev, BLADERF_MODULE_RX, BLADERF_FORMAT_SC16_Q11, 64,
8192, 32, 10000)) < 0)
| ^~~~~~~~~~~~~~~~~
| |
| bladerf_channel {aka int}
/usr/include/libbladeRF.h:2625:58: note: initializing argument 2 of ‘int bladerf_sync_config(bladerf*, bl
aderf_channel_layout, bladerf_format, unsigned int, unsigned int, unsigned int, unsigned int)’
2625 | bladerf_channel_layout layout,
| ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
make[2]: *** [CMakeFiles/sfmbladerf.dir/build.make:76: CMakeFiles/sfmbladerf.dir/sfmbase/BladeRFSource.cpp.o
] Error 1
make[1]: *** [CMakeFiles/Makefile2:197: CMakeFiles/sfmbladerf.dir/all] Error 2
make: *** [Makefile:136: all] Error 2
$

armbianではライブライの不整合もあるかもしれないのでrasbianとamd64 ubuntu 22.04 LTSでもコンパイルしてみたが同じ

ソースの修正は一筋縄では出来そうにないし「rtl-sdr」を使用する場合においては関係ない部分なのでコメントアウトしてコンパイルを完了させた

以下のコマンドラインでFM受信できている

$ softfm -t rtlsdr -M -c freq=92600000,gain=48.0,agc -R - | aplay -f S16_LE -r 48000 -D plughw:1

受信時の微調整データが文字出力されているのでサスペンドして「rtl_fm 」と比較

$ rtl_fm -f 92.6M -s 192k -r 48k -g 48 -p 55 -E wav -E deemp -F 9 - | aplay -D plughw:1

こちらも受信の差が感じられなかった(残念)

NOAAの受信ができるかどうかは未確認,調整して実施予定

(追加:2024.03.24)

soxのオプション指定方法がやっと判った(-t で嵌った)

これで「-E wav」が無くても動作可能

grainはautoでも問題なさそうなので修正

$ rtl_fm -f 92.6M -s 192k -r 48k -p 55 -E deemp -F 9 - | sox -t raw -r 48000 -e signed -b 16 -c 1 - out.wav rate 11025
or
$ softfm -t rtlsdr -M -c freq=92600000,gain=auto,agc -R - | sox -t raw -r 48000 -e signed -b 16 -c 1 - out.wav rate 11025

※)受信周波数と出力ファイル名は確認用,rateはNOAA用

sox -r 48000 -e signed -b 16 -c 1 in.raw out.wav
-r 48000 rate
-e signed sign bit
-b 16 bits
-c 1 channels(1: mono, 2: stereo)
sox -t raw -r 48000 -e signed -b 16 -c 1 - out.wav
-t raw stdin format

注)soxで入力ファイル名を指定する場合は「.raw」でないと入力エラーとなる

「rtl_fm」と「softfm」の受信比較(rateは48k)

(rtl_fm)

(softfm)

試しに以下の下側(青い方)の受信機でも試してみたが上側の方が(はっきり判るくらい)感度が良い

IMG_20240323_200013.jpg

ページ移動

ユーティリティ

検索

エントリー検索フォーム
キーワード

過去ログ

Feed