エントリー

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

ページ移動

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

NOAA受信サーバ異常

NOAA受信サーバが停止していた

発生要因は判っているのだけど,なんで?ってことで原因は不明

どうもOSをアップデートしてから期待通り動作しなくなっている

まず発生要因は月2回cronで自動実行している再起動(reboot実行)で,実行後に起動していないと思われる(手動でのrebootは再起するので何らかの事象待ちでの停止ではない)

# crontab -l
20 0 1,15 * * /sbin/reboot
30 0 * * * /srv/predict/pause_nidnight.sh
#20 12 * * 1-5 /srv/predict/pause_daytime.sh

1行目:月2回のreboot

2行目:夜間停止

3行目:昼間停止 → 再起しないので実施していない

なんか仕様が変わったのか?デバイスとの整合性問題なのか?こうゆうのは調査に時間が必要なので困る

次回の4/1まで変更しないでおいて確認することにする

NOAA受信における不思議な現象

上空850kmの衛星から137MHz帯のFM受信だと突き抜ける電離層はもちろん雲や気圧とか何が影響しているのか判っていないのだけど,少なくとも受信角度が高い(つまり上方で短距離)の方が明らかに感度が良くなりそうに思う

しかし,そうでも無いことが先日は起きている(これ

不思議なことに(1日中良好に受信できそうな日に)一番有利なはずの場所からの衛星受信が不可だったのだ

納得いかないので受信データを調べたがまるで受信できていないことが判明したが原因は判らない

受信音声データは3カ月で削除しているため記録しておく

①NOAA15 08:00:56~08:16:02 進行方向(北から南) 最大昇角(64°) 方角(西)

20240313-080056-NOAA15-MCIR-s.png

②NOAA19 09:30:00~09:45:40 進行方向(北から南) 最大昇角(89°) 方角(西)

20240313-093000-NOAA19-MCIR-s.png

③NOAA18 10:59:08~11:14:58 進行方向(北から南) 最大昇角(86°) 方角(東)

20240313-105908-NOAA18-MCIR-s.png

④NOAA15 19:16:42~19:31:52 進行方向(南から北) 最大昇角(61°) 方角(西)

20240313-191642-NOAA15-MCIR-s.png

⑤NOAA19 20:52:06~21:08:01 進行方向(南から北) 最大昇角(70°) 方角(西)

20240313-205206-NOAA19-MCIR-s.png

⑥NOAA18 22:21:18~22:36:57 進行方向(南から北) 最大昇角(75°) 方角(西)

20240313-222118-NOAA18-MCIR-s.png

 

現在使用中のアンテナは耐久性を考えていないので,そろそろ改良も含めた補修が必要かな

NOAA受信システム異常の復旧

3/3~3/4に温度センサー異常でメンテナンス後,NOAA受信システムが異常になっていた

同時にOSのアップデートを実施したためだと思われ調査の結果ようやく復旧

今後も失敗しないよう記録

rtcwake

rtcwakeでメモリーサスペンド後,復帰しなかったため記録がない(3/4~3/5)

→ この件はまだ未解決のため動作停止させている(手動では問題ないので困っている)

rtl-sdr

問題発生後,最初にrtl-sdrの問題でないかと最新のrtl-sdrをDLして再セットアップしたためsoxへのフォーマットエラーとなっていた(3/7~3/8)

$ /usr/local/bin/rtl_fm -f 137.9125M -s 160k -g 48 -p 55 -E wav -E deemp -F 9 - | sox -t wav - NOAA18.wav rate 11025
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Tuner gain set to 48.00 dB.
Tuner error set to 55 ppm.
Tuned to 138232500 Hz.
Oversampling input by: 8x.
Oversampling output by: 1x.
Buffer size: 6.40ms
Sampling at 1280000 S/s.
Output at 160000 Hz.
sox FAIL formats: can't open input `-': WAVE: RIFF header not found
Signal caught, exiting!

User cancel, exiting...
$

現時点での最新版ではパッケージ版と同じ問題が発生するようだ

最新にする必要はなかったので当初セットアップした版数を再度make(waningエラーが多発するが動作は問題なしだった)→ 最新版ではコンパイルエラーは発生しない

gpioset

NOAA受信時LNAの電源をONしているがGPIOに対するコマンドでエラーが発生していたため,rtl_sdrを入れ替える前の受信にて感度不足により画像にできていなかった(3/6~3/7)

$ /usr/bin/gpioset gpiochip1 72=1
/usr/bin/gpioset: error setting the GPIO line values: Invalid argument

GPIOの構成でgpiochip1に接続されていたのがgpiochip0に変わっていた(何故なのか不明)

$ gpiodetect
gpiochip0 [1c20800.pinctrl] (256 lines)
gpiochip1 [1f02c00.pinctrl] (32 lines)
gpiochip2 [axp20x-gpio] (2 lines)
$
(修正)
$ /usr/bin/gpioset gpiochip0 72=1
$ /usr/bin/gpioset gpiochip0 72=0
温度センサー

BMP280を⑤に交換したが温度も異常だったので⑭に変更

IMG_20240303_131935.jpg

しかし同様に正常な温度を取得できていないのでESP8266の問題である可能性がでてきた(⑤のBMP280は単体確認で問題あり⑭は問題なし)

ページ移動

ユーティリティ

検索

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

新着コメント

Re:NOAA受信システム復旧
2025/06/11 from admin
Re:NOAA受信システム復旧
2025/06/11 from とおりすがり
Re:SDRplay社RSP1クローンを購入
2025/05/25 from 匿名希望
Re:Mozilla FirefoxではNHKプラスを再生できない件
2025/05/09 from Donabeyaki
Re:ATS-25を作製する
2025/03/23 from kazu

過去ログ

Feed