2012年1月10日火曜日

Jota でシンタックスハイライト

新年明けましておめでとうございます!

本年もどうぞよろしくお願いいたします。

例年、仕事に追われてどうしようもない感じなのですが、
今年こそはなにか新しいモノを!という意気込みでやっていきたいと思っています。
おつきあいのほど、よろしくお願いいたします。



閑話休題。

え~、いきなり趣味話から失礼(笑)
新年早々、Android用のJota Text Editorが、バージョンアップしました。
β版ながら今回のアップデートで、キーワードハイライティングに対応しています。

せっかくキーボード付きのアンドロイド端末、LifetouchNOTEをもってるんですが、
肝心のテキストエディタで、キーワードの色別ができるソフトがなくて、
なかなかプログラムにつかう!というところには心がうごかなかったんですが
やっとこれでつかえそうです。

特に、Android単体でプログラミング&実行ができる
luaridaだと、キーワードがハイライトされるだけで、結構見通しが
ちがうものです。

というわけで、暫定的にluarida用の定義ファイルをつくってみました。

Luarida用キーワード定義ファイル(lua.conf)

うまくいくようなら、標準添付分にいれてもらえるように申請してみようと
おもいます。

やりかたは簡単で、
SDカードの
.jota/keyword/user
のなかにこのファイルをいれるだけです。

とりあえず、これでテストしています。


というわけで今年もどうぞよろしくお願いいたします!!


2011年12月28日水曜日

年末のご挨拶&自宅でできるリフロー

Twitter経由でなにげにおもしろいビデオ、みせてもらいました(笑)
なるほど。ホットプレートをつかうんですね。
前に、仕事の関連の人がやってましたが、温度管理が難しいと
のたまっていました。
そうか、
230->180->230
の変更でうまくいくのね。
案外こういうノウハウが大事だったりするので、メモメモ(^^
さすがスイッチサイエンス。



閑話休題。


今年もはやもう数日を残すのみとなりました。
10月から始めたこのブログも何とか起動に乗りつつあるようです。

MDRのHPやひとりごとページからきてくれているのが半分、
それ以外からの検索でこられる人が半分、というところでしょうか。

当初はHPの更新の面倒さからの解放を意図して始めたのですが
この気楽さはなんなんでしょうねぇ、ほぼ隔週での更新ができました。

単純な仕事話題だけでなく、サークラインLEDなど、かなり個人的な
内容にもかなりのヒットがあるようで、なんとなくおもしろいなぁ、と
おもいました。

Twitter(@tetnoguchi)facebookでネットのつながりが増え、
GENETなどのリアルつながりがこれに加わりつつあり、
来年はこれらを生かした形でなにかできればな~と思ってたりします。


というわけで、来年もがんばって更新していきたいとおもいます。

それでは、みなさん、良いお年をお迎えください。


2011年12月13日火曜日

ZigBeeの能力試験をやってみた

某研究会でおこなっているZigBeeのボード設計周りも大詰めなので
懸案だった接続テストと能力測定を行いました。
場所は京都五条七本松のASTEM(京都高度技術研究所)です。

省エネ動作そのものは特に問題となるほどおおきくないので
DigiのXBeeとXBeeProでZigBeeモードのコーディネータデバイスとルータデバイス
としてテストを行いました。
製品性能の取得を目的としていないので、実運用に近いテストという観点から
コーディネータからコマンド送信し、ルータデバイスからトークバックが得られるかどうかと
その遅延性がどの程度か、を確認していくという簡易な方法をとりました。

屋内試験では事務所内でいろいろやってたんですが、同一フロアなら
XBee/XBeeProとも、特に問題にならないほどの安定性が得られました。
そういうもんなんですかね。

XBeeとXBeeProでは利用できる出力がかなりちがうので、どうようの運転が
できたのはここまでで、XBeeは階がかわるととたんに通信が滞るようになります。
このレベルになると、電源ONからの再接続ができなくなるので、
最初のコーディネータとの通信はかなりの電波強度がないとうまくいかない
雰囲気でした。

XBeeProだと階が変わってもそこそこ通信が成り立つようで、9F事務所から
階段をつかってどこまで通信できるかをテストしました。

防火扉の向こうで徐々に降りていくと6FはOKでしたが5Fだと環境に微妙に依存
することがわかり、このあたりが限界点のようです。
電源のON・OFFによる再接続試験でも6FではOKですが、5Fだとダメ。
ということはPro版をつかっておけば、通常想定される多くの環境では
メッシュネットなどの複雑な通信なくコーディネータtoエンドデバイスという
通信でカバーできるということなのでしょう。

ここまでが観測距離だということがわかったので、こんどはルータ機能の確認も
やってみることに。
いままで通信していたデバイス1を1Fまで下げ、6Fの踊り場にルータを挿入しました。
案の定、何事もなかったようにつながります。なるほどね。

せっかく接続出来る限界をみつけられたので、気になる電源断からの復帰実験も。
結果からいえば、特に問題なく、再接続できました。電源の復帰順も関係なくデバイス1
からコーディネータへの再接続が行われます。
ここが一番不安だったので、ちょっとほっとしました。

ただ、電源断後復帰時に2.4GHz帯のチャンネル変更がかかったときにも同様に
ちゃんと復帰できるのかは未だに不安がのこるところですが、こればっかりは確認の
しようもないので、仕方ないですよね。

こんどは地下室と地下駐車場へ。
地下室内も金属パーティションが入っているにもかかわらず、
とくに問題なく接続できてしまいます。

地下室からコンクリート越しに駐車場にでてみるとやはりダメ。
つまりコンクリートは貫通できないと、まぁ当たり前の結論に。
ただ、各部屋の金属ドアをすこしあけてやると、状況は一変。

部屋から表に電波をだせさえすれば、コンクリートの特性で反射によって普通に
通信できてしまいます。
ここはちょっとオドロキでした。



最後に屋外の直線見通しでどの程度の実力があるのかを検証。
ASTEMからすぐ横の七本松通にでて、エンドデバイスをうごかしていきます。



縮尺単位が見やすいので
マップファンWebを
切り出して
つかっています。


Aの場所にコーディネータをおいて、
いままでと同じ要領でコマンドのトークバックを
確認していきます。

B位置くらいまでは普通に通信できますが
ここを超えると怪しくなり、信号を渡るために影に隠れると
通信エラーとなります。
信号を渡りきり、再び直線上にもどるとDの位置では
通信できるようになります。

このことから直線だと300mくらいが限界なのかもしれません。
まぁ、見通し直線といっても街路樹や電柱、看板など
障害となるモノはたくさんあるので、
実用距離は200mくらいとおもっていいのでしょう。
これでも十分です。

あとはルータを挿入するとどんどん伸ばせるので
ここらあたりからはZigBeeの独壇場となるのでしょうね。








2011年12月9日金曜日

Androidで「ものづくり」 第3回


昨日、奈良県工業技術センターで行われた
Androidで「ものづくり」  ~ものづくりシステムへのAndroid導入法~
の第3回、つまり最終回が終了しました。

1,2回がAndroidの組込ボードへのポーティングとNDKによるドライバレベルの実装、
という観点からのテーマでOESFのテキストに従って行われたのに対して
最終回である今回は、ふつ~にAndroidアプリを開発して、WifiのUDPダイアグラムで
自走模型をうごかしてみる、という内容。
つまり7月29日に行われた、奈良高専主催のアンドロイドワークショップの焼き直し
版でした。
ワークショップのときは午前の2時間、ということで時間切れ続出だったのと
自分自身にもアンドロイドの経験値がほとんどなかったので、こういう小難しいものなのか~
という印象しかなかったんですが、さすがに3ヶ月も経過するとその間の経験値上昇分で
いろいろ見えてくるモノがありました。

ダメだしする気は毛頭無いけど、ちょっとサンプルがお粗末だったかなぁ、というのが
正直なところ。3~4ヶ月あったにも関わらず、ほとんどコーディングが見直されておらず
個人的な印象では
「こりゃダメじゃん」(あくまで個人的印象ですよ)
なところが盛りだくさん。

まず、基本的なところで、フォームにボタン貼り付けてそれぞれの
コードを記述する、という部分。
いろんな本をよんだり、話をしていて一般的なのは
1.onCreateのなかで
    button.setOnClickListener(
          new View.OnClickListener(){
                 public void onClick( View v ){
                      ......
                 }
          }
     }
    みたいに記述する。

2.アクティビティの先頭で、implements View.OnClickListener を記述して
    onCreate内部で、
           Button.setOnClickListener(this);
    を実装した上で
    public void onClick( View v) {
         if ( v.getId() == R.id.Button1 ){
              .....
         }
    }
    を記述する。

3.XMLの<Button >のなかに、android:onClickで関数名を記述して
    アクティビティのコード内に直接関数記述する方法

の3種にほぼ集約されるとおもいます。
おそらく、これ以外の方法を公然となさっているパターンは少ないんじゃないかと。


で、今回の会ではこのいずれでもない状態で進んでしまいます(汗)
どうするかというと

メインのアクティビティのonCreateで
   Button.setOnClickListener( new XButtonListener() );
と記述した上で、当然、newしたリスナの実体がないので、
  Create class
して、実体を別クラスに生成するという荒技をつかいます。
初期のうちはこれでもちゃんと動作しますし、ソースが分割されていく、
というのを是とすれば、別に問題なくうごきます。

ただ、このあと別の画面へのインテントやWiport模型への各種コマンド発行ボタン
を実装したときに徐々に破綻していきます。
別の画面で設定変更を行って、メインのイベントに内蔵された機構にアクセスする
ときにクラスが分かれており、その都度生成を繰り返すため、
すべてのソースに同じ記述を繰り返すほか、本来必要でないfinal 宣言までつけないと
ダメとか、もうハチャメチャ。

すべては、必要のない記述と新規クラス生成をおこなったことを追認しようとして
穴埋めした結果におもえてしまう。

うごけばいいや、的な発想で教えられてもこまるんだよなぁ。
ことに、高専の先生であることが最大にイタイ。

まあ、コードの設計によって、最終コードの品質がここまでかわるんだ!ってのが
実感できたのは収穫だったけど。


このあたりのことも含めて反省会なんかでコードレビューも含めて座談会なんかが
開かれたらおもしろいなぁ。


総括としては
1.前2回のポーティング作業で、NDKで開発するのは問題ないとしても
    デバッグ等が結構面倒で、必要最小限にとどめるべきじゃないか?というのが
    得られた感触。
    NDKつかえば、たしかに高速化やLinuxの技術がつかえるなどのメリットもあるかも
    しれないけど、新たなバグの入り込む余地が爆発的にふえるにも関わらず、
    十分なデバッグ手法があるようにも思えないのが、最大の理由。
    つまり、どうしてもNDKをつかわないとダメか、という判断の上で決断すべきとおもう。
    機種(CPU)依存という新たな足かせも発生するというデメリットもおおきくなり
    アンドロイドという汎用OSをつかうメリットを失わせる危険もある

2.SDKによるアプリ開発のほうは、できるだけ標準的な手法に基づくほうが望ましい。
    特殊なやり方を推し進めようとすると、破綻する可能性が高い!


2011年12月7日水曜日

地デジその後

実家のTVのアンテナ用にいろいろ行ったことは前に書いた


で、団地の解体が現実に始まった段階で防音シートに覆われたところから
第二章が始まった(汗)


ま~~~~ったくうつらんようになった。
ハンパじゃなくて、それこそ全く。
で、ワンセグテレビを買ったときの室内アンテナを、自宅にあった5kgのダンベル(笑)に
くっつけて映るチャンネルによって向きを変えるなどの方法でごまかしてたけど
さすがに寒くなったのと、防音シートがとれたので、早速復旧開始。


TVの電波強度では3~4と、こりゃうつらんわな。
でもアンテナの向きを変えてもいっこうに変わる雰囲気がない???
いろいろごそごそと調べていくと、ブースタDU-35MパワーアップブースタDPW03
通電している確認ランプが、電源投入とともに明るくつくのに、3~5秒です~~~っと
消える。
どうもどこかで減衰するかショートしているようだ。
で、しかたないので、屋根までの同軸線も新調したらすごい!!
電波強度55~58くらい。
やっぱりアンテナ線だったかorz

そういえば、アナログの終盤ではTV大阪の映りが異様にわるかったんだよね。
今回は諸般の事情でそのケーブルを流用したんだけど、それが敗因だったとは。

で、方向も再計測すると従来よりかなり南西よりの方向が良いようだ。
ちょうど枚方方向がひらけているのがみえるようになったのでこれが効果があるんだろうなぁ

おかげで半年ぶりに、民放各社とNHKがみれるようになったのにくわえて
ずっとみれなかったKBS京都とサンテレビ、テレビ大阪が新たに加わった。
NHKも神戸が入るようになったし(意味ないけど)

なんかくたびれた~~

2011年12月6日火曜日

近畿高専JST産学マッチングフェア

12月5日に、大阪科学技術センタで行われたJST産学マッチングフェア
ワイヤレスコントロール研究会の出展をおこなってきました。

このワイヤレスコントロール研究会、ASTEM(京都高度技術研究所)の声がけで
京都・滋賀の数社と組んで「なんかおもしろいこと発信しよう!」ってことで
集まってる会なんですが、やっと実利用版のボードができたところです。



結局特別なハードウエアじゃなくて
センサー端末側は
   STM8S + XBee
でそこそこコンパクトになんでもできるように。

マスター(コーディネータ)側は能力が必要になるので
XPortPro(uCLinux) + XBee
で、ネットワークをまたいでいろんな制御ができるように

というのをもくろんだ簡単ユニットとなっています。


おきらくな測定用をもくろんだのですが、
試作基板的にはなんでもできる版なので
無駄が多い設計です。

つぎのバージョンではもっとかっちょよく
つくりたいところです



さて、印象なんですが、本来的な部分では特に問題ないっていうか
高専の関連の先生方なので、「ふ~ん」的反応しかなかったというか。
現実的なお話も若干はあったけど、名刺くれなかったし(汗)
まぁ、まだ値段がつけられてないし、しかたないよね

どっちかというと、展示場所が廊下というか通路に設定されてて
人がこないのが痛かった。
これって反則だよね。展示ブースとしては最低ランクにちかい。
まあ、それほど気張った展示でもないけどさ、それでもちょっとひどいかなぁ

あと、小難しく納入車の制限までかけて、車番まで通知したのに
現場で「駐車はNGです。出てって!」と追い出されたこと。
納入後止められるようにしてもらうための登録だったはずなのに。
結局近くのパーキングさがすハメになった。
これも最悪の印象。
けっきょくあんまりいい印象なかったなぁ。
なんか、待遇わるくない?どうするつもりなん?って感じ。
まあいいけどさ。

でも、悪いことばかりでもなかった。
最後の懇親会のときに、株式会社 ティーエーシーの高垣さんと
結構盛り上がったこと。
ET2011でも出展していた、おでかけガイガーを出展されてたんだけど
生にお話しすると、やっぱりかなりの部分「趣味で」とのお返事。

やっぱりな~、おもしろそうなことしてるもんね~ってカンジで
クレイン電子さんと盛り上がってた(笑)

ET-WESTでは、こっちもアンドロイドアプリだそう~っと。




マスター(コーディネータ)ユニット
こっちはデータの収集と
制御とLAN周りを統括します
LAN経由でつながっているのは
mbedでつくった即席コントローラです(^^)



エンド(センサ)ユニット
こっちはとりあえず温度制御用の
ユニットです。
汎用IOはすべて出ているので
ソフト次第でなんでもOKです。
処理も簡単だし。


チラシ表

今回配った
チラシです。がんばったでしょ


チラシ裏

裏面は研究会の
参加企業一覧



2011年12月3日土曜日

けいはんな

12月2日にけいはんなプラザで行われた組込みソフトサロンに行ってきました。

1.組込みソフトウエア開発の現状
2.エコタイプ次世代植物工場の制御
3.有機太陽電池の開発と展望
4.位置情報によるサービス提供技術の開発と実用化
5.製品開発ノウハウの流出の解決策

という大まかに5案件の講演と懇親会でした。

まあ、自慢?みたいな話もあるにはあったけど、それなりに刺激的。
エコタイプ次世代植物工場の案件が 旧 京都府フラワーセンター跡施設で
うごいてるなんてしらなかったし。
で、いまどきらしくLED照明で植物工場つくりましょ!ってところから
はじまって、赤色LEDの660nmの波長が葉緑素に強く働きかけて
蛍光灯より効率がいいとか、強すぎる光量は害になるだけなので
そこそこの光量(10000ルクス)ぐらいあれば十分なのだとか
それなりに科学的。
太陽光はもとより、燃料電池での発電、熱利用にくわえて、
発生する発電により発生するCO2をも植物用に流用しようと、
まぁ、できることはなんでもしてみるというどん欲な感じがすき(笑)

もう数年すると有機太陽電池も多く出てきたら、それこそすごいことができそう
って話も聞けたし。


で、一番おもしろかったのは位置情報。
といってもGPSみたいなのじゃなくて閉鎖空間(建物内)での
情報制御。
具体的には、病院内でのナースの位置情報取得から始まって
患者さんのデータ管理とか、という京大病院とのコラボ実例。

最初はZigBeeネット+赤外線による個体認証をつかってたけど
バージョンアップ時にBluetoothに変更したとのこと。
ちょっと「???」となった。
Bluetoothは基本ペアリングでデータ転送することをベースに
設計されているんで、マルチ基地と通信するのは無理じゃないか?
とおもったんだよね。

でも、どうも話を聞いてるうちにちがうことがわかってきた。
ここからは想像だけど、データ通信をすることを捨ててるんじゃないか?と。
つまりペアリングを前提にするBluetoothだからこそ、ブロードキャスト
で基地局の列挙をまずおこなっているわけで、そのときに得られる
RSSI値(電界強度ですな)をサンプルして、各基地局はそれぞれの
数値をただサーバーに転送するだけと。

これなら、サーバー側でいろんなアルゴリズムでデータ化ができるもんね。
データ通信機器をつかってデータ通信をしないという禁じ手をつかうとは!
目からうろこだったわ。
ただ、おもしろいつかいかただけどもったいないね。

ていうか、ZigBeeじゃダメだったんかな?
結構面倒なのは事実だけど。

もうすこし、やりようがありそうな気がする。

まあ、そういう発想の違いも得られたのはおおきかったかな。