Windowsのショートカットとリンクの違い

 前の投稿で、Windowsのショートカットとリンクは違うようだと書いたが、その違いを実際に試してみた。

まず、実際に同一フォルダ（E:\CAR）のショートカットとリンクを作成してみた。リンクの作成は管理者権限のcmdで次のコマンドを実行した。

C:\work>mklink /D .\CAR-ln E:\CAR
.\CAR-ln <<===>> E:\CAR のシンボリック リンクが作成されました 

リンクの実体はシンボリックリンク、それならショートカットと同じはずだと考えたがエクスプローラの表示は異なっている。

 明らかな違いは、ショートカットには1KBと表示される実体（ファイル）が見えているがリンクにはそれが無く、あたかもそこにリンク先の実体（フォルダ）があるように表示されており、見かけ上UNIX(Linux)のリンクのように機能している。UNIXのシンボリックリンクならショートカットと同じく実体がある筈だが、Windowsではそれは隠されているか別のカラクリで実装されているのだろう。

各々のプロパティを見てみると、

となっている。やはり上で述べたようにリンクはシンボリックリンクではなくUNIXのリンクのように見えている。

リンクではリンク先のファイルが読み取り専用のように見えるがこれは変更できた。

 Windowsでショートカットとリンクは同じように見えてシステム上の扱いは別物だという事がわかった。Windowsには別のカラクリとしてジャンクションもあるようだしショートカットとリンクの細かい話もあるが、それらはCopilotにでも相談して欲しい。

 

〔参考〕UNIX(Linux)の リンクとシンボリックリンク

UNIXのファイルの実体は i-nodeというデータに1:1で紐づけられている。 i-nodeは i-node番号というユニークな番号を持っている。UNIXのディレクトリはファイル名と i-node番号の対応表にすぎない。従って１つの i-nodeに対応したファイル名を複数作ることができ、これがリンクである。各i-nodeにはこの実体がいくつの名前と紐づけられているかを表すリンク数というパラメータがあり、これが0になるとその実体は消去される。

UNIXのファイルはファイルシステムという単位で管理されている。UNIXのファイルシステムは、ストレージ内の管理構造という意味ではWindowsのドライブに相当するものと考えられるが、UNIXにドライブの概念は無く、UNIXのファイル全体は1本の木構造をしている。複数のファイルシステムを扱う場合、根元（root）から立ち上がった木の何処かの枝に他の木を接ぎ木（mount）する。

i-nodeはファイルシステム毎に独立しているため、ファイルシステムが異なるとリンクは出来ない。これを可能にするのがUNIXのシンボリックリンクであり、Windowsのショートカットと同様にパスを示してファイルやディレクトリ（フォルダ）を指定する。

 一方、私はWindowsのファイルについてFat32とかNTFSという名前は知っているが 内部構造は全く理解していない。

C:ドライブが満杯

 家族のPCの C: ドライブ（500GB）がほぼ満杯で動きが悪い（これ以上写真を保存できない）との相談を受けた。

どうせ写真や動画を撮りまくってるんだろうと思いながら内容を確認すると、C: ドライブの大部分は iTunes が作成した iPhone のバックアップファイルで、何と計286GB もあった。そのほか iTunes が使っていた一時ファイルが約32GB あり、 iTunes の無駄使いが過ぎる。デスクトップにも 50GB 近く使っていてその合計が 368GB にもなる。つまりC:ドライブの半分以上が本来の目的意外に食われている事になる。

iPhone/iPad のバックアップファイルは機種毎に作成されるようで、それらを買い替える度に巨大なファイルが残り、意識的に掃除しない限り残り C: ドライブを圧迫する。iPhoneの バックアップファイルはユーザデータ（写真と動画がメイン）をバックアップしているようだが、最近の大容量化した iPhone を使う上では盲点だろう。1TBの iPhone を買うならそのために PC に １TB 近いストレージを用意する必要がある。こんなバックアップファイルは少なくともC: ドライブからは追い出す必要があると思う。C: ドライブはパフォーマンス向上のため SSD 化しているし、その大部分をほぼ使う可能性が無いバックアップに提供するのは勿体ない。

Copilot に相談したら、iTunes にはバックアップファイルの場所を変更するメニューは無いので（これは明らかに欠陥で、Apple に何とかして欲しい）リンクを使えとの事。ちなみにiTunes が作るバックアップファイルの格納場所には2種類あるようだが私の場合は次の場所だった（ちなみに MobileSync は隠しフォルダなのでフォルダーオプションを変更しないと表示されない）。

 C:\Users\ユーザー名\Apple\MobileSync\Backup\

そこでバックアップファイルを D: ドライブの中に作った次のフォルダへコピーし、

 D:\Apple\ios-backup\Backup\ 

そのフォルダのショートカットを作って元のフォルダに入れた（このとき元の Backup フォルダは消して（または別の名前にリネームして）使われないようにした）。これで上手く行くはずだ。

iTunesを立ち上げ「編集」->「環境設定」->「デバイス」を確認するとコピーしたバックアップファイルは認識されていない。iPhone を接続してバックアップを行うとC:ドライブにはBackupというショートカットに加えて消したはずの Backup という同名のフォルダが作られ、その中に新しいバックアップファイルが作られている。これを何度か繰り返して、埒が明かない。

なぜショートカットが認識されないんだ？ネットで成功事例を見ると、皆さんリンクはコマンドで作成していて、ショートカットを作成＆コピーしてはいない。結果に違いはないように思うがこの方法を試しにやってみるか、と次のコマンドを管理者権限で cmd に与えた（ちなみに、この mklink は cmd の内部コマンドなので PowerShell ではエラーとなる）。

mklink /D "C:\Users\ユーザー名\Apple\MobileSync\Backup"  "D:\Apple\ios-backup\Backup"

iTunes を立ち上げると何故か過去のバックアップファイルをちゃんと認識してる。そしてバックアップも正しく D: ドライブの方へ格納される。理由は不明だがこれで上手く行ったようだ。

（終り）

追伸：Windows のショートカットとリンクの違いについては次の投稿「Windows のショートカットとリンクの違い」を参考に。

携帯内に混在する2つのPontaポイントの統合

 私の携帯（iPhone）内には10年以上前にLawsonで作ったカードをそのまま携帯アプリに移行したPontaポイントと、

AU Payアプリに紐づけられたPontaポイントが混在していた。

最初はこの違いに気づかなかったがポイントの数が違うことから2つが独立していることに気づいた。

Pontaのホームページ（PontaWeb）を見るとこれらを1つに纏める方法も書いてあるが、Pontaにも色々あるようで私がどれに該当するのか、或いは場合分けが多く、私の場合にどうすればよいのか分かりずらかった。じっさいLawsonで作ったPontaカードを携帯アプリに移行したものは今はRecruit IDに関連付けられていることを後に認識した。AU Payアプリに紐づけられたPontaは意識しないまま、いつの間にか登録されていた。

AU Pay ではPonta IDの切り替えも出来るようだが、これをやると統合は出来ず片方のPontaポイントを失う事になる。 

実際に手続きを進めると上手く行きそうなのに最後はエラーで駄目になる。手続きの途中でエラーで「失敗しました」と言われても何が悪かったのか原因も分からない。これまで時々挑戦しては失敗を繰り返してきたが、やっと成功したのでメモとして残す。

携帯アプリのPontaカードはRecruit IDに紐づけられていて、これをPonta-1とする。AU Pay に紐づけられたPontaカードをPonta-2とする。それぞれのカードは独立したPonta ID及びそれに対応して独立したPontaポイントを持っている。

〔Step-1〕 ２つのカードの会員情報を合わせる（同じにする）。氏名や生年月日、電話番号等で、これが違っているとStep-2の手続きがエラーになる。私の場合、古いPonta-1は固定電話で登録していたので携帯に合わせた。
〔Step-2〕PontaWebにログインしてPonta-2のポイントをPonta-1に統合する。この手続きが済むとPonta-2は使えなくなる。
〔Step-3〕AU Pay でPonta-2との連携を解除する。Step-2の時点でAU Pay からPonta-2へはアクセスできなくなっているが、この解除を行わないとStep-4がエラーになる。
〔Step-4〕 AU Pay でRecruit IDを使ってPonta-1と連携させる。

これで携帯内の２つのPontaポイントは１つに統合された。 

メデタシ、メデタシ 

（上の記述の中に何点か誤りがあったので訂正しました） 

 

LiDARを使った距離計（その３）

 実際にソフトを組むにあたって最初に問題となったのは通信速度だ。当初データシートの記述を頼りに 460800bps と考えていたが、本当にそうなのか？Copilotは違う値（115200bps）を第一候補として答えてくるが・・・？

TSD-10に電源を入れると基板面で微小なLEDが点滅を繰り返していた。どうも電源ONと同時に連続測定をスタートしているようだ。こういったセンサーはスタートコマンドを送るまで測定を始めないかと思っていたが違ったようだ。それなら測定データをUARTで連続送信しているだろうから、その信号で通信速度を確認すればよい。

オシロスコープでTSD-10のUARTの波形を観測すると1ビットが約2μsに相当するようで、デフォルトの通信速度は 460800bps で間違いないようだ（計算上は1ビットが2.17μsになる）。

そこでPIC16F15325の内蔵UARTを使って近い速度の信号を作ってみたが上手く行かない。内蔵の16MHzや32MHzのクロックを分周して合わせてみても速度誤差が8.5%出てしまう。UARTは多少の誤差は許容できるはずだが、ここまで違うと無理のようだ。そこで内蔵UARTを使わず、ソフトで直接ポートを駆動してUART信号を作る事にした。送信するデータの1ビットずつを取出し、それに従ってポートをON/OFFるする。この方法で作った実際の波形を観測すると、オーバーヘッドが大きく1ビットに最低3μsほどかかり2.17μs迄は下がらなかった。そこで最後の手段として、プログラム中にビット出力命令を直接並べて（ハンドエンコードして）実行する事とした。試しに1/0を交互に出力させて観測するとビット出力命令の実行時間は0.124μs程度（Fosc/4に相当）なので2μs程度の遅延を挟めば丁度良い信号を生成できる。そうやって出来上がったプログラムの1バイト送信分が次のようなものである。

     // 1 - 0x5A
    LATAbits.LATA4  = 0;   _delay3(5);  // Start bit 
        LATAbits.LATA4  = 0;   _delay3(5);  // b0        
        LATAbits.LATA4  = 1;   _delay3(5);  // b1      
        LATAbits.LATA4  = 0;   _delay3(5);  // b2      
        LATAbits.LATA4  = 1;   _delay3(5);  // b3      
        LATAbits.LATA4  = 1;   _delay3(5);  // b4      
        LATAbits.LATA4  = 0;   _delay3(5);  // b5      
        LATAbits.LATA4  = 1;   _delay3(5);  // b6      
        LATAbits.LATA4  = 0;   _delay3(5);  // b7      
    LATAbits.LATA4  = 1;   _delay3(10);  // Stop bit     
 

Stop bitを長めにとっているのは次のバイトのStart bitまでの時間に余裕を持たせ多少の同期ずれを回復できるようにするためである。 このプログラムは上手く機能した。これで測定の停止(Stop)とボーレートの変更は出来るようになった。ビットレートを一旦9600bpsまで落とせば後はPIC内蔵UARTでも余裕をもってコマンドを送信できる。

もう1つ問題になったのはTSD10からのデータが全く受信出来なかった事である。色々テストした結果判明した原因は、受信に使ったPICのA5ポートが全く機能しなかった事である。以前同様なトラブルが別のPICであり、解決策も以前書いたが今回はそれでも上手く行かなかった。色々試したが結局諦めて代わりに基板を改造してC5ポートを受信に使う事で解決した。 

TSD10の仕様によると測定データは毎秒50回（20ms毎に）送られてきて、精度は±5cm、ブラインドゾーン（無感距離）が5cmある。また分解能（測定結果）がmm単位なので使いづらい。そこで複数回（とりあえず10回）の測定の平均をとり、最下桁を丸めてcm単位を結果とするようにした。

実際に周囲の対象物の距離を測定してみるとブラインドゾーンはほとんど無く、測定値には10cm位のオフセットがあるがほぼ直線に乗っている（ただ30cmところだけ原因不明のずれがある）。

オフセットについてはTDS10の個体毎に異なると推察されるのでコマンドで設定できるようにした。またデータシートによると反射の無い状態（測定範囲外）では65535mmが送られてくるよう記載されているが、実際にTSD10を空に向けてみると最大探知距離である10000mmが送られてきてデータシートと異なる。

超音波センサーとLiDARを比べてみると、 超音波センサーは測定値に少しのふらつきが見られることもあるがLiDARは比較的安定しているようだ。これは統計処理の違いに起因するかも知れなく、これが問題になる場合は更なる検証が必要だろう。

TSD10は指向性が鋭いうえに赤外線は目に見えないので、どこの距離を測定しているか分かり辛い。レーザーポインタを併用すれば分かり易くなるが、逆にレーザーポインタが明るすぎて目に辛い。幸いレーザポインタの消費電流は多くないのでPICで直接駆動できる。レーザーポインタをソフト的にON/OFF出来るようにすればもっと使い易くなるだろう。

さて、これを何に使おうか？ 

（終り） 

 

LiDARを使った距離計（その２）

 

 修正した基板は次の通り。パスコンはSMD（表面実装部品）として基板の裏面へ移した。LiDARの赤外ペンシルビームはどこを指しているか分かりにくいので、J3としてレーザポインタを追加するための+5Vの分岐を追加した。

発注して1週間も経たずに修正版の基板が届いた。昨年まではSHENZHEN(深圳)から関空へ送られ国内配送されていたが、今年になって（理由は不明だが）SHENZHEN⇒香港⇒羽田という配送ルートに変わったようだ。到着が少し早くなったような気もする。

これを組み立てて、次の写真の様になった。左がLiDARインターフェイス、右が超音波測距センサーインターフェイスだ。超音波測距センサーの動作も確認できた。

ここからLiDARインターフェイスのソフトの制作について検討する。TSD-10のインターフェイスはRS-232Cだが交換するコードは文字ベースではなくバイナリーでNULL(0x00)を含む。転送速度がデフォルトの460,800bpsだと毎秒46,080バイト、22μs毎に1バイト転送され、これを処理する必要がある。結構シビアだ。転送速度の変更はコマンドで可能なので、初期化の段階で9600bpsまで速度を落としてみる事とした。

 ソフトの製作には時間がかかりそうなので、今回はとりあえずここまでで、次回へ続く。

（続く） 

 

LiDARを使った距離計（その１）

 超音波距離計は超音波センサーの前に膜など何らかの空気以外の物体があるとそこで音が反射されたり減衰したりして上手く計れない。そこでLiDAR距離計を試してみる事にした。LiDARは赤外線を使って反射物までの光の往復時間を測ることで距離を求める。1nsに光が進む距離は30cmだから往復で見ると15cm。1cmの分解能で距離を測るためには1/15nsの時間分解能が必要である。

秋月で売っているLiDAR距離計を見てみると、水平スキャンが出来るタイプと出来ないタイプの2種類あり、前者はロボット掃除機に使われているようなもので探知距離が1m程度と短い割に試すには高価である。そこで水平スキャン機能の無い単純なTSD-10というものを買った。これは最大10mまで計れるもので５ｍ以内の精度は±5cm、それより以遠は1%である。大雑把に言うと1/3ns単位で時間を測定しているという事か。

 

指向性については超音波距離計の半値幅が30度あるのに対しTSD-10は3度しかないので ペンシルビームみたいな特性で、ターゲットの方向に正確に向けないと正しく計れない。

 TSD-10を使う上でもう1つ検討を要するのはUARTインターフェイスの通信速度である。デフォルトで460,800bpsと高速だ（これは9600bpsの48倍）。UARTを動作をさせるためには通信速度の16倍の周期のクロックが必要になる。460,800bpsの場合を計算してみると、14.7MHzのクロックが必要だ。PICの内蔵発信器で得られる周波数で最も近い周波数は16MHzなので8%の誤差がある。秋月では外付けの水晶で14.31818MHzの物を売っていて、これを使うと誤差は2.6%となる。内蔵発信器で上手く行かない場合は外付け水晶を使ってみるか。

使うPICの種別であるが、TDS-10とHOSTの両方ともUARTインターフェイスを使うので2つのUARTを内蔵して手頃なPIC16F15325を使うこととし、回路を設計すると共に基板を発注した。

なお、回路・基板の設計に当たっては、この基板を超音波距離計にもそのまま流用できるようピン配置の共通化を図っている。つまり14ピンのPIC16F15325を8ピンのPIC16F18313に挿し替えることでそのまま超音波距離計にも使えるようにした。

発注後、2日で基板は出来上がったが、その後春節と重なったため配送業者のピックアップが1週間ほど遅れている。以前と同じだ。結局、発注から半月ほどかかって届いた。 

届いた基板を組み立てると、とんでもない間違いに気づいた。センサーと接続するコネクタを逆向きに設計していた。これでは超音波センサーが後向きになってしまう。 そこで修正して再発注した。送料込みで3.3ドル、この安さがチェックを疎かにしてミスを誘発する原因かもしれない。なお上の回路図は修正版に挿し替えている。

（続く） 

LT-R6のバグを修正しバージョン0.24として公開しました。

 LT-R6 バージョン0.23以前のバージョンでは「新規作成」メニューでICFデータを初期化した場合、BAND領域に誤った値を書き込むバグが存在しました。これを修正しバージョンを0.24として公開します。

バージョン0.24のjarファイルのダウンロードはこちらから。 

使い方は、ダウンロードした ltr6-0.24.jar ファイルを ltr6.jar とリネームしLT-R6のフォルダに入れてください。この時、フォルダ内の既存の ltr6.jar は名前を変更するか別の場所に移してください。

今回のバグにより「新規作成」メニューで初期化したICFデータを編集・アップロードしたとき、VFOモードでBANDを切り替えると各BANDとも最初は145.000NHzと表示されます。

 なお、ICFデータ中の BAND領域についてはこれまで解析されておらず、ユーザからの指摘を受けて初めてBAND領域である事を確認できたものの、この領域の各データの意味や役目は未解析です。従ってLT-R6はBANDデータの編集機能は実装していません。

 以上