PATHpilotのブログ

IC-705のVBUSに接続されている過電圧保護用ツェナーダイオードが焼けてしまった。焼けちゃったらダメだろーって思うんだけれど。

ちなみに、リペアセンターによると焼けたツェナーダイオードは以下とのこと。
ダイオード：1SMB5920BT3G
ツェナー電圧：定格6.2V

つまり6.2V以上がVBUSラインに加わると焼けるそうだ。これは困る。なので過電圧保護回路を入れたい。

ツェナーダイオードの電圧と電源供給電圧をLM358で比較し、MOSFETをスイッチングする。MOSFETのオンオフをするトランジスタは汎用トランジスタの2SA1015だ。LEDをON/OFFする2SC15815とはコンプリメンタリな関係のトランジスタだ。回路としてはコンパレータとMOSFETにスイッチングトランジスタと、非常にシンプルな回路となっている。ツェナーダイオードを切り替えることにより、5Vラインと13.8Vラインの両方に対応できるようにした。

この回路をベースに作業を進める。なお、ツェナーダイオードからDC IN＋への接続に20KΩと1KΩがパラレル接続になっている理由は本文後半に記載している。

スイッチングトランジスタとして2SJ555をつかう。2SJ555のオン抵抗が0.017Ωととても小さいためで、損失が少ないから都合がよい。

ゲートソース間電圧を確認する。

15V時
ゲートソース間電圧　VGS ＞ 14V となるのでIDは無限大となる。
6V時
ゲートソース間電圧　VGS ＞ 4V となるのでIDは70Aとなり、問題なし。

次に、記事には無かったゲート抵抗を加える。必要となるデータはターンオン時の上昇時間またはターンオフ時の下降時間（どちから短い方）、ゲートチャージだ。

15V時
ゲートチャージ VGS=14Vで180nc
ターンオン上昇時間（270ns）とターンオフ下降時間時間では上昇時間が短いので、ターンオフ時により多くの電流が流れる。ターンオフ時の電流に合わせてゲート抵抗を求める。

電流値 = 180nc / 270ns = 0.67A
ゲート抵抗値 14V / 0.67A = 20Ω

6V時
ゲートチャージ VGS=4Vで40nc
電流値 = 40 / 270 =0.14
ゲート抵抗値 4/0.14 = 28Ω

以上より22Ωとしてみる。

パーツの配置を考える。配線が交差しないように、幾度かリトライ。

配置が決まったのでパーツをセットして、電源ラインに1.6mm銅線を配置する。

出来上がった基板。
表側：

裏側：

負荷として10KΩを接続して遮断電圧の調整をしてみる。

9.1Vツェナーダイオード

コンパレータとして動作するオペアンプの出力が変化する時、つまり＋とーの電圧値が拮抗するところではオペアンプ出力が以下のようになることが分かった。

入力電圧：15.58V オペアンプ出力 LOW

入力電圧：15.70V オペアンプ出力 HIGH

この中間電圧では以下の波形となった。

入力電圧: 15.61V

入力電圧：15.62V

実際問題、このような電圧で入力電圧が安定することはないと判断されるので、特に問題ないと思う。

3.6Vツェナーダイオード

3.6Vツェナーダイオードの場合、VR50KΩの範囲では調整できなかった。というよりもツェナーダイオード電圧が3.6Vにならず、2.0V程度になっていた。調べてみるとダイオードがにツェナー電圧によりブレークダウンするため必要な最小電流として通常5mAから10mAの間の電流が必要のようだ。適当に抵抗を決めたのが良くない。そこで電源からツェナーダイオードに繋ぐ抵抗20KΩに1KΩをパラに接続（0.95KΩ）し、電流量を増やしてみた。6Vで約6mA流れる。

結果うまくいった。

ケースへの収納

ダイソーで買ってきた3個で100円のキッチンプラケースに基板を収納した。

この状態で、総抵抗5オームのセメント抵抗を取り付けて電流試験（約3A）を行った。セメント抵抗はかなり熱くなったけどMOSFETは特に発熱はしなかった。これはオン抵抗が小さいことが効いているんだと思う。

蓋をして定電圧電源に接続、この先はIC-705の外部電源端子に繋がる。
 

まぁ、良い感じで仕上がったと思う。

ヤフオク!で購入した16メートルアンテナマストを軽トラに取り付けてみた。

取り付ける前の荷台の様子。運転席後ろに取り付けてみる。

マストの根元固定部。合板に角材をコの字にネジくぎで固定し、その合板をM8のボルトで荷台に固定。ボルトには大型平ワッシャを入れてある。このM8のネジは荷台取り付けネジを外して、そのネジ穴に固定している。

ネジ位置は排水の為の段差があるので、12mmの合板を入れてある。

マスト根元を入れた様子。

マスト上部は軽トラの鳥居に、C型クランプで固定する。

C型クランプにはリピート型結束バンドで固定する。

軽トラの鳥居とC型クランプとの間に傷防止も兼ねて滑り止めのゴムを入れてある。

アンテナマストを伸ばした状態。

16メートル伸ばした状態。

根元部分や鳥居との固定部に若干の隙間があるので、固定を確実にするためにスペーサーを入れる予定。

その後は10メートル電線をマストに沿って固定し、7MHz 1/4λホイップの実験に移る予定。

移動用アンテナの基本形として、垂直ダイポールを作ってみた。

アンテナ自体はとってもシンプルなんだけれど、持ち運びを念頭に全体を仕上げるのはちょっと工夫が要る感じ。

アンテナはアルミ線を塩ビパイプにリピート型結束バンドにて固定し、BNC (J) Wターミナルを接続し、同軸ケーブルからの直接給電としている。

調整後のアンテナ総長は95cm。145MHzで短縮率0.98としても101cmと計算されるので、思いの外短い。

三脚に取り付けた状態。三脚は半分伸ばした位だが、それでも給電点地上高は2m以上ある。

この状態でのAA-1500によるSWRチャート測定結果が以下となる。ちょっと高め（アンテナ短め）となっているが、145MHzを中心にSWR<1.2は144.30から146MHzと運用上は特に問題がないと思われる。

とにかく構造が簡単なので、移動先でも調整することもなく（調整するにも出来ない）運用が可能というところがうれしい。

手荷物としてまとめた姿。

XR2206を使ったFunction Generator kitを作った。このICはFSKをサポートするのでその動作について確認した。

奥がKit、手前がFSK切替信号を発生させているPico。

このキットは中国製で、正弦波と三角波を生成するFunction Generator。少ない外付け部品で広範囲の周波数の信号を作ることができる。回路図は以下のとおり。キットの回路図にFSK実験用のR10とPICO接続端子、SINE出力のAC成分だけを取り出すようにC10を追加している。

このXR2206はTC1・TC2間に接続されるコンデンサーCとTR1（P7）とTR2（P8）のそれぞれに接続される抵抗値R6,7,8とR10によってそれぞれ2つの周波数を生成する。この周波数のどちかを出力するかをFSKコントロール端子（P9）によって選択する。発生する周波数は以下のとおり。

F = 1/RC

キットの回路図にR10を接続し、FSK制御信号として、Picoから8msecインターバルの信号を入力した。その結果が以下のオシロスコープ出力結果になる。

周波数の切り替えはスムーズだ。全く同期がとれていない2つの発信波形を切り替えると、切替時点でレベルが大きく変化するが、XR2206は波形のレベルが引き継がれている。これってどうやって実現するんだろう？？優れものだと思う。

アマゾンでオーダーしたNEO-7M GPSモジュールが中国郵便ePacketで届いた。PICO-TNCのGPSモジュールとして使えるか確認する。

届いたのはモジュール基板とアンテナモジュール、ピンヘッダー。

ピンヘッダーを半田付けして、RS232Cレベル変換モジュールを通してPCのコムポートに接続してGPSモジュールの出力を見てみた。

GPSモジュールは以下のテキストデータを1秒間隔で出力し続けている。

$GPRMC,013837.00,A,3540.78920,N,13738.11534,E,0.134,,150123,,,A*76
$GPVTG,,T,,M,0.134,N,0.248,K,A*2B
$GPGGA,013837.00,3540.78920,N,13738.11534,E,1,06,1.91,540.5,M,36.5,M,,*53
$GPGSA,A,3,25,32,24,10,23,12,,,,,,,3.20,1.91,2.57*09
$GPGSV,3,1,09,10,47,226,29,12,51,054,26,22,29,312,10,23,26,190,12*7B
$GPGSV,3,2,09,24,22,071,09,25,79,103,30,29,12,146,08,31,26,273,26*77
$GPGSV,3,3,09,32,61,324,29*48
$GPGLL,3540.78920,N,13738.11534,E,013837.00,A,A*6D

この出力内容の内、$GPGGAはプロトタイプで使っていたGPSモジュールが出力していた$GNGGAとフォーマットが同じであることが確認できたので、この出力をそのままPICO-TNCのコードに読み取らせた。

結果は良好で、PICO-TNCはビーコンを発生することができた。なお、NEO-7Mモジュール基板はGPSデータ出力時にLEDを点灯する。よって、このLEDの点灯でGPSデータ受信が行われていることが分かる。

NEO-7Mモジュールをプラケースにねじ止め固定した。

蓋を閉じる前の様子はこんな感じ。ケース内のスペースにはまだ若干の余裕がある。

蓋を閉じるとこんな感じになる。FT-70Dよりも一回りちょっと大きなケースとなるが、プロトタイプ1号機としてはまずまずの出来だと思う。

PICO-TNCとFT-70Dで近所を軽トラ（超低速）で走ってみた。Beaconインターバルは1分。プロットはいずれも移動経路上にあり、GPSとしては使いそうと判断した。

このNEO-7Mモジュール＋アンテナモジュールはアマゾンで850円程。送料が800円かかる。とりあえず追加で3個をオーダーした。

追記

このGPSモジュールは捕捉できるGPS衛星の数が５から8個程度のようだ。秋月で購入したGPSモジュールは、みちびきも捕捉できるので12個だった。つまりこのGPSもジュールはそれなりの誤差があるということだ。

$GPGGA,013837.00,3540.78920,N,13738.11534,E,1,06,1.91,540.5,M,36.5,M,,*53
$GPGGA,202824.00,3540.79166,N,13738.11552,E,1,07,1.55,510.8,M,36.5,M,,*59
$GPGGA,221438.00,3540.78683,N,13738.11710,E,1,08,1.10,513.7,M,36.5,M,,*52

実験をしている作業場所をGoogle Mapでみてみると35.67982（3540.7892）、137.63527（13738.1162）とでてくる。標高も30メートルは前後する様子だ。

PICO TNCのdemodulatorにおける信号処理を調べてみた。

demodulatorはADCデータを1バイト読み込み、ある値sumを出す。sumを算出するに当たってdemodulatorは以下の信号処理を行っている。

• Bandpass Filter 入力:adc  出力:val
• Digital Correlator (Delay) 入力:val  出力:m
• Lowpass Filter  入力:m  出力:sum

それぞれの処理後の値をプロットしてみた。

まずは全体像。それぞれの値に大きな差があるため、わかりにくくなっているが、mとsumの関係はわかる。

ADCデータ列

Bandpass Filterの出力。通過周波数は900Hzから2500Hz。これによってOffset成分がなくなる。

Delayの出力。DelayはMarkとSpaceのTone差を最大化することを目的としている。これにより、両Toneの分別がしやすくなる。ここでは446usのDelay値を積算することで1200Hzは正値、2200Hzは負値となるようにしている。一般的なDelayはDelay値を加算しているが、ここでは積算している。
  m=val[t] * val[t-446us]    なお、Sampling Rate =1200x11では6サンプル分遅延した値を積算している。

6サンプリング前の値を取り出す方法として、6エレメント（6サンプル）のリングバッファを使っている。リングバッファの場合、現在のポインタをtとすると、t+1は現在よりも5サンプリング前のデータが格納されている。t+2は4サンプリング前、、、、といった具合。なのでtは今から6サンプリング前のデータ格納されている訳で、その値を取り出してから、tに新しくサンプリングしたデータを格納する。こうすることで、過去のサンプリング値を取り出したあと、そこに新しいサンプリングデータを格納し、ポインターを一つ進める、という動作を繰り返すことで常に6サンプリング前のデータを取り出すことができる。

Lowpass Filterの出力結果。カットオフ周波数は1200Hz。プラス部分がSpace（2200Hz）、マイナス部分がTone（1200Hz）となってる。逆に言えば、この波形を取得するためにDelayを使っている。

レベル識別の閾値は以下のとおり

• sum <  - 4096 : bit=1 (Mark)
• sum >=  4096 : bit=0 (Space)

DIGITAL PLL

Ditigal PLLは11回で1 Time Domainを形成している。

• PLL Counter Step = 390,451,572
• PLL Counterは正値5回負値6回、または正値6回負値5回の合計11回で1 time domainとなる。
  
  • PLL Step 11回でbit decode
• 入力bitに遷移が発生した時にPLL Counterを25%調整する。
  
  • PLL Counter値が負値の場合は25％加算し、正値の場合は25％減算する。

このPLL Counter値の正負で25%加算減算するのがミソで、bit遷移が発生した時点でのPLL Counter値からPLL Counter値自体を調整し、遷移点とTime Domainの位置関係を保っている。

実験結果

PICO_TNCが発生するAFSK信号をPCに取り込み、サンプルコードでDelay（積算）とLowpass Filterを通してみた。

Beaconデータ：ダウンロード - mice7mono.wav

Delayコード：ダウンロード - dd_psude_stereo2.c

Delay後データ：ダウンロード - mice7mono_output.wav

LPFコード：ダウンロード - dd_lpf2.c

LPF後データ：ダウンロード - mice7mono_output_output.wav

AFSKの復調について大変参考になる情報があったので、その要約も含めて備忘録。

復調における課題：

• Low SNR
• Hight Twist -  Mark信号とSpace信号の大きな振幅差
• Phase distortion - Mark信号とSpace信号が符号境界に到達しない
• Inter-Symbol interference - Mark信号とSpace信号がPhase Distortionにより重なる
• Frequency Distortion - Tone周波数とData Rateとの大きな差
• No error correction - 1ビットエラーで破棄

Hight Twist対策

Digital Correlator

Comb Filter（自らの遅延信号によりその信号自体を増幅する手法）の利用。

Delayを最適化することでMarkとSpaceのTone差を最大化することができる。
Zero Cross Detectorを使ってアナログ信号をデジタル変換し、同じDelayをComb Filterに適用する。

テストでの入力信号は以下。ジッターを発生させる低周波成分が含まれていてこのままではZero Cross Detectorにかけられない。

1200Hz-2200Hzを通過させるBandpass Filterを通すと、低周波成分が除去できる、

Bandpass Filterを通した波形をZero Cross Detectorにかける。

Digital Comb Filterを適用する。Digital Comb Filterでは以下を実行する。

1. Zero Cross Detector出力をDelayさせた信号とXORを取る
2. 得られた信号に対してLow Pass Filterをかける。
3. 得られた波形に対してZero Cross Detectorをかける。

XORを取った信号波形

Cutoff 760HzでLowpass Filterをとおした波形

Lowpass Filterを通した波形に対してZero Cross Detectorをかける。

Clock Recovery

送信信号に対して、受信側のクロックを同期させる必要がある。そうしないと上記Bit Periodが得られない。

この為にTX Dlayがある。TX Delayで送られる信号でこのClock同期をとる。よってTX Delayはそれなりの長さが必要となる。

この過程においてCarrierシグナルからビット周期（パルス幅）を測定する。

クロック同期をとるためにDigital PLLをつかう。Digital PLLはジッター量を計り、そのジッター量により、Data Carrierに同期しているかを判断する。

ここでは、シンボル周期をサンプリング数22で測定している。この範囲で上記矩形幅によってPLLを遅らせたり、進めたりする。

ロック状態と判断するには、ジッター幅が1.1サンプル以内になった時、アンロックと判断するのはジッター量が4.4サンプル以上となった時。

APRSでのNRZI方式について備忘録

APRSはHDLCフレームをAX.25で転送するとの理解で考えると、APRSのTNCはNRZ-SpaceでEncode/Decodeしていると解釈される。

NRZ-Spaceはレベル遷移をゼロで行う。一般的なNRZIは1でレベル遷移実行となっているからここが大きな違いだ。

これについてはWikiwandに書かれている。以下がNRZ-Space部分の抜粋。

Non-return-to-zero space

"One" is represented by no change in physical level, while "zero" is represented by a change in physical level. In clock language, the level transitions on the trailing clock edge of the previous bit to represent a "zero".

This "change-on-zero" is used by High-Level Data Link Control and USB. They both avoid long periods of no transitions (even when the data contains long sequences of 1 bits) by using zero-bit insertion. HDLC transmitters insert a 0 bit after 5 contiguous 1 bits (except when transmitting the frame delimiter "01111110"). USB transmitters insert a 0 bit after 6 consecutive 1 bits. The receiver at the far end uses every transition — both from 0 bits in the data and these extra non-data 0 bits — to maintain clock synchronization. The receiver otherwise ignores these non-data 0 bits.

更に重要なのは赤字部分。1が5つ続いたら0を挿入すること。これを知らないとデコードが出来ない。

KENWOODハンディトランシーバー対応。トランシーバーはTH-K20、ちょっと（かなり）古い。

KENWOOD対応のヘッドセットのケーブル・ジャックを活用しようとして驚いた。ケーブルを切ったのはこのヘッドセット。

まぁ、幾分細いワイヤーがはいっているんだろうと思ったら、、、なんと超極細エナメル線を編んだワイヤーが4本入っていた。これはどうしたものやら。とりあえずカッターナイフで極細エナメル線の被覆を削り落としてクリップを付けて配線を確認した。

3芯ケーブルに半田付けし、熱収縮チューブでカバーした。

KENWOOD ハンディのスピーカーマイク配線は以下のとおり。

つまりMICラインとPTTラインは分けないといけない。ここがYaesuと違う所。そこで、ビーコン発生機のジャック端子の真ん中（Ring）にPTT信号を割り当てる改造を実施。

この結果、ハンディのスピーカーマイク端子とビーコン発生機に差し込むジャックとの配線は以下のようになった。マイク信号線はマイク端子（Tip）へ、MIC/PTT共通信号線はPTT端子（Ring）へ、PTT/GND信号線はGND端子（Sleeve）へ接続した。

これでとりあえず動くようになった。

しかし、トランシーバーから電波を出すとPicoが誤動作し、PTTが切れない。つまり電波が出っぱなしになる。この状態で今回作ったケーブルを手で覆い隠すと誤動作（PTTオン）が止まる。つまり、トランシーバーからの電波に対してビーコン発生機をシールドする必要がある。

Picoが誤動作している可能性があると思い、ケーブルのビーコン発生機ジャック根元部分にコアを入れてみたが効果なし。

今度はトランシーバー側にコアを入れてみた。こちらは効果があり、安定的に動作するようになった。ちなみにコアはFT-114-43、バラン用に購入してあったもの。

以上でKENWOOD Handy対応も目処がたった。

追加のノイズ対策

今回の誤動作はPTTがオンになりっ放しになるというもの。スピーカーマイクケーブルのトランシーバー側にコアを入れて改善したことから、このケーブルを介してノイズがビーコン発生機に入ってきていることが想像できる。そして、ビーコン発生機のPTT信号出力トランジスターを誤動作させているということだろうか。であれば、トランジスター自体にノイズ対策を施すことは効果がありそうだ。

それで以下の対策を施した。

Q1のベース・エミッター間にR3 10KΩ抵抗を入れた。この抵抗がない状態ではベースに入ってきたノイズ電流によってQ1が誤動作する場合が有り得るが、そのノイズ電流をGNDに流す役割をするのがR3になる。仮に0.01mAのノイズ電流がベースに入ってきたしても、10KΩに流れたとして電圧は0.1Vとなりベース・エミッター間飽和電圧（大体0.8V）よりも十分小さいのでQ1を動作させることはないがノイズ電流はGNDに流すことができる。

試しにコアを取り外してみたが、やっぱりコアが無いとPTTがオンになったままになる。ということで、上記R3の追加は決定的な対策にはならないことが判明。

PICO TNC製作の続編その２。

プロトタイプが完成した。

事前設定したインターバルで、ハンディ―トランシーバーのマイク端子経由にてMic-EフォーマットでGPSデータを送信することができるようになった。

PICO TNC コマンドの使い方

• mycall JA0WBT または JA0WBT-7  :  SSID有無どちらでもよい。mycallを設定しないとBeaconは出ない。
• unproto JA0WBT V WIDE1-1   :  Vの前はDestination Addressだが、ソフトウエア内部でMic-E形式のDestinationに上書きするようにした。なのでどんな文字列でも構わない。Vの後はデジパス１でNewパラダイムに従ってWIDE1-1を指定する。
• digi ON  : デジパスを指定しているのでONを指定する。
• gps $GNGGA   : プロトタイプに接続しているGPSモジュールのGGAフォーマットは$GNGGAと頭に付けてくるのでそれを指定する。これ以外のフォーマットタイプは今はサポートしていない。
• btext HelloWorld  : BeaconのInformationに付加する自由テキスト。
• beacon every n  : Beacon発生インターバル。n=1で1/6秒。最大360＝60分。
• PERM  : パラメータを設定したら実行。これにより設定したパラメータ値がFlashメモリーに保存され、パワーサイクルでも消えない。

以下がdispコマンド実行結果。MYALIASは設定しなくてもよい。

disp

ECHO ON
TXDELAY 100
GPS $GNGGA
TRace OFF
MONitor ALL
DIGIpeater ON
BEACON On EVERY 6
UNPROTO SUTPW8 V WIDE1-1
MYCALL JA0WBT-7
MYALIAS JA0WBT
BTEXT HelloWorld

OK
cmd:

送信されるパケットデータ

PICOの出力（トランシーバーのマイク入力）を入力（トランシーバーのスピーカ出力）にループさせてPICO TNCにて自分の出力を自分でデコードさせた。さらに実際にトランシーバー（FT-70D）のマイク入力に接続し、電波送信してI-Gateにて受信した。その受信した結果が以下：

17:43:53R JA0WBT-7>SUTPW8,WIDE1-1 Port=1 <UI C Len=24>:
`AB'l l[/`"9L}HelloWorld
17:43:53R JA0WBT-7>SUTPW8,WIDE1-1 Port=2 <UI C Len=24>:
`AB'l l[/`"9L}HelloWorld
17:43:55R JA0WBT-7>SUTPW8,WIDE1-1* Port=1 <UI C Len=24>:
`AB'l l[/`"9L}HelloWorld
17:43:55R JA0WBT-7>SUTPW8,WIDE1-1* Port=2 <UI C Len=24>:
`AB'l l[/`"9L}HelloWorld

I-Gateは2ポート設定しているので（1ポートにする方法がわからん）、同じ電波信号をPort1とPort2で2回取り込んでいる。最初のペアがPICO TNCが生成したフレームで、次のペアがPICO TNC内でループバックして再送信した信号になる。ループバックした信号はデジピートしたことになるのでWIDE1-1の後ろに＊が付加されている。

Digipeaterとしての機能

Digipeaterとしの機能を確認する。FT3Dからビーコンを送信し、それをFT-70Dで受信。FT-70DのSpeakerをPICO TNCの入力に接続し、MicをPICO TNCの出力に接続した。

結果は、FT3Dからのビーコン（上図①）はFT-70Dでビーコン再送（上図④）された。そのビーコンはFT3Dで受信することができた（以下写真）。一方、UI-VIEW32はFT3Dからのビーコン（上図①）は受信表示したが、FT-70Dからのビーコン再送（上図④）は受信表示されなかった。

考察として、UI-VIEW32はオリジナル信号を受信した後に、そのデジピート信号を受信した場合、それは受信表示しないのではないかと思われる。もしそれを許したら、同じ信号をデジピートの分だけ何度もI-Gateしてしまうから。一方、FT3Dは自分が発信した信号のデジピートであっても自分以外の送信機からの信号なのでそのまま表示したのだと思う。

UI-VIEW32のTerminalで確認したところ、上記の通りと判断できる。以下がTerminalの表示内容。3つ目のWIDE1-1に＊が付いているのでデジピートされた信号と判断される。デジピートしたのはPico TNCになるので、Pico TNCはちゃんとデジピートしているのだけれど、それをUI-VIEW32がInternetには送り出さなかったということだ。

19:34:21R JA0WBT-7>SUTPW7,WIDE1-1 Port=1 <UI R Len=17>:
`AB(l!m[/`"9l}_0
19:34:21R JA0WBT-7>SUTPW7,WIDE1-1 Port=2 <UI R Len=17>:
`AB(l!m[/`"9l}_0
19:34:22R JA0WBT-7>SUTPW7,WIDE1-1* Port=2 <UI R Len=17>:
`AB(l!m[/`"9l}_0

乾電池駆動について

この実験に際して、PICO TNCを単四乾電池2本で駆動した。5分インターバルで一晩ビーコンを出し、朝停波。その状態で実験を続けていたところ午後3時ころには電池がなくなった（Watchdog Timer Failure発生）。結構電力を消費している。

基板への実装とケースへの取り付け

ブレッドボードに作った回路を

この回路をユニバーサル基板に配置する。

実装が終わった状態。RS232CでPCでモニターする。

乾電池（単三2本）での動作確認。

ダイソーの3個100円のケースにいれる。RS232Cのボードもユニバーサル基板に実装した。

完成した状態。

この状態で持ち運んで軌跡確認を行った。

実験結果はまずまず良好で、基本機能が動作することを確認できた。