Show page

Differences

This shows you the differences between two versions of the page.

--- iothings:proiecte:2022:low_power_environmental_monitoring_system [2023/01/18 18:21]
ciprian.costea [2. Hardware Bill of Materials]
+++ iothings:proiecte:2022:low_power_environmental_monitoring_system [2023/01/19 21:58] (current)
ciprian.costea [7. Further work]
@@ Line 32: / Line 32: @@
 The hardware schematics and wiring can be observed in the following image developed in [[https://www.kicad.org/|Kicad]] \\
-{{ :iothings:proiecte:2022:costea_schematic_iot_project.png | Hardware schematic of the project}}
+{{ :iothings:proiecte:2022:costea_schematic_iot_project_4.png?819 | Hardware schematic of the project}}
 The ESP32 board is being powered through its 3.3V pin and the communication with the BME280 sensor is realized through the
@@ Line 48: / Line 48: @@
 The following flowchart of the software architecture shows the states and transitions which the application will execute.
 Note that primarily the software will send queried data to "wunderground" server and optionally to Firebase, based on the value set for a specific flag. \\
-With respect to WiFi connection, if the ESP32 board cannot establish the connection in under 20 seconds the software logic will reset the platform in order to avoid any unconditional hangs, resuming its bloc logic execution from the very beginning.
+With respect to WiFi setup, if the ESP32 board cannot establish the connection in under 20 seconds the software logic will reset the platform in order to avoid any unconditional hangs, resuming its bloc logic execution from the very beginning.
 {{ :iothings:proiecte:2022:costea_software_flowchart_iot_project_2.png | Software State Machine (Flowchart) of the project}}
@@ Line 69: / Line 69: @@
    * Hibernation mode -- ~2.5uA
-     * Only one RTC Timer and some RTC GPIOs remains active. Everything else is turned off.
+     * Only one RTC Timer and some RTC GPIOs remain active. Everything else is turned off.
 For this project we chose the Hibernation Mode, which only keeps alive the RTC timer and some RTC GPIOs used for waking the platform up. In this mode the advertised power consumption is around ~2.5uA. The ESP32 core, WiFi, Bluetooth and other Peripherals will be inactive.
@@ Line 93: / Line 93: @@
 <code c>
 String constructHttpGET(float temp, float humidity, float pressure) {
-  String url = "https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php?ID=<your_id>&PASSWORD=<your_passwd>&dateutc=now";
+  String url = "https://weatherstation.wunderground.com/weatherstation/updateweatherstation.php?ID=<your_device_id>&PASSWORD=<your_device_passwd>&dateutc=now";
   float tempf;
@@ Line 134: / Line 134: @@
 ====== 5. Results & Challenges ======
-As it can be seen in the following images from the [[https://www.wunderground.com/pws/overview|WeatherUnderground]], under the page related to the registered device, the periodically queried BME280 sensor data is being received and displayed.
+As it can be seen in the following images from the [[https://www.wunderground.com/pws/overview|WeatherUnderground]], under the page related to the registered device (in this case -- IBUCHA284), the periodically queried BME280 sensor data is being received and displayed.
 {{ :iothings:proiecte:2022:costea_wunderground_1.png?800 | Wunderground project data table}}
@@ Line 159: / Line 159: @@
 ====== 7. Further work ======
-More analysis with respect to usage of RTC memory in Deep Sleep as opposed to directly using Hibernation mode would be of interest. While Hibernation mode uses less power by not keeping the RTC recovery memory on, in Deep Sleep we could use this RTC memory to store any relevant data and maybe bypass some of the reinitialization mechanism. Some effort was invested in this regard, but the **RTC_DATA_ATTR** is not complex enough to support storing information regarding Wifi or Firebase status. Nevertheless, the tradeoff between Hibernation and Deep Sleep could be further explored.
+More analysis with respect to usage of RTC memory in Deep Sleep as opposed to directly using Hibernation mode would be of interest. While Hibernation mode uses less power by not keeping the RTC recovery memory on, in Deep Sleep we could use this RTC memory to store any relevant data and maybe bypass some of the initialization mechanism. Some effort was invested in this regard, but the **RTC_DATA_ATTR** data type is not complex enough to support storing information regarding Wifi or Firebase status. Nevertheless, the tradeoff between Hibernation and Deep Sleep could be further explored.
-Power consumption of this project could be monitored by using the ADC module available on the ESP32 platform and taking into consideration that the Li-Ion battery outputs a voltage between 3.7V and 4.2V (when fully charged).
+Li-Ion battery level could be monitored by using the ADC module available on the ESP32 platform, taking into consideration that the battery outputs a voltage between 3.7V and 4.2V (when fully charged).
-Since this project is finally intended to be installed outdoors, a platform connection through a low throughput, low data rate, low power and long distance communication protocol such as [[https://lora-alliance.org/about-lorawan/|LoRaWAN]] would be more practical compared to WiFi, which was used as a first demonstration.
+Since this project is finally intended to be installed outdoors, a platform connection through a low throughput, low data rate, low power and long distance communication protocol such as [[https://lora-alliance.org/about-lorawan/|LoRaWAN]] would be more practical compared to WiFi.
 A more suitable case/packaging could be built/developed for the hardware solution of this project.
 ====== 8. Resources ======
+[[https://www.espressif.com/sites/default/files/documentation/esp32_datasheet_en.pdf]] \\
 [[https://esphome.io/devices/nodemcu_esp32.html]] \\
 [[https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/sleep_modes.html]] \\