SIM800C Perdendo Arquivo FTP

[eliveltonpsantos]

Estou com um problema de perder um arquivo quando envio-o por FTP pelo módulo da SIMCom SIM800C (também tive com o SIM900A).
Meu código, num STM32F0, a cada 5 minutos formata um frame (data, hora e valores de uns sensores), acessa um arquivo do FTP e adiciona uma linha nesse arquivo (modo "appending file" com AT+FTPCID=1) normalmente, conforme indicado no Application Notes (http://simcomm2m.com/UploadFile/Technic ... _V1.03.pdf) e o manual (http://simcomm2m.com/UploadFile/Technic ... _V1.10.pdf).
Porém, após o comando de iniciar sessão FTP (AT+FTPPUT=1), o módulo me retorna um "OK" e, logo em seguida, retorna um time out (+FTPPUT:1,64). Isso faz com que o arquivo seja "aberto" e, na próxima execução do código, o servidor entende que o arquivo não existe e acaba criando um novo arquivo. Me parece que o arquivo está sendo aberto pelo comando AT+FTPPUT=1, mas, por conta do erro +FTPPUT:1,64, não consigo enviar o comando para fechar (AT+FTPPUT=2,0 retorna ERROR).
Esse erro acontece aleatóriamente: tem vez que funciona por 6 horas, tem vez que funciona por 5 minutos. Tentei reinicar o módulo todas as vezes (AT+CPOWD=1), verificar se está conectado à rede (AT+CGATT?), ler o tamanho do arquivo antes para ver se consegue acessar o servidor, mas o problema persiste.
Listarei a sequência de comandos que estou utilizando. Se puderem dar alguma sugestão, seria grato.

Código: Selecionar todos

AT+CGATT?

AT+CGATT=1
AT+SAPBR=3,1,"Contype","GPRS"
AT+SAPBR=3,1,"APN","zap.vivo.com.br"
AT+SAPBR=1,1
AT+SAPBR=2,1

AT+FTPPUTOPT="APPE"

AT+FTPCID=1
AT+FTPSERV="ftp.elivelton.hospedagemdesites.ws"
AT+FTPUN="elivelton"
AT+FTPPW="eli1234"
AT+FTPGETNAME="meters.csv"
AT+FTPGETPATH="/meters/teste/"
AT+FTPSIZE

AT+FTPCID=1
AT+FTPSERV="ftp.elivelton.hospedagemdesites.ws"
AT+FTPUN="elivelton"
AT+FTPPW="eli1234"
AT+FTPPUTNAME="meters.csv"
AT+FTPPUTPATH="/meters/teste/"
AT+FTPPUT=1
AT+FTPPUT=2,269
frame com as informações
AT+FTPPUT=2,0

5 minutos depois, reinicia a sequência

[EDSONCAN]

Não mexi com o SIM800, mas quando tinha que fazer isso mandava um get em uma pagina em php no servidor e esse fazia o apendice no arquivo, acho via ftp tem muito risco de timeout do servidor, fazer um UDP em um servidor no Brasil já demora 60 segundos as vezes imagine um ftp que envolve muito mais interações e sentar e chorar.....

[ivan braga]

Vamos lá eliveltonpsantos.

Recebi sua MP, mais responderei aqui, pois pode ajudar alguém no futuro.

Já faz muito tempo que não mexo com esses módulos da SIMCOM e nunca usei suas funções FTP, porem depois de uma lida rápida no APN e nos cmd AT, a primeira coisa que me vem a cabeça é "AT+FTPTIMEOUT?", isso provavelmente lhe dará o retorno parecido com isto "AT+FTPTIMEOUT:64".
Leia as paginas 276 e 277 do SIM800 Series_AT Command, e tente aumentar o timeout "AT+FTPTIMEOUT=128 ou 256 ou 512", teste e veja o que acontece.

Caso continue com problemas, tente atualizar a versão do soft do SIM800 ou faça como eu fazia, TCP/IP nele, mais braçal, porem nunca tive problemas.

Sorte....

[eliveltonpsantos]

AT+FTPTIMEOUT?

Eu não tinha me atentado à esse comando. Amanhã a tarde farei um teste e retorno com o resultado.

atualizar a versão do soft do SIM800

Atualizei para a versão mais recente assim que o módulo chegou. Inclusive, o firmware é de 27/06/17.

fazer um UDP

TCP/IP nele

Esta é a minha primeira aplicação com servidor e eu adotei o FTP por parecer o mais simples e que atendia a necessidade.
Caso eu veja que o FTP se encontre muito instável, para essa aplicação de ir acrescentando uma linha com meu pacote de dados num arquivo a cada t intervalo de tempo (um datalogger), vocês recomendam algum outro método? Tudo bem se este for mais complexo, apenas queria um método rápido pra validar a ideia (mesmo que instável) e, depois, com mais tempo, utilizar um método final, mais confiável.

[andre_luis]

O timeout não pode ser configurado no servidor de arquivos, á gosto ? Tendo se em conta que esse cliente em especifico é sabidamente um modem GSM, poderia-se definir uma margem mais folgada.

[eliveltonpsantos]

O timeout do servidor é de 5 minutos; já acho esse valor razoável. Nunca enviarei mais do que 1kB de dados por vez.

Para a aplicação, não tem problema o servidor dar timeout. Eu simplesmente envio o comando de reiniciar o módulo, reconecto e tento subir novamente; se após n tentativas der errado, aí o microcontrolador toma uma outra ação.
O problema maior é que, ao dar timeout, não consigo "fechar" o arquivo. Com isso, na próxima execução, ao tentar abrir um arquivo que já está aberto, ele entende que o arquivo não existe e cria um novo começando do zero, e aquele que havia diversas informações é pedido.
Quero, nesse primeiro momento, não mais perder o arquivo. Resolver o timeout está em segundo plano.

[tcpipchip]

em ultima instancia, partir para mais baixo nivel e trabalhar em nivel de sockets...siga a RFC

[andre_luis]

Eu nunca trabalhei com o FTP via comando AT e por isso não entendo a sintaxe do código acima, mas baseado em outras aplicações com as quais trabalhei, me parece que está faltando acima o processo de abrir-a-conexao-realizar-a-operação-e-fechar-a-conexao-logo-em-seguida para cada amostra registrada. Se entendi corretamente, voce está fazendo tudo numa unica sequencia. Caso faça do modo como falei, tente utilizar mais comandos de confimação de operação bem-sucedida para cada operação, que ao menos na minha leiguiçe não os consegui identificar acima.

[eliveltonpsantos]

Verifiquei aqui e está +FTPTIMEOUT=0; ou seja, sem timeout pelo módulo.

Cheguei a pensar nisso de abrir-a-conexao-realizar-a-operação-e-fechar-a-conexao-logo-em-seguida, mas eu reduziria a quantidade de amostragens que eu poderia fazer, então deixei de lado. Eu fiz sim algumas verificações em cada uma dessas etapas, andre_teprom; para simplificar a postagem e o entendimento, ocultei essa parte.

Conversando com o pessoal de web (e que já tiveram problemas semelhantes), cheguei a conclusão de que é melhor subir um arquivo único por vez contendo a data e hora no nome do arquivo e depois verificar se subiu corretamente; caso contrário, retransmitir, resetar o módulo, etc. Inclusive, ter vários arquivos pequenos, segundo eles, é melhor gerenciável no servidor se comparado à poucos arquivos grandes.

Agora, implementarei no modo Storage, ao invés de Appending, e veremos o resultado disso...

[eliveltonpsantos]

Enviar um arquivo diferente por vez, resolveu para a minha aplicação.

Nesse meio tempo, também enviei um email pra um representante da SIMCOM e ele me respondeu pedindo umas informações de firmware e configuração do módulo, além de sugerir trocar de modo ativo/passivo. Em paralelo, irei fazendo os testes assim que possível e atualizando.