satnogs-auto-scheduler,その後 ― 2022/03/01 18:56
スケジューラが2/27日に突然・止まった。 対話的に実行すると，エラーがpass_predictor.pyで発生！した事が判った。 TLEが古いらしい，でも何で?!
2022-02-27 21:21:01,231 - root - INFO - Finding all passes for 651 satellites:
22%|█████████▏ | 146/651 [00:02<00:08, 56.49it/s]
Traceback (most recent call last):
File "./schedule_single_station.py", line 339, in <module>
main()
File "./schedule_single_station.py", line 259, in main
min_pass_duration)
File "/home/pi/.../pass_predictor.py", line 68, in find_passes
sat_ephem.compute(observer)
ValueError: TLE elements are valid for a few weeks around their epoch, but you are asking about a date 365 days from the epoch
ググって対応版を適用したら，スケジューリングが再開した。ここ数日は連続・稼働中なので，もう大丈夫だろう。
ちなみに，問題となったTLEは TIANWANG-1C-TW-1Cので，当該衛星は大気圏再突入済み！だが，TLE取得対象となっている...謎だ。
QMR-KWTをデコード ― 2022/03/07 17:33
SMOG-1 ― 2022/03/09 20:02
デコード結果を（今朝のパスから）BMEにアップロードできなくなった 😲
エラー内容はSSL: CERTIFICATE_VERIFY_FAILED（証明書の検証に失敗）で，現地が朝になったら解消!して，smogcli2でデコードしたファイルが受理された 😌
その他の衛星： VZLUSAT-2をデコード！
openBCMのmakeで悩む ― 2022/03/12 22:30
久し振りにmakeしたら，「ldが互換性のない libcrypt.so をスキップしました」とエラーを吐いたが，libxcrypt-devel-32bitを追加したら解消した。でも，スッキリしない 😒
$ ldd out-x86_64/bcm | grep libcrypt libcrypt.so.1 => /usr/lib/libcrypt.so.1 (0xf7f4e000) $ rpm -qf /usr/lib/libcrypt.so.1 libcrypt1-32bit-4.4.15-2.51.x86_64 $ rpm -ql libcrypt1-32bit | grep libcrypt.so /usr/lib/libcrypt.so.1 /usr/lib/libcrypt.so.1.1.0 $ rpm -ql libxcrypt-devel-32bit | grep libcrypt.so /usr/lib/libcrypt.so $ ls -l /usr/lib/libcrypt.so* lrwxrwxrwx 1 root root 17 5月 7 2021 /usr/lib/libcrypt.so -> libcrypt.so.1.1.0 lrwxrwxrwx 1 root root 17 5月 7 2021 /usr/lib/libcrypt.so.1 -> libcrypt.so.1.1.0 -rwxr-xr-x 1 root root 222604 5月 7 2021 /usr/lib/libcrypt.so.1.1.0
本日の衛星： HO-113で交信。
最近のコメント