かなり自由度が増しています。
ハード的には、電動ドリルから、ファンモータ加工に変更してあります。
騒音がマシにはなったけど、速度が落ちたのと、トルクがないので
ちょっとした歪みでも速度が大きく変化するので安定した表示にするのが
まだ大変です。
ここらは同期信号をなんとかすればなるので、次のステップにやっと進めそうです。
2012年1月25日水曜日
ぶんぶんディスプレイ Ver0.2
遅々としてすすまないわけですが、ソフト的にはかなりがっつり書き換わって
かなり自由度が増しています。
ハード的には、電動ドリルから、ファンモータ加工に変更してあります。
騒音がマシにはなったけど、速度が落ちたのと、トルクがないので
ちょっとした歪みでも速度が大きく変化するので安定した表示にするのが
まだ大変です。
ここらは同期信号をなんとかすればなるので、次のステップにやっと進めそうです。
かなり自由度が増しています。
ハード的には、電動ドリルから、ファンモータ加工に変更してあります。
騒音がマシにはなったけど、速度が落ちたのと、トルクがないので
ちょっとした歪みでも速度が大きく変化するので安定した表示にするのが
まだ大変です。
ここらは同期信号をなんとかすればなるので、次のステップにやっと進めそうです。
2012年1月24日火曜日
ぶんぶんディスプレイ
ちょっと会社でいろいろやってるんですが、
プロトタイプＡができたので、その報告（^@^
とりあえず、mbedつかってユニバーサルをつくって
ドリルでブン回してみたと。
同期もなにもとってないので、プロトタイプ０号機ってところでしょうか。
でも、文字がみえて、ひさしぶりにうれしくなって動画撮影(^^
まぁ、速度が変えられるのとテストが兼ねられるので
手作り感を堪能．．．．
mbedと16bit分のＬＥＤをつけてますが、現状ではソフトフォントを
流用したので、８ｘ８フォントです。
つまり最終的には16x100ぐらいのテロップくらいはいきたいかなと。
とりあえず、プロトタイプ０号のお祝いということで。
2012年1月10日火曜日
Jota でシンタックスハイライト
新年明けましておめでとうございます！
本年もどうぞよろしくお願いいたします。
例年、仕事に追われてどうしようもない感じなのですが、
今年こそはなにか新しいモノを！という意気込みでやっていきたいと思っています。
おつきあいのほど、よろしくお願いいたします。
閑話休題。
え～、いきなり趣味話から失礼（笑）
新年早々、Android用のJota Text Editorが、バージョンアップしました。
β版ながら今回のアップデートで、キーワードハイライティングに対応しています。
せっかくキーボード付きのアンドロイド端末、LifetouchNOTEをもってるんですが、
肝心のテキストエディタで、キーワードの色別ができるソフトがなくて、
なかなかプログラムにつかう！というところには心がうごかなかったんですが
やっとこれでつかえそうです。
特に、Android単体でプログラミング＆実行ができる
luaridaだと、キーワードがハイライトされるだけで、結構見通しが
ちがうものです。
というわけで、暫定的にluarida用の定義ファイルをつくってみました。
本年もどうぞよろしくお願いいたします。
例年、仕事に追われてどうしようもない感じなのですが、
今年こそはなにか新しいモノを！という意気込みでやっていきたいと思っています。
おつきあいのほど、よろしくお願いいたします。
閑話休題。
え～、いきなり趣味話から失礼（笑）
新年早々、Android用のJota Text Editorが、バージョンアップしました。
β版ながら今回のアップデートで、キーワードハイライティングに対応しています。
せっかくキーボード付きのアンドロイド端末、LifetouchNOTEをもってるんですが、
肝心のテキストエディタで、キーワードの色別ができるソフトがなくて、
なかなかプログラムにつかう！というところには心がうごかなかったんですが
やっとこれでつかえそうです。
特に、Android単体でプログラミング＆実行ができる
luaridaだと、キーワードがハイライトされるだけで、結構見通しが
ちがうものです。
というわけで、暫定的にluarida用の定義ファイルをつくってみました。
Luarida用キーワード定義ファイル(lua.conf)
うまくいくようなら、標準添付分にいれてもらえるように申請してみようと
おもいます。
やりかたは簡単で、
SDカードの
.jota/keyword/user
のなかにこのファイルをいれるだけです。
とりあえず、これでテストしています。
というわけで今年もどうぞよろしくお願いいたします！！
うまくいくようなら、標準添付分にいれてもらえるように申請してみようと
おもいます。
やりかたは簡単で、
SDカードの
.jota/keyword/user
のなかにこのファイルをいれるだけです。
とりあえず、これでテストしています。
というわけで今年もどうぞよろしくお願いいたします！！
2011年12月28日水曜日
年末のご挨拶＆自宅でできるリフロー
Twitter経由でなにげにおもしろいビデオ、みせてもらいました（笑）
なるほど。ホットプレートをつかうんですね。
前に、仕事の関連の人がやってましたが、温度管理が難しいと
のたまっていました。
そうか、
２３０－＞１８０－＞２３０
の変更でうまくいくのね。
案外こういうノウハウが大事だったりするので、メモメモ(^^
閑話休題。
今年もはやもう数日を残すのみとなりました。
10月から始めたこのブログも何とか起動に乗りつつあるようです。
MDRのHPやひとりごとページからきてくれているのが半分、
それ以外からの検索でこられる人が半分、というところでしょうか。
当初はＨＰの更新の面倒さからの解放を意図して始めたのですが
この気楽さはなんなんでしょうねぇ、ほぼ隔週での更新ができました。
単純な仕事話題だけでなく、サークラインＬＥＤなど、かなり個人的な
内容にもかなりのヒットがあるようで、なんとなくおもしろいなぁ、と
おもいました。
Twitter(@tetnoguchi)とfacebookでネットのつながりが増え、
ＧＥＮＥＴなどのリアルつながりがこれに加わりつつあり、
来年はこれらを生かした形でなにかできればな～と思ってたりします。
というわけで、来年もがんばって更新していきたいとおもいます。
それでは、みなさん、良いお年をお迎えください。
なるほど。ホットプレートをつかうんですね。
前に、仕事の関連の人がやってましたが、温度管理が難しいと
のたまっていました。
そうか、
２３０－＞１８０－＞２３０
の変更でうまくいくのね。
案外こういうノウハウが大事だったりするので、メモメモ(^^
さすがスイッチサイエンス。
今年もはやもう数日を残すのみとなりました。
10月から始めたこのブログも何とか起動に乗りつつあるようです。
MDRのHPやひとりごとページからきてくれているのが半分、
それ以外からの検索でこられる人が半分、というところでしょうか。
当初はＨＰの更新の面倒さからの解放を意図して始めたのですが
この気楽さはなんなんでしょうねぇ、ほぼ隔週での更新ができました。
単純な仕事話題だけでなく、サークラインＬＥＤなど、かなり個人的な
内容にもかなりのヒットがあるようで、なんとなくおもしろいなぁ、と
おもいました。
Twitter(@tetnoguchi)とfacebookでネットのつながりが増え、
ＧＥＮＥＴなどのリアルつながりがこれに加わりつつあり、
来年はこれらを生かした形でなにかできればな～と思ってたりします。
というわけで、来年もがんばって更新していきたいとおもいます。
それでは、みなさん、良いお年をお迎えください。
2011年12月13日火曜日
ZigBeeの能力試験をやってみた
某研究会でおこなっているZigBeeのボード設計周りも大詰めなので
懸案だった接続テストと能力測定を行いました。
場所は京都五条七本松のＡＳＴＥＭ（京都高度技術研究所）です。
省エネ動作そのものは特に問題となるほどおおきくないので
DigiのXBeeとXBeeProでZigBeeモードのコーディネータデバイスとルータデバイス
としてテストを行いました。
製品性能の取得を目的としていないので、実運用に近いテストという観点から
コーディネータからコマンド送信し、ルータデバイスからトークバックが得られるかどうかと
その遅延性がどの程度か、を確認していくという簡易な方法をとりました。
屋内試験では事務所内でいろいろやってたんですが、同一フロアなら
XBee/XBeeProとも、特に問題にならないほどの安定性が得られました。
そういうもんなんですかね。
XBeeとXBeeProでは利用できる出力がかなりちがうので、どうようの運転が
できたのはここまでで、XBeeは階がかわるととたんに通信が滞るようになります。
このレベルになると、電源ＯＮからの再接続ができなくなるので、
最初のコーディネータとの通信はかなりの電波強度がないとうまくいかない
雰囲気でした。
XBeeProだと階が変わってもそこそこ通信が成り立つようで、９F事務所から
階段をつかってどこまで通信できるかをテストしました。
防火扉の向こうで徐々に降りていくと６ＦはＯＫでしたが５Ｆだと環境に微妙に依存
することがわかり、このあたりが限界点のようです。
電源のＯＮ・ＯＦＦによる再接続試験でも６ＦではＯＫですが、５Ｆだとダメ。
ということはＰｒｏ版をつかっておけば、通常想定される多くの環境では
メッシュネットなどの複雑な通信なくコーディネータtoエンドデバイスという
通信でカバーできるということなのでしょう。
ここまでが観測距離だということがわかったので、こんどはルータ機能の確認も
やってみることに。
いままで通信していたデバイス１を１Ｆまで下げ、６Ｆの踊り場にルータを挿入しました。
案の定、何事もなかったようにつながります。なるほどね。
せっかく接続出来る限界をみつけられたので、気になる電源断からの復帰実験も。
結果からいえば、特に問題なく、再接続できました。電源の復帰順も関係なくデバイス１
からコーディネータへの再接続が行われます。
ここが一番不安だったので、ちょっとほっとしました。
ただ、電源断後復帰時に２．４ＧＨｚ帯のチャンネル変更がかかったときにも同様に
ちゃんと復帰できるのかは未だに不安がのこるところですが、こればっかりは確認の
しようもないので、仕方ないですよね。
こんどは地下室と地下駐車場へ。
地下室内も金属パーティションが入っているにもかかわらず、
とくに問題なく接続できてしまいます。
地下室からコンクリート越しに駐車場にでてみるとやはりダメ。
つまりコンクリートは貫通できないと、まぁ当たり前の結論に。
ただ、各部屋の金属ドアをすこしあけてやると、状況は一変。
部屋から表に電波をだせさえすれば、コンクリートの特性で反射によって普通に
通信できてしまいます。
ここはちょっとオドロキでした。
最後に屋外の直線見通しでどの程度の実力があるのかを検証。
ASTEMからすぐ横の七本松通にでて、エンドデバイスをうごかしていきます。
Ａの場所にコーディネータをおいて、
いままでと同じ要領でコマンドのトークバックを
確認していきます。
Ｂ位置くらいまでは普通に通信できますが
ここを超えると怪しくなり、信号を渡るために影に隠れると
通信エラーとなります。
信号を渡りきり、再び直線上にもどるとＤの位置では
通信できるようになります。
このことから直線だと３００ｍくらいが限界なのかもしれません。
まぁ、見通し直線といっても街路樹や電柱、看板など
障害となるモノはたくさんあるので、
実用距離は２００ｍくらいとおもっていいのでしょう。
これでも十分です。
あとはルータを挿入するとどんどん伸ばせるので
ここらあたりからはZigBeeの独壇場となるのでしょうね。
懸案だった接続テストと能力測定を行いました。
場所は京都五条七本松のＡＳＴＥＭ（京都高度技術研究所）です。
省エネ動作そのものは特に問題となるほどおおきくないので
DigiのXBeeとXBeeProでZigBeeモードのコーディネータデバイスとルータデバイス
としてテストを行いました。
製品性能の取得を目的としていないので、実運用に近いテストという観点から
コーディネータからコマンド送信し、ルータデバイスからトークバックが得られるかどうかと
その遅延性がどの程度か、を確認していくという簡易な方法をとりました。
屋内試験では事務所内でいろいろやってたんですが、同一フロアなら
XBee/XBeeProとも、特に問題にならないほどの安定性が得られました。
そういうもんなんですかね。
XBeeとXBeeProでは利用できる出力がかなりちがうので、どうようの運転が
できたのはここまでで、XBeeは階がかわるととたんに通信が滞るようになります。
このレベルになると、電源ＯＮからの再接続ができなくなるので、
最初のコーディネータとの通信はかなりの電波強度がないとうまくいかない
雰囲気でした。
XBeeProだと階が変わってもそこそこ通信が成り立つようで、９F事務所から
階段をつかってどこまで通信できるかをテストしました。
防火扉の向こうで徐々に降りていくと６ＦはＯＫでしたが５Ｆだと環境に微妙に依存
することがわかり、このあたりが限界点のようです。
電源のＯＮ・ＯＦＦによる再接続試験でも６ＦではＯＫですが、５Ｆだとダメ。
ということはＰｒｏ版をつかっておけば、通常想定される多くの環境では
メッシュネットなどの複雑な通信なくコーディネータtoエンドデバイスという
通信でカバーできるということなのでしょう。
ここまでが観測距離だということがわかったので、こんどはルータ機能の確認も
やってみることに。
いままで通信していたデバイス１を１Ｆまで下げ、６Ｆの踊り場にルータを挿入しました。
案の定、何事もなかったようにつながります。なるほどね。
せっかく接続出来る限界をみつけられたので、気になる電源断からの復帰実験も。
結果からいえば、特に問題なく、再接続できました。電源の復帰順も関係なくデバイス１
からコーディネータへの再接続が行われます。
ここが一番不安だったので、ちょっとほっとしました。
ただ、電源断後復帰時に２．４ＧＨｚ帯のチャンネル変更がかかったときにも同様に
ちゃんと復帰できるのかは未だに不安がのこるところですが、こればっかりは確認の
しようもないので、仕方ないですよね。
こんどは地下室と地下駐車場へ。
地下室内も金属パーティションが入っているにもかかわらず、
とくに問題なく接続できてしまいます。
地下室からコンクリート越しに駐車場にでてみるとやはりダメ。
つまりコンクリートは貫通できないと、まぁ当たり前の結論に。
ただ、各部屋の金属ドアをすこしあけてやると、状況は一変。
部屋から表に電波をだせさえすれば、コンクリートの特性で反射によって普通に
通信できてしまいます。
ここはちょっとオドロキでした。
最後に屋外の直線見通しでどの程度の実力があるのかを検証。
ASTEMからすぐ横の七本松通にでて、エンドデバイスをうごかしていきます。
 |
| 縮尺単位が見やすいので マップファンＷｅｂを 切り出して つかっています。 |
Ａの場所にコーディネータをおいて、
いままでと同じ要領でコマンドのトークバックを
確認していきます。
Ｂ位置くらいまでは普通に通信できますが
ここを超えると怪しくなり、信号を渡るために影に隠れると
通信エラーとなります。
信号を渡りきり、再び直線上にもどるとＤの位置では
通信できるようになります。
このことから直線だと３００ｍくらいが限界なのかもしれません。
まぁ、見通し直線といっても街路樹や電柱、看板など
障害となるモノはたくさんあるので、
実用距離は２００ｍくらいとおもっていいのでしょう。
これでも十分です。
あとはルータを挿入するとどんどん伸ばせるので
ここらあたりからはZigBeeの独壇場となるのでしょうね。
2011年12月9日金曜日
Androidで「ものづくり」 第3回
昨日、奈良県工業技術センターで行われた
Androidで「ものづくり」 ～ものづくりシステムへのAndroid導入法～
の第3回、つまり最終回が終了しました。
１，２回がAndroidの組込ボードへのポーティングとＮＤＫによるドライバレベルの実装、
という観点からのテーマでＯＥＳＦのテキストに従って行われたのに対して
最終回である今回は、ふつ～にAndroidアプリを開発して、WifiのUDPダイアグラムで
自走模型をうごかしてみる、という内容。
つまり７月２９日に行われた、奈良高専主催のアンドロイドワークショップの焼き直し
版でした。
ワークショップのときは午前の２時間、ということで時間切れ続出だったのと
自分自身にもアンドロイドの経験値がほとんどなかったので、こういう小難しいものなのか～
という印象しかなかったんですが、さすがに３ヶ月も経過するとその間の経験値上昇分で
いろいろ見えてくるモノがありました。
ダメだしする気は毛頭無いけど、ちょっとサンプルがお粗末だったかなぁ、というのが
正直なところ。３～４ヶ月あったにも関わらず、ほとんどコーディングが見直されておらず
個人的な印象では
「こりゃダメじゃん」（あくまで個人的印象ですよ）
なところが盛りだくさん。
まず、基本的なところで、フォームにボタン貼り付けてそれぞれの
コードを記述する、という部分。
いろんな本をよんだり、話をしていて一般的なのは
１．onCreateのなかで
button.setOnClickListener(
new View.OnClickListener(){
public void onClick( View v ){
......
}
}
}
みたいに記述する。
２．アクティビティの先頭で、implements View.OnClickListener を記述して
onCreate内部で、
Button.setOnClickListener(this);
を実装した上で
public void onClick( View v) {
if ( v.getId() == R.id.Button1 ){
.....
}
}
を記述する。
３．XMLの<Button >のなかに、android:onClickで関数名を記述して
アクティビティのコード内に直接関数記述する方法
の３種にほぼ集約されるとおもいます。
おそらく、これ以外の方法を公然となさっているパターンは少ないんじゃないかと。
で、今回の会ではこのいずれでもない状態で進んでしまいます（汗）
どうするかというと
メインのアクティビティのonCreateで
Button.setOnClickListener( new XButtonListener() );
と記述した上で、当然、newしたリスナの実体がないので、
Create class
して、実体を別クラスに生成するという荒技をつかいます。
初期のうちはこれでもちゃんと動作しますし、ソースが分割されていく、
というのを是とすれば、別に問題なくうごきます。
ただ、このあと別の画面へのインテントやWiport模型への各種コマンド発行ボタン
を実装したときに徐々に破綻していきます。
別の画面で設定変更を行って、メインのイベントに内蔵された機構にアクセスする
ときにクラスが分かれており、その都度生成を繰り返すため、
すべてのソースに同じ記述を繰り返すほか、本来必要でないfinal 宣言までつけないと
ダメとか、もうハチャメチャ。
すべては、必要のない記述と新規クラス生成をおこなったことを追認しようとして
穴埋めした結果におもえてしまう。
うごけばいいや、的な発想で教えられてもこまるんだよなぁ。
ことに、高専の先生であることが最大にイタイ。
まあ、コードの設計によって、最終コードの品質がここまでかわるんだ！ってのが
実感できたのは収穫だったけど。
このあたりのことも含めて反省会なんかでコードレビューも含めて座談会なんかが
開かれたらおもしろいなぁ。
総括としては
１．前２回のポーティング作業で、NDKで開発するのは問題ないとしても
デバッグ等が結構面倒で、必要最小限にとどめるべきじゃないか？というのが
得られた感触。
ＮＤＫつかえば、たしかに高速化やLinuxの技術がつかえるなどのメリットもあるかも
しれないけど、新たなバグの入り込む余地が爆発的にふえるにも関わらず、
十分なデバッグ手法があるようにも思えないのが、最大の理由。
つまり、どうしてもＮＤＫをつかわないとダメか、という判断の上で決断すべきとおもう。
機種（ＣＰＵ）依存という新たな足かせも発生するというデメリットもおおきくなり
アンドロイドという汎用ＯＳをつかうメリットを失わせる危険もある
２．ＳＤＫによるアプリ開発のほうは、できるだけ標準的な手法に基づくほうが望ましい。
特殊なやり方を推し進めようとすると、破綻する可能性が高い！
2011年12月7日水曜日
地デジその後
実家のTVのアンテナ用にいろいろ行ったことは前に書いた
で、団地の解体が現実に始まった段階で防音シートに覆われたところから
第二章が始まった（汗）
ま～～～～ったくうつらんようになった。
ハンパじゃなくて、それこそ全く。
で、ワンセグテレビを買ったときの室内アンテナを、自宅にあった５ｋｇのダンベル（笑）に
くっつけて映るチャンネルによって向きを変えるなどの方法でごまかしてたけど
さすがに寒くなったのと、防音シートがとれたので、早速復旧開始。
TVの電波強度では３～４と、こりゃうつらんわな。
でもアンテナの向きを変えてもいっこうに変わる雰囲気がない？？？
なんかくたびれた～～
で、団地の解体が現実に始まった段階で防音シートに覆われたところから
第二章が始まった（汗）
ま～～～～ったくうつらんようになった。
ハンパじゃなくて、それこそ全く。
で、ワンセグテレビを買ったときの室内アンテナを、自宅にあった５ｋｇのダンベル（笑）に
くっつけて映るチャンネルによって向きを変えるなどの方法でごまかしてたけど
さすがに寒くなったのと、防音シートがとれたので、早速復旧開始。
TVの電波強度では３～４と、こりゃうつらんわな。
でもアンテナの向きを変えてもいっこうに変わる雰囲気がない？？？
通電している確認ランプが、電源投入とともに明るくつくのに、３～５秒です～～～っと
消える。
どうもどこかで減衰するかショートしているようだ。
で、しかたないので、屋根までの同軸線も新調したらすごい！！
電波強度５５～５８くらい。
やっぱりアンテナ線だったかorz
そういえば、アナログの終盤ではＴＶ大阪の映りが異様にわるかったんだよね。
今回は諸般の事情でそのケーブルを流用したんだけど、それが敗因だったとは。
で、方向も再計測すると従来よりかなり南西よりの方向が良いようだ。
ちょうど枚方方向がひらけているのがみえるようになったのでこれが効果があるんだろうなぁ
おかげで半年ぶりに、民放各社とＮＨＫがみれるようになったのにくわえて
ずっとみれなかったＫＢＳ京都とサンテレビ、テレビ大阪が新たに加わった。
ＮＨＫも神戸が入るようになったし（意味ないけど）
なんかくたびれた～～
登録:
投稿 (Atom)