ESP8266 Projects Blog
Home of CBDB / MPDMv4 /SmartMon Development boards (ESP-12/ESP-07).
Guidelines and ESP8266 programming examples using LUA, Eclipse and Arduino IDE, ESP Basic and many more!
2 Resistors for the voltage divider, R1=105.6k, R2=24.08k. I am using here precision resistors and the values are measured values with a proper calibrated bench meter.
Voltage divider schematic and Vout (ADC input voltage) formula
How do we do it :
1. Measure your Max desired input voltage In my case, Max Input Voltage (Vmax) = 5.1919 (measured)
2. Measure Resistors values: R1 = 105.6k R2 = 24.08k 3. Check if Full Scale Value at the voltage divider output is inside the ADC defined domain:
Calculated : Vout = (R2/(R1+R2))*Vin = 0.964072733 V
Measured = 0.96038V
Good enough for the precision we are looking for. ESP8266 ADC is 10bit only and not exactly the most accurate in town
4. Calculate Voltage Divider Ratio:
Vdivider Ratio= Max Input Voltage/Fullscale value = 5.405976676
5. Read ADC value :
adcr = adc.read(0) print(" ReadADC : "..adcr)
Average result for adcr = 1017
THIS IS IMPORTANT !! It tell us that we are inside the ADC domain as adcr < 1024 !
IF adcr > 1023 then you need to adjust your voltage divider resistors to fit inside ADC domain!
6. Calculate LSB in 2 ways to cross check that we have the right value:
LSB = Input Voltage read by multimeter/ADC readed Value =
= 5.1919 / 1017 = 0.005105113 V
OR
LSB = (ADC Input pin read Voltage by multimeter/ADC readed Value/)*Vdivider Ratio =
= (0.96038/1017)*5.405976676 = 0.005105113 V
It looks that we have the right LSB Value for our exercise!
If you want to know also the ADC LSB, then
LSB = ADC Input pin read Voltage by multimeter/ADC readed Value = = 0.96038/1017 = 0.000944346 V
Guess what's happening if you multiply ADC LSB with Vdivider ratio :)
7. Software Implementation for the ADC read function:
function readADC() ad = 0 LSB = 0.005105113 --calibrate based on your voltage divider AND Vref! adcr = adc.read(0) ad= adcr*LSB print(" ReadADC : "..adcr) print(" Read Voltage : "..ad) return ad end
For any new orders/requests please feel free to use as usual: tech at esp8266-projects.com. MPDMv4 Boards are also available on Tindie: AC MAINS Dimmer - MPDMv4
WARNING!! You will play with LIVE MAINS!! Deadly zone!!
If you don't
have any experience and are not qualified for working with MAINS power I
will not encourage you to play arround!. The
author take no responsibility for any injury or
death resulting, directly or indirectly, from your inability to
appreciate the hazards of household mains voltages.
The circuit diagrams are as accurately as possible, but are offered with no
guarantees whatsoever.
There is no guarantee that this design meets any Rules which may be in
force in your country so please check before your local
rules/regulations.
One of the main problem that people has been complained about was the fact that a simple MAINS Power Dimmer/Switch unit like the basic one presented last year is using sometime too much resources from a already overloaded application MCU/processor:
MPDMv3 - MAINS Dimmer/Switch with Phase detection
One of the scenarios, directly related with ESP8266 is about the limited timers capabilities that you have. For example, if you want to implement a proper web server to directly serve your webpages from ESP8266 you are automatically using one timer. If you want to start using the second one for your ZCD processing ...well...it's becoming very tricky. Very.
Don't uderstand me wrong, a bigger, better MCU can do it probably very well,
but even then if you have the chance to free some resources easily, do
it!. And I really cannot see a ESP8266 acting as a App MCU (webserver,
data logger, MQTT client, etc, etc) and doing reliable also other demanding
functions as Processing Zero Crossing Detection.
SOLUTION?
I can see only one, and it is a lesson learned many years ago: keep your real-time processing functions away from your Application MCU/Processor. To do that we just need to move the ZCD processing function from the ESP8266/whatever MCU you want to the MPDM Driver itself:
MPDMv4 - MAINS Phase detection and ZCD processing
What means that? means that in this new configuration our ESP8266 will be free from any type of real-time ZCD processing that is related with the MAINS Dimming process, you just need to send to the MPDMv4 driver a voltage (Vcontrol) in a pre-established range (0-3V for example) that will correspond with different desired Dimming levels.
What we have obtained? A UNIVERSAL MAINS Power Dimmer driver that can be used with any MCU you might want or even no MCU at all. You can dimm it even with a simple Potentiometer at input, no programming, no code, no nothing!!
Legend:
PURPLE - Phase detector output
BLUE - Reversed phase signal (normalised)
Yellow - Triac Driver CMD signal (PWM)
Vcontrol = 0, CMD Duty cycle=6%
Vcontrol = 2V, CMD Duty=50%
Vcontrol = 2.8V, CMD Duty=96%
How can be done that? Easy. Use PWM or a DAC, your choice. For ESP8266 I will recommend you to use a DAC, like the MCP4726 or, why not , the MCP4728, for a full 4 Channel MAINS Dimmers solution. PWM in case of the ESP8266..let's say that is has some limitations that you will discover very soon that you don't like :)
The mains advantages of using DAC?
Notable:
1. Very low to zero overhead on the App MCU
2. High precision (DAC from above are 12 bit!! - 4096 levels of dimming!!)
3. You can use the "set-and-forget" technique using DAC internal nonvolatile memory (EEPROM) and have the same level on the next power-off/on cycle.
IMPLEMENTATION
SCHEMATICS
As the only functional difference between the previous MPDMv3 MAINS Dimmer and the new MPDMv4 is the presence of the ZCD function onboard, basically, without some small bits and pieces around like the MOV protection circuit, you can see it exactly as it is: a MPDMv3 with a ZCD circuit onboard:
MPDMv3 - Phase detection and Triac control
Zero crossing detector circuit
MPDMv4 PCB:
MPDMv4 PCB
As you can see from the above picture, it was carefully designed with proper MAINS isolation from the rest of the driver, you can see even the extra isolation slots done for a even bigger Creepage distance.
And because I know this terms still creates some confusion, short definitions below:
CLEARANCE is the shortest distance in air between two conductive parts. CREEPAGE distance means the shortest distance along the surface of a solid insulating material between two conductive parts.
A creepage distance cannot be less than the associated clearance so that
the shortest creepage distance possible is equal to the required
clearance. However, there is no physical relationship, other than this
dimensional limitation, between the minimum clearance in air and the
minimum acceptable creepage distance.
And the new, freshly baked result:
MPDMv4 - MAINS Power Dimmer/Switch with Phase detection and ZCD Processing
Next time we will move on to the Software side, to see what is going on with our Webserver interface & stuff.
As been working to a ESP DHT22 sensors array for a Environment data logging system I was thinking that it would be nice to have also a direct reading panel for the data. And because just received in my mailbox few days ago a KN-WS400 Weather station to be used for another project I said why do not to take a deeper look and see if we can use it also as a realtime data view panel for our DHT22 sensors.
As you can see from the picture below, it has a big and nice looking display (not the best quality or contrast in town but, hey, it's just a 40USD unit, nothing fancy):
KN-WS400 Weather station
It has only temperature and humidity capabilities, but for our project is more than enough:).
What is interesting about KN-WS400 is the fact that it can receive temperature and humidity data also from another 3 external sensors (but delivered in the box with only one!).
You can setup and choose between 3 different channels, each one allocated for a separate remote sensor unit.
Remote sensor
Reading remote temperature data on Channel 1
Channel setup is done very simple, choose your desired free channel from your remote sensor unit and reset the corresponding channel on the Weather station by pressing more than 10 sec the channel button.
External sensor CHannel setup and C/F scale option buttons
So far so good. The idea is to try to use another 2 ESP DHT22 sensor units to send the temperature and humidity data directly to WS400 Weather station on the available channels. Or, why not, to replace them all 3 with the WIFI Web enabled ESP DHT22 smarter ones :)
To do this, first of all we need to take a look at the transmission frequency to know what kind of receiver/transmitter to use with our ESP DHT22 Modules.
As is written on the back of the unit, the KN-WS400 Weather station use for remote sensors communication the standard 433Mhz frequency, same as probably most of the zillions different types of cheap weather stations available around.
So now, as we know the frequency, next we need to see if we can have any luck in decoding the communication protocol.
I will not insist to much on the wiring setup as it is a very simple one, just connect your simple 433mhz Receiver module to your Power supply Vcc , GND and the Data pin to your used Oscilloscope channel probe.
As soon as it is connected and you start changing the channel on the KN-WS400 sensor module by pressing the CH button from the back of the unit, you will see a data burst on your Oscilloscope. See also Youtube video from above.
Data burst received on 433Mhz from KN-WS400 remote sensor
As you can see from the captured data above, it looks like the unit is transmitting the data in 6 separate data bursts. Actually, when zoomed in we can see that is sending the same data 6 times.
At a deeper look at the received data stream we can see that:
Each transmission consists of 6 repetitions of the same data.
They are separated by a long sync signal ("preamble") that’s about 4.5ms (3.8ms low + 0.7ms high)
We can suppose the bit patterns (they might be inverted sometime 1<->0 but is not the case of this sensor) as:
- Logic 1 (or 0) is about 2.6ms -> 1.9ms low + 0.7ms high
- Logic 0 (or 1) is about 1.7ms -> 1.0ms low + 0.7ms high
"Preamble" measurement
Logic "1" Measuremnt
Logic "0" measurement
Based on the assumptions from above, let's try to "transcribe" the signal from the above: PRE10101011100100010000010111110011010100000PRExxxxPRExxx4PRE
Before even thinking to try to decode the data we need to be able to identify where reside each data value in the stream. For this taskthat can become quite complicated or impossible some time, you can start using a very simple technique: just change only one variable at a time, in very small increments if possible and look after changes.
The easiest one to do, is the Channel setup, as we have on the back of the sensor unit a switch for it.
Press the channel button and change Channel to 1,2 and 3.
Capture and take a look at the received data :
Now you can clearly see that the channel data (CH) is encoded on 2 bits in the 3rd column. Not bad at all. You know why? because despite the fact that you cannot find 2 Weather stations with the same exact data format they are quite similar and any existing information can help you a lot in the reduction of the complexity of the decoding process.
Let's make another assumption based on the info that we already have from other existing models, that the first 2 bits from column 3 to be the battery status ones. Usually they are coded in this way.
Powering the sensor unit from an external lab PSU and reducing gradually the voltage until under normal working one the data obtained looks:
Nice. So, until now, we have identified the Battery status and Channel ID. Let's go further.
For temperature and humidity a common found coding technique is as follows:
Humidity is stored as low/high order nibbles. So you need to take
the first 4 bits and tack them on the end of the next 4 bits. 11010101 becomes
01011101.
Temperature is transmitted as 12 bits in 3x nibbles ranging from low to
high nibbles. A fixed offset of 900 is applied to the temperature value so 0
degrees F = 900 and each degree F change is 10 decimal. Then the obtained value is divided by 10. And converted to degC. Confusing and painful stuff to find in a data stream.
Sounds complicated? Why are temperature and humidity data coded like that? My personal opinion is that some specifications were created for the first designed one and now as these cheap weather stations has become such a mass product everybody is copying more or less the same design :)
If somebody really knows the true reason for such a coding, I will more than happy to know. Might be some good reasons behind that I'm missing.
Let's see what's happening in our case. And before anything else, let's use the same technique, keeping all the data the same and change slowly Temperature only part:
Only few things remained "undecoded" but believe me after capturing hundreds and hundreds of data streams it looks like de ID remains stable, same with the mysterious "1111" between Temperature and Humidity and the "0" from the end.
As it looks like there is no fancy Checksum algorithm involved or any special data stream identifier I think we can move further and design your own ESP DHT22 Module transmission program for direct data upload. And as you can see in the above Youtube video it was a success.
As soon as I cleaned it a little bit, the Part 2 will follow, with the full code description.
PS: I really hope that after reading this article the guys from Konig or who are doing the coding for this product will let it as it is because it has becoming the most desired cheap Wireless Weather Station around, believe me, they are selling like hotcakes :). Thank you Konig for such a nice surprise for all of us!
And to be clear: I am NOT afiliated in any way with Konig and the unit was not received from Konig. But if they want to thank me for opening a new market for their products I will not say no. lol.
As been asked so many times in the latest days about, please find below a quick install guide that might help you to have a smooth and easy installation:
Inside the new "arduino-1.6.4" subfolder create a New Folder called "Portable"
In
this way you can avoid the way Arduino is installing files all
over the place on your system. All your Arduino IDE v 1.6.4 files will be located only
under the new created "arduino-1.6.4" folder. And yes, your drive can be
in this case a Stick/SD Card or external HDD/SSD Drive so you can take your Arduino IDE
and your projects everywhere, just ready for coding!
2. Start the new installed Arduino IDE.
Go to File
Preferences - in Preferences window go to
"additional boards manager URL's" where you need to paste the following link:
Boards - > Boards manager, in the Boards manager
window select "contributed" from the TYPE drop
Select
ESP8266 by ESP8266 community forum and version 1.6.2
Press Install.
Installation process can take a while, so please be patient! A cup of tea/coffee might work here :)
4. Restart IDE
5. Select your board as ADAFRUIT HUZZAH ESP8266 or GenericESP8266 Module. For CBDBv2 EVO use provided config file or GenericESP8266.
6. Select CPU frequency: 80Mhz
7.
Select your Serial port and upload speed. Looks like it's working upto 921600 but quite unstable. Keep the usual 115200 baud for more solid
upload results.
You are ready for your first ESP8266 Program written in Arduino IDE :)
