+CME ERROR: 583

6 thoughts on “+CME ERROR: 583

  1. Hello

     

    The Documentation (80378ST10091A Rev. 4 – 2012-07-02, or 80000ST10025a Rev. 15 – 2012-10-18) do not mention +CME 583. Is that the latest documentation ?

     I’m getting the following error, can you enlighten me please:

    AT#FTPRECV=128
    +CME ERROR: 583

    With the following modem:

    AT+CGMR
    13.00.001

    OK
    AT+CGMI
    Telit

    OK
    AT+CGMM
    GE910-QUAD

    OK
    AT+CGSN
    351732050205023

     

    Thank you, Olivier

    1. Hello

       

      I just had an other occurrence of the 583 error. Attached is the complete log of the modem echo.

       

      I’m also wondering why we are getting 606 errors quite often. After retrying things come right most of the time though.

       

      Kind Regards, Olivier

  2. Hello

    After AT#FTPRECV we have meanwhile seen the following errors (We do not know how to interpret 22, 47, 107, 583 & ERROR):
    ERROR
    +CME ERROR: 583
    +CME ERROR: 614
    +CME ERROR: 603
    +CME ERROR: 609
    +CME ERROR: 107
    +CME ERROR: 47
    +CME ERROR: 30
    +CME ERROR: 22

    Regards, Olivier

    1. we need to clarify how FTPrecv works:

      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?

      answer #FTPGETPKT: filename,1,1 means: complete file has been transferred to FTP client
      answer #FTPGETPKT: filename,1,0 means: file currently being transferred

      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

  3. Hello

     

    I still do not know what  EASY_SERV_OPT_NOT_SUPPORTED means. It does not look like it is related to what I do with the FTP-get operation or the GSM / GPRS connection failing (see telit_ftp_04_log.txt).

     

    AT#FTPGETPKT="UGD2-Test002.GAL",1

    OK

    AT#SLED=3,1,3

    OK

    AT+CSQ

    +CSQ: 7,0

     

    OK

    AT#FTPRECV=128

    #FTPRECV: 80

    040C06010102030405060708090A0B0C010101010101010101010101010101010201010101010101

    01010101010101010301000001010101010000010101010109160000161616161600001616161616

     

     

    OK

    AT#FTPRECV=128

    #FTPRECV: 0

     

     

    OK

    AT#FTPRECV=128

    +CME ERROR:
    583

    AT#FTPGETPKT?

    #FTPGETPKT:
    UGD2-Test002.GAL,1,1

     

    Same with +CME ERROR:47 (corporate personalization PUK required). Why would the a PUK be required, just once, in the FTP-get operation ?

    AT#FTPGETPKT="UGD0-Test002.GAL",1

    OK

    AT#SLED=3,1,3

    OK

    AT+CSQ

    +CSQ: 8,0

     

    OK

    AT#FTPRECV=128

    #FTPRECV: 128

    090C06010102030405060708090A0B0C010101010101010101010101010101010201010101010101

    01010101010101010301000001010101010000010101010104020202020202020202020202020202

    05131314000C0C0C0C0C0C00000F0F0F060C0C0C0C00000F0F0F0F0F0F000011070F0F0F0F0F0F00

    0011131313131314

     

    OK

    AT#FTPRECV=128

    #FTPRECV: 32

    08000011131313131314000C0C0C0C0C09160000161616161600001616161616

     

    OK

    AT#FTPRECV=128

    +CME ERROR:
    47

    AT#SLED=2

    OK

    AT+CSQ

    +CSQ: 8,0

     

    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 file
    telit_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+CGMR
    13.00.002

    OK
    AT+CGMI
    Telit

    OK
    AT+CGMM
    GE910-QUAD

    OK
    AT+CGSN
    351732050205023

    OK

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

     

    Kind Regards, Olivier

  4. Hello

    What does EASY_SERV_OPT_NOT_SUPPORTED mean and what has it got to do with GSM / GPRS connections or FTP-get?

    AT#FTPGETPKT="UGD2-Test002.GAL",1

    OK
    AT#SLED=3,1,3
    OK
    AT+CSQ
    +CSQ: 7,0

    OK
    AT#FTPRECV=128
    #FTPRECV: 80
    040C06010102030405060708090A0B0C010101010101010101010101010101010201010101010101
    01010101010101010301000001010101010000010101010109160000161616161600001616161616

    OK
    AT#FTPRECV=128
    #FTPRECV: 0
     

    OK
    AT#FTPRECV=128
    +CME ERROR: 583
    AT#FTPGETPKT?
    #FTPGETPKT: UGD2-Test002.GAL,1,1

    OK

    Also why do I get a +CME ERROR: 47 (corporate personalization PUK required) in an FTP-get operation, just once at a random time?

    AT#FTPGETPKT="UGD0-Test002.GAL",1

     

    OK
    AT#SLED=3,1,3

    OK
    AT+CSQ
    +CSQ: 8,0

    OK
    AT#FTPRECV=128
    #FTPRECV: 128
    090C06010102030405060708090A0B0C010101010101010101010101010101010201010101010101
    01010101010101010301000001010101010000010101010104020202020202020202020202020202
    05131314000C0C0C0C0C0C00000F0F0F060C0C0C0C00000F0F0F0F0F0F000011070F0F0F0F0F0F00
    0011131313131314

    OK
    AT#FTPRECV=128
    #FTPRECV: 32
    08000011131313131314000C0C0C0C0C09160000161616161600001616161616

    OK
    AT#FTPRECV=128
    +CME ERROR: 47
    AT#SLED=2
    OK
    AT+CSQ
    +CSQ: 8,0

    OK

    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.

     

    The Modem version is:

    AT+CGMR
    13.00.002

    OK
    AT+CGMI
    Telit

    OK
    AT+CGMM
    GE910-QUAD

    OK
    AT+CGSN
    351732050205023

    OK

    The basic procedure is like in the log posted "telit_ftp_04_log.txt"

    Kind Regards, Olivier