オンでもオフでもそれっぽくまとまるということで、 最近オックスフォードシャツに手を出しています。これまでは基本的にドレスシャツが好きで、 オックスフォードシャツはほとんど買ったことがありませんでした。 zozo, GU、そして2020年10月に税込み1990円に値下げされた無印良品で購入して比較してみました。

コスパではこの3社の製品では、個人的には無印良品が一番良いかと思いました。

zozoオックスフォードシャツ

360.lifeの高評価で気になっていました。 何回か着て自分なりの評価が固まってきたのでまとめます。 マルチサイズという、身長、体重から選択する方式で購入しました。

気に入った点

• ジャストサイズ。着丈も長すぎず、アウトでも良い感じ。身幅もスリムで野暮ったくない。
• 生地は肉厚で、この値段(購入時1990円)にして質感が十分高いと感じます。

イマイチな点

• 袖口が絞りすぎ。もう少し余裕があっても良い。
• 襟が細すぎ。ネクタイ着用は基本的に考慮されていないと思います。 このシャツの襟の細さだと、ネクタイがはみ出て、みっともないと思われます。
• 自分は肩幅、腕が長いので、裄丈をもう+2cm程度できればなお良いと思いました。
• アームホールも結構絞られているのか、少し窮屈に感じます。 デザイン性を優先させているのだと思います。

全体として

デザイン性とフィット感にこだわった結果、自分としては残念なところがいくらか出てしまっていると感じました。 こればかりはトレードオフなのかも知れません。ノーネクタイは割り切っても良いのですが、 袖口はもう少し広め、袖丈はもう少し長めが良かったです。 袖丈については、もうワンサイズ体重が重いタイプを選べば良かったのかも知れません。 もともとスリムにできているので、それでも丁度よいのかも。

GUオックスフォードシャツ

GUでもオックスフォードシャツを買ってみました。こちらはMサイズです。

気に入った点

• 裄丈が丁度良い。私はドレスシャツだと、84,85cm位と結構腕が長いのですが、 このシャツでは短い感じが全くありません。商品ページで見てみると、裄丈84cmとなっています。
• アームホールは十分広い。
• 襟の広さも個人的には好み。

イマイチな点

• ちょっと着丈は長いかな。さすがにzozoほどぴったりではないですね。 でも、アウトでもダサくならない手前だとは思います。
• 生地自体は、ちょっと薄くて、zozoの質感には及びません。zozoと比べてしまうと薄く感じますが、 オックスフォードシャツとして問題があるとは思いませんでした。

全体として

zozoほどぴったりサイズを狙っているわけではないですが、 個人的には丁度よいゆとりがあり、かつ野暮ったくなりすぎないということで、 生産数が抜群に多いアパレルメーカーとして、さすがに良く出来た商品だと思います。 日本人の体型が計算しつくされているのでしょう。 これが1,490円+税ですから、zozoも霞んでしまいます。 最初に1着試した後、追加で別色を買ってしまいました。

無印良品オックスフォードシャツ

こちらの商品で、正確には、 「新疆綿洗いざらしオックスボタンダウンシャツ」が商品名のようです。

GUとの比較

• 着丈はGUより短くて丁度良いです。
• 裄丈はGUと比較して5mm程度長いようです(この程度だと個体差かも知れません)。長過ぎるようには感じません。
• 全体としては、GUをもう少しフィットさせた感じとでも表現しましょうか。
• 生地については、GUよりはきめが細かいです。質感としてはこちらの方が少し上かな。

2年ほど前に実験していた、FPGAを使用したFM受信機の設計資料をGitHubに上げました。 SDR受信機とはどのように設計されるものなのか。実際のアナログ/デジタル回路含めて全体を理解したい、 という好奇心を満たすために始めたプロジェクトで、当初の目的はそれなりに達成できたと思います。

あまり詳しくドキュメントを書いていないので、実際に使用するのは難しいかと思いますが、 FM用のバンドパスフィルタ基板、ADC基板の回路図、ガーバー、BOMも含まれています。

これまで数年間自宅のインターネット回線はWiMaxを利用してきました。 契約更新のお知らせで、3年縛りになること、さらに月額アップとのことで、回線を乗り換えました。

現契約では月額税込み3023円でしたが、更新後は税込み3515円ということで、ほぼ500円アップでした。 スピードもそれほど出ていなくて、調子が良いときは4-5MBytes/sec出ていましたが、夜の時間帯では 1-2MBytes/secあたりでした。

調査した結果、ギガトラWiFiがクーポンを利用することで、 2890円+税=3179円(予想)で利用できるため、こちらに乗り換えました。100GB制限があるそうですが、 これまでの利用方法では、沢山利用しても月40GBに満たない程度でしたので、自分の利用法では問題ありません。 そもそも、WiMaxも3日で10GB制限があるため、自宅でVivadoをダウンロードするのも気が引けていました。

回線はSoftbankになりますが、端末は、これまでWiMaxで使用していたW04が使用できます。 SoftbankのためのAPNやパスワードを、指示通りにプロファイルとして作成してあげるだけでOKです。

早速Fastでテストしてみました。

上記の通り、下りよりも上りのほうが早いです。WiMaxは上りは10Mbps行ったことは無かったと思います。 スマホから同じサイトで試してみたところ、もう少し下りは速かったです(13Mbps程度)。

追記： さらに別の時間に試したところ、下り24Mbps, 上りも24Mbps出ました。ある程度のムラはあるようですね。

それほど速くは無いですが、WiMaxでも同じような速度でしたので、自分の使い方では不満はありません。 ブラウジングをしていると、気持ちレイテンシが低くなっているように感じます。

契約してから発見したのですが、Softbank 100GBのプリペイドSIMなるものがあるようです。 こちらだと33,000円で12ヶ月(契約月無料で最大13ヶ月使えるようです)なので、月々で考えると2750円程度(13ヶ月で2538円)です。 しかも5%還元がつくようなのでさらに安くなります。ギガトラと同じような仕様ですが、コメントを見てみると、 半月縛り、あるいは3日縛りがあるのかも知れません(あくまで1コメントのため真偽は不明)。 同じ縛りがギガトラWiFiにもあるのか、いずれVivadoをダウンロードして試してみようと思います。 全く仕様が同じであれば、上記Amazonで購入したほうがお得ということになりそうですが、契約したばかりで 解約料もかかりませんので、もう少し使ってみようと思います。

2019/12/17 追記： 10GB程度あるVivadoをダウンロードしてみましたが、ダウンロード途中も速度制限がかかるような様子はなく、 平均して3MB/s(24Mb/s)程度の速度で通信できている様子でした。上記画面の8.9Mbpsというのは、 あまり調子が良くない時の速度かもしれません。

自宅で使っているデスクトップパソコンは、USB経由でWiMaxのルータに接続してインターネット接続をしています。 ルータの電源をパソコンからではなくて、コンセントから供給するために、パソコンとルータの通信は無線化することにしました。

少し検索して、I-O DATAのWN-G150UMKを購入しました。Amazonでたったの685円。 黒は685円なのに、なぜか白は1621円という謎。

早速パソコンに挿して見ると、画面右上にWiFiのマークが現れましたので、クリックしてSSIDの選択、 パスワードの入力で接続できました。ドライバを手動でインストールする必要もありませんでした。

iwconfigで見てみると、Bit Rate=1 Mb/sと常に表示されています。でも実際はしっかり速度は出ているようですので、 表示にはバグがありそうです。

**2019/12/13 追記：**次はBluetoothはどうかと思って少し調べてみたところ、 USB 4.0 Bluetoothドングル CSR4.0+ EDRというモノだとUbuntu 18.04で動作しているというコメントがありました。

**2021/2/6 追記：**光回線の導入に合わせて、5GHzにも対応したTP-Linkのドングルを購入しました。こちらはドライバの手動インストールが必要でした。

タイトルの通り、GCE(Google Compute Engine)のf1-micro(無料枠で使えるもの)のベンチマークを取りましたので、 備忘録として貼っておきます。

   #    #  #    #  #  #    #          #####   ######  #    #   ####   #    #
   #    #  ##   #  #   #  #           #    #  #       ##   #  #    #  #    #
   #    #  # #  #  #    ##            #####   #####   # #  #  #       ######
   #    #  #  # #  #    ##            #    #  #       #  # #  #       #    #
   #    #  #   ##  #   #  #           #    #  #       #   ##  #    #  #    #
    ####   #    #  #  #    #          #####   ######  #    #   ####   #    #

   Version 5.1.3                      Based on the Byte Magazine Unix Benchmark

   Multi-CPU version                  Version 5 revisions by Ian Smith,
                                      Sunnyvale, CA, USA
   January 13, 2011                   johantheghost at yahoo period com

------------------------------------------------------------------------------
   Use directories for:
      * File I/O tests (named fs***) = /home/xxx/byte-unixbench/UnixBench/tmp
      * Results                      = /home/xxx/byte-unixbench/UnixBench/results
------------------------------------------------------------------------------


1 x Dhrystone 2 using register variables  1 2 3 4 5 6 7 8 9 10

1 x Double-Precision Whetstone  1 2 3 4 5 6 7 8 9 10

1 x Execl Throughput  1 2 3

1 x File Copy 1024 bufsize 2000 maxblocks  1 2 3

1 x File Copy 256 bufsize 500 maxblocks  1 2 3

1 x File Copy 4096 bufsize 8000 maxblocks  1 2 3

1 x Pipe Throughput  1 2 3 4 5 6 7 8 9 10

1 x Pipe-based Context Switching  1 2 3 4 5 6 7 8 9 10

1 x Process Creation  1 2 3

1 x System Call Overhead  1 2 3 4 5 6 7 8 9 10

1 x Shell Scripts (1 concurrent)  1 2 3

1 x Shell Scripts (8 concurrent)  1 2 3

========================================================================
   BYTE UNIX Benchmarks (Version 5.1.3)

   System: db: GNU/Linux
   OS: GNU/Linux -- 4.15.0-1029-gcp -- #31-Ubuntu SMP Thu Mar 21 09:40:28 UTC 2019
   Machine: x86_64 (x86_64)
   Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
   CPU 0: Intel(R) Xeon(R) CPU @ 2.20GHz (4400.0 bogomips)
          Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
   00:12:07 up 3 days, 11:23,  1 user,  load average: 0.13, 0.03, 0.01; runlevel 2019-04-30

------------------------------------------------------------------------
Benchmark Run: Sat May 04 2019 00:12:07 - 00:43:23
1 CPU in system; running 1 parallel copy of tests

Dhrystone 2 using register variables       19549752.8 lps   (10.1 s, 7 samples)
Double-Precision Whetstone                      965.7 MWIPS (33.6 s, 7 samples)
Execl Throughput                                771.9 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        112448.3 KBps  (30.1 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           37081.8 KBps  (30.1 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        246207.9 KBps  (30.1 s, 2 samples)
Pipe Throughput                              281428.4 lps   (10.2 s, 7 samples)
Pipe-based Context Switching                  66004.8 lps   (10.1 s, 7 samples)
Process Creation                               2366.5 lps   (30.2 s, 2 samples)
Shell Scripts (1 concurrent)                   1486.9 lpm   (60.2 s, 2 samples)
Shell Scripts (8 concurrent)                    205.7 lpm   (60.2 s, 2 samples)
System Call Overhead                         202476.7 lps   (10.1 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   19549752.8   1675.2
Double-Precision Whetstone                       55.0        965.7    175.6
Execl Throughput                                 43.0        771.9    179.5
File Copy 1024 bufsize 2000 maxblocks          3960.0     112448.3    284.0
File Copy 256 bufsize 500 maxblocks            1655.0      37081.8    224.1
File Copy 4096 bufsize 8000 maxblocks          5800.0     246207.9    424.5
Pipe Throughput                               12440.0     281428.4    226.2
Pipe-based Context Switching                   4000.0      66004.8    165.0
Process Creation                                126.0       2366.5    187.8
Shell Scripts (1 concurrent)                     42.4       1486.9    350.7
Shell Scripts (8 concurrent)                      6.0        205.7    342.8
System Call Overhead                          15000.0     202476.7    135.0
                                                                   ========
System Benchmarks Index Score                                         271.8

Amazon Lightsailのベンチマーク(UnixBench)とか貼っておきますね。と比べてみると、かなりパフォーマンスは低いようです。 最後のSystem Benchmarks Index Scoreでは、Lightsailの1971.6に対して、271.8と13%程度の性能です。

今日は永田町から中野新橋まで、おおむね下のルートで歩きました。

永田町についた時は、少し雨が降っていましたので、傘が不要になるまで待ちました。 日テレ通りを北上し、麹町を通り越して市ヶ谷に到着です。

防衛省の北側を回りこむと、大日本印刷のビルが林立しています。昔の五反田のソニー村のようです。 西に進んで牛込柳町を通り、大久保通りを西に歩きます。

国立国際医療研究センター病院を過ぎて右に曲がって、戸山公園の箱根山(44.6m。標高と思われる。 実際に登るのは10m位?)に登頂しました。管理事務所で自己申告をすれば、登頂証明書をもらえるそうです。

頂上からの眺めが良いわけでもないので、そちらは撮影しませんでした。

西に進んで、新宿コズミックセンターという謎の施設(どうやらスポーツ施設のようです)を周り、 新宿コズミック通りという微妙なネーミングの通りを西に向かいます。 この道沿いに早稲田大学の理工学部があるようです。

新大久保の北で山手線をくぐり、東中野まで歩きました。東中野からは、山手通りを南下し、 中野坂上まで。休日のせいか、山手通りはそれほど渋滞もしておらず、道も綺麗に感じました。 ちょうどよい起伏のおかげで、見通しがよく感じます。

本当は東中野近辺で食事をしたかったのですが、めぼしいところが見つからなかったので、 結局中野坂上のマックに入りました。最近はビッグマックのセットが690円するのですね。 アメリカの物価に合わせているのでしょうか、コストに対する満足度が低かったですね…

それから南西に歩いて、本二東郷やすらぎ公園を抜けます。そして神田川まで出ます。

神田川と都庁。大分晴れてきました。

もう少し西に歩いて、丸ノ内線中野新橋から帰途につきました。Googleマップで調べてみると、 大体10km程度歩いたようです。

タイトルの通り、Haskell Stackで作成しているプロジェクトを、テスト用のディレクトリから正式なプロジェクト管理用ディレクトリに移動したところ、stack buildが失敗するようになってしまいました。

エラーメッセージは正確に記録しなかったのですが、/usr/bin/ld.goldがエラーを出していて、 プロジェクトが使用しているHaskellライブラリの.soファイルが見つからない、 といったようなメッセージを出力していました。

stack buildが通らなくなった時のメモを見てみましたが、libgmpといった、システム全体にインストールされているライブラリではないので、症状は異なります。 同ページに記載されていた、stack setup –reinstallを試してみましたが、相変わらずstack buildのエラーは同じでした。

結果としては、プロジェクトディレクトリにある、.stack-workディレクトリをrm -rfで削除して、再度stack buildしたら成功しました。

机には透明のビニール製マットをひいて、その上で光学式マウスを使用していましたが、 最近カーソルが思い通りに動かない場面が多く感じてストレスになっていました。 それで思い立って、トラックボールに手を出してみました。

Kensington Orbit Trackball with Scroll Ringです。初日は、なんとなく右方向に回転する時にイマイチなフィーリングでしたが、少ししたら引っかかりは無くなりました。これでマウスのストレスから解放されました。机の上があまり広くない場合もお勧めできると思います。 ただ、中ボタンが無いため、沢山ボタンが欲しいという場合は避けたほうが良いでしょう。

最近少し忙しくて、OFDM関連の作業を続ける気力が無くなっています。 ビタビ符号の復号は実装したのですが、まだ記事にできていません。残るReed-Solomon符号のところは、 最初はOSSのものを使用して動作させようかと思っています。

それと別件でWebアプリを一個完成させたいとも思っているので、なおさら集中できてません。

ストレス発散のための買い物かも知れません。

前回、パイロット信号が正しく取り出せないのはキャリア周波数オフセット(Carrier Frequency Offset, CFO)が原因ではないかと書きました。それ以後、 OFDM Baseband Receiver Design for Wireless Communicationsを参考に、 CFO, SCO(Sampling Clock Offset)を除去するためのPLLを実装してみたりもしましたが、どうにも思うとおりにはなりませんでした。

考え直してさらに調査した結果、DFTのデータを取り出すウィンドウが間違っていたということが判明しました。

これまでは、相関値が最大になる場所をDFTウィンドウの先頭としていましたが、 それだとCyclie Prefix(ガードインターバル)の先頭からOFDMシンボルを切り出してしまうことになります。 この領域は、信号に遅延波があるときに、他のシンボルからの干渉を避けるためのものなので、 本来DFTに使用するのは望ましくありません。

遅延波が全く無かったとしても、上記の文献の式(5.11)の通り、周波数領域の信号Zkは、送信信号Xk、チャンネル応答Hkに対して次のようになります。

ここに、TdはDFTウィンドウがCyclic Prefixに入り込んでいる時間です。

これまでのTs=1, Td=128, N=1024で計算してみると、e^{-j2pi128k/1024}= e^{-jpi*k/4}となります。つまり、隣り合ったサブキャリアの間で-pi/4だけ位相が本来の信号からずれていくことになります。

これまでの結果を振り返ってみると、サブキャリア12本ごとにpi位相がずれている様子でした。 計算すると、-pi/4*12=-3pi=pi (modulo 2pi)ですので、ちょうどこの結果と一致します。

それで、CPの開始からDFTウィンドウを設定するのではなく、CPの終わりの少し前からDFTウィンドウを設定することで、ほぼ所望の結果が得られるようになりました。

上はチャンネル補正をする前の、生のDFT後のデータです。 これだけバラけていると、QPSKであることも疑わしい感じですね。

SP自体は上のように、まだキャリアごとに、わずかに回転しています。このSPによって、残りのチャンネルは線形補間で推定します。推定結果でデータを補正すると、次になりました。

このように、CFO, SCOのためのPLLは一切使用せずに、相関値を算出したときのガンマの値による回転と、整数倍のチャンネル周波数補正、SPによるチャンネル補正のみで、QPSKの信号がほぼ復元できました。

流石に、この程度のコンステレーションでは64QAMは無理ですが、4象限しか区別しないQPSK程度であれば、これでも十分に思われます。また、TMCC, ACに相当するI軸上の点も見つけられます。

ここまで来れば、TMCCのデコードをはじめ、ワンセグのデコード処理も規格書に則って進めれば完成まで持っていけそうな気がしてきました。

前回までで、ワンセグの生データからのOFDMシンボル切り出し、パイロット信号を見つけるところまで実装しました。ところが、パイロット信号からチャンネル補正ができそうにない、というところで止まってしまいました。もう少し調査したところ、原因が分かってきました。 自分の理解の範囲でのまとめです。

OFDM Baseband Receiver Design for Wireless CommunicationsのChanter 5. Synchronizationの式(5.6)は次のようになっています。

これは、キャリア周波数のオフセットが、FFTした結果に及ぼす影響を記述した式です。 左辺Z_{i, k}は、(時系列に並んだ)i番目のシンボルの、k番目のサブキャリアの(周波数領域の)値を示しています。また、ε_I, ε_fがそれぞれキャリア周波数オフセットの整数部、小数部です。 Hはそれぞれのサブキャリアに対応するチャンネルの周波数応答です。

ごちゃごちゃしていますが、とにかく、ε_I, ε_fが0でなければ、Z = X Hとは記述できず、他のキャリア周波数の影響を受けてしまうことを示しています。

右辺の第一項を見てみると、大きく4つの掛け算になっていますが、最後の2つのe^{…}の部分は純粋な回転です。 これまでの実装で、小数部のキャリア周波数補正はできていると思われます。 そのため、ε_fはほとんど0と考えます。

したがって、振幅だけを見るならば、受信したk番目のサブキャリアのFFT結果は、送信側のk-ε_I番目のサブキャリアの値に、チャンネル応答を掛けたものになっています(sinの項はε_f->0で1になるため)。 ですから、パイロット信号も含めてXの振幅は既知なので、振幅について積算することで、 ε_Iを求めることができたのでした。

問題は3番目のeの項による回転です。 この式を見るとε_Iが0でなければ、時間と共に盛大に回転します。 (2019/2/20追記：これ自体は正しいですが、kには依存していませんので、 Scattered Pilotがキャリアによって回転量が異なることの説明にはなりません。 それより(5.6)右辺第2項が寄与しているのかも知れません)

これの逆数を求めて回転を補正することもできるかも知れませんが、 上記の式では右辺には第2項以降も存在します。 そのため、基本的にはε_I, ε_fを0に収束させるような制御をしたほうが良さそうです。

上記の本の5.2.3節にも、周波数領域の推定アルゴリズムには限度があるので、同期エラーはその限界内に来ていることを確かめないといけない、といった記述があります。そのためには、時間領域で補正することができる、と書かれています。

時間領域での補正方法は下記の図のようになります(Figure 5.13より)。

求められたε_I, ε_fをloop filterを通してNCOに与え、その周波数でサンプリングしたデータを回転させる、というものです。 これまでの実装ではε_fのみしか考慮していませんでしたが、ε_Iも考慮する必要がある、ということです。

以上を参考にして、PLLでキャリア周波数オフセットを0に制御できるか試してみたいと思います。