Problems with new SMTPCL command

17 thoughts on “Problems with new SMTPCL command

  1. Hi Telit Forum,

    I’m using a GC864-QUAD V2 with recently
    upgraded firmware 10.00.054, and am trying to send email with
    attachments using the AT#SMTPCL command.

    This is a new addition to
    the command set (only described in the latest AT Command Reference
    Guide r10), and I cannot seem to get the command to return after the
    escape sequence (+++<CR>).

    I can get it past the body text
    phase, and the CONNECT phase, but when I send the attachment text (after
    receiving the CONNECT message), and then finish the escape sequence
    with +++<CR>, it just sits there and does nothing.

    I poll
    the response from the module for 200 seconds, and there’s no response.  I
    would have thought this would be plenty of time for it to send the body
    text, attachment and return with a NO CARRIER response.

     

    After
    polling and getting no response for 200 seconds,  the controller
    sending commands to the GC864 stops waiting and goes on to try and
    re-send another email thru the GC864.  However, now the GC864 is frozen,
    and won’t give any responses at all, and the controller has to power it
    down and back up again to get it functional again.

     

    Has anyone else had this problem?

     

    Cheers,

    Glen Johnston

    1. +++ is not an AT command that has to be terminated with <CR>

      Is
      a sequence of three + characters that need a timeguard before and after
      the sequence to be recognized as valid. See also ATS12 description
      about the timeguard.

      <S12pause>+++<S12pause>

      1. Hi Cosmin,

        Great advice.  I hadn’t realised there were such timing provisos around the escape sequence.

        I’ve incorporated it into the controller code, and now I’m sending email attachments no problems.  Many thanks.

        However, having got that working, I’ve noticed another problem seems to occur: I’m sending file sizes of ~ 4000 characters, and I’m finding that there’s a ‘!’ and <CR> being inserted in the text stream at several positions in the text.  One text file of 3,826 characters had the !<CR> insertions at positions 988, 989 and 1058.

        I’ve come across this previously using the EMAILD command, where the body text also had this !<CR> combination inserted at much the same positions in the text stream. 

        I’ve been hunting through the controller code to see if there’s any point at which it could be inserting such anomalies, but haven’t found anything yet.

        Have you seen such behaviour before?

        Many thanks,

        Glen

         

        1. Hi Glen,

           

          What type of file is, and are you seeing this systematically? Are you using flow control on serial port?

           

          1. Hi Cosmin,

            I’m just streaming a text array from an embedded controller into the UART of the GC864 once the CONNECT response has been received from the SMTPCL command.

            Yes, it is systematic – happens without fail.  I’ve been putting debug print lines in the embedded controller code to test the text stream before it gets sent to the GC864, but no !<CR> seems to appear.

            No, I’m not using any flow control on the UART comms between the embedded controller and the GC864.

            Following is a typical received text stream in an attached text file from the GC864, and I’m also attaching the text file itself as sent from the GC864.  Note that there’s 3 sets of !<CR> (there are no exclamation marks in the original text stream) :

             

            204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/!
             -13108 0:204:204204/204/-13108 204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204!
             204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 !
             0:204:204204/204/-13108 204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108 0:204:204204/204/-13108

             

            Not sure what’s going on.  Any advice appreciated.

            Cheers,

            Glen

          2. Hi Cosmin,

            I thought I had responded to your last query, but I can’t see it in the thread.

            In answer to your questions:

            1.  The file type is simply streamed text, sent by the embedded controller to the GC864 UART, once the CONNECT response has been received from the SMTPCL command.  I’m attaching a copy of the received atached text file that I get from the GC864. You’ll see there are 3 instances of the !<CR> insertion.  There are no exclamation marks in the original text stream.

            2.  Yes, this behaviour happens every time there’s more characters than ~988.

            3.  No, I’m not using flow control on the serial comms between the embedded controller and the GC864.

            And thoughts?

            Cheers,

            Glen

          3. Hi Glen,

             

            I’ll try with your file on Monday and let you know.

            Hi Cosmin,

            Just wondering if you may have been able to test sending that Attach.txt file I sent over?

            Cheers,

            Glen

  2. Hi Glen, just finished testing. There are no "!" inserted in attached files, only some line separators as 7-bit MIME for text files requires:

     

    7-Bit data
    7-bit data refers to data that is represented by relatively
    short lines with 998 octets or less between Carriage Return Line Feed (CRLF)
    line separation sequences. Octets with decimal values greater than 127 are
    not permitted, and neither are "NULL" octets (octets with a decimal equivalent of 0).

    1. Hi Glen, just finished testing. There are no "!" inserted in attached files, only some line separators as 7-bit MIME for text files requires:

       

      7-Bit data
      7-bit data refers to data that is represented by relatively
      short lines with 998 octets or less between Carriage Return Line Feed (CRLF)
      line separation sequences. Octets with decimal values greater than 127 are
      not permitted, and neither are "NULL" octets (octets with a decimal equivalent of 0).

      Hi Cosmin,

      OK, interesting result.  It seems you are seeing some line separators  at approximately the same positions as I’m getting ‘! <CR>’ insertions.  What are line separators, BTW?

      I’ve actually got <CR>’s  at the end of the lines of data, and these would be less than 998 characters, and this should stop the MIME boundaries being triggered. I’m wondering if the <LF> character (Chr(10)) also needs to be included in these line ends?

      Could you please advise if the Telit implementation of the MIME protocol requires both <CR><LF> at the end of text line in order for the line to be properly terminated, or whether a <CR> on its own will be interpreted the same way?

      Your help appreciated.

      Glen

       

      1. I see the specs are clear, CRLF pair; I’ll try to obtain specifics from RD next week.

         

      2. Hi Cosmin,

        You’ve hit it!  I’ve put in <CR><LF> pairs at the end of each data line, and the "! <CR>" insertions have dissappeared, and the attached text file looks perfect.

        I’ve also tested with just <LF> alone, and everything still works fine.

        If I put <LF><CR> at the end of the lines, it also eliminates the "! <CR>" insertions, but each line is separated by an empty new line.

        So, the rule is: either <LF> or <CR><LF>, but not <CR> on its own or <LF><CR>.

        Many thanks.

        I think we can close this thread.

        Cheers,

        Glen

  3. OK I did a test again a few moments ago.

    – I sent your file with "!" and CR removed "Attach.txt"

    -received the file with CRLF inserted at positions 990, three times "sample1.txt"

    – sent file "sample1.txt", which conforms with 7-bit MIME

    – received "sample2.txt", identical with "sample1.txt"

     

    So #SMTPCL inserts needed CRLF pairs at positions 990 if needed.

     

     

    1. OK I did a test again a few moments ago.

      – I sent your file with "!" and CR removed "Attach.txt"

      -received the file with CRLF inserted at positions 990, three times "sample1.txt"

      – sent file "sample1.txt", which conforms with 7-bit MIME

      – received "sample2.txt", identical with "sample1.txt"

       

      So #SMTPCL inserts needed CRLF pairs at positions 990 if needed.

       

       

      Hi Cosmin,

      You’ve hit it!  I’ve put in
      <CR><LF> pairs at the end of each data line, and the "!
      <CR>" insertions have dissappeared, and the attached text file
      looks perfect.

      I’ve also tested with just <LF> alone, and everything still works fine.

      If
      I put <LF><CR> at the end of the lines, it also eliminates
      the "! <CR>" insertions, but each line is separated by an empty
      new line.

      So, the rule is: either <LF> or <CR><LF>, but not <CR> on its own or <LF><CR>.

      Many thanks.

      I think we can close this thread.

      Cheers,

      Glen

  4. tryed use at#smtpcl command for send e-mail with attachment

    I put 

    AT#SMTPCL=”xxx@mail.ru”,”pasw”,2,”file.bin”,1

    after CONNECT send to modem file encoded to Base64

    Receiving e-mail from modem. In attachment I see file. But when I open attachment file Outlook Express just open file without decoding from Base64 to bin. What is problem ? Please advic

    1. Please attach a small file encoded in base-64 by your application, something usable like an image, and the result received by Outlook.