MQ7-esp/esp8266-RM370-interrupt

README ESP8266

Die aktuelle Implementierung ist für den ESP8266 vorgesehen.

Dabei wird per Interrupt eine Veränderung (FALLING) der LED Steuerleitungen überwacht. Zusätzlich wird an die Steuerleitung des Buzzers ein Ausgang gelegt. Optional kann der analoge Eingang zur Überwachung der Batteriespannung eingesetzt werden (Mindestens 200k Ohm Widerstand fehlen noch, dies hat aber rund 10µA (gemessen 6,96µA bei ~3,8V VBAT zur Folge). 3 volle LSD-NiMH kommen auf 4.4V ohne Last, nach Schottky-Diode 4.2V. Damit wäre vermutlich der geringe Ladestrom nicht übermäßig schädlich. Ein einfacher LiPo Akku mit Schutzschaltung dürfte ebenfalls hinreichend gut funktionieren.

Funktion	Pin	Default
rote LED	D7	High
gelbe LED	D6	High
grüne LED	D5	High
Buzzer	D2	High
GND	GND	-
VCC RM370	-	-
Batterie	A0	-

Durch die zwei Spannungsversorgungen und sowie unterschiedlichen VCC Rails ergeben sich in der Signalverarbeitung Probleme:

1. Die ESP8266 GPIOs sind nicht 5V tolerant (https://www.espressif.com/sites/default/files/documentation/Espressif_FAQ_EN.pdf Punkt 5.14)
2. Die Spannungslevel nach einem unidirectionalen LevelShifter sind falsch (https://www.espressif.com/sites/default/files/documentation/0a-esp8266ex_datasheet_en.pdf Kapitel 5.1)
3. Die Spannungslevel funktionieren wenn die Batterien an Spannung verloren haben und die V_USB des wemos D1 mini die VCC vom RM370 übernimmt
4. Wenn das Wemos D1 Board ohne Spannung ist, schweben die einzelnen GPIO
5. Eine Spannungsmessung der Batterien ist nicht möglich, da selbst ohne Batterien die Spannung ~4.2V beträgt

Die Lösungen sind vermutlich wie folgt:

1. Mit einem bidrectionalen Level Shifter kommt man auf passende Level
2. Siehe Punkt 1, vermutlich
3. Siehe Punkt 1 sowie den Rail vom RM370 mit 3.3V nutzen als Low Level [3.3V Rail vom ESP funktioniert auch]
4. Auswirkungen noch unbekannt
5. Spannungsteiler

Der Versuchsträger führt die Kabel nach unten hinaus, die wemos D1 mini Platine (3,5cm x 2,5cm) sowie der Logic Level Shifter (1,5cm x 1,5cm) passen auch auf den Batteriehalter innerhalb des Gehäuses. Problematisch ist die Kabelführung, da die Befestigungsschrauben das PCB ohne größere Spalte an das Gehäuse drücken. Wenn dünne Einzellitzen (z.B. wire wrapping wire 26AWG) genutzt werden, so können diese durch die vorhandenen Löcher der JTAG-Header gezogen werden. Alternativ kann je nach Stärke auch an der Platine zur LED Seite bzw. beim Buzzer nach oben hin Kabel durchgeführt werden.

Mittels Diode (1N400X) kann man den freien V+ Pin nutzen. Damit kann das PCB auch über die Versorgungsspannung betrieben werden. Es liegen dann ~4,2V am Batteriekasten an! Die Nutzung von zwei BAT43 Dioden würde einerseits geringere Spannungsverluste bedeutet, andererseits den Reverse Current in den Batteriekasten verhindern. Die 4.2V

Verkabelung

Funktion	Pin ESP	LLS	RM370
rote LED	D7	3	R8 TP
gelbe LED	D6	2	R13 TP
grüne LED	D5	1	R12 TP
Buzzer	D2	4	R7 TP
GND	GND	GND	(-)
VCC RM370	-	HV	D3 TP
3V3 RM370	-	LV	R35 TP
VUSB ESP	5V 1N400X	-	V+
Batterie	A0 200k	-	(+)

Grundverbrauch liegt bei 20 bis 30 µA (Errechnet: I=0.000059), nach der Modifikation liegt der Verbrauch bei rund 69µA.

PCB

Die wesentlichen Eigenschaften des PCB wären:

1. Nutzung der Testpads auf der Unterseite
2. ESP32-PICO oder ESP8285
3. Logic Level Shifter ( keine N-MOSFET, sondern P-MOSFET) für die GPIO
4. Spannungsteiler für den ADC 5V<->1V (440k (200k + 220k) und 100k) plus MOSFET
5. Schutzdiode für V_5V Rail
6. MOSFET für die VBAT

Funktionsweise

Der eigentliche CO-Melder wird nicht verändert, es werden lediglich die Zustände erfasst und per WLAN weitergeleitet. Hierbei kommt ESP-Now zum Einsatz, ein WiFi Vendor Frame Format, welches ohne AP auskommt. der Payload wurde in einer Struktur geordnet, sodass man eine Präamble, eine eindeutige Kennung, den codierten Zustand sowie ein Flag für geringe Batteriespannung mitteilen kann. Maximal sind 20 Teilnehmer zugelassen, diese nutzen den Channel 3 und geben sich als AP mit der Kennung "CO-WARN" aus. Der Sketch verarbeitet maßgeblich zwei folgende Aufgaben:

• Statusüberwachung
• eingehende Broadcast Frames weiterleiten Hierzu werden die LEDs per Interrupt überwacht. In der Realität leuchten die LEDs nur kurz aber für einen Menschen erkennbar auf, dies ist aber zu lange für eine einmalige Interruptauslösung. Die Beschränkung auf FALLING funktionierte nicht wie erwünscht. Grundsätzlich wird in den Interrupts für die LEDs wird der Eigenzustand im Strukt rm370 ownState gespeichert, zusätzlich wird der globale Status angepasst.

Sollte der globale Status nicht dem Eigenen entsprechen, so wird der Buzzer aktiviert. Ist der Buzzer durch das System selbst schon aktiv bzw. die LED rot oder gelb leuchten, dann wird der Buzzer nicht beeinflusst.

Ist der eigene Status entweder rot oder gelb, so wird diese Nachricht an alle anderen verschickt.

Werden Nachrichten empfangen, so werden diese mit dem eigenen Status abgeglichen und bei Code 'rot' oder 'gelb' wieder per Broadcast weitergeleitet. Weiterhin wird geprüft, ob diese Kennung schonmal empfangen wurde.

Nach 20 Sekunden wird der globale Status wieder zurückgesetzt. Dies setzt ein Ausbleiben eingehender Nachrichten voraus.

Der Test Knopf wird nicht unmittelbar erfasst, allerdings leuchtet die rote LED ebenfalls kurz auf, dadurch wird die Meldekette initiert.

Trivia

• Der Buzzer summt leise wenn das Board programmiert wird.
• Das Wemos Board verbraucht rund 90mA über die VUSB Schiene
• intergrierter LevelShifter mit EN-Pin: TXB0104

ToDo

-[ ] Batteriestatus geeignet erfassen -[ ] espnow Verschlüsselung -[ ] alive Nachrichten -[ ] receivebuffer Größe anpassen -[ ] ringbuffer.next Implementierung -[ ] Minimales PCB entwerfen