燃費 99.9Km/L

最近の車は燃費が表示される。次の写真は借りたプリウスの燃費。流石のハイブリッドでもここまで行くのか？

実はこれは車庫から出すときの燃費。最初は0.0Km/Lであるが、走り始めはバッテリーだけで動くからオーバーフローしてこうなるんだろう。エンジンがかかると急激に1桁まで低下し、その後徐々に20Km/L以上まで上昇する。

　一般にキーをONにしたときの燃費は計算上0÷0で不定の筈であり、これを0と表示したり標準的な値を表示したりと、車ごとに色々のようである。

今年もハムフェア 2018

今年も暑い中で行ってきました。

最近外国のハムクラブの展示が年々増えているように感じます。今回特に買いたくなるものも無かったけど、SDR的なものが円熟期に入ったような気がしました。なぜかCW関係が元気です。
　昨年留守番が一人だけで閑散としていたPRUGのブースには今年は数名の方が詰めてあって、AX.25を拡張したFX.25のプロトタイプTNCを作っているみたいなポスターと実物らしき物が展示してありました。X.25由来のAX.25は元々品質の良い回線を相手にしているので１ビットでもエラーがあるとフレームを捨ててしまいます。そこで回線品質が悪いと途端にリトライが始まり、特に回線遅延が大きい場合に疎通が極端に悪くなるんですが、FX.25では衛星通信で使うような Forward Error Correction（前方誤り訂正）をやるのでそれが改善されるようです。またAX.25を内包していて、AX.25でも通信できます。今後の成り行きをフォローしたいものです。
　CQ出版のブースで再免許の書類を買ってきましたが、電波法のスプリアスの規定が変更になりH34年でJARLの補償が無効になるような記載が・・・。

やってくれますMicrosoft

　仕事で60台ほどのPCを管理しているが、Windows10 1803 の8月定期更新（KB4343909）を適用してから動きが変わった。
　多くのPCを管理するため1台のPCでバッチファイルを組み、その中でPsExec.exeを使って他のPCで遠隔コマンドを実行させているが、やってみると7月までうまく行っていたのに、今月はエラーメッセージのオンパレードだ。

　Make sure that the default admin$ share is enabled on xxxxx.
  xxxxx:
　Could't access xxxxx:
  ネットワークパスが見つかりません。

ときた。default admin$ shareって何だ？　
　ネットで検索するとnet share コマンドで確認できるらしいが、実物を見ても問題は無さそう(というかビールスの感染ルートなので用が無ければ塞ぐべきか)。そのほかUACだ何だと出るが、書いてあることを試しても効果が無い。そこでネットワークパスに着目した。要するに「ネット上でPCが見つからない」って事だろう。すでに動いていたカラクリなのでユーザとしては名前以外は手の出しようがない。Windowsのコンピュータ名は大文字と小文字を区別しない仕様だった筈なので、これまでこの違いを放置していた。
　試しにコンピュータ名を正確に打ち直してみると状況が変わった。エラーにはなるがPCにはアクセスできている。要するにPCの名前の大文字と小文字を（勝手に）区別するようになってPCの名前が解決できなくなったようだ。そこで大文字小文字を合わせてアクセスできるようにした。
　しかし、今度はログインを拒否される。 PsExecのパラメータで指定したユーザ名/パスワードが受け入れてもらえないようだ。試しに、ローカルアカウントであることを表すためにユーザ名の頭に付けている「.\」を外してみた。すると何事も無かったように動くようになった。

　これらを踏まえると、8月15日の更新でコンピュータ名やユーザ名に関する扱いが変わってるようだ。これが意図されたものかバグかは分からないが影響は相当なものだと考えられる。クラッカー対策かもしれないが、我々みたいに他に困っている人は大勢いると思うのだが。
　まあ PsExecなんて普通の人は使わないか。

LT-R6のカラクリ（その１）

　最後にLT-R6を公開してから数年が過ぎた。その間にいくつかのバグレポートをいただき、修正も済んでいるがリリースする気になれないまま月日が経った。時間が経つと、それに見合った機能追加をしないと格好がつかない、と考えたまま今日に至っている。アイデアはあるが気力が続かない。

　そんなこともあり、とりあえずここでLT-R6についてこれまで書かなかった中身を少し公開しよう。CI-Vは1本の線を共用して双方向の通信を行うため、CI-V上を流れる個々のデータからはそれが何かは判別できない。通信の内容を解析するには先ずCI-Vの調歩同期信号を受信・UARTで再生し（ここまではクローニングケーブルの仕事）、その後バイト単位で受信したデータからフレーム（以下、CI-Vの基本フォーマットのプリアンブル (0xFE)からEOM (0xFD)までをこう表現する）を再構成し、その中身を解析することで誰が何の目的で送信したフレームかを判別する。このときIC-R6とLT-R6の双方がランダムにデータを送信することで起きる信号の衝突や、衝突を検出した場合に送出される連続したJammer(0xFC)、及びその後のフレームの再送に対応した処理を行う必要がある。実際にCI-VをモニターしているとJammerはよく見られる。
　フレームの再構成にはステートマシンを使う。LT-R6には3つのステートマシンを内蔵している。通信用、メモリーデータ受信用、及びCI-Vプロトコル解析用だ。通信用は通常のLT-R6の動作に使う。この場合正常にフレームを受信した時だけ結果を上位ソフトに上げればよいが、ただし自分が送信したデータをモニターし、もし潰れていた時は衝突が起きているのでJammerを送出してアボート（中断）処理を行い双方の状態を整合させるようにしている。メモリーデータ受信用も同様だが制御に使うコードが違う。通信用、メモリーデータ受信用は送信部との連携がある分だけややこしい。
　一方プロトコル解析用はCI-Vの全てのデータを抜けなくキャプチャーするのみで単純である。解析用ステートマシンの状態遷移表を抜き出すと次のようになっている（作者独自の書式）。

     * STATE MACHINE
     *  State        OUTFR        SYNC        INFR         ABT
     *   /Input(event)
     *  SYN(FE)     +/SYNC         +/SYNC    x]+/SYNC    x]+/SYNC
     *  EOM(FD)     +/OUTFR      x]+/OUTFR   +]]/OUTFR   x]+/OUTFR 
     *  JAM(FC)   x]+/ABT        x]+/ABT     x]+/ABT       +/ABT   
     *  ELSE        +/OUTFR        +/INFR      +/INFR    x]+/OUTFR   
     *  TM-OUT     x]/OUTFR       x]/OUTFR    x]/OUTFR    x]/OUTFR
     * 
     *  SYMBOLS:
     *   -: abandon data
     *   +: accept data
     *   ]]: complete with success
     *   x]: complete with error

　 ステートマシンは状態を持ち、通信に伴って発生するイベントに対しアクション/次の状態を記述する。 OUTFR,SYNC,INFR,ABTが状態であり、SYN,EOM,JAM,ELSE,TM-OUTがイベントである。例えばフレーム受信中(INFR)にフレーム開始(SYN)を受信すると、受信は異常終了し（x]）データ(SYN)は取り込み(+)、次の状態をプリアンブル部(SYNC)とする。
　TM-OUTはフレーム受信中の一定時間内にフレームが完結しない場合の処理である。

　 ステートマシンは通信ライブラリから渡されるCI-V受信データを処理する。通信ライブラリはCI-Vデータを受信するとそれを受信バッファに積み、次にデータが入ったというイベントを発生する。このイベントを受けてスレッド（イベントディスパッチングスレッド）が実行され、その中でステートマシンを実行することになる（少し専門的ですがご勘弁）。スレッドを実行中に通信ライブラリは次のデータを受信する可能性があり、1バイト受信する度にイベントが発生する訳ではない事を含めてロジックを組む必要がる。リアルタイム処理ではここら辺りがややこしくていまだに理解不十分な点があるかもしれないが結果オーライで実装している。

　リアルタイム処理のデバッグは処理を止めて解析できないので厄介である。とくに以前ci-vの受信に使っていたrxtxライブラリーには受信したデータがライブラリーの中に詰まるような現象を起こす問題があり、それを発見し対処するのには長期間を要した。現在のjSSCライブラリーに変えてからはこれまでそのような問題はない。

続く

Google StreetView撮影車に遭遇

朝、車で走っていたら横道から見慣れない変な車が出てきた。
屋根の上方に青色のガスマスクみたいなものを乗っけてる。
横目で見ながら通り過ぎたが車の横に何か書いてあって、はっきり読めなかったがどうもGoogle StreetViewらしい。
家に帰ってドライブレコーダの画像を確認すると、やっぱりそうだった。

　以前、茨木県内でGoogle StreetView の撮影車に出くわしたときは目立たない車にミラーボールみたいなのを乗っけていたように思うが、システムが進歩したのかな。そういえばStreetView空白地帯だったうちの周りがいつの間にか埋まっている。家の中を覗かれているみたいで何か気持ち悪い。

　うちの車がStreetViewに再デビューする日は近いかもしれない。

JAVA有償化

　JAVA有償化という話が賑わっているがイマイチ実態が分かりずらい。話が有償化にどう対応するかばかりで、無料で使える範囲の情報が無い。オラクルの代弁者みたいな記事ばかりである。
　JAVAを使った開発を商売にしている企業では影響は甚大かもしれないが、半年ごとにバージョンが上がり旧バージョンのサポートが打ち切られても趣味でアプリを開発している私には痛くもかゆくもない。セキュリティ云々の話はJREの話だろうし、私が開発しているのはネットアプリじゃないので関係ない。私が欲しいのはプラットフォームによらない（オブジェクト指向を含む）強い型付けの構造化言語でグラフィック機能があるもの。
　資産の継承という意味ではOpenJDKという選択肢もあるらしいので、最後はここに逃げ込めば良いんだろう。

　そもそも、JAVAはコンパイラ(javac)と実行環境(java=JVM)から成る。コンパイラ（開発環境）はJAVAで書かれたプログラムをバイトコードというプラットフォームによらない中間言語に翻訳する。これはWindowsでもMACでもLinuxでも同じ機能である。実行環境はバイトコードをプラットフォームに合わせて実行する。これら全体がJDKとして提供され、実行環境のみで良ければJREとして提供されている。
　今回有償化されるのはどの部分か？これが分からない。JDKと書いてある記事もあるしJREも対象であるような記述も見受けられる。

　仕事で使っているNotesは裏でJAVAが動いている。少し前のバージョンは化石のような初期のJAVA 1.47だったように思うし滅多にバージョンアップされなかったが、こんな使い方 はもうできないのだろうか。
　

ゾンビのような OneDrive

　子供が1年ほど前に買ったノートPCがトラブったと持ってきた。

　起動するとSkypeやらOffice365やら幾つかのプログラムがインストール（起動）されているが不完全なまま放り出してある。Office365は金払えと言っているので調べてみると買取契約ではなく年額での支払いが必要なんだ。最初の1年間は無料なのがあざとい。資産が貯まってきた頃に人質にとる、あくどいお試し商法だ。今ではOSに組み込まれているZIP解凍機能まで有料化して使えなくなっているのには驚いた。多分ほとんどの人は騙されるだろうなぁ。携帯の4年契約と同じだ。そのほか使うことも無いソフトが山のようにバンドルされている。このエネルギーや経費は別の方向に使うべきだろう。外国メーカのようにBIOSレベルでの自己診断機能はぜひ備えておいて欲しい。

　で、OSのバージョンを見たらAnniversally Update（1607)で、すでにサポートが切れているのでとりあえず最新のApril2018 Update(1803)まで前に書いた手法で更新した。Core i7なのに1つの更新プログラムのインストールに数時間かかり、それが数回あって初めて1803になる。この作業に12時間くらいかかったかな。
　毎月の定例更新で1GB以上降ってくるうえに半年毎の更新では数GB、おまけにやたら時間がかかる。子供のポータブルWiFiでは無理だったかな。MSはどこまでユーザに負担を強いるんだろう。10分程度なら我慢できるが、何やっているか分からないまま延々と何時間も待たされる。電源管理をデフォルトのままにしているノートPCだとインストール中にスリープモードに入って再起不能に陥る可能性もある。外に持ち出すこともできない。言っている事とやっている事が真逆のように思う、というか個人は相手にしていないのか。夜間にインストールする手もあるが省エネに反するしね。

　で、ふと気になったのがOneDriveである。自分のPCはXPから更新を続けたものなのでドキュメント環境はXPのままWin10になっている。OneDrive等のネットストレージは自分の汗と苦労をMSに人質にとられそうなのでWin10のインストールと同時に削除し、どんなものかも理解していない。

　OneDriveが入ったPCでややこしいのは「ドキュメント」フォルダが２つあること。１つはお決まりの、「C:\ユーザ\<UID>\ドキュメント￥」であるが、OneDriveがインストールされていると 「C:\ユーザ\<UID>\OneDrive\ドキュメント￥」が出来て、こちらがデフォルトになるとともにミラーリングの対象とされるのだろう。
 　実際に子供のWin10 Homeを使ってみると、ファイルはデフォルトでOneDriveに保存するように仕組まれている。つまり「PC\ドキュメント￥」の実体はOneDriveの方になっているのである。でも「C:\ユーザ\<UID>\ドキュメント￥」も表示されている。

　不要なのでOneDriveを停止し、アンインストールした。

　するとエクスプローラでの見え方が変わった。「PC\ドキュメント￥」はOneDriveの方になったままである。一方「OneDrive」や「C:\ユーザ\<UID>\ドキュメント￥」はエクスプローラの木表示から消えてしまって「C:\」から見ていかないと辿り着けず実用に耐えない。結局、もっと徹底的にやらないと「C:\ユーザ\<UID>\OneDrive\ドキュメント￥」から抜け出せないことが分かった。
　MSも遅ればせながらMac OSXみたいな仮想化のカラクリを組み込んだんだなぁ、と感じるが、数GBある月例インストーラの重さは如何ともし難い。
 
　ネットワーク共有もデフォルトで有効になっているのも気に入らない。即OFFにした。