Friday, August 28, 2015

Many people are complaining about I2C communications problems, mostly related with the NodeMCU LUA.

I found out that many of the related problems are generated from a easy to fall in trap, generated by the way how code is executed in case of a step-by-step debug run or using a interpreter console, as in our above NodeMCU LUA case.

Let's take a very simple example code and with the help of a Oscilloscope let's see what's happening exactly. I have choosen a LM75 I2C temperature sensor for our example, as been widely used and also people heavily complained about communication problems with. For more details about the code take a look at the LM75 Temperature sensor Article.

If you take the code from above, save it on ESP8266 module aslm75_test.lua and run it after that asdofile("lm75_test.lua") you will see that the result is OK, typing the right temperature, 29C in our case.

LM75 - I2C Communication - 500 us timebase

If we zoom in a bit, we will be able to identify also our code snippets: i2c.start(bus) i2c.address(bus, address, i2c.TRANSMITTER) i2c.write(bus, temp_reg) i2c.stop(bus)

So, as you can see above, all OK and confirmed also by decoding the I2C communication on the Oscilloscope.

Now, let's see what's happening when running the same code from the console (just select the code and press "Execute Selection" button.

-> h = 255-> l = 255-> temp = 0.5

WHAT?! WHY?!

Let's take a look on the Osciloscope also for this Run, using the same timebase, 500us :

LM 75 - I2C Communication - Run from console - 500us

Confused? Let's increase the time base to 500ms and let's see what we can found about:

LM 75 - I2C Communication - Run from console - 500ms

What is telling us the last picture? The TIMING now is totally wrong !!

Why?
Because of the way that the code is sended to the interpreter and the way that is run, line by line!!

And please remember , these nasty things might happen in some conditions, even in case of a compiled code, not interpreted, when the code is in a step-by-step debugger mode run!

Might look silly and trivial, but imagine a way more complex code, all working OK, adding some extra modules, start debugging for them and suddenly starting having problems with previous tested modules, some nice working ones!
If you fall in such a trap, you can end up to spin around in circles for weeks.

What can be the solution? Easy. Just use the Rule number one: keep sensitive things like communication/timing and stuff at "atomic" level! Reading carefully the Datasheets can help you to quickly identify the "atomic granulation".

How can be done that in a easy way? Simple. Just use a FUNCTION!

Rememer, using functions in you code will give you not only the advantage of high readability, a modular and structural programming, easy debugging, etc, but also, if functions are designed properly, can help you to avoid a potential pitfall as the one above.

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:

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.

For any new orders / requests please feel free to use as usual: tech at esp8266-projects.com. If
you want for your own experiments to order ESP8266 WIFI Web Power Switch for MAINS - MPSM v.2 DevBoardbare PCBs only,
you can also do it directly at Dirty PCBs, our preferred PCB House:

I was asked to make also a short, basic introduction also for Arduino IDE, so here we go. But before of that I need to make also a short presentation of the MPSMv2 Board with few extra explanations. I will not insist too much on the hardware/schematics/theory of operation part of the story as you have all the details already in the previous articles about, including BOM.

What I want to explain a bit is the concept behind that might help you to understand better how to use the board. To ease the understanding you can see MPSMV2 as 2 separate Boards spliced together, a Breadboard friendly ESP8266 adapter with
integrated 3.3V Power Supply, and a MAINS Triac Switch.

The PCB is designed in such way that no harm will be done by cutting it in half as in the below picture.

MPSMv2 Board - Full and splitted

You can use separatelly the 2 parts, the ESP8266 Adapter with 3V3 regulator and the Triac MAINS Power Switch.

MPSMv2 - ESP8266 adapter with voltage regulator & stuff on the back

The Triac Switch part can be used directly even with a
different ARM, PIC, Arduino, whatever MCU you have arround without any
problems as long as it has a GPIO pin capable to
drive the MOC Optocoupler LED thru CMD port.

Triac Driver part - use proper Fuse and EMI filtering!

Please keep in mind that de design was
done in such a basic way as been designed to be part of a bigger system and used for development and testing.

There were a lot of questions and debates about, including the Hackaday one, why it has not a FUSE, where is the filtering, etc, etc ... they are not there because should not be there in our MPSMv2 design.
Input protection/filtering block for MAINS should not be on the same
board with the driver. They are a lot of explanations behind this but
even only having more flexibility in mind should suffice.
If you
look at the EMI filter below, similar with the choosen one as suitable to be used in our project
you will understand even more why should be not on the MPSMv2 board.

EMI filter vs. MPSMv2 Board

Now let's go back to our main story for today: how to use MPSMv2 with Arduino IDE.

Select inside IDE your desired ESP8266 Board (default one should be also OK).

Plug-in the USB adapter connected with the MPSMv2 module as above, will see the power on LED's

Open in IDE the basic Blink program

Replace the digital pin 13 as an output PIN with1.

Compile and upload the program to MPSMv3 board.

The result:

Let's test also the Triac driver command pin:

Q & A :

How can you have more than a MAINS power switch channel available? Very simple: just cut the Triac driver part from other MPSMv2 PCB's and connect the Driver side only to the full size MPSMv2 Board.

How many independent MAINS lines can be driven by a single MPSMv2 Board? As many as free IO pins you have available in your project and Triac Drivers you might add to it.

What's the easiest way to have 2 MAINS lines swiched synchronous? Just connect the CMD port from a second available Triac module to the CMD port on the main MPSMv2 Triac Module. The Triac driver from the MPSMv2 will be commanded in sync with the second connected one.