CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug Reports on this forum. Send them to support@ccsinfo.com

Send file FTP with SIM900
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Orcino



Joined: 07 Sep 2003
Posts: 56

View user's profile Send private message

Send file FTP with SIM900
PostPosted: Fri Jul 14, 2017 7:11 am     Reply with quote

Hello guys,

I need to send some data coming from a PC to an FTP server, through the PIC a SIM900D module.

The data is sent in packets of 1024 bytes via serial to the PIC, which stores in a buffer and sends via SIM900D to the FTP server.

For testing, I'm sending text files.

The file is sent, but arrives out of order.

The buffer size in the PIC is 1024. Could this be a problem ?

Code:

#include <24FJ128GB204.h>
#build (stack=256)
#device PASS_STRINGS=IN_RAM


Code:

#define sizeBufferBT   1024

char  bufferRxBT[sizeBufferBT];



Code:


for(i=0; i < numberPackets; i++)
      {           
          if(sendComandoAT(ATFTPPUT2_1024,respFTPPUT2,20000)) // send AT+FTPPUT=2,1024
                  fputs(OK_SEND_PCTE,BT);                     // Requests the PC The sending of the bytes
       
          while((flagBufferRead==0)  && (++ timeOutRx < 5000) )  // Wait for the buffer to fill
                {                                                     
                delay_ms(1);
                }
       
          delay_ms(200);
       
          for(contBytes=0;contBytes < 1024; contBytes++)
                {
                fprintf(GPRS,"%c",bufferRxBT[contBytes]);  // send data for FTP server
                }
     
           if(waitAnsewrGPRS(respFTPPUT,10000))  // Wait answer SIM900
                   clearBufferBT();              // clear buffer for next packet
         
       }

   sendComandoAT(ATFTPPUT2_0,respFTPPUT,20000); // fprintf(GPRS,"AT+FTPPUT=2,0");
   
   clearBufferBT();   
   delay_ms(1000); 
   }

Ttelmah



Joined: 11 Mar 2010
Posts: 12828

View user's profile Send private message

PostPosted: Fri Jul 14, 2017 7:51 am     Reply with quote

What is returned when you open the FTP session.
When you send "AT+FTPPUT=1", the modem will respond with "OK", and then a few moments later, with "AT+FTPPUT:1,1,xxxxx", where 'xxxxx' is the maximum FTP session packet size supported by the provider. Your packet, must be no larger than this number.
If you need to sens amounts larger than this, then it needs to be split up and sent in smaller packets.
It might be better for you to use the EXTPUT option offered by the SIM900. With this the packet is loaded into the SIM900's memory, and the modem then automatically sends it using the largest packet size supported by the network. This is only available on reasonably recent firmware (anything over the last couple of years). Otherwise even if your network supports 1024 bytes, it is easy to move to another provider, and find that the maximum packet size is only something like 376 bytes. Minimum guaranteed is only a few hundred bytes. Most networks support about 1.5K.

However I'd guess your actual problem is you are overflowing the buffer in the PIC. If you are using the standard CCS internal 'hidden' buffer code, this simply overwrites data if you overflow. Because of the way the counters are handled you have to ensure that the value from tx_buffer_available is 2 or larger, before a character is added to the buffer.

So instead of using the fprintf, use:
Code:

void GSMputc(int chr) {
   while (tx_buffer_available(GPRS) < 2)
      ; //prevent buffer overflow
   fputc(chr,GPRS);
}

//then where you use fprintf, use:

                GSMPutc(bufferRxBT[contBytes]);  // send data for FTP server


Which will wait when the buffer is full.
Orcino



Joined: 07 Sep 2003
Posts: 56

View user's profile Send private message

PostPosted: Fri Jul 14, 2017 11:28 am     Reply with quote

Thanks Ttelmah,

When I add "TRANSMIT_BUFFER", the device does not send data to the PC via bluetooth (UART2).

What could be happening ?


Code:

#pin_select U1TX=PIN_C1
#pin_select U1RX=PIN_C2
#use rs232(UART1, baud=9600,ERRORS,stream=GPS)

#pin_select U2TX=PIN_B7
#pin_select U2RX=PIN_B8
#use rs232(UART2, baud=9600, ERRORS,stream=BT)

#pin_select U3TX=PIN_C4
#pin_select U3RX=PIN_C3
#use rs232(UART3, baud=19200, ERRORS,stream=GPRS,TRANSMIT_BUFFER=4)
Ttelmah



Joined: 11 Mar 2010
Posts: 12828

View user's profile Send private message

PostPosted: Fri Jul 14, 2017 1:05 pm     Reply with quote

TXISR is needed in the setup as well.

Otherwise the buffer has to be polled.

However I must admit I assumed you were using buffered transmit already.

What does the FTP open return as the maximum size?.
Orcino



Joined: 07 Sep 2003
Posts: 56

View user's profile Send private message

PostPosted: Fri Jul 14, 2017 1:52 pm     Reply with quote

The SIM900D, after AT+FTPPUT=2,1024, return +FTPPUT: 1294.

I have a receive buffer, 1024 bytes, which receives the data from the PC.

After the full buffer, the firmware will read and send via GPRS.

Orcino
Ttelmah



Joined: 11 Mar 2010
Posts: 12828

View user's profile Send private message

PostPosted: Fri Jul 14, 2017 2:40 pm     Reply with quote

If you are intending ever to use it on a different GSM provider, or even at different sites, then you need to assume that on some at least, 1024 will not be supported as a single transaction.

So, use the EXTPUT command instead.

This is awfully documented. You can use it to extend or overwrite.

Setup just as for normal FTP. So APN (if needed), USER, and PWD for the access point. Then SERV (server name), UN (user name), & PW (login password). Then the filename, and path. Then select the mode (APPE, or STOR), for append or overwrite. Then turn on EXTPUT (AT+FTPEXTPUT=2,0,1024,30000) (for a 1024 byte transmission, and 30 second timeout). Wait to receive back +FTPEXTPUT:0,1024, and then just send your 1024 bytes. It'll send 'OK' when 1024 bytes have been transferred to the modem. Then just send "AT+FTPPUT=1". It'll reply 'OK', and then when the transmission has finished, "+FTPPUT:1,0". It automatically does the transmission using as many transactions as are needed.With 30000 selected in the command, it'll timeout if the data doesn't send in 30 seconds, and give an error - either +FTPPUT:1,nnnn where nnnn is the error number, or +CME ERROR:yyyy where yyyy is a CME error (things like a DNS failure etc..).

I had problems ages ago, when just moving a few miles, picked up a different cell tower, which supported different maximum block sizes.
Orcino



Joined: 07 Sep 2003
Posts: 56

View user's profile Send private message

PostPosted: Sat Jul 15, 2017 8:34 am     Reply with quote

I will update the firmware of the module and follow its tip.

Thanks again.

Orcino
NVergunst



Joined: 20 Oct 2017
Posts: 7
Location: Canada

View user's profile Send private message

PostPosted: Fri Oct 20, 2017 2:36 pm     Reply with quote

Ttelmah wrote:
If you are intending ever to use it on a different GSM provider, or even at different sites, then you need to assume that on some at least, 1024 will not be supported as a single transaction.

So, use the EXTPUT command instead.

This is awfully documented. You can use it to extend or overwrite.

Setup just as for normal FTP. So APN (if needed), USER, and PWD for the access point. Then SERV (server name), UN (user name), & PW (login password). Then the filename, and path. Then select the mode (APPE, or STOR), for append or overwrite. Then turn on EXTPUT (AT+FTPEXTPUT=2,0,1024,30000) (for a 1024 byte transmission, and 30 second timeout). Wait to receive back +FTPEXTPUT:0,1024, and then just send your 1024 bytes. It'll send 'OK' when 1024 bytes have been transferred to the modem. Then just send "AT+FTPPUT=1". It'll reply 'OK', and then when the transmission has finished, "+FTPPUT:1,0". It automatically does the transmission using as many transactions as are needed.With 30000 selected in the command, it'll timeout if the data doesn't send in 30 seconds, and give an error - either +FTPPUT:1,nnnn where nnnn is the error number, or +CME ERROR:yyyy where yyyy is a CME error (things like a DNS failure etc..).

I had problems ages ago, when just moving a few miles, picked up a different cell tower, which supported different maximum block sizes.


Hello,

Sorry to hijack this thread, but I am doing FTPEXTPUT with a SIMCOM SIM808 module and their tech-support has been useless. That's why I am trying some Google-Fu and found your post.

I am grasping at straws here, but I am unable to make a reliable FTPEXTPUT connection. You make mention of "Then select the mode (APPE, or STOR), for append or overwrite". Do you have any example code for this? This is the only thing I appear not to be doing, I really hope this magically fixes things...

My code looks like:


Code:

AT+CGREG?
AT+SAPBR=0,1
AT+FTPPUT=1
AT+FTPEXTPUT=0
AT+SAPBR=3,1,"Contype","GPRS";
AT+SAPBR=3,1,"APN","wholesale"
AT+SAPBR=1,1
AT+SAPBR=2,1
AT+FTPCID=1
AT+FTPTYPE=I
AT+FTPSERV="ftp.***.com"
AT+FTPUN="***"
AT+FTPPW="***"
AT+FTPPUTNAME="FTPEXT.txt"
AT+FTPPUTPATH="/"
AT+FTPEXTPUT=1
AT+FTPEXTPUT=2,0,100,10000
AT+FTPPUT=1
AT+FTPEXTPUT=0


I have been able to get files to upload this way, some of the time.. Other times I just get "ERROR" out of the device with no error code, and other times it just hangs on the FTPPUT=1 command never giving me an OK. Recently it has been giving me ERROR immediately after AT+FTPEXTPUT=1.

If it is ERRORing because I haven't told it to overwrite an internal file handler, that would potentially make sense. If you have any working code for this it is super appreciated as it appears like nobody is using this]
Ttelmah



Joined: 11 Mar 2010
Posts: 12828

View user's profile Send private message

PostPosted: Fri Oct 20, 2017 2:57 pm     Reply with quote

Error on FTPPUT, almost certainly means it has not dropped the previous connection. I have never worked out 'why', you tell it to drop the connection at the end, but for some (unknown) reason it seems still sometimes to be open...
Sequence I'm using is:

Initially send AT+SAPBR, with CONTYPE, APN, USER, and PWD. Save to NVRAM and jump on to 'a'.

For all subsequent entries I test the GPRS context with AT+CGATT?. If I get an IP address then jump straight on, otherwise try re-attaching. If OK return to 'a'. Otherwise hang up and try again.

'a' Now send AT+FTPCID=1, and set server name, user name password, filename and path to send.
Now AT+FTPPUTOPT="APPE" or "STOR" as applicable.

Now the AT+FTPEXTPUT=1 to open the extended mode context.

Now AT+FTPEXTPUT=2,0,size,40000 - I've found the timeout needs to be this long...

Then wait for +FTPEXTPUT: and send 'size' number of bytes.

Wait for OK. If ERROR hand up everything and retry.

Now send AT+FTPPUT=1 which starts the physical transfer.

Wait for +FTPPUT:1,0

Send AT+FTPEXTPUT=0 & exit

It is much cheaper to leave the main context open, and only reconnect if CGATT says it has dropped.
NVergunst



Joined: 20 Oct 2017
Posts: 7
Location: Canada

View user's profile Send private message

PostPosted: Fri Oct 20, 2017 3:56 pm     Reply with quote

Ttelmah wrote:
Error on FTPPUT, almost certainly means it has not dropped the previous connection. I have never worked out 'why', you tell it to drop the connection at the end, but for some (unknown) reason it seems still sometimes to be open...


Interested. The device thinks the FTP connection is still alive you mean? I can see the FTP server logs in realtime and I can see that very quickly after closing the FTP connection by serial command to the SIM808, the server sees the connection close.

Ttelmah wrote:

Sequence I'm using is:

Initially send AT+SAPBR, with CONTYPE, APN, USER, and PWD. Save to NVRAM and jump on to 'a'.

For all subsequent entries I test the GPRS context with AT+CGATT?. If I get an IP address then jump straight on, otherwise try re-attaching. If OK return to 'a'. Otherwise hang up and try again.


Good advice. In my app it basically sits a long time then wakes up, does stuff, then goes back to sleep. The time from waking up registering on the network and getting an IP is minimal and OK. Then the time between getting the IP and actually using it is always less than 10 seconds. So I do not believe I am dropping the network in that short time causing my problems.

Ttelmah wrote:

'a' Now send AT+FTPCID=1, and set server name, user name password, filename and path to send.
Now AT+FTPPUTOPT="APPE" or "STOR" as applicable.


Ok, I see you were talking about the overwrite/append for the server side. Default of overwrite works fine in my case. So not the issue... :(

Ttelmah wrote:

Now the AT+FTPEXTPUT=1 to open the extended mode context.

Now AT+FTPEXTPUT=2,0,size,40000 - I've found the timeout needs to be this long...

Then wait for +FTPEXTPUT: and send 'size' number of bytes.

Wait for OK. If ERROR hand up everything and retry.

Now send AT+FTPPUT=1 which starts the physical transfer.

Wait for +FTPPUT:1,0

Send AT+FTPEXTPUT=0 & exit


That's pretty much the flow I have, but it doesn't seem to work...



Ttelmah wrote:

It is much cheaper to leave the main context open, and only reconnect if CGATT says it has dropped.


True.
Ttelmah



Joined: 11 Mar 2010
Posts: 12828

View user's profile Send private message

PostPosted: Sat Oct 21, 2017 3:40 am     Reply with quote

If the simple FTPEXTPUT command is giving 'ERROR' directly like this without saying anything else, I'd say you don't have firmware that supports this.
Check your firmware version and update if necessary.
NVergunst



Joined: 20 Oct 2017
Posts: 7
Location: Canada

View user's profile Send private message

PostPosted: Sat Oct 21, 2017 3:43 am     Reply with quote

Ttelmah wrote:
If the simple FTPEXTPUT command is giving 'ERROR' directly like this without saying anything else, I'd say you don't have firmware that supports this.
Check your firmware version and update if necessary.


That was the first thing I checked. Simcom app support gave me the firmware updater and new firmware and they say all is well now. Apparently not.
Ttelmah



Joined: 11 Mar 2010
Posts: 12828

View user's profile Send private message

PostPosted: Sat Oct 21, 2017 10:39 am     Reply with quote

I notice your syntax is incorrect for the FTPTYPE command. Might not be helping.

The syntax is:

AT+FTPTYPE="I"

Must have the inverted commas.
NVergunst



Joined: 20 Oct 2017
Posts: 7
Location: Canada

View user's profile Send private message

PostPosted: Sat Oct 21, 2017 8:51 pm     Reply with quote

Ttelmah wrote:
I notice your syntax is incorrect for the FTPTYPE command. Might not be helping.

The syntax is:

AT+FTPTYPE="I"

Must have the inverted commas.


Good catch. I changed that, no change in the outcome... :(

Ttelmah



Joined: 11 Mar 2010
Posts: 12828

View user's profile Send private message

PostPosted: Sun Oct 22, 2017 1:48 am     Reply with quote

You seem to be sending an FTPPUT=1 before the FTPEXTPUT. The FTPPUT=1 is what triggers the transfer. You can't setup the extended transfer after having triggered the transfer.

Look at the application notes for FTP transfers on this modem. Follow the sequence exactly.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group