Здравейте,
разцъквам въпросните модем и се натъкнах на проблем.
Командата AT+QIRD=0,1,0,1024 не взема под внимание последния параметър, дължината на данните които се четат. Парсва го, и ако не е в допустимия интервал дава грешка. Но независимо от стойността му, връща всичко което е в буфера.
А ако е 0 връща допълнително след като се изпратят данните +IRQD: xxx, xxx, 0 където xxx са сумарно приетите данни през сесията.

Някой да знае нещо по въпроса?
Няколко пъти минавам чарашафите по въпроса но нямам обяснение защо така се случва.

5.3.2. Retrieve the received data via AT command
The module in this mode, compared with the above mode, outputs a URC ‘+QIRD:’ to inform the user that
TCP/UDP data has been received and user can retrieve the data by command AT+QIRD. This mode is not
supported by default. Execute command AT+QINDI=1 to enable this mode before the TCP/UDP
connection is established. An example when the module receives the data in this mode is shown as below.
Suppose the module receives the TCP data below from the remote end:
"1234567890abcdefghijklmnopqrstuvwxyz"
+QIRDI:0,1,0 //The module receives the data based on Context 0, and the module acts as
the client.
Now retrieve data by the following command.
AT+QIRD=0,1,0,1024 //Retrieve the data from the module’s socket buffer. The maximum length to
retrieve is 1024. If the data length in the buffer is less than 1024, retrieve all
the data from the buffer.
+QIRD:116.228.146.250:7070,TCP,36<CR><LF>
1234567890abcdefghijklmnopqrstuvwxyz
It is recommended to use AT+QIRD to read all received data when there is ‘+QIRD:’ arrived.
5.4. Close connection
When AT+QIMUX=0, after establishing TCP or UDP connection, close connection as below.
AT+QICLOSE // Close the session with the remote server.
CLOSE OK
When AT+QIMUX=1, after establishing TCP or UDP connection, use AT+QICLOSE=<index> to close
one connection as below.
AT+QICLOSE=0 // Close the session with the remote server.
0, CLOSE OK
Note:
When connection is established as a server, it is needed to select and control server connection or client
contention by AT+QISRVC.
5.5. Deactivate PDP context
Use AT+QIDEACT command to deactivate current PDP context.
AT+QIDEACT // If the context will not be used in a long period (for example more
than one hour), it’s recommended to close this context by
command AT+QIDEACT. Normally the response time for this
command is about 2-5 seconds. But when the network is very

Уф мерси,
ще се гръмна. Събрали са се два фактора.

Вместо AT+QINDI=1 съм пращал AT+QINDI=0.

При тази ситуация данните ми излизат директно на порта. Ама ги прочитам чак като почна да чакам отговора на AT+QIRD=0,1,0,1024.

Експериментирам с една малко изчанчена организация на работата с модема, че затова.

Да не отварям нова тема.
С AT+QIFGCNT си избирам активния контекст. И си работя с него нататък.
Но не схващам защо имам 2 контекста и на практика за какво може да бъде ползвано това.

Някой ден може да ти се наложи да ползваш 2 или повече различни връзки едновременно. Примерно през различни APN-и. Ако не на теб, на други понякога им се налага. За по-лесно в стековете се ползват контексти.
Избираш един контекст, настройваш си го, вдигаш някаква връзка... Ако искаш да вдигнеш втори, избираш друг свободен, настройваш си го него като междувременно първия си бачка и по всяко време може да ги превключваш (ако искаш).
Просто с контексти е по-лесно, защото в тях се запомнят разни настройки...

едит: Между другото Quectel имат малко различно виждане на тема как се буферират и затватят сокети. В случай че ползваш буферите им, да знаеш че отстреща сървъра като затвори сокета и пристигне нотификацията модема си чисти буферите... (освен ако учтиво не ги помолиш да не го правят).

Миро, нящо не разбрах едита - след FIN-ASK за какво са ти буферите и сокета

те самите буфери на мен не ми трябва, трябват ми данните в тях
Примерно не всички HTTP сървъри признават connection: keep-alive. Като получат заявка, връщат ти отговора и ти затварят сокета. Това си е съвсем легално поведение... При тая ситуация куйктела забърсва буферираните данни и ти казва "чао-чао". Дефактно така направено не може да ползваш буфериране, защото има ситуации в които изобщо не виждаш никакви данни. Примерно тествали сме го и с малко данни и изобщо не идва никаква нотификация за данни, вижда се само чао-чао и толкоз

Това беше интересно инфо. Вероятно щях да я настъпя тази мотика

значи специално за M95, M66:
Правил съм HTTP и HTTP Long Polling с MCU + АТ команди ,
и с OpenCPU ( и през RIL и през Socket API ) и всичко си е било наред при условие, че апача "винаги" затваря (ако не го "помоля")
Настъпил съм само на една мотика: POST с дължина 0 (а това си е прост GET) - дава грешка

мда, ако не ползваш буфериране (AT+QINDI=0 мисля беше) може и да работи. Всъщност имаше и други предложения на съпорта, но не сме тествали и не знам дали работят. Нас ни кефи повече с буфериране

а за някой "прости" HTTP заявки има и такива решения:
AT+QHTTPURL Set HTTP Server URL
AT+QHTTPGET Send HTTP GET Request
AT+QHTTPREAD Read HTTP Server Response
AT+QHTTPPOST Send HTTP POST Request
AT+QHTTPDL Download file from HTTP server

Да не отварям нова тема.
Сблъсках се със следния проблем.
Конекция с индекс 0 не може да отвори SSL връзка с авторизация. На всички останали индекси 1..5 си работи.
SSL без авторизация работи без проблем на индекс 0.
Някой да знае нещо по въпроса?