PIRセンサーは赤外線に反応しますが、そのPN接合部がESP8266WiFi無線波からの干渉を受け出力値が安定しない現象が生じます。解決策として、
- イベント発生時のみWiFiを有効とする。
- シールド+電解コンデンサ
- WiFi出力値のレベル制御
1.イベント発生時のみWiFiを有効とする。
WIFiのON/OFFを適宜実行します。
イベント処理終了後、切断—>ループ処理継続—>イベント発生—>再接続するようにします。
再接続
void WF_reconnect() {
wifi_set_opmode(STATION_MODE);
wifi_station_connect();
Serial.print("wifi connection status1: ");
Serial.println(WiFi.status());
yield();
}
切断
void WF_disconnect() {
wifi_station_disconnect();
wifi_set_opmode(NULL_MODE);
Serial.print("wifi connection status2: ");
Serial.println(WiFi.status());
yield();
}
2.シールド+電解コンデンサ
PIRセンサーに座金を嵌めこみます（PIRセンサーの真下にESP8266を配置した場合に限ります）。
ESPの電源ラインに470μF以上の電解コンデンサを追加します。（以下画像参照）
3.WiFi出力値のレベル制御
アイドリング状態とイベント発生時とでWiFi出力レベルを調整します（以下リンクを参照）。
http://bbs.espressif.com/viewtopic.php?f=7&t=1955
system_phy_set_max_tpw(82);
環境にも左右されると思いますが上記リンク先では82から1の範囲内で-18dBmから-45dBmまで変化したようです。
上記1のみの対策で効果が出ますが、WiFi再接続に時間を数秒とられるため、イベント発生の遠隔確認にも時間差が生じます。
以下関数WiFi.setOutputPower（）を使用します。
Arduino/libraries/ESP8266WiFi/src/ESP8266WiFiGeneric.cpp
WiFi.setOutputPower（）;
/**
* set the output power of WiFi
* @param dBm max: +20.5dBm min: 0dBm
*/
void ESP8266WiFiGenericClass::setOutputPower(float dBm) {
if(dBm > 20.5) {
dBm = 20.5;
} else if(dBm < 0) {
dBm = 0;
}
uint8_t val = (dBm*4.0f);
system_phy_set_max_tpw(val);
}
https://links2004.github.io/Arduino/d0/d52/class_e_s_p8266_wi_fi_generic_class.html
void ESP8266WiFiGenericClass::setOutputPower (float dBm)
set the output power of WiFi
Parameters
dBm max: +20.5dBm min: 0dBm
http://www.esp8266.com/viewtopic.php?f=32&t=13496#sthash.vQAh2bO6.dpuf
WiFi.setOutputPower(0); // this sets wifi to lowest power
WiFi.setOutputPower(20.5); // this sets wifi to highest power - See more at:
ESPモジュールのアンテナパターンとセンサ出力ラインとの距離やセンサ出力ラインに並列に1K-10K抵抗を挿入することで大きく改善するかもしれません。信号線はパワーライン、グランドラインとツイストして下さい。
WiFi.begin(); の直前に WiFi.setSleepMode(WIFI_NONE_SLEEP); を挿入、WiFiのスリープモード解除がPIRセンサへの周期的なノイズ除去に効果がある可能性があります。ただし消費電力と熱問題のためメーカは推奨していないようです。
https://github.com/esp8266/Arduino/issues/2330
I filled a bug report to Espresif (they offer a $2000 price for anyone who discover a bug in ESP modules, that is motivating blush) about those connectivity problems. After exchanging some emails and sending many wireshark packet captures, they suggested me to test the effect of WIFI_NONE_SLEEP, which actually worked. The problem is, they don’t recommend using this mode in which the wifi radio is always on, as the power consumption and heat increase a lot. In “normal” mode, the wifi radio wakes up every 100ms, wait for the router’s beacon for any packet pending to be received, and goes to sleep again. According to Espresif’s support, my Wifi network is “bad”, because 70% of the beacons are lost and that is the cause of the connectivity problem: there are packets (such as your ping tests) waiting but they are never received by the ESP due to the beacons being lost. That should be also the reason that WIFI_NONE_SLEEP solve the problem, as the wifi radio is always on and more beacons can be received. However, I don’t believe that a “bad” network is the problem. I have tested THREE routers so far, in different channels, and I live in a detached house with very little interferences from neighbour’s wifi networks. The ESP modules loss connectivity in all cases, even with a very strong signal from the router just one meter apart. It is a weird problem, and the router firmware and the sleep mode do have an influence, somehow.
https://github.com/FastLED/FastLED/issues/367
Maybe i found one issue with the ESP. I have tried a lot of solutions to reduce the problem with jitter. Nothing seems to work, even the three commands
FASTLED_ALLOW_INTERRUPTS 0
FASTLED_INTERRUPT_RETRY_COUNT 0
INTERRUPT_THRESHOLD 1
to reduce problems with interrupts didn't seem to work.
So what to do is reducing interrupts or the time interrupts need to complete.
The solution for me is to set the wifi.sleepMode to WIFI_NONE_SLEEP. The default value from the SDK is WIFI_MODEM_SLEEP, which will set the modem to sleep between two beacons from the ap. So if there is an interrupt from the wifi core to respond to the ap's beacon to hold the connection.
My idea is, that if the modem is in sleep mode, it needs much more time to wake up and respond to the beacon. So i disabled the sleep mode and the jitter got reduced, but you will have a higher power consumption.
