Raspberry Pi Zero W / OpenCV 3.x ArUcoも使える

連投失礼
Raspberry Pi Zero W に最新の OpenCV 3.x をインストールした
Raspbian の標準パッケージの OpenCVは、旧バージョンのOpenCV 2.x であり、ARコードを認識する ArUcoも使えない
そこで、最新の OpenCV 3.x をインストールし、ArUcoも使えようにした

現状、最新の OpenCV 3.x のバイナリはないので、ソースコードから構築するしかない
Core i7 なら、5分もあれば make が終わるのに、Raspberry Pi Zero W だと14時間以上もかかってしまった
しかし、14時間かかっても構築可能だということが判ったので、報告する

構築には、最低限 16GB の microSD にデスクトップ版 Raspbian を入れたものを用いる

$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get install -y build-essential cmake pkg-config
$ sudo apt-get install -y libjpeg-dev libtiff5-dev libjasper-dev libpng12-dev
$ sudo apt-get install -y libavcodec-dev libavformat-dev libswscale-dev libv4l-dev
$ sudo apt-get install -y libxvidcore-dev libx264-dev
$ sudo apt-get install -y libgtk2.0-dev
$ sudo apt-get install -y libatlas-base-dev gfortran
$ sudo apt-get install -y python2.7-dev python3-dev
$ sudo apt-get install -y libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev
$ mkdir opencv
$ cd opencv/
$ git clone https://github.com/opencv/opencv.git
$ git clone https://github.com/opencv/opencv_contrib.git
$ cd opencv
$ mkdir build
$ cd build/
$ cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -D INSTALL_PYTHON_EXAMPLES=ON -D OPENCV_EXTRA_MODULES_PATH=/home/pi/opencv/opencv_contrib/modules -D WITH_GSTREAMER=ON -D BUILD_EXAMPLES=ON ..
$ nohup make &
<< 上記のようにしておけば、ssh などでコマンドしておいても、途中でログオフできる >>
<< 私の環境では、14時間18分もかかった >>
$ sudo make install
$ sudo ldconfig

プログラムは、python なので、インデントが表示できないブログでは、表示できないので、下記からダウンロードしてもらいたい
「camera.tgz」をダウンロード
解凍すると 「camerapi.py」と「camerausb.py」になる

ラズバイ専用カメラなら
$ python camerapi.py

USBカメラなら
$ python camerausb.py

である。ブログ冒頭の画像は、カメラでARコードを読み取り認識したところのスクリーンショットである
なお、OpenCVは、Python2 でも Python3 でも使える

追記 2017.08.28
先日の記事で、「python3 では使えない」と書いていたが、その後の調査で、Python3 でも使えることが判ったので、当該箇所を削除した

Raspberry Pi Zero W ミニサーバー と DNS

前回の記事に書いた RTC とシャットダウン・ボタンを写真のようなケースに入れてミニサーバーにした
本当は、FRISKのケースに入れたかったのだが、RTCを入れると、どうしても大きくなってしまう。
そこで、千石電商で買った 80 x 40 x 20 mm のケースに入れることにした
中は、次の写真のように、2枚の基板をロープロファイルのヘッダーで結合する形式にしている（回路は前回示した通り）
これなら、必要な時に分解して、カメラを接続するなり、ブレッドボードで実験するなり、自由にできる
実は、失敗したなあと思うところが一つある
RTCを左側に、押しボタンスイッチと LED を右側に半2階に飛び出した配置にしているが、左右逆にすれば良かった
千石電商で買ったケースは、対角に蓋を絞めるネジが付いているのだが、これと干渉するが、
左右逆なら問題ない
ケースの表面には、アクセスしやすいように、SSIDやパスワード、最初にアクセスすべき URL を QR コードをシールで貼った
（写真は、凄く簡単な SSID と パスワードにしているが、実際に作る時は、難しいパスワードに変えるように）

カメラで、 UR コードが認識できるスマホなどからだと、簡単に Wifi に接続できる

なお、ホスト名は、「raspberrypi」から「piserver」に変更している
と、ここで問題が起こった
接続した Android スマホから「http://piserver.local」の URL が接続できないのだ
Ubuntu からなら、接続できるのに

DNSを立てる
調査の結果、Raspberry Pi Zero W が DHCP サーバーとしては働いているが、DNS サーバーになっていないことが判った
急遽、DNSサーバーをインストールしたが、普通 Linux で使われる bind9 は上手く行かなかった
代わりに、dnsmasq を使った

$ sudo apt-get install dnsmasq dnsutils
$ sudo vim.tiny /etc/hosts
<< 下記のようにした >>
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
127.0.11.1 piserver
192.168.123.234 piserver.local

また、/etc/dhcp/dhcpd.conf のドメインネームサーバーのところに、192.168.123.234 を追加する。

option domain-name-servers 192.168.123.234, 192.168.137.1;

これで、再起動すると、スマホからでも、Ubuntuからでも「http://piserver.local」が接続できる

なお、DNSが正常じゃなかった時点で、なぜ、Ubuntuから「http://piserver.local」が接続できていたかは謎である

追記
『DNSが正常じゃなかった時点で、なぜ、Ubuntuから「http://piserver.local」が接続できていたかは謎である』の部分ですが、Twitterで、GNUE(鵺) @gnue さんが、教えてくれました
・ホスト名.local となってるものは mDNS と思っていいかと思います。ホスト名がぶつかった場合は ホスト名+数字.local みたいに自動的に名前解決が行われます。ちなみにその性質上 同一LAN上でのみ使えます
・Raspbianには最初からmDNSが入ってます
・Ubuntu が接続できたのは、Ubuntuにavahi (mDNSのソフト）が入ってたからでしょう。
・おそらく、Android が mDNS に対応してないために、接続できなかったと思われます
・なお、 Apple が macOS/iOS で使用している Bonjour と同じプロトコルですなので、iPhone なら接続できたかもしれません

どうも有難うございます

Raspberry Pi Zero W RTC と シャットダウン・ボタン

先日のブログ にも書いたが、Raspberry Pi Zero W をアクセスポイント化して、山奥とか離れ小島とか、インターネットにアクセスする方法がない場所でも、チャットや対戦ゲームやチェックリストのオリジナルなプログラムを、仲間内だけで使うような ミニサーバーを作ろうと思っている
が、大きな問題があった

Raspberry Pi Zero W には、リアルタイムクロックが無い
これは、Raspberry Pi Zero W に限らず、Raspberry Pi シリーズは全てリアルタイムクロックがない
このため、起動すると、前回シャットダウンした時刻にシステムクロックが止まったままになる
もちろん、インターネットアクセスが可能なら、即座に NTP に接続し、システムクロックを修正するのだが、そもそもインターネットアクセスができないような場所で、チャットや対戦ゲームやチェックリストをやりたいのだから、困ったしまう
もう一つの問題は、リアルタイムクロックに比べると些細だが、単独ではシャットダウンする方法がないことだ

そこで、RTC と シャットダウンするためのボタンを追加することにした
ついでながら、ステータス表示のための LED も追加した

必要な部品
秋月電子にて
・DS1307　I2Cリアルタイムクロックモジュール(RTC) 750円
・2色LED　赤・黄緑3mmクリアボディ　OSRGHC3131A　(10個入) 150円　：　使うのは 1個
その他
・押しボタンスイッチ
・抵抗 5.1kΩ 2個

配線
・Raspberry Pi Zero W 部品
・2pin 5V ⇔DS1307 P1 3pin Vcc
・3pin SDA1 ⇔DS1307 P1 4pin SDA
・5pin SCL1 ⇔DS1307 P1 5pin SCL
・30pin Gnd ⇔DS1307 P1 2pin Gnd
・29pin GPIO5 ⇔押しボタン
・33pin GPIO13 ⇔LED (赤) 5kΩ経由
・35pin GPIO19 ⇔LED (緑) 5kΩ経由
・30pin Gnd ⇔押しボタン・LED コモンカソード

シャットダウンプログラム
・ブログのせいで、インデントが表示されず、見にくいところ、申し訳ない

/usr/local/sbin/raspi_shutdown.sh

#!/bin/sh
count=0
b_status=0
b_count=0
flg_ping=0
while :
do
sleep 0.5s
if [ $b_status -eq 0 -o $b_status -eq 1 ]; then
case $count in
0)
echo 0 > /sys/class/gpio/gpio13/value
echo 1 > /sys/class/gpio/gpio19/value
;;
1)
if [ $flg_ping -eq 0 ]; then
ping -c 1 -W 1 google.com > /dev/null 2>&1
if [ $? -eq 0 ]; then
echo 0 > /sys/class/gpio/gpio13/value
flg_ping=1
else
echo 1 > /sys/class/gpio/gpio13/value
fi
else
echo 0 > /sys/class/gpio/gpio13/value
fi
echo 0 > /sys/class/gpio/gpio19/value
;;
esac
elif [ $b_status -eq 2 -o $b_status -eq 3 ]; then
case $count in
0)
echo 1 > /sys/class/gpio/gpio13/value
echo 0 > /sys/class/gpio/gpio19/value
;;
1)
echo 0 > /sys/class/gpio/gpio13/value
echo 0 > /sys/class/gpio/gpio19/value
;;
esac
elif [ $b_status -eq 4 ]; then
echo 1 > /sys/class/gpio/gpio13/value
echo 0 > /sys/class/gpio/gpio19/value
fi
SHUTDOWN=$(/bin/cat /sys/class/gpio/gpio5/value)
case $b_status in
0)
if [ $SHUTDOWN = 0 ]; then
b_status=1
b_count=0
fi
;;
1)
if [ $SHUTDOWN = 0 ]; then
b_count=`expr $b_count + 1`
if [ $b_count -eq 10 ]; then
b_status=2
b_count=0
fi
else
b_status=0
b_count=0
fi
;;
2)
if [ $SHUTDOWN -ne 0 ]; then
b_status=3
b_count=0
fi
;;
3)
if [ $SHUTDOWN = 0 ]; then
b_status=4
b_count=0
else
b_count=`expr $b_count + 1`
if [ $b_count -eq 10 ]; then
b_status=0
b_count=0
fi
fi
;;
4)
if [ $SHUTDOWN = 0 ]; then
/sbin/shutdown -h now
else
b_status=0
b_count=0
fi
;;
esac
count=`expr $count + 1`
if [ $count -eq 2 ]; then
count=0
fi
done

なお、このプログラム、元々は日経LINUX 2017年2月号の記事を参考にしたのだが、日経LINUXの記事のままだと、Raspberry Pi Zero W の少ない CPU の負荷が100％になってしまうので、改良した
また、Raspberry Pi Zero W のステータス表示機能も追加している

RTC の設定

$ sudo raspi-config
<< i2cをイネーブルにする >>
$ sudo reboot

再起動

$ sudo apt-get install i2c-tools python-smbus
$ sudo modprobe rtc-ds1307
$ sudo apt-get remove fake-hwclock
$ sudo dpkg --purge fake-hwclock

/etc/rc.local のファイル末に下記を追加

echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
sudo hwclock --adjust || true
sudo hwclock -s || true
echo 13 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio13/direction
echo 0 > /sys/class/gpio/gpio13/value
echo 19 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio19/direction
echo 0 > /sys/class/gpio/gpio19/value
echo 5 > /sys/class/gpio/export
echo in > /sys/class/gpio/gpio5/direction
/usr/local/sbin/raspi_shutdown.sh &
exit 0

ここで、一度、再起動

使い方

RTCモジュールについているボタン電池は、充電池なのだが、秋月電子で購入したときは、ほぼ空になっていた
起動した状態で充電できるようなので、最初は、何時間か連続で通電しておく
インターネットに接続し、NTPで時刻が正しくなっている状況で、

$ sudo hwclock -w

とやると、RTCが設定される

最初の内は、RTCの誤差が大きい（私のRTCの場合は、24時間で6秒も遅れた）
インターネットのNTPで正しい時刻にシステムクロックが設定されている時に、「$ sudo hwclock -w」を何度か繰り返しているうちに、誤差が補正される
これは、/etc/rc.local のファイルの中で、「sudo hwclock --adjust」と補正オプションが指定されているため、補正値を自動設定しているからだ
補正が正しくできるようになったら、インターネットアクセスは必要なくなる

電源が入り、OSが起動すると、LEDが点滅してステータスを表示する
インターネットアクセスにアクセスできないうちは、LEDは「赤と緑が交互に点滅」になる
そのうち、インターネットアクセスが確立したら「緑だけの点滅」になる
（当然ながら、インターネットアクセスが不可能な山の中や離れ小島では、「赤と緑が交互に点滅」のままだ）
押しボタンを長押しすると、LEDは「赤だけの点滅」に変わる
ここで一度指を離し、再びボタンを押すと「赤の点灯」になり、その後、シャットダウンする

さて、今回は、ブレッドボードで回路を作ったが、次回は、ユニバーサル基板に半田付けし、小さなケースにいれて、『ミニサーバー』にする予定だ

Raspberry Pi Zero W ブレッドボード

Raspberry Pi Zero W だが、外部と結線するところをどうするか、悩んでいた
どうせなら、汎用的な I/F にするべきだろうが、普通の Raspberry 3などと同じにすると、表側（CPUの付いた面）側にオスのヘッダを付けることになり、そうすると、折角の専用ケースに入らなくなる
Raspberry Pi Zero 専用ケースには、裏面側に I/Fが通る穴がある
そこで、裏表逆になるが、基板裏面側に I/F 用に秋月で売っているロープロファイルピンヘッダ（オス）を半田付けすることにした

これに、やはり秋月で300円で売っている ラズベリーパイB+/A+ブレッドボード用変換基板に ロープロファイルピンソケット（メス）および、細ピンのヘッダを半田付けしたものを用意する
と、ブレッドボードに挿して、実験しやすくなる

左の写真のように、ヘッダを半田付けした Raspberry Pi Zero W は専用ケースにすっぽり入る

実は、この状態で、専用カメラが付いた状態なのだが、全く問題なく入る。
　

ケースの裏側は、このような状態

ほんの少しだけ、ヘッダピンが飛び出しているが、ロープロファイルを使っているので、あまり気にならない程度だ
　
　
　
　
　
　
　
　
　
　

最後に、ブレッドボードに付けた状態
専用ケースの中には、Raspberry Pi Zero Wと専用カメラが入った状態だ

これなら、色々と実験できる

で、実際に、これを使って実験して、作ったものは、また、次回以降に紹介予定

Raspberry Pi Zero W CPUの謎とカメラ

Raspberry Pi Zero Wの謎
・一番大きなチッブ（おそらくCPU等の入ったSoC）が何故かエルピーダの刻印。エルピーダってメモリでしょ？
・小さなWifii/Bluetoothと思われるチップと、プリントされたアンテナ
・裏面はパスコンの全く無い、真っ平・・・

これをTwitterで呟いたら、「Package on Package でDRAMの下にCPU SoC がある」と教えてもらった。
ネットを調べたら、ZeroではないRaspberry Piですが、分解（破壊）動画見つけた

Under The Raspberry Pi CPU: The Actual Soc / CPU

2分あたりでCPU＆メモリを剝がしているが、これと同じような実装方法であろう。
しかし、凄い実装法だなぁ

ラズバイ専用カメラ

Raspberry Pi Zero Wに、アマゾンで850円で買ったカメラを付けた。何の問題もなく、写真が撮れる
1200円のラズパイゼロWと850円のカメラで、Wifi接続のWebカメラになる。

私の買ったのは、これ
アマゾン => HiLetgo　OV5647 5MP　カメラ　OV5647 HDカメラモジュール 　Raspberry Pi に対応　A/B+/2 モデルB ケーブル
ラズパイ A/B+/2 モデルB 用とあるが、Zero Wでも変換ケーブルさえあれば動く。
私が買ったときは850円だったが、今は800円だ（2017．08.06現在）

実際に送られてきたのが、これ。シンガポールから送られてきた。
Raspberry Pi Camera Rev. 1.3 と書いてある。
調べると、ラズパイカメラは、V1.3 が500万画素、V2.1が800万画素。V1.3 は製造中止になり、V2.1が現行品らしい。
あんまり安いんでパチモンかもしれないと思ったが、どうやら、売れ残りのV1.3の在庫処分品だったのだろう。

WifiやBluetoothが付いているものは、海外から輸入すると技適の関係で違法になる可能性があるから、海外からは買わない
でも、カメラなど、電波出さないものは、関係ないから、海外から安いのを買っちゃう・・

なお、カメラとRaspberry Pi Zero Wを結ぶケーブルは、専用ケースに付属していたもの。Raspberry Pi 2や3と比べて、カメラ用のコネクタが小さいので変換ケーブルが必要なんだが、専用ケースに付属していた。Raspberry Pi Zero W、単品では購入できず、専用ケースとのセット販売で買ったのだが、この変換ケーブルが付いていたので、役にたった。ちなみに次の写真のようにカメラを付けた状態でケースに入る。

で、このカメラを使って、「静止画を撮る」「動画のストリーミング」「OpenCVで画像解析」をやってみた

静止画を撮る
第43回「Raspberry Pi Zero V1.3＋カメラモジュールでミニ定点カメラを作ろう！」
これで、OK!

動画のストリーミング
mjpg-streamerでraspberryPiのカメラからストリーミングをする方法
これ、Raspberry Pi 2や3用の記事と思われるが、そのままでOK!
ただし、ストリーミングは、5fpsくらいで遅いが

OpenCVで画像解析
講談社ブルーバックスの「実例で学ぶＲａｓｐｂｅｒｒｙ　Ｐｉ電子工作　作りながら応用力を身につける」
この本の7章の「円の抽出」と「顔検出」を試してみた。これRaspberry Pi ＋や2用プログラムだが、Zero Wでも上手く行った

やって気が付いたのだが、UVC規格のUSBカメラでもOpenCVで画像解析できる
ラズパイ専用カメラでも、USBカメラでも、とにかく安いカメラをRaspberry Pi Zero Wに接続して、何か面白いものを作りたいな

Raspberry Pi Zero Wを買った アクセスポイント化に成功

先日 (7月18日)、Raspberry Pi Zero Wが、やっと技適を取得し、販売が開始された。早速購入。7月21日に届いたので、約一週間。
その間、Rasbianのデスクトップ版やCUI版を試すが、この辺の話はネット上にも多数載っているので、特に報告することはない。

その後、USBケーブルだけで Raspberry Pi Zero W をセットアップする方法と、それを使って、無線アクセスポイント・ルーター化することに成功した。この2つは一寸特殊な使い方なので、これらを紹介する。

前半：USBケーブルだけで Raspberry Pi Zero W をセットアップ
私は、母艦に Windows10マシンを使ったが、UbuntuでもMACでも使えるらしい。(Ubuntuは確認済み。MACについては、私がMACを持っていないので未確認）

まず、https://www.raspberrypi.org/downloads/raspbian/ から、2017-07-05-raspbian-jessie-lite.zipをダウンロード。
これを解凍して得た 2017-07-05-raspbian-jessie-lite.img を Win32DiskImager を使って、microSDに書き込む。
microSDは、8GB以上が推奨されているようだが、2GBでも動いた。

Windows10が microSD を識別すると boot ドライブが見つかるが、このなかに
・ssh と言う名の空ファイルを作る
・cmdline.txt を次のようにする
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait modules-load=dwc2,g_ether quiet init=/usr/lib/raspi-config/init_resize.sh quiet splash plymouth.ignore-serial-consoles
・config.txt の最後に下行を追加
dtoverlay=dwc2

Windows10側としては、
・RPI Driver OTG:URLからドライバーをダウンロードして解凍しておく
・iTunes もしくは、Bonjour Print Services (Windows)をダウンロードしてインストしておく

最初の接続
・先ほど作った microSD を Raspberry Pi Zero W に挿入
・USBケーブルで、母艦PCとRaspberry Pi Zero Wを接続
・Windows10側のコントロールパネルのデバイスマネージャーのCOMの項目に「USBシリアルデバイス(COM6)」が増えている（COMの番号は、異なる場合があるので注意）
・「USBシリアルデバイス(COM6)」を右クリックし、ドライバーソフトウェアの更新
・「コンピューターを参照して、ドライバーソフトウェアを検索します」で、先ほどダウンロード・解凍しておいた RPI Driver をインスト
・デバイスマネジャーのネットワークアダプターに「USB EthernetRNDIS Gadget」が追加される
・しかし、エラーが出ている（どうも、1回目にエラーが出るのは、共通らしい）
2回目の接続

・Windows10 の再起動
・デバイスマネジャーのネットワークアダプターに「USB EthernetRNDIS Gadget」が追加される
・ Raspberry Pi Zero W に接続しても、今度はエラーなし

・Puttyjp.exe や TeraTerm で、raspberrypi.local を SSH 接続できる。
・デフォルトでは、IDは pi パスワードは raspberry
・このままでは、Raspberry Pi Zeroからインターネットをアクセスできない

Raspberry Pi Zeroからインターネットをアクセス

・Windows10側「コントロールパネル」「ネットワークとインターネット」「ネットワークと共有センター」
・Wifi(xxx：貴方が接続しているWifiのSSID)をクリック「プロパティ」「共有タブ」「インターネットのほかのユーザーに、このコンピューターのインターネット接続をとおしての接続を許可する」を選択
・「コントロールパネル」以下のダイアログを「OK」ボタンなどで全て消す
・しばらくすると、Raspberry Pi Zero Wからインターネットをアクセスできるようになる
・sudo apt-get install で、Apache2をインストールすると、母艦のWindows10から http://raspberrypi.local でアクセスできるようになる

後半：アクセスポイント化

これは、Raspberry Pi 3に内蔵の WiFiを使った無線LANアクセスポイント化 hostapd + isc-dhcp-server編を参考にしたが、Raspberry Pi Zero W にアレンジしている

$ sudo apt-get install hostapd isc-dhcp-server

/etc/network/interfaces を次のようにする

source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopback
iface eth0 inet manual
allow-hotplug wlan0
iface wlan0 inet static
address 192.168.123.234
netmask 255.255.255.0
network 192.168.123.0
broadcast 192.168.123.255
allow-hotplug wlan1
iface wlan1 inet manual
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

/etc/dhcpcd.conf を次のようにする

hostname
clientid
persistent
option rapid_commit
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
option ntp_servers
require dhcp_server_identifier
slaac private
nohook lookup-hostname
denyinterfaces wlan0

$ sudo service dhcpcd restart
$ sudo ifdown wlan0; sudo ifup wlan0

/etc/dhcp/dhcpd.conf を次のようにする

ddns-update-style none;
default-lease-time 600;
max-lease-time 7200;
authoritative;
log-facility local7;
subnet 192.168.123.0 netmask 255.255.255.0 {
range 192.168.123.100 192.168.123.120;
option routers 192.168.123.234;
option broadcast-address 192.168.123.255;
option domain-name local_pi_dns;
option domain-name-servers 8.8.8.8 4.4.4.4;
default-lease-time 600;
max-lease-time 7200;
}

なお、「8.8.8.8 4.4.4.4」を「192.168.137.1」にすると、母艦 Windows10 のドメインサーバーの設定を引き継ぐようである

/etc/default/isc-dhcp-server を次のようにする
INTERFACES="wlan0"

$ sudo bash -c "zcat /usr/share/doc/hostapd/examples/hostapd.conf.gz > /etc/hostapd/hostapd.conf"

/etc/hostapd/hostapd.confは長いので、変更点のみ記す

「# driver=hostap」を「driver=nl80211」に
「ssid=test」を「ssid=WIFISSID」に
「#wpa=1」を「wpa=2」に
「#wpa_passphrase=secret passphrase」を「wpa_passphrase=PASSWORD」
（さすがに SSID と パスワードは書き換えてね）

/etc/default/hostapd を次のようにする
DAEMON_CONF="/etc/hostapd/hostapd.conf"

/etc/sysctl.conf を次のようにする
net.ipv4.ip_forward=1
net.ipv6.conf.all.disable_ipv6 = 1

/etc/rc.local を次のようにする
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
printf "My IP address is %s\n" "$_IP"
fi
iptables-restore < /etc/iptables.ipv4.nat
exit 0

$ sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"
$ sudo iptables -t nat -A POSTROUTING -o usb0 -j MASQUERADE
$ sudo iptables -A FORWARD -i usb0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
$ sudo iptables -A FORWARD -i wlan0 -o usb0 -j ACCEPT
$ sudo sh -c "iptables-save > /etc/iptables.ipv4.nat"
$ sudo reboot

とやって、再起動
これで、アクセスポイント化ができた

アクセスポイント化して、どうするの？
これを説明したのが、2つ目の絵。

例えば、出先で、仲間だけでネットを組みたい場合。
図のようにアクセスすれば、Raspberry Pi Zero W にファイルサーバーを立てておけば、ファイルの共有化ができる。
ファイルサーバーが無くても、フォルダーを共有化しておけば、仲間内だけで、ファイルの共有も可能だ。
この場合、パスワードさえ破られなければ、仲間以外からファイルを守ることができる。外から中には入って来れないが、中から外をアクセスすることは可能なので、Googleでの検索やLine、メールなどは普通に使える。

まあ、正直、ファイルの共有くらいなら、外部のクラウドサービスを使った方が早いのだが、むしろ、Apache2やNode.jpを使って、WebSocketを駆使したチャットや対戦ゲームやチェックリストの方が効果があるだろう。
チャットや対戦ゲームやチェックリストのオリジナルなプログラムを作って、仲間内だけで使う。
この場合、山奥とか離れ小島とか、インターネットにアクセスする方法がない場所でも、（もちろんインターネットアクセスはできないが）仲間内でのチャットや対戦ゲームやチェックリストを使うことができる。

一番やってみたいのは、最後のチェックリストなんだよね。
WebSocketを駆使して、誰が何を何時何分に作業し、チェックしたのかを、メンバー全員にリアルタイムで配信して、作業効率を上げるんだ・・

2017.08.05 誤記があったので、少し修正

SFのアイデア

先日、酒を飲みながら、ちょっとしたSFのアイデアを考えてみた。
前半くらい迄のプロットを書いてみるので、誰か小説にしてくれないかなあ・・

== ここからプロット ==
ほぼ、我々と同じような世界。
17世紀にガリレオ、ケプラー、ニュートンが天体観測から力学をはじめ科学を作り上げる。
18世紀、ジェームズ・ブラッドリーが光行差を発見するのだが、方向性による微妙な違いがあることに気が付く（この辺から我々の歴史と異なり始める）。
19世紀後半、マイケルソンとモーリーは干渉計を使い、光の速度を測定する。この時、地球の公転速度に依存せず、光速が一定であることを発見する。しかし、公転速度方向とは関係のない方向に光速の微妙なずれも発見する。そのずれはブラッドリーの観測とほぼ一致するも、ごくわずかの時間的変異があることも観測する。

20世紀初頭、アインシュタインはマイケルソン・モーリーの観測からローレンツ変換の考えを経て、特殊相対性理論を構築する。それから10年後、理論を拡大した一般相対性理論を発表。この中で、空間の伸び縮みが伝達する重力波を予言し、ブラッドリーとマイケルソンが観測したずれが重力波の可能性であることも示唆する。

残念ながら第一次世界大戦は起こるのだが、大戦後、ハッブルは遠くの銀河ほど、速い速度で地球から離れていく事いわゆるハッブルの法則を発見する。
この時、同時に天の川銀河とアンドロメダ星雲が衝突しつつあること観測する。

ハッブルの観測は高い精度ではなく、予想の幅が大きかったが、最短の場合、50年で2つの銀河の中心同士が衝突し、その衝撃で地球が滅びる可能性すらあることが判った。

急速に迫りつつあった二番目の世界大戦は回避された。
地球と人類の滅びる可能性は、戦争どころではないことが全人類に伝えられたからである。

世界初の巨大プロジェクトであるペルセウス計画（マンハッタン計画でもアポロ計画でもなく）が始まった（鎖に繋がれたアンドロメダ姫を開放するのはペルセウスしかいないと言う意味）。
ペルセウス計画は（マンハッタン計画＝原爆開発でもアポロ計画＝月着陸でもなく）、2つの銀河の衝突の正確な時間とその影響を予測し、人類の滅亡を避けることが目的であり、アインシュタインを中心に、オッペンハイマーをリーダーとして、ノイマン、チューリング、ゲーデルを始め、チャンドラセカール、フェルミ、ガモフ、湯川など、連合国・同盟国・資本主義・共産主義の壁を越えて、世界中から最高の知性が集められた。

宇宙空間からの観測は、オーベルト、ゴダード、フォン・ブラウンを中心としたロケット開発班が担当した（平和目的のロケット開発であれば、オーベルトが離脱する理由はない）。　（ツィオルコフスキーは1935年に亡くなったので、残念ながら間に合わなかった）　ロケット開発班には、のちにコロリョフや糸川も加わる。

宇宙空間からの観測が早期に行われ、世界中の超A級の知性が（戦争などに無駄遣いされることもなく）集結したため、銀河の衝突のメカニズムの解明は急速にすすむ。（宇宙論やブラックホールなどの科学に関しては数十年先行し、1960年代時点で現在の科学レベルに到達している。逆に原子爆弾・原子力発電など、原子力関係の応用技術分野は遅れている）

1969年7月、ついにペルセウス計画は、銀河の衝突のメカニズムを解き明かした。
・2つの銀河の中心にある巨大ブラックホールは既に衝突している。
・巨大ブラックホールの衝突の結果、太陽の数万倍の質量分が失われ、それがエネルギーとして、重力波・ガンマ線・エックス線・高エネルギー粒子の形で一瞬に放出される（以降、このエネルギー群をフラッシュと呼ぶ）。
・ブラックホールから2万光年ほど離れている地球には、光速で進むフラッシュは未だ届いていない。
・ブラッドリーとマイケルソンが観測した重力波は、衝突以前に渦巻状に互いを回るブラックホールから放射されたものである。
・フラッシュが地球に届くと、その強力なエネルギーのため、海は沸騰し、空気は吹き飛ばされ、ガンマ線とエックス線の放射線により全ての生命が一瞬で滅亡する。
・フラッシュが地球に届くまで、1000年プラスマイナス100年と予想される。

この話の舞台は、実は『我々の地球』ではない。
今から40億年ほど未来、天の川銀河とアンドロメダ星雲が衝突するときに、『我々の地球』と同じように独自進化した星の物語である。

残された時間は、1000年。
彼らは生き残ることができるであろうか？？
== ここまでプロット ==

ね。イーガンとかバクスターばりのSFになりそうでしょ

ちなみに、舞台となる世界での科学・技術は、我々に比べ
・1940年までは、ほぼ同じ。
・ブラックホールなどの宇宙論は、1960年時点では50年程度進んでいる。
・逆に原子爆弾・原子力発電など、原子力関係の応用技術分野は大きく遅れている。
・航空機技術も遅れている。1970年でもプロペラが主流で、音速は超えていない。21世紀に入って初めてジェット旅客機が実用化された。
・ロケット・人工衛星などの宇宙技術は進んでいる。
・電子技術は宇宙技術の余波で進んでいる。
・ジェット機が遅れた分、通信技術が進んで、インターネットは、20年早く出現した。
・日本においては、第二次大戦が無かったため、軍は残っている。が、そもそも戦争が激減している。国同士の戦いよりも、ブラックホール衝突での人類滅亡を防ぐことが共通の目標になっているため。
・環境保護の思想は、ほぼない。温暖化は進んでいるが、どうせ先の無い世界だから保護する必要も無いと考える。21世紀になってもハイブリッド車もEVも出現せず、化石燃料を使ったエンジンが主流。
・資源保護の観点もない。残された時間で資源を使い切ることはあり得ないと考えている。
・したがって、粛清や節約の思想もない。資源を使いきろうとするので、物質的には、むしろ贅沢。
・逆に最も価値が高いのは「時間」。残された限りある時間を無駄にすることは、最大の悪と考える。無駄な会議や残業は皆無。
などなど・・・

実は、「じゃあ、1000年で、どうやって滅亡を避けるのか」は、未だ考えていない。

誰か、イーガンとかバクスターばりのSFを書かないか？
滅亡から逃れる方法は、一緒に考えるから・・・・

（なんかあったら、Twitterの @madnoda に）

2 in 1 タブレットPC ECS LIVA TE10EA3

メインで使っているノート/タブレットPCを更新した。
新規購入した 2 in 1 モバイル・ノート/タブレットPCが自宅に届いたのが5月31日。
それから、1か月。だいたい使い方が定まって来たので、このパソコンの使用報告をしよう。

今回、購入したのは、10.1インチの 2 in 1 モバイル・ノート/タブレットPC ECS LIVA TE10EA3 のストレージ容量128GBタイプである。最大の特徴は、WACOMによる電磁誘導デジタイザ・ペン入力を持つことだ。

今まで使っていたPCは、8インチタブレット lenovo Miix 2 8 128GBであるが、2つ大きな問題があって、今回更新した

・私の老眼が進んでいて、8インチ画面だと小さすぎて読めない
・絵を描こうにも静電容量型のタッチスクリーンでは、まともに描けない
特に2つ目は深刻で、タッチペンを色々購入しても一向に改善しない。自己静電発生式 スタイラスペンも試してみたが、ダメだった。
ソフトウエア側の問題かとも思い、CLIP STUDIO PAINT PROも購入したが、これでも改善しない。やはり、原因はハード側だ。

Zaurus SL-C860・FMV-BIBLO LOOX U/C30と、電車の中などで絵を描いてブログにアップしていたのが、Miix 2 8にしてからは、家の中でUSB接続の外部デジタイザを使ってのお絵描きになった。ブログの更新が極端に少なくなったのは、このせいもある。

さて、新規パソコンの候補に挙がったのは、下記の3機種だ。いずれもペン入力付き。
・ECS LIVA TE10EA3 32GB:約4万5千円 128GB:約6万円
・ASUS TransBook Mini T102HA 64GB:約4万8千円 128GB:約6万円
・lenovo YOGA BOOK with Windows 64GB:約5万円
話題のドスパラのraytrektabが入っていないのは、前述のように8インチでは老眼のため画面が良く見えないからだ。
そうは言っても、前述の3機種、いずれも中国/台湾製で、国産が入っていないのは残念。国産のパソコンって、高価なんだよねえ。

さて、前述3機種は、10.1インチの 2 in 1 、Cherry Trail ATOM CPU、メモリ容量 4GB、64ビット版 Windows10と、かなり性格の近いものである。

違いはペン等の入力方式だ。LIVAが電磁誘導方式、TransBookが静電発生式、YOGA BOOKは（おそらく）電磁誘導式。
電磁誘導式の方が歴史がある分書き味が良い。静電式は最近進歩し書き味向上しているが、電池が必須なのが大きな欠点。
世の中は、電磁誘導から静電式に移りつつあると言うのが、客観的な見方だろう。
今回は、書き味とペン内部に電池を必要としない電磁誘導を選択した。

こうなると、LIVAとYOGA BOOKの二択になる。
YOGA BOOKは、きわめて個性的なPCで、ディスプレイ部とキーボード部が360度回転するヒンジで繋がっている。そのうえ、キーボード部は完全な平坦で、タッチスクリーン的センサーで入力を行い、ペン入力の時は鍵盤の表示が消えると言うものである。

このように興味深い YOGA BOOKを選ばなかったのは、特徴的なキーボードやペン入力のせいではなく、単にストレージ容量が64GBのモデルしかなかったためである。
一般的な使い方なら、64GBのストレージで足りるであろう。もし足りなくても、大容量MicroSDを入れれば良いだけだ。
しかし、私の場合、Visual STUDIOを始め、Android Studio、STM32、ESP-WROOM-32などのプログラム・クロス開発環境を入れることを考えている。これらは、MicroSDに入れるとアクセス速度が遅くて使い物にならないと言うのが、経験的に判っている。MicroSDは単なるデータストレージなら良いのだが、クロスコンパイラなどのアプリをインストするには向いていない。

このような理由で、ECS LIVA TE10EA3 の 128GBモデルを選択した。
しかし、「ECS」ってメーカー聞いたこともない。
一応、調べると、台湾のメーカーで、マザーボードは有名らしい。最近、超小型PCも出している。日本では殆ど知られていないが、ノートPCも以前から作っていたようだ。私の購入した TE10EA3 は、ECSにとって、珍しい日本に対応したノートPCのようだ。キーボードはちゃんと日本語化してあったし。

さて、購入して、実際に使ってみた感想が、最初の絵だ。
まず、一見して格好悪い。これはベゼル（枠）が大きすぎるからだろう。同じ画面のiPadと比べると、一回り大きいと思えるくらいベゼルが大きくスマートじゃない。その上厚さも厚いので、まるでスマートさに欠ける。
次にキーボード部。これが、ペコペコで感触が悪い。その上、キーボード部についているタッチパッドが誤動作しまくりで、使い物にならない。

ディスプレイの付いた本体側は、ケースも兼ねたキーボード部の「布」を折ったようなところに吸盤で付ける。本体とキーボード部は結線されておらず、Bluetoothで通信されている。要は、キーボード部は、単なるタッチバッド付きのBluetoothキーボードだ。

とにかく、キーボード部に付いているタッチパッドの誤動作が多くてストレスが溜まるので、ポインティングデバイスは、別途、家で余っていたBluetoothマウスを接続することにし、タッチパッドを無効化した。キーボードは生かしたまま、タッチパッドのみを無効化し、その上、別のマウスを使えるようにできるか心配したが、やってみたら何の問題もなかった。

キーボード部は、ペコペコで打ちにくく、肩が凝る。Miix 2 8用に買った Bluetoothキーボードは、マルチペアリングできる上に、パンタグラフ型キーを使った優れもの。これも接続すると、さすがに使い良い。

Bluetoothのキーボードとマウスは、使い心地は良いが、モバイルには向いていないので、出先では、ECS LIVA TE10EA3 付属のキーボードを使おうと、ケース代わりにもなるので、ECS LIVA TE10EA3 をキーボード（ケースも兼ねている）に挟んでリュックやカバンに入れて持ち歩いていた。しかし、重い。本体が500グラムに対して、キーボード部が400グラム以上ある。

思い知ったのが、6月中旬に会津地方に観光旅行に行った時だ。大内宿と言う茅葺屋根の建物の並ぶ宿場街が保存されているのだが、キーボードが重くて、本体ごと、駐車場の車の中に置いて来てしまった。しかし、大内宿には、絵の題材になりそうな建物が多くある。タブレットPC持ってきてたら、ササッと絵の一枚くらい描いたのにと反省しきりだ。

帰宅後、持ち歩きの方針を変えたのが、2枚目の絵だ。
百均で買ったクッションケースに、同じく百均で買ったカラーボードを切って大きさを合わせた板を画面の保護用に入れたものをケースとして使うことにした。安い上に軽い。
この場合、出先では、キーボードは使えないのだが、そもそも電車の中などで付属のキーボードは使えなかった。これはECS LIVAに限った話ではなく、Surfaceを含め、分離型の 2 in 1 モバイル全般に言えることだと思うが、キーボードとディスプレイ部をつなぐヒンジがないため、電車やバスのシートに座った状態で膝の上にパソコンを乗せてキーボードを打つことができない。新幹線や特急列車のようにお弁当を食べるためのテーブルでもあれば話は別なのだが・・（つくばエクスプレスのボックスシートにはテーブルが付いているが、混雑時は使いにくい上に、今後ボックスシート自体が順次廃止されるらしい）

キーボードが無くても、ペンさえあれば、絵を描くのには問題がない。文字入力はタッチキーボードが使えるのは勿論のこと、ペンの場合、手書き文字の認識が非常に良いので、これも問題なし。

電車の中で絵を描いていて気が付いたのだが、前に書いた「ベゼル（枠）が大きくて格好悪い」が、そんなに悪くないことに気付いた。右手にペンを持って、左手でタブレット本体を支えるとき、ベゼルが大きいので持ちやすいのだ。今よりベゼルが細かったら、画面に指があたりタッチスクリーンが反応するから、持ちにくかったと思われる。
Miix 2 8時代に買った CLIP STUDIO を、LIVAに移したら、絵を描くのが楽しいくらいだ。なお、LIVAに使っている Cherry Trail CPUは非力なため、CLIP STUDIOには向かないとネット上で紹介されているところもある。しかし、私はCPUの力不足は感じなかった。まあ、私の使い方では、CLIP STUDIOを十分使い込んでいないからかもしれない。
なお、バッテリーの持ちは連続使用で8時間くらいだと思われる。実は未だ8時間連続で使ったことはなく、6時間連続で使った後、バッテリーの残りが2時間分と表示されたので、そう推定している。まあ、8時間程度使えれば、十分である。

家では、またまた百均で買ったスマホ・タブレットスタンドで立てて、Bluetooth キーボードとマウスを付けて使っている。

気が付いたと思うが、ECS LIVA TE10EA3 付属のキーボードは殆ど使わなくなってしまった。

1か月使った感想としては、
・タブレット部分本体は、満足度95点 足りないのは、タッチスクリーンの感度が少し悪いこと。
・キーボード部は、満足度40点。まあ、付録だと思えば良いだろう。もともと、ペン付きで、このスペックで約6万円は破格に安いのだから・・

さて、お絵描きタブレットとして、ECS LIVA TE10EA3は十分満足できるものだ。ブログにLIVAで描いた絵を使うことこそ、今回が初めてだが、電車の中で思いついたアイデアをササッと描くなど、すでに色々な効果が出ている。
多分、ASUS TransBook Mini T102HAを選んだとしても同じようなものだっただろう。

気になるのは、YOGA BOOKだ。この変態キーボード、いったい役に立つのだろうか？
私の場合、ストレージ容量が64GBしかないので、選択から外したが、一般の使い方なら十分かもしれない。
誰か、YOGA BOOKを買った人が居たら、その感想を教えてほしい。

ESP-WROOM-32のBluetooth Classic SPP接続 Windowsも大丈夫！

ESP-WROOM-32のBluetooth Classic SPP接続だが、前回は、Windowsだと SPP 接続できないと書いた。が、この１０日ほどの間に、GitHub の btstack が何回かアップデートされており、今日試したら、Windowsとも問題なく接続できたので、報告する。

要は、GitHub の btstack が良くなっただけで、私は何もしていない。
前回と全く同じ「patch.patch.gz」をダウンロードして、作業は次の通りする。

$ cd ~/
$ git clone https://github.com/bluekitchen/btstack.git
$ patch -p1 -d btstack < patch.patch
$ cd btstack/port/esp32/
$ ./create_examples.py
$ cd spp_counter/
$ make all
$ make flash << ESP-WROOM-32をUSB接続していれば、書き込まれる >>

これで、前回と同じく Android と接続できるだけではなく、Ubuntu も GUIでペアリングできるようになったし、Windows も接続できる。
私は、Windows １０で試したが、普通にWindows設定・デバイスの Bluetooth でペアリングした後、デバイスマネージャーで、どの COM番号に割り当てられたか確認し、Putty や TeraTerm でオープンすると「BTstack counter （数字）」が送られてくる。
（MACでの動作確認していないのは、単にMAC環境が手元にないだけのことなのは前回と同じ）

Bluetooth SPP を使ったプログラムのやり方

と、これだけでは、寂しいので、Bluetooth SPP を使ったプログラムのやり方を説明しよう。

$ cd ~/
$ git clone https://github.com/bluekitchen/btstack.git
$ patch -p1 -d btstack < patch.patch
$ cd btstack/port/esp32/
$ ./create_examples.py
<< ここまでは上と同じ >>
$ cd ~/
$ cp -rp btstack/port/esp32/spp_counter ./spp_test

さて、必要なファイルは以下の通り

spp_test
├── Makefile
├── components
│   └── btstack
│   ├── component.mk
│   ├── include
│   │   └── btstack_config.h
│   └── main.c
├── main
│   ├── component.mk
│   └── spp_counter.c <= spp_test.c にファイル名変更
└── sdkconfig

・ spp_test/Makefile に２箇所ある「spp_counter」を「spp_test」に変更
・ spp_test/main/spp_test.c に２箇所ある「spp_counter」を「spp_test」に変更
・ spp_test/components/btstack/component.mkの「BTSTACK_ROOT := ../../../btstack」に

本当は、BTSTACK_ROOTを絶対パスで指定したいのだけど、何故か相対パスでしか動かなかった。絶対パスで設定する方法を知っている人がいたら、教えてください。

後は、make して、書き込むだけ。

$ cd spp_test/
$ make all
$ make flash << ESP-WROOM-32をUSB接続していれば、書き込まれる >>

さて、プログラム本体は、spp_test/main/spp_counter.c で、データを送信している部分は、 rfcomm_send(rfcomm_channel_id, (uint8_t*) lineBuffer, strlen(lineBuffer)); だ。

まあ、想像が付くと思うが、rfcomm_channel_id がSPPドライバ番号で、続いてバッファのポインタと送信バイト数だ。戻り値が「0」なら正常に送信できた事になる。
試してみたら、バッファの中はテキストだけではなく、バイナリーでも問題なく、rfcomm_send() の戻り値が「0」以外のときは、バッファの中身が一切送られていないだけだ。
送る時間間隔を短くし、バンバン連続して送ったら、最大25kバイト/秒で送ることができた。

受信の方は、「case RFCOMM_DATA_PACKET:」あたりらしいのだが、まだ試したことはない。
誰か、確認したら、教えてください。

と言うわけで、ESP-WROOM-３２ の Bluetooth Classic SPP接続も使えそうになってきた。
これからが楽しみである。

ESP-WROOM-32のBluetooth Classic SPP接続に成功

GitHubのbtstackが進んでいて、ESP-WROOM-32のBluetooth Classic SPP接続に成功したので、報告する。
前回（4月25日）の時点では、接続後わずか数秒でアボートしていたが、今回は、200kpbs (もしくは250kpbs)と言う高速で安定して通信できるようになった。

ESP-WROOM-32には、3つの無線通信機能がある
・Wifi
・Bluetooth Classic
・Bluetooth Low Energy (BLE)

この内、Wifiは、無線LANそのものなので判りやすいが、Bluetooth Classic と BLE の違いが判り難い。
Bluetooth Classic は、Bluetooth 3.0以前から存在するプロトコルで、どちらかと言えば高速性を目指したもので、BLEは、Bluetooth 4.0で新設されたプロトコルで、高速性よりも低消費電力性を目指したものだ。
Bluetooth 4.0以降は、Bluetooth ClassicもBLEも包含した規格なので、ややこしい。

Wifi、Bluetooth Classic、BLEの特徴を整理すると、おおよそ、次のようになる。
・Wifi:無線LAN 周辺機と言うよりネットワークとしての接続方法。伝送速度は数Mbps以上と高速
・Bluetooth Classic 周辺機器用プロトコル。特にSPPは接続が簡単。速度は実効的に200kpbs程度
・BLE 低消費電力。周辺機器用。速度は実効的に5kbsp程度で遅い。親機専用に個別アプリを作る必要がある。

Bluetooth Classic SPP は、昔からあるプロトコルで、親機のターミナルソフトからシリアル通信できるように接続が簡単なため、良く使われてきた。ただし速度が早い分、消費電力も大きい。
一方、BLEは、新しい規格のため、Androidなら4.3以降、Windowsなら8以降でないと使えないし、親機側にいちいち専用個別アプリを作る必要があって、面倒。その代わり、低速だけど低消費電力のためボタン電池で何ヶ月も使えると言うメリットもある。

私も含めて、自作派としては、馴染みのある Bluetooth ClassicのSPP が、ESP-WROOM-32の無線通信機能の中で、最も使うことができずにいたのが、今回のbtstackで使えるようになったのが、嬉しいところだ。

さて、肝心の使い方だが、、Ubuntu 16.04 上でesp-idfが既にインストールされてるものとして、説明する。
（この辺、前回と前々回の記事を参考して欲しい）
また、パッチも作った。「patch.patch.gz」をダウンロード
作業は次の通り

$ git clone https://github.com/bluekitchen/btstack.git
$ patch -p1 -d btstack < patch.patch
$ cd btstack/port/esp32/
$ ./create_examples.py
$ cd spp_counter/
$ make all
$ make flash << ESP-WROOM-32をUSB接続していれば、書き込まれる >>

これで、例えば Android なら、普通にBluetoothペアリングした後、「BT Simple Terminal」などでオープンすれば、一秒ごとに「BTstack counter （数字）」が送られてくる。（私が試したのは、Android7.0 スマホだが、Android4.2以前のスマホでも接続できるはずだ）

Ubuntuなら、前回と同じようにCUIでペアリングする（GUIでペアリングしていけないのは前回と同じ）
$ sudo rfcomm bind 0 XX:XX:XX:XX:XX:XX
$ sudo chnod 666 /dev/rfcomm0
$ kermit
> set line /dev/rfcomm0
> c
とやると、「BTstack counter （数字）」が送られてくる。（今回は安定して長時間送られてくる）

Windows10の場合、ペアリングまでうまく行くのだが、ターミナルソフトで仮想COMポートを開くとエラーになると言う不具合が残っている。

Ubuntuを親機として、「BTstack counter （数字）」の代わりに大量にデータを送るプログラムを作ったら、毎秒約25kバイトの安定した通信に成功した。毎秒25kバイトは、1バイトは8ビットなので、200kbpsなのか、仮想的なシリアル通信とすると、スタートビットとストップビットを足して1バイトを10ビットとして250kpbsと計算するのかは、わからないが、とにかく、「毎秒約25kバイトの安定した通信」を確認できたことは間違いない。200kbpsだろうが、250kpbsだろうが、Bluetooth Classic SPP接続としては、ほぼ上限値なので、大成功と言えよう。

WindowsでのSPP通信が未だできていなので、完全ではないが、AndroidとUbuntuとの通信実験に成功したので、報告した次第である。
（MACと実験していないのは、単にMAC環境が手元にないだけのことである）