2023/04/15(土)複数の電源トランスを扱う場合の注意点がよく判らない・・・

2023/04/15 23:37 電子工作
実際、事例が少ない上、要点しか書いていない場合が殆どで「何故か」の言及は殆ど皆無。

パワートランジスタが壊れた回路の概略図を描くとこんな感じ ↓
20230415_Epson_1_out.jpg


トランジスタの1つ、或いは2つがコレクタ・エミッタ間で短絡故障を起こしました。
電源トランスが複数あり、一次側の0V端子側、2次側の0V端子側を共に合わせて配線しています。
こうすることで、極性が合うはずと思っているんですが、

結果的に、金属ケース筺体を利用して、ダイオードブリッジの中間を共通接地にした形というアホな回路になっていたため、何かしらの循環電流が流れる感じになっていたのかもしれません。
C05 の端子間電圧が 54V になっていたり(ここは 42.5V 以上にはならないはず・・・・)、トランジスタが壊れなかったとしても、意味不明のスパークを筺体で発生させてヒューズが飛ぶ、とか起きる謎の現象もあったので、それは、この狂った配線が原因なのだろうか・・・?

いずれにしても、色々と直観的によろしくないと思うので、下記のように変更を予定しています。
20230415_Epson_2_out.jpg


ただ、これでもパワートランジスタ故障の原因が釈然としません。
破壊するとしたら、VEBOが絶対最大定格5Vを越えたくらいしか考えられない感じで、これが発生する条件というのがどうも判りません。。

2023/04/15(土)整流回路の平滑コンデンサは容量が大きければいいというものではないらしい

自作の安定化電源装置にて、再びパワートランジスタが破損したので、その原因を調査している途上で設計を色々見直しているのだが・・・
10年近く前に、PC-9801 のBASIC で組んで公開されていた整流回路シミュレーションがあったので、手元のMZ-2500 BASIC-M25 に移植して使っています。最低限機能させるための移植なので、色々変な部分はあるんですが。。orz

引用元の書籍を紹介しようとして、手持ちの書籍を漁ったのですが、何故か見つからない。
ということで、「原作者の方、申し訳ないです・・・」ということで、、、
いずれにしても、MZ-2500だったから移植出来たのです。他の機器だったら、かなり苦しい。

ここから本題なのですが、当初は、こんなふうにしていました ↓
20230415_6800uF.png


そして、おもむろにこのシミュレーションを動作させてみると・・・
20230415_6800uF.jpg


負荷電流1Aという、意図的に悪い動作条件を与えたんですが、こんな感じになりました。
黄色の線は電流を示しますが、正確ではないし、描画がおかしいので、とりあえず無視。
注目すべきは赤っぽい実線。
このあとに5V出力の3端子レギュレータが繋がるのですが、安定動作には7.5V以上の電圧が必要なので、14ms あたりまでは何かしらの不具合が出る可能性がある。
静電容量が大きすぎて、電圧が上がり切りません。

ということで、平滑コンデンサ C01 を下記のようにしてみました ↓
20230415_2200uF.png


静電容量だけ変えて、他は同じ条件です。
20230415_2200uF.jpg


ここまでは、安定化電源装置を動作させるための補助電源部の話で、
本当の本題は、PT2-D3-C05 で構成する、この平滑回路です ↓
20230415_22000uF.png


22mF(22,000μF)というオーディオアンプの電源に使うような大容量電解コンデンサを当初使っていました。
安定化電源装置の最高出力電圧は24V、最高出力電流は3Aの設計です。
24Vの安定化出力を出すためには、平滑回路の電圧は27Vは欲しい。
これを安定化電源装置の設計最大電流である3Aでシミュレーションさせると・・・
20230415_22000uF.jpg


40ms あたりまで、所要の電圧にはならないことが判りました。
試行錯誤で、落ち着いたのがこれ ↓
20230415_4700uF.png


シミュレーション結果は以下。
20230415_4700uF.jpg

ギリギリ大丈夫か? みたいな感じです。今までは経験と勘だけで適当に決めていたところだったが。。orz

Rs というのは、変圧トランスやコンデンサを結線する配線抵抗等ですが、これを正確に決めるのは難しく、代表的な値として0.5Ωと見做すことが多い模様。
恐らく、殆どのケースでは0.5Ωよりも小さく、このシミュレーションで得られる電圧よりは若干高めになると思います。

シミュレーション上の紫の実線の山と赤っぽい実線の山の間隔が広いと、それだけ電力損失が増え、整流ダイオードあたりが発熱しやすくなるのではないかと思われます。
ですが、このことがパワートランジスタの破損に直結するとは思えないです。

2023/04/06(木)Let's encrypt のサーバ証明書をpostfix で使う場合の注意

2023/04/06 16:15 サーバ運営・管理
今回、初めての経験だったのでメモ。。。
発端は、「こんなメッセージが出るんだが・・・」という一報。
20230406_1.png

証明書の更新は正常にできているので、謎の現象です。さらに「証明書の表示(V)...」で表示される内容を送ってもらうと・・・

20230406_2.png

こんな感じになるらしい。確かにここでは「期限切れ」になっています。

証明書の誤認識であることには間違いないので、クライアント側の設定で何か問題を引き起こしているのではないかと思うのですが、いろいろと不可解なので、一報を頂いた会社へ許可を得て出向いて、原因究明と解消を試みました。

証明書チェーンはあっているが、変にキャッシュしているのかと思い、色々と余計な「オレオレ証明書(最近まで使わせていました)」を削除したが、進展せず。

よく聞くと、最初の送信時だけ出て、電子メール送受信ソフトウェアを終了させない限りは「出ない」とのこと。
また、受信時は一切出ないとのこと。ということは postfix の問題か?

ということで、結局、試行錯誤と考察でひらめいたのが、postfix のhash DB です。
試しに
# postmap -F hash:tls_sni.map
# postfix reload
(tls_sni.map には、証明書の一覧などが所定フォーマットで記述してある)

とやったあと、試してみると、当初のメッセージは一切でなくなりました。
ここには、証明書の有効期限までもデータとして保存される作りらしい。

ということで、
2022/12/25 付けの記事 メールサーバの中規模改修と基礎知識(3)~ Dovecot+Pigeonhole,cert-bot
の最終部分に記述した内容は
#!/bin/sh

/usr/local/etc/rc.d/apache2 stop
/sbin/pfctl -d
/usr/local/bin/certbot renew -m user@example.com
/sbin/pfctl -e
/usr/local/sbin/postmap -F hash:/usr/local/etc/postfix/tls_sni.map
/usr/local/sbin/postfix reload
/usr/local/sbin/dovecot reload
/usr/local/etc/rc.d/apache2 start
のようにし、postfix が扱う証明書情報も更新しないと駄目です。
これでこの件は解決。