橋!橋!橋! @隅田川

最近、電車に乗ることが怖くなったので、代わりに散歩することが増えてきました。 そんな中で、都内の散歩スポットはいろいろあると思いますが、 隅田川のそばにテラス?があって散歩できる道があります。

今回はその付近を歩いて見つけた橋の写真を取ったので記載していきます!

両国橋

まずは基本中の基本?両国橋です。 二つの国を結ぶ橋で両国橋と名がついたようです。

f:id:thira2:20200412185922j:plain

柳橋

両国橋から浅草橋の方に向かうとある橋です。 なかなか趣深い橋です。

f:id:thira2:20200412185841j:plain

新大橋

昔は萬年橋と同様に鉄鋼という感じの橋だったようですが、 今は何か普通のモダン?で若干地味な感じのする橋です笑

f:id:thira2:20200412185752j:plain

蔵前橋

ライトアップされていてもなくても綺麗な橋でいい感じです。 散歩にもおすすめの橋です。

f:id:thira2:20200412185714j:plain

萬年橋

小さな橋なんですが、鉄鋼具合が堪らないです。

f:id:thira2:20200412185616j:plain

f:id:thira2:20200412185456j:plain

f:id:thira2:20200412185438j:plain

清洲橋

非常にいい感じのフォルムで鉄鋼具合が堪らない橋です。 おすすめです笑

f:id:thira2:20200413002418j:plain

f:id:thira2:20200412185410j:plain

まとめ

清洲橋のそばに橋の地図が書いてありました。 まだいくつか回っていない橋があるので、周りにいかないとです。

f:id:thira2:20200412185427j:plain

あとがき

というわけで、橋を回りました。 昔から橋オタというわけではないのですが、散歩中に橋を見ていると、 橋それぞれに個性があり、その造形美にひかれていった形です。

あと、本当はタイトルを「橋これ」にしようとしたのですが、調べてみたら、すでに先人がいらしたので、 鮫もとに虎のオマージュにしました。

橋これ

マンションのネットワークが重いと感じる話

最近、住んでいるマンションのネットワークが重いと感じることが増えてきました。 試しに通信量を1時間ごとくらいに調べてみたんですが、大体10Mbpsを下回っているありさまでした。。(朝は少し早い。)

以前は50Mbpsは軽く出ていたんですが、でないので、マンション内か外側かはわかりませんが、 ネットワークの限界に達しているようです。

思い返してみると、私の住んでいるマンションは数十部屋くらいなんですが、4月初めから徐々に重くなってきたことを感じていたので、想像の通りコロナの自粛期間に合致するわけです。 さらに緊急事態宣言が出てから、愕然と遅くなった感があります。(速度を毎週調べとくべきでした笑)

自粛中に、自宅にいて動画視聴をしている人が多いのだろうと、調べてみました。 調べてみたら、EUの場合ですが、Netflixの使用転送量が増えて、 転送量を抑止するために画質を落とすようになっているみたいですね。。

Netflix will reduce streaming quality in Europe for 30 days – TechCrunch

日本も↑と同様だろうと推測します。以下をみると4割り増えたみたいですね。

データ通信量、4割増加 在宅勤務・休校が影響 3月、前月比 回線増・画質制限が急務 :日本経済新聞

ネットワークが重たいので実は在宅勤務で困ってはいるのですが、 この問題は簡単な解決策がないのが痛いところです。

別途モバイルルータを購入したり、光回線を自室まで引けば、対応可能と思うのですが、 お金かかりますし、おそらく対応に数週間時間がかかるはずです。

一方で、マンションに住んでいる人だけでなく、専用回線を引いている家持の方も同様に ネットワークが遅いという話もよく聴きます。 原因は社内のネットワークも重くなっていることのようでした。

社内でも、在宅勤務する想定でネットワーク設計できていなかったんでしょうね。 おそらく今回の件で、全国的に改善されるとは思ってますが、時間はかかるでしょうから、 今は昔の遅いインターネットの時代を思い出したながら、在宅勤務を頑張ることにしました。

あとがき

ネットワークが重かったという話を備忘録として記載しました。 数十年後には、10Mbpsとかwwと言っているんでしょうか。 数十年前に100kbpsで喜んでいる頃に比べると、今の重くなった状況すら数百倍早いわけですから。

ワイヤレスイヤホンを購入してみました

先日、自粛中ではあったのですが、ある駅で偶然に友人と会うことになりました。 なので、久しぶりにイカした喫茶店(サイゼ)に行くことにしました。

ドリンクバーを頼み、近況報告したあとに、気付いたら読書時間になっていました。 で、ふと気になったことがあり、友人に話しかけたのですが、回答がありません。

寝ているのかとも思ったのですが、目を開いて本を読んでいるように見えます。 話しかけていることを無視するような人でもないので、集中しているのだろうと思い、気にしないことにしました。 で、再度顔を上げると、耳栓をしているではないですか。 どおりで聞こえないわけだと気にしないことにしました。

時間が経ち、その後に耳についている耳栓について聞くと、 それは耳栓ではなくて、ワイヤレスイヤホンというものであることがわかりました。

数年前に登場したBluetoothイヤホンだと片耳ではなく両耳のイヤホンが線につながってましたが、 なんと今は片耳ずつになっているんです。 さらに、その友人からすごく便利で最近買ったもので一番よかったと教えてもらい、私も欲しくなりました。 というわけで、高いの買って後悔することを防ぐ面もあり、試しに以下の低価格帯のものを買ってみました。

Amazonで調べたんですが、同じようなものがたくさん並んでいて、非常に迷いました。。 出店者も聞いたことないところばかりで迷ったんですが、イヤホンを主に取り扱っていて、評価件数も多いところにしてみました。

さて、使ってみると、まずペアリング接続はなかなかに簡単です。 Bluetooth有効にして「P10S」を選ぶだけです。

別の機器に接続する場合には初期化が必要なようで、 充電しているときに両方のイヤホンを三回押すと白いランプが光ると初期化されるようでした。

iMac, Androidスマホで試しましたが、両方とも問題なく接続されます。 面白いのは片耳ずつだして耳に装着すると2回接続音が流れることです。 1回目はイヤホン同士で、2回目はホスト(iMac/スマホ)と接続しているようです。

イヤホンの装着感は軽く、長時間使用が可能な感じです。 ワイヤーもないので、快適で、ウォーキングもしやすいです。 電池持ちも数時間くらいなら持つので、ケースを持って歩かなくてもまぁ大丈夫でした。

あとがき

というわけで、ワイヤレスイヤホンを買いました。 ワイヤがなく非常に快適で、ケースにしまえば充電されて非常に便利です。

安いイヤホンしか使っていない自分としては、音質も問題ありません。 というわけで、友人に進められたワイヤレスイヤホンを購入しましたが、買ってよかった、という話でした。

転送帯域を増すためにzlib圧縮を学んでみました。

先日、Uartを使えるようになったのですが、転送帯域が115Kbpsとなかなかに遅いです。 転送速度を上げるために、パラレルにしたり、周波数を上げたりすることが考えられます。

一方で、データに目を向けてみると、圧縮して送信することで、転送帯域を上げることが可能です。 今回はデータを圧縮転送帯域を増すためにzlib圧縮を学ぶことにしたので、備忘録として記載します。

まずは以下サイトで総論を学びました。

次に以下サイトでPythonでzlib, glibで圧縮する方法を学びました。 Pythonだと以下のようなコマンドで簡単に圧縮を試せることがわかりました。

Pythonでデータを圧縮する話 - EnsekiTT Blog

import zlib
s = b'wwww'
t = zlib.compress(s)

ただ、↑のtをprintすると以下のような意味不明な出力を吐きました。wは0x77なのですが、 値がまったく出てきていません。

0000: 2f2b9c78
0004: 00072f2f
0008: dd01aa04

↑の調査のために、ZLIBのフォーマットをRFC1950(ZLIBのフォーマット定義)調べることにしました。 すると、以下がわかりました。

RFC 1950 ZLIB Compressed Data Format Specification version 3.3 日本語訳 - futomi's CGI Cafe

  • 先頭の2byteはCMFとFLG。↑のログだとCMF(0x78-> CINFO=7:32K window CM(Compression method)=8: deflate), FLG(0x9C)
  • 残りは圧縮データ(t[2:-4])
  • RFC 1951 DEFLATE Compressed Data Format Specification で定義
  • 末尾の4byteはChecksum

というわけで、データ圧縮の定義はRFC1951に記載があることがわかりました。

RFC 1951 DEFLATE Compressed Data Format Specification version 1.3 日本語訳 - futomi's CGI Cafe

各ブロックは、LZ77 アルゴリズムとハフマン符号化の組み合わせで圧縮されます。
各ブロックは、次のデータを含む 3 ビットのヘッダーから始まります。
第1ビット BFINAL
次の2ビット BTYPE

ただ、↑を見ても正直よくわからないので、解説サイトを調べてみたら、 以下にたどり着きました。これも難しいのですが、何回か読んでいて少し理解しました。

Deflate

  • 0-255のリテラルデータ or 戻り距離
  • 0x100(256)はブロックの終端
  • 0x257-285の値は長さ符号
  • 3.2.6. 固定ハフマン符号を使った圧縮 (BTYPE=01)に記載されているようにリテラル値は符号に割り当てられている('a'(0x61) ->0x91になる)

また、最後に以下を見るといい感じで頭が整理されました。

SWFバイナリ編集のススメ番外編 (zlib 伸張) 前編 | エンジニアブログ | GREE Engineering

あとがき

Zlibによる圧縮を学んでみました。 結局のところ、Zlib自体は先頭と末尾はヘッダとChecksumついているくらいで、まだ大丈夫かなでしたが、 Deflateについて難しすぎました。。

FPGAで動かすために、ハード化することも相当大変そうなので、 もっと簡易化されたアルゴリズムを探さないと、というのが結論です笑

AIによる意思決定について

最近、諸事情により、引越ししたいなと考えることが増えてきました。 それではと、引っ越し先予定の土地にある賃貸を探すと100件近くでてきます。 候補を絞ると十数件くらいにはなるんですが、どれも良さそうで迷います。

いつもなら、その候補で数件選んで、不動産屋に行って見て回るんですが、自粛期間中なので、あんまり行きたくないです。 で、ふとAIで良い賃貸を選んでくれないのかと調べてみました。 結論から言うとなかったんです。売買のほうはあるようでしたが、賃貸は見つけられませんでした。 賃貸は失敗しても移ればいいだけですし、ダメージ少ないので特に必要とされていないんでしょう。

残念だなと思ったんですが、それなら作ってみたら面白そうと思いました。 要は各物件のパラメータから、角賃貸の良さや異なりを見つけられれば良いのでAIにぴったりのはずです。 これで、良さげな物件見つけて、実際に下見して選択すれば、はい一丁出来上がりってわけです笑

すなわち、AIを意思決定に使用することが可能というわけです。 AIによる意思決定について調べて見ると以下のサイトを見つけました。 "Leveraging both AI and Human processors in the workflow"の図に記載ありますが、AIに良さげなものを選ばせて、 その中から、人間がその他デジタルでない情報を元に最終決定を下す、という流れです。 これは面白いなと思いました。

参考: What AI-Driven Decision Making Looks Like

あとがき

AIを意思決定に使えることがわかりました。

AIで良い賃貸を評価することはなかなか難しそうですが、面白そうなので、とりまやってみることにします!!

Visitのhello worldを動かしてみました(on Zybo)

Visitをインストールし、次にZyboでVisitのHello worldを動かしたので、備忘録として記載します。

↑の参考元の通り進めるだけなのですが、以下につまったので記載します。

  1. Zyboの基板設定ファイルをダウンロードします。
  2. 解答してzyboディレクトリを以下のようなVivado内のboard_filesに格納します。
    C:\Xilinx\Vivado\2019.2\data\boards\board_files
  3. 後は↑の参考元にしたがって進めるだけでした

あとがき

Vivado 2019でもZyboの基板ファイルが読めて、無事にVisitで動かせることに感動しました。 ツール互換性がしっかり保たれていると感じました。(細かいところは動かなくなったりするのでしょうが)

あと何より参考元が非常に詳しく記載されていて非常に助かりました。 おかけで、Visitで無事にHello worldを動かせたので次にVisitのSDKをいろいろ触ってみようと思います。 特にUART使えるようになったのはいい感じです。

苦戦したこと

実は↑の手順にたどり着く前に以下のことを実施しました。 いずれもうまくいかいきませんでした。。

  • Example Projectを使用しようとしてみる -> Vivado落ちるため実施できず。。
    • Project TypeをExample Projectに選択
    • TempleateをBase Zynqを選択
      (CPUを選ぶとOpenRISCになるみたいでした)
    • でボードを選択するわけですが、Zyboは残念ながら、ありませんでした
      なのでUpdate xxを選択してしばらく待つと。。落ちました。。

↑より、Exampleはつかわず、一番上の参考元を一から進めてみることにしました。

基板設定ファイルありましたが、2015版で使える気がしなかったので、使わないことにしました <-- ここで失敗しました

進めると、Visitの起動まで進むのですが、以下のURLと同様にUART IPがないとhello worldを選択することができなくなりました。。 というわけでこれも摘みました。

https://www.xilinx.com/support/answers/37123.html

↑のような状況になったので、しょうがなく基板設定ファイルを使ってみたら、上手くいきました。 推測では、基板ファイルにUARTを有効にする設定が入っていると思っています。よくわかりませんが

Xilinx Vitisをインストールしました

先日、Zynq内にはFPGA部分にもARMのプロセッサが乗っていることを思い出しました笑

データシートを読んでみると、ZynqはARMだけではなく、Synopsys, Cadence, Arasanと著名なIPベンダのIPで構成されていることがわかりました。 こんなおもしろチップなのに、まったく動かしていないことに気がついたので、色々動かしてみようと思いました。

f:id:thira2:20200328200952p:plain:w600

出典元: Zynq-7000 All Programmable SoC Technical Reference Manual UG585 (v1.11) September 27, 2016

まずはARMを動かすためにはXilinx SDKをインストールしようとしたのですが、 2019/10にVitisで一つにまとめられていることがわかりました。 というわけで、それならばとVitisをインストールしてみることにしました。

ダウンロード元: Vitis Core Development Kit - 2019.2
https://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/vitis.html

  • Unitfied 2019.2 Instllerを起動し、ログイン
    • Vitsを選択
    • ディレクトリをXilinxSDKに設定
      (既存インストール済みのVivadoのディレクトリと異なるディレクトリにするようにメッセージあったため)
    • インストールに90GBの容量が必要で、ツール自体には40GB必要なようでした
    • Vits入れるとなんとVivadoも入ってました。すなわちVitsをとりあえずインストールしておけばよかったみたいです。。
    • Downloadに3時間30分近くかかりました。。Install、Final Processingは30分程度くらいと合わせて4時間くらいです

↑を実施するとVivado Licence Managerが起動するので、Get Free ISE Web Packを選択しました。 次に、XIlinxのサイト内でとりあえず無期限でフリーの以下ライセンスを選択し、 Host IDにEthernetアドレスを選択しました。 次に進めると、ライセンスファイルが添付されたメールが送られてきました。

Licence Managerの「Load License」を選択し、↑のファイルを選択します。 「View License Status」をクリックし、諸々のLisenceがあることを確認しました。

  • ISE Embeded Edition License
  • Vivado Design Suite
  • ISE WebPACK
  • Xilinx MicroBlase

あとがき

以上でVitisのインストールまで完了しました! 次はZynqにプログラムを組み込んで行く予定です。

GitHub - Xilinx/Vitis-Tutorials