のほほ~んなブログ - gooブログはじめました!

< 田舎生活から情報発信 > < 都会では味わえない風景満載!>

広告

※このエリアは、60日間投稿が無い場合に表示されます。記事を投稿すると、表示されなくなります。

MTL (MFC on ATL/WTL)

2017年05月10日 09時39分28秒 | Timidi95 シリーズ
Timidi95 シリーズは、32bitモジュールと64bit モジュールが有ります。
32bitモジュールは VC6(VisualStudio 2000)でコンパイル、
64bitモジュールは VC12(VisualStudio 2013)でコンパイルしています。

VC6でのコンパイルは、WindowXP や 旧Windows での動作と、
.exe ファイルのサイズ縮小のために使用しています。

VC6 MFC ライブラリは、DLL リンクを使用しています。
スタティックリンクだと .exeファイルサイズが大きくなります。

TimidiDR では、MFC ライブラリをカスタマイズしてサイズ縮小し使用しています。

64bitモジュールでは、MFC DLL を使用していましたが、
VC のバージョンを変える毎に MFC DLL を再配布する必要がありました。
MFC スタティックリンクでは、VC6 に比べて .exeファイルサイズが非常に大きくなります。

MFC ライブラリをカスタマイズしてサイズ縮小するのは、VC のバージョン依存が大きく
かなり大変です。

そこで、ATL/WTL の様にヘッダファイルだけでコンパイルできる MFC ファイルを作成しました。
MTL (MFC on ATL/WTL) です。
https://github.com/mohishiSoftkoubouINUI/MTL

MTL は VC6 MFC の良く使用されるクラスの機能を代替します。
MFC プロジェクトはスタティックで作成し、stdafx.h と stdafx.cpp を MTL 対応に書き換えます。

MTL 対応プロジェクトは、MFC DLL でコンパイルしたり、MFC スタティックでコンパイル
デバッグする事も可能です。

MTL はヘッダファイルのみで構成しているので、機能を書き換えたりする事もできます。
VC12 MFC スタティックリンクより、ファイルサイズが小さくなった事が何より魅力です。
コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

Timidi95 シリーズ 64bitで AVX 最適化したけれど

2013年08月09日 17時27分49秒 | Timidi95 シリーズ

日中の暑さが家の中に溜まり始めました。
夜になると外の風は気持ちが良いのに家の中は暑いままです。

以前にもブログで書きましたが、Timidi95 シリーズの TimidiS4 と TimidiDR は 64bit Windows アプリとしてネイティブに対応しています。

VC の最適化で AVX をオンにしてます。
プログラムでAVX 最適化しやすいように、コードを並べて書いていますが、逆アセンブルコードを探しても AVX 命令が見つからないです。

浮動小数点演算の高速化を期待して AVX 有効にしています。
しかし今の所 Timidi95 シリーズの 64bit では効果は無いようです。

折角 AVX 最適化を有効にしているので、最適化が出来るようにしたいです。

コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

VC 32bit 64bit ソース互換です。

2013年06月20日 17時12分46秒 | Timidi95 シリーズ

今日も朝から見事に雨でした。
小ぶりの間に外に出ましたが、温度は低めで湿度が高く、居心地悪いので室内に戻ります。

VC の 64bit コンパイルとデバッグもだいぶ慣れてきました。

Timidi95 シリーズは、古い開発環境と、新しい開発環境で同じソース(.cpp)をコンパイルしています。

古い開発環境ソースから、新環境共用ソースにするのに修正が必要でした。

古い開発環境では 32bit 専用なので、sizeof(int)  == sizeof(void*) でした。
64bit環境では、sizeof(int)  != sizeof(void*) です。

Timidi95 シリーズでは音の出力を行っています。
例えば、waveOutOpen 関数を使用して音を出力したとします。

旧環境
MMRESULT waveOutOpen(
  LPHWAVEOUT phwo,         
  UINT uDeviceID,          
  LPWAVEFORMATEX pwfx,      
  DWORD dwCallback,         
  DWORD dwCallbackInstance,
  DWORD fdwOpen            
);

新環境
MMRESULT waveOutOpen(
  LPHWAVEOUT     phwo,      
  UINT_PTR       uDeviceID,
  LPWAVEFORMATEX pwfx,      
  DWORD_PTR      dwCallback,
  DWORD_PTR      dwCallbackInstance,
  DWORD          fdwOpen   
);

DWORD が DWORD_PTRに変わっています。
コールバック関数を指定するのに、(DWORD)コールバック関数の様にキャストしています。
64bit 対応するためには、(DWORD_PTR)でキャストする必要があります。

この様な調子で INT -> INT_PTR、UINT -> UINT_PTR、DWORD -> DWORD_PTR にし直す必要がありました。
型のソースの修正部分は typedef を使用して 共用ソースにしてあります。

TimidiDR はドライバなので、コールバック処理や、データ渡しでのキャストが多くあります。
共用前ソースでは数多くのコンパイルエラーがでました。
さらに 64bit 専用の修正があり、共用ソースに纏めるのに苦労しました。

現在でもソース修正は古い開発環境で編集しています。
新しい環境のエディタの方が機能が多いですが、慣れでしょうか、古い開発環境のコンパイルとデバッグが使いやすいです。

コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

VC 64bit コンパイルです。

2013年06月19日 16時24分55秒 | Timidi95 シリーズ

朝、雨降っていないなぁ?と思っていたらやっぱり降りだしました。
午後になるにつれ雨脚が強くなり、家の中で窓越しに外を見ています。

Timidi95 シリーズの TimidiS4 と TimidiDR は 64bit Windows アプリとしてネイティブに対応しています。

Timidi95 シリーズの 32bit 版は、昔の Windows 上でも動作するように、古い開発環境で最適化し作成しています。

一方 64bit 版は、新し開発環境と 64bit  Windows に限定し、さらなる最適化を行い、高速化と低 CPU 負荷を実現しています。

32bit 版も新しい開発環境上で作成したくなりますが、新しい開発環境上で作成すると昔の Windows 上で動作しないアプリケーションが出来上がります。

古い開発環境上でも十分論理の最適化を行っていますので低 CPU 負荷を実現しています。
しかし 従来命令の 32bit と 拡張された 64bit では、コンパイラの最適化の度合いが違います。

Vcassemble
32bitと64bit の VC アセンブル出力を並べてみました。

64bit では浮動小数点演算を従来命令を使用しない最適化指定をしています。
レジスタ上での演算が増え、メモリアクセス回数が減ります。

Timidi95 シリーズの発音処理では、整数や浮動小数の繰り返し演算が多いのでメモリアクセス回数が減ると高速化の度合いが大きくなります。

デバッガ上で逆アセンブルを表示してトレースする事が多々あります。
64bit Windows 上で 64bit 版 Timidi95 シリーズをデバッグすると、逆アセンブルコードから32bit版より明らかに高速化されているのが分かります。

コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

ノートPCのサウンドです。

2013年05月11日 17時10分05秒 | Timidi95 シリーズ

朝から雨で一日中室内で過ごしました。
晴天続きで室内の空気は乾燥したままなので、雨でも過ごし易いです。

ノートPC の様に、小型のスピーカで音楽を聞くとステレオ再生でも、ただ音が鳴っている程度に聞こえる事が良くあります。

Maxxaudio_2
ノートPC によっては、MaxxAUDIO と FR-Port のように、音を少しでも聞き易くする工夫がされています。

FR-Port は YAMAHA の技術で、スピーカから出力される音域を広げる効果があります。
MaxxAUDIO は、低高音の補正と音場を広げてくれます。

小型スピーカーのノートPCだと音量が小さくスピーカーの付近に近づかないとステレオ感が感じ難いものが、MaxxAUDIO の働きでノートPC の通常の手前の位置でステレオ感と音の広がりを感じる事ができます。

MaxxAUDIO を効かせると多少作った音?と感じない事もないですが、BGM で音楽を流して聴くにはとても良い効果があります。

コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

Windows8 64bit で開発です。

2013年05月06日 16時58分31秒 | Timidi95 シリーズ

連休最終日も暖かい一日でした。
花壇の水やりと草取りは日課です。

TimidiS4、TimidiDR は 64bit 版を作成しました。
開発は Windows8 Pro 64bit 上で行っています。

Windows8 と言えば スタート画面のある Metoro UI です。
開発環境は、従来のデスクトップ画面を使用しています。

デスクトップ画面は、スタートボタンが無いので、タスクバーに最低限のアイコンをピン留めしました。

W8taskbar
スタートボタンにあったアプリケーション一覧の代わりに、エクスプローラーにプログラムをピン留めしました。
プログラムはスタートボタンで表示されるプログラム一覧のフォルダを表示します。

スタート画面は...Windowsストアアプリを全てピン留めを外し、普段使用するソフトだけを残しました。

スタート画面の右クリックで全てのアプリを表示起動する事ができますし、デスクトップ画面のエクスプローラーにピン留めしたプログラムからアプリケーションを起動する事が出来ます。

Windows8 の起動、終了は早いですが、普段の電源入り切りは休止を使用しています。
ノートPC を開発環境として使用していますが、実用的な速さです。

Timidi シリーズのアプリケーションは、Windows8 Pro 64bit で動作する事を確認しました。

コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

TimidiDR の 64bit 化です。

2013年05月02日 17時07分46秒 | Timidi95 シリーズ

今日も良い天気となりました。
でも北風が冷たく感じます。
暖房は相変わらず朝から使用しています。

TimdiS4 の 64bit 化は上手く行きました。
今度は TimdiDR を 64bit しています。

TimdiDR は、ユーザーモードで動作する MIDI ドライバです。
既存の TimidiDR を 64bit 環境で実行すると、WOW64 上で 32bit ドライバとして動作します。
64bit アプリケーションからは WOW64 配下の TimidiDR は、呼び出す事が出来ないです。

64bit 環境には、 64bit ドライバが必要です。
TimdiDR を 64bit 化してみたら、WOW64 配下の 32bit アプリケーションから、64bit 側の TimidiDR を呼び出す事が出来ませんでした。

そこで WOW64 配下から、64bit 側の TimidiDR を呼び出す 32bit ドライバが必要となりました。

試行錯誤をしましたが、TimidiDR 64bit ドライバは無事動作し始めました。
TimidiS4 もそうでしたが、64bit に最適化すると CPU 負荷が下がります。

開発環境として、64bit Windows は、思ったより使いでがありそうです。

コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

64bit 開発環境と TimidiS4 です。

2013年04月30日 16時32分00秒 | Timidi95 シリーズ

朝から雨、その後どんより曇り空です。
外にでても、雨が降りだしそうで長居はしないです。

Windows8 + Visual Studio 2012 の開発環境は、インストールして一ヶ月が経ちました。
漸く開発に必要なソフトが Windows8 上でも動き始め、ソフト開発が出来つつあります。

Windows8 は 64bit なので、64bit ネイティブアプリケーションを VC で試しに作ってみました。

TimidiS4 をVisual Studio 2012 でコンパイル出来るようにし、最適化を 64bit + AVX で行いました。

64bit Windows でも勿論 32bit アプリケーションは動作します。
そこで、TimidiS4 32bit 版と、64bit版で CPU負荷の比較を行ってみました。

Timidis464
青線が 32bit版、赤線が 64bit 版です。
CPU負荷の高い、32パートの MIDI ファイルを同時再生しました。

32bit版でも論理の最適化を行い CPU 負荷を下げていました。
64bit 版は更に CPU 負荷が下がりました。

64bitではレジスタ本数が増えた事と、浮動小数点演算の最適化が効いたようです。
アセンブラ出力をしてみるとコンパイル結果が分かります。

コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

寒い一日でした。

2013年04月20日 18時46分23秒 | Timidi95 シリーズ

朝から曇りでした。
昨日の暖かさが嘘のように寒い北風が吹きました。
暖房はまだまだ活躍しそうです。

仕事で Windows 8 の 64bit 版を使用してプログラム開発しています。
仕事がひと段落したら、64bit アプリケーションの実験をしたいです。

取り合えず TimidiS4 あたりを 64bit 化して、開発環境とコンパイル性能を確かめたいです。

ここの所忙しいので、仕事以外の時間が少ないです。
でも花壇の様子や水やりは毎日確認しています。

コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

MIDI ファイル読み込みの高速化です。

2013年03月14日 16時19分13秒 | Timidi95 シリーズ

昨夜の激しい雨で車の花粉が洗い流されたと思っていました...。
予想以上に花粉が残りガラスはまだら模様になってました。
日中は冷たい北風が吹いていて寒かったです。

以前 TimidiS4 に演奏リストウインドウを追加しました。
一覧にMIDI ファイルの演奏時間を表示するのは、処理時間が掛かります。

MIDI ファイルの読み込み高速化は何度も行っていますが、再び高速化をしています。
論理は完成し、動作も順調です。

高速化の最後の手順でアセンブラ出力を行い、無駄なレジスタ参照やメモリアクセスが無いか確かめます。

Readmidi
C++で記述して、ファイル出力でアセンブラ出力を有りにしてます。
C は低レベル表記が可能な言語ですが、オプティマイザに高速化を任せておいただけでは満足いくコード出力は得られないです。

プロセッサにあった論理表記をして、オプティマイザの出力を確かめます。
プログラム全てのコード出力を確認するのは無駄な時間が多いので、ボトルネックになりそうな部分だけを念入りに調べます。

こうしてオプティマイザの癖が分かると、より高速なプログラムを記述できるようになります。

コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

TimidiS4 の演奏リストウインドウです。

2013年02月27日 17時06分54秒 | Timidi95 シリーズ

日中はとても暖かくなりました。
昨夜は雪が降り、その後雨となりましたが、午後の晴れ間に温度が上がり風も無く気持ち良く過ごせました。

TimidiS4には MIDI ファイルの演奏リスト機能があります。
今回新たに演奏リストウインドウを作りました。

Timidis4playlist
演奏リストウインドウはドッキングとフローティングウインドウにする事ができます。フローティングウインドウではウインドウの大きさ変更が可能です。

従来からファイル一覧での演奏リスト表示はありました。

演奏リストウインドウでは、MIDI ファイル中に含まれるタイトルと、演奏時間を表示する事ができます。

タイトルは MIDI ファイルに含まれる先頭トラックのトラック名を探して表示します。この処理は比較的分かり易いです。

MIDI ファイルの演奏時間を求める処理は、結構大変です。
MIDI ファイルは、音符の発音長さをカウント数で決めます。
カウントの単位を決めるため、MIDI ファイルの中に4分音符のカウント数が定義してあります。
カウント情報だけでは発音を時間に換算できないため、MIDI ファイルの中にテンポとして4分音符の発音長さを us単位で表す数値があります。

演奏時間を求めるためには、MIDI ファイルの中の音符のカウントをテンポを基に時間に換算して、全て足し合わせる必要があります。

結局 MIDI ファイルを全て読み込み、処理する必要があります。
しかも演奏リストウインドウに表示する項目数だけ繰り返します。

処理論理を高速化してようやく実用的に使えるようになりました。
MIDI ファイル中にタイトルが含まれていない事が多々ありますが、演奏時間と一緒に表示できると選局するのに便利です。

コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

Windows の MIDI 音源と音域比較です。

2013年02月26日 16時42分49秒 | Timidi95 シリーズ

昨日の寒さに比べ、風が無く暖かく感じる一日となりました。
朝は氷点下 8度位まで下がりましたが、日中は外に出て日差しを浴びるのが心地よかったです。

Windows には 標準で MIDI 音源が入っています。
MIDI音源名は Microsoft GS Wavetable Synth のような名前です。

Windows Media Player で MIDI 再生すると、特に変更しない限り、Microsoft GS Wavetable Synth が初期状態で使われるので、馴染みの再生音だと思います。

この Windows の音源と Timidi95 シリーズの音源の出力を周波数分析してみました。

Gssynth
上図が Windows の音源、下図が Timidi95 シリーズです。

良く知られている事ですが、Windows の音源は 22050Hz 再生です。すると再生可能な音域は 11025Hz までです。
人間の高音側の可聴域は 20000Hz(20KHz) と言われているので、Windows の音源では 11025Hz より上の高音をバッサリ切り捨てている事になります。

年を取ると高音域の聞こえが鈍くなりますので、そんなに気にならないのかもしれません。

Timidi95 シリーズでは 44100Hz での再生をサポートしています。高周波側の音も再生できます。聞き比べると高周波側の音があるのは自然で良いです。

しかし Windows の音源と Timidi95の音源は異なるので、楽器音に差があります。
Windows の音源に聞き慣れていると、Timidi95の音源は異質の音に感じるかもしれません。

コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

ツールバーのアイコン追加です。

2013年02月11日 16時53分46秒 | Timidi95 シリーズ

朝起きたら外は一面雪で真っ白でした。
雪はお昼まで降り続きましたが、午後は天気が回復し太陽の日差しでどんどん融けています。
この雪解け水が凍ると路面凍結が怖いです。

TimidiS4、WaveST、TimidiDR 中の PlayDR のツールバーアイコンの追加を行っています。
再生中のMIDI ファイルから WAVE ファイル変換保存や、プレイリストの読み込みなど追加しています。

Toolbar
追加したツールバーアイコンで、赤丸はWAVE ファイル保存、緑丸は演奏リストの読み込みです。
画面上半分が TimidiS4、下半分が WaveST のツールバーです。

メニューから選択すれば同等の事が出来ます。
良く使用しそうな機能なのでツールバーにも追加しました。

Timidi95 シリーズは現在5本のプログラムで構成しています。
少しずつ修正を加えています。

コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

Windows Theme 対応です。

2013年02月10日 16時24分38秒 | Timidi95 シリーズ

風は強いですが、昨日より日差しが強く感じられます。
寒さは相変わらずですが、若干1度位は昨日より暖かいです。

WindowXP 以降には、デスクトップ等の配色に Windows Theme があります。
画面に表示するコントロールなど、カスタマイズできるようになっています。

色々なパソコンを起動してみると、パソコン毎に何となく配色が違うなと感じた事があると思います。

Timidi95 シリーズでは、Windows Theme 以前の従来表示を使用してきました。
試しに Windows Theme で表示出来るようにしてみました。

Windowstheme1

Windowstheme2
Vista で撮影しました。画面の雰囲気が変わっていると思います。

Windows Theme 対応の標準ツールバーはフラット表示ですが、再生ボタンなどの位置が分かり難くなってしまったので、ツールバーだけ従来表示としました。

レイアウト等微調整して、Windows Theme 使用時の画面にだいぶ落ち着きがでました。
次回のアップロードからは、Windows Theme 対応版となります。

Windows Theme 対応していない、Windows 2000 以前では従来通りの表示となります。

コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

普段見聞きする情報精度と数値計算です。

2013年01月28日 16時58分07秒 | Timidi95 シリーズ

寒い寒いと言いながら1月も末に近づきつつあります。
寒中ですので平均気温では寒さのピークですが、最低気温ならまだまだ先に現れる事があります。

今日は晴れかと思えば午後から辺りが真っ白になる位雪が降りました。
その後再び晴れとなり雪は融けだしています。道路が凍結すると車の運転怖いです。

まったりと写真と短い文章で終える、のほほ~んなブログですが、最近長い文章が多いです。
今回も長くなりそうですが、宜しかったら最後までお付き合いください。

長くソフトウエアの開発に携わっていると、データ処理をする上で、どうすれば良いの?と感じてしまう事も多々あります。

普段見聞きしている、表示や音楽は、人間の感覚や時間軸に合わせて出来ています。

秒針のある時計を考えた場合、1秒単位で動いて、60秒で1分となり、さらに60倍動いて1時間となります。
1秒単位の動作が多少ふらついて、0.9秒や、1.1秒の時があっても、1分や1時間経過した時に合計で誤差がなければ実用上問題が無いので良しとなります。

デジタル放送は、局送信時と、テレビで映像を表示するまでに数秒の時間差があります。テレビは映像が連続で映っていれば、局送信時間から多少遅れて表示していてもあまり問題となる事はないです。
時計とテレビ映像開始時間がずれている事に気が付く事もあるかと思います。

CD を再生して、3分の曲を、2分59秒で再生しても、3分1秒で再生しても普通に再生しているように聞こえるのであまり問題となる事はありません。

MIDI など音楽曲再生では、テンポ 120の4分音符発音が 0.5秒です。8分音符、16分音符...となる毎に発音時間は1/2になり 0.25秒、0.125秒...となります。
ではどの位の時間単位で処理すれば殆どの人が曲再生がよれずに聞いてもらえるかと言えば、1ms位の処理単位が必要となります。
3分の曲はやはり3分で再生する事が必要です。例えばピアノ3分の演奏と、バイオリン3分の演奏を重ねた時、どちらかの演奏時間が1秒でも狂えば、音が重ならないので気が付きます。

状況に応じて精度を考える必要があります。精度が上がれば良いものが出来ますが、作成コストや時間が掛かります。

192KHz の音楽再生の場合、扱うデータの最小単位は 1/192000 秒で約 5us です。この単位のデータの中に多少ノイズとなるような不規則なデータが混じっても、人間の聞く時間単位になると聞こえなかったり、聞き逃したりします。

運悪くノイズが聞こえる場合が見つかると、1/192000 秒のサンプリングデータを曲単位で収集し膨大なデータの中からノイズ原因を探します。

正常か異常か扱う場合の判断規則は、人間が決めています。正常で無ければ異常とする場合と、異常で無ければ正常とする論理を組み上げた場合、感覚的にはどちらも同じ結果を出しそうな気がします。
しかし実際は白黒判断つかないグレーゾーンのデータを入力した場合、正常となるか、異常となるかは判断規則で変わってきます。
また人間の時間軸に合わせ、データが平均化されている事があり、例えば正常異常の2値の場合、正常,正常,異常,正常,正常の場合、区間平均して正常が多いので正常とするような場合があります。区間平均したデータが正常なので入力データが全て正常かと言えば、それは違います。

正常異常の2値を 1か0で考えた場合、単純な四捨五入もデータとしてあてにならない事があります。
0.0, 0.1 ,0.2, ... 0.7, 0.8, 0.9, 1.0 の均等なデータ入力を考えた場合、0.0 と 1.0 は四捨五入する必要がないので、0と1になります。切り捨て対象は 0.1, 0.2, 0.3, 0.4 の4通り、切り上げ対象は 0.5, 0.6, 0.7, 0.8, 0.9 の5通りとなります。
すると0となる場合は5通り、1となる場合は6通りとなります。均等なデータ入力なので、0と1になる確率は1対1となるはずが、単純な四捨五入では5対6となってしまいます。
これを回避するために数値計算上の丸め(四捨五入)では、四捨五入と五捨六入を組み合わせて計算しています。

人間の感覚や時間軸に合わせている処理済みデータでは、入力している元データが本当にあっているかどうかは判断がつかないです。

インターナビなど自車位置を決定するのに GPS のデータや車速パルスなどのデータを使用します。

車速パルスのデータは速度メータや積算計に使用されると言いますが、人間の感覚感度に合わせて表示しています。
メーター上 60Km/h で走行している時、本当に車は 60Km/h で走行しているのか、メーターで 1Km 進んだとき本当に 1Km 進んでいるかの精度は、タイヤの外径が変わると誤差がでますと言われるように、メーター上の値はだいたい程度の値です。殆どの場合実際の数値より小さい値を示しています。

自車位置を表示するナビにとっては数値の誤差などは深刻で、各入力データを時間軸で統計補正して使用していると思われます。
自車位置が大きくずれる場合、ソフトウエアの論理があっているならば、入力データのいずれかが足を引っ張っているのでしょうし、ソフトウエアの論理もあっていない可能性も否定は出来ないでしょう。

メーターが動いているので車速パルスは大丈夫だとか、 GPS が受信できているので GPS は大丈夫だとかは、言いきれるものではないです。

ソフトウエアを作成していて思うのですが、人間の感覚や時間軸に合わせた表示データは、調査段階では信じる事は出来ないです。
入力の生データをサンプリング調査して、このデータだから処理論理を通すとこの表示になると、思い込みでは無く、収集データを論理的に積み上げ結果を出すのが技術屋さんの仕事です。

GPSの位置を割り出すのに GPS 時間の計算を精度良く高速に計算していく必要があるので、結構大変です。
位置情報など全て計算で行うものは、小さな誤差やデータエラーは積み重ねると大きな誤差を生みます。
大量の入力データを扱うソフトウエア作成と動作確認は本当に大変だと実感します。

コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする