June 07, 2017

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

ESP-WROOM-32のBluetooth Classic SPP接続だが、前回は、Windowsだと SPP 接続できないと書いた。が、この10日ほどの間に、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 10で試したが、普通に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 に2箇所ある「spp_counter」を「spp_test」に変更
・ spp_test/main/spp_test.c に2箇所ある「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-32 の Bluetooth Classic SPP接続も使えそうになってきた。
これからが楽しみである。

| | Comments (0) | TrackBack (0)

May 28, 2017

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環境が手元にないだけのことである)

| | Comments (0) | TrackBack (0)

April 25, 2017

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

E309ESP-WROOM-32のBluetooth Classic接続に一部成功したので報告する。
GitHubのbtstackにESP32対応のブランチがある事を発見した。

やり方だが、まず、Ubuntu 16.04 上でesp-idfが既にインストールされてるものとして、説明する。
もちろん、Ubuntu 16.04 は、Bluetooth内蔵、またはBluetooth USBドングルを持っているものとする。

適当なディレクトリで下記を実行する。
$ git clone https://github.com/bluekitchen/btstack.git
$ cd btstack
$ git checkout -b esp32-freertos origin/esp32-freertos
$ cd port/esp32/
$ ./create_examples.py
$ cd spp_counter
ここで sdkconfig を下記の diff を参考に変更する
$ diff sdkconfig sdkconfig.org
32,33c32,33
< CONFIG_ESPTOOLPY_PORT="/dev/ttyUSB0"
< CONFIG_ESPTOOLPY_BAUD_115200B=y
---
> CONFIG_ESPTOOLPY_PORT="/dev/tty.usbserial-DN02B3PF"
> # CONFIG_ESPTOOLPY_BAUD_115200B is not set
37,40c37,40
< # CONFIG_ESPTOOLPY_BAUD_OTHER is not set
< CONFIG_ESPTOOLPY_BAUD_OTHER_VAL=115200
< CONFIG_ESPTOOLPY_BAUD=115200
< CONFIG_ESPTOOLPY_COMPRESSED=y
---
> CONFIG_ESPTOOLPY_BAUD_OTHER=y
> CONFIG_ESPTOOLPY_BAUD_OTHER_VAL=1000000
> CONFIG_ESPTOOLPY_BAUD=1000000
> # CONFIG_ESPTOOLPY_COMPRESSED is not set
ここで、EPS-WROOM-32をUSB接続し、BOOTボタンを押しながら、リセットボタン(ENボタン)を押す
$ make all
$ make flash
プログラムを書き込んだ後、kermit等のターミナルソフトで/dev/ttyUSB0 を速度 115200 で接続して、もう一度リセットボタンを押す

注意すべきは、ここでデスクトップ右上のBluetoothマークをクリックすると、EPS-WROOM-32 が見えるのだが、GUIではペアリングしない事だ。GUIでペアリングすると、以降の接続とテキスト伝送ができないので、GUIでペアリングしてしまった場合はペアリングを解除する。GUIからは、ESP-WROOM-32のBluetoothのBDアドレスを記録するにとどめる。

次にCUIでペアリングする
$ sudo rfcomm bind 0 XX:XX:XX:XX:XX:XX
$ sudo chnod 666 /dev/rfcomm0
もう一つ kermit を起動する
$ kermit
> set line /dev/rfcomm0
> c
とやると、上手くすると、
BTstack counter 0001
BTstack counter 0002
と言うように、SPP 接続してテキストが送られてくる
残念ながら、上手く行っても2行か3行で、ESP-WROOM-32側のプログラムはコアダンプしてしまう。運が悪ければ、接続する以前にコアダンプする。
コアダンプした様子は、/dev/ttyUSB0に接続したKermitでモニターできる。
諦めずに何度も試すと、上手く行くこともあるだろう。

このように、まだまだ、ESP-WROOM-32の Blutooth Classic の SPP 接続は不完全かつ不安定な状態で実用には程遠い。
しかし、少なくとも ESP-WROOM-32が短時間であっても曲がりなりにも Blutooth Classic 接続ができたことが重要であると思ったので、ここに報告した。
GitHubのbtstackも進歩が速いので、放っておいてもいずれは解決するかもしれないが、この書き込みが何かの役に立って解決の糸口が見つかるようになれば、幸いである。


| | Comments (2) | TrackBack (0)

February 24, 2014

トラ技ARMライタをUbuntuのOpenOCDで使う(プラス パッチ)

E292トランジスタ技術2014年3月号に付いている『トラ技ARMライタ(写真左)』を Ubuntu の OpenOCD で使い、自作のSTM32F4基板(写真右)に接続する事に成功した。
この時、僅かではあるが、OpenOCD のバグを見つけたので、その報告も行う。

私の Ubuntu は、12.04 で、この上で OpenOCD を CMSIS-DAP 対応にビルドする。

$ sudo apt-get install libtool libudev-dev autoconf libusb-dev libusb-1.0-0-dev
$ git clone http://github.com/signal11/hidapi.git
$ cd hidapi/
$ ./bootstrap
$ ./configure
$ make
$ sudo make install
$ sudo ln -s /usr/local/lib/libhidapi-hidraw.so.0 /usr/lib/libhidapi-hidraw.so.0
$ sudo vim.tiny /etc/udev/rules.d/99-hidraw-permissions.rules
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0664", GROUP="plugdev"
を追加。
$ cd ..
$ git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
$ cd openocd/
ハッシュは『6c74255ee2569bf2748ecbbd252e2a91bbce6644』だった。
$ ./bootstrap
$ ./configure --enable-maintainer-mode --enable-cmsis-dap --enable-hidapi-libusb
$ make
$ sudo make install

トラ技ARMライタとSTM32F4とは SWDIO、SWCLK、NRESET、GNDを接続。

/usr/local/share/openocd/scripts/target/stm32f4x.cfgの 38行目の「 jtag_ntrst_delay 100」をコメントアウトし、STM32F4の電源を入れた状態で、下記コマンドで、OpenOCDが起動する。

$ openocd -c "interface cmsis-dap" -f /usr/local/share/openocd/scripts/target/stm32f4x.cfg
Open On-Chip Debugger 0.8.0-dev-00350-g6c74255 (2014-02-19-22:34)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'cmsis-dap'
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: JTAG Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
cortex_m reset_config sysresetreq
Info : CMSIS-DAP: FW Version = 1.0
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 1 nTRST = 0 nRESET = 1
Info : DAP_SWJ Sequence (reset: 50+ '1' followed by 0)
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : IDCODE 0x2ba01477
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

これで、6割方は上手く行く。と言うのも、私が持つ3台の Ubuntu 12.04マシンのうち、1台が下記の様にコアダンプして異常終了するのだ。

$ src/openocd -c "interface cmsis-dap" -f /usr/local/share/openocd/scripts/target/kl25.cfg
Open On-Chip Debugger 0.8.0-dev-00350-g6c74255 (2014-02-24-20:34)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'cmsis-dap'
Segmentation fault (コアダンプ)

このマシンは、、CPUがAMD Athlon64X2 4200+ 2.2GHz、マザーボードがMSI K9N6PGM2-V と言う古い古い構成。ハードウエアの内どの部分が悪いかは不明だが、OpenOCDのソースコードの「openocd/src/jtag/drivers/cmsis_dap_usb.c」の176行目を
if ((0 == cmsis_dap_vid[0]) && wcsstr(cur_dev->product_string, L"CMSIS-DAP")) {
から
if ((0 == cmsis_dap_vid[0]) && (NULL != cur_dev->product_string) && wcsstr(cur_dev->product_string, L"CMSIS-DAP")) {
に変更して、ビルドし直すと、問題が解決する。
上記の行、たぶん、バグだと思うので、正式のOpenOCDに反映してもらうように働きかけようかな・・・とも考えている。

| | Comments (0) | TrackBack (0)

November 17, 2013

デジタルオーディオプレーヤー・リファレンスモデル

E2891ここ1ヶ月ほど、暇を見つけてはコツコツと写真のような『デジタルオーディオプレーヤー・リファレンスモデル』を作っていて、昨日の土曜日にやっと音が鳴るようになった。

なぜ、こんな『デジタルオーディオプレーヤー・リファレンスモデル』と言う大層な名前のオーディオプレーヤーを作ったかと言うと、コミケにも出品したポータブル型のデジタルオーディオプレーヤーのさらなる性能向上を目指したからだ。

『ポータブル型のオーディオプレーヤー』は、その名の通り持ち運びに便利なように小型軽量に作っている。そのため、工作や回路変更が難しい。例えば、音を良くするための実験として、ローパスフィルターの特性周波数を変更するためにコンデンサーを交換するが、何回も繰り返すとプリント基板のパターンが剥がれてしまう。また、そもそもローパスフィルターの次数を変えることなど大幅な回路変更を伴う実験などはできない。

そこで、多少大きくても良いから、色々な実験ができるオーディオプレーヤーを別に作り、そこで実験して得たデータを使って、次回作の『ポータブル型のオーディオプレーヤー』の設計に反映しようと考えた。この実験のためのシステムが『デジタルオーディオプレーヤー・リファレンスモデル』である。

E2892『デジタルオーディオプレーヤー・リファレンスモデル』は左のようなブロック図になっている。『ポータブル型のオーディオプレーヤー』は、電源に単一のバッテリーを使っており、これがノイズの混入などの音質劣化を招いていた。このため、『デジタルオーディオプレーヤー・リファレンスモデル』では、独立電源としている。図のうち 3.3V電源のみがデジタル回路用で、5V電源は DAC のアナログ部専用電源、±9V電源が純粋なアナログ用電源だ。

ローパスフィルターやヘッドホンアンプ部は、それぞれ独立したモジュールとして、今後色々な回路を試せるようにしている。
特に、クロック部も独立したモジュールとしている。今までは、音源用のサンプリング周波数は、CPUである STM32F4の内部のPLLで、CPU駆動用クロックから作っていた。音源用のサンプリング周波数に PLL を使うとジッタを発生するため、音質が劣化すると言われている。今後、専用周波数のTCXOを使い、ジッタのないクロックを使って音質が向上するかの実験も行うつもりだ。

このように、『デジタルオーディオプレーヤー・リファレンスモデル』は、いままでのポータブル型では試せなかった贅沢な回路の実験を行うので、ずっと音は良くなるはずだ。

だが、『デジタルオーディオプレーヤー・リファレンスモデル』、本来、高音質を狙うオーディオでは、やってはいけない事をやっている。
その1つが、回路が過度に分割されていることだ。本当なら、CPU部とクロック部を同じ基板、ローパスフィルターとヘッドホンアンプを同じ基板にすべきだ。その方がモジュール間の結線が短くて、ノイズや音質劣化が少なくて済む。

もう一つは、モジュール間の結線が無駄に長く、コネクタを使って接続していることだ。結線が長いのは、今後、モジュールを交換する時の余裕をみているからで、コネクタを使っているのもモジュール交換するためである。本来、結線は必要最小限の長さにし、コネクタを用いずに直接基板に半田付けする方が音質劣化にならないことは言うまでもない。

このように実験しやすい様にモジュール化したため、多少の問題はあるとは思うが、少なくとも『ポータブル型のオーディオプレーヤー』よりは、良い音になるはずだ。

しかし、『デジタルオーディオプレーヤー・リファレンスモデル』は、昨日やっと最低限の機能である『音楽が演奏できる』ようになったばかりであり、性能的には、まだまだである。クロック部は未だ手付かずで、現状は、サンプル周波数はCPUの内部PLLを使っている。ローパスフィルターは、パッシブのCRフィルターで間に合わせた。ヘッドホンアンプは、CQ出版 の「OPアンプMUSESで作る高音質ヘッドホンアンプ」に掲載されている回路を、そのまま使っている。

特に酷いのは電源部で、 3.3Vだけはレギュレーターで安定化しているが、その他の電源は安定化もせず、ダイオードブリッジの出力にコンデンサーを付けただけだ。

このため、ハム・ノイズが酷い。その上、濁ったような乱れた音に歪んでいる。
早い話が、まだ『ポータブル型のオーディオプレーヤー』より音が悪い。

まあ、一ヶ月くらい、あっちこっち弄ったら、『ポータブル型のオーディオプレーヤー』と同じくらいの音になるだろう。その後は『ポータブル型のオーディオプレーヤー』より良い音になるに違いない。

ある程度、音が良くなったら、試したいことは山ほどある。
・既に言ったように、ジッタの無いクロックだと音は良くなるか?
・音響用の高価なコンデンサーや抵抗だと、本当に音は良くなるか?
・ローパスフィルターの特性周波数や次数は音にどう影響するか?
・OPアンプの種類で、音は違ってくるか?
などなどなどだ。

ある程度、実験が進んだら、また報告する・・


| | Comments (0) | TrackBack (0)

September 13, 2013

MAKERS 読了

E287クリス・アンダーソン著 MAKERS 〜21世紀の産業革命が始まる〜 を読んだ。私が「コミケ報告 〜その3」の中で言いたかった「個人によるモノ作り」と同じような事を分厚い書籍にしたもの。日本語訳は昨年10月に出版されている。

実は、コミケ開催以前に、今回の私のコミケ参加の目的は「コミケにおける個人によるモノ作り」の実情調査だと周囲の人には話しており、それを聞いた一人が「野田さんと同じような考えをまとめた本があるので、是非読むべきだ」と指摘を受けていた。その人から話を聞く分には、確かに私が考えているのと同じような内容の本だと思えた。しかし、コミケにおける実情調査の前に、その本を読むと先入観を持ってしまう可能性があったので、コミケが終り、その結果を「コミケ報告 〜その3」にまとめるまで本を読むのをひかえていた。従って、「コミケ報告 〜その3」の内容は、MAKERSを読む以前の 完全に私のオリジナルの考えである。

さて、MAKERSを読むと、「コミケ報告 その3」で指摘していた「ミッシングリンク」つまり「個人によるモノ作りが日本全体の技術向上に繋がることは疑い無いが、大金を儲ける事も、雇用を生み日本経済を支えるところまでは私には未だ方法が判らない」と言う部分に関して、かなり楽観的な事が書いてあった。しかし、MAKERSは、アメリカ中心の考え方であり、欧米が「個人開発」と言う頭脳中心の発展をする一方、中国を始めとするアジア諸国が「生産」と言う肉体労働(?)と言う格差を利用することを暗に示しているが、アジア諸国の一角である日本の場合、この考えが通用するか甚だ疑問である。
その他、キックスタートなど、初期の資金調達に必要な仕組みなどを詳細に説明してあり、さすがに「ワイヤード」の編集長を務めるだけあって、情報収集と読みやすい文章は、私は足元にも及ばない。

しかし、その一方、私がモノ作りに必要かつ重要だと思う項目が3つ抜けていた。それは、以下の3つだ。
1) 設計
2) インテグレーション
3) 作品としての評価

著者であるクリス・アンダーソンは、この3つの項目が重要であることを見抜いていないのか、それとも「MAKERS」で書いていないだけのかは判らない。彼の生い立ち(職人である祖父の元でモノ作りを学んだ少年時代など)や その後を見ると「設計」と「インテグレーション」を知らずに居るとは思えない。が、一方、「設計」についてはバート・ルタンの実例やローカルモーターズの場合には既存の構造をそのまま使う例を出してはいるものの、「MAKERS」の記述だけでは天才や以前からのプロとしての経験によってのみしか「設計」ができない事になってしまう。
残りの「インテグレーション」と「作品としての評価」については、「MAKERS」に少なくとも私が重要だと思える事について記述は無かった。

さて、私が重要視していると言う「1) 設計」「2) インテグレーション」「3) 作品としての評価」だが、いきなり3つの言葉を並べられても、読者は困惑してしまうだろう。特に私が使う「設計」と一般の人がイメージする「設計」では異なるため、誤解される恐れがある。

一般的に「設計=デザイン」と言う言葉から、どう言った事を連想するだろうか?
「形状・装飾デザイン=スタイリングや装飾を設計・デザインする」事だろうか?
それとも「製造設計=製造に必要な図面や回路図をCADや製図機を用いて描く」事だろうか?

「設計」には、大きく分けて「機能・性能設計」と「形状・装飾デザイン」と「製造設計」の3つが在る。この3つの内、後の2つが一般的にイメージされる「設計」だ。じゃあ、「機能・性能設計」は、ほとんど認知されていない。

ちょっと極端な例で、3つの設計の違いを説明しよう。
「二輪車が存在しない」世界を想像して欲しい。自転車もオートバイも無い世界だ。自動車は全て4つ以上の車輪を持っている。
この世界で、新しい自動車を作ることになった。ネット上でチャットなどを使って、新しい自動車作りについて議論する。
この時、「格好良いデザインにしようよ。流線型にして、先端は尖らせて・・」と言うのが「形状・装飾デザイン」だ。
次に「判った。それじゃ、僕がCADで図面を描くよ。その図面をネットで業者に送ったら、すぐに製造できるような図面をね」と言うのが「製造設計」だ。

とまあ、こんな感じで進むかも知れない。
スケッチや図面と言った画像も入るかも知れないが、基本的にはネット上のテキストのやり取りで設計が進む。

しかし、誰かが「なんで車輪が4つもあるんだ? 2つにできたら良いのに」と言い出したらどうだろう?
「そんなもの倒れるに決まっているだろう。できるわけない」で終わってしまうのが想像できる。

だが、実際には2つの車輪で倒れずに走行できる。
この技術的ギャップを埋めるのが、「機能・性能設計」だ。
「MAKERS」の中では、バート・ルタンが「カナード=先尾翼機」を作ったところにあたる。「MAKERS」では例は示しても、これを新しい「個人的なモノ作り」で具体的にどう行うかの説明はない。
私は、このような「イノベーティブな機能・性能設計」の解決法を全く持っていないわけではないが、まだ試行段階だ。いずれ、もう少しまとまったら、ブログでも書きたい。

次の「インテグレーション」だが、この言葉自体初めて聞く人も多いかもしれない。「外部業者で作ったものを組み合わせて構築し、最終的に動くものを創り上げる事」だ。
実は、「インテグレーション」は、人工衛星を作る時の用語で、一般的な日本語で言うと「統合」とか「組立・整合性試験」とか、そう云うイメージのものだが、あまり適当ではないので、ここでは「インテグレーション」を使わせてもらう。
ネット経由で海外の業者に発注したモノが製造され送られてきたものが、設計通りにできていても、それらを組み合わせてちゃんと動くと思ったら大間違いだ。
多くの場合、「設計図通り」に動かない。
むしろ、全く新しいモノを作る場合、一発目から「設計図通りに作ったら、動作する」ような設計図を描ける人は、まずいない。

製造されたものを組み合わせる。この時、単体での試験を行い、想定通りの機能・性能を満足していることを確認しては、次のモノと組み合わせていく。個々の機器が単体で機能性能を満足しても組み合わせると動作しないことが極めて多い。このような場合に、それぞれの問題を、可能ならその場で解決して組み上げていき、最終的に全て組み合わせて動くようにする、これが「インテグレーション」だ。

「インテグレーション」の過程で出てくる不具合は、その場で対処療法的に対処される一方、製造の元になった設計図等に反映し、次のサイクルでの再発を防ぐ。このように一通り機能するようにしたのち、再び、設計に戻り、改良された設計で再製造・インテグレーションを繰り返す。
このようなサイクルを何回か繰り返したのち、「設計図通りに製造したら機能するモノ」ができる。私のオーディオプレーヤでも、プリント基板を起こした時点から3サイクル、その前のユニバーサル基板での試作を加えると4サイクル回している。データロガーの場合は、それぞれ、2サイクル・3サイクルだ。
「インテグレーション」の言葉は知らなくても、モノ作りをするものなら、誰もが行なっている極めて重要な工程である。

「設計」と「インテグレーション」は表裏一体のところがある。
私の技術者としての経験から言うと「インテグレーション」を先に覚え、その後「設計」を知った。これが一般的なのかは判らないが、いずれにしろ、この2つがモノ作りに必須であることは間違いない。

最後の「作品としての評価」は、少し異質だ。
「作品としての評価」は、私の「コミケ報告 その3」のブログで、「機能作品してのアート性」として強調していた部分である。要は、「私の作ったオーディオプレーヤのアート性は実際に聞いてみなければ判らない」と言うことだ。

書籍「MAKERS」の中で、個人的なモノ作りをする人が、多くの人に理解してもらうには、ネット上でのプレゼンテーションすなわち、テキストや画像、動画を使って如何にアピールするかが重要であると言う事が、直接的ではないにせよ、間接的に書いてある。しかし、これは投資家や経営者、評論家サイドから見た技術者への要求であり、技術者から見れば無理難題だ。

私のオーディオプレーヤを例にさせてもらうと、どんなに言葉で説明しても、その音の本当の伝わらない。動画にしても同じだ。私のオーディオプレーヤの音を録音して、それをYoutubeにアップしても、その動画から聞こえる音は、あなたの持っているパソコンに付いているスピーカーなりイヤホンの音であり、私のオーディオプレーヤの音ではない。

ネットでアピールするために、テキストや写真、動画にすることは、結局大なり小なり偽りが含まれる。偽りのアピールは偽りの連鎖を産んで、本質から離れていく。個人的なモノ作りをする人の中には、本質から離れた偽りのアピールに嫌気がさし、作ったものの本質を訴えたいと思っている人が少数でも確実にいる。

また、モノ作りが得意な人は、必ずしもアピール上手ではない。いやむしろアピールが苦手な人、口下手な人が多いのではないか?
一人の人間が持つ能力には限界がある。本当にモノ作りができる人よりアピールの上手い人が作ったモノの方が受け入れられやすい。
「ろくにモノ作りもできないのに、口ばかり上手い奴ばかりがなんで受けるんだ?」と思った人も多いだろう。
大企業によるモノ作りの場合、モノを作る技術者とは別にアピール上手な人を専門においていた。それが「営業」だったり「広報」だったりする。モノ作り専門の技術者は、本質的に良いものを作るのではなく、「営業」や「広報」がアピールしやすいものを優先的に作らされてきた。それに嫌気がさして「個人的なモノ作り」をしたいと思った人もいるはずだ。
にもかかわらず、「個人的なモノ作り」もまたネット上での「アピール」が優先されるとなると、本末転倒である。

コミケのように、多くの人に「実際に音を聞いてもらう」ことは貴重な機会だ。これは、オーディオプレーヤに限らず、機能するモノを作るのなら、共通して同じで、どうやっても、テキストや写真、動画で伝わらない「機能」がある。
Makeフェアーも、コミケと同じように実際に「機能」を見てもらう良い機会となり得る。しかし、「MAKERS」でのMakeフェアーの扱いが思いの外少なかったので、気になった。

また、長文になってしまった。
「イノベーティブな機能・性能設計」や「インテグレーション」「評価」については、別の機会に詳しく書きたいと思う。

| | Comments (0) | TrackBack (0)

September 05, 2013

コミケ報告 その4

E286コミケの報告は前回で終わりにしようと思ったのだが、急遽追加。
ブログで、コミケ報告をして、決算赤字で売れ残りがあると判ると、途端に通販希望の方々から連絡が。結局何枚か売れて、その結果、なんと赤字が黒字に反転した。

コミケの分と合わせての決算は以下の通り

 コミケでの売上
  オーディオプレーヤ半完成品 9000 x 3 (準備したのは8枚)
  オーディオプレーヤ生基板  1000 x 19 (準備したのは20枚)
  データロガー半完成品   5000 x 5 (準備したのは10枚)
  データロガー生基板    1000 x 4 (準備したのは20枚)
  合計 75,000円

 コミケ後の売上
  オーディオプレーヤ半完成品 9000 x 1
  データロガー半完成品   5000 x 3
  データロガー半完成品   2500 x 1 (私が買ったので、実費のみ)
  データロガー生基板    1000 x 1
  合計 27,500円


 支出
  オーディオプレーヤ半完成品 4500 x 10 (うち展示品2枚)
  オーディオプレーヤ生基板  230 x 20
  データロガー半完成品   2500 x 10
  データロガー生基板    230 x 20
  コミケ参加費       5000円
  印刷(ちらしと説明書のコピー)
   6x40x10
   7x20x10
   40x10
  合計 88,400円

と言う訳で、14,100円の黒字。

実は、データロガー半完成品については、通販の申し込みがある前に、少しでも赤字解消にと、私とサークル代表の水城さんが、各1枚ずつもらった。赤字分を負担している水城さんは無料で、私は関係者と言う事で実費で買ったわけ。その後、通販の申し込みでデータロガー半完成品は完売となってしまった。

他は、少しずつ余っているけど、とりあえず、これ以上の通販はない予定。
来年の夏コミには、また、更に改良したものを持ち込むつもりだが、それまでお待ちを。

| | Comments (1) | TrackBack (0)

August 27, 2013

コミケ報告 その3

E285前回・前々回に続いて、8月12日のコミケの報告の3回目。今日はちょいと固い話。おそらく、これでコミケの報告は最後になる。

コミケは、同人漫画のみならず、電子工作のようなハードウエアのオリジナル作品を発表する場としても有効だと言うのは、前々回書いた通りだ。これは、コミケに限らず、Makeフェアーやワンフェスにも同じ事が言える。また、コミケは電子工作だけでなく、機械加工などのハードウエアの発表するのにも有効だろう。

個人が自分で考えたオリジナル作品を発表する。これは、その分野の活性化には不可欠なものであり、コミケは漫画やアニメの分野で何十年も前から、その役目を果たしてきた。その結果、若い才能が芽を開き、クールジャパンと呼ばれる日本オリジナルの文化を生んだのは、私があえて言うまでもない。
コンピュータ・プログラムのようなソフトウエアの世界では、パブリックドメインやオープンソースと言った仕組みが、新しい文化を生む土壌になっているが、残念ながら、日本での認知度は海外に比べて低く、その結果として、海外よりも日本のソフトウエア開発力で後塵を拝する結果となっている。これは、スマホの主流の一つであるAndroidの例でも明らかだろう。

しかし、電子工作や機械加工によって作られる技術的なハードウエア作品の発表の場が少なく、それが日本の技術力低下に繋がっていると、少なくとも私は考えている。この場合「ハードウエア作品」は、フィギュアやミニチュア模型のように外観形状デザインが主で観賞用の動かないものではなく、なんらかの技術的仕組みで機能する作品を指す。フィギュアやミニチュア模型であれば、既にワンフェス等での発表が定着しており、それがクールジャパンの一つの要素になっている。

「機能するオリジナル作品」は、今まで大企業の大量生産で供給されていた。30年前のウォークマンが、その例だ。しかし、少品種大量生産は利潤が大きい一方リスクも大きく、ただでさえ数少ない『新しい作品』の開発に、飛躍したオリジナリティを入れることが難しくなっている。このため、特に日本では、新しい作品を作ると言う『モノ作り』の技術が低下している。日本全体の技術、特に『新しい作品』を飛躍的なオリジナリィを持って作る技術の向上のためには、個人個人が『新しい作品』を発表する機会を増やす事が必要だ。

一方、従来は個人が「機能するオリジナル作品」を発表するのは難しく、その原因は、大きく次の2つだと考える。
1) 開発・製造に物質的コストがかかる事。
2) 機能の再現性が難しい事。それに伴い改変・再配布が難しいこと。

ハードウエアを開発し作り、配布するために生産するためには、部品購入などのコストが必要なのは当然だろう。しかし、コンピュータ・プログラムの場合、当人の人的コストを度外視すれば、コンピュータの電気代やネット等の使用料はともかく、物質的なコストはかからない。漫画であれば、製造料としての印刷代が必要であるが、ハードウエアに比べれば安い。
また、コンピュータ・プログラムであれば、ダウンロードしたアプリケーションが動作する率は高く、さらにソースコードが公開されていれば、それを改変・再配布することは容易だ。漫画の場合、コピーを取れば複製するよとは容易だし、二次創作として改変・再配布することもできる(これはあくまで技術的に可能と言う意味。もちろん、著作権などの倫理的な問題は別にある)

これに対して、ハードウエアの場合、回路図通りに配線したとしても、ちょっとしたハンダ付けのミス等で動作しないことは良くある。それどころか、例えミスなく配線しても、私の作ったオーディオプレーヤの音を再現できる保証はない。それほどにアナログ系の配線は微妙なのである。
しかしながら、電子回路は、ハードウエアの中では再現性がある方で、機械加工品は更に難しい。特に燃焼を伴う機械すなわち内燃機関など、例え設計図通りに作っても全く動かないと言う可能性が高い。
単なる再現性ですら、こうなので、ましてや改良し再配布することなど更に難しいと言わざるを得ない。

そもそも、技術的な工作品において、オリジナル性を主張するほどの「作品性」を持たせる事などできるのかと言う点で疑問を持たれる方も居るとは思う。しかし、この疑問に対する私の答えは明確で「芸術作品と同じく、技術作品においても作者のオリジナル性を反映する作品性を持たせる事は可能だ」と言うことだ。
言い換えれば「技術製品において、機能にアート性を持たせる事」とも言える。これが、40年に渡りオリジナル作品を作り続けてきた私の到達した思想だ。

具体的に、私が今回のコミケで披露したオーディオプレーヤにおいて「機能作品してのアート性」が何であるかは、言葉で言い表すのは極めて難しい。しかし、オリジナルのオーディオプレーヤを作り続けて1年強、設計的に3世代を経て、私なりの『音』をオーディオプレーヤに入れる事に成功しつつある。それが未だ理想的なものでは無いにせよだ。

そして、それは言葉で説明することはできなくても、コミケの会場で試聴してもらった多くの方々には通じた。ほとんどの人は「イイ音がする」と言う反応で、それは私のオーディオプレーヤのアート性の理解の入り口だと思う。しかし、わずかに少数ながら、私がオーディオプレーヤに入れたアート性の存在そのものを理解した人も居るには居た。それが、その人が気に入るか否かは別にして、私が作り出した『音』のオジリナル性とアート性の存在を認める事に他ならない。

繰り返しになるが、私のオーディオプレーヤに込めた『音』のアート性は、言葉で言い表すことは困難で、やはり『音』自体を聞いてもらう他に良い方法は無い。実際に音を聞いてもらうと言う機会と言う意味で、やはりコミケはは、非常に良い舞台である。

ただし、前々回のブログで既に述べたようにオーディオプレーヤは、イノベーションと言う意味では半人前だ。イノベーションは、技術的飛躍だけではなく、新たな価値観の創造と言う意味を持つ。携帯型オーディオプレーヤは、既に30年以上前にSONYによってウォークマンと言う形で世に出され、『携帯性』と『音の良さ』と言う評価基準も定まっている。要は私のオーディオプレーヤもハイレゾ対応と言う新しい技術の導入はあっても、所詮既存の土俵で戦っているに過ぎない。

今回のコミケに出展した、もう一方のデータロガーは、私自身のオリジナルであり、そもそも『データロガー』と言う名称の枠組みを超えた可能性を秘めている。しかしながら、4月からの開発と短期間であり、評価も定まっておらず、他人にその『作品性』を訴える程、熟成していない。そのため、売上もオーディオプレーヤの半分となった。このデータロガーのように、その価値観・評価基準すらもオリジナルな作品こそ、真の意味での『オリジナル』と言えよう。今後は、こう言った真のオリジナル作品を作り、発表することに、より力を入れたい。

話がそれたが、主題は、「機能するオリジナル作品」におけるコミケの役割・有効性である。ハードウエアを伴う作品の開発生産には、物質的コストが伴う事が問題であるのは既に述べた。しかし、前々回のブログでも書いたように、近年、オリジナル作品の少量生産に必要なコストが激減しており、コミケなどを通じて、数十個販売することができれば、損をしない程度になっている。今回は格安になったプリント基板製作がキーになったが、いずれは、SOC(システムオンチップ)も格安で作れるようになり、それがコミケで売られるようになるだろう。

また、「機能作品してのアート性」を理解してもらうためには、実際に見て聞いて触ってもらうと言う貴重な機会をコミケは持つ。
こうした「オリジナル作品」が人から人へ渡り、進化し続ける事が、本当の意味の日本の技術力の向上に繋がると、私は信じている。

もう一つの「再現性・改変・再配布が難しい」ことに対する答えは未だ無い。

今回、我々のサークルでは残念ながら赤字であったが、後に続くものに、せめて損をしないためのノウハウとして、箇条書きであるが、私の気付いた点を羅列しておく。
・「ハイレゾ」と言った「売り言葉」を用意し、できれば大きく書く。
・「ハイレゾ」は時流に乗った
・ちらしは多いほうが良い
・シリーズ物にしたり、レギュラーにした方が売れる。
・試聴は高いイヤホンではなく、5000円以下のイヤホンの方が良い。
 (高いイヤホンだと、良い音はプレーヤのせいではなくイヤホンのためと思われる)
・午前の方が売れる、除く10:00〜10:30
・AC100Vは無いので、バッテリーを多めに準備
・携帯電波特にスマホは混雑のため、なかなか接続できない
・太文字マジックやホチキスは必須。
・実装基板はオペアンプを付けずにいたが、完成品にすべきだった。
・逆にQFPのみ付けると言うった組み合わせもありか?
・汗が動作中の基板に落ちて、オーディオ基板が1枚アウト
 真夏のコミケならではのアクシデント
・しかし一方試聴としては、むき出し基板の方が迫力がある。
 防湿コーティングが必要?
 それとも透明ケースか?
 ともかく、イソプロピルアルコールで洗浄したら直った。

以上が、どこまで役に立つかは判らないが、今後、コミケにオリジナル作品を作って参加する方は是非参考にして、少しでも赤字を少なく、できれば黒字を出して、小遣い銭でも稼ぐようにして欲しい。そうすれば、ただでさえ家族から「また無駄使いして、変なものを作って」と非難されることも減り、新たなオリジナル作品の開発に勤しめる事うけ合いである。

こうやって、多くの人がオリジナル作品を作り発表し続ける事が、日本全体の技術向上に繋がることは疑い無い。しかし、コミケ程度では、赤字を出さずに小銭を稼ぐ事はできても、大金を儲ける事も、雇用を生み、日本経済を支えるところまで繋げる事は、私には未だ方法が判らない。誰か、このミッシングリンクを見つけて、儲かる方法を考えて欲しい。

他にやることもあるので、とりあえず今年末の冬コミは止めて、次回は来年の夏コミに参加予定する予定だ。来年の夏コミまでには、オーディオプレーヤは更に磨きをかけ、データロガーは『作品』として熟成をし、それら以外にも幾つか新しい作品を持ち込めるようにしたい。

| | Comments (1) | TrackBack (0)

August 25, 2013

コミケ報告 その2

E284前回に続いて、8月12日のコミケの報告。今日は軽い話。

12日の朝8時、国際展示場正門駅改札で、当サークル代表の水城さんと落ち合う。直ぐに手伝ってくれることになったモりやまさんに電話。駅改札は余りにも人が多いので、もう少し空いている場所で落ち合う事にする。
モりやまさんは、直前に Twitter で手伝いを募集した時に手を上げてくれた。他にも手伝いを表明してくれた人が居たのだが、旧知の仲と言うことで、モりやまさんに頼んだ。他に表明してくれた方々、どうも有難うございます。

ビックサイト前のペデストリアンデッキ上の広場でモりやまさんと会って、サークル入場なので、あっと言う間に会場入り。一般入場だったら、2時間並ぶと言う噂も聞いたが、後で、一般で入った人に聞いたら、そんな混雑は無かったらしい。

すぐに、我がサークル「航天機構」が陣取る 東 "へ"ブロック12bへ行く。私はコミケ自体に来たことが無いし、水城さんも一般として来たことがあるだけ。でも、助っ人の モりやまさんは何度もサークル参加しているそうで慣れていて助かった。

会場は、本来モーターショーなどを行う だだっ広いところ。毎年、お盆と年末の2回、3日間ずつコミケが行われる。
その広くて屋根が高いところに、数多くの長テーブルが、四角く並べられている。それぞれの四角く並べられた長テーブルに「ハ」だとか「ペ」だとか「ヘ」と言うブロック名が付いている。
それで、その長テーブルの一つの更に半分が、一つのサークルに割り当てられる。サークル毎に長テーブルの上にパイプ椅子が2つ畳んだ状態で置いてあった。サークルは3名までなのだが、椅子は2つ。つまり一人は立っていないといけない。
次に参加することがあったら、キャンプ用の椅子か何か持ってくるようにしよう。

さっさと、テーブルの上に試聴用の基板などを並べて、開場を待つ。チェックの人が来る。同人誌なら、一冊ずつ、コミケ本部に納めなければならない。だが、我々のように電子回路のような『モノ』は納めても保管場所も無いらしく、納めたのは電子回路と一緒に配布する説明書だけで済んだ。

開場が近付くと、会場のあちこちに列ができ始める。人気サークルのグッズを買うための列だ。本来、一般客は、10時の開場まで入れない。しかし、サークル参加であれば、もっと前から入場できる。売り切れしやすい人気サークルのグッズを買うためにサークルメンバーとして入場した人達が列を作っているのである。このためだけにサークルメンバーとして参加する人も居るらしい。
列ができるのと合わせるように、警備隊も現れる。警備隊は、男も女も居るが、別にお揃いのユニホームがあるわけではけど、何となく警備員と見えるようなファッションだ。これに、見るからにフニャフニャの警棒を持っている。発泡ウレタン出できているのだろう、叩かれても痛くなさそうだ。このフニャフニャの警棒で警備できるとは、何とも平和なものだ。

さて、いよいよ 10時の開場だ。それまで、閉めていたシャッターも開かれる。
拍手と共に、一般客が入ってくる。大勢が列に入ってくるだが、混乱は無い。走る人も列を乱す人も居ない。人数のわりには、驚くほど静かだ。

いくら静かと言っても人数が人数だ。今回のコミケは3日間で59万人と史上最高の人出だったらしい。12日は平日だったこともあり、3日間の中では人が少ない方とは言え、相当な人が集まっている。
開け放たれたシャッターから真夏の熱気が入ってくるのと共に、人出の熱気で会場の温度が一気に上がる。

大量に入ってきた一般客は、人気サークルのグッズを買うために、先ほどからできていた列に並ぶ。沢山の人が、我々のサークルの目の前を通り過ぎたが、立ち止まる人は誰も居ない。10時30分になり、人気サークルのグッズが売り切れた頃に初めて、我々のサークルに人が来るようになった・・と言うのは前回書いた通り。

コミケ自体は、8月10日(土) 11日(日) 12日(月)の3日間続くが、今回我々が参加したのは、12日(月)の一日だけだ。3日間の期間中、唯一平日なので入場者が最も少ない。
1日毎にテーマが決められていて、12日(月)のメインテーマは、同人ソフトだったらしい。もちろん、国際展示場の広大な会場が、全て同一のテーマで統一されているわけではなく、種々雑多なテーマも、また併せられている。我々の属する電子工作系テーマも、その一つだ。ちなみに、最も人気の高い漫画・アニメ系のテーマは11日(日)だったらしい。

電子工作系と言っても、さらに細分化し、ゲームソフト、OS等のソフト、オーディオ系電子工作、その他の純粋な電子工作となるようで、我々の居た"ヘ"ブロックは、大半がオーディオ系電子工作だった。他の電子工作系サークルも近くにあるので、見に来る客は、元々電子工作好きが多い。

しばらくすると、コスプレしている人が増えてきた。我々のサークルのある場所は、コミケ会場の中に幾つか点在するコスプレ広場へ行く通り道になっているらしい。

「規制緩和されて、露出度が増えていますよ。前は、ヘソを出してはいけなかったのが、今回はヘソ出しOKですから」
コスプレ広場へ行くコスプレイヤーは、電子工作には興味がないから、我々のサークルに立ち寄ることもない・・・・と思ったら、そうではない。コスプレした人も何人も立ち寄って、オーディオプレーヤの試聴とかしていく。

「データロガーって、何ができるんですか?」と、小動物の耳が生えたコスプレをした女の子が色々聞いてきた。聞けば、某大学の鳥人間コンテスト・サークルに所属していて、琵琶湖で飛ぶ時のナビゲーションの方法を探しているんだそうだ。
売り物にしていたデータロガーは、GPSなどの受信機能はなかったので、残念。
(別に、そう云う航法用のデータロガーも作っているんだよ、それも超音速でも使える奴を・・・って言えば良かったかな?)
終始、その女の子は人力飛行機とナビゲーションの話をしていたのだが、後から別の人に聞くと、その娘のコスプレは、空を飛ぶ飛行機(それも零戦)に擬人化された少女のアニメ・キャラクターだったらしい。
骨の髄まで、空を飛ぶのが好きなんだな・・・

人が増えてくるに従い、会場の温度が上昇する。会場には冷房が無いわけではなく、実際、10時の開場までは涼しかった。
しかし、開場と共に外に通じるシャッターが開かれたままになり、外の暑い空気が入ってくるだけではなく、入場して来る人の熱気で、会場の温度は上昇し続ける。

「人数の多かった昨日は、もっと暑かったですよ。天井が見えなくなるくらいに霧というか雲が会場の上層にできました。」と、昨日もコミケに来ていたモりやまさん。
まあ、11日は、東京の最低気温が30度を越えたと言う超猛暑日だったからなあ。

暑いと、のどが乾く、熱中症になったらイカンので、水を補給する。家からペットボトルと水筒を持って行ったのだが、そんなものでは足りない。会場にある自動販売機でスポーツドリンクを買うのだが、補給したばかりのようで生暖かい。

サークルメンバーは3名なのに、パイプ椅子は2つしか無いので、誰か一人は立っていなければならない。私以外の二人は肥満気味で運動不足のようなので、可能な限り私が立っていた。とは言え、直接客と話をする係になった時は座っていたけど。

12時頃になると、コンビニで買っていったサンドイッチを食べる。10時を過ぎると会場からの出入りは自由になるので、外に昼食を食べに行っても良いのだが、時間がもったいない。

閉会の16時まではあっという間で、時間通りに片付けて帰路に付く。
我々のサークルがあった東館から出ると、ゆりかもめ線の国際展示場正門駅より一つ東の有明駅の方が近いので、そこから新橋駅に向けて乗る。意外と空いていて座ることができた。
国際展示場正門駅から乗ってくる乗客も、そんなに多くない。ラッシュ時の山手線の方が遥かに多い。コミケ終了時は混雑して、改札は入場制限になるほどだって噂で聞いたけど、そんなに酷くはない。

新橋の焼肉屋に3人で入る。私以外の2人は医者に酒を禁止さているので、ビールの飲むのは私だけ。私だって、そんなに飲めないのに。

焼肉を食べながら反省会。電卓叩いて「赤字だったね」とか、「売り子に女の子入れても売り上げには関係ないね」とか。

焼肉屋を出たら、土砂降りになっていた。
傘を持っていない。
次回参加する時は、折畳み傘を忘れないようにしよう。

| | Comments (0) | TrackBack (0)

August 23, 2013

コミケ報告

E2838月12日(月)にコミケにサークル参加した。ちょっと遅くなったが、その報告だ。実は私は今までコミケに行ったことが無かった。サークルのみならず一般客としてもだ。
今回は、初めてのコミケなのだが、いきなりサークル参加して、自分の作ったものを売ることになった。コミケで売ると言っても、漫画ではない。電子工作だ。
コミケで販売したのは、基本的には2種。一つ目は「ハイレゾ高音質携帯オーディオプレーヤ」、もう一つは「液晶付きデータロガー」だ。それぞれ、「部品を全く載せていない生基板」と「主にハンダ付けが難しい表面実装部品だけ付けた半完成品」の2パターンずつ、計4種を売った。

コミケは本来、同人漫画を売るところなのだが、オリジナルの電子工作も売ると知ったのは、去年の夏だ。コミケで、オリジナルのヘッドホン・アンプの基板を売っていると知って、それなら当時私が作っていたオーディオプレーヤも売れるんじゃないかと思った。
昨年末のコミケはサークル参加申請が間に合わず、参加していない。が、この時に一般客として行った水城さん(当コミケ・サークルの代表)が、オーディオプレーヤを持参した。コミケ会場に居たヘッドホン・アンプを扱っているサークルの人に音を聞いてもらったところ、「そんなに音は良くない」との反応を受けた。
それで奮起して、二人でオーディオプレーヤを改良し、今回のコミケに向け音質を大幅に良くした。
データロガーの方は、今年の4月に作り始めたばかりのもの。これは私自身が電子工作をするときに、ロジアナやオシロスコープよりも遅くて良いから、数時間から数十時間連続でデータを記録するロガーが欲しいと思い作ったものだ。通常、ロジアナやオシロスコープのサンプリング周波数は遅くても数十MHzだ。それに対して、私のデータロガーのサンプリング周波数は10kHzしかない。しかし、単三電池2本で数十時間のデータをmicroSDに記録し続けることができる。

オーディオプレーヤもデータロガーも、主に私が回路設計やプログラミングを行い、水城さんがプリント基板のパターンを作っている。プリント基板は、無料のCADでパターンを作り、それをインターネットで送れば、中国の工場から10枚2300円で送ってくれるというモノ。これ、15年前だったら、4〜50万円かかって当たり前だった。できた基板に主に水城さんがハンダ付けし、私が回路テストを行う・・と言うのをオーディオプレーヤの場合は3回、データロガーの場合は2回繰り返した。

さて、コミケ当日、8時に会場入りし、準備をして、10時の開場を待った。周りは、ほとんどが電子工作関係。おなじような種類のサークルを集めているらしい。
10時になると一般客が流れるように入ってくる。意外と整然としていて静か。今回のコミケは3日間で59万人が来場するという空前の人出だったらしいが、目立った混乱はない。

開場と当時に入ってくる大量の客は、お目当てのサークルへと急ぐ。人気サークルのグッズは早く行かないと売り切れるからだ。このため、開場から30分は全く客が来なかった。10時30分になり、人気のグッズが売り切れた頃になると、客がやってくるようになった。

まずは、展示品のオーディオプレーヤを試聴してもらう。
「音がイイね」と言う反応が、ほとんどだった。昨年末のコミケの反応とはエラい違い。改良したかいがあったというものだ。すかさず
「96kHz 24bitのハイレゾ音源対応の完全自作オーディオプレーヤです。」と言うと
「え、ハイレゾのオーディオプレーヤが自作できるんだ」と好感触。
全く誰にも見向きもされない可能性すらあったのだが、意外と受け入れられた。

こうして、12時頃まで、それなりに売れて、この分だと売り切れるかな・・と甘い期待も。しかし、午後になってから売れ方が鈍化。多少は売れたけど、売り切れって事は無かった。

と訳で、多少は売れたが、儲かってはいない。結果は残念ながら赤字だった。

内訳は以下の通り。
 売上
  オーディオプレーヤ半完成品 9000 x 3 (準備したのは8枚)
  オーディオプレーヤ生基板  1000 x 19 (準備したのは20枚)
  データロガー半完成品   5000 x 5 (準備したのは10枚)
  データロガー生基板    1000 x 4 (準備したのは20枚)
  合計 75,000円

 支出
  オーディオプレーヤ半完成品 4500 x 10 (うち展示品2枚)
  オーディオプレーヤ生基板  230 x 20
  データロガー半完成品   2500 x 10
  データロガー生基板    230 x 20
  コミケ参加費       5000円
  印刷(ちらしと説明書のコピー)
   6x40x10
   7x20x10
   40x10
  合計 88,400円

となり、差し引き13,400円の赤字と言うわけだ。あと、オーディオプレーヤ半完成品とデータロガー半完成品が1枚ずつ売れれば、とんとんだったんだけどねえ。それとも半完成品を少なくしておけば良かったか。


さて、なんで私がコミケに参加して、わざわざ決算報告をブログで公開しているかと言うと、「オリジナルの作品を、損しないで開発し世に出すことができるか」と言うことを試したかったからだ。

例えば、オーディオプレーヤは、ウォークマンや iPod のようなものだ。だが、大手のSONYもAPPLEも、まだハイレゾ音源対応の携帯オーディオプレーヤを作っていない現在に完全自作で作ってしまおうと言うモノだ。まあ、大手じゃなくてマイナーメーカーなら、ハイレゾ対応のオーディオプレーヤもあるようだが、とても高価なので、完全自作の方が安いので存在意味はそれなりにある。

今から30年前に携帯オーディオプレーヤつまりウォークマンを開発しようものなら、開発だけで何百万だか何千万だかの金額が必要だっただろう。生産のための設備投資は億を軽く超えるんじゃないかな? この投資を取り返すためには、何万個とか何十万個売れないとダメだった。もし、売れなきゃ開発費と生産設備への投資の分だけ赤字になる。とてもじゃないが、個人でリスクを負える金額じゃない。

ところが、昨今では、既に書いたようにプリント基板が15年前の100分の1くらいのコストで作れるようになった。電子部品も小型軽量で高性能なものが秋葉原やネット通販で買える。プログラミングも全てフリーのツールで可能だ。これらは電子工作だけではない。今回は使わなかったが、話題の3Dプリンタを使えば、CADで作ったモデルを実際に格安で作ってくれる業者もある。

この結果、オーディオプレーヤは正確には計算していないが、4万円くらいで開発できた。
今回は赤字だったが、例えば、オーディオプレーヤとデータロガーの半完成品を、完成品にして3枚ずつ程度にしていれば、赤字解消になるどころか、4万円ほどの黒字になる計算になる。つまりオーディオプレーヤの開発費も得ることができたわけだ。

要は何が言いたいかと言えば、「30年前は、オリジナルの電子機器を開発するには、数万〜数十万の人に売れる必要があり、そうでなければ、数億円を超えるリスクを負う」だったのが、「現在では、30人程度の人に売れれば損しない。仮に丸損しても数万円」って事になる。

要は、技術開発の「損益分岐点は、販売数が数万だったのが、数十個になった」と言うことと「開発に伴うリスクが極端に減った」と言う事だ。

何万と言う人に受け入れられなければ、数億円と言うリスクと伴うのであれば、個人がオリジナルなものを作るのは極めて難しい。
しかし、数十人に受け入れられれば損そせず、万一まるでダメでも数万円の損で済むなら、個人が自由な発想でオリジナルなものを作るのも容易になるだろう。

正直に言うと、イノベーションと言う側面で見た場合、オーディオプレーヤは半人前だ。イノベーションとは技術的な進歩だけじゃなくて、新しい価値観の創造もある。オーディオプレーヤは、言ってしまえば、ウォークマンやiPodの価値観を借りただけだ。それをハイレゾ対応に改良しただけに過ぎない。

しかし、データロガーは、価値観も含めて私のオリジナルである。この世になく、私自身が欲しかったものを具現化して、コミケと言う場所で世に問うたものである。でも、売上は、オーディオプレーヤの半分。なかなか、価値観の創造は難しい。
まあ、ろくな事前の宣伝なしで、半完成品と生基板あわせて9枚も売れたのだから、ある意味成功だったのだが。

さて、ここまででも、十分に長文になってしまった。
まだまだ、コミケの情報で書くことは残っているのだが、また、別の機会にするかなあ。

| | Comments (3) | TrackBack (0)

より以前の記事一覧