TTLとCMOSのバイブル

古いデータブックを並べてある書架。
ロジック回路の基本は「モトローラ」(赤いの)と「TI」(黄土色の)の
本で勉強させてもらいました。


オペアンプやアナログ回路は「NS」の青い本ですな。

「おつまみ鶏皮 柚子こしょう風味」

もらいものでもらった肴。

むちゃ美味しかった。
どこで買えるのか、いくらくらいか？
ネットで調べると  ・・・あわわわ・・・　ムチャ高価！

いただいたところに「美味しかったでぇ」っとリクエストしておこう。

IEC60617で記述したRSフリップ・フロップ 74279

IEC60617での記述、キラいなんで寄りつかなかったんですが、
あれこれ見てますと・・・

まず、「NANDゲート」の基本。
ド・モルガンの変換でもって、正論理入力と負論理入力が
このように描けます。

左下のは「負論理入力のOR」。
実体は正論理のORの前にインバートをくっつけただけ。
でも、負論理入力になっても、入力信号の状態「Lが0、Hが1」
に対する結果(出力)は変わりません。
　　入　　入　　出
　　０　　０　　１
　　０　　１　　１
　　１　　０　　１
　　１　　１　　０

IEC60617での表記で「面白いなぁ」と思ったのが
NANDゲートを使った「RSフリップフロップ」。

通常は左のように描きますが、動作は右のように
「負論理のOR」で考えるほうが動きが見えます。

入力信号(Lアクティブ)の上側が優先で出力の状態が決まる
様子が、右の描き方だと目に浮かびます。

このRSフリップフロップが４組入ったのが「74279」。
データーシートにはMILでこのような表記。

入力信号名には「￣付」で負論理であることが示されていますが、
NANDゲートで描かれているので、絵を見て動作が直感的に判断
できるかどうか・・・
負論理入力のORゲートで描いてると分かりやすいのにと思っちゃ
うわけです。
このIC、/Sが二つあるゲートがあるんですが、この/Sの条件、
ANDなの？っと思ってしまうわけです。
負論理入力のORでゲートを表現したら「/Sは負論理のOR」で
あることが一目瞭然。
間違いようがない。

TIのデータシートにはこんな具合にIECでの記述が載っています。

左が入力。　右が４つの出力。
負論理での入力だということは分かるんですが、
/Rと/Sが同時にアクティブ(L=0)になった時、
「/S」入力が優先されるということがこの図だと
読めません。

CMOSの「4044」、これも負論理入力のRSフリップフロップ
ですが、これは「/R」優先です。
IEC表記では「真理値表」が無ければ、どうなるのかが
判断つきません。

JIS、IECの論理回路記号

ANDやORの論理記号について、ちょっとあれこれ話をしてました。
　※抵抗やスイッチなどはここであれこれ。
　　　「電子工作」のキホン
　　　「子供の科学」の回路図記号

今回は論理記号を掘り下げて。

NANDとNORをトラ技(MIL記号)と新JIS、IECで比べると・・・


この違いは、あちこちで紹介されていますが、入力を負論理に
するとどうなるか。
MILなら一目瞭然なんですが・・・


新JISだと、「＆」が「≧1」に。

さて、IECの場合の負論理記号はどうすれば？

JISの「まるぽち」のくっつき方だと「下」のほうかな
と思えるのですが、IECの矢印は信号の向きを示すという
ことで、上が正解。

通常、信号の流れは「左から入って右へ出て行く」ように
描くんですが、信号処理の具合で右入りで描きたいときも
あるわけです。
MILなら「出力側がすぼんでいる」ということで、ANDも
ORもINVも見た目が分かりやす。
でも、新JIS、IECはちょっとわかりにくい。
直感的じゃない。


ORの「1≦」は向きを示しているように見えるんで、なんとなく
信号の流れが分かります。
しかし、「＆」は直感から外れます。
そして、IECの矢印は信号の流れということで、まだまし。

ゲートの中にはこんなのもあります。
入力が2つあって、それを「AND」して、出力が正論理と
負論理で2つ。

出力が２つ存在するのがあります。
MILなら入出力間違いませんが、JISもIECも
「なんじゃこりゃ？」。
「▲1」は左右どっちがどっち(入出力)か直感で
分かりますか？

ということで、私の場合、死ぬまでトラ技方式(MIL)で
描かせていもらいます。

※追記：資料として
新JISやIECの論理記号、これをまとめてあるのが
TIのこの本。　
『標準ロジックIC　ポケット・データ・ブック』、
持っているのは1998年版です。

この付録ページに解説が載っています。




今回、あらためてこの資料を読んでみました。
負論理を示すJISの「まるぽち」とIECの「矢印」記号。
これは「表記方法が異なる」もんだと思ってたんですが、
【表2】の最初の4行を見ると・・・
　　「同じなん？」「どっちでもOKなん？」
と・・・
原文(英語か)を見てみないと。
はてさて。

オーバーフロー割り込みでの割り込み周期(周波数)計算

2020年2月4日：Arduinoのタイマー OCRレジスタは「n」じゃなく「n - 1」の値を設定せよ
てなことを論じました。
この時はコンペアマッチ割り込みで一定周期(周波数)の
タイミングを得ようというものでした。
同じようなことがオーバーフロー割り込みでも言えるのです。

8ビットタイマーでのオーバーフロー割り込みの発生タイミングは
「255の次」のクロックです。
その時にTCNTの値を書き換えて、所定の周期を得ます。
こんな感じになります。

・オーバーフロー発生タイミングは255の次のクロック
　　　：
　　 253
　　 254
　　 255
　　　 0　→ OVF発生 → TCNT書き換え
　　TCNT+1
　　TCNT+2
　　　：
TCNTを書き換えなければ255→0→1とカウントが進み
クロックの256倍の割り込み周期(1/256の周波数)が
得られます。

TCNTの書き換え値を「254」にすると、
　　　　255
　　　　 0　→ OVF → 254
　　　　255
　　　　 0　→ OVF → 254
　　　　255
　　　　 0　→ OVF → 254

255→254→255→254…と2クロックサイクルで割り込みが
発生します。
クロック数は「256-254」で得られ、設定数は「256-2」で
計算できます。

書き換え値が253の時は
　　　　255
　　　　 0　→ OVF → 253
　　　　254
　　　　255
　　　　 0　→ OVF → 253
　　　　255
　　　　254
　　　　 0　→ OVF → 253

「256-253」で3クロックサイクルで割り込み発生します。

さて、vabenecosiさんの簡易パルスジェネレータの製作（ソフト編）
この中に置かれているソースファイル：
　・2018/2/8　上記に加えてアイドル時の自動画面切り替え表示機能を追加　Simplified_PG_v5r4
をご覧ください。

#define tcnt2base 102　// timer2のTCNT2のBOTTOM値
　　　　　　　　　　　 // 102で約10ms(CK/1024)
ISR(TIMER2_OVF_vect) {　　…タイマー2のオーバーフロー割り込み
　TCNT2 = tcnt2base;　　　…102を設定
　t2ovfCnt += 1;
　if (t2ovfCnt >= timeout) {
　　timeoutFlg = true;　　　 // タイムアウトフラグをセット
　　t2ovfCnt = t2ovfCnt - timeout;
　}
}

このように10msの割り込み周期を得るのに、
「64usクロックで102」をTCNTに設定されています。
　　　※これだと、ちょっと狂ってしまうのです。
この設定102前後の様子を見てみましょう。

　クロックが64us=15.625kHzの時。
　TCNT設定値　　　 割り込み周期
　　254 (256-254)　2パルス　0.128ms 7.8125kHz
　　253 (256-253)　3パルス　0.192ms 5.208kHz
　　：
　　102　　　　　154パルス　9.856ms 101.46Hz
　　101　　　　　155パルス　9.920ms 100.81Hz
　　100　　　　　156パルス　9.984ms 100.16Hz
　 　99　　　　　157パルス 10.048ms　99.52Hz

15.625kHzから100Hz(10ms)を得るのですから
分周比の近似値は「156」。
ということは「256-156」で、割り込みの時に「100」
をTCNTに書き込まなくてはなりません。
102だと、10msより短い周期になってしまいます。

※テストプログラム　PB2～PB5ポートに観察用パルスを出してます。
　　・ダウンロード - test_tm2_ovf.txt

※インプットキャプチャーとオーバーフローのタイミングは
　　↓で出しています。
Arduino デューティー計測のためのインプットキャプチャータイミング

修理：オンボード・スイッチングレギュレータ回路

とある制御回路基板の修理依頼。
　　「電源が入らない」という故障内容。
AC100V供給のスイッチングレギュレータ回路が載っていて、
それが動いてません。
電源投入の一瞬だけ出力電圧が出るんですが、すぐにドロップ。

制御部回路に外から電源を加えるとマイコンや周辺が動き出した
んで、一安心。
電源部の故障だと判断できます。

長年稼働したスイッチングレギュレータ、故障原因のほとんど
がコンデンサの劣化。
AC100V入力の平滑コンデンサか出力段の平滑コンデンサ、これを
交換すれば動き始めることが多いかと。

でもダメでした。
どんな制御回路かと追いかけてみたら・・・
富士電機製の電源制御ICが使われていました。
型番が分かればデータシートが引っ張り出せます。
　　※便利な世の中です。

データシートのサンプル回路を見て「おっ」と気になった
のが、ICの制御電圧を供給している回路。
スイッチングトランスからダイオードを通って平滑して
ICのVCCに電源供給。
これを追いかけたら電解コンデンサが使われていました。






この小さなコンデンサ、これがアウトになってました。
交換で復活。
めでたしめでたし。

で、ここからが昔の話。
2018年9月20日：バッファロー WiFiルーター 「WHR-G301N」故障
この故障電源。
一次と二次の平滑コンデンサは正常でした。
この時の写真をよく見ると、もう一つ小さな電解コンデンサが
基板に載ってます。
この電源、ひょっとするとこれが悪かったのかも。
捨ててしまったんで、もう確かめられませんが、
今度、似たような修理が来た時は注意しておこうということで。

ダイソーの新型ニッ水電池：LEXEL社製 LOOPER

『で』は「でんでんタウン」ので　今冬はこの手袋で
この記事のコメントに、「ダイソーの新型のニッケル水素電池」の話が
出ていました。　　（ざっと1ヶ月前）
近所にあるダイソー(徒歩自転車範囲で2軒ある)で気をつけ
ていたわけなんですが、今日 ダイソー大今里店 で発見しました。
単3のを2コ買っておきました。

３つ作ってある「JIS C8708:2019充放電テスト回路」、今は
３つとも埋まってましてどれかの実験が終わらなくては次へ
進めません。
「AMAZON BASICS の60%放電」か「enevolt」の次でしょうか。
　　(650cycほど)　　　　　　　　　　(まだ70cycほど)
タミヤの「NEO CHAMP 950mAh」は頑張って欲しいし。

DHT11を使った出窓の結露対策用ヒータ制御回路 65%設定で

2021年12月20日のは「湿度60%」でヒーターをオンしていま
したが、電気代を抑える目的で設定を「湿度65%」にしてみま
した。

これでも結露は出ませんでしたので（夜中も、トイレに起きた
ときにチェック）しばらくこれで運転します。

ヒータがオンしてから次にオフする湿度、センサー(DHT11)の
性能、「最小桁が1%」ということもあり「3%のヒステリシス」を
設けてあります。
65%でオンしたら、オフするのは62%まで下がった時になります。
今回のグラフ「▼▼▼▼」のところでその様子が現れています。

※温度も湿度も出窓内、適当に置いたセンサーでの様子です。
　サーミスタを窓ガラスに接触させて、外の温度の影響を計って
　みると面白いかも・・・です。

リコー「GXR+S10」カメラ用バッテリ

リコー「GXR+S10」がやってきた　中古だけど
がやってきて、とくに問題なく使えてますんで、予備電池を購入。
「DB-90」という型番で1700mAh。
リコーの純正品にしました。

さっそく、その内部抵抗（充電後に）を測定。
　　・交流定電流方式で電池の内部抵抗を計ってみる

中古品に付いてきたのが「98mΩ」で新品購入のが「95mΩ」で
大きくな違いはありませんでした。

カメラ用リチウム電池、「そろそろあかんなぁ」となった
内部抵抗の上昇、オリンパスのE-520で使っている「BLM-1」が、
初期「150mΩ台」、それが12年で「220mΩ台」に。

リコーGX100の「DB-60」が7年で145ｍΩ→210mΩに。
今回のDB-90、今までのより内部抵抗がちょいと低くなって
います。
保護回路が違うのかなぁ。

フライス屋の気まぐれ「文鎮」 その2・・異形で

－－－【完売御礼】－－－

文鎮：ハンダ付け補助ツール の製造元、佐藤テック君が
「端材が見つかったんで」ということで作ってきてくれ
ました。


最重量級。 V字形溝の異形です。

　　重さ：855グラム
　　厚み：23mm
　　幅　：63mm
　　長さ：100mm

フライス仕上げの「鉄」。
　　　※油まみれ
　　　　塗装やメッキは無し
M5のタップ穴が5カ所。
　　（ハンダ付けに使うというより、アンビルがわりの用途かも）

お代は「2600円で」と。
　　（タップの穴あけが面倒だったんでと）

M5のキャップボルトとワッシャ、それにゴム板
を添付します。
　　※ゴム板はクリップ口に接着すると、部品を
　　　はさみこむ時に安定します。
　　※65mm幅のクリップはご自身で入手してくだ
　　　さい。

この一つだけ。 早い者勝ちです。
　　※クリックポストだと破損が心配なので
　　　レターパックライト(370円)でお送りします。

ご希望の方は、この記事にコメントしてください。
　　（匿名でかまいません）
連絡の付くメールアドレスを記入してください。
その後、私の仕事場からメールしますのでお届け先を
返信してください。
代金＋送料は到着後に振り込んで(振り込み先のメモを
同封します)ください。

フライス屋の気まぐれ「文鎮」 その1

・・・「シェフの気まぐれサラダ」なんてジャンルが
　　　　あるということで、それにならって・・・

－－－【完売御礼】－－－

文鎮：ハンダ付け補助ツール の製造元、佐藤テック君が
「端材が出たんで」ということで作ってきてくれました。

この一つだけ。　早い者勝ちです。
　　重さ：435グラム
　　厚み：15mm
　　幅　：57mm
　　長さ：65mm

フライス仕上げの「鉄」。
　　　※油まみれ
　　　　塗装やメッキは無し
　　　　六面の直角・平行はばっちしと
M5のタップ穴が２カ所。

お代は「1500円で」と。

M5のキャップボルトとワッシャ、それにゴム板
を添付します。
　　※クリップ口に接着すると、部品をはさみこむ時に
　　　安定します。
　　※65mm幅のクリップはご自身で入手してくだ
　　　さい。
　　※クリックポスト(198円)でお送りします。

ご希望の方は、この記事にコメントしてください。
　　（匿名でかまいません）
連絡の付くメールアドレスを記入してください。
その後、私の仕事場からメールしますのでお届け先を
返信してください。
代金＋送料は到着後に振り込んで(振り込み先のメモを
同封します)ください。

DHT11を使った出窓の結露対策用ヒータ制御回路 60%設定で

土曜日の朝からヒータオン湿度を「60%」にして、2日間記録
してみました。
開始時はなかなかの結露で窓の内側下部は真っ白に。

しばらくすると、結露が解消。
お昼になって暖かくなってきたということもあり、
時間軸7時間経過あたりで60%を切ってヒータが
オフになっている様子が見えています。
日曜の昼(時間軸30くらい)もヒーターの断続を
繰り返しています。
その部分を拡大すると・・・

湿度変化によるヒーターの断続制御が見えています。
青線の値、温度軸で3がヒーターオン。
0でヒーターオフで、1が制御出力はオンだけれども、
ヒータを仕込んだアルミチャンネルに接触させた
サーミスタが過温検出して、ハードで(コンパレータで)
ヒータをオフしている様子です。

制御湿度の設定、どのくらいで結露が消えるのかを
試してみなくちゃなりません。
　　　※電気代節約のため
とりあえず「60%」設定だと、結露ゼロということが判明。
今夜は「62%」にして試してみます。

※センサーの位置を自由にできるよう、50cmばかりの
　ケーブルを付けて制御回路と離すようにしました。
　今回は出窓の床から15cm、窓ガラスから20cmほど離れた
　ところに置いてみました。
　このあたりも、結露防止に影響があるかと。

リコー「GXR+S10」がやってきた 中古だけど

不調のリコーGX100 の代替機としてほぼ同じ撮影能力の
「GXR+S10」を入手しました。



左が現用GX100。　右がGXR+S10。
一回りでかい。

「レンズキャップなし」のが安価で出ていたので、買ってみました。
バッテリと充電器は付属。




件のGX100、メモリーカードの抜き差しも調子が悪く
なってきてます。
状況によってはピンセットが必要に。
メモリーカードを差し込んで、もう一押すと出てくる機構、
これが不調。
指先で引っ張り出せない時があるんです。

新しいカメラで、「ブツの接写」はできるようになりました。
時間があるときにでもGX100の解体を試してみます。

ISOを上げた時のノイズ、GX100よりずいぶんましな
感じです。
GX100でのISO400は非常用でしたから。

リコーのデジカメ「GX100」、ADJレバーの右が効かなくなったぁ

今日の夕刻、「ピコピコ・スイッチ」 の表示画面をGX100 で
撮ろうとした時・・・
ブラウン管画面なんで、露出を「Mモード」(F値、シャッター速度一定)
にしたら・・・
シャッター速度を設定する「ADJレバー」の「→」スイッチが作動不良に。
ADJレバーの「←」しか反応しなくなっちゃいました。



「←」だとシャッター速度がどんどん長く。
一周して戻るというふうにはなっていません。
困ったぞ・・・

オリンパスのE-520やE-M1mk2を持ち出すのもなぁ。
マクロレンズ、持ってないし。

『ピコピコ・スイッチ』制御回路

2021年12月13日：ひさしぶりのイベントだったけど・・・「ピコピコ・スイッチ」破損
2014年07月21日：イベント用ゲーム機「ピコピコ・スイッチ」、スイッチ破損！
モノを仕事場に持ち込んで、状態を観察。

スイッチ本体には「TKC」 という刻印。

これだけひどい目に会いながら、接触状態は非常に安定していました。

「ピコピコ・スイッチ」の制御ボックス、中味はこんなの。


マイコンは「AT90S2313」。
ATtiny2313の前身。

電源部を除いた回路図。
 
10MHzのセラロックがクロック。
表示と音出しにテレビを活用。

制御プログラムはアセンブラ。
ROM容量が足りなくて、EEPROM部にブザー報知音程データを
置いています。
　　・ダウンロード - pikosw1.zip

表示画面の様子
・電源オン

・スタンバイ

・開始　３秒間秒読み

・計測開始　10秒間

・結果表示

（NEC製9inchi グリーンモニターで）

enevolt単3(2150mAh) 新JISでの充放電実験開始

パナソニックeneloopスタンダード単3「BK-3MCC」60%(72分)放電 2800回で終了
で、JIS C8708:2019充放電実験回路のアキができたんで、
2021年10月21日：イジめるニッ水電池がやってきた。
の「enevolt 2150mAh(min 2100mAh)」のイジメを始めました。
実験回路に設定した電池の定格容量はminの2100mAhじゃなく、
大きな文字で書いている「2150mAh」で。

初回の0.2C放電(5時間率)から5回目の充放電までをグラフに
してみました。

初回ですんで、やってきたまま、未充電状態からの放電です。
電池に2021年3月の記述がありましたんで、9ヶ月放置と
いうところです。
放電0.2C(430mA)で、定格だと5時間=300分。
それが3時間18分=198分で放電終止電圧1.0Vに達しました。

その後の0.5Cでの放電は1時間45分くらいですんで、
定格容量の80%ほどになっています。

50サイクル目の0.2C放電がどうなるか、データが出るまで
もうちょいお待ちください。
　　※なにせ時間がかかります。

※＜電池あれこれ＞

DHT11を使った出窓の結露対策用ヒータ制御回路試験

DHT11を使った出窓の結露対策用ヒータ制御回路 、10日(金)に
完成したんで、2日間、出窓の中に放置してみました。
　　※まだヒーターにはつながず、
　　　制御は無しで
1分間隔でこんなデータがシリアルで出力されます。
それを記録。
　　 1　19.4　59.0 3
　　 2　18.9　61.0 3
　　 3　18.6　62.0 3
　　　　：
　3286　15.0　63.0 3
　3287　15.0　63.0 3
　3288　15.0　62.0 3
今朝、データを回収。

gnuplotでグラフに。
#gnuplt 5.2で
set term wxt 0
set grid
set colorsequence classic
set title "DHT11温湿度センサー テスト 2021-12-13"
set y2tics
set xrange [0:60] # 時間軸
set yrange [0:40] # 温度
set y2range [40:80] # 湿度
set xlabel "経過時間(時)"
set ylabel "温度(℃)"
set y2label "湿度(%)"
set grid
set xtics 6
set ytics 5
set y2tics 5
#set y2tics format "%3.2f"
set key right top
#set label "0.5C充電時間(分)" at 810,126
#set label "0.5C放電時間(分)" at 810,66
#set label "充電停止電圧(V)右目盛" at 810,36
#set label "2400サイクル目までの変化" at 1650,54
plot "h02.txt" using ($1/60):2 with lines lw 2 ti "温度(℃)" ,\
"h02.txt" using ($1/60):3 with lines lw 2 ti "湿度(％)" axes x1y2 ,\
"h02.txt" using ($1/60):($4*1) with lines lw 2 ti "on/off"

湿度データ(緑線)が1％単位なので、デコボコ。
湿度だけスムージングすると、なめらかに。
"h02.txt" using ($1/60):3 with lines lw 2 ti "湿度(％)" smooth bezier axes x1y2 ,\

ずっと暖かい天気が続いていましたんで、まだ結露は出ていません。
今週から寒くなるということで、今晩からヒーター制御を始めてみます。
ヒーターオンする湿度、とりあえず「70％」で試してみます。

ひさしぶりのイベントだったけど・・・「ピコピコ・スイッチ」破損

昨日、ひさしぶりの地域のイベントが小学校でありました。
いつもの時期だと「もちつき」なんですが「学校での飲食不可」
ということで、ゲーム大会なら子供達に楽しんでもらえるだろ
うと、PTAさんと地域の青少年指導員が協力。
昼過ぎから子供達と遊びました。
　　※マスクをしているということで
　　　「大声トライアル」 は×。

そんな中、イベントの途中で自作ゲーム機の一つが使えなく
なるというアクシデントが発生。
　　・イベント用ゲーム機「ピコピコ・スイッチ」、スイッチ破損！
これが2014年の夏。

この時はスイッチそのものの破損(戻らなくなる)でしたが
今回は樹脂ケース(家庭用の食材入れ)がアウトに。
　　（2011年から使っている）

子供達、叩き過ぎ。
左右のボタンを交互に押したら得点が入るという仕掛け。
実際は押すというより叩くという操作になっちゃいます。
競技時間は10秒。
10秒間に何回左右交互に「押せる」かを競うわけです。
左右交互にというのがミソで、同じボタンの2度押しは点に
なりません。
ウマい子は軽く100点を突破します。

イベントでの子供達の数、小学校の生徒数＋地域の子供達、
中学生もやってくるし、大人も「やらして」ですんで、
毎回300～400人には使ってもらってるでしょうか。

仮に1スイッチあたり50回の操作としたら、1日で2万プッシュ
くらいの回数になります。
それが10年分溜まって、ケースのほうが破損しちゃった
という次第でした。

Arduinoのスケッチ floatの乗算と除算の速度

DHT11を使った出窓の結露対策用ヒータ制御回路
このスケッチでちょい気になるところがあったので
確かめてみました。

420行目の
　　humi_w = d;　　　　　　　　 //湿度確定(wordで)
　　humi_f = (float)d / 10.0;　 // 0.1%で

436行目の
　　temp_w = d;　　　　　　　　 // 温度確定(wordで)
　　temp_f = (float)d / 10.0;　 // 0.1℃で

ここで整数値を1/10して0.1%あるいは0.1℃単位の
floatに湿度と温度を変換しています。
「1/10」するのに割り算を使ったわけです。
floatですので「* 0.1」という乗算でも同じ結果が
出ます。

しかし・・・実行速度が違うのでは？ っと気になり
始めたのです。
整数の演算では、乗算命令のあるATmega328Pが圧倒的に
有利です。
整数の除算、16bit÷16bitでもどうしても遅くなります。
割り込み処理の中では使いたくありません。
　　※1/2や1/16、1/64は右シフトで割り算が
　　　できるので高速処理になります。

さて、Arduino-UNOでのfloat、どんな具合かちょっと
確かめてみました。
こんなスケッチで
　　・ダウンロード - test_float1.txt

起動すると、
　　Num 1 2>　　 入力プロンプトが出ますんで、
２つの数値をスペースあるいはコンマで区切って
入力します。小数点、マイナスもOK。
例えば、
　　Num 1 2>234　0.1　　　　数値を2つ入力

1つ目に2つ目を乗じた値g1と、「1/n」した2つ目で
割った値g2(結果的にnを乗じてる)を出力します。

　　g1:23.4000 g2:23.4000　 乗算と1/nした値を除算

それをオシロスコープで見られるようにパルスを出力しました。
パルスはポートの直叩きでDigitalWriteのような遅延はありません。
この値だと、こんな具合。

乗算が10μS弱、除算が30μsちょいと約3倍の差がありました。
ということで、乗算に直せる切りの良い数字は乗算で、という
ことが処理時間の短縮につながります。

このスケッチ、1行入力した文字列から数値を分離するstrtok
の使い方あたりが何かの参考になるでしょうか。

//　1行文字受信処理
　　　　if(f_rxok){　　　　　　　　 // CR入力あり
　　　　　f_rxok = 0;
　　　　　n = 0;
　　　　　s = strtok(rx_bff, " ,");　　// 最初の文字分離
　　　　　while(s != NULL){
　　　　　　s_in[n] = s;
　　　　　　s = strtok(NULL, " ,");　　// 次文字分離
　　　　　　n++;
　　　　　　if(n >= 2)　break;　　　　　// 2文字まで
　　　　　}
　　　　　if(n >= 2){　　　　　　　　　 // 2文字ok ?
//　文字→floatへ
　　　　　：

分離した文字列は、文字列をコピーするのではなく、「nul」終端
され分離された元文字列の先頭アドレスをポインタとして記録し
ています。

DHT11を使った出窓の結露対策用ヒータ制御回路

出窓の結露対策用ヒータ制御回路 のセンサーがおかしなことに
なっているのに気付いたのが11月29日。
湿度センサー「DHT11」がやってきた・・・けど！？ を乗り越えて、
やっと回路と「スケッチ」が完成形に。
こんな回路に落ち着きました。


ユニバーサル基板に組んだ回路を密閉容器に入れてます。
センサーは外出し。

　　※前に作ってあった回路を手直ししただけ。
　　　ガラス窓越しですが、長い間日光に当たって
　　　いたんで、以前のケースはモロモロに。
　　　ひどい状態の写真を撮る前に捨てちゃいました。
　　　珍しい状態(現象出現に時間がかかる)はなんでも
　　　記録に残さないかんかなぁ。

DHT11が出すデータ列はそのパルス幅で1/0が決まります。
今回のスケッチは、その測定に0.5μs(2MHz)クロックにした
タイマー1の「インプットキャプチャ」機能を使いました。
↓エッジ間のパルス数から1/0を判断しています。

Lレベル50μsの後に、データが0なら25μsのHパルス、
データが1なら70μsのHパルスとなっていて、その中間の
100μs、タイマー1のクロック数で200を判断の基準にして
1/0を判定しています。

オシロで見たその様子です。

20ms幅の開始信号の後、DHT11からデータ列が出ています。
データ取得の間、割り込みは禁止していませんので、
1ms周期のタイマー割り込みとA/D変換割り込みは普通に
走っています。

データ列の終端付近を拡大してみると、

DHT11のパルス間隔は勝手にハード(タイマー1)がカウントし
てくれますので、ソフトは↓エッジが来るのを待つだけ。

Adafruitのライブラリだと、ソフトでループカウンタを回すので
割り込み禁止にしておかないと、カウント値が狂います。
インプットキャプチャを使ってのパルスカウントはこんな時に
ためにあるようなものです。

最後の方で、整数の湿度データをfloatへ変換をしていますが、
その処理時間がどんなものかが見えています。

さて、実際に出窓へ置いて試運転です。
センサーの寿命がどんなものかが気になります。

※現在のスケッチ(txtにしています)
　　　　ダウンロード - humidity3.txt

パナソニックeneloopスタンダード単3「BK-3MCC」60%(72分)放電 2800回で終了

パナソニックeneloopスタンダード単3「BK-3MCC」、
新JISの寿命測定で放電時間を60%(72分)にすると
どうなるかを試したましたが、今朝、2800回に到達。
これでこのテストを終わります。

充放電時間と充電終止電圧をグラフにしたのがこれ。

50サイクルごとに1.0Vまでの放電を行うので、その直後の
充電時間が長くなって赤線の飛び出しが現れています。

スタートが、
・2020年11月7日：富士通の白 HR-3UTC(1900mAh) 新JIS充放電実験1000サイクルで終了
この続きでしたので、1年と1ヶ月。
長かった。
　　テスト回路が自動でやってくれるんですが、
　　400サイクルごとにデータ保存をしなくちゃ
　　なりません。

先月は、充電での「偽の-ΔV」が出現していました。
・2021年11月18日：パナソニックeneloopスタンダード単3「BK-3MCC」60%(72分)放電で偽の-ΔV出現

これが新JISでの寿命試験。
・2020年10月10日：パナソニックeneloopスタンダード単3「BK-3MCC」新JISでの寿命実験終了
0.5C放電で元気なのは600サイクルあたりまで。
72分放電だと、2400サイクルあたりから劣化
（放電が72分の手前で終わる）が目立ち始めます。
ということは、サイクル数でざっと4倍になったわけ
ですが、放電容量が60%ですので、それだけで1.7倍は
増えてもらわなくちゃいけません。
ということは、寿命の延びはおよそ2.4倍というところ
でしょうか。

さすがのエネループ・スタンダード。
突然死せず、寿命を全うした感じです。

※参考
「放電深度を60%から100%にしたら寿命が10～15%に減る」

※＜電池あれこれ＞

焼け跡にプリントパターンが見える

不二サッシ製電動窓開閉コントローラの修理依頼。
あらま珍しい「8749」で制御されていました。

　　　ケースへの刻印から1996年製のようでした

故障原因は、電源部の焼損。
　　過大な電源電圧が加わった？
　　100V仕様なのに、工事のミスか事故で200Vを
　　入れてもたのような？

ひどいのがモータ駆動用の19V系。
LM317の周辺が焼損。

51Ωの抵抗がはじけてます。

ガラエポの基板が焦げてしまって、アラまな状態に。

部品を外して様子を見ると・・・
抵抗の周囲に信号線が走っていて、そのラインもろとも
焼失しています。

焼けの巻き添えを食って、6本の信号パターンが断線していました。

このままではつなげないので、信号線の入りと出の場所
をチェックして、焼けた部分でつなぐのではなく、
出入りの元をジャンパーすることで対処しました。
同一面のつなぎは良いんですが、基板の上と下をつながな
ければならない信号がありました。
基板サイズがケースギリギリなんで、ジャンパー線は基板の
外を回せません。
そこで、スルーホールに入ったハンダを抜いて、できた穴に
ジャンパー線を貫通させるという手法で対処。

「うまく動いた」とメールを頂戴して、一件落着。
手強い修理案件でした。

マイコンやモータ駆動回路が生きていたんでうまく
いったわけでして。
マイコンの信号とパワー段がフォトカプラで絶縁されて
いたんが幸いしたのでしょう。

湿度センサー「DHT11」がやってきた・・・けど！？

注文していた湿度センサー「DHT11」、届いたのはこれ。
「ASAIR」というメーカーのようです。


　・https://www.aosong.com/en/productslist-4.html
　・https://www.aosong.com/en/products-21.html

※前記事：出窓の結露対策用ヒータ制御回路

さっそくArduino-UNOで試運転。
　　ライブラリは使わず自前のルーチンで。
すると・・・いくつかの疑問が・・・

(1) DHT11の応答速度

「読み出し速度は1秒以上」なんて書かれてるページが
あります。
センサーとしての応答速度と通信速度とは違う
わけでして。
試しに0.2秒サイクルでデータを読み出してみました。
上がってくる5バイトのデータ、10進と16進で示します。

・加熱しながら0.2秒サイクルで読み出し
- 湿度-　-温度-　sum　---HEXで------
15　 0　40　 3　58　 0F 00 28 03 3A
14　 0　41　 2　57　 0E 00 29 02 39 …0.0 41.2℃
14　 0　41　 2　57　 0E 00 29 02 39　　 2
14　 0　41　 2　57　 0E 00 29 02 39　　 4
14　 0　41　 2　57　 0E 00 29 02 39　　 6
14　 0　41　 2　57　 0E 00 29 02 39　　 8
14　 0　41　 2　57　 0E 00 29 02 39　 1.0
14　 0　41　 9　64　 0E 00 29 09 40 …0.0 41.9℃
14　 0　41　 9　64　 0E 00 29 09 40　　 2
14　 0　41　 9　64　 0E 00 29 09 40　　 4
14　 0　41　 9　64　 0E 00 29 09 40　　 6
14　 0　41　 9　64　 0E 00 29 09 40　　 8
14　 0　41　 9　64　 0E 00 29 09 40　 1.0
14　 0　42　 6　62　 0E 00 2A 06 3E …0.0 42.6℃
14　 0　42　 6　62　 0E 00 2A 06 3E　　 2
14　 0　42　 6　62　 0E 00 2A 06 3E　　 4
14　 0　42　 6　62　 0E 00 2A 06 3E　　 6
　　※センサーのそばにハンダゴテを置いて加熱。
　　　湿度がえらい低く出てます。
「1.2秒」周期で湿度+温度データが更新されてました。
※追記
これ↑、私の勘違いを含んでいました。
6回のうちの5回はACK応答なしでタイムアウトエラーを
生じていました。
つまり直前に読み取ったデータを出力していたのです。
AdafruitのDHTライブラリではMIN_INTERVALとして2秒が
取られています。
その間の呼び出しは、読み出しは行わずに前回値を使うという
処理になっています。


(2) 0.1℃の桁まで温度が出てるぞ！

あちこちにあるDHT11のデータシート、湿度と温度のデータの
分解能、湿度が1％、温度が1℃と記されています。
しかし、このデータ列を見ると、4つ目のデータが「0.1℃」
の数字になっています。
　　（2つ目の湿度データは00が続く）
スケッチのサンプル、floatで処理しているようなんで、
分解能を気にしていないのか、はてさて。

(3) ライブラリはどうしてる？

よく使われているライブラリ「DHT.cpp」を見ますと・・・
DHT11はこんな処理に。

　　case DHT11:
　　　f = data[2];　　　　　　…3つ目が1℃桁
　　　if (data[3] & 0x80) {　　…4つ目のMSBがマイナス符号
　　　　f = -1 - f;　　　　　　…★1
　　　}
　　　f += (data[3] & 0x0f) * 0.1;　…4つ目の下位4bitが0.1℃

「0.1℃」が出ているのは間違いないようです。
で、★1のところに疑問。　データシートに出ていない、
マイナスの処理、これでエエん？

湿度が高分解能なDHT22の温度処理を見ると、

　　case DHT22:
　　　f = ((word)(data[2] & 0x7F)) << 8 | data[3];　★2
　　　f *= 0.1;　　 …3つ目が1℃で4つ目が0.1℃
　　　if (data[2] & 0x80) {　　…3つ目のMSBが1なら
　　　　f *= -1;　　　　　　　…マイナスに
　　　}

このDHT22のマイナス処理はなるほど。
★2の所、3つ目の8bitデータはちゃんとマスクしてあります。

ということで、温度がマイナスはどうなる？　が疑問です。


(4) 氷点下は？

実データを見るため、センサーをビニール袋に入れて
サンハヤトの「Q-REI」で冷やしてみました。
　　シリアル出力は2秒サイクル。

- 湿度-　-温度-　sum　---HEXで------
27　 0　 4　 9　40　 1B 00 04 09 28 … 4.9℃ 下降
27　 0　 4　 1　32　 1B 00 04 01 20 … 4.1℃
27　 0　 3　 3　33　 1B 00 03 03 21 … 3.3℃
27　 0　 2　 5　34　 1B 00 02 05 22 … 2.5℃
27　 0　 1　 7　35　 1B 00 01 07 23 … 1.7℃
27　 0　 0　 9　36　 1B 00 00 09 24 … 0.9℃
27　 0　 0　 2　29　 1B 00 00 02 1D … 0.2℃
28　 0　 0 133 161　 1C 00 00 85 A1 …-0.5℃ ★3
28　 0　 1 129 158　 1C 00 01 81 9E …-1.1℃
29　 0　 1 136 166　 1D 00 01 88 A6 …-1.8℃
29　 0　 2 132 163　 1D 00 02 84 A3 …-2.4℃
30　 0　 3 128 161　 1E 00 03 80 A1 …-3.0℃
　　　：　　：
45　 0　 2 132 179　 2D 00 02 84 B3 …-2.4℃ 上昇
47　 0　 2 129 178　 2F 00 02 81 B2 …-2.1℃
48　 0　 1 136 185　 30 00 01 88 B9 …-1.8℃
49　 0　 1 132 182　 31 00 01 84 B6 …-1.4℃
50　 0　 1 129 180　 32 00 01 81 B4 …-1.1℃
52　 0　 0 135 187　 34 00 00 87 BB …-0.7℃
53　 0　 0 132 185　 35 00 00 84 B9 …-0.4℃
54　 0　 0 129 183　 36 00 00 81 B7 …-0.1℃ ★4
55　 0　 0　 3　58　 37 00 00 03 3A … 0.3℃
57　 0　 0　 7　64　 39 00 00 07 40 … 0.7℃
58　 0　 1　 1　60　 3A 00 01 01 3C … 1.1℃
59　 0　 1　 4　64　 3B 00 01 04 40 … 1.4℃

温度が下降、上昇する速度から0℃付近の挙動が
見えてきます。
　(1) 3つ目と4つ目のLSBを加算してxx.x℃に
　(2) 4つ目のMSBが1ならマイナスに
ということでよさそうです。
しかし、★1の手順だと、「-0.1℃」を読んだときは、
「(-1 - 0) + 0.1」で「-0.9℃」になっちゃいます。

DHT11の0.1℃処理、後からデータが出ているのが
分かったんで付け足した感じでしょうか。
プラスのことしか考えなかったんで、それで、ミスを！

「ライブラリをうかつに信じたらアカンぞ！」っという
ことになっちゃいました。

DHT11の処理をこのライブラリでしたことがある方、
氷点下の処理を見直さなくちゃいけません。
1℃内で温度の上昇と下降が逆になってしまいます。


※こんなスケッチです　（完成形じゃありません）
　　・ダウンロード - test_hdt2.txt

タイマー1のインプットキャプチャ機能を使って
DHT11からのパルス幅を読んでいます。
　　※ソース、DHTとする所、間違ってHDTとなってます。
　　　次の手直しで直します。

～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
※追記　DHT11、氷点下の処理　（↑の★1）

　case DHT11:
　　f = data[2];　　　　　…1℃桁
　　if (data[3] & 0x80) {　…MSBがマイナス符号
　　　f = -1 - f;　　　　　…★1
　　}
　　f += (data[3] & 0x0f) * 0.1;　…下位4bitが0.1℃

おそらく・・・★1は最小桁が1℃の時の処理だったかと。

温度が降下して「 4　3　2　1　0℃」と来た次、
データが「0」のままマイナスになって「-0℃」
が出現します。
それを嫌って、「4　3　2　1　0　-1　-2」となる
ようにするための処理が「f = -1 - f;」だったと
推測できます。

それが、「0.1℃桁」まで出ているのが分かり
（DHT11の機能アップ？）、それじゃと追加したのが
　　f += (data[3] & 0x0f) * 0.1;

しかし、マイナス温度を考えていなかったのがミス。
DHT22と同じように、先に1℃桁と0.1℃桁を合成してから
マイナスを判断して処理しなければなりません。

気が付かない原因・・・
　　・昔からあるライブラリにミスは無いだろう。
　　・みんな、使っているし。
　　・動いているし。
　　・欲しいのは湿度。　温度はおまけ。
　　・DHT11で氷点下なんて使わないぜ。
　　・1℃桁が合ってればヨシ！

「現場ネコ」みたいになってきました。

※追記　　氷点下実験の様子

センサーをビニール袋に入れ、その上からQ-REIを噴射。

40.0% -19.6 28 00 13 86 C1
40.0% -19.7 28 00 13 87 C2
40.0% -19.7 28 00 13 87 C2
40.0% -19.8 28 00 13 88 C3
40.0% -19.8 28 00 13 88 C3
40.0% -19.9 28 00 13 89 C4
40.0% -20.0 28 00 14 80 BC
40.0% -20.0 28 00 14 80 BC 　最低到達点
　　　：
「-20.0℃」まで到達。　ここで数値が張り付きました。


※追記　氷点下の温度数値が★1の処理だと狂う様子

　正　　　　　　　　　　★1の計算方法
 1.9 [20 00 01 09 2A ]　　1.9　↓温度下降
 1.4 [20 00 01 04 25 ]　　1.4
 0.8 [21 00 00 08 29 ]　　0.8
 0.3 [21 00 00 03 24 ]　　0.3 プラスはok
-0.2 [21 00 00 82 A3 ]　 -0.8　マイナスがアウト
-0.6 [21 00 00 86 A7 ]　 -0.4
-1.0 [21 00 01 80 A2 ]　 -2.0
-1.4 [21 00 01 84 A6 ]　 -1.6
-1.8 [21 00 01 88 AA ]　 -1.2
-2.1 [22 00 02 81 A5 ]　 -2.9
-2.5 [22 00 02 85 A9 ]　 -2.5
-2.8 [22 00 02 88 AC ]　 -2.2　実際は0.2℃の変化なのに
-3.0 [22 00 03 80 A5 ]　 -4.0　1.8℃も飛んじゃっている。
　　　　　：
-2.3 [31 00 02 83 B6 ]　 -2.7　↓温度上昇
-2.1 [32 00 02 81 B5 ]　 -2.9
-1.8 [34 00 01 88 BD ]　 -1.2
-1.5 [35 00 01 85 BB ]　 -1.5
-1.3 [37 00 01 83 BB ]　 -1.7
-1.1 [39 00 01 81 BB ]　 -1.9　0.3の変化が
-0.8 [3A 00 00 88 C2 ]　 -0.2　　1.7に。
-0.5 [3C 00 00 85 C1 ]　 -0.5
-0.3 [3D 00 00 83 C0 ]　 -0.7
 0.0 [3F 00 00 00 3F ]　　0.0　0はok
 0.3 [40 00 00 03 43 ]　　0.3　プラス復帰でokに

こんな変化になるんで、0℃を中心に温度がゆっくり変わったとき、
「なんかマイナスがおかしい」と気づきそうです。

「センサーがおかしい」とか「回路がおかしい」「精度が出てない」
じゃなく、「ソフトがバグってる」というのがこの原因です。

　DHT11センサーで
　AdafruitのDHTライブラリを使って
　氷点下を計る
という条件なので、異常に気付くかどうか・・・微妙でしょうね。


※完成形へ
・2021年12月10日：DHT11を使った出窓の結露対策用ヒータ制御回路

※追記
・2022年3月10日：温湿度センサーDHT11、ライブラリを使うと氷点下の温度がおかしくなるぞ！

湿度センサー駆動回路 「センサ・インターフェージング No1」から

抵抗値変化型の湿度センサー、手持ちの本の中に資料はないものか
と探しましたら、出てきました。

CQ出版 トラ技別冊「センサ・インターフェージング No1」。

1982年の本。　書架に眠っていました。


「湿度センサ活用編」という章があって、当時のセンサーなど
があれこれ紹介されています。
今のように、湿度・温度がデジタル値として出てくるのは
無く、アナログ値。


ちょいと関連しそうな回路をピックアップしてみます。

・ダイオードで対数変換。


・コンパレータでレベル分けして湿度警報表示


・抵抗値変化を周波数変化に

　　※先日の三角波発振回路と同じ

・単電源回路で


抵抗値変化型の湿度センサー、40年前でも考え方は
同じだっということを再認識。

タクトスイッチを押してみる …何万回も その5 続き

2021年12月2日：タクトスイッチを押してみる　…何万回も その5
で、オムロンのB3F-1062を押し始めました。

今朝、仕事場に来たら72万回ちょいで停止してました。
新しいスケッチでは
　　・デジタル入力オフ検出1回で異常停止。
　　・接触状態見るA/D値の記録は、2以上の時に
　　　リングバッファに記録。
　　・リングバッファの大きさは1365個でF-RAMに記録。

今回記録していたのは、310個で
2以上のA/D値は全数記録していました。

グラフ化するとこんな具合。

36万回と46万回あたりに大きくなったA/D値が出現。
しかし、「デジタル入力オフ」という異常事態は
起こっていませんでした。

その後、順調に「押し」が進みます。
しかし、72万4千89回目で、前触れなしに「オフ」が発生。
数値で見ると、こんな具合です。
左側がサイクル数。
右がA/D値。　オフだとA/D値フルスケールに。

　　：
　465137　　4
　465143　　3
　465205　　6　　　　前徴なく、
　724089 1023　 1　←突然オフに
　　　　　　　　　新しいスケッチは1回
　　　　　　　　　だけで異常停止。
　724090　 11　　その後、走らせたら
　724091　110　　大きなA/D値が続く。
　724092　303
　724093　203
　724094　381
　724095　 12
　724096　 10
　724097　　4　　しかし、これ以降、
　724098　　0　　　「0」に復帰。
　　：

オフ検出で停止していたのですが、サイクルを
再開するとしばらく異常値が続いた後、再び「0」
になって、「まだまだっ」っという感じになっ
ちゃいました。

タクトスイッチの寿命、単純に「押す」だけでは
測れないようです。
湿気など、周囲環境の影響のほうが大きいのかも。

B3F-1062のスペックを見ますと、
　定格負荷　DC3～24V 1～50mA(抵抗負荷)
　接点材質　銀メッキ
　作動力　　1.47N
　耐久性　　30万回以上（1.47Nタイプ)
と記されています。

今回のテストでは、負荷はATmega328Pの内蔵プルアップ抵抗で
およそ30kΩ、0.17mA。
この負荷なら「金メッキタイプ(0.1～50mA)」を使えという
ことになるんでしょうが・・・

湿度センサーHS15P駆動回路・案

出窓の結露対策用ヒータ制御回路
　・・・結露の季節、早いこと修理しなくちゃなりません。

湿度センサーに、
　　■HS15P 湿度センサーの簡易動作実験■
を使ってみたいな(結露環境下でも長持ちしそう)ということで、
正確な駆動パルスをハード的に出すのに、こんなスケッチを
試してみました。
　　Arduino-UNOでワンショットパルスを出力

しかし、これ↑で回路を作るとなると、ちょいと大げさに。
　　■HS15P 湿度センサーの簡易動作実験 Arduino版■
ではこんな具合に、非常にシンプルにこんな回路構成です。

Arduino-UNOのマイコン、ATmega328Pの足にセンサーを
直付け。
余計な部品は不要です。

しかし「ワンショットパルス案」だと、こんな具合に
アナログスイッチやゲートICが必要になってきます。

 
一定時間、センサー抵抗を通してコンデンサを充電し、
その電圧から抵抗値を計算しようという目論見ですが、
センサーを交流駆動する必要から、流しただけと同じ
電流を反対向きに流しておかなくてはなりません。
それが２つのANDゲートです。

さらに、コンデンサを放電して、センサー両端をゼロボルト
にするアナログスイッチの駆動回路が必要です。
元の回路に比べると、ちょっとたいそう。

そんな中、あれこれ調べているとこんなページが見つかり
ました。
　　・http://einstlab.web.fc2.com/hum/hum2.html

センサーの解説に、こんな記述が。（改行位置を変えています）

　　対数変換を簡略化するため、過渡現象を利用した
　　湿度回路を見かけます。
　　発想としては素晴らしいのですが、残念ながら
　　致命的な問題があります。
　　それは、過渡現象を利用するために、直流を掛け
　　ていることです。
　　常にプラスの電圧のため、高分子が電気分解して
　　劣化します。マイナスの電圧がかかっていません。
　　そのため短寿命です。

センサーを通してコンデンサを充放電するわけですから、
+/-になっているのでは・・・っと。
センサーの寿命にどのくらいの影響があるのか。

あれこれ思うと・・・欲しいのはセンサーの抵抗値。
だったら、こんな発振回路を作って、センサー抵抗を
時定数にすればいかがだろうかと・・・

R2とR3の比をうまく選べば、「t = C・R1」で周期が
出てきます。
コンデンサを0.1μFにすれば、
　　1MΩで 100ms = 10Hz
　　100kΩで10ms = 100Hz
　　10kΩで 1ms = 1kHz
　　1kΩで 0.1ms = 10kHz
　　500Ωで0.05ms = 20kHz
数十kHz～1Hzの周波数カウンタ(あるいは周期測定回路)
を用いれば、センサーの抵抗変化範囲をカバーできるの
ではないでしょか。
　　※抵抗値の小さい所(高湿度)では、コンパレータ出力の
　　　駆動能力と積分回路に使うOP-AMPの周波数特性で
　　　制限が出てきます。

出窓の結露対策用ヒーター制御回路の復旧、早くしなくちゃ
なりません。
12月4日にコメントしましたように、
湿度センサー「DHT11」を手配しました。
取り急ぎ、DHT11で復旧する予定で、「HS15P」のあれこれは、
また今度にということにします。

タクトスイッチを押してみる …何万回も その5

こんな回路に落ち着きました。

オムロンのタクトスイッチ「B3F-1062」を付けて
「押してみる」を始めています。


　　ボタンとの間隔、この写真↑よりもうちょい
　　縮めて(接近させて)います。

・タクトスイッチを押してみる　…何万回も その4 続き
・EEPROM、 2kバイトと4kバイトの間には壁がある　(24LC16で)
・EEPROM I2Cのクロックを早くすると・・・

接触不良はプルアップ付デジタル入力のon/offで
見ていますが、接触状態(接触抵抗)はA/D入力を記録します。
そのためのメモリーがF-RAM。

FM24C64。　64kビット。　8kバイト。
リングバッファにして直近の1365データ記録できます。
　　on/off回数4バイトと2バイトのA/D値で
　　6バイトが1データ。

こんなスケッチです。
EEPROM、F-RAMアクセスの所が参考になるかと。
　・ダウンロード - sw_life_test4.txt
　　　　（テキストファイルにしてます）

『元素創造』93～118番元素を作った科学者達

図書館で借りてきた本。
　　・元素創造　93～118番元素を作った科学者達

著者　キット・チャップマン
翻訳　渡辺 正

原題が、
　　Superheavy: Making and Breaking the Periodic Table

元本の表紙のほうが良いような。


むちゃ面白いです。
内容紹介は、ネットの検索でどうぞ。
例えば、紀伊國屋書店

・元素命名競争
・不正
・核種採取のためキノコ雲に突入したジェット機

Arduino UNOでワンショットパルスを出力

出窓の結露対策で使う「湿度センサー」 をあれこれ調べていて、
『高機能なものより単純なもののほうが良いのではないか？』
っと思い始めました。
ネットを探しますと、センサーのから湿度を引き出す手順を
丁寧に解説されていたのが、このページ。
　■HS15P 湿度センサーの簡易動作実験■
　■HS15P 湿度センサーの簡易動作実験 Arduino版■

・湿度でセンサーの抵抗値が変化。
・センサーに直流を加えるのは×。
　　　1kHzくらいのACで測定と
・湿度による抵抗値の変化が大。
　　　数百Ω～数メガΩ
・温度による補正が必要。

示されている回路では、センサーにコンデンサを直列につなぎ、
その充電時間とコンデンサ両端電圧から抵抗値を測定しようと
いうもの。
充電時間を変えることで、大きなレンジ幅が得られます。

Arduino用のスケッチを拝見しました。

気になったのが充電時間を決めているタイマーの処置。
Arduinoのソフトウェアタイマー「delayMicroseconds()」
を割り込み禁止状態で使われています。
パルスの出力(実際にはハイインピーダンスとH/L出力の切り替え)
も digitalWrite() と pinMode()。
　　　※回路は簡単になります。
これでは「遅く」なってしまい、私の好みの処理ではありません。
delay()やdelayMicroseconds()を使うと、
その待ち時間の間は何もできませんから。

必要なのは正確な時間のワンショットパルス。
そこで、ちょっとトライ。
・ATmega328Pのタイマー1を利用して、ハード的に
　パルスを発生させる。
・タイマー1のOC1A出力を用いる。
・設定範囲は1μ秒単位で最大4,096,000μ秒。

昔々のタイマーIC、8253や6840では簡単にできた
ワンショットタイマー、ATmega328Pではちょいと面倒です。

こんな考え方です。

使うレジスタはTCNT1、OCR1A以外にこれらを駆使します。

・クロックの停止とプリスケーラの設定


・OC1A出力のH/L設定


・OC1A強制出力　（コンペアマッチを待たずに出力）

・プリスケーラのリセット

こんなパルスが得られます。

4000μ秒まではプリスケーラ無しで16MHzをカウント。
それより長いパルスはプリスケーラを切り替えながら
16bitの範囲でOCR1Aレジスタでパルス幅を設定します。

この処理のメリット。
・パルス出力中も他のことができる。
・割り込みも有効。

サンプルスケッチはキー入力した値(μ秒)でワンショットパルス
を発生させます。

　　　・ダウンロード - pulse_tm1.txt
　　　　　　（テキストファイルにしてます)

出力中に新たな値を入れた時は、先のパルス出力を中断して
新しいパルスを出します。
「0」だと出力停止です。
定常的なパルス出力はPWMやアウトプットコンペアで出力
できますが、ワンショットとなるとなかなか面倒な手順に
なりました。

PWMではOCR1Aが2重バッファになり、即値での更新ができなく
なるので、ワンショットには使えませんでした。

湿度計回路に使うには、充放電のためのアナログスイッチを
外付けしなくてはなりません。
しかし、ハード的に正確な時間のパルスが使えるということで、
いかがでしょうか。