Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
esp8266_wifi_modules [2014/10/31 16:16] karl |
esp8266_wifi_modules [2017/04/04 06:42] (aktuell) karl [Notes] |
||
---|---|---|---|
Zeile 8: | Zeile 8: | ||
This module supports TCP and UDP, both as a server or a client, which is pretty awesome! | This module supports TCP and UDP, both as a server or a client, which is pretty awesome! | ||
+ | Version 2 has an IPEX (U.FL) connector. A possible antenna coudl be this one from [[http:// | ||
===== Documentation Sites ===== | ===== Documentation Sites ===== | ||
http:// | http:// | ||
https:// | https:// | ||
+ | |||
+ | ===== My experience ===== | ||
+ | 2.12.2014 | ||
+ | |||
+ | ==== Schematic for testing ==== | ||
+ | [[http:// | ||
+ | [[http:// | ||
+ | [[http:// | ||
+ | |||
+ | ==== Communication ==== | ||
+ | I'm using CuteCom on / | ||
+ | The USB-UART chip is a CH340G from WCH. It is recognized by Kubuntu without any driver installations. | ||
+ | For direct communication from the PC to the WiFi module, the ATmega-328 is disabled by pulling the RST-line to GND. | ||
+ | |||
+ | |||
+ | On power up we get this message on the CuteCom terminal: \\ | ||
+ | |||
+ | \0xc8DtP\0xa4\0xf8B\0xb6E\0xb4\0x86\0xc8`CXR\0xc0D\0xd0\0x04ixI\0xc0M\0xf9\0xe0: | ||
+ | [Vendor: | ||
+ | | ||
+ | ready | ||
+ | |||
+ | === Join a WiFi access point === | ||
+ | AT+RST | ||
+ | OK | ||
+ | V\0x08\0x88\0xa0\0xd1\0x0c)B\0xeb`!\0x8e\0xc7\0x9c\0x8c\0xc7J\\0x08\0x80\0xfc | ||
+ | [Vendor: | ||
+ | ready | ||
+ | AT+CWMODE=3 | ||
+ | no change | ||
+ | |||
+ | AT+RST | ||
+ | OK | ||
+ | \0xa5\0xfcv\0x8c\0xff\0x08\0xa9\0xfc@F\0x01 | ||
+ | (\0xe2\0x9e\0x9a*\0x87F\0xe5\0xfc | ||
+ | [Vendor: | ||
+ | ready | ||
+ | Look for access points: | ||
+ | AT+CWLAP | ||
+ | +CWLAP: | ||
+ | OK | ||
+ | Join access point (******** is shared key): | ||
+ | AT+CWJAP=" | ||
+ | OK | ||
+ | Check if it is connected: | ||
+ | AT+CWJAP? | ||
+ | +CWJAP:" | ||
+ | OK | ||
+ | |||
+ | === Ping it === | ||
+ | In order we can ping the module, we have to find out the IP address. This we get either by looking into the webinterface of the accesspoint, | ||
+ | AT+CIFSR | ||
+ | 192.168.4.1 | ||
+ | 10.0.0.2 | ||
+ | OK | ||
+ | |||
+ | I think, the first IP address is an internal IP address of the module. The second one is the IP address, that the DHCP on the access point assigned to the module. \\ | ||
+ | When we open a terminal on Kubuntu and ping it: | ||
+ | karl@lenovo-w520: | ||
+ | PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. | ||
+ | 64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=67.1 ms | ||
+ | 64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=294 ms | ||
+ | 64 bytes from 10.0.0.2: icmp_seq=3 ttl=255 time=214 ms | ||
+ | 64 bytes from 10.0.0.2: icmp_seq=4 ttl=255 time=135 ms | ||
+ | 64 bytes from 10.0.0.2: icmp_seq=5 ttl=255 time=61.2 ms | ||
+ | 64 bytes from 10.0.0.2: icmp_seq=6 ttl=255 time=279 ms | ||
+ | 64 bytes from 10.0.0.2: icmp_seq=7 ttl=255 time=200 ms | ||
+ | 64 bytes from 10.0.0.2: icmp_seq=8 ttl=255 time=326 ms | ||
+ | 64 bytes from 10.0.0.2: icmp_seq=9 ttl=255 time=42.1 ms | ||
+ | 64 bytes from 10.0.0.2: icmp_seq=10 ttl=255 time=482 ms | ||
+ | 64 bytes from 10.0.0.2: icmp_seq=11 ttl=255 time=195 ms | ||
+ | 64 bytes from 10.0.0.2: icmp_seq=12 ttl=255 time=111 ms | ||
+ | 64 bytes from 10.0.0.2: icmp_seq=13 ttl=255 time=32.7 ms | ||
+ | ^C | ||
+ | --- 10.0.0.2 ping statistics --- | ||
+ | 13 packets transmitted, | ||
+ | rtt min/ | ||
+ | As we can see, the average response time of 188ms is quite long. But hey, I don't want to use the module for high speed low latency applications. I want to measure temperature and switch on or off a heating system. | ||
+ | |||
+ | ==== Testing it as a TCP client ==== | ||
+ | |||
+ | < | ||
+ | AT+RST | ||
+ | |||
+ | |||
+ | OK | ||
+ | ? | ||
+ | \0xff | ||
+ | [Vendor: | ||
+ | |||
+ | ready | ||
+ | AT+CWJAP=" | ||
+ | |||
+ | |||
+ | OK | ||
+ | AT+CIPSTART=" | ||
+ | |||
+ | |||
+ | OK | ||
+ | Linked | ||
+ | AT+CIPSEND=43 | ||
+ | |||
+ | > GET / | ||
+ | |||
+ | SEND OK | ||
+ | AT+CIPSEND=30 | ||
+ | |||
+ | > Host: www.zeilhofer.co.at: | ||
+ | |||
+ | SEND OK | ||
+ | AT+CIPSEND=2 | ||
+ | |||
+ | > | ||
+ | |||
+ | SEND OK | ||
+ | |||
+ | +IPD, | ||
+ | Date: Tue, 02 Dec 2014 13:46:03 GMT | ||
+ | Server: Apache | ||
+ | Connection: close | ||
+ | Transfer-Encoding: | ||
+ | Content-Type: | ||
+ | |||
+ | 14 | ||
+ | Hello World!< | ||
+ | |||
+ | |||
+ | |||
+ | OK | ||
+ | |||
+ | +IPD,5:0 | ||
+ | |||
+ | |||
+ | OK | ||
+ | </ | ||
+ | |||
+ | As we can see, we get the desired response from the webserver. | ||
+ | The HTTP message body is " | ||
+ | A chunk is terminated with a < | ||
+ | |||
+ | Lets decode the message above in details: | ||
+ | |||
+ | +IPD,170: | ||
+ | this is sent from the WiFi module, and tells the terminal, that data from the open TCP connection is received. The data has 170 bytes. | ||
+ | HTTP/1.1 200 OK< | ||
+ | 17 bytes: This is the HTTP status line. For details click here: http:// | ||
+ | \\ | ||
+ | The line is terminated with < | ||
+ | Date: Tue, 02 Dec 2014 13:46:03 GMT< | ||
+ | 37 bytes: From the server we get the current date and time | ||
+ | Server: Apache< | ||
+ | 16 bytes: The server tells us, that it is an Apache server. | ||
+ | Connection: close< | ||
+ | 19 bytes: The connection is closed by the server after the message is transmitted. This is because we did not tell the server to keep the connection alive (we could add **Connection: | ||
+ | Transfer-Encoding: | ||
+ | 28 bytes: the message body is transmitted in chunks. | ||
+ | Content-Type: | ||
+ | < | ||
+ | 2 bytes: end of http-message-header\\ | ||
+ | Body: | ||
+ | 14< | ||
+ | 4 bytes: hexadecimal block length = 20 decimal | ||
+ | Hello World!< | ||
+ | < | ||
+ | 20 bytes message body. | ||
+ | < | ||
+ | 2 bytes empty line, which terminates the first chunk | ||
+ | < | ||
+ | |||
+ | |||
+ | |||
+ | OK | ||
+ | |||
+ | +IPD,5:0 | ||
+ | |||
+ | |||
+ | OK | ||
+ | </ | ||
+ | |||
+ | ===== TCP Server Example ===== | ||
+ | **Attention: | ||
+ | |||
+ | < | ||
+ | AT+RST | ||
+ | OK | ||
+ | c_\0xc7\0xcfRS\0xfe\0xe2FjS\0xf6fJ[\0xfa\0xe2\0xea | ||
+ | [Vendor: | ||
+ | ready | ||
+ | |||
+ | AT+CWJAP=" | ||
+ | OK | ||
+ | |||
+ | AT+CIPSTATUS | ||
+ | STATUS:5 | ||
+ | OK | ||
+ | |||
+ | AT+CIPMUX=1 | ||
+ | OK | ||
+ | |||
+ | AT+CIPSTATUS | ||
+ | STATUS:5 | ||
+ | OK | ||
+ | |||
+ | AT+CIPSERVER=1, | ||
+ | OK | ||
+ | |||
+ | AT+CIPSTATUS | ||
+ | STATUS:5 | ||
+ | OK | ||
+ | |||
+ | Link | ||
+ | |||
+ | AT+CIPSTATUS | ||
+ | STATUS:3 | ||
+ | +CIPSTATUS: | ||
+ | OK | ||
+ | |||
+ | +IPD, | ||
+ | |||
+ | OK | ||
+ | |||
+ | STATUS:3 | ||
+ | +CIPSTATUS: | ||
+ | OK | ||
+ | |||
+ | AT+CIPSEND=0, | ||
+ | > Hello Lenovo, thank you very much for your request | ||
+ | SEND OK | ||
+ | |||
+ | +IPD, | ||
+ | OK | ||
+ | |||
+ | Unlink | ||
+ | |||
+ | AT+CIPSTATUS | ||
+ | STATUS:4 | ||
+ | OK | ||
+ | </ | ||
+ | |||
+ | A server is opened on a specific port. To this port there can be up to 5 connections in parallel, TCP and UDP mixed. When responding, we have to set the ' | ||
+ | |||
+ | If we have multiple incomint TCP-connections from one client (multiple processes), we get multiple connections in the CIPSTATUS-list. Each with it's own reply port. \\ | ||
+ | But if we get multiple UDP connections from one client (also different client-processes), | ||
+ | |||
+ | ==== CIPSTATUS Example ==== | ||
+ | < | ||
+ | AT+CIPSTATUS | ||
+ | STATUS:3 | ||
+ | +CIPSTATUS: | ||
+ | +CIPSTATUS: | ||
+ | +CIPSTATUS: | ||
+ | OK | ||
+ | </ | ||
+ | |||
+ | Here I opened 4 instances of the application " | ||
+ | |||
+ | ===== Notes ===== | ||
+ | When we close the server with | ||
+ | AT+CIPSERVER=0 | ||
+ | , then the module has to be resetted! | ||
+ | |||
+ | As far as I know, we cannot find out, on which port the server was opened. | ||
+ | |||
+ | We can find the own IP address with | ||
+ | AT+CIFSR | ||
+ | . Note, that there is no questionmark! | ||
+ | |||
+ | |||
+ | {{tag> | ||
+ | |||