解読器開発ノート。
解読器のハードウェアはなんとかなったけど、ソフトウェアに不具合多発。
まず半角カナをプログラム中で使うと、一文字二文字なら大丈夫だったんだけど、変換テーブルのswitch文に使うと予期せぬ『文字』になってしまいNG。
想定の範囲内だったけど、変換テーブル全部書き換え。
それとNJM567の出力をC-MOSインバータで5Vレベルにして取り出してるんだけど、この信号のサンプリングが上手くいってない模様。
ハイレベルの周期を測ってるんだけど、これがいけないのかなぁ?ポケコンで作ったときは周期測定だったはず…
それと符号の長さと周期から読み取った符号の数値化で別々に変換するようにしてるんだけど、これがいかんのか?
他の方のプログラムでは周期を測るんじゃなくて、時分割で標本化してるらしい。
その上、符号長と数値化した符号を一つの数値にしてテーブルに持っていってるようだ。
70とか参照するより符号長でテーブルを分割したほうが時間がかからないと思ったんだけど、これも問題かなあ?
符号長と符号を一体化すると、英文だと8bitでギリ間に合うんだけど、10bitとかになっちゃうしなあ。
まずはラジオからのTTL出力をオシロで見てみるか。この出力が細切れになってると話しにならんし。
その後、周期測定〜数値化のアルゴリズムが正しいかどうか検証だな。
解読器のハードウェアはなんとかなったけど、ソフトウェアに不具合多発。
まず半角カナをプログラム中で使うと、一文字二文字なら大丈夫だったんだけど、変換テーブルのswitch文に使うと予期せぬ『文字』になってしまいNG。
想定の範囲内だったけど、変換テーブル全部書き換え。
それとNJM567の出力をC-MOSインバータで5Vレベルにして取り出してるんだけど、この信号のサンプリングが上手くいってない模様。
ハイレベルの周期を測ってるんだけど、これがいけないのかなぁ?ポケコンで作ったときは周期測定だったはず…
それと符号の長さと周期から読み取った符号の数値化で別々に変換するようにしてるんだけど、これがいかんのか?
他の方のプログラムでは周期を測るんじゃなくて、時分割で標本化してるらしい。
その上、符号長と数値化した符号を一つの数値にしてテーブルに持っていってるようだ。
70とか参照するより符号長でテーブルを分割したほうが時間がかからないと思ったんだけど、これも問題かなあ?
符号長と符号を一体化すると、英文だと8bitでギリ間に合うんだけど、10bitとかになっちゃうしなあ。
まずはラジオからのTTL出力をオシロで見てみるか。この出力が細切れになってると話しにならんし。
その後、周期測定〜数値化のアルゴリズムが正しいかどうか検証だな。