Ask
This is my first project with both electronics and programming so I'm hoping that people could let me know if I'm on the right track with how I'm tackling the project.
Blockers
- Haven't wrapped my head around the relationship between V=IR to an extent that I can apply it to;
- Whether the complete circuit will work.
- Identify and choose appropriate components.
- Whether the components will work together.
- Interpretting data sheets.
- Am struggling with circuit fault finding in my circuits and identifying what went is wrong or how I fixed it when getting the circuit to work again.
- Some fear of nuking the board or components >$10. (Pretty sure I nuked one of my USB ports on my monitor arm.)
Ways you can help:
- Point out any glaring issues that are likely to be dead ends.
- Would appreciate context as to why and nudges into a more productive direction.
- Point out if/where I have designed in needless complexity.
- Point me in the direction of good resources that can help me work out the V=IR relationship in the context of circuits that aren't a simple circuit (LED) etc.
- Any Google Keywords that might be relevant for me to look into and understand.
Specific questions:
Are the Mosfets models appropriate?Any issues with the circuit diagram?
* I'll be relying upon it to have confidence in my wiring down the track
My preference is for suggestions in the right direction for me to try and work it out on my own over giving straight answers. However I have attention challenges and am most effective when I can try and break it with a feedback loop.
Project
Am replacing the mesh cover (has rusted out) to full acrylic sheet on my paludarium so need to make sure there is sufficient ventilation.
Rather than just putting 'dumb' fans on it's a perfect excuse to learn programming, microcontrollers and electronics.
Solution/Project:
- Build a "Controller Unit" for the Paludarium.
- Run a bank of 5x 5V fans based on Humidity and/or Temperature values read from a sensor.
- Have varying "Settings" with different speeds depending on sensor readings.
Goals:
- Learn Electronics and Programming
- The "Controller Unit" be extensible for future features.
- Be able to remotely update "Settings" (access will be finnicky).
- As minimal hardware within the enclosure as possible.
- Log sensor readings and fan events off the controller.
- Try and wire sensors/fans in a way that make them "hot swappable".
Components
| Component | Status | Rated mA | Total mA | Voltage | Datasheet Link |
|---|---|---|---|---|---|
| Replaced | |||||
| Replaced | |||||
| ESP32 | Done | 250mA | - | 3.3V | Can't find. |
| SHT31 temperature and humidity sensor | Done | <1.5mA | - | 3.3~5V | Wiki / DS |
| N-channel MOSFET (FQP30N06L) | Done | - | - | - | DS |
| Protection diode (1N4148) | Done | - | - | - | - |
| Capacitor (10uF and 0.1uF) | Done | - | - | - | Product Page |
| 5 x 5V DC Fans | Done | 200mA | 1000mA (1A) | 5V | Product Page |
| LM7805 voltage regulator | - | - | - | - | - |
Project Steps:
| Milestone | Status |
|---|---|
| Pick up Elegoo "starter kit" and try my hand at Uncle Paul's (Paul McWhorter) relevant tutorials | Done |
| Get the DHT11 sensor going (programming and circuit) | Done |
| Replicate N-Channel Mosfet as a Switch Youtube tutorial to control fans. | Done |
| Combine the above two and control one fan based on sensor reaadings. | Done |
| Draw a circuit diagram ( |
Done |
| Use circuit diagram to work out how the errors david_2018 pointed out might occur | Done |
| ------- Prototype if necessary. | Done |
| Update circuit diagram with ESP32 [V1] | Done |
| Incorporate D's (friend) code review feedback. | Done |
| - | |
| Write program for ESP32 | Done |
| Explore paulpalson's suggestion of using Arrays | [Probably] |
| Calculte V = IR for each circuit half and confrim it's safe the with ESP32 | - |
| Confirm components are appropriate and the circuit should work | - |
| Determine Power regulator etc. | - |
| Order components | In Progress |
| Replace DHT11 with the SHT31 (get code back to stable) | Done |
| Scream at why it isn't working | |
| N/A | |
| Breadboard circuit V1 with the ESP32 | Done |
| Breadboard one fan protoype with ESP32 | - |
| Work out enclosure requirements | - |
| Move off breadboard | - |
| N/A | |
| N/A | |
| Set up logging to Google Sheets | - |
| ** Scream at why it isn't working | [DONE] TruckMe IFTTT documentation is great! |
| *** N.B For those discovering this in the archives of the internet. | Hopefully this saves you 5 days when trying to work out webhooks and JSON payloads. |
Supporting Materials
- Current Sketch code (below)
Conversation with ChatGPT trying to unblock myself. (Google Docs)After mucking around with it on my lunch break with a co-worker I thought I'd give it a whirl. It seemed to do it pretty well.
The Circuit Diagram I drew based upon the instructions from ChatGPT.- The Circuit Diagram (V1) incorporating the ESP32 and seperating into two independant circuits.
Circuit Diagram
Program Architecture and Design Decisions
- Alto has used an unsigned declaration on the Long
- Long appears to be a data type (variable)
- Linsell was talking about the idea learning datatypes depending on my circumstances
- INPUT_PULLUP
- using an onboard pullup resistor to set the pin to High in order to overcome nearby electrical noise.
- Debouncing
- A tactic that prevents multiple input readings or input noise from a source
- Causes for multiple readings/input noise?
- Electrical interfences?
- kids smashing buttons
Design Decisions.
Structure:
- Write all functions/arguments as if the parameters and variables can be self contained and use "global variables" for all of the data you would like the logical arguments to update/respond to.
Setup:
- "inititating" hardware doing the set up seems like a logical thing to do particularly on reboot.
Timing:
- Do I design my logic around using "real time" or use an internal counter to manage "program time"?
- Using "program time" will reduce a complexity that could lead to issues (say power outtage).
- For the purposes of logging I can find a way to fetch "real time" to be recorded with the log.
- As a consumer I still get a meaningful time but without the potential frustration.
Logging:
- What is it that I want to log?
- I can log when the program runs an argument, or
- I can log when a state changes.
- Based on the the "do while" argument being a set that encourages the argument to reach it's conclusion I should consider;
- a generally applied rule as a matter of practice won't always be applicable and logging may be at times impractical.
- as a design practice, assuming each argument to execute is flawed thinking.
- Is there a benefit to logging device state?
- Thinking about the initiating hardware during setup, there could be a situation whereby if the device were to restart, confirming that it re-initialised could be important in post production debugging.
- This could be particularly important if I want to update remotely.
- Thinking about the design goal of this being set and forget, I should consider if I would want exception/error reporting to be proactively notified if the device isn't running as intended.
- This would likely have to off device and either a "phone home" or a "ping check"
- Will have to think about how I might want to do this.
- Simplest would be a visual indicator like an LED run to the front of the enclosure I can glance at
- Alta was right about the LCD display!!! Maybe later.
Fail State:
- In an instance whereby the sensor fails for some reason, I should consider a default state.
- This probably should be my "entry" which should definitely not be "off".
- In an instance whereby a fan fails. the others shouldn't be blocked.
- I wonder whether there is a way to "read" the pin to confirm output.
- Is there another component I can place on the "local fan circuit" that can indicate an issue with that fan.
- As the Mosfet is controlling the "local fan circuit" via Ground, is there a way I can create the circuit equivalent of:
IF(!fanPower) {
turn on buzzer}- Would be worth considering a microSD card module for non-permanent local logging
Program Architecture
Libraries
- SHT31
- <Wire.h>
- ESP32 Servo
- SerialDebug
State
- Variables
- Fan state
- Program Time
- Real Time
- Loop count (need to think through how knowing the current loop could be used)
- Sensor readings (might stick with variables now and look into arrays later. Need to do more study/find good excuse to play with them)
- LED Indicator state
- Ventilation Setings
- Arrays or Constants?
- Humidity
- VeryHigh
- High
- Stable
- Low
- Temperature
- VerHigh
- High
- Stable
- Low
Setup
- Fans
- SHT
- Initialise components
- Log Setup
- Don't block program, just log
Loop
- Update state
- Program time
- Real time
- Sensor Readings
- Fan state
- Led indicator State
- Update Report
- The things I want to know
- Update log
- The things I hope I don't have to check
Arguments
- Functions
- Fetching real time
- Reporting
- Logging
- Reading Sensors
- Sensor Decisions
- Checking fan state
- Controlling Fans
Potential extension projects:
- Control the lights to simulate day/night cycle.
- Use habitat weather data to simulate habitat conditions.
- Control existing Misting system.
- Control existing water filtration system.
- Mating Observation System:
- Listening for mating calls.
- Motion detecting.
- Capturing PAR sensor data
- Capturing TDS of the water column
Changelog
18/01/23
- Replace the nano and ESP8266 with an ESP32 based on horace and Idahowalker advice.
- Update Mosfet model.
- Update Logging idea to use google sheets via the ESP32
- Added Amperage, Voltage and Datasheets/Reference links to components to begin accounting for Ohms law.
21/01/23
- Fixed (pending confirmation) the issue where the fans were bypassed in the circuit.
- Worked out that the power regulator allows me to seperate the ESP32 from the fans in order to meet the current requirements of the board.
- Update Circuit Diagram breaking out into two halves split between Power Regulator
24/01/23
- Incorporated Alta's fanControlHack which unblocks the program from it's delays and allows it to operate based on conditions and states.
- Wrote Architecture/Design Decisions doc to help plan out/think through what I need the program to do and how I might be able to structure it.
Sketch Code
// general
// fan
int fanPin = 6;
/*
analogWrite(0) means a signal of 0% duty cycle.
analogWrite(127) means a signal of 50% duty cycle.
analogWrite(255) means a signal of 100% duty cycle.
Notes: #FIXME Work this out.
- 5% (12) doesn't turn the fan on from stand still
- 10% (25) doesn't turn the fan on from stand still
- 15% (37) doesn't turn the fan on from stand still
*/
/* This function will allow me to control multiple output pins indepentaly of each other.
*********** VVV this is the function VVV ***********
void setFanSpeed(int fanPin, float fanSpeed) {
}
*********** ^^^ this is the function ^^^ ***********
*/
// DHT sensor
#include <DHT.h>
#define Type DHT11
int sensePin = 2;
DHT HT(sensePin, Type);
float humidity;
float temp;
int setTime = 500;
void setup() {
// put your setup code here, to run once:
// General
Serial.begin(9600);
// sensor
HT.begin();
delay(setTime);
//fan
pinMode(fanPin, OUTPUT);
}
int convertFanDurationToMs(int fanDuration) {
int fanDurationMs = fanDuration * 1000;
return fanDurationMs;
}
/* #FIXME Final calculation to set the fan speed in minutes rather than seconds
int convertFanDurationToM(int fanDuration) {
int fanDurationM = fanDuration * 60000;
return fanDurationMs;
}
*/
void setFanSpeed(int fanSpeed, int fanDuration) {
int DurationMS = convertFanDurationToMs(fanDuration);
Serial.println("Upcoming:" + String(fanSpeed));
Serial.print("3");
Serial.println();
delay(1000);
Serial.println();
Serial.print("2");
Serial.println();
delay(1000);
Serial.println();
Serial.print("1");
Serial.println();
delay(1000);
// int fanSpeedAnalog = fanSpeed * (((int)255/100) +1);
int fanSpeedAnalog = ((fanSpeed * 255) / 100);
Serial.println("Analog read:" + String(fanSpeedAnalog));
analogWrite(fanPin, fanSpeedAnalog);
Serial.println("Running fan " + String(fanPin) + " for " + String(fanDuration) + "s at " + String(fanSpeed) + "%");
delay(DurationMS);
}
void loop() {
// put your main code here, to run repeatedly:
// sensor settings
humidity = HT.readHumidity();
temp = HT.readTemperature();
// tempF=HT.readTemperature(true);
int humidityVeryHigh = 90;
// FanSpeed = 100 Duration = 30
int humidityHigh = 75;
// FanSpeed = 75 Duration = 20
int humidityStable = 60;
// FanSpeed = 30 Duration = 60
int humidityLow = 40;
// FanSpeed = 0 Duration = 30
int tempVeryHigh = 90;
// FanSpeed = 100 Duration = 30
int tempHigh = 75;
// FanSpeed = 75 Duration = 20
int tempStable = 60;
// FanSpeed = 30 Duration = 60
int tempLow = 40;
// FanSpeed = 0 Duration = 30
Serial.println("Humidity:" + String(humidity) + "%" + " Temperature:" + String(temp) + "C");
if (humidity >= humidityVeryHigh || temp >= tempVeryHigh) {
Serial.println("Setting Fans to: 100% for 30 minutes");
setFanSpeed(100, 30);
} else if (humidity >= humidityHigh || temp >= tempHigh) {
Serial.println("Setting Fans to: 75% for 20 minutes");
setFanSpeed(75, 20);
} else if (humidity >= humidityStable || temp >= tempStable) {
Serial.println("Setting Fans to: 40% for 60 minutes");
setFanSpeed(40, 60);
} else if (humidity >= humidityLow || temp >= tempLow) {
Serial.println("Setting Fans to: 0% for 30 minutes");
setFanSpeed(30, 60);
}
}
Learning Journal
- Not all Mosfets are the same despite their "name" and their pins could be different based on their models.
- When having different parts of an overall circuit that is powered from a single PSU with different Voltage and Current requirements you can choose where to branch those parts to control the V = IR conditions for either branch. In the case of the 5 fans creating a Current draw greater than the ESP32 can handle the voltage regulator can be used as junction to create independant circuit conditions for both.
Ancillary Steps
| Item | Notes |
|---|---|
| Work out why you might not use a gate current limiting resister from an ESP32. | - |
| Investigate the differences in the ESP32 Servo and PWM to work out why the Servo Library might be preferred. | Could have something to do with how the ESP32 handles Timers. |
| --- | Could have something to do with losing power and not maintaining current time. Or even state? |
| Play around with arrays to handle constants | - |
Relevant Tutorials
-
Interfacing SHT31 with ESP32 TTGO LoRa32 and display on its OLED display
-
ESP32 with DC Motor and L298N Motor Driver – Control Speed and Direction
-
DIY Cloud Weather Station with ESP32/ESP8266 (MySQL Database and PHP)
-
MQTT – Publish DHT11/DHT22 Temperature and Humidity Readings (Arduino IDE)
-
Visualize Your Sensor Readings from Anywhere in the World (ESP32/ESP8266 + MySQL + PHP)
-
DHT11/DHT22 Web Server – Temperature and Humidity using Arduino IDE
-
Publish Sensor Readings to Google Sheets (ESP8266 Compatible)
Glossary
| Term | Clue | Definition |
|---|---|---|
| Current Limiting Resistor | - | A resistor placed prior to a something (in series) that limits the current going into the the component placed after it. |
| AVR | GPIO pins have a 40mA limit which is the same as an AVR | ? |
Reference Material
- Any difference powering the board through VIN vs 3V3
- Arduino to control 3 DC motors
- Stackexchange answer that explains how to power two different "Modules" that require different voltages (thus currents) with the same PSU.
Archive:
Original Circuit Diagram
Notes:
The Circuit Diagram has the IRF520 Mosfet based on ChatGPT suggestion.Not sure how to validate. Forum suggests "Logic-Level" Mosfets.Preferred supplier also doesn't seem to stock IRF520. Their search points to the FQP30N06L.
