Trouble with FTP

10 thoughts on “Trouble with FTP

  1. Hi,

    I have a trouble with FTP transfer.

    My handheld terminal  transfer its data to a Filezilla Server every day using the PUT ftp command. I have about 500 terminal in use in europe, and I have seen that sometimes the server store only 300 byte of data.

     

    I transfer the data with a PUT command then send a +++ command and again a new PUT command with a new file name and a zero length file. This latest file is for sincronize our software in order to process the data file.

     

    Our terminal send data every day,so we transmit more than 10000 file/month and I have seen that in a month we can have 50-60 corrupted file with a length of 300 bytes or multiple of it.

     

    30-40 files ahve no the confirmation file, so the CPU of the handheld has received an error from the GC864 and have retransmit the data. But 20-30 file are marked as OK and the handheld CPU has sent the validation file, and has DELETE all the records in its memory.

     

    I have seen this with GE863 and GC864 QUAD V2, all files corrupted have a length of 300 bytes or multiple of it

    Most of our terminal have a TIM simcard, but we have also with a Telit M2M simcard and also these have had   the trouble.

     

    Please help me.

     Marco

      1. Hi Marco, how large are the files and do you use hardware flow control between CPU and module?

        The file dimension could change from 100 bytes to 40Kbytes and I have seen the trouble in file from 800 Bytes to 5-6 KBytes. I don’t use HW flow control, but XON/XOFF flow control.

         

        BR

        marco 

        1. Software flow control is not working for TCP/IP/IPEasy, hardware flow control is required. Probably this is why you are loosing data from time to time.

          1. Software flow control is not working for TCP/IP/IPEasy, hardware flow control is required. Probably this is why you are loosing data from time to time.

            Hi Cosmin,

            I have used the XON/XOFF because I have seen that the XOFF command arrive from modem. I have sent also 50 KBytes at 115K and I have seen that the CPU stop itself when arrive an XOFF. I have some customer that always transmit more than 20K and they haven’t had any trouble. Do you know the modem buffer capacity of the module ? I have read somewhere is 4096 bytes, if this is right I must have the trouble only on file larger than 4096 bytes, but I have the trouble also with smaller files.

             

            In my opinion I think that if was an XOFF/XON trouble I must see also some files with some hole (in the data) in the middle of the file; but I see only files trunked to 300 bytes or multiple.

             

             BR

            marco 

          2. 300 because that’s the default packet size used for FTP upload, see AT#FTPCFG. I think there isn’t any buffering during online transfers so one must rely on hardware flow control.

          3. 300 because that’s the default packet size used for FTP upload, see AT#FTPCFG. I think there isn’t any buffering during online transfers so one must rely on hardware flow control.

            Hi Cosmin,

            so I must check the DTR pin in order to transfer data from CPU to MODEM ?

             

            BR

            marco 

          4. 300 because that’s the default packet size used for FTP upload, see AT#FTPCFG. I think there isn’t any buffering during online transfers so one must rely on hardware flow control.

            Hi Cosmin,

            so I must check the DTR pin in order to transfer data from CPU to MODEM ?

             

            BR

            marco 

            Excuse me Cosmin, but I don’t find the AT#FTPCFG command in the AT command reference rev 13

             

            Many thx

            marco 

  2. That one is well outdated, the current revision is r20.

     

    — but take care about the synchronization between modules’ firmware versions and doc revisions numbers.