マクドmini突然死

昨日(2019/12/23)の夕食前まで元気に動いていた,筆者のメインWSであるMac miniが,夕食後書斎に戻ってみると,黒い画面に,”?”マークをのついたフォルダーを表示して,キーボードやマウスの操作に全く反応しませんでした.

電源リセットをしてみましたが,電源ランプは点くものの,スタートアップのジャーンが鳴りませんし,画面も黒いままです.何度かやってあきらめて,一晩AC電源を抜いておき,朝試してみましたが同じでした.

つながっているケーブルも,キーボードと電源とHDMI以外全部外しましたが,同じです.

あとやってみようと思うのは,分解掃除です.搭載しているSSDを購入時の250GBのHDDに換装してみます(これはもはや廃棄の準備😓).

じつは,このMac miniのパフォーマンスの悪さは前から悩みの種で,年明けあたりに,Core i7 6 coreの豪勢なMac miniを買おうかと密かに考えていたのですが,そのことをこのMac miniに悟られたのかも知れません.

費用の算段も頭が痛いですが,もうひとつ困るのは,Appleとのひも付けが解除できないことです(もう一つくらい何かたちの悪いひも付けソフトがあったかもしれません).

当分,FT8の運用が出来ません.

そうだ,年賀状をどうやって作ろうか😓

FT8しばらく運用して

FT8をしばらく運用しての雑感です.

信号が聞こえるか聞こえないかレベルの局と交信できるのは素晴らしいと思います.JT65時代も,ノイズレベル以下の信号がデコードできる的な説明をあちこちで読みましたが,実際運用してみると,これだけ聞こえればCWで交信できるじゃないかと思ったものです.しかし,FT8だとCWじゃ無理かもというケースがよくあります(当社調べ).HFの伝搬により適した性能になってきたのでしょう.

一方,CWで楽々交信できる地域,例えば40mのイタリアやギリシャなどについては,FT8では相手がかなり強く入感していても苦戦することが多いです.信号自体に50Hzほどの帯域があり,たいていの人は2.4kHz程度の受信帯域で聞くのでどうしてもQRM(混信)や,非常に強い信号にともなうスプリアスや抑圧があるためでしょう.

それから、実際交信してみて,1st QSOが非常に多いです.特に国内の場合.また,何十年ぶりのQSOということが,けっこうあります.こちらは国内外を問いません.数日前にニュージーランドの局と37年ぶりに,またもう少し前には北海道の局と40年ぶりのQSOをして,少し感動しました.

しかし,相手の人も同様に感動していた可能性は低いです.40年も前の交信記録をデータ化している人はそう多くないからです.

当分,国内外を問わず,FT8で,そのバンドで未交信の局は呼びますのでよろしくお願いします.

CQもけっこう出しています.こちらは同じバンド・モードでも一切気にしません(解りますが😓)ので気が向いたら呼んでください.

EFI+GRUBで悩む

久しぶりにEFI+GRUB関係で悩みました.

今,メインサーバーはSlackware ARMで動いてます.Raspberry Pi に切り替える前まで,メインサーバーだった,Core i7のデスクトップ機は,無任所workstation (WS)として存在していますが,とにかく使用目的がないので動かすのがまれで,そこそこのマシンパワーを持っているのに,持ち腐れ状態です.

最近,無線関係の機器を作りたい気持ちが高まってきていますが,まずは,GNU Radioでソフト的に遊んでみることにしました.Mac miniとMacBookには,Mac PortsでGNU Radioがインストールできましたが,そもそも非力だし,動作に怪しいところがあるので,そこで,このWSを使おうと思いつきました.

このWSはサーバー時代のままSlackware64が入っています.以前はSlackwareで,GNU Radioを手でbuildしたものですが,今はどうもそんな気力がありません.となると,UbuntuとかDebianです.Ubuntuはどうにもあかん(当社調べによる)ので,それならDebianにすることにしました.

Debianは既にそのWSの仮想マシンとしてインストールしてありますが,実時間性が必要となる信号処理で仮想マシンはたいていうまく動いてくれません.そこで,比較的余裕のあるルートディスクにパーティションを切って,Debianをクリーンインストールしてdual bootにしてしまおう,というところまでが,まえがきです.

EFI+GRUBはかつて,かなり苦労してそのWSに導入しました.GRUBは良く出来すぎていて,一度イントールしたら,kernelをupdateしても,ちょこっとしたおまじないでconfigファイルを書き直すだけでいいので,ほとんどいじることがないので,もともとよく理解しないままインストールした上に,すっかり忘れてしまいました.

そんなわけで,ただ元のルートディスクの中身を他のディスクに書き出して,その他の方からブートして,元のルートディスクに書き戻す,というだけの作業で苦労してしまいました.コピー自体は,rsyncを使う自作スクリプトで簡単なんですが,コピー先からのブートで難儀しました.

いろんな罠にハマりましたが,特に残念なのがGoogle検索です.GRUBのコマンドラインについて調べると,GRUB1についての解説が上位に出てきます.GRUB1と2ではコマンドの基本的な文法に大きな違いがあって,参考になるどころか害悪をもたらされ,時間を空費しました.

それでもなんとか,EFI+GRUBで,もとのSlackware64にてブートできるようになりました.最終的な手がかりは,自分の非公開Wikiに書いてあるメモでした😓 少しわかりにくい部分があったので,いつあるか解らない次回のために加筆修正しておきました.

このあと,あけたパーティションにDebian AMD64版をインストールして,GNU Radioもインストールしてみます.

時計が合わない

macOSをCatalinaにアップグレード(UG)して,使えなくなったVMWareをUGして,結局,WSJT-Xは,macOSのネイティブアプリもWindows版をVMWare上でも使えないと確認できて,死蔵していたWindowsの実マシンでWSJT-Xを使うようになった話の続きです.

どうも,時計が合いません.起動直後や,運用の合間にも時々,手動でタイムサーバーへの同期ボタンを押すのですが,受信局の時間遅れが1秒台ということが多いです.

受信する局の多数が1秒以上遅れているということは,こちらが1秒以上進んでいると考えるのが妥当でしょう.

タイムサーバーを変えてみても状況は変わりません.

macOSのネイティブのWSJT-Xでは,受信する局のほとんどが0秒台前半なので,こちらもあっていると確認できます.

Linuxだとntp(d)が普通についていて,同期すべきタイムサーバーを設定すれば,いちいち手動で同期ボタンを押さなくてもPCの内部時計が常に正確な状態が保たれます.

macOSは詳しいことは解りませんが,Linuxの多くのdistroと同様の仕組みと思います.

Windowsの仕様なのかAMD A6を搭載したこのポンコツPCのチップセットがタコなのか解りませんが,どうにもしようがない状況なので,「あいつの信号はいつも1秒以上ずれている」と責めないようにお願いいたします😥

追記: 時計合ってます

2019年11月9日にMac miniをMojaveに戻し,以後はWSJT-XのmacOS版に戻りましたので,時計は正確です.

2019年11月15日

ntpを使っていないLinux distroの存在を知りませんでしたが,Chronyとopenntpdというのがあるようです.

Catalina UGの後始末

結局,WSJT-Xのみは,Windowsの実機(AMD A6 Windows 10 32bit)で,動かすことにしました.その他のアマチュア無線関係のソフト, N1MM+, MMTTY, Log200は,引き続き,Mac miniのVMWare Fusion 11.5下で,Windows 8.1の仮想マシンを走らせて,そこで動かします.

VMWare Fusion上のWindows 8.1仮想マシンと,USBリソース(CAT用のUSB-serialアダプターと音声信号入出力用USB-audio)は,KVM Switchで切り替えると不具合が生じましたが,これを避けるために,基本的に両方のWindows環境を起動しないこととします.また,KVM SwitchでMacとWindows実機をどうしても切り替える時は,USBの切り替えを伴わない,HOT Key 2回, ポート番号, k, リターンという手順で切り替えることにします.

Windows実機では,S/Nが-20dBを下回る信号もちゃんとデコードしてくれます.macOS版のWSJT-Xと同等のデコード性能と思います.

たぶん,VMWare Fusion下では,単純な時間遅れが生じているのかもしれませんが,それより問題になるのは,スケジューラーによるタスクの切り替えで,仮想マシンの時間軸にjitterが発生して非線形(時間のjitterは,相対的に入力信号のjitterになります)となっていることでしょう.このため信号のデコード(信号を重ね合わせてランダムノイズを除去する)で大きな不利になっているのでしょう.あくまで推測で,確認・検証などはしません^^;

傍証として,VMWare Fusionで動かしているWindows 8.1 (32bit)上で,DFUSe Demoを使って,nanoVNAにファームウェア(固件)を書き込むのがうまく行かない(書き込みの途中で必ずエラーになる)というのがあります.