Comprimir dados (ajuda)

[lucasromeiro]

GPRS é tâo caro assim?

Outra dica: deixe os campos com comprimento fixo e elimine os delimitadores ( ; , - / etc.). Em Hexa isso será quase obrigatório. Duh!

Se a frequencia de envio for alta, uma alternativa é usar 2 tipos de pacotes. Um completo e um simples. O completo transmitido a intervalos maiores e o simples sem os dados que variam pouco (como dia, mês, ano) e transmitidos com maior frequencia. Pode usar apenas um bit para identificar o tipo de cada pacote. Ou ainda identificar pelo tamanho.

nao entendi, remover os marcadores? mas eles sao a base para eu saber onde estao os dados.. a nao ser que eu fixe o comprimento dos dados, mas assim nao perderei mais dados?

[lucasromeiro]

Se a operadora cobrar pelo encapsulamento TCP, muito pouco pode ser feito para um pacote de dados tão pequeno. É algo como tentar economizar combustível de avião levando menos passageiros.

Concordo, mas este é um exemplo. poderei precisar enviar um pacote grande com varios pacotes pequenos dentro, entende?
toda economia é bem vinda...

[EDSONCAN]

Se você tem pouco intervalo de tempo entre uma transmissão e outra, a variação as serão pequenas, portanto, transmite a diferença somente, como exemplo:

Data: vai trocar a cada 24 horas e um numero somente na maioria das vezes;
Latitude e longitude, vai trocar a casa da dezena ou centena se estiver parado e fora do equador.
Segundo varia muito, mas hora e dia da para economizar.

Acho que já deu para entender a ideia.

Abraços

[edsont]

GPRS é tâo caro assim?

Outra dica: deixe os campos com comprimento fixo e elimine os delimitadores ( ; , - / etc.). Em Hexa isso será quase obrigatório. Duh!

Se a frequencia de envio for alta, uma alternativa é usar 2 tipos de pacotes. Um completo e um simples. O completo transmitido a intervalos maiores e o simples sem os dados que variam pouco (como dia, mês, ano) e transmitidos com maior frequencia. Pode usar apenas um bit para identificar o tipo de cada pacote. Ou ainda identificar pelo tamanho.

nao entendi, remover os marcadores? mas eles sao a base para eu saber onde estao os dados.. a nao ser que eu fixe o comprimento dos dados, mas assim nao perderei mais dados?

Perder dados? Não entendi.

[andre_luis]

remover os marcadores? mas eles sao a base para eu saber onde estao os dados.. a nao ser que eu fixe o comprimento dos dados, mas assim nao perderei mais dados?

Se adicionar 2 bytes de CRC no pacote, você só vai aceitar os dados se não estiverem corrompidos.

[lucasromeiro]

Se você tem pouco intervalo de tempo entre uma transmissão e outra, a variação as serão pequenas, portanto, transmite a diferença somente, como exemplo:

Data: vai trocar a cada 24 horas e um numero somente na maioria das vezes;
Latitude e longitude, vai trocar a casa da dezena ou centena se estiver parado e fora do equador.
Segundo varia muito, mas hora e dia da para economizar.

Acho que já deu para entender a ideia.

Abraços

Ah sim! entendi! vou analizar uma boa forma de implementar isso

[lucasromeiro]

GPRS é tâo caro assim?

Outra dica: deixe os campos com comprimento fixo e elimine os delimitadores ( ; , - / etc.). Em Hexa isso será quase obrigatório. Duh!

Se a frequencia de envio for alta, uma alternativa é usar 2 tipos de pacotes. Um completo e um simples. O completo transmitido a intervalos maiores e o simples sem os dados que variam pouco (como dia, mês, ano) e transmitidos com maior frequencia. Pode usar apenas um bit para identificar o tipo de cada pacote. Ou ainda identificar pelo tamanho.

nao entendi, remover os marcadores? mas eles sao a base para eu saber onde estao os dados.. a nao ser que eu fixe o comprimento dos dados, mas assim nao perderei mais dados?

Perder dados? Não entendi.

fixando o comprimento eu perco dados, pois terei que completar com ZEROS quando o numero for pequeno, correto?

[lucasromeiro]

remover os marcadores? mas eles sao a base para eu saber onde estao os dados.. a nao ser que eu fixe o comprimento dos dados, mas assim nao perderei mais dados?

Se adicionar 2 bytes de CRC no pacote, você só vai aceitar os dados se não estiverem corrompidos.

Voce nao entendeu, quando falei de perder dados, me referi a ter que enviar mais dados na transmissao e nao necessariamente pacote corrompido. entende? tcp ja faz tratamento do pacote para mim quanto ao crc

[lucasromeiro]

xultz e barboza

Quando puderem, me respondam.
Ansioso para ler

[barboza]

xultz e barboza

Quando puderem, me respondam.
Ansioso para ler

Não sei porque o fórum não esta me enviando mais e-mail quando há respostas nas threads que participo.

[barboza]

Além da conversão de valores enviados como string para hexadecimal, você pode também enviar o timestamp no padrão UTC.

25/10/2015-23:22:34

No seu exemplo acima, você esta enviando 19 bytes para definir sua data/hora.

Com o UTC, bastam 4 (ou 8 bytes).

https://pt.wikipedia.org/wiki/Tempo_Uni ... Coordenado

http://www.cplusplus.com/reference/ctime/time_t/

Você pode também implementar seu próprio padrão de envio do timestamp. Se não precisa da resolução de segundos, pode enviar os minutos passados desde o ano 2015 por exemplo, ao invés dos segundos após 1970 (UTC).

Exato, me falaram que posso enviar o timestamp no formato de um INT32, ocupando beeeem menos espaco do que ocupa hoje!
Pesquisei, vi exemplos, mas nao achei a forma usada para converter.. a lógica usada na conversao entende?
eu preciso da resolucao de segundos sim, mas posso usar um unsigned int32, me da mais possibilidades...
pode me explicar o funcionamento do utc?
acho que entendi durante a escrita deste texto, basicamente seria a contagem de segundos que se passou desde 1970? rsrs
quando se refere que eu posso fazer meu timestamp quer dizer que posso comecar a contar desde 01/01/2015? boa ideia.
so nao entendi porque eu perco os segundos!!
outra duvida, como eu faco para saber se o ano eh bisexto ou coisas do genero que poderiam bugar o sistema.....
preciso prever isso tudo...

- Sim, você pode usar o padrão UTC ou criar o seu como já relatou acima;
- Nos links que enviei explica bem o padrão e há toneladas de códigos de como converter o timestamp em UTC e vice-versa;
- Não entendi porque diz que irá perder os segundos;
- Nos códigos exemplos irá encontrar como tratar anos bisextos e tal;

[edsont]

Perder dados? Não entendi.

fixando o comprimento eu perco dados, pois terei que completar com ZEROS quando o numero for pequeno, correto?

Você quiz dizer desperdiar banda.
No caso de binário não é comum usar delimitador. O tipo de dado já define o comprimento. No caso de ASCII (texto) é mais comum o uso de delimitador. Um exemplo é o CSV (dados separados por vígula, ou ponto e virgula).

Se a transmissão tiver que ser em ASCII, os valores binários não precisam necessariamente ser em formato Hexa.

O e-mail originalmente foi criado para transmissão de texto, e por isso usa codificação em 7 bits. Quando se envia um anexo (binário) num e-mail ele é convertido para texto. Há "desperdício" de 1 bit, mas ainda é melhor do que o hexa em texto, que ocupa 2 caracteres para cada byte, sendo que no e-mail o byte ocuparia 1 caracter e 1/7 do caracter seguinte. Na verdade não é tão simples porque existem os caracteres de controle, mas é mais ou menos isso.

[xultz]

fixando o comprimento eu perco dados, pois terei que completar com ZEROS quando o numero for pequeno, correto?

Correto, mas o tamanho da perda é uma questão estatística. Eu não sei que tipos de valores você irá transmitir, mas vamos supor que sejam sensores que na maior parte do tempo eles têm valores bem baixos, por exemplo menores que 100, e só eventualmente eles assumem valores acima de, sei lá, 50000. Neste caso, é possível que o uso de delimitadores possa fazer você ganhar alguns bytes. Porém, se o valores serão mais aleatórios, podendo ser de qualquer tamanho a qualquer instante, o uso de tamanho fixo tende a ser mais econômico. A resposta prá tua pergunta só pode ser respondida analisando de forma estatística (ou estocástica), e para isso é necessário conhecer a fundo teu sistema. E como qualquer coisa baseado em estatística, ainda tem uma chance de estar errado.

[lucasromeiro]

fixando o comprimento eu perco dados, pois terei que completar com ZEROS quando o numero for pequeno, correto?

Correto, mas o tamanho da perda é uma questão estatística. Eu não sei que tipos de valores você irá transmitir, mas vamos supor que sejam sensores que na maior parte do tempo eles têm valores bem baixos, por exemplo menores que 100, e só eventualmente eles assumem valores acima de, sei lá, 50000. Neste caso, é possível que o uso de delimitadores possa fazer você ganhar alguns bytes. Porém, se o valores serão mais aleatórios, podendo ser de qualquer tamanho a qualquer instante, o uso de tamanho fixo tende a ser mais econômico. A resposta prá tua pergunta só pode ser respondida analisando de forma estatística (ou estocástica), e para isso é necessário conhecer a fundo teu sistema. E como qualquer coisa baseado em estatística, ainda tem uma chance de estar errado.

xultz,
tive outras duvidas e te fiz algums perguntas, so que ficaram na primeira pagina. acho que vc nao viu.
foi uma resposta ao seu texto explicativo.
da uma olhada lá

[xultz]

Não achei, formula de novo.