Send file FTP with SIM900

[Orcino]

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 ?

[Ttelmah]

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:

[Orcino]

Thanks Ttelmah,

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

What could be happening ?

[Ttelmah]

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]

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]

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]

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

Thanks again.

Orcino

[NVergunst]

[Ttelmah]

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]

[Ttelmah]

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]

[Ttelmah]

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]

[Ttelmah]

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.