赤外線発信する際の「射」の後の「０」ですが、ソニー方式リモコンデータの場合は、「１」になります。
「頭│ペイ長│射│ここ！│デー長│赤外線の波形データ│検」

つまり、エクスポートしたxmlファイルの0 or 1の値を入れると良いと思われます。

実際は、ゼロのままでも何故かソニーテレビを操作できたので、実用上の支障はなかったのですけど、気になったので調べてみました。

CRC の計算プログラムとしては見慣れないものだったので面喰らいましたが、これは生成多項式が x⁸ + x⁷ + x² + 1 の CRC-8 ですね。高速化のため配列を用いているのでしょう。

「検」が CRC である可能性は (昨年の段階で) 真っ先に検討したのですが、CRC-8 で一般的に使われる生成多項式で除算した余りとは一致しなかったので、CRC ではないと判断してしまったのでした。

いま思えば、CRC-8 の生成多項式は高々 256個しかないわけで、一般的に使われるものだけでなく、全てを試してみるべきでした。

送信するパケットデータのうち、最初の３バイト「頭＆ペイ長」と最後の１バイト「検」を除いたバイト列のCRC8を計算すると、「検」の部分になります。
計測データも赤外線発射も同じ計算方法です。

例えば、計測データ取得パケット列「AA 00 01 18 50」の場合、「18」のCRC8を計算することになり、結果は「50」ですので、「検」にあたる最後のデータと一致しています。

同じRatoc製品のRPi-IREXのサンプルソースがヒントになりました。
https://github.com/ratocsystems/rpi-irex/tree/master/python

かつて搾取は生産手段の有無が原因でしたが、生産手段よりも知識のほうが重要になり、さらに最近は IT によって (単なる) 知識では大して役に立たず、知能のほうが力の持つようになってきているわけです。

何が力の源泉かによって「資本」や「搾取」の意味が変わってくることに気づかないと、社会を正しく理解することができないと思います。

一物一価の法則は、「法則」と名前が付いてますが、ごく限られた状況でしか成り立たないわけで、この手の役に立たない法則を前提にした考えは、結論も間違ったものになると思っていたほうがいいでしょう。

時代遅れの搾取の考え方も、一物一価の法則も、社会を理解しようとする際は、百害あって一利なしです。

1物1価が成り立つ条件としては、
「自由な市場経済において同一の市場の同一時点における同一の商品は同一の価格である」(wikipedia)と書いてあり、

したがって、給与を決めるときは、この条件が成りたっていないと考えられます。

例えば、日本でしているのと全く同じ事業内容を東南アジアに移した時、日本人に渡していた賃金と東南アジアの人に渡す賃金はもちろん異なっています(事業内容が同じで利益が同じであっても)
これは、’同一の市場’ではないからと考えられます。

また、基本的に転職するときは、前の給与を参考にして決められることが多く、全く能力としては同じであるはずなのに給与が変わってきます。社員がいる会社の年収の基準も大きく関係してくると言うことでしょうか。

搾取というと労働階級に対する資本家の搾取という意味が一番抽象度の高い’搾取’の意味だと感じています。
まず一つ大きな搾取として、生産手段を持っていない労働者は生み出した利益分の給与をもらえておらず、労働自体が搾取であると考えています。

保険やローンは、抽象度を一つ上にすると知識不足が原因の搾取と考えることができます。
また、企業(資本家)の利益のために、時間の搾取(スマホなど)や依存性による搾取(ギャンブルや酒や砂糖)もあげられると考えています。

実は、勝手に友だち登録もしていない状態で、メッセンジャーでメッセージを送らせて頂いたのですが、ご迷惑だったでしょうか。

そのうえで、気になった点をあえて書いてみます：

まず「評価システムが正確ではない」場合もあるかもしれませんが、それが給料が安く据え置かれる理由ではありません。たとえ能力 (あるいは利益への貢献度) を正確に評価できたとしても、評価だけで給料が決まるわけではないのです。

おそらく一物一価 (同一労働同一賃金) の法則が念頭にあるのだとは思いますが、なぜ給料がそうならないのか考えてみるのがよいと思います。あるいは逆に一物一価の法則が成り立つ状況としてどんなものがあるか考えてみるのもいいでしょうね。

搾取が何であるか抽象化できたとのことですが、保険やローンの他にどんな搾取があるか列挙できるでしょうか？ 理解できたと思っていても、具体例を挙げようとすると意外と理解が中途半端だったりするものです。

facebook にも書いています ↓ ので、よかったら参照してみてください。

https://www.facebook.com/sengoku.hiroaki/posts/2961784700601877

また、’最も警戒すべきは、 搾取と気付かれないだけでなく、 むしろ進んで搾取されることを多くの人が望むような搾取です’
ここも沁みました。例えば、保険会社のテレビ番組での販売の仕方に対して、がんの患者を登場させて、必要以上に恐怖心をあおり、恐怖心を取り除きたいという需要を無理やり作り出している風に感じていて、それにも関わらず多くの人は保険に入ることを選択しているのを見て、仙石さんの文章がズバリ言語化されており、抽象化できました。

新卒採用って、ポテンシャル採用と言われることもありますが、私にとっては「ポテンシャル」じゃなくてまさに「即戦力」です。

http://www.gcd.org/blog/2006/05/367/
「新卒の段階で既にとてつもなく大きな差がついていることに改めて驚かされました」

最大流量を生み出すための車間距離と車速の最適値は道路によって決まっているので、そのような運転を維持するように誘導すれば良いのです。道路にLEDを一定間隔で埋め込んで、最適車間距離・車速に合わせて流れるように光らせることで、ドライバーの技能、モラル、モチベーションに強く依存せずに、誘導できそうな気がします。

最大流量で流れている状態から渋滞になるのは、ちょっとした余分なブレーキなどで、ある区間の流量が減ってしまったことをキッカケに、そのツケが、その後ろ（時間的にも空間的にも）に波及してしまうというメカニズムだと思います。

この仮説が正しければ、キッカケを作った集団は渋滞にはまらずに逃げきれてしまうわけで、キッカケを作らない行動をすることに対するモチベーションを持たせるのは難しいという課題があります。

区間ごとのリアルタイムな流量を測定する仕組みは整備されているので、流量を俯瞰することはシステムで可能です。大域的な流量と比較して、局所的な流量が減り始めたことを検知すると、その区間のドライバーの流量を向上させるような協力行動（安全を確保しつつ車速を上げて車間を下げる）に対してモチベーションを与えるような仕組みを作ると良いのではないかと思います。

ETCやカーナビに連動して、該当区間のドライバーに警告を上げて、そのドライバーが協力行動をするとご褒美（ETCのポイントなど）が与えられる仕組みが有効だと思います。位置情報を利用したスマホアプリでも実現できそうです。協力行動を検出するのが難しければ、警告を音声で通知することに対してご褒美を与えるようにするだけでも一定の効果は期待できるのではないかと思います。

この記事にあるように、自宅の LAN は、タグVLAN を使っているのですが、対外セグメントの VLAN ID を 1 にしていました。

VLAN ID 1 は (なにかと) 問題を起こす機器が多いので避けたほうが無難と言われますが、そんなに多種多様な機器があるわけじゃない (なにせ家庭内の LAN ですから) ので大丈夫だろうと VLAN ID 1 のまま使っていました。

ところが！ 昨今のスマホの普及でマンションの住民の中にネットを使う人が激増したせいか、マンション内のグローバルIP アドレスが枯渇気味になってきました。マンションのルータから DHCP でグローバルIP アドレスが割り当てられるわけですが、各戸グローバルIP アドレス 5個までという制限がより厳格に適用されるようになったのです。

わたし的には最大 5個しか使ってないつもりなのですが、マンションのルータはそう思ってくれないらしく、対外サーバを (メンテなどで) いったん外し、1時間くらいたってから再度つなぐと、グローバルIP アドレスを割り当ててもらえないという事態が頻発しました。

酷いときは、DHCP のリース時間の更新ができずに、運用中の対外サーバがグローバルIP アドレスを失うケースさえありました。

いったいどの機器が余計にカウントされて 5個制限にひっかかっているのか？ あるいは、単にマンションのルータのバグで、DHCP リクエストに応答しなくなってるだけなのか？

前者なら、余計にカウントされている機器を外せばいいだけですが、あいにく全く心当たりありません。DHCP リクエストを出している機器は (最大) 5個しかないハズなんです。

後者の可能性が濃厚だったので、マンションのネットの管理を担当している会社に電話をかけて相談してみたのですが、(予想通り) あまり技術に詳しくない人が対応するばかりで全く埒が明きません。

グローバルIP アドレスを失ったときは、天井裏を開けて、アップリンクのイーサケーブルを外せばグローバルIP アドレスの再割当が行われるので、手間ではあるのですが致命的ではないので、半ば諦めつつ放置状態でした。

で、昨日ふと、そーいえば VLAN ID 1 は鬼門だったなぁと思って、ダメ元で対外セグメントの VLAN ID を 10に変更してみました。すると… いままで意固地なまでに DHCP リクエストに反応してくれなかったマンションのルータが、あっさりグローバルIP アドレスを割り当ててくれるようになったのです！

教訓: VLAN ID 1 は避けるべし