suppose that we are in a condition that the file has been completely read/downloaded with consecutive at#FTPRECV, and the FIN message – generated by the server to signal the end of file downloading – has not arrived to the module yet.

In this condition there are no data to read in our stack, because all data were read with the previous ftprecv requests. In this condition, if you would be able to issue another at#ftprecv you would get 0 .

But often it happens that the server sends the FIN message to the module before you can issue another FTPRECV. In this case the FIN message coming to the module, causes the closing of the data port.So if you send an FTPrecv after the FIN reception, you’ll get logically the ERROR message

What you need probably is an end of file flag on the read responses that changes from a 0 to 1 once all data has been read. And this is already available: it is in the at#ftpgetpkt? request.

We suggest this because it could happen that you could receive ftprecv=0 also in conditions not corresponding to the complete file downloading.e.g.: if you are out of coverage for some time (or data suspending for cell reselection) you could have downlaoded all the data available in the local module stack, but there are still other pending data in the net to download to the module when the coverage will be again recovered.In this case you could get 0 after issued ftprecv, but you have still more file data to downlaod!

So the best thing is to check the EOF with at#ftpgetpkt? to decide when the file downlaoding has completed.at#ftpgetpkt?

Another method could be: to read the file dimension with at#ftpfsize and then check the size od data downlaoded with every ftprecv requests and detect when it’s not more necessary to issue at#ftprecv and finally check the eof with at#ftpgetpkt? and probably there are other methods that you could implement.

The list of errors you post is not useful to have a diagnosis. If it’s a question about their meaning , I have already written in a separated e-mail that 583 means EASY_SERV_OPT_NOT_SUPPORTED. About the meaning of the other errors, please read

the following paragraph of the AT commands reference guide: "ME Error Result Code – +CME ERROR: <err>".

Regarding the reasons why you get these errors, please post here (I have seen you prefer this channel) your logs and your SOURCE code controlling the module, if you will not be able to detect by yourself their cause

My customer was unable to supply a complete log and I could not reproduce all of these error at MicroPoint. Basically the commands would be like the ones in the posted filetelit_ftp_04_log.txt with the 583 replaced by any of the mentioned
errors.

At the present our code checks if there is any error after AT#FTPRECV=xxx and if there is we issue AT#FTPGETPKT? to see if the file is at the end.

I think that works pretty well because the file is at the end after an error (#FTPGETPKT: xxxxxxxx,1,1).

The modem version is:

AT+CGMR13.00.002

OKAT+CGMITelit

OKAT+CGMMGE910-QUAD

OKAT+CGSN351732050205023

OK

Basically I like to be assured that this is how the modem is is supposed to operate.

Basically I like to know if these are all errors I have to expect in this situation. I can understand that 606, 609, 614 and some other connection related errors would happen especially with week connections but why would 22, 47, 107, 583 & ERROR occur.