ESP8266 - no server response when sending a request via UART

Hello Colleagues,
I am struggling with the problem of sending a complete query to the weather server. This process performed from terminal RealTerm or . Terminal by Br@y++ ends with success , i.e. receiving the data sent after a while from the weather server, while executed from the processor level (via the UART) ends with no response from the server and a server timeout. I suspect that the CPU side function interprets and sends special characters in a different way, while the terminals interpret and send special characters in a different way and hence the server does not get a complete query. I will give examples below:

in RealTerm's send:

.
and after a while


selecting each time to append CR+LF at the end and I get the correct server response to such a query. Similarly in the terminal Br@y++ I send:

.
and after a while
.

So basically the same thing, I just encode the special characters in a different way. As far as the processor is concerned, I harness a simple function like the following to send:

.

which uses:

.

and I send the same as above as follows:

.
and after a while
.

And lime... The server doesn't respond but waits and waits and then reports a timeout...as if the request is not complete. Asking for suggestions, for which I thank you in advance.... robiw

Mate, I've been doing various projects on the ESP8266 and I'll say one thing. Forget about using the AT comment. I also lost a lot of time fighting with the web server. It worked as such, but after switching to the arduino interface with the ESP8266 board manager, it went away like a hand.
You program normally as in C under the arduino environment, but the code is compiled straight onto the ESP8266.

Here you will find everything : https://github.com/esp8266/Arduino

For this you have ready-made libraries.

I don't know Arduino and in fact don't want to know it. Besides, the project uses TFT and other components. I need to operate it via AT...robiw

Well, but Arduino (software) is just an overlay. After all, your code is in C+.
I'm not talking about Arduino in the context of hardware, just software.
Maybe describe exactly what you are doing and on what hardware ?

I send via USART, as I wrote. Unfortunately from the terminal it works and from the USART it doesn't want to, so it's probably a matter of special characters...robiw

Added after 3 [minutes]:

My code is in C. Besides, the same processor still supports the TFT display. Since it works on the terminal and not from the USART then the code is to blame...robiw

I experienced a problem many times when strings were too long. I don't quite know what it was related to, but I read something somewhere about a small buffer.
Try splitting the last sequence into 3 separate ones (ending lines with characters). It should help.

But since it goes from the Windows terminal without a problem, it doesn't seem to be a buffer problem. Besides, there are elements in this long string, so how would I split it? Also, what value should I then set for AT+CIPSEND=126? robiw

Please write what you are using to communicate with the ESP8266. As I understand it, in the first case it is a PC (terminal) and in the second case some external microprocessor (Raspberry or what ?). In both cases the communication is via RS232 with the ESP8266 module.Is that so?

My guess is that you want to download the predicted weather data via the wether underground service provider API.

Go here https://github.com/squix78/esp8266-weather-station. There you have everything, including the source code.

The query to the server should look like this:

client.print(String("GET ") + url + " HTTP/1.1" + "Host: api.wunderground.com" + "Connection: close");

and as far as I can see you have constructed it correctly, but I don't know if the PSTR function works correctly in this case. It is possible that you have to mark the special characters (\n) somehow.
To check this, just enter the address (not as a variable to convert to string) and see if it works.

albertb wrote:

Instead of wasting your time, our time and internet resources, send both strings to your computer and compare the received ones. Albert

.

Nothing like a brilliant answer . Problem solved, so I'll describe it here. Ah those Chinese toys...

Had to insert a small delay after sending each byte (5ms for 9600bps) then everything works beautifully. Strange, after all it should work when sending byte by byte...and yet it didn't work...robiw

There is no need to insert any delay. What version do you have of the module and what firmware?

dondu wrote:

No need to insert any delay. Which version of the module do you have and which firmware?

.

It all depends. When controlling the ESP module with AT commands from an external controller, there are often problems with this (as I wrote above) and a delay may or may not help.

I'm afraid that since we haven't got an answer so far as to what a colleague is using as a controller for the ESP module then also the version of the module itself and the firmware will remain a mystery.

I think the topic can be closed

raceman wrote:

dondu wrote:

No need to insert any delay. Which version of the module do you have and which firmware?

.

It all depends. When controlling the ESP module with AT commands from an external controller, there are often problems with this (as I wrote above) and a delay may or may not help.

.
I have not encountered any problems regarding what my colleague suggests.
Transmissions fly without any additional delay.

Perhaps this is a problem with some older firmware version, which is why I asked about it.

I'll answer, I'll answer, just need to get some free time to check. The controller is an Atmega64. Without the delay in the byte sending function it doesn't work, from the terminal it works. Robiw

@robiw .
This behaviour and the addition of delays is strange. I have a lot of experience with the ESP8266 and I will say this - the firmware for AT commands is total junk.

What I do in my projects is that I write my own firmware on the ESP, which takes care of all the network communication. For example, every minute it checks the content of a page, analyses its content and sends only processed data (e.g. temperature, state of diodes, text to be displayed on LCD, etc.) via UART to the uC. In the other direction, I similarly send a simple string, e.g. 10, to the ESP, and the ESP already knows that it has to call up the page http: //bal.bla.com/abecadlo/save.php?x=10.

I recommend this solution to you too.

I recently made a module for infrared transmission over WiFi in this way - since the ESP can't cope with decoding the codes (there are no suitable timers available) there's a tiny STM32F0 sitting in the chip, which decodes the frames and controls the transmission, and sends e.g. IR:type_transmission:code to the ESP, and similarly waits for IRSEND:type:code to transmit something. Whereas the transmission itself over UDP or TCP (including SSL encryption) and the interface to configure the device via http sits in the ESP.

I'm not familiar with the ESP software, so I don't want to write a separate programme for the module (including compiling and uploading it) and for my device, which, in addition to supporting the TFT display, also supports a keyboard, infrared, temperature sensor, etc. etc...robiw

robiw wrote:

I don't know the ESP software, so I don't want to write a separate program for the module (including compiling and uploading it)

.
It's high time to get to know. Since you are writing in C or C++ - a matter of installing under Arduino (5 minutes) and poking around in examps (30 minutes) and viola. Believe - it will be simpler than messing around with AT commands - but do as you feel

I don't like Arduino I mean Bascomino hehe. It's been a long time since I switched from Bascom to C to go back to a similar environment again...robiw

You can fire up a compiler under the command line and put the libraries under Eclipse - although then it doesn't take 5 minutes

robiw wrote:

I don't like Arduino I mean Bascomino hehe. It's been a long time since I switched from Bascom to C to go back to a similar environment again...robiw

.

Like playing chess with a pigeon. Arduino for the ESP overlay is nothing like Bascom. You program normally in C++. AND as you would like to know In ESP you have an 80Mhz processor with some cool features unlike AVR which is basically the same as the arduino boards (ATMEGA etc) you so despise.

Using AVR commands to control ESP with AT commands is .... no words.

I have to support my colleagues. Arduino (i.e. C language) is the best software for ESP. It doesn't create problems, and if you need to change a faulty ESP module in the future then it's better to re-upload your software to it, rather than worry about differing firmware (AT commands). If someone wants to create several devices, you may find that they work differently because they are from different manufacturers and have different firmware. Many things can be done directly on the ESP, but if one wants or needs to, just use the UART, over which one's own tailored communication goes, rather than AT.
And one more note - I suggest using the http 1.0 protocol rather than 1.1. Some servers can get tricky when sending in 1.1. Especially troublesome is "Chunked transfer-coding"

I don't despise anything, that's the first thing. Secondly I was referring to Arduino itself in terms of syntax like Serial.Find and the like, i.e. using off-the-shelf, libraries etc...but I don't want to start a language war here. I need more than 20 ports in my project, so I need to use an external controller especially since I'm programming in C on an AVR (not C++). So much roughly...robiw

The software version is:

AT - 0.25.0.0.

SDK - 1.1.1

Well, it's a mega old version of both AT and SDK.