2021年01月30日

掃除機 吸引圧

今回は掃除機の吸引圧について事前検討した内容を少し紹介します。なぜ、掃除機の吸引圧を検討したかというと紙パックの容量を可視化できたら便利だと思ったからです。市販品の掃除機では紙パック詰まりを表示して交換を促す製品もありますが、定量的に紙パック容量を可視化しているものはあまりありません。

今回はマキタの掃除機CL107FDに新品の紙パックを使用した状態でダストボックス内の紙パックとファンの間に圧力センサを入れ込んで吸引圧を調べてみました。

圧力センサはST製 LPS22HHの評価基板を使用して、USBシリアルI2C変換基板でPCに接続して1秒周期でNode-Redからリアルタイムに可視化してみました。
cleaner.jpg

今回の掃除機は吸引パワーを3段階切り替え可能で標準→強→弱の順に切り替えてみました。


掃除機圧力_.jpg

標準で1012hPaから996hPaまで低下、強で993hPa、弱で1004hPaとなりました。まとめると標準で-16hPa、強で-19hPa、弱で-8hPaという感じです。


掃除機圧力2_.jpg

続いて標準状態で紙パックにごみが堆積して詰まったと仮定してノズル先端を手で押さえて検討してみました。標準の996hPaから987hPaまで低下し、-9hPa程度内部の気圧が低下することが分かりました。

実際の掃除では掃除機のモードによる気圧変化だけでなく、更に掃除機のノズル形状、絨毯かフローリングかで若干基準が変わります。圧力センサを入れるだけで容易に紙パック容量を可視化というのは難しいかもしれませんが、見込みはあることが分かりました。定常的な圧力だけでなく、圧力変化の勾配等、圧力センサを活用して面白いセンサを検討してみたいと思います。
posted by Crescent at 00:00| Comment(0) | 電子工作 | このブログの読者になる | 更新情報をチェックする

2020年12月19日

絶縁コンバータノイズ対策

今回は絶縁コンバータのノイズ対策について紹介します。絶縁コンバータは非絶縁コンバータに比べて、ノイズ対策に工夫が必要です。


非絶縁コンバータの場合、入出力でGNDが共通のため、主にディファレンシャルモードのノイズを考慮した設計が必要です。出力とGNDにコンデンサを並列に挿入したり、出力部にインダクタを直列に挿入することでディファレンシャルモードのノイズは容易に抑制することが可能です。なお、非絶縁コンバータの場合はコモンモードノイズはGNDや入出力を介してそのまま伝搬するため、入力段にコモンモードノイズフィルタを挿入して対策することが一般的です。

一方、絶縁コンバータの場合は当然ながら入出力でGNDが絶縁されているため、GNDが共通ではありません。GNDを入力と出力で分けることができるため、鉄道や自動車、産業用途などのノイズが多い環境下で多く使用されています。GNDが絶縁されているため、入力側のノイズを受けにくくなりますが、絶縁コンバータを使用すれば、ノイズの影響を受けない、ノイズが少ないという訳ではありません。絶縁コンバータに適切なノイズ対策をすることで絶縁によるノイズ抑制効果を発揮します。

dcdc_only_diff.jpg

絶縁コンバータに適切なノイズ対策とはコモンモードノイズ対策です。ディファレンシャルモードのノイズ対策は非絶縁コンバータ同様の対策で比較的容易に対策できますが、コモンモードノイズの対策はディファレンシャルモードのノイズに比べると容易ではありません。

絶縁コンバータは絶縁トランスを介して、入力側と出力側が接続されています。絶縁トランスが理想的にインダクタ成分のみであれば問題ありませんが、実際の絶縁トランスは入出力間に数10pF~100pF程度の静電容量を持っています。この静電容量と入力側のスイッチング(200kHz~1MHz程度)によってコモンモードノイズを発生させます。負荷や回路構成によって異なりますが、入力側のスイッチングが1MHz程度と高い場合であっても、コモンモードノイズに低い周波数(10k~100kHz程度)のピークが発生する場合があります。


コモンモードノイズは対象機器内部だけでクローズされた回路であれば、対象機器内部全体が揺れるため、比較的問題を受けにくい傾向があります。一方で信号を他の機器から受ける、他の機器へ信号を出すという場合には考慮が必要です。例えば、外部のセンサ信号を機器が受けて、増幅する場合にコモンモードノイズが影響します。外部のセンサ信号をアンプ(差動アンプでない)で増幅することで信号のインピーダンスとGNDのインピーダンスに差が生まれます。このインピーダンス差からコモンモードノイズがアンプ出力側にノイズとして表れることがあります。コモンモードノイズフィルタや差動アンプといった対策が必要です。電源系の至るところに様々な容量のコンデンサを追加してもノイズの現象が改善しないしない場合の多くはコモンモードノイズの影響が疑われます(それ以外は放射ノイズを受けている可能性がある)。外部のAC電源から入るノイズと切り分けをする場合は電池で駆動させてノイズを見ます。電池でもコモンモードノイズが発生する場合は絶縁コンバータがノイズ源か疑います。


このような絶縁コンバータによって生じるコモンモードノイズは下記のような対策で改善できる場合があります。回路設計や機器構成によってコモンモードノイズはノイズの出方や対策が異なるため、対策については参考に紹介します。

@絶縁入出力間のリターン回路
絶縁トランスの容量によって出力側に発生するコモンモードノイズに対して、リターン回路をつくることでコモンモードノイズを低減できます。具体的には入力側と出力側(もしくは基準となる端子)を数1000pFのコンデンサで接続させます。トランスの容量よりも同じor大きければコモンモードノイズ対策としては十分です。この容量を更に増やすと漏れ電流が大きくなり、ノイズ環境下で漏電ブレーカが頻繁に作動するといった不具合が発生します。この問題を防ぐため、数1000pF程度に抑える必要があります。また、コンデンサの耐圧は絶縁コンバータの絶縁耐圧に合わせた電圧を選定します。多くは1kV以上の耐圧を選択します。


dcdc_diff_and_simple_common.jpg

絶縁入出力間のリターン回路は入力側のスイッチング素子がない方と出力側のダイオードがない方を結合させます。絶縁コンバータの内部構成が不明な場合は必要に応じて両側にリターン回路を実装します。リターン回路は絶縁コンバータに可能な限り近い場所に実装します。


Aコモンモードノイズフィルタ
絶縁入出力間のリターン回路の対策@ではコモンモードノイズのピークを抑えることができますが、全体的なコモンモードノイズを低減させるためにはコモンモードノイズフィルタを入出力の両側に実装します。片側のみの場合はコモンモードノイズがもう片方から出てしまうため、両側かつ絶縁コンバータから近い場所に実装することが理想的です。


dcdc_diff_and_fully_common.jpg


コモンモードノイズは対策が難しく、発生源の特定も難しい場合が多々あります。ポイントはコモンモードノイズ対策が不十分な場合、絶縁コンバータ自体もコモンモードノイズの発生源になり得るということです。それらを踏まえた上で回路設計、ノイズ評価を行うとスムーズに対応できます。

posted by Crescent at 00:00| Comment(0) | 電子工作 | このブログの読者になる | 更新情報をチェックする

2020年11月28日

CO2モニタツール

以前にZMOD4410のCO2センサCO2センサの比較について紹介しました。その際に紹介したZMOD4410とHS3001を組み合わせた環境センサ基板はエアクオリティセンサ基板として専用変換基板を組み合わせてスイッチサイエンスで販売を開始しました。

今回はZMOD4410の応用事例として、現在、開発中のCO2モニタツールを紹介します。ZMOD4410とHS3001を組み合わせた環境センサ基板にOLEDとLEDを実装した基板を組み合わせてCO2の状態や推移を可視化できるツールです。

今後は家庭や事務所等の使用を想定して、下記のような機能を実装してみました。

・温度、湿度、CO2、IAQ(ドイツ環境庁屋内空気質基準)表示機能
・グラフ表示機能
・USBシリアルポートを介したログ出力機能
・夜間のOLED表示、LED点灯の輝度自動減少機能
・ボタン切り替えによるメイン表示項目切り替え機能


sensor_1.jpg

sensor_2.jpg

開発中のため、上部からピンヘッダが複数出ていますが、最終的にはスティック状にする予定です。今後は筐体となるフレーム設計やファームの作りこみを行い、来年以降に提供開始を検討したいと思います。ZMOD4410はファームウェアを入れ替えることでCO2以外にも臭気や硫黄といった状態を計測することが可能です。他の状態に対応したファームウェアの開発も行ってみたいと思います。エアクオリティセンサ基板と組み合わせて自作モニタツールをぜひ開発してみてください。
posted by Crescent at 00:00| Comment(0) | 電子工作 | このブログの読者になる | 更新情報をチェックする

2020年10月17日

STM32F3 FPU設定の注意点

以前にリンカライブラリ(*.lib)ファイルや静的ライブラリ(*.a)ファイル等のライブラリを追加する方法について紹介しました。その際にライブラリに合わせてFPUなしのMPUとしてビルドする設定について、STM32F3シリーズでの注意点について紹介します。

 プロジェクトファイルのプロパティを開き(Alt+Enter)、「C/C++Build」の「Settings」、「MPU Settings」内の「Floating-point ABI」を「hard」から「soft」もしくは「softfp」に切り替えます。「hard」、「soft」、「softfp」の違いは下記の通りです。

soft浮動小数点の演算に整数命令のみで構成された浮動小数点演算ライブラリ(soft-float)を使用
softfp浮動小数点の演算に浮動小数点演算命令(hard-FPU)を使用するが、floatを引数にする関数の呼び出しはsoft-floatと同じく汎用レジスタを使用
hard浮動小数点の演算に浮動小数点演算命令(hard-FPU)を使用し、floatを引数にする関数は浮動小数点レジスタを使用

softのみFPUを使用しません。一方、softfp、hardは内蔵のFPUを使用します。STM32Fシリーズの場合は「soft」を選択した場合は「Floating point hardware」を「No unit」に合わせて設定する必要があります。逆に 「softfp」、「hard」を選択した場合は「fpv4-sp-d16」のFPUを選択する必要があります。この設定をチグハグにした場合、Hard Faultが起動直後に発生し、マイコンが停止する場合があります。

FPU2.jpg

FPU1.jpg

STM32マイコンのシリーズによっては「Floating point hardware」で「fpv4-sp-d16」のFPUを選択した状態でも「soft」で動作しましたが、STM32F3シリーズではHard Faultになって正常に動作しませんでした(SW4STM32+STM32F3 V1.11.0環境)。シリーズやバージョンによっては挙動が異なるかもしれませんが、「Floating-point ABI」の設定と「Floating point hardware」の設定は合わせてした方が良さそうです。
posted by Crescent at 00:00| Comment(0) | 電子工作 | このブログの読者になる | 更新情報をチェックする

2020年10月10日

STM32 USB CDC注意点

STM32マイコンでUSBデバイス(USB_HSやUSB_FS)に対応している場合、CubeMX上で容易にUSB-CDC(Communications Device Class:CDCもしくはVirtual COM Port:VCP)を利用することができます。CubeMXの設定については今回は割愛しますが、CDCを利用する際に知っておきたい挙動、注意点について下記の3点を紹介します。

@usbd_cdc_if.cの関数ポインタ
Aバッファは割込み専用バッファ
B64byte以上のデータの送受信


@usbd_cdc_if.cの関数ポインタ
 CubeMX上で生成されてユーザがCDC機能を利用する場合、usbd_cdc_if.c内の関数を利用することになります。usbd_cdc_if.c内ではCDCの送受信の関数の他にバッファの初期化設定やCDCクラスの要求処理等の関数があります。これらの関数は関数ポインタで呼び出されるため、プロジェクト内で関数をgrepしても個々の関数は見つかりません。USBD_Interface_fops_FSでポインタが管理されています。そのため、usbd_cdc_if.cの関数の初期化や受信処理等の一通りの処理はCubeMX生成時点で既に実装されており、自動的に関数が実行されます。関数ポインタで管理、呼び出されるため、usbd_cdc_if.c内に安易に自作関数を配置することは避けたほうが賢明です。自作関数を置く場合、関数ポインタにも自作関数を加えて、さらに他のUSBライブラリとの整合を取る必要があります。関数ポインタの整合を取らないと関数が正常に呼び出されず、挙動がおかしくなります。

Aバッファは割込み専用バッファ
CubeMX生成時点で自動でバッファUserRxBufferFS、UserTxBufferFSが生成されます。このバッファは割込みorDMAのバッファとして使用されるため、ユーザー用途のデータバッファとして利用するのは避けた方が賢明です。バッファは受信時に読み込み、送信時の書き込みだけで利用します。このバッファは受信時はUserRxBufferFSにデータが入り、次の受信で自動的にクリアされて新しいデータが上書きされます。送信のUserTxBufferFSについても同様です。MX_USB_DEVICE_Init()の初期化の際にバッファの設定が有効化されます。CDC受信時のCDC_Receive_FS関数内のUSBD_CDC_SetRxBufferでバッファを再度設定していますが、例えば受信の都度、バッファをクリアやバッファの位置を変更、他のバッファに設定するといった自動で生成されたバッファに手を加えると2回目以降の送受信ができないといったCDCの不具合が発生しました。

B64byte以上のデータの送受信
USB_FSの場合、USBの仕様上、通信1回のデータサイズが最大64byteに制限されます。通常は相手側(通常はPC)ではデータの分割、結合が自動で行われるため、無理に独自規格で64byte以上に実装し直す必要はありません。一方、STM32マイコン側はデータの分割、結合の処理が記述されていないため、64byte以上の送受信をするとデータが欠落します。Aで少し触れましたが、CDCの通信バッファであるUserRxBufferFSとUserTxBufferFSは毎回の通信で自動的に上書きされます。例えば受信の場合は毎回上書きされるため、64byte以上のデータを受信した場合は64byteの端数(余り)のデータがバッファに残ります。

64byte以上を送信する際にはUSBD_StatusTypeDefを64byte毎にCDC_Transmit_FSを呼び出して、USBの状態を見てバッファが空になってから次の64byteを送信するようにします。

64byte以上を受信する際には下記のようにUserRxBufferFSとは別にバッファ(CDC_RxBuffer、CDC_RxBufferLen)を用意し、上書きされる前にグローバル変数の受信バッファにデータを退避させます。必要に応じてユーザープログラム側でCDC_RxBufferの読み出し、CDC_RxBufferLenのクリアなどの処理を行ってください。


//グローバル変数としての受信バッファ
uint16_t CDC_RxBufferLen=0;
uint8_t CDC_RxBuffer[2048];


static int8_t CDC_Receive_FS(uint8_t* Buf, uint32_t *Len)
{
/* USER CODE BEGIN 6 */
USBD_CDC_SetRxBuffer(&hUsbDeviceFS, Buf);
USBD_CDC_ReceivePacket(&hUsbDeviceFS);
memcpy(CDC_RxBuffer+CDC_RxBufferLen,Buf,*Len);//データ退避処理追加
CDC_RxBufferLen=CDC_RxBufferLen+*Len;//データ長さ処理追加
return (USBD_OK);
/* USER CODE END 6 */
}


STM32マイコンのCDCに関する記事は多くありますが、CDC機能を応用しようとするとCubeMXで生成された関数の挙動を理解する必要があります。その他にもUSBの接続状態やポートをソフトウェアで開いたタイミングの検知などもできるため、機会があれば紹介したいと思います。
posted by Crescent at 00:00| Comment(0) | 電子工作 | このブログの読者になる | 更新情報をチェックする