QPM-01のfirmware update

作者のJL1VNQさんから,どこかのSNSで😓,通過型電力計QPM-01のfirmwareのupdateの案内がありました.firmwareは,このサイトからダウンロードできます.

このキットは,VN-4002のようなICSP™でなくて,チップを外してプログラミングする必要があり,なんかめんどくさくてしばらく放置していました.

しかし,それではいかんと,一念発起して,どこかにあった,チッププログラミング用のICクリップと,ソケットを探し出して,PicKit3につないでMPLab IPEでプログラミングを試みますが,ソケットをひっくり返したり,ICをひっくり返したり,供給電圧を3.3Vや5.0Vに変えてやってみますが,プログラミングどころか,消去もできません.

これは,配線が違っているに違いないと,ようやく観念して,ネットでPIC12F1840とPicKit3の接続例を探してみたら,やはり全然配線が違っていました.

そもそも,見つけ出してきたソケットには,「16F88専用」なんてテプラが貼ってありますので,冷静に考えれば,12F1840でそのまま使える可能性は低いんですが,めんどくさいので,きっとピンコンパチに違いないと考えることにしていました.

しょうがないので,ソケットの配線を直してプログラミングしたら,一発でできました.電圧を変えたり,ICを上下ひっくり返したりしましたが,PICは丈夫にできているようで,全く問題ありませんでした😓

16F88用として作った経緯はさっぱり覚えていません.

ワイヤレス送電

十年一昔と言いますが,ずいぶん昔に,「ワイヤレス送電といえば電気シェーバーの充電が関の山」っていう趣旨のBLOGの記事を書いたところ,あらぬ所で,筆者のアマチュア無線の資格を侮辱するようなことまで含む,変な絡まれ方をしたことがあります.

あれからずいぶん経ちますが,実用的なワイヤレス送電と言えば,電気シェーバーの充電に,スマートフォンの充電が加わったくらいでしょうか😓

電気に多少詳しい素人レベルの考えですが,ワイヤレス送電を実用化するためには,

  1. 効率が度外視できる
  2. コストが度外視できる
  3. 安全性

の3条件が必要です.1, 2はある程度の大電力になれば無視できませんが,スマホやその関連機器,そして電気シェーバーの充電では度外視できます.

3番目の安全性はなかなかやっかいで,(1, 2が問題にならないとして)人が全く住まない山奥の発電所から,人里に近い山までワイヤレスで送電したとして,その間を,鳥や飛行機やスーパーマンが横切ったら致命的なダメージを受けかねません.また,飛行機自体がダメージを免れたとしても機体で反射した電力(電波)がどこに飛んでいくか解らず,危険極まりないです.

地上の電力を宇宙ステーションに送る場合や,逆に宇宙で発電した電力を地上に送る場合は,鳥やスーパーマンの問題の他に,送り先が逸れたらどうなるかという問題もあります.

人里でのワイヤレス送電は,より非現実的でしょう.

では,もっと小さい電力で,家庭内で家電機器に送電するのには使えないかということになりますが,数百ワットでも,送電している間に間違って人やペットの体の一部が入ったら絶対安全とは言い切れないでしょう.となれば,送電する空間を何らか方法で囲って安全を確保する必要があります.それだったら,電線を使ったほうが,圧倒的に安くて効率がよく,配置・配線の柔軟性があり,そして安全です

さらに小電力のモバイル機器の電力源は,現状のリチウムポリマーバッテリーで,それほど不便を感じませんし,これに置き換わるものとなると,コストをはじめとする条件がよほどよくないと無理でしょう.ワイヤレス送電があっても,電力供給の不安定さを解消するために小容量でもバッテリーの内蔵も必要だし.たぶん,モバイル機器の電源としておき代わるものがあるとしたら新型バッテリーだと思います😓

また,モバイル機器は,通信に周波数資源が欲しいので,送電のためにそれを割くのは難しいでしょうね.ジレンマというか自己矛盾というか😓

あくまで,多少電気に詳しいアマチュア無線を趣味に持つ一般人の意見です.

アマチュア無線は,微弱な電波を拾い出すような趣味なので,「近所」に途方もない大電力を通すのは歓迎できません.

ご注意: もし,この記事にコメントを付けたいけれどコメントが閉鎖されていた場合(一定の日数で自動的に閉鎖されます),他所に書かずに,このBLOG内の新しい記事にコメントを付けてください.記事のタイトルを引用していただければ解ります.

電気カミソリ,電動ひげそり.
旧システムのため,現在は,BLOGもろとも存在しません.
よほど画期的な技術が実用化されない限り.
よほど画期的な技術が実用化されない限り.
今のところ,効率やコストは度外視できそうですが.
ある程度効率は度外視できるかも.
日本は電気代が高いので,数十〜数百ワットでも効率は無視できないと思います
空間的,周波数的に.

寒い部屋で無線をすると血圧が上がる

この冬は暖冬ですが,わが家的には寒冬です.関東の冬といえば,晴れて乾燥した強い北風が吹く日が続くんですが,この冬と言えば,曇りがちでしばしば雨が降り,晴れて日差しのある日が非常に少なくなっています.

わが家は構造的に,真冬でも日が差せば暖房が要らないくらい暖かいのですが,日が差さない今年は寒冬です😓

筆者の書斎兼無線部屋は,冷暖房器具としてパナソニックのインバータ式のエアコンがあり,冷暖房能力は十分なのですが,冬場,特に日差しがないときに暖房しても足もとが全く温まりません.頭寒足熱の反対の頭熱足寒となります.

その条件でパソコンいじり(無線の運用も含む😓)をしていると,どうも調子が悪いです.血圧を測ったところ.収縮期(いわゆる「上」)がリラックス時よりも10〜20,拡張期(下)が,10それぞれ高くなっています.

これはいけません.特に元々血圧が高めの午前中はいけません.夜,湯上がりのあとは同じ条件でもそれほど血圧が上がりませんから,自律神経の問題でしょうね

ということで,天気の悪い日の日中に書斎でパソコンいじりや無線の運用をすると寿命が縮むことが解りましたので,今後は気をつけていきたいと思います.

地形的な影響でしょうか,「北風」といいますが,当地では西北西の風が多いです.
しかし,これまでこの条件でなぜ血圧を測らなかったのか,悔やまれます😓

新Mac miniの良いところと悪いところ(WSJT-X関連)

macOSネイティブのWSJT-XがFTDX5000MPと正常にCATで通信できない問題ですが,いったん,VMWare Fusion上で動く仮想マシンであるWindows 8.1上のN1MM+でCAT接続してから,仮想マシンを終了(ないしサスペンド)して,macOSネイティブのWSJT-X (2.1.2)を動かすと正常にCATで通信することが解りました.

原因については推測の域ですが,macOS版のWSJT-Xに含まれるhamlibが通信ポートの初期化を正しくできないのではないかと思います.いったんWindows版で初期化した後だとOKとなる模様です.

しかし,かつてのMac mini Core i5 2core (late 2014)ではこのトラブルは起きなかったので,ハードに依存する何かがあるのかもしれません.これ以上はどうにも調べられません.

また,VMWare Fusion下の仮想マシンが,WindowsもLinuxもシャキシャキ動くことこの上ないです.もう実機はいらないのではないかと思っています.

Mac mini Core i5では,仮想マシンのWindows 8.1でWSJT-Xを動かしたときは,FT8の信号がまともにデコードできないことが多かったですが,Mac mini Core i7 6core (2018)であるところの新WSでは難なくデコードできますし,交信もできたので送信信号にも問題はないようです.

高速の親機のもとでは,仮想マシンの時間軸のジッタもほとんど生じていないのだろうと推測されます.

2020/01/21注

不思議なことに,新しいMac miniに切り替えた当初はこの症状がときどき出ましたが,その後は全く出なくなりました.

Mac mini+

メインWSであるところのMac mini (late 2014)が死亡し,後継のMac miniをCTOして待っていましたが,予定通りに昨日(2020年1月11日),届きました.

Mac mini (2018) core i7 6-core

緊急リリーフのMac mini Core i7 (late 2012)が,死亡したCore i5よりも明らかに速いので,今回は迷わずCore i7にしました.

Catalinaがプレインストールされていましたが,今まで使ってきたSSDの中身(Mojave)を内蔵SSDにコピーして使うことにしました.

しかし,これが今までのMac miniのように簡単にいきませんでした.セキュリティーチップが内蔵されていて,デフォルトでは外部ドライブからは起動しません.調べてその設定を外して,外付けSSDから起動しましたが,最後の段階でスタックしてしまいました.

起動したい外部ドライブが暗号化されているためかなと思い,1週間くらい前にクローニングした暗号化していないドライブから起動したらなんとかなりました

外部ドライブからブートできたので,内蔵SSDを初期化して,Carbon Copy Clonerでコピーをしましたが,これが何とも遅く,8時間もかかりました

それでもこのクローニングで,内蔵ドライブから起動できましたので,8時間待った甲斐はありました.

あとはiCloudやいろいろなアプリ関係で再認証して死亡前とほとんど同等になりました.

動作はキビキビして何とも軽快です.そこで,このMac miniはMac Semi Proだって,書きたいところですが,内蔵ドライブへの書き込みが遅かったので,Mac mini+止まりとしておきます.

ソフトは,ほとんど動き,すんなり動かなくても再認証するくらいでしたが,WSJT-XがCATでFTDX5000MPと通信してくれません.

いろいろ試しました.不思議なことに,VMWare Fusion上のWindows 8.1で動くN1MM+からはFTDX5000MPと問題なくCATで通信してくれます.

かつて,CatalinaにしたときWSJT-Xが動かなかったので,Windows 10の実機からWSJT-Xを運用し,CAT用のUSB-serial変換器はKVM switchを介したHUBにつないで使うようにしていました.ふとそのことを思い出して,USB HUBがKVM switchを介さないでつながるようにトポロジーを変更してみました.そうしたらあっさり動きました😓

これで,旧Mac miniが死亡する以前動いていたものが全部動くようになりました.

後に解ったことですが,このSSDは死亡寸前(あるいはエンクロージャーのインターフェースICが死亡寸前)だったようです.
実は,USBのトポロジーの問題ではありませんでした.詳しくは別稿にて