TWELITE日記

2024年1月28日 (日)

TWELITEでソーラーパワーを使う - その4

蓄電デバイスがどの程度動くのか確認した。

蓄電デバイスがどの程度チャージできているか分からないのでこの結果がどの程度の一般性があるかは分からない。

薄曇りではあったけれども比較的天気の良い日に屋根の上にソーラーパネル付きのTWELITEを置いておいた。

TWELITEを部屋に取り込み段ボール箱を被せて日光を遮った。つまり蓄電デバイスのみでの動作となるわけだ。

Img06914_small

以下にTWELITEのVCC変化をグラフにしてみた。縦軸がVCC(Vx100)、横軸がサンプリングカウントで5秒に1回インクリメントしている。

Twevcc
VCCは明るいところでは3.5V程度あるが、段ボール箱を被せると3V程度に低下する。つまり、蓄電デバイス単独となるとVCCは3Vになるということだ。このあと徐々に電圧は低下していく。大体2.6V程度でTWELITE自体がPORしてしまう。その時のサンプリングカウントは400だ。つまり400 x 5秒 = 2000秒 = 33.3分。

結果:蓄電デバイス1.5F、送信インターバル5秒では暗所で約33分は動作した

TWELITE DIPの送信インターバルが5秒だと約33分程度は蓄電デバイス(1.5F)で動作することが分かった(少なくともこの建付けでは)。

ちなみにここのデータ取りは以下のPythonコードで行った。TWELITEからの送信データをCSVにしてファイルに書き出している。上記のグラフはそのCSVをエクセルでグラフ化したもの。

ダウンロード - twelitemonitor1.py

次は蓄電デバイス3.5Fで実験してみる。

Img06915_small

電気二重層コンデンサを1.5Fから3.5Fに差し替えて実験を行った。まずローラーパネルが日光に当たるように一日外に出した。十分に充電と判断し、陽射しが残っている間にTWELITEを室内に取り込み段ボールで蓋をした。

段ボールを被せてから917カウント後にTWELITEはPORした。
917 x 5秒 = 4585秒 = 76分

Twevcc35f

1.5F : 33分
3.5F : 73分
-----   -----
2.3倍  2.2倍

この2つのサンプルではキャパシティ容量増加比と動作時間増加比はほぼ同じとなった。

次は送信インターバルを5分 = Sleep Dur 300,000ms(今までは5秒だったので60倍)にして発電停止後の動作時間を計ってみる。

Dur300000

1.5Fについて、Sleep Duration 300,000秒、すなわち5分で実験してみた。結果は約50分。横軸はTWELITEのCounterで92で遮光した。で、102が最後のログとなっていた。つまり102-92=10 10x5分で50分。誤差は5分はある。5秒インターバルで33分だった。思いの外時間が伸びなかった(2倍にもなっていない)。
15fdur30k

Sleep Durationを変更しても動作時間が伸びないということは、TWELITE以外の消費電力が多い可能性を示唆している。今回の測定ではADT7410温度センサーモジュールを使っている。

Img07200

このモジュールが怪しい。スペックをみると210uA(Typ)とある。これは常時通電モードの消費電流。ADT7410はシャットダウンモードを供えていてそちらは2uAだ。TWELITEではDevice ModeとしてADT7410を設定しているが、TWELITEのApp_TagがどのモードでADT7410にセットしているかわからない。ちなみにDefaultは常時通電モード。

とりあえずADT7410を取り外し、TWELITEのDevice Modeをアナログセンサーモード0x10(内蔵ADCレベルの取得)に設定して再テストすることにした。ちなみにDevice ModeをADT7410(0x30)にセットしたままでADT7410だけ取り外すとTWELITEは動作しない(多分ADT7410とコミュニケーションできないから)。電気二重層コンデンサは1.5F、Sleep Durationは5分(30,000msec)。

結果は劇的だった。33.16時間。Count=37からスタートして435まで(5min/count)。
(435-37)*5/60 = 33.16 hours
途中PCをスリープにしたので目盛りでCount=104から210までは飛んでいる。

Twelite_20240205091401

これなら24時間を大きく超えているので、天候が良い日が続けば24時間稼働が可能だ。電気二重層コンデンサを3.5Fに交換すれば単純に2倍の時間は動作すると予想されるので66時間(約2日半)は動作すると思われる。

この事はTWELITE動作時間においてセンサー回路の設計がとても重要であることを示唆している。

2024年1月26日 (金)

TWELITEでソーラーパワーを使う - その3

秋月電子からソーラーモジュールと電気二重層コンデンサ1.5F3.5Fが届いた。

Img06891_small

まずはソーラーモジュールからテストしてみた。ソーラーモジュールはSHARP製の300mWモジュールだ。これにC基板が付属したものを購入した。C基板が必要かどうか分からなかったので(でもセットで売ってるんだから理由があるのでは?って思い)とりあえずC基板付属を調達してみた。いろいろ考えたが結局C基板付属の意味が見いだせなかった。

Img06892_small

ソーラーモジュールに出力線を半田付け。

Img06893_small

ショート防止のために養生テープを貼り付けた。ガムテープだと剥がすのが大変かと思い、比較的やさしい接着力の養生テープを採用。

Img06894_small

ソーラー電源管理モジュールに接続した。

Img06896_small

既に日没後だったのでまずはLEDランプで動作確認。

Img06895_small

オシロでみてみると2.9V程度の出力が出ている。これはかなり強力だ。

Ds1z_quickprint1_20240126194501

LEDランプを消してみると急速に2Vまで電圧低下する。これはソーラー電源管理モジュール内蔵の220uFの放電の様子を見ているんだと思う。2.0VになるとTWELITEがOFFになるので暫く2.0Vで水平飛行をする。

Ds1z_quickprint2_20240126194501

しかし、耐え切れなくてなって完全放電するみたい。

Ds1z_quickprint3_20240126194501

放電が進んでからLEDランプを点灯させると一瞬にして2.9Vまで回復する(当然か)。

Ds1z_quickprint4

ということで300mWのモジュールは結構パワーがありそうだ。次は電気二重層コンデンサを接続して蓄電をしてみる。

その前にちょっと特記すべき現象に遭遇した。LEDランプだけでTWELITEが動作するような書き方を上でしたけれど、どうもそう簡単ではないようだ。ちなみに上の試験はまだ明るいうち(外からの光が窓越しにはいってきていて、その上でLEDランプをつけていた)に実行したモノだった。夜になって外の明かりが無くなってLEDランプだけになったら様子は違った。

LEDランプだけだとTWELITEの電源電圧はこんな感じで振れてしまった。① おそらく電圧が上昇してTWELITEに給電できる電圧(オシロでは2.6V位か)に到達してTWELITEの電源がONになるけれども ②発電量よりも供給量の方が多く急激に電圧低下(220uFが放電してまう)を起こしTWELITEをOFFにする。③ また受光による充電による給電がはじまって②にもどる、、、、というサイクルが起きてるのではないかと思う。

Ds1z_quickprint1_20240127083201

Ds1z_quickprint4_20240127083701

LEDランプの発光量を弱にして(TWELITEが再起動しないほど発電量を下げて)電圧が降下した後、LEDランプに加えて昔ながらの豆電球懐中電灯の光を当ててやると、発電量が増加するがその過程で一瞬同様の事象が発生する。つまり電圧が過渡期で発電量が弱い場合にこのような発振的な事象が発生するんだと思う。

そんなこんなで電気二重層コンデンサ1.5Fを付けてみた。

Img06898_small

朝日が出る前に窓際に一式をセットした。

Img06899_small
日光が当たってきた。ガラスの関係で室内にはソフトな光が入ってくる。
Img06901_hdr_small

 

Img06904_small

光の強さによってTWELITE VCCは様子が変化した。光が強くなると高い周波数のノイズが入るようになった。電圧は大体3.2V位になっている。10分程光に当てた状態でソーラーパネルに遮蔽を被せるとノイズは乗るが電圧は3.2Vあたりで安定している。電気二重層コンデンサに充電がされているようだ。

朝日が当たる前:
Ds1z_quickprint1_20240127084801
薄っすらと光が当り始める直前:
Ds1z_quickprint2_20240127084801
朝日がうっすらと当たり始めた時:
Ds1z_quickprint3_20240127084801
しっかりと太陽光が当たっている時:
Ds1z_quickprint4_20240127084801

朝8時55分に外に出してみた。暫く充電をしてみる。

Img06904_small Img06905_small

TWELITEは元気に動いている。
::ts=62
::rc=80000000:lq=78:ct=05F5:ed=810CCAC2:id=0:ba=3650:a1=1792:a2=2467:te=1050
::ts=63
::ts=64
::ts=65
::ts=66
::ts=67
::rc=80000000:lq=78:ct=05F6:ed=810CCAC2:id=0:ba=3480:a1=1792:a2=2467:te=1062
::ts=68
::ts=69
::ts=70
::ts=71
::ts=72
::rc=80000000:lq=78:ct=05F7:ed=810CCAC2:id=0:ba=3650:a1=1789:a2=2467:te=1050
::ts=73
::ts=74
::ts=75
::ts=76
::ts=77
::rc=80000000:lq=75:ct=05F8:ed=810CCAC2:id=0:ba=3470:a1=1792:a2=2467:te=1050
::ts=78
::ts=79
::ts=80
::ts=81
::ts=82
::rc=80000000:lq=78:ct=05F9:ed=810CCAC2:id=0:ba=3650:a1=1789:a2=2467:te=1056
::ts=83

想定外の結果になった。

ログを見ると5時3分位にTWELITEの送信が止まっていた。だいたい4時近くまで陽射しはあり、3時30分位までは斜めからではあるけれど日光が当たっていたと思う。5時3分はまだ明るい時間で、この時間に送信が止まるという事はソーラーパネルの充電電圧が低下してから1時間30分も持たなかったことになる。
Tickカウンター 27535まではct=1B64とインクリメントが続いている。その時の電源電圧2.675V
Tickカウンター 27540ではct=0001とリセットされている。その時の電源電圧は2.630V

::rc=80000000:lq=84:ct=1B63:ed=810CCAC2:id=0:ba=2680:a1=1534:a2=2467:te=0656
::ts=27531
::ts=27532
::ts=27533
::ts=27534
::ts=27535
::rc=80000000:lq=84:ct=1B64:ed=810CCAC2:id=0:ba=2675:a1=1534:a2=2467:te=0656
::ts=27536
::ts=27537
::ts=27538
::ts=27539
::ts=27540
::rc=80000000:lq=84:ct=0001:ed=810CCAC2:id=0:ba=2630:a1=1107:a2=2467:te=0850
::ts=27541
::ts=27542
::ts=27543
::ts=27544
::ts=27545
::ts=27546
::rc=80000000:lq=84:ct=0001:ed=810CCAC2:id=0:ba=2635:a1=1097:a2=2467:te=0612

どうやら電源電圧2.675Vを下回るとTWELITE DIPは電源電圧モニターが働くようだ。

ログが残っている最も過去はおよそ20分前。その時の電源電圧は2.880V。およそ20分かけて2.880Vから2.630Vまで0.25V低下したことになる。

::ts=26327
::rc=80000000:lq=84:ct=1A70:ed=810CCAC2:id=0:ba=2880:a1=1628:a2=2467:te=1075
::ts=26328

ソーラー電源管理モジュールのマニュアルには以下の記載がある。BYPをDO2に接続すれば0.2Vを稼ぐことができる。リニアに低下するわけではないと思うが約15分程度は延命できるとみることもできる。
BYP
TWELITEのDO2に接続します。
Hiにすると、蓄電デバイスとTWE_VCC間へ接続されているダイオードをバイパスします。
蓄電デバイスが2.3Vの状態でTWELITEへ電源を供給すると、ダイオードの電圧降下によりTVE_VCCは約2.0Vになり動作を停止します。バイパスを行うと、蓄電デバイスが約2.0VまでTWELITEを動作できます。
電圧条件は、TWELITEの電圧条件に従います。

どうやら受信データから電源電圧(ba)を取り出してプロットするアプリを作る必要がありそうだ。

2024年1月23日 (火)

TWELITEでソーラーパワーを使う - その2

TWELITE DIPにApp_Tagをインストールできたので、次はTWE-EH SOLARの実験だ。以後ソーラーモジュールと呼ぶ。

Img06838_small

ソーラーモジュールを配線してLEDランプの下に置いてみた。TWELITEは時々(本当に時々)動作する。TWELITEはVCCが2.0V以下では動作しないので発電電圧(TWE_VCC)が2.0を超えないという事だとおもう。

Img06830_small

朝、太陽が出てからソーラーパネルを日光に当ててみた。TWELITEは速攻で動き出した。

Img06833_hdr_small

::ts=44032
::rc=80000000:lq=135:ct=0016:ed=810CCAC2:id=0:ba=3310:a1=0612:a2=2467:te=1562
::ts=44033
::ts=44034
::ts=44035
::ts=44036
::ts=44037
::rc=80000000:lq=132:ct=0017:ed=810CCAC2:id=0:ba=3420:a1=0598:a2=2467:te=1562
::ts=44038
::ts=44039
::ts=44040
::ts=44041
::ts=44042
::rc=80000000:lq=132:ct=0018:ed=810CCAC2:id=0:ba=3340:a1=0634:a2=2467:te=1562
::ts=44043
::ts=44044
::ts=44045
::ts=44046
::ts=44047
::rc=80000000:lq=132:ct=0019:ed=810CCAC2:id=0:ba=3380:a1=0627:a2=2467:te=1562
::ts=44048
::ts=44049
::ts=44050
::ts=44051
::ts=44052
::rc=80000000:lq=132:ct=001A:ed=810CCAC2:id=0:ba=3360:a1=0639:a2=2467:te=1562
::ts=44053
::ts=44054
::ts=44055
::ts=44056
::ts=44057
::rc=80000000:lq=132:ct=001B:ed=810CCAC2:id=0:ba=3350:a1=0624:a2=2467:te=1562
::ts=44058

ソーラーパネルを日陰の状態から日光にあてるとTWE_VCCは3.2V程度まで上がる。

Ds1z_quickprint10

ソーラーパネルを日陰にするとTWE_VCCは徐々に低下していく。階段上になっているのがTWELITEの送信タイミング。この時TWELITEの送信間隔は5秒に設定している。

Ds1z_quickprint12

TWE_VCCが2V程度になるとTWELITEは動いたり動かなかったりする。動くと電圧はドロップし、徐々に回復する。つまり日陰で細々と充電するわけだ。けれども2.0Vを越えられないようだ。

Ds1z_quickprint13

次にVC2を見てみた。マニュアルによるとVC2は蓄電デバイス(デフォルトで220uFコンデンサ、写真アカ丸のC2)の充電電圧モニター出力だ。

Img068611_small

充電電圧モニターこんな感じの鋸状の波形になっている。真ん中の谷はTWELITE動作時。充放電サイクルを繰り返しているんだと思う。

Ds1z_quickprint9

このC2には外部に並列コンデンサを付けることができる。それによって充電デバイス容量を増やすことができるわけだ。以下の写真は外部コンデンサーとして220uFのケミコンを取り付けた様子。

Img068631_small

外部コンデンサー220uFを追加すると充電電圧モニターはこんな感じに変わる。充電容量が増えた分、充放電サイクルが長くなるようだ。

Ds1z_quickprint8

仮に外部コンデンサーを取り付けても日陰になると直ぐにTWE_VCCは2ボルトになってしまう。次は外部蓄電デバイスとして電気二重層コンデンサ、いわゆるEDLCを取り付けて日光が当たらない状態でどのくらいの動作時間が得られるか実験だ。なにしろ1FのEDLCでも220uFの4500倍の静電容量となる。

仮に220uFで送信4回できるならインターバル5秒だと20秒、4500x20= 90000秒、 90000秒は25時間なので、一回充電すれば1日は持つことになる(かな)。

 

TWELITEでソーラーパワーを使う

TWELITEでソーラーパワー(TWE-EH SOLAR)無線マイコンTWELITE用ソーラー電源管理モジュールを使う。

ソーラーパワーの使い方はネットに書かれているけれど情報が拡散していてなかなか分かりにくい。

まずは無線タグアプリ(App_Tag)をインストールすることが必要だと分かった最新のTWELITE Stageをダウンロードする。古いままでやっていたら何が何だかわからなくなった。。。。

最新版のTWELITE Stageを使用すること。

で、TWELITE_Stage.exeを使ってTWELITE APPSビルド&書換を実行した。インストールするのは、子機(DIP)はApp_Tag_EndDevice_Input、MONO_StickはApp_Tag_Parent_MONOSTICKだ。

App_TagをDIPにインストールしたけれどインタラクティブモードに移行しない。
どうやらM2をグランドに落とさないといけないようだ。M2がオープンのままだとOTAモードが働くと書いてある。なんだかちょっと違うような雰囲気だけれども、M2をグランドに落とさないとインタラクティブモードにならない事に変わりはない。

で、M2をグランドにおとしてみたらインタラクティブモードのメニューが現れた。
OTA(On The Air)をPORで起動しないようにするにはオプションビット ?????4?? を設定しろとある。現時点のオプションビットの値が0x00000011だから0x00000411に設定すればよいのだろう。
Tag4
しかし、Optionを00000411にしてもやっぱりM2をGNDに落とさないとインタラクティブモードに入れない。

App_Tagで子機をインタラクティブモードにするにはM2をGNDに接続すること。通常動作に戻すにはM2をOPENにすること。
この操作を実行するために簡易的にR2にスイッチをつけた。
Img06831_burst01_small

子機をインタラクティブモードにしてSleep Durを(2000) 2秒にした時のMONO Stickのアウトプット。この画面はMONOSTICKのターミナル画面。MONOSTICKは1秒間隔でモニター結果をターミナルに出力するようだ。tsとはTimeStampだと思う。起動(リセット)直後はts=1でそこからインクリメントされていく。子機からの信号を受信するとその結果を表示する。以下の表示結果はMONOSTICKのOption Bitsを0x00000000に、子機(DIP)のSensor Modeを0x11に設定した場合の表示フォーマットだ。ちなみにこのモニター時にはアナログ温度センサーとしてMCP9700を取り付けてある。

::ts=2270
::rc=80000000:lq=132:ct=00CD:ed=810CCAC2:id=0:ba=3060:te=1090:a0=2467:a1=709
::ts=2271
::ts=2272
::rc=80000000:lq=135:ct=00CE:ed=810CCAC2:id=0:ba=3060:te=1110:a0=2467:a1=711
::ts=2273
::ts=2274
::rc=80000000:lq=132:ct=00CF:ed=810CCAC2:id=0:ba=3060:te=1090:a0=2467:a1=709
::ts=2275
::ts=2276
::rc=80000000:lq=132:ct=00D0:ed=810CCAC2:id=0:ba=3060:te=1090:a0=2467:a1=709
::ts=2277
::ts=2278
::rc=80000000:lq=132:ct=00D1:ed=810CCAC2:id=0:ba=3060:te=1060:a0=2467:a1=706
::ts=2279
::ts=2280
::rc=80000000:lq=132:ct=00D2:ed=810CCAC2:id=0:ba=3060:te=1060:a0=2467:a1=706
::ts=2281
::ts=2282
::rc=80000000:lq=132:ct=00D3:ed=810CCAC2:id=0:ba=3060:te=1090:a0=2467:a1=709
::ts=2283
::ts=2284
::rc=80000000:lq=132:ct=00D4:ed=810CCAC2:id=0:ba=3060:te=1090:a0=2467:a1=709
::ts=2285
::ts=2286
::rc=80000000:lq=132:ct=00D5:ed=810CCAC2:id=0:ba=3060:te=1090:a0=2467:a1=709
::ts=2287

  • rc: 中継機のSID(中継していない場合は0x80000000)
  • lq: LQI
  • ct: 続き番号
  • ed: 子機のSID
  • id: 子機論理デバイスID
  • ba: 子機の電源電圧
  • te: 温度(℃)×100
  • a0: AI1(mV)
  • a1: AI3(mV)

なおSensor Modeの設定値は以下の通り。

センサーNo. センサー 固有パラメータ
0x10 アナログセンサー なし
0x11 LM61(アナログ温度センサー) 温度にかけるバイアスを設定します。1℃上昇させるには100に設定します。値域は-32767~32767の間で設定できます。
0x31 SHT21(温湿度センサー) なし
0x32 ADT7410(温度センサー) なし
0x33 MPL115A2(気圧センサー) なし
0x34 LIS3DH(3軸加速度センサー) なし
0x35 ADXL34x(加速度センサー) 「ADXL34xの動作モードとパラメータ」を参照
0x36 TSL2561(照度センサー) なし
0x37 L3GD20(ジャイロセンサー) なし
0x38 S11059-02DT(カラーセンサー) なし
0x39 BME280(温度、湿度、圧力センサー) なし
0x3A SHT3x(温湿度センサー) なし
0x3B SHTC1(温湿度センサー) なし
0x61 MAX31855(温度センサー) なし
0xD1 複数I2Cセンサモード 設定についてはこちらを参照してください
0xFE 押しボタン パケットを送信するタイミングを設定します。
0:DI1(DIO12)の立ち下がりを検出する
1:DI1(DIO12)の立ち上がりを検出する
2:DI1(DIO12)で立ち下がり、DI2(DIO13)で立ち上がりを検出する
4:TWELITE SWING用設定(起動後ただちにパケット送信し、スリープを行わない)

※ 1に設定したときは DI1 のプルアップが停止されます。

 

I2CデバイスとしてATD7410を接続してみた。

::ts=3158
::rc=80000000:lq=132:ct=002E:ed=810CCAC2:id=0:ba=3050:a1=2467:a2=0701:te=2006
::ts=3159
::ts=3160
::rc=80000000:lq=141:ct=002F:ed=810CCAC2:id=0:ba=3050:a1=2467:a2=0701:te=2006
::ts=3161
::ts=3162
::rc=80000000:lq=141:ct=0030:ed=810CCAC2:id=0:ba=3050:a1=2467:a2=0701:te=2006
::ts=3163
::ts=3164
::rc=80000000:lq=141:ct=0031:ed=810CCAC2:id=0:ba=3050:a1=2467:a2=0701:te=2006
::ts=3165
::ts=3166
::rc=80000000:lq=141:ct=0032:ed=810CCAC2:id=0:ba=3050:a1=2467:a2=0699:te=2006
::ts=3167
::ts=3168
::rc=80000000:lq=141:ct=0033:ed=810CCAC2:id=0:ba=3050:a1=2467:a2=0701:te=2000
::ts=3169
::ts=3170
::rc=80000000:lq=144:ct=0034:ed=810CCAC2:id=0:ba=3050:a1=2467:a2=0701:te=2006
::ts=3171
::ts=3172
::rc=80000000:lq=144:ct=0035:ed=810CCAC2:id=0:ba=3050:a1=2467:a2=0701:te=2006
::ts=3173

ATD7410(Sensor Mode=0x32)のデータフォーマット以下のとおり。ちなみにこの実験時の室温はおよそ20℃だった。

  • rc: 中継機のSID(中継していない場合は0x80000000)
  • lq: LQI
  • ct: 続き番号
  • ed: 子機のID(MACアドレスの下8桁)
  • id: 子機論理デバイスID
  • ba: 子機の電源電圧
  • a1: AI1(mV)
  • a2: AI3(mV)
  • te: 温度(℃)×100

どうやらApp_Tagで温度測定ができそうだ。子機(DIP)のSleep Durを長くすればそれだけ省電力となる。

さて、これにソーラー電源管理ユニットをつないで様子をみてみる。

2024年1月20日 (土)

ゼロプレシャーICソケットに細いピンヘッダーを取り付けた

28ピンのゼロプレッシャーICソケットをブレッドボードに取り付けたくて作業した記録。

28ピンのゼロプレッシャーICソケットはそのままではブレッドボードに差さらない(ピンが短い)。ICソケットをアダプターにしようにもICソケットに差さらない(ピンが太すぎる)。で、細いピンヘッダー半田付けすることにした。

さすがにソケットにピンヘッダーに直付けは自身がないのでユニバーサル基板を介することにした。
Img06784_small

まずはICソケットをユニバーサル基板に半田付けする。この際、後からピンヘッダーを半田付けするため、ちょっと多めに半田を盛っておく。
Img06785_small

基板をクリップで固定する。
Img06786_hdr_small

ここからがミソで、ピンヘッダーに丸ピンICソケットを差しておく。これはピンヘッダーが半田ごての熱で溶けて変形したりピン抜けしたりすることを防ぐため。これをしないと大変なことになる。
Img06788_small

こんな感じにしてヘッダーピンをICソケットの半田付け部分に半田付けをする。
Img06790_small

ICソケットによって固定されているので半田ごてによる各ピン保持部分のプラスチック変形を防ぐことができる。
Img06793_small

もう一方も同様の方法で半田付けする。ICソケットのピンへのヘッダーピンの半田付けする側は揃えること。
Img06794_small

思ったよりもきれいに出来た気がする。
Img06796_small
Img06797_small

ブレッドボードに挿すにあたって、ICソケットを一段かませた。というのもちょっと幅がありすぎて配線の邪魔になったので。
Img06798_small

拡大鏡前提の作業になるが、コツがつかめれば出来ない作業では無い事がわかったのだ。めでたし、めでたし。

2024年1月16日 (火)

TWELITE DIP通信距離実験

先日製作したTWELITE DIP BLUEユニットにて子機ユニットと中継ユニット間の通信距離実験を行った。

通信距離レベルが分からなかったので、まずはスポーツ公園の400メートルトラックにて実験を行った。
子機を三脚に固定しグランドの東端に設置した。
Img06665_small1

子機ユニットを段ボールに貼り付けて、その段ボールを三脚のアタッチメントに固定した。
Img06666_small1

中継機ユニットとUSB親機(白いUSBモジュール)+PCを持ってグランドを端まで移動した。USB親機の受信性能は高くないようなので、長距離通信は子機ユニットと中継機ユニットで行い、中継機ユニットUSB親機は至近距離で通信する構成としている。
Img06661_hdr_small1
Img06662_small1

PCにてTWELITE Stageを実行し、子機ユニットからの信号を中継機ユニットで受信したうえで、その中継信号をPCのUSBソケットに接続してあるUSB親機で受信する。通信距離はおよそ267メートルで、子機ユニットと中継機ユニットの間の通信は良好に行われている様子だった。
Twelite_20240116211601

これならば木曽川越えが可能かもしれないと、子機ユニットを和村の河岸段丘に設置したうえでImg06671_small2

中継機と親機+PCを持ってこの子機が良く見える木曽川対岸の須原のJR線上の峠道(越坂)の途中まで移動した。
Img06669_hdr_small2

この距離で子機・中継機とのパケット通信は70%程度は成功している様子だった(TWELITE Stage画面上の受信パケットのスクロール状態で判断)。通信距離は854メートル。これは可也すごい!ことだと思う。Twelite_20240116212201

今回の実験はTWELITE DIP BLUE (送信出力 2.5dBm = 1.778mW) で実験したが、TWELITE DIP RED (送信出力 9.19dBm = 8.299mW)であれば1kmを越える通信は可也余裕があると予想される。

2024年1月12日 (金)

TWELITE DIPにU.FLコネクター取り付け

TWELITE DIPに専用ダイポールアンテナを取り付けるため、U.FLコネクターを半田付けした。

やりたい事はTWELITE DIP2つで、一つは子機、一つは中継機として構成し、子機と中継機の通信距離測定。この為、TWELITE純正の外付けダイポールアンテナをTWELITE DIPに取り付けたいわけ。

取り敢えずの完成形は以下。タッパーにいれて実験する。
Img06579_small

ケース壁に貼り付けてある長方形の板がダイポールアンテナ。
Img06586_small

このダイポールアンテナはU.FLコネクターでTWELITE DIPと接続するようになっている。けれども、自分がストックしていたTWELITE DIPは簡易アンテナ(マッチ棒)を取り付けるタイプでU.FLコネクターが付いてない。で、自分で半田付けすることにした。

とにかくコネクターは小さい。2mm角くらいだろうか。
Img06563_small

横にピンセットを置いてみると大きさがわかる(超~小さい)。Img065721_small

このコネクターをTWELITE DIPに半田付けするわけだ。
Img065731

コネクターを取り付けるパターンの内、①がセンター線、②から④が外被となる。コネクターが乗ると①と②は半田ごてが入れにくいので、①と②のパターンには半田を薄く乗せておいた。半田を乗せる前にフラックスも塗っておいた。
Img0657620
コネクターをパターンに乗せて、①のパターンとコネクタ端子を過熱して半田付けしコネクターを固定した。そのうえで②部分を過熱し、コネクターをパターンに半田付けした。③と④はコネクターが固定されてから半田付けした。①から④まで半田を薄く乗せておくのが良いかもしれない。というのも③に乗せた半田量がちょっと多すぎてソルダーウィックで半田を取り除いたりしたからだ。つまり、半田を後から盛ると半田量のコントロールが超難しいので、予めパターン上に半田を薄く乗せておくのが良いように思えた。

Img065761
③部分は余分な半田をソルダーウィックで吸い取った。

アンテナのケーブルを取り付けて完成。
Img065771

出来上がりはこんな感じ。
Img06578_small

半田付けが細かすぎて容易な作業ではないけれど、それほど難易度が高いという感じでもなかったが、コネクターパターンが小さすぎて(コネクターからのはみ出し量が少なく過ぎて)半田ごての小手先で半田を乗せるのに手間取った。

上記の2が中継機で3が子機となる。簡易的に中継実験を行ったが動いているようだ。次はスポーツ公園に行って距離測定実験だ。

2021年2月26日 (金)

TKinter afterメソッド:再帰的コールによる自動更新

GUIの表示を定期的に更新したくなるのはリアルタイムデータ処理では避けられない(と思う)。

GUI表示自体はTKinterで容易にできるようだけれど、それを定期的に更新する方法を調べて実装してみた。背景にあるのは、Pico+TWELITEによって定期的に取得する超音波距離センサー・データをGUI表示するためだ。

ここで使うのはTKinterが提供するafterメソッドだ。afterメソッドは、このメソッドコール後に実行するFunctionと、その実行までの待機時間をパラメータとして指定する。このFunctionとして、このafterメソッドを実行するFunction自体を指定すると再帰的なコールが実行される。つまり、指定した待機時間後のそのFunctionが繰り返し実行されるようになるわけだ。このFunctionにてGUIを描画すれば、定期ていなGUIアップデータ実現する。

class GUI(tk.Frame):

   def update(self):

      # GUIを描画するコード

      self.after(100,self.update) # 100ms後に自分自身を実行する。結果的にループ化する


if __name__ == "__main__":
   gui = tk.Tk()
   app = GUI(master = gui)
   app.update()  # updateをコールして再帰的コールをキックする
   app.mainloop() # 以後のイベント処理はmainloop内で実行される

ネット上に公開されている先人の知恵に学びながら作成した参考コードは以下からダウンロードできる。

ダウンロード - tktest04.py

また具体的な工作内容はこちらから参照できる。

aftetrメソッドを上手く使えばいろいろな事ができそうだ。

 

2021年2月17日 (水)

RaspiとTWELITEの会話の手助け

昨日悩んでいた事の一つがUARTのBaud Rate設定。

インタラクティブモードのSet UART Baudが38400になっているのでてっきりそうだと思っていたことが混乱の元だった。実際Raspberry Pi側のBaud Rateは115200に設定していて、これで通信が成立していたので???だった。今日、改めてモノワイヤレスのホームページを見ていると以下の記述があった。

Baudrate
BPS(Pin-20)でBaud Rateが設定できて、オープン状態(O)だと115200とある。G、つまりGNDに接続すると38400とある。今は無接続なので115200なわけだ。ちなみにインタラクティブモードで設定するのはGの時のBaud Rateのようだ。これで謎が一つ解けた。

もう一つ悩んだのがApp_Uartでシリアル通信モードになっているTWELITE DIPからのパケットはMONOSTICKは受信できるけれど、その逆方向でMONOSTICKから送ったパケットがTWELITEのUARTのTXに出力されないこと。理解が正しいのか分からないけれども、これは出来ないとの結論に落ち着いている。

そもそもシリアル通信モードで送信されるパケットには宛先もコマンドも含まれていない(ブロードキャスト)。例えばシリアル通信モードのTWELITEから送信されるパケットはこんな感じになっている。

:03002020202020203734333768

最初の03が送信元のDevice ID、その次が送信シーケンス番号で任意の値。ここではディフォルトの00が設定されている。それ以降はUARTに書き込んだ文字列で最後がチェックサムになっている。MONO STICKには出荷時のApp_Wingsが親機として機能している。これをシリアル通信モードのApp_Uartに置き換えれば通信するのかもしれない。でも、それをしたいわけではなくて、一般的な親機に対して複数のシリアル通信モードのTWELITEからシリアル通信モードパケットを送りたいだけなので、MONOSTICKのAppを書き換えることまではしなくていいのかなっておもった次第。

真偽はわかってないけれど、次のステップに進むにあたってはここまで確認できればいいのかなって思っている。

2021年2月16日 (火)

なかなか会話できないRaspiとTwelite

Raspberry Pi 4とTWELITEを会話させようとして一日終わってしまった。

Raspberry Pi 4 と TWELITEの接続は至って単純で4本繋ぐだけ。

Raspberry Pi 4 TWELITE
3.3V (pin-1) VCC (pin 28)
GND (pin-6) GND (pin-1)
TXD (pin-8) RX (pin-3)
RXD (pin-10) TX (pin-10)

しかし、これを通信させるのには一苦労した。おまけに理由は分からないけれどTWELITEを一つ殉職させてしまった。

分からなかったのはRaspberry PiのGPIOのUARTに信号を出力する方法。あと、TWELITEのアプリのApp_Uartが送出する信号フォーマット。

まず、Raspberry PiのSerialポート機能を有効化する方法は幾つかの書き込みがあった。それは以下コマンドを実行すること。

$ sudo raspi-config

ここで表示される画面で 5. Interfacing Optionsを選ぶ。
02161
次に P6 Serial を選ぶ。 
02162
ここでは<いいえ>を選ぶ。<はい>を選ぶとLinuxのコンソールアウトプットが怒涛の如くこのシリアルポートに流れてくる。
02163
結果的に以下の組み合わせ(login shellは禁止でSerialをイネーブルにする)に設定する。
 02164

ここからが分からなかった。どのポートにどのボーレートでデータを書き込むのか。
採用したのは以下のファイルの記述。これは上のraspi-configでlogin shellの利用で<はい>を選んだ場合にcmdline.txtに書かれる内容。ここではconsole=serial0, 115200 と書かれている。login shellで<はい>を選ぶと、GPIOのUARTに怒涛の如くコンソール出力が書かれて、それをTWELITEは送り続ける。この様子はMONOSTICKをTeraTermで観察しているとわかる。つまり、serial0を115200でオープンすればよいわけだ。
02165

で、以下のコードをRaspberry Piで動かしてみた

import serial

s = serial.Serial("/dev/serial0", 115200)
bs = '112233445566778899\n\r'
s.write(bs.encode())

結果はビンゴで、MONOSTICK側のTeraTermに以下が出力された。

:0300313132323333343435353636373738383939000043

Byte0はTWELITE DIPのDevice ID
Byte1は不明(親機のMONOSTICKのDevice ID=0だから宛先か?)
一番後ろはチェックサム
その前の2バイトの0000は不明

いずれにせよRaspberry PiのUART出力をTWELITEで送信することが出来た。

なお親機側は以下のコードで文字列化された16進数データをアスキー文字列に変換している。

import serial

s = serial.Serial("COM6", 115200, timeout=1)

try:
  while True:
    line = s.readline()
    line = line.decode('utf-8')
    if len(line):
      print("%s" % line)
      rdata = [line[i:i+2] for i in range(5,len(line)-6,2)]
      for x in rdata:
        n = int(x, 16)
        print(chr(int(n)),end='')
      print('\n')

except KeyboardInterrupt:
  pass

s.close()

明日ははMONOSTICK側からTWELITE経由でRaspberry Piにコマンドを送ろう。