StargazR

Proxmoxの非特権LXC上にJellyfinでメディアサーバーを構築する (QSV HW Transcoding)

Mon, 01 Dec 2025 00:00:00 GMT

経緯

AmazonのブラックフライデーセールでFire TV Stick 4K Plusを買いました。
そこで、NAS上の動画ファイルをFire TV Stick経由で再生できるようにメディアサーバーを構築することにしました。
今回は無料でハードウェアトランスコードにも対応しているJellyfinを採用しました。

既存のNASセットアップ

現在、N100ミニPC上にProxmoxを入れ、Proxmox上のVMでTrueNAS Scaleを走らせてNASとして運用しています。
NAS用のHDDはVMにPCIe passthroughでSATAコントローラーごと渡しています。

Jellyfinサーバー環境は以下のように構築することにしました。

Proxmox上にJellyfinのLXCを構築 (iGPU passthroughでJellyfinでHWトランスコードを利用可能とする)
ProxmoxホストにNASの共有フォルダをマウント
ProxmoxホストからJellyfin LXCに共有フォルダをbind mount

Jellyfinサーバー環境の構築

Jellyfin LXCの作成

Jellyfin LXCの作成にはProxmox VE Helper-Scriptsを利用させてもらいます。
Proxmoxホストのshellでインストールスクリプトを実行し、ウィザードに従ってLXCを構築します。
途中でVAAPIデバイスを自動でマウントするかどうか聞かれるので、yesにしておきます。

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/jellyfin.sh)"

LXCへのNASフォルダマウントの準備

LXCができたら、LXCのshellでNASフォルダをマウントする準備をします。
参考：https://forum.proxmox.com/threads/tutorial-unprivileged-lxcs-mount-cifs-shares.101795/
ユーザーグループlxc_shares（gid:10000）を作成し、jellyfinユーザーをlxc_sharesグループに追加します。

groupadd -g 10000 lxc_shares
usermod -aG lxc_shares jellyfin

LXCをシャットダウンします。

ProxmoxホストへのNASフォルダのマウント

ProxmoxホストにNASフォルダマウント用ディレクトリを追加します。

mkdir -p /mnt/lxc_shares/nas_rwx

/etc/fstabにNASフォルダマウントの設定を追加します。
smb_usernameとsmb_passwordはNASのSMB接続用IDとパスワードです。

{ echo '' ; echo '# Mount CIFS share on demand with rwx permissions for use in LXCs (manually added)' ; echo '//NAS/nas/ /mnt/lxc_shares/nas_rwx cifs _netdev,x-systemd.automount,noatime,uid=100000,gid=110000,dir_mode=0770,file_mode=0770,user=smb_username,pass=smb_password 0 0' ; } | tee -a /etc/fstab

NASフォルダをProxmoxホスト上にマウントします。

mount /mnt/lxc_shares/nas_rwx

Jellyfin LXCへNASフォルダをbind mount

LXCの設定ファイルを編集し、Proxmoxホスト上の/mnt/lxc_shares/nas_rwxをLXC上の/mnt/nasにbind mountします。
なおLXC_IDはJellyfinのLXCコンテナ番号(e.g., 101)。
ro=1は読み取り専用オプションなので不要な場合は取る。

{ echo 'mp0: /mnt/lxc_shares/nas_rwx/,mp=/mnt/nas,mountoptions=noatime,ro=1' ; } | tee -a /etc/pve/lxc/LXC_ID.conf

LXCを起動し、/mnt/nasのアクセス権がlxc_sharesグループに設定されていることを確認します。

root@jellyfin:~# ls -l /mnt/
total 0
drwxrwx--- 2 root lxc_shares 0 11月 29 14:44 nas

あとはJellyfinの管理画面を開いて各種設定をすればOKです。
プレイバック→トランスコーディングからハードウェアアクセラレーションの設定をします。
当方の環境ではQSVを使うので、ハードウェアアクセラレーション：Intel Quicksync (QSV)、QSVデバイス：/dev/dri/renderD128。

HWトランスコードしようとすると再生できない場合

基本的には上記の手順により非特権LXCコンテナ上でHWトランスコードが利用できるようになるはずなのですが、うまくいかない場合はGPUデバイスのパーミッション設定の誤りの可能性があります。
Jellyfinのプロセスはjellyfinユーザーとして実行されるため、jellyfinユーザーのグループに対してパーミッションが設定されていない場合、JellyfinがGPUにアクセスできません。
私が構築した際も/dev/dri/renderD128のパーミッションが間違っていました（PVE Helper-Scriptsのバグ？）。

LXC上で/dev/dri/のパーミッションを確認します。

root@jellyfin:~# ls -l /dev/dri/
total 0
crw-rw---- 1 root video  226,   1 12月  1 21:10 card1
crw-rw---- 1 root render 226, 128 12月  1 21:10 renderD128

card1のグループがvideo、renderD128のグループがrenderになっていない場合は、Proxmoxのコンテナ設定が間違っています。
その場合、まずLXCコンテナ上でのvideo、renderのgidを確認します。

root@jellyfin:~# cat /etc/group | grep -e video -e render
video:x:44:jellyfin
render:x:993:jellyfin

この場合、videoのgidが44、renderのgidが993です。
LXCをシャットダウンします。

Proxmoxホストで/etc/pve/lxc/LXC_ID.confを開き、dev0とdev1のgidが上記の通りになっているか確認、間違っていれば修正します。

dev0: /dev/dri/card1,gid=44
dev1: /dev/dri/renderD128,gid=993

私の場合はこれで問題なくHWトランスコードできるようになりました。

おわりに

特殊な環境なのでこの情報を必要とする人が存在するか怪しいですが、もしもこの情報が誰かのお役に立ちましたら幸いです。

天体写真のFITS保管用にNASをチューニングする

Sat, 29 Nov 2025 00:00:00 GMT

NAS

3.5インチドライブが2つ搭載でき、2.5GbEが2ポートあるN100搭載ミニ(?)PCをNASとして使っています。

NASの簡易スペック

ホストOSにProxmox、ゲストOSにTrueNAS Scale
CPUはN100、PL1 10W、PL2 15W
2x 2.5GbEでSMB Multichannel、最大5Gbps
1x 8TB HDD (WD80EAAZ)
- ファイルシステムはZFS
RAM32GB
- TrueNAS VMに24GBを割り当て
- zfs_dirty_data_maxは16GBに設定
1x 256GB SATA SSDをL2ARCに（128GBをオーバープロビジョニングに確保）

ストレージデバイスがHDD1本なので、書き込み速度はシーケンシャルでも最大200MB/s程度（ディスクが空の場合）、ランダム書き込みではもっと遅くなります。
ところがZFSの場合、書き込み時にRAM上のdirty pageに一時的にデータを貯めてからまとめてディスクに書き込むので、ランダム書き込みでもシーケンシャルに近い速度を出すことができ、dirty pageを拡張すればある程度のサイズまでは見かけ上ディスクの上限を超えた速度で書き込むことも可能です。
さらにZFSは透過圧縮の機能があるので、例えば圧縮率が1.5倍の場合、ディスクから200MB/sで読み出しつつリアルタイムで解凍、見かけ上300MB/sで読み出しなんてこともできます。
ちなみに天体写真のFITSは比較的圧縮のよく効くタイプのファイルです。

今回はPCからNASに天体写真のFITSを書き込む場合のパフォーマンスをいろいろ比較して、ZFSのチューニングをしました。

パフォーマンステスト

テストデータは69.4GB分のASI533MCおよびASI2600MC-PのFITSデータ。少しjpgが混じってる。
Windows11のPCからNASに書き込み。書き込みにはFastCopyを使用。
PC、NASともに2x 2.5GbEのSMB Multichannelで最大5Gbps (600MB/s程度)。

compression=?

ZFSの透過圧縮では、圧縮形式や圧縮率を選択できます。
今回は以下の4パターンでパフォーマンスを比較しました。
基本的にはCPU負荷は1<2<3<4、圧縮率は4>3>2>1。

lz4: 最もCPU負荷が軽い。圧縮率は低い。
zstd-fast: zstdの高速版。zstdより圧縮率は低い。
zstd-1: zstd圧縮率1。
zstd-3: ZFSで圧縮オプションをzstdに指定したときの標準圧縮率。

書き込み速度および書き込み時間

平均書き込み速度 (MB/s)

lz4	zstd-fast	zstd-1	zstd-3
138.0	191.8	175.0	82.3

最速だったのはzstd-fast。次点がzstd-1。
lz4はCPU負荷は軽いが圧縮率が低いので、ディスク書き込みがボトルネック?。
zstd-3はCPU負荷がボトルネック?。

書き込み時間 (seconds)

lz4	zstd-fast	zstd-1	zstd-3
540	388	425	905

書き込み速度と同じなので省略。

圧縮率およびディスク上のサイズ

圧縮率

lz4	zstd-fast	zstd-1	zstd-3
1.19	1.32	1.48	1.51

もちろん最良はzstd-3で次点がzstd-1。
ただしzstd-1とzstd-3はほとんど差がない。

ディスク上のサイズ (GiB)

lz4	zstd-fast	zstd-1	zstd-3
59.2	53.1	47.4	46.6

lz4とzstd-1では10GiB以上の差。
zstd-fastとzstd-1でも5.7GiBの差。

圧縮形式の決定

書き込み速度と圧縮率のバランスからcompression=zstd-1に決定。
CPUがもっと強ければzstd-3あるいはそれ以上の圧縮率を選択可能でしょうが、N100の場合zstd-1からzstd-3にすると圧縮率がそれほど変わらない割に書き込み速度が圧倒的に下がるのでダメそうです。

recordsize=?

ZFSでは、データセットごとにrecordsize (実際にディスクに書き込み時の最大ブロックサイズ)を指定でき、圧縮率や速度に影響します。
当方のNASでは動画などのメディアファイル用に基本的にrecordsize=1Mで運用していますが、FITS用のデータセットではいくつに設定するのがよいかを調べました。

書き込み速度および書き込み時間

平均書き込み速度 (MB/s)

recordsize	lz4	zstd-fast	zstd-1	zstd-3
1M	138.0	191.8	175.0	82.3
512K			190.6
256K			184.0
128K			180.7

512Kにすると、zstd-1の書き込み速度が1Mで最速だったzstd-fastに匹敵するレベルに改善。

書き込み時間 (seconds)

recordsize	lz4	zstd-fast	zstd-1	zstd-3
1M	540	388	425	905
512K			391
256K			405
128K			412

圧縮率およびディスク上のサイズ

圧縮率

recordsize	lz4	zstd-fast	zstd-1	zstd-3
1M	1.19	1.32	1.48	1.51
512K			1.47
256K			1.47
128K			1.44

一般にrecordsizeを小さくすると圧縮率が落ちるとされているが、zstd-1の場合256Kまではさほど変わらない様子。

ディスク上のサイズ (GiB)

recordsize	lz4	zstd-fast	zstd-1	zstd-3
1M	59.2	53.1	47.4	46.6
512K			47.5
256K			47.5
128K			48.1

256Kまでは誤差。128Kにするとやや大きくなる。

recordsizeの決定

速度が改善し圧縮率も落ちない、recordsize=512Kで決定。

もう少し小さいデータセットの場合

上記のテストでは書き込み量を約70GBというZFSのdirty page (16GBに設定)から大幅にあふれる量に設定しました。
しかし、実際には1回の撮影データ量はそこまで大きくないので、書き込み量がもっと小さい場合も検証してみます。

合計書き込み量別書き込み速度 (MB/s)

	70GB	30GB	20GB	15GB	10GB	5GB
zstd-1/512K	190.6	222.5	262.0	292.2	381.9	477.9

書き込み量が小さいと速度が上がります。15GB未満ならSMB Multichannelなしの2.5GbEでは飽和するほどの速度が出てます。　　ただ、FITSの場合ネットワークがボトルネックになるほどの書き込み速度はでないみたいです。
大きな動画ファイルを書き込むような場合、合計14GB程度までは600MB/s（2x 2.5GbEのネットワークが飽和する速度）に張り付きます。

結論

というわけで、上記のテストからFITS保管用のZFSデータセットではcompression=zstd-1、recordsize=512Kがよさそうということがわかりましたので、このパラメータで運用しようと思います。

ZWO EAFのハンドコントローラを自作した

Sat, 11 Oct 2025 00:00:00 GMT

光軸調整などの際、いちいちPCに接続せずにフォーカサーを操作したい、だけど純正ハンドコントローラは高い、ということで簡単そうだったこともあり自作してみました。
<br> 以下のページを参考にしました。 ::linkcard[https://www.williamliphotos.com/pages/diy-eaf-handcontroller]{title="DIY Hand Controller for ZWO Electronic Automatic Focuser" desc="Will Li Photography"}

必要なもの

モーメンタリスイッチ2個
トグルスイッチ1個
4.7kΩの抵抗1個
3.5mm4極ミニプラグケーブル1本

スイッチ、抵抗は手元にあったので、4極ミニプラグケーブルだけAmazonで入手。 <br> 要するに、4極ミニプラグの先端からT,R1,R2,Sと置くと、以下のような動作になるようです。

R1とSを短絡するとDOWN (IN)
R2とSを短絡するとUP (OUT)
T-S間が短絡だと高速モード
T-S間が4.7kΩだと低速モード

ケースは3Dプリンタで適当に作成。
はんだ付け汚いけど動けばよし（笑）

<br> フタして完成！動作確認も全く問題なし。

DIYハーモニック赤道儀⑨：15cmニュートン搭載実験

Sun, 28 Sep 2025 00:00:00 GMT

晴れたのでDIYハーモニック赤道儀への15cmニュートン搭載実験のためプチ遠征してきた。
メイン鏡筒にSW Quattro 150p、メインカメラにASI2600MC Pro、ガイド鏡にSVBONY SV165 40mm、ガイドカメラにASI120mm mini。
三脚はVixenのASG-CB90三脚、ピラーはなし。特に転倒しそうな気配もなくウェイトレスで使用できた。
搭載機材の重量は測ってないけど、確実に6kgは超えてるかな？
<br> いくつかの対象を撮ってきたけど、とりあえずM45をペタリ。 15cmニュートン搭載での撮影自体は問題なくできた。
ただ、やはり極軸ウェッジ部分の剛性が圧倒的に不足している感じで、ちょっと揺れるし極軸合わせが非常に難しい。
<br> あとこれはたぶん鏡筒側の問題なのだが、星の形が変だし光条が割れているように見える。
3Dプリンタ自作した主鏡押さえ兼主鏡マスクを付けてるのだが、たぶんネジを締めすぎなのと形状の改良が必要かも。　　 ASIAIRのオートフォーカス時に振動のせい？か星が三角の軌跡みたいになってそもそもピントがちゃんと合ってるかも自身がないが…
<br> 今後は主鏡押さえ兼主鏡マスクを改良しつつ、剛性の高そうな極軸ウェッジをアリエクで物色する予定。

DIYハーモニック赤道儀⑧：実地試験成功！？

Sat, 13 Sep 2025 00:00:00 GMT

仕事の都合と天気が噛み合わず、ずっとDIYハーモニック赤道儀の実地試験ができていませんでした。
今週平日の夜ですがほんの少しだけ晴れ間があったので、自宅ベランダから撮影テストできました。

スペックまとめ

項目	内容
駆動系	ハーモニックドライブ（減速比100:1）+プラネタリギア（減速比10:1）<br>総減速比1000:1
モーター	NEMA17ステッピングモーター（400steps/rev）1/16マイクロステップ駆動
モーター解像度	0.29arcsec
最大駆動速度	1.5degree/s（対恒星時360倍速）
電源電圧	DC20V（PDトリガーケーブル使用）
本体重量	計6.4kg<br>赤経体2.8kg（OnStepXコントローラ含）<br>赤緯体3kg<br>極軸ウェッジ0.6kg

プラネタリギアの減速比が大きすぎて、最大駆動速度がちょっと低くなってしまった。とはいえ実用上はそこまで気にならない範囲。

テスト機材セットアップ

項目	内容
撮影鏡	SW EVOGUIDE 50EDII（FL242mm）+ASI533MC+QBP3フィルター
ガイド鏡	SVBONY SV165 40mm（FL170mm）+ASI120MM mini
制御システム	ASIAIR Plus-256G

極軸合わせ

南向きベランダのため、ASIAIRのAll-Sky Polar Alignmentで極軸合わせ。
もう少し極軸追い込みたかったけど、極軸ウェッジが剛性不足な感じでこれくらいで妥協。 EVOGUIDEでAll-Sky PAがうまく動作しなかったのでガイド鏡で行った。焦点距離も合ってるはずだし原因がよくわからなかった。

ガイド状況

月も出ていてあまり時間もなかったので、ごく短時間ですがオートガイドさせてみました。
以下は一番良かった時ですが、RA/DECともにガイドエラーが0.5秒角前後、総ガイドエラーも0.6秒角台。
ガイドグラフも暴れておらずいい感じ？ただガイド鏡のピントが甘かったか。 <br> 30秒露出でしばらくライブスタッキングさせてみた。視界内にあまりいい被写体がなくて、M15でテスト。総ガイドエラーは1秒角前後。ただDECが少し暴れ気味か？
<br> 全体的には大成功と言えるでしょうか？

今後の予定

15cm反射+冷却カメラを搭載してテストしたい。ウェイトレスでslewできることは確認済み。
しっかり長時間露出した場合の精度確認。
PEC学習させたらどうなるか？（ハーモニック赤道儀ではPECはあまり有用ではないとは言われるが）

DIYハーモニック赤道儀⑦：組み立て完了

Sat, 05 Apr 2025 00:00:00 GMT

組み立て完了

なんとか組みあがりました。多治見コネクタの極小はんだカップのはんだ付け難しすぎる。
重量は赤経体・赤緯体それぞれ2.6kgくらいです。汎用のアルミフレームとブラケットで組んでるのでどうしても重量かさみますが、それでもSXD2に比べればだいぶ軽いですね。分割もできるし。

動作確認

動きました！ <iframe width="560" height="315" src="https://www.youtube.com/embed/QV8CSpVlzIU?si=PbUkTH-_TCKtelfM" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

定格0.9Aのモーターに対して、現状DRIVER_IRUN=400、DRIVER_IGOTO=600ですがDC20Vだと2deg/sでslewできる。DC12Vだと脱調する感じ。
できれば3deg/sでslewできるようにしたいけど厳しいか。プラネタリギアボックスは5:1でもよかったかも。
いずれにせよOnStepの設定はまだまだ追い込まないといけないですね。

蓋とかOnStepホルダーとか

最近3Dプリンタ（Bambu Lab A1 mini）を買ったので、赤経体・赤緯体後部の蓋とかOnStep筐体のホルダーなんかは3Dプリントで作りました。
図らずもOnStep筐体の長さがアルミフレームの長さにドンピシャで助かった…
赤緯体には一応ウェイトシャフトが取り付け可能。これはSUSのアルミフレームのアクセサリパーツで、本来は高さアジャスターとかを取り付けるためのフットベース。 ::linkcard[https://www.monotaro.com/p/2173/8298/]{title="SFK-51A フットベース 4040 2S 1個 SUS(エスユーエス) 【通販モノタロウ】" desc=""} 真ん中にM12の穴が開いており、ここにAZ-GTiにも使えるM12Φ20のウェイトシャフトをねじ込むことで、Vixenのウェイトが使えます。

今後の予定

OnStep設定の追い込み。
ようやく春になったので、近いうちに実地テストに行きたいですね。

Cloudflare Pagesのデプロイ終了後にエッジキャッシュをパージする

Tue, 18 Mar 2025 00:00:00 GMT

当ブログではCloudflareのエッジキャッシュTTLを次のように設定しています。

html（パスが/で終わる）: 1日
画像やcss、jsなど: 14日

記事を追加したりコメントが投稿された時自動デプロイが走りますが、エッジキャッシュが残ったままだと更新内容が見えない可能性があります。ですので、Pagesのデプロイ終了時にエッジキャッシュをパージしたい。 Pagesのプロジェクト設定にありそうなものですが、調べた限りではそんな機能はなさそう？不思議です。

というわけでやり方がわかったのでその備忘録です。

ビルド後にエッジキャッシュパージ

Pagesのビルドコマンドに&&でチェーンしてCFのAPIを叩くスクリプトを呼べばよい。

scripts/cf-purge.js

<zone id>はCFのダッシュボードで調べる。
<API token>はCFのAPIトークン。必要な権限はゾーン-キャッシュパージ-パージ。

const api =
  'https://api.cloudflare.com/client/v4/zones/<zone id>/purge_cache'
const body = JSON.stringify({ purge_everything: true })
const res = await fetch(api, {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    Authorization: 'Bearer <API token>',
  },
  body: body,
})

res.ok
  ? console.log('Purged CF edge cache.\n')
  : console.error('Failed to purge CF edge cache.\n')

package.json

スクリプトを追記。
ターミナルからpnpm cf-purgeでキャッシュパージできるようになるのも地味に使えるかも。

"scripts": {
    "cf-purge": "node scripts/cf-purge.js",
  },

Pagesのビルドコマンド変更

ビルドコマンドを変更する。

pnpm build && pnpm cf-purge

これでビルド終了時にエッジキャッシュがパージされるようになる。
だが正直Pagesの設定として公式に用意してほしい… <br><br>

おまけ　"デプロイ後"にエッジキャッシュパージ

少し面倒だがGitHub Actionsを組み合わせれば一応可能。

.github/workflows/cf-purge.yml

CF Pagesのデプロイを待つアクションが公開されているので使わせてもらう。 ::github{repo="WalshyDev/cf-pages-await"} レポジトリのActions secretsに'CF_API_TOKEN'を作成しCFのAPIトークンを入れておく。 <account ID><zone id>はCFのダッシュボードで調べて入力。<project>はPagesのプロジェクト名。

name: Purge CF Cache
on: 
  repository_dispatch:
    types: [cf-pages-deploy]
  
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      deployments: write
    steps:
    - name: Await CF Pages
      uses: WalshyDev/cf-pages-await@v1.3.1
      with:
        apiToken: ${{ secrets.CF_API_TOKEN  }}
        accountId: '<account id>'
        project: '<project>'
        githubToken: ${{ secrets.GITHUB_TOKEN }}
    - run: |
        curl -X POST "https://api.cloudflare.com/client/v4/zones/<zone id>/purge_cache" -H "Authorization: Bearer <CF-API-TOKEN>" -H "Content-Type: application/json" --data '{"purge_everything":true}'

あとはcf-purge.jsと同じように、GitHub APIのhttps://api.github.com/repos/{owner}/{repo}/dispatches からcf-pages-deployイベントを発火させればよい。その方法は省略。

AstroブログにCloudflare D1を利用したシンプルなコメント機能を付けた

Sun, 16 Mar 2025 00:00:00 GMT

この度、当ブログをWordpress on 自宅鯖 through Cloudflare Tunnelから、Astro on Cloudflare Pagesに移行しました。
その際、AstroおよびテンプレートFuwariにコメント機能がなかったので、Cloudflare D1を利用したシンプルなコメント機能を作りました。
本記事はその備忘録です。

:::caution 筆者は素人です。したがって間違った点が多々あると思いますので、お気を付けください。なお具体的な修正コメント歓迎いたします。 :::

はじめに

Astroブログ（および静的ブログ）にコメント機能を付けるための既存のソリューションについて検討しました。代表的なものにはDisqusやgiscusなどがあると思いますが、それぞれ以下の理由で採用しませんでした。

Disqus：ごちゃついた見た目が嫌い。採用サイトを見たことがあるが使いづらい。
giscus：Githubログイン必須で匿名コメント機能がない。特に日本ではわざわざログインしてまでコメントしようという人はまずいないと思われる。

というわけで目的に合ったものがなかったため、自分で作ることにしました。
せっかくサイトをCloudflare Pagesでのホストにしたので、コメント機能もサーバーレスで構築したいところ。
CloudflareにはD1というサーバーレスDBがあるので、Cloudflare Workersと組み合わせてうまいことすれば作れそうと思いました。

システムの概要

コメントシステムはAstroから独立したAPIとします。
これによりサイトがCloudflare以外のサービスでホストされていたとしても利用できます。

都合がよいことにCloudflareのチュートリアルにD1を使ってコメントAPIを作るというものがあるので、これを改変して利用します。

::linkcard[https://developers.cloudflare.com/d1/tutorials/build-a-comments-api/]{title="Build a Comments API · Cloudflare D1 docs" desc="In this tutorial, you will learn how to use D1 to add comments to a static blog site. To do this, you will construct a new D1 database, and build a JSON API that allows the creation and retrieval of c"}

Astroブログは、ビルド時にAPIからコメントを取得して、コメントもページの一部として静的にページ生成します。

動作の流れ

コメントが投稿された際の動作は以下のような流れになります。

AstroブログのフォームからコメントAPIにjsonでPOST
コメントAPIは受信内容をバリデーションしてDBに格納、その後Astroブログのデプロイフックを叩く
AstroブログはコメントAPIからGETでコメントを取得、コメントをページの一部として静的にビルド <br><br>

コメントAPIの構築

テーブルの構造を変更。

DROP TABLE IF EXISTS comments;
CREATE TABLE IF NOT EXISTS comments (
  id integer PRIMARY KEY AUTOINCREMENT,
  author text NOT NULL DEFAULT 'Anonymous',
  body text NOT NULL,
  post_slug text NOT NULL,
  post_date text NOT NULL DEFAULT CURRENT_DATE
);
CREATE INDEX idx_comments_post_slug ON comments (post_slug);

コメント取得はslugごとではなく、全件一括でJSONを返すようにします。

app.get('/api/<任意のパス：コメント取得用>', async (c) => {
	const { results } = await c.env.DB.prepare(
		`
      select * from comments
    `
	).all();
	return c.json(results);
});

投稿時もAPIエンドポイントのパスにslugを含めるのをやめ、jsonの中にpost_slugを含めてPOSTにするように変更。

app.post('/api/<任意のパス：コメント投稿用>'>, async (c) => {
	var { author, body, slug } = await c.req.json();

	/*
    バリデーションとか実施
    */

	// 改行を<br>に置換しておく
	body = body.replace(/(?:\r\n|\r|\n)/g, '<br>');

	const { success } = await c.env.DB.prepare(
		`
      insert into comments (author, body, post_slug) values (?, ?, ?)
    `
	)
    .bind(author, body, slug)
    .run();

	// Cloudflare Pages用
    // Deploy Hookを叩く
	await fetch('<Deploy HookのURL>', {
		method: 'POST',
	});

	if (success) {
		c.status(201);
		return c.text('Created');
	} else {
		c.status(500);
		return c.text('Something went wrong');
	}
});

これでコメントAPIの方はひとまず完成。

Astroコードの改変

まずコメント取得用のライブラリを作成。
記事ごとにfetchしてるとビルド時間に悪影響があることが容易に予想できるため、一括で取得した後componentからの要求に応じてslugでフィルターして返す。

const response = await fetch(
  '<コメント取得用APIエンドポイントのURLまたはパス>',
)
if (!response.ok) throw new Error('[Comments] Comments cannot be fetched.')
const comments = await response.json()
console.log(`[Comments] Fetched ${Object.keys(comments).length} comments.`)

export type comment = {
  id: number
  author: string
  body: string
  post_slug: string
  post_date: string
}

export function getComments(slug: string): comment[] {
  return comments.filter((comment: comment) => {
    return comment.post_slug === slug
  })
}

次にコメントのAstroコンポーネントを作成。
コメントはサニタイズ（brのみ許可）後URLをリンクに変換しています。

---
import { getComments } from '@/library/comments'
import type { comment } from '@/library/comments'
import sanitizeHTML from 'sanitize-html'
const { slug } = Astro.props
const comments = getComments(slug)
const hasComment = comments.length > 0

function replaceURLWithLink(text: string) {
  const urlRegex =
    /https?:\/\/[-_.!~*\'()a-zA-Z0-9;\/?:\@&=+\$,%#\u3000-\u30FE\u4E00-\u9FA0\uFF01-\uFFE3]+/g
  return text.replace(
    urlRegex,
    url => `<a href="${url}" target="_blank">${url}</a>`,
  )
}
---

<div id="comments_container">
  <div id="comment_title">
    Comments
  </div>
  {
    hasComment &&
      comments.map(
        (comment: comment) => (
          <div id="comment">
            <div id="comment_header">
              <div id="comment_author">
                {comment.author}
              </div>
              <div id="comment_date">
                {comment.post_date}
              </div>
            </div>
            <div
              id="comment_body"
              set:html={replaceURLWithLink(sanitizeHTML(comment.body, { allowedTags: ["br"], allowedAttributes: false }))}
            ></div>
          </div>
        ),
      )
  }
  {
    !hasComment && (
      <p>
        No comments yet.
      </p>
    )
  }

  <form id="comment_form" action="<投稿用APIエンドポイントのURLまたはパス>">
    <input
      type="text"
      name="author"
      placeholder="Name"
      maxlength="20"
      /><br>
    <textarea
      name="body"
      placeholder="Message"
      maxlength="1000"
      required
    ></textarea><br>
    <input type="hidden" name="slug" value={slug} />
    <button id="submit" type="button"> Submit </button>
  </form>
</div>

<script>
  const form = document.forms[0];
  const button = document.getElementById("submit") as HTMLInputElement;

  button?.addEventListener("click", async function () {
    button.disabled = true;
    const formData = new FormData(form);
    if (formData.get("body") === "") {
      button.disabled = false;
      return;
    }

    const data = JSON.stringify(Object.fromEntries(formData));

    const res = await fetch(form.action, {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
      },
      body: data,
    });

    if (res.ok) {
      form.body.value = "";
    }
    button.disabled = false;
  });
</script>

あとは、[...slug].astroから作成したコンポーネントを呼び出せばOK。

<D1Comments slug={entry.slug} />

一応これで超シンプルなコメント機能が実装できました。
ただこのままだとAPIエンドポイントが脆弱なので、適宜保護する必要があります。例えばCloudflare Turnstileのpre-clearanceモードで投稿時のfetch()リクエストに対してマネージドチャレンジをかけられるようにする、など。

::linkcard[https://blog.cloudflare.com/integrating-turnstile-with-the-cloudflare-waf-to-challenge-fetch-requests/]{title="Integrating Turnstile with the Cloudflare WAF to challenge fetch requests" desc="By editing or creating a new Turnstile widget with “Pre-Clearance” enabled, Cloudflare customers can now use Turnstile to issue a challenge when a page’s HTML loads, and enforce that all valid respons"}

なおこの方法の場合、追加するコードのうち1つ目のscriptタグにはis:inlineを指定しないとうまく動作しませんでした。

また、/api/*にマネージドチャレンジをかけるとビルド時のコメントフェッチも失敗するので、WAFのカスタムルールでコメントフェッチ時はマネージドチャレンジをスキップするような設定も必要かもです。たとえば任意のリクエストヘッダとかクッキーで認証キーを指定するとか。

DIYハーモニック赤道儀⑥：フランジプレート完成

Mon, 03 Mar 2025 00:00:00 GMT

JLCCNCで注文したアルミ製フランジプレートが届きました。

両方8mm厚のアルミA6061材です。表面処理はマットブラックアルマイト仕様にしてみました。アリミゾアダプタの方は、M8穴2か所をタップ立てしてもらいました。価格はハーモニックホルダー（左）のほうが2個で$48.82、アリミゾアダプタ（右）のほうが2個で$26.02、送料が$12.92で、合計が日本円で￥13,926でした。この価格でワンオフのアルミ削り出しパーツが作れるということに驚きます。ちなみに汚れっぽいのが見えますが、私が触ったときについたものです。

OpenSCADで面取り形状にする方法など調べたりもしましたが、結局のところ基本的な造形をOpenSCADでやった後、FreeCADのOpenSCADワークベンチで読み込み、FreeCAD上で面取りしたり図面に起こしたりすることにしました。BOSL2のライブラリを使った状態だとFreeCADでうまく読み込めなかったので。今回初めて3DCADを触りましたが、これも楽しいですね。

ハーモニックドライブをはめるΦ48の窪みと、プラネタリギアボックスをはめるΦ25の穴だけ±0.1mmの公差を入れています。JLCCNCだと、指定できる一番厳しい公差が±0.05mmまでです。±0.05mmにするとかなり高くなるが±0.1mmだとあまり変わらなかったので、穴寸法を+0.1mmしたうえで±0.1mmの公差を入れる感じにしました。

アルミフレームとボルト類の準備が終わってないのでまだ組めませんが、とりあえずハーモニックドライブやギアボックスのはまり具合だけ確かめてみたところ、いい感じです。

DIYハーモニック赤道儀⑤：OnStepX完成

Thu, 27 Feb 2025 00:00:00 GMT

OnStepXが完成しました。

最小限の機能でよくてコンパクトにしたかったので、基板はMiniPCB2。ステッパードライバーはTMC5160。ファームウェアはOnStepX v10.24c。

とりあえず無負荷ではSLEW_RATE_BASE_DESIRED 3.0で脱調なし。モーターは定格0.9Aで400steps/revの17HM15-0904S、プラネタリギアボックスは減速比10:1のEG17-G10。このギアボックスはお高いだけあって極めてスムーズで静か。

オリジナルのMiniPCB2からのカスタマイズ点は2点。
①WeMos D1 miniの代わりにD1 miniサイズのESP32-WROOM-32Eを取付
②32KBのFRAMモジュールを追加実装

①のESP32について、Amazonなどで「D1 mini ESP32」を検索すると、ピンヘッダが2列でD1 miniのフォームファクタよりやや大きいやつが出てきます。しかし、OnStepの公式Wikiによると「MiniPCB2はWeMosソケット周りのスペースに余裕がないのでESP32は取付できません。」と書いてあります（試してはいない）。私はAndroidユーザーかつ現地でのPCとの接続でもWiFiよりBluetoothの方が使い勝手がいいので、このD1 miniソケットにはBluetooth SPP用のチップを付けたいのです。

一応、秋月のRN-42ピッチ変換モジュールは工夫すれば付けられなくもなさそうでしたが、今更Bluetooth 2.1はちょっとな…（しかも高いし）ということでネットサーフィンの結果、「ESP32 in true D1 Mini form factor」を謳うパブリックドメイン基板を発見、これを使ってESP32を取り付けました。JLCPCBAで裏面の表面実装部品の実装込みで注文できて助かります。

USBシリアルは載ってないので、5ピンピンヘッダからの書き込みになります。なおこの基板の3.3VレギュレータはLDOタイプではないので、MiniPCB2のD5はバイパスしないと（多分）電源電圧が足りない。

あとは以下のプログラムを書き込んでD1 miniのソケットに刺せばBluetooth SPP対応OK、後日WiFiにしたくなった時もSmart Web Serverを書き込めば対応可能。
ちなみに以下のコードはSerialToSerialBTのサンプルコードをちょっと書き換えただけ。

#include "BluetoothSerial.h"

String device_name = "OnStepX-HARMONIC";

// Check if Bluetooth is available
#if !defined(CONFIG_BT_ENABLED) || !defined(CONFIG_BLUEDROID_ENABLED)
#error Bluetooth is not enabled! Please run `make menuconfig` to and enable it
#endif

// Check Serial Port Profile
#if !defined(CONFIG_BT_SPP_ENABLED)
#error Serial Port Profile for Bluetooth is not available or not enabled. It is only available for the ESP32 chip.
#endif

BluetoothSerial SerialBT;

void setup() {
  Serial1.begin(9600, SERIAL_8N1, 16, 4);
  SerialBT.begin(device_name);  //Bluetooth device name
}

void loop() {
  if (Serial1.available()) {
    SerialBT.write(Serial1.read());
  }
  if (SerialBT.available()) {
    Serial1.write(SerialBT.read());
  }
  delay(20);
}

②のFRAMについては興味本位。Teensy 4.0はエミュレートされたEEPROMの容量が小さく、PECバッファの容量を増やそうとしたときにエラーが出るという情報があったのでその対策でもあります。使ったのはたぶんAdafruit用であろうと思われるI2C 32KB FRAM MB85RC256Vモジュール。アリエクで600円くらい。パスコンとSCL・SDAのプルアップ抵抗も載ってるので使い勝手がよいです。別に32KBもいらないのですが、8KBのMB85RC64モジュールは売ってませんでした。

そのままだとデカいので、A1とA2の間で基板をカット。あとFRAMチップの右側4端子（上からVSS (GND)、A2、A1、A0）およびピンヘッダ部分のGNDとWPを短絡。これでVDD、SCL、SDA以外がすべてGNDに落ちます（データシートによれば内部プルダウンがあるみたいなので、この短絡加工は必要ないかもしれません）。MiniPCB2の右下、本来はPECセンサーコネクタを取り付けるスペースがありますが、ここには3.3Vも来てて上記基板カットしたモジュールがぴったり収まります（VCC～SDAまでの5ピンにピンヘッダを実装）。あとはTeensy 4.0裏面のGPIO24（SCL）、25（SDA）にワイヤーをはんだ付けして引き出し、モジュールのSCL、SDAと接続します。

OnStepX側では、Config.hに以下を追記。

#define HAL_Wire Wire2

またNV_DRIVERをNV_DEFAULTからNV_MB85RC256に変更。

#define NV_DRIVER NV_MB85RC256

これで問題なくFRAMを認識しました。なお初回起動時はFRAM初期化のためかなり時間がかかります。Extended.config.hでDEBUGをVERBOSEに設定するとシリアルモニタで経過状況が確認できます。

私はFRAMにしましたが、同じI2CバスにZS-042モジュールを接続すれば、RTC追加とEEPROMの拡張が両方できるみたいですね。

その他、MiniPCB2製作にあたっては、DCジャックが鬼門でした…

DCジャックの取付パターンは丸穴3か所のJP1なんですが、この丸穴が絶妙に小さくて一般的な基板取付用DCジャック（例えばマル信無線電機のMJ-179PHとか）が刺さりません。秋月で売ってるDCジャックで取り付け可能なのはこれです。

DIYハーモニック赤道儀④：フレーム加工

Fri, 21 Feb 2025 00:00:00 GMT

アルミフレームの加工を進めています。

加工といっても大部分は端面にM5タップを立てるだけですが…フレーム1本につき穴が4か所、これが8本あるので32個の穴にタップを立てる必要があります。ハンドタップでやってるのでまあまあ大変。

当初は8本すべて同一の4面溝フレームを使うつもりだったのですが、底面だけ3面溝のフレーム（SF-20･40･1F）に変更することにしました。

こういう1面だけ溝がないフレームです。

寸法こんな感じなんですが、この真ん中の中空部分の幅12mmというのが実に都合よくて、アリガタプレートとモーターの接続端子を固定できそうなんです。

まずアリガタの固定について、真ん中にM6の長孔が空けてあるアリガタが多いです。そこで使うのが、M6の四角ナット。私が今使っているアルミフレームはSUS製のものなんですが、この四角ナットは別のメーカーのアルミフレーム用のものみたいです。コイツの幅が10mmなので、12mm幅の部分に入れてやればナットが空回りせず外側からM6でアリガタを固定できるというわけです。

次にモーターの接続端子には多治見無線のワンタッチコネクタEPRC05を調達しました。そのSF型レセプタクルEPRC05-RB5Fが差込部径9mmなので、12mm幅の部分に取り付けできそうです。

問題はこの3面溝フレーム、モノタロウで取り扱いがなかったんですよね…しかたないのでAmazonで200mmのを入手して手ノコで切断を試みたんですが、まっすぐ切るのが難しすぎる！1本だけ奇跡的に成功しましたが2本は全くダメ、1本もビミョーな仕上がりになってしまいました。

そこで、ダメ元でモノタロウに取り扱い希望出してみたら、なんと数日で定尺品と10mm単位カット品を取り扱いしてくれることになりました！モノタロウ神。MONOTARO IS GOD. 早速買います。

切るのに失敗したフレームをテスト加工。アリエクで調達した100mmのアリガタでちょうどいい感じ。

DIYハーモニック赤道儀③：フランジプレートの設計

Wed, 12 Feb 2025 00:00:00 GMT

OpenSCADでフランジプレートの設計中…

だいたい設計が固まってきました。8mm厚のアルミ製になる予定です。

OpenSCADでchamfer（面取り）形状にする方法に手こずりましたが、BOSL2というライブラリでうまくできることがわかりました。FreeCADに取り込むときにうまくいかないので、ChamferはFreeCAD上でやることにしてやめました。

中心部の4つ穴がプラネタリギアボックスの固定用、外周4辺に2つずつある穴がアルミフレームに固定するためのM5ボルト穴、その合間に60度間隔で6つ空いている穴がハーモニックドライブの固定用M4ボルト穴。

裏面はこんな感じ。今のところ、ハーモニックドライブの固定ボルトにはそこそこトルクを掛けたいなと思っていて、裏面にM4の鉄製四角ナットをはめ込めるように作ってみています。アルミのネジ穴の強度をあまり信用できないと思っているためです…

DIYハーモニック赤道儀②：設計

Sat, 11 Jan 2025 00:00:00 GMT

DIYハーモニック赤道儀について、年末年始の時間を使って設計を考えていました。

15cmニュートンを載せたいので、筐体の強度もそこそこ必要、できれば金属で筐体を作りたいところ。

いろいろ作例の情報収集をしていたところ、工業用アルミフレームを使った作例を見つけました。この作例では、20角のアルミフレーム（20x20）と3Dプリントパーツで構成されています。

::github{repo=polvinc/DHEM}

先の作例ではアルミフレームは全て20x20のものでしたが、20x40のフレームに統一すればもっとシンプルに、少ない部品点数で作れそうな気がします。使う予定のNEMA17モーターは42x42mmなので、20x40のフレームを四方にピッタリ並べてしまうと内部空間が40x40で収まりませんが、アルミフラットバーとかで作った5mmくらいのスペーサーを挟んで固定するようにすれば、内部空間50x50でちょうどよい感じにできそう。

この方針はよさそうです。何しろアルミフレームは安い。例えば、モノタロウで売っているSUS製の20x40アルミフレーム（なんと10mm刻みでカット済みのものが売っている！）は、L=120mmで1本154円（税別）、L=150mmで1本206円（税別）。赤経体と赤緯体を分割式にするとして、片方に4本ずつ、計8本買ったとしても、合計2,000円もかかりません。プラスして必要なアングルブラケットやTナット（50個入り1,870円を2セットで十分足りる）などを含めても、余裕で1万円未満に収まりますね。しかも側面の溝を使って無加工でいろいろ（アリガタとか）固定できるという利点も。

ただし、3DプリントやCNCでピッタリの筐体を作るのに比べるとフレームの厚みがあるのでやや嵩張ります。とはいっても、1辺が20x4+5x2=90mm、かつ四隅はフレームがないので十分コンパクト。

あとはモーターとハーモニックドライブを固定するフランジプレートと、出力面にタカハシ規格のアリミゾを取り付けるためのアダプタが必要です。

OpenSCADでおおざっぱに作ってみたイメージ図がこんな感じ。

端子類はバックプレートに取り付け。プラネタリギアードステッパーの長さが95mmくらいなので、フレームの長さは赤緯体は120mmくらい、赤経体は基板内蔵するなら+40～50mmくらい？

フランジプレートとフレーム側面のアングルブラケットでの固定で強度は十分と思われるので、端子類が付くバックプレートは3Dプリント製でよさそうですね。

高度ウェッジは、アルミフレームの側面にアリガタをつければ手持ちのスカイメモS微動雲台のコピー品っぽいやつを流用できます。

こうして考えてみると、フランジプレートさえ作れればほぼゴールですね。JLCCNCあたりでアルミをCNCフライス加工で作ってもらうか？ほかに必要な加工はフレーム端面のタップ穴とフラットバーの穴あけ程度。これは自分でできますね。

2段か3段のOnStep基板を自作すれば、赤経体に内蔵することもできそう…
内側の溝を使ってウェイトシャフト取付用の板付きナットとかも取付できそう…

もう少し考えてみます。

DIYハーモニック赤道儀①：中国製ハーモニックドライブ

Sun, 29 Dec 2024 00:00:00 GMT

この度DIYハーモニックドライブ赤道儀のプロジェクトを始めました。

年の瀬に中国から謎の荷物が着弾…

グリスですごいことになってますが…

こいつは中国製のZXS17というカップタイプのハーモニックドライブ（減速比1:100）です。 ::linkcard[https://s.click.aliexpress.com/e/_oFSgUZh]{title="Nema17 23ステップ4060 80mm用ヒューマノイドロボットアーム,カップタイプのフランジプレート付きハーモニックドライブ,サーボモーター - AliExpress 13" desc="Smarter Shopping, Better Living! Aliexpress.com"}

冬の間に機材が生えてくるというのはこの界隈あるあるらしいですが、KENさんのブログに触発されていろいろ情報収集していたところ、ハーモニックドライブ+プラネタリギアードステッパーの組み合わせなら意外と簡単に作れちゃいそうじゃね？となり、気づいたらポチっていました。

アリエクの商品ページより引用。各種寸法はHDS社製のCSF-17-100-2UHと互換性があるようです。商品種類は「ZXS17 For 40mm Servo」を選択。ウェーブジェネレータのインプットシャフトが、For 42mm StepだとΦ5mmキー無し、For 40mm ServoだとΦ8mmキー有りになる様子。

送料無料で割引が効いて2個で￥26,961、1個￥13,481と超激安でした。使い物になるか不安ですが、これを使った作例があったので買ってみました。

ウェーブジェネレータのインプットシャフト穴の仕様がいくつかあって、今後StepperOnlineの8mmキー有プラネタリギアボックスを使おうと思っているので、届いたブツの穴径が注文通り8mmキー有シャフト用かだけ確認しておきました。

ステッパーモーターを回せないと話が始まらないので、まずはOnStepXコントローラから製作予定。

AZ-GTi改造②：サブアリミゾ装着

Sun, 24 Nov 2024 00:00:00 GMT

ネジが届いたのでM8と1/4"のネジ穴を使ってガイド鏡用のアリミゾを装着しました。

前回の改造（AZ-GTiアリミゾ交換）はこちら。

ホームセンターで買ってきた5mm厚のゴム板で段差を解消して取り付け。

ファインダー用だと思い込んで買ったのにノーマルサイズのアリミゾでした。なんかでかいなとは思ってましたが…取り付けるときになって初めて気づきました。ちなみにこれは1200円くらい。

というわけでうちのAZ-GTiは謎のダブルアリミゾ仕様になりました。

まあファインダーアリミゾを付けたアリガタをかませばファインダー規格の鏡筒も載せられるのでよしとしましょう…

AZ-GTi改造：アリミゾ交換

Thu, 21 Nov 2024 00:00:00 GMT

AZ-GTiのアリミゾをアリエクで買ったキットで交換しました。

アリエクの独身の日セールでAZ-GTiのアリミゾ交換キットをゲットしました。価格は送料込み3600円くらいでした。激安。

早速交換後の画像を。

中華品質なのでバリ・傷は多少ありましたが、作りはまあ悪くない感じです。ちなみに上から落とし込みはできないタイプ。

一応リンクはこちらですが、同じものが届くとは限らないので注意。

::linkcard[https://ja.aliexpress.com/item/1005007192009386.html?src=ibdm_d03p0558e02r02&sk=&aff_platform=&aff_trace_key=&af=&cv=&cn=&dp=&aff_short_key=]{title="Sky-Watcher AZ-GTI 赤道ダブテール溝修正ディスク Xinda AZ-GTI セオドライト非破壊クランプダブテール溝 - AliExpress 1420" desc="Smarter Shopping, Better Living! Aliexpress.com"}

Celestron Telescope And Accessories Storeというショップですが、セレストロンの公式セラーなのでしょうか？

アリエクではこれのほかにも回転ベースの外周部が波型のタイプも売ってましたが、コイツを選んだのには理由があります。商品画像のアリミゾ金具の側面にネジ穴が開いているのが載っていて、この穴を使っていろいろ悪さができそうだと思ったからです。

商品ページには製品寸法とか一切書いてないので届いてみるまでわかりませんでしたが、小さいほうが1/4インチ、大きいほうがM8でした。謎の組み合わせです。

とりあえずガイド鏡用のファインダー規格アリミゾでも取り付けてみるつもりです。

M42電視観望 2024-11-10

Sat, 09 Nov 2024 00:00:00 GMT

SV165 40mmでM42の電視観望にトライ。

テストでROI設定してみたが、せっかく1時間も撮るなら後で画像処理することも考えてROIなしで撮ればよかったか…

Sharpcapのダーク補正も有効にしてみたが、ホットピクセルが消えてなくて暴れている。

Telescope: SVBONY SV165 40mm fl170mm/Filter: QBP3/Camera: ASI533MC/Gain200/240x15s

SharpcapでのASIカメラのオフセット設定が謎だったが、Brightnessがオフセットらしいということで調整してみた。以前の撮影では1になっていておもっくそダークのヒストグラムの山がクリップしてた。

もうちょっとまともな鏡筒が欲しくてEVOGUIDE 50EDIIポチりましたが、納期が12月中旬以降になるみたいなので、当分あおずけですね…

AZ-GTiはPlate solve & Syncだけでアライメントできるのか

Sat, 26 Oct 2024 00:00:00 GMT

SharpcapのPlate solve機能を使って、アライメント星の選択やセンタリングをせずに、指定座標にSlew→Plate solve & SyncだけでAZ-GTiのアライメントは取れるのかを試しました。

AZ-GTiでのPlate solveを使ったアライメント方法としては、以下の手順で行われている場合が多いようです。

SynscanアプリからNスターアライメントを実行
SharpcapのPlate solve機能（Offset the mounts position to center the target：マウント位置をオフセットして、天体を中央に配置する）で目標天体を写野中心に捉える
Synscanアプリでアライメント完了を押し、次のアライメント星へ

これでアライメントできるのですが、この手順には次のような不満点があります。

視界が限られたベランダからの観測では、特に3スターアライメントなどではアライメント星が見える範囲にとれない場合がある。
観望天体導入後の追尾精度向上のため、アライメント後はSharpcapのPlate solve設定は「Sync Mount and Re-center target」で使いたい。アライメント後にオプションを切り替えるのが面倒。
上記2のセンタリング手順が省略できればもっと短時間で終わるのに…

Plate solve & Syncでアライメントが取れるなら、これら不満点がすべて解消します。

Plate solve & SyncによるAZ-GTiのアライメントの情報を探しましたが、以外とネットに情報がない？

ですがSynscanの更新履歴を見ると、2023-09-02のv2.4.5に以下のような記述があります。

• Replaced "Align with Sync" page with "Sync samples" page.
• Multi-star alignment, where performing any of the following adds a sync sample:
  • Using one of the alignment methods from the Alignment page
  • Centering on a celestial object at the prompt after any catalog object GOTO
  • Receiving a `SyncTo` command from ASCOM with a plate-solving software

実際、Nスターアライメントを実行した場合、SynscanアプリのSync samplesにその情報が追加されます。この書き方を見ると、Synscanアプリのアライメントページからどれかのアライメント方法を実行するのと、ASCOM経由でSyncToするのは同じであるように読み取れます。

そして2023-09-19のv2.4.8から、Sharpcapでオートアライメントするためのスクリプトが同梱されているんですよね…

• Windows: bundle SharpCap AutoAlign scripts under "SharpCap scripts"

というわけで、実際にやってみました。やり方としては、まずAZ-GTiはホームポジションから始めます。Sharpcapでは、Plate solveのオプションは「Sync Mount and Re-center target」のまま。そして全自動でのアライメントのため、Sequencer機能を使います。

メインメニューのSequencer→EditからSequence Editorを開きます。この機能を使うと、コードを書かなくてもSharpcapのいろんな動作を自動実行させるマクロを組めます。この機能を使って、「特定の方向に向ける→Plate solve & Sync」を3回実行するように設定し、3スターアライメントを試みます。ここでうれしいことに、Sequence EditorのMOUNT GOTOコマンドは目標座標をRA/DECだけでなくAltitude/Azimuthで指定できます。Alt/Azで指定すれば、限られたベランダの視界から確実に見える方位・高度を観測時間に関係なく指定可能です。

Synscanアプリのマニュアルの「SYNC: CHOOSING ALIGNMENT STAR」によれば、3スターアライメントの場合、最初の2点は同じくらいの高度、3点目は高度を30度以上離すことが推奨されています。

Alt-azimuth mount
– Altitude is between 15 and 60 degrees
– Difference between altitudes is between 10 and 30 degrees
– Difference between azimuth is between 45 and 135 degrees
– For 3-Star alignment, the first two stars should have similar altitude and the 3rd star should have 30 degree or more variant in altitude compared to at least one of the first two stars.

これを参考に、うちのベランダから見える範囲でアライメントエリア3点の方位・高度を決め、Sequence Editorに入力したのが以下の状態です。このSequenceは保存しておけば次回から読みこむだけで実行できるのでらくちんです。

Synscanのアライメントをリセットしてから実行してみた結果、このPlate solve & Sync法でもきちんとSync sampleが追加され、アライメントパラメータも定まっています。もちろんアライメント後の導入と追尾も問題なし。以下はアライメントを実行しているときのSynscanアプリの動画です。

導入後にしばらく止まっているのは、Sharpcapのマウント整定時間（5s）とPlate solve & Syncを実行しているためです。

というわけで、AZ-GTiはPlate solve & Syncだけでアライメントできることがわかりました。十分見通しのよい屋外ではSynscanアプリのSynMatrix AutoAlignを使った方が早いですが、視界の限られたベランダからのアライメントには役立つと思います。

SharpcapのPlate solveがBlind Solveできればマウントは適当な方向に向けた状態から開始できそうな気もしますが、それは試していません。

M42オリオン大星雲 20241013

Mon, 14 Oct 2024 00:00:00 GMT

AZ-GTiがやっと届いて実践投入できたので、さっそく自宅ベランダからM42を撮ってみました。

Sharpcapも初めてまともに使うのでライブスタックの保存形式を間違えてFITSで保存してしまったので、ライブスタック結果の画像はなし。

AZ-GTi/SV106 fl240mm/QBP3/ASI533MC/Gain500/15s*137frames/20241013

PixInsightで2x drizzle後中心部をクロップ。

月が出てて撮影条件はいまいちでしたが、QBPフィルターの威力はすごいですね。SV106 60mmも星雲の電視観望には使えそうです。ASI533MCもいい感じ。中心部が飽和しちゃったのでそのうちリベンジしたい。

よく見ると下の端のほうのオリオン座イオタ星?の光芒なんかがグニャグニャのヒトデみたいになってますが、これはBXTのせいっぽい。要調整。

それにしても、GOTO経緯台での電視観望って楽ですね…水平取って適当に2スターアライメントするだけで十分な追尾精度が出てましたし。リモートデスクトップで家の中からぬくぬく観望できる快適さも癖になりそうです。

190万都市の中心部でこれだけ写せるなら、車で1時間以上かけて遠征しなくてもかなり楽しめそうです。

ただ見つかった課題もあって、

AZ-GTiにASCOM Device Hubで接続できない。POTH Hubだといける。
AZ-GTiのASCOM接続が調子悪くなるときがある。SynScanアプリからは制御できるが、POTH Hub側がConversation Errorで接続できなくなる。こうなると一度電源落としてSynScan Appも再立ち上げ、アライメント取り直さないといけない。

特に2が困ったもので、ASCOM経由での制御を全く受け付けなくなるのでSharpcapのライブスタック中のディザリングやオートリセンターが機能しなくなります。

SynScanアプリからは制御できるのでアプリ側かASCOMドライバのバグな気もしますが、無線接続の不安定さが悪さをしているとの情報もあったので、USBシリアルで有線接続したら改善するのか試してみたいと思います。

ベランダの手すりにAZ-GTiを載せる（お安く）

Sun, 13 Oct 2024 00:00:00 GMT

ベランダで天体観測をされている方が皆悩むことだと思いますが、屋根があるので広い視界を確保するためには、可能な限り機材を手すり側に寄せて設置したい。できれば手すりに載せたい。ということでこれをできるだけお安く実現できないか考えてみました。

うちのベランダの手すりは、厚みが15cmあるコンクリートで上面は平らです。何かクランプ的なもので手すりを挟むように固定すればいけそうです。

先人の知恵として、同じようなコンクリートの手すりに赤道儀を設置されている方がおられます。中型赤道儀を載せても大丈夫そうなくらい頑丈そう。ただ、部品がお高い。パラボラキャッチャーがAmazonで1個7000円ほど、それが2個とチャンネルブラケットで2万近くかかりそうです。私の場合、載せるのはAZ-GTiなので、ここまでの強度は必要なさそうです。

材料

土台（手すりにクランプ固定できるもの）

まずもっと安くて使えそうなクランプがないか探して見つけたのがこれです。ガレージミラーをコンクリートブロックなんかに取り付けるときに使うやつみたいですね。1個982円。お安い。実際買ってみたら2mm厚の鉄板で思ったよりしっかりしてました。

::linkcard[https://www.amazon.co.jp/gp/product/B003LXQDFE]{title="Amazon.co.jp: MYST(マイスト) ガレージミラーブロック用取付金具(幅90~180mm) (5106) : DIY・工具・ガーデン" desc="Amazon"}

AZ-GTiエクステンションピラーの土台

AZ-GTiのエクステンションピラーを載せる土台としてはこいつが使えそうです。カメラ用のチーズプレートですね。真ん中に3/8"のネジ穴があって、両端が長穴になっています。長穴を利用して先ほどの取付金具に共締め固定する作戦です。こいつも1,278円で非常にお安いですが、アルミで厚みが10mmもあるので強度は十分でしょう。幅が50mmなのでピラーが少しはみ出ます。もう少しだけ幅広なのがあればベストなんですが…。

::linkcard[https://www.amazon.co.jp/gp/product/B0D7PKLWZ7?th=1]{title='Amazon | チーズプレートカメラビデオ撮影サポート 1/4" & 3/8" ネジ穴多用途アクセサリー搭載三脚マウント拡張ブラケット軽量多機能金属アダプタープレート (CP-E1-MZ) | クイックシュー・プレート・ブラケットオンライン通販' desc="Amazon"}

ねじ類

以下にごちゃごちゃ書いてますが、リストにまとめておきました。

1/4" UNC 長さ1/2"のキャップボルト（ステン）×4（←もうちょい長くてもいいかも？）
1/4" UNC ナット（ステン）x4
M6ワッシャー外径が大きいもの x4（1/4"ワッシャーの代用・M8用の穴に1/4"ナットを固定するために必要）
3/8" UNC 長さ3/4"のボルト（ステン）x1

あとは、3/8" UNCのちょうどいい長さのネジがホームセンターで見つからなかったので、少し割高ですがこれもAmazonで長さ5/8"（15.88mm）のネジを調達。カメラネジの規格は長さが4.5mmだそうですが、チーズプレートの厚みが10mmなので1mmのワッシャーを入れれば15.88-10-1=4.88mmでちょうどいいくらいでしょう。AZ-GTiの使用だけを考えるならもう少し長めのネジのほうがよさそうだったので、最終的に3/8"-3/4"のネジを使用しました。

ガレージミラー金具の開き固定とチーズプレートの固定には、付属のM8ボルトではなくM6のボルト・ナット・ワッシャーを使います。チーズプレートの長穴部分には1/4"のキャップボルトが入るのですが、入手性が悪いのでM6で代用します。M6の場合キャップボルトの頭がくぼみにはまらないので、ワッシャーで挟んで固定することにします。…と思っていたのですが、AZ-GTiのピラー底部が思ったより太くて干渉しそうだったので、1/4" UNCのキャップボルトとナットを購入しボルトの頭が飛び出ないようにしました。ウィットネジはホームセンターでもよく売ってますが、ユニファイネジは入手性が悪くて難儀しますね。インチネジ嫌いです。ちなみにホームセンターで売ってたウィットの1/4"キャップボルトだと、微妙に頭が大きくてチーズプレートの溝にはまりませんでした。ステンの1/4"-1/2"ボルトナット×4で2000円。タカイ…。ワッシャーはM6で代用できます。

完成図

組み上げるとこんな感じになりました。完全無加工で組んだだけです。1/4"キャップボルトの裏にはM6のデカいワッシャーが挟んであります。だいたい7000円くらいで作れたでしょうか？AZ-GTiで使うには十分な強度だと思います。

あとは適当なゴム板を挟んで水平を調整しつつ、手すりに設置すれば完成です。

ピラーを掴んで揺らそうとしてもビクともしません。もともとガレージミラー用の金具ということで屋外用なので対候性も問題ないと思います。

送料込み千円未満でバーティノフマスクを3Dプリントで作る！（CAD知識なしでOK）

Mon, 07 Oct 2024 00:00:00 GMT

この度SV106 60mmとSV165 40mm用のバーティノフマスクを3Dプリントで作ったので、その方法をご紹介します。CAD知識なしで自分の望遠鏡用のバーティノフマスクの3Dプリント用データを作れます。

中口径以上は調整可能な汎用品が売ってますが、60mm以下の小口径用はあまり見かけないので自作しました。

バーティノフマスクの3Dプリント用データ作成

バーティノフマスクの3Dプリント用データ作成には、ttait_vantim氏がThingiverseで無料公開してくださっているUniversal Bahtinov Mask Generatorを使います。

::linkcard[https://www.thingiverse.com/thing:4581618]{title="Universal Bahtinov Mask Generator by ttait_vantim" desc="Update of my previous remix, should have everything that one did plus:Easy-to-use Customizer based interface - no source code modifications neededSupport for dynamic creation of masks for lenses not i"}

上記Thingiverseからbahtinov_universal.scadとbahtinov_universal.jsonの2つのファイルをダウンロードして、適当なフォルダに入れておきます。同じフォルダに入れておく必要があります。

これはOpenSCADというフリーの3D CADソフト用のデータで、CADの操作が全くわからなくても、パラメータをいくつか入力するだけで3Dプリント用のモデルデータを作ってくれるという、大変素晴らしいものとなっています。

まずはOpenSCAD本体が必要なので、以下からダウンロードしてインストールもしくは展開します。

::linkcard[https://openscad.org/downloads.html]{title="OpenSCAD - Downloads" desc="OpenSCAD"}

次にOpenSCADを起動して先ほどダウンロードしたbahtinov_universal.scadを開きます。画面右の方にCustomizerというペインがありますので、開きます。ここでマスク生成のためのパラメータを設定します。

以下が各パラメータの詳細です。なお画像はSV106 60mm用のマスクの設定例です。ノギス等でレンズフードの外径さえ測れば作れますね。

注意点として、bahtinovfactorがデフォルトの150だとバグかなにかでスリットが異様に細かくなることがあるので、bahtinovfactorを少し動かして確認してみることを推奨します。

以下Lens Mask Parametersの説明。なお外から被せるタイプだけでなく内側（フィルターネジ部分）にはめるタイプも作れるようですが、そのタイプは作ったことがないので説明省略します。

lensFocalLength

焦点距離をmmで入力します。

lensDiameter

マスクを外側にかぶせる場合は鏡筒先端の外径をmmで入力します。

lensAperture

スリットが入るマスク本体部分の径を決めるパラメータです。レンズの有効径を入力します。望遠鏡の場合はスペック上のレンズ口径でよいかと。

centerHoleDiameter

反射望遠鏡の場合は中央遮蔽径（mm）、屈折望遠鏡の場合は0を入力します。

ringHeight

マスク固定用のツメ（リング）の高さ（mm）です。

handleHeight

0でOKです。

bahtinovfactor

スリットの細かさを決めるパラメータです。大きくすると細かくなります。あまり細かくしすぎるとプリント失敗の原因になりかねないので、ほどほどに。スリットが細かすぎず、一番端のスリットがあまり小さな穴にならないように適当に決めればよいと思います。

以下Mask Optionsの説明。

ringTabInterference

マスク固定用のツメ（リング）をlensDiameter（鏡筒外径）からどれくらいオフセットするか（mm）を決めます。0にするとツメ（リング）の内面がlensDiameter（鏡筒外径）とピッタリ同じになり、プラス数値にすると内側にオフセット（きつく）、マイナス数値にすると外側にオフセット（ゆるく）。ギチギチより多少緩めのほうが使いやすいかも？（個人的意見）

maskThickness

マスク部分の厚み（mm）です。2mmで問題ないかと。

ringThickness

マスク固定用のツメ（リング）の厚み（mm）です。きつめにはまるように設計する場合はあまり厚いとツメの柔軟性に影響するかも？

ringPieces

マスク固定用のツメの数です。ツメではなく全周が立ち上がったリング形状にする場合は1にします。

ringPiece

マスク固定用のツメの幅を決めるパラメータです。ツメではなく全周が立ち上がったリング形状にする場合は360にします。

ringRotation

マスク固定用のツメの位置を回転させるパラメータです。

handleDiameter

そのままでOK。

minGapWidth

3Dプリンターのスペックに合わせた最小ギャップ（mm）を設定します。あまりに小さいギャップはプリント失敗の原因になります。私はデフォルトの0.8mmにしています。

パラメータの設定ができてプレビューでいい感じになったら、キーボードのF6を押してモデルをレンダリングします。PCスペック次第ですが少し時間がかかります。レンダリング時にエラーが出る場合は、どこかのパラメータ設定がおかしいので確認します。

レンダリングが終わったら、File→Export→Export as STLからSTL形式で出力できます。

これで3Dプリント用のモデルデータが完成したわけですが、パラメータの数字を弄るだけで3D CADの知識は全く不要であることがわかると思います。しかも無料。

3Dプリント

あとは先ほど出力したSTLファイルを3Dプリントすればバーティノフマスクの完成です。とはいえ、3Dプリンターを持っている方は少数でしょうし、このためだけに買うのも躊躇われます。通常は3Dプリントサービスにモデルデータを投げてプリントしてもらうことになるかと思います。

3Dプリントサービスもいろいろありますが、私は最近JLC3DPというサービスしか使っていません。もとはJLCPCBというプリント基板のオンデマンド生産をやっている会社のサービスで、中国から発送になりますが大変安くてしかも早いです。支払いにPayPalが使えるのも安心です。

たとえば、今回作ったSV106用バーティノフマスクの場合、プリント代が$3.36、送料$2.23、合計$5.59で、円換算すると送料込みで900円未満で作れてしまいました。

発注から届くまでのタイムラインとしては以下のような感じで、発注から10日ほどで届いています。なお私は北海道在住なので国内輸送に比較的時間がかかってこれです。発送オプションは一番安いOCS Expressです。

<table class="has-fixed-layout"><tbody><tr><td>日時</td><td>状態</td></tr><tr><td>9/25 21:33</td><td>発注（レビュー待ち）</td></tr><tr><td>9/26 18:55</td><td>レビュー完了（※）、支払い</td></tr><tr><td>9/26 21:20</td><td>生産開始</td></tr><tr><td>9/27 19:46</td><td>生産終了</td></tr><tr><td>9/28 16:10</td><td>発送</td></tr><tr><td>10/4</td><td>受取</td></tr></tbody></table>

※たぶんレビューはもっと早く終わっていますが、私がログインしてレビュー終了を確認、支払したのが翌日夕方でした。

さて実際の発注方法ですが、特に難しいことはありません。JLC3DPの発注ページから先ほどのSTLファイルをアップロードして、印刷方式や材質、色などを選択するだけです。

これはSV106用のバーティノフマスクを発注した際の設定です。過去の実績からMJFを選びましたが、光造形方式のSLAのほうがひょっとすると造形精度は高いのかも？しかも多少安いようです。今回の場合はあまり関係ないですが、MJFは複雑な構造や中空構造でもサポート材が不要なのが強みですね。

Product Descは通関書類に書かれるHSコードの選択ですが、ピッタリ合致するものがなかったので私の場合は拡大解釈でToy Partにしています。

あとはカートに保存してCheckoutするだけです。注文画面の3. Submit Orderの欄でAutomatic pay with PayPalにチェックしなかった場合は、ファイルのレビュー終了後、注文詳細画面から支払い手続きを行う必要があります。PayPal以外にもGoogle Payなんかも使えるようです。ファイルレビューは営業時間中であればすぐ終わるようですが、レビュー完了のメール連絡はなかった気がするので注意。

ちなみに、国内で使ったことがあるDMM.makeの3Dプリントサービスで見積を取ってみたら、MJF（PA12黒、今回の発注とほぼ同等の設定）で4500円、SLA（エコノミーレジン、色選択不可）で1200円でした。参考までに。

出来上がったバーティノフマスクがこちらです。どちらもMJFで作りましたが、表面はややざらざらの艶消しみたいな風合いになるのでちょうどいいかなと思ってます。造形精度はよいです。

埃汚くてすみません（笑）写真撮ってから気づきました。

使ってみての感想ですが、まず当たり前ですがバーティノフマスクとしてちゃんと機能します。あとはもう少し爪を短くして3本でなく全周リングの形状にしてもよかったかな？と思いました。

ASI533MC購入

Fri, 20 Sep 2024 00:00:00 GMT

電視観望用にASI533MC（非冷却）を購入しました。

もともと出不精ですが、札幌に引っ越してから遠征して赤道儀で写真撮るハードルが上がってしまい、なかなか活動できなくなってきてしまいました。

わざわざ赤道儀設置して写真撮るなら、せっかくならBortle3に近い4くらいのところには行きたいですが、そうなると1時間くらいは車走らせないといけません。

それに北海道だと冬場は路面状況の関係でさらに難易度が上がるので、全く活動できていません。オリオン大星雲とか冬の天体も撮りたいんですけどね。

天文趣味のモチベを保つためにも、気軽に星に触れられる環境を作りたくて、この度電視観望に手を出すことにしました。

目標は自宅のベランダに機材を設置して、家の中からリモートでぬくぬく観測することです。

そんなわけで機材選びを始めました。

目的として、とにかく「気軽に」を最重視することにします。

まずおおざっぱにシステムの全貌を想像しますが、架台は自動追尾経緯台、鏡筒はせいぜい口径40mm、焦点距離は長くても200mmくらいの小型軽量の機材にします。

さて、気軽に、ということで冷却CMOSは最初から除外、非冷却CMOSから選びます。もちろん、性能だけ考えれば冷却CMOSはベストですが、重いしケーブルも増えるしクールダウン・ウォームアップの手間がかかって面倒です。というかすでに2600MC Pro持ってますし、冷却カメラはこれで間に合っている感。冷却CMOSの場合ダークを後で撮れるメリットありますが、今回の用途では露出時間はせいぜい10秒くらいの予定なので、ダーク撮影にも大して時間はかからないでしょう。

初めて電視観望を始めますので、先達の方々が公開されている情報をもとに、必要スペックを考えます。

・主な対象はDSO。
・ピクセルサイズ：感度を考えると3.75μm程度は欲しい。
・センサーサイズ：焦点距離200mm前後の鏡筒でオリオン大星雲やアンドロメダなどがある程度余裕をもって収まるようにしたい。経緯台で使うので写野回転があり、ライブスタックするとセンサーの端の方はあまり有効活用できない。
・ハイゲインで短時間露光に使うので、HCGモードは合った方がよさそう。
・ゼロアンプグローは優先度低いがあるに越したことはない。
・ライブスタックによるその場での観望だけでなく、できれば撮影した画像をPixInsightで処理して印刷もしたいので、画素数は多めだとうれしい。

さて、この条件でZWOのカメラ一覧とにらめっこして、2600MCと特性が似てて使いやすそう、ということで533MCを選択しました。

ピクセルサイズも必要十分で解像度も高く、ゼロアンプグロー機種でしかも経緯台向きのスクエアセンサー。価格も294MCに比べてお手頃。難点がすでにディスコンになったっぽく、国内に在庫がなさそうなこと。

この機種なんでこんなに早くディスコンなんですかね？電視観望用途にはかなり優れた機種だと思うんですけど。他社からは同じIMX533のカメラが普通に売られているので、センサー供給の問題ではないと思うんですけども。

で、どうしても欲しくて、個人輸入も選択肢にして探しました。そしたらありました。マレーシアのZWO正規代理店に2個在庫が残っていました。なんかセール対象になっていて、本体価格503USD、送料手数料と国内消費税を含めて￥88,637で買えました。国内で買うより多少安く済んだ感じでしょうか？在庫なくて買えないけど。9/12発送で9/20に届きました。

早速ファーストライトと行きたいですがAZ-GTiの納期が10月末予定ということで当分先になりそうです…残念。

Ginji-150fnをEAF化する

Fri, 13 Sep 2024 00:00:00 GMT

Ginji-150fnのGS2インチクレイフォード接眼部にEAFを取り付けました。

10年前、学生時代に￥37,500で購入したGinji君…今はほぼ6万円にまで値上がりしているみたいですね。

さて、細かいところで不満点ありつつも、こんなにお安いのによく頑張ってくれているGinji君ですが、GSO社製のクレイフォード接眼部が曲者で、なにしろ丸っこくてEAFの固定に使えそうなネジもないという大きな欠点があります。なんなら（公式？）EAFコンパチリストにUnsupportedと明言されています。

私は数年前にArduinoで自作した電動フォーカサーを取り付けて使っていました。ASCOMで制御もできるし実用上は特に問題なかったのですが、なにしろモーターがデカい・重い・個別に12Vが必要で取り回しが悪い。

それに比べてEAFっていいですよね。見た目がスタイリッシュだし、USBバスパワーだけで動作、しかも超コンパクトなのにクソデカNEMA17PG27モーターよりステップ数が多い。

どうしてもGinji君にEAF取り付けたくて、ネット徘徊した結果取り付け成功したのでその内容をまとめます。

Adruino ASCOMフォーカサーを自作したときと同様、Thingiverseで取り付けアダプタの3Dプリントデータを公開している方がおられました。

::linkcard[https://www.thingiverse.com/thing:4946220]{title="ZWO EAF adapter to GSO Crayford focuser by tgmorris99" desc="Adapter to mount ZWO EAF on GSO Crayford focuserThis was designed to fit my Lunt LS60MT Crayford focuser which is the same as my GSO Crayford focuser and allows the ZWO EAF electronic focuser to be mo"}

ファイルが複数ありますが、STLファイルをJLC3DPで3Dプリント。素材はPA12-MJFを選択。費用は送料込みで12ドルほど。

印刷されてきたものがこちら。裏面の六角穴のM4ナットを圧入した後の状態になります。圧入は表からボルトを締めていけば簡単に入ります。

必要なもの一覧（丸数字はネジ穴の番号に対応）：
①M4x16mm 六角穴付きボタンボルト（Monotaro）
②M4x25mm 六角穴付きとめネジ平先（Monotaro）
②M4ローレットナット（Monotaro）
③M4ナット（裏側に圧入）
③M4x16mm ネジ、ワッシャー
④(+)トラスタッピンねじ 2種溝なしB-0形（[Monotaro](http://(+)トラスタッピンねじ 2種溝なしB-0形)）
モーターカップリング（4.5mm-5mm）（Monotaro）

④のタッピングネジはいらないかも。あまりネジが効いてる感じがしないし固定強度は④がなくても十分に感じました。

なおこのクレイフォードの軸は4.5mmなので、EAFに標準添付のモーターカップリングはサイズが合いません。4.5mm-5mmの異径カップリングが必要です。

裏面がこちら。

①の穴はフォーカスロックネジのネジ穴に対応します。このアダプタ固定用。

②の穴はフォーカステンションネジのネジ穴に対応します。とめネジでテンション調整しつつアルミブラケットの上からローレットナットでアダプタとブラケットを共締めします。

③④の穴はアダプタにアルミブラケットを固定する用。④は補助的。

実際にEAFを取り付けるとこのようになります。上のアダプタ画像と180度向きが違うのでご注意を。ワッシャー付きのプラスネジが刺さってるところが③の穴です。

クレイフォードのテンションを調整したいときは、ローレットナットを外して六角レンチでとめネジの締め具合を調整します。

ただこれだと現地で調整したいときにレンチが必要でめんどくさいので、長いM4のローレットネジがあればツールフリーにできそうです。もし手に入ったら追記します。

動作は完璧に問題ありませんでした。ただこのクレイフォード自体の問題で、重い冷却CMOSカメラを付けたときに鏡筒の向きによっては軸がスリップします。もしかしたらそのうち笠井のMRP接眼部に交換するかもしれません…（接眼部だけで鏡筒の価格とほぼ同じなので二の足を踏んでいます）。

StargazR

Proxmoxの非特権LXC上にJellyfinでメディアサーバーを構築する (QSV HW Transcoding)

経緯

既存のNASセットアップ

Jellyfinサーバー環境の構築

Jellyfin LXCの作成

LXCへのNASフォルダマウントの準備

ProxmoxホストへのNASフォルダのマウント

Jellyfin LXCへNASフォルダをbind mount

HWトランスコードしようとすると再生できない場合

おわりに

天体写真のFITS保管用にNASをチューニングする

NAS

NASの簡易スペック

パフォーマンステスト

compression=?

書き込み速度および書き込み時間

平均書き込み速度 (MB/s)

書き込み時間 (seconds)

圧縮率およびディスク上のサイズ

圧縮率

ディスク上のサイズ (GiB)

圧縮形式の決定

recordsize=?

書き込み速度および書き込み時間

平均書き込み速度 (MB/s)

書き込み時間 (seconds)

圧縮率およびディスク上のサイズ

圧縮率

ディスク上のサイズ (GiB)

recordsizeの決定

もう少し小さいデータセットの場合

合計書き込み量別書き込み速度 (MB/s)

結論

ZWO EAFのハンドコントローラを自作した

DIYハーモニック赤道儀⑨：15cmニュートン搭載実験

DIYハーモニック赤道儀⑧：実地試験成功！？

スペックまとめ

テスト機材セットアップ

極軸合わせ

ガイド状況

今後の予定

DIYハーモニック赤道儀⑦：組み立て完了

組み立て完了

動作確認

蓋とかOnStepホルダーとか

今後の予定

Cloudflare Pagesのデプロイ終了後にエッジキャッシュをパージする

ビルド後にエッジキャッシュパージ

scripts/cf-purge.js

package.json

Pagesのビルドコマンド変更

おまけ "デプロイ後"にエッジキャッシュパージ

.github/workflows/cf-purge.yml

AstroブログにCloudflare D1を利用したシンプルなコメント機能を付けた

はじめに

システムの概要

動作の流れ

コメントAPIの構築

Astroコードの改変

DIYハーモニック赤道儀⑥：フランジプレート完成

DIYハーモニック赤道儀⑤：OnStepX完成

DIYハーモニック赤道儀④：フレーム加工

DIYハーモニック赤道儀③：フランジプレートの設計

DIYハーモニック赤道儀②：設計

DIYハーモニック赤道儀①：中国製ハーモニックドライブ

AZ-GTi改造②：サブアリミゾ装着

AZ-GTi改造：アリミゾ交換

M42電視観望 2024-11-10

AZ-GTiはPlate solve & Syncだけでアライメントできるのか

M42オリオン大星雲 20241013

ベランダの手すりにAZ-GTiを載せる（お安く）

材料

土台（手すりにクランプ固定できるもの）

AZ-GTiエクステンションピラーの土台

ねじ類

完成図

送料込み千円未満でバーティノフマスクを3Dプリントで作る！（CAD知識なしでOK）

バーティノフマスクの3Dプリント用データ作成

3Dプリント

おまけ　"デプロイ後"にエッジキャッシュパージ