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!
Because many people have encountered lots of issues with the installation, mainly r8188eu WIFI chipset driver issues or strange compile problems, I was thinking to give a chance also to the new RASPBIAN Jessie, maybe it might be possible to make life easier for many of us.
First thing: because I use RPI2 board headless, I have disabled the new default boot to graphical interface that Jessie has, CLI is more than enough for me.
GOOD NEWS!! The issue with the r8188eu WIFI seems to be solved. At least my dongle worked this time out of the box, nothing fancy to be done anymore.
Below is the full transcript of a Thingspeak Server installation process finished about 30 min ago, using a fresh new RASPBIAN Jessie image:
System Update & required packages install
Switched over to SSH remote access with Putty - accept new key
Change "pi" account password:
pi@RPIMON1~$passwd
Set ROOT password, so you can then use root (just for very, very special things!)
MySQL Database configuration pi@RPIMON1~$mysql --user=root mysql -p useyourpasswd here pi@RPIMON1~$mysql> CREATE USER 'thing'@'localhost' IDENTIFIED BY 'speak’; pi@RPIMON1~$mysql> GRANT ALL PRIVILEGES ON *.* TO 'thing'@'localhost' WITH GRANT OPTION; pi@RPIMON1~$mysql> commit; pi@RPIMON1~$mysql> exit;
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 :)
Another very popular and widely available module, used already in many Projects before, meeting the ESP8266 ecosystem :)
You can buy MAX7219 modules from Banggood, Amazon, Ebay, nameyourfavorite.com, quality and price might hugely vary from one to another so don't choose the cheapest one in town as you might find it as been not a very good deal to the end.
Description
The MAX7219 are compact, serial input/output common-cathode
display drivers that interface microprocessors (µPs) to 7-segment
numeric LED displays of up to 8 digits, bar-graph displays, or 64
individual LEDs. Included on-chip are a BCD code-B decoder, multiplex
scan circuitry, segment and digit drivers, and an 8x8 static RAM that
stores each digit. Only one external resistor is required to set the
segment current for all LEDs.
A convenient 4-wire serial interface connects to all common µPs.
Individual digits may be addressed and updated without rewriting the
entire display. The MAX7219 also allow the user to select code-B
decoding or no-decode for each digit.
The devices include a 150µA low-power shutdown mode, analog and digital
brightness control, a scan-limit register that allows the user to
display from 1 to 8 digits, and a test mode that forces all LEDs on.
Key Features
10MHz Serial Interface
Individual LED Segment Control
Decode/No-Decode Digit Selection
150µA Low-Power Shutdown (Data Retained)
Digital and Analog Brightness Control
Display Blanked on Power-Up
Drive Common-Cathode LED Display
24-Pin DIP and SO Packages
Typical Application Circuit
This is a 5V operation device. If you need to run it by the book at 3.3V Logic Level you will
need to use a level shifter. In practice, as you will see below, you can
try and run it directly, a bit out of spec. As MAX7219 HIGH logic level is at
3.5V...well...looks like it's working quite OK also in this way, in 48
hours of continuous running no freeze or strange behaviour:)
For programming and uploading the driver and the software we will continue to use the LuaUploader as before.
MAX7219 - CBDBv2 EVO Connection
Wire MAX7219 ESP8266
Green +5Vcc
Blue GND GND
Yellow DIN 13
White CS 12
Orange CLK 14
MAX7219 Driver Implementation
Timing Diagram
Initial Power-Up
On initial power-up, all control registers are reset, the display is blanked, and the MAX7219 enter shutdown mode.
Program the display driver prior to display use. Otherwise, it will initially be set to scan one digit, it will not decode data in the data registers, and the intensity register will be set to its minimum value.
Shutdown Mode
When the MAX7219 is in shutdown mode, the scan oscillator is halted, all segment current sources are pulled to ground, and all digit drivers are pulled to V+, thereby blanking the display.
Data in the digit and control registers remains unaltered.
Shutdown can be used to save power or as an alarm to flash the display by successively entering and leaving shutdown mode.
For minimum supply current in shutdown mode, logic inputs should be at ground or V+ (CMOS-logic levels).
Typically, it takes less than 250μs for the MAX7219 to leave shutdown mode.
A nice thing is the fact that the display driver can be programmed while in shutdown mode, and shutdown mode can be overridden by the display-test function.
Serial-Addressing Modes
For the MAX7219, serial data at DIN, sent in 16-bit packets, is shifted into the internal 16-bit shift register with each rising edge of CLK regardless of the state of LOAD. For the MAX7221, CS must be low to clock data in or out. The data is then latched into either the digit or control registers on the rising edge of LOAD/CS.
LOAD/CS must go high concurrently with or after the 16th rising clock edge, but before the next rising clock edge or data will be lost. Data at DIN is propagated through the shift register and appears at DOUT 16.5 clock cycles later.
Data is clocked out on the falling edge of CLK.
Data bits are labeled D0–D15.
D8–D11 contain the register address.
D0–D7 contain the data, and D12–D15 are “don’t care” bits.
The first received is D15, the most significant bit (MSB).
Digit and Control Registers
14 addressable digit and control registers.
The digit registers are realized with an on-chip, 8x8 dual-port SRAM. They are addressed directly so that individual digits can be updated and retain data as long as V+ typically exceeds 2V.
The control registers consist of decode mode, display intensity, scan limit(number of scanned digits), shutdown, and display test (all LEDs on).
Decode-Mode Register
The decode-mode register sets BCD code B (0-9, E, H, L, P, and -) or no-decode operation for each digit.
Each bit in the register corresponds to one digit.
A logic high selects code B decoding while logic low bypasses the decoder.
When the code B decode mode is used, the decoder looks only at the lower nibble of the data in the digit registers (D3–D0), disregarding bits D4–D6. D7, which sets the decimal point (SEG DP), is independent of the decoder and is positive logic (D7 = 1 turns the decimal point on).
When no-decode is selected, data bits D7–D0 correspond to the segment lines of the MAX7219/MAX7221.
Intensity Control and Interdigit Blanking
The MAX7219 allow display brightness to be controlled with an external resistor (RSET) connected between V+ and ISET.
The peak current sourced from the segment drivers is nominally 100 times the current entering ISET.
This resistor can either be fixed or variable to allow brightness adjustment from the front panel.
Its minimum value should be 9.53kΩ, which typically sets the segment current at 40mA.
Display brightness can also be controlled digitally by using the intensity register.
Digital control of display brightness is provided by an internal pulse-width modulator, which is controlled by the lower nibble of the intensity register.
The modulator scales the average segment current in 16 steps from a maximum of 31/32 down to 1/32 of the peak current set by RSET.
The minimum interdigit blanking time is set to 1/32 of a cycle.
Scan-Limit Register
The scan-limit register sets how many digits are displayed, from 1 to 8.
They are displayed in a multiplexed manner with a typical display scan rate of 800Hz with 8 digits displayed.
If fewer digits are displayed, the scan rate is 8fOSC/N, where N is the number of digits scanned.
Since the number of scanned digits affects the display brightness, the scan-limit register should not be used to blank portions of the display (such as leading zero suppression).
Display-Test Register
The display-test register operates in two modes: normal and display test. Display-test mode turns all LEDs on by overriding, but not altering, all controls and digit registers(including the shutdown register).
In display-test mode, 8 digits are scanned and the duty cycle is 31/32
function wrByte(data) i=8 while (i>0) do mask = bit.lshift(0x01,i-1) --print(mask) gpio.write( CLK, 0) -- tick dser = bit.band(data,mask) if (dser > 0) then gpio.write(DIN, 1) -- send 1 --print("1") else gpio.write(DIN, 0) -- send 0 --print("0") end --endif --print(dser) gpio.write( CLK, 1) -- tick i=i-1 end --while end
3. Set Register
function setReg(reg, value) gpio.write(CS, 0)
wrByte(reg) -- specify register tmr.delay(10) wrByte(value) -- send data
gpio.write(CS, 0) --tmr.delay(10) gpio.write(CS, 1) end
4. Convert anf Print integer number in xxxx format
function print_led_int(c) th = string.format("%d",c / 1000) h = string.format("%d",(c-th*1000) / 100) t = string.format("%d", (c-th*1000-h*100) / 10) u = string.format("%d", c-th*1000-h*100-t*10) --print(string.format("%d %d %d %d", th,h,t,u)) setReg(4, th) setReg(3, h) setReg(2, t) setReg(1, u) end
5. Create a Display 'ZERO' init stage
function zero_all() v=1 while (v<9) do setReg(v,0) v=v+1 end end
6. MAX7219 Initialisation
setReg(MAXREG_SCANLIMIT, 0x07) tmr.delay(100) setReg(MAXREG_DECODEMODE, 0xFF) -- full decode mode BCD tmr.delay(100) setReg(MAXREG_SHUTDOWN, 0x01) -- not in shutdown mode tmr.delay(100) setReg(MAXREG_DISPTEST, 0x00) -- no display test tmr.delay(100) setReg(MAXREG_INTENSITY, 0x00) -- set Brightness zero_all() -- set all to ZERO
7. Test Display - 9999 counter
count=0 tmr.alarm(0,1000,1, function() count=count+1; --print(count); print_led_int(count) if (count>9999) then count=0;zero_all() end end)
