今日も学校へ

今日も朝から研究室でゼミ資料を作成しています。
27日が発表なのですが、前回から少し時間があいているのでそれなりの進捗を
発表しないといけないのですが、如何せんうまくいかないことが多々あり
想定していたものと内容が若干変更になりそうです。

提案プロトコルの実装はもう直ぐα版が完成しそうな感じまでこぎつけましたが
ここからのチューニングとバグフィックスが問題です。

コーディングしながらいくつかの箇所で怪しいところを抱えていると思っているので
修正方法を検討しながらコーディングを進めていきます。
思ったようなエラーであれば直ぐに修正が可能なのですが、実行結果が所望の
物と違いすぎた時の調整が本当に苦労します。

でも、少しは形になってきた気がしますが・・・。
夏休み10日のお休み以外は基本的に毎日出勤してやってたんだから、それなりに
進んでないとかなり痛々しいのですが・・・。

で、プレゼンを作りながらシミュレータの検討箇所を再度洗ってみたところ
RadioNoise系での受信判定処理は間違ってはいないのではないかと思ったり
他の箇所が怪しいのではないかと感じてみたり。
見れば見るほど怪しさ満天です。
以下、今日の所見

・「新しく受信した電波電力＞現在受信中の電波電力*SNR」なら新しい電波を受信
　受信するようにロックを切り替える処理判定は理屈的にあっていると思われます。
　なので、unlockに切り替えるように訂正しなくてもいい感じです。
　新しい電波を所望波、古い電波をノイズと考えれば所望波の方がノイズにSNRを
　乗算した強さよりも大きければ所望波を受信します。
　しかし、これが無線器であればそちらの音声なり映像が受信されますが、パケットの
　受信処理が行われている最中に新しい電波を受信した場合、ただ単純に新しい方を
　選択して古いものを破棄するだけか怪しいところです。
　もし、これが実環境で起これば相手のPCに好きなデータを邪魔して送れてしまう
　気がするのですが・・・。

・RadioModeがTRANSMITTINGの時の処理が無いのがおかしい気がします。
　送信中に送信を邪魔するような電波がやってきたら送信中のパケットが落ちる
　気がしますが、その処理がされていない感じです。
　でも、このシミュレータの設計上この処理はかなり面倒な感じです。
　なので放置でもいいかなと思います。

・802.11については調査中

少しずつ訂正なりをしてきましたが、如何せんBloadCast時の配送率100%問題が
解決していません。
しかし、RadioNoiseモデルを変更したら落ちるようになったのでこちらで様子を
見ていきたいと思います。