Raspberry Pi で遊ぼう

前回の記事では、モールス信号の読み取りに迷ったらどちらの可能性にも分岐する「多重世界線方式」を考えて実装したところ、その自信度で評価して一番上に正解が来るようになりました。しかし可能性をいくつも見せても仕方がないのでやはり一つを残して他は刈り取る必要があります。これが次の課題です。

前回の記事で、モールス信号読み取りプログラムの大枠を作って紹介しましたが、モールス信号のオンオフパタンの読み取りは原始的な方法でお茶を濁してしまいました。今回はそこを強化してみた、という記事です。

モールス符号の入力を実際に理解させるときに、大きく二つ問題があります。

• 全く同一のタイミングで別の符号パタンが存在する
• モールス信号は人手で叩くこともあり、タイミングは必ずしも正確ではない

全く同一のタイミングについては、例えばこのようなもの

******      ******      ******

これは、トンの長さが文字二個分と認識すると”T T T” になって正しいコードです。トンの長さを文字六個分と認識するとこれは “S” になってこれも正しいコードです（SOS の S です）。

モールス符号のタイミングのブレで読み取りが紛らわしい問題については、実際にテストパタンで経験したものでは例えば

*****      ***************      ***********   ******

これは P (.–.) のつもりですけれども三番目の信号が何かあいまいで L (.-..) とも読めてしまいます。他にも隙間があいまいで単なる信号の切れ目なのか文字の切れ目なのか判別がつけづらいという場合もありました。

ここ数日モールス符号のデコードアルゴリズムを書いていました。何故かというと、ラズパイでモールス信号の読み取り機ができるんだろうか？と突如疑問に思ったわけなんです。スマホが音声認識してしまう時代にモールス信号なんて、できても虚しいのでは？という自問に負けず、それでもやっぱりちゃんと機構を組んでメカメカしく動くものを作ると見えてくる物事の本質もあるはず。いやそんなメカちょっとみてみたい、と、復号化だけでなく信号を読むとこ全部やってみることにしたわけです。

Chris Wellons さんのモールス符号のデコード関数の実装を参考に同じことをする別関数を書いてみたけれどもあんまり筋が良くありません。やっぱり本家のほうが魅力的。もと実装を見ていたら、もう少しだけ小さく実装できそうだったのでやってみました。

モールス符号のデコーダを書いてみました。初見でこれの原理がぱっとわかったらちょっとすごいです。

ソフトウェアを書く方は、「やーそれラズパイ買ってきてちゃちゃっとデモしちゃいましょうよ」というようなことを一度や二度は口にしたことがあるんじゃないでしょうか？僕はあります。でもいざやってみると、SD Card に乗ってるシステムって怖いんですよね。いつ飛んじゃうのかと。そして、近頃もラズパイで楽しく遊んでみようと思ったらやはりシステムが飛んでしまいました。まあただの設定ミスかもしれないんですけど。それで、本格的に遊んでみる前に、以前からかねての疑問「そもそもラズパイには何の SD Card を使ったらいいの？」についてまじめに取り組んでみました。

SD Card の規格、超わかりくくないですか？こんなのとか。

「え？class 10? V30? U3? A1? なにそれ？」と思ってしまいます。買うとき毎回です。

調べた結論から書いてしまうと僕の考えは「SD Card を使うなら A2 クラスが良い。ほかのあれこれは無視してOK」です。でも「むしろ SD Card は使わないで SSD を使った方がいい」とも思うんですけれども。なんでそう思うのか興味があったら続きを読んでいってください。

前回の記事 Raspberry Pi で DPDK は使えるか？ の続きです。いきなり始めたこの話題ですが、そもそも DPDK とは何でしょうか？Wikipedia の説明が良くまとまっていてわかりやすいです。Data Plane Development Kit の略で、データプレーンを扱うアプリケーションを書くためのライブラリです。

8/19 もうちょっと色々わかったので追記しました。

かなり以前に Raspberry Pi で DPDK を走らせようとして挫折したのですが

それから7年も経っているし、状況は変わっているでしょう。再挑戦してみます。