Detecção e correção de erros (migrado)

Software e Hardware para uC da Qualcomm, NXP, FreeScale e Motorola

Moderadores: 51, guest2003

Detecção e correção de erros (migrado)

Mensagempor Fábio Pereira » 17 Out 2006 17:30

BFCardoso
Aprendiz



43 Posts Posted - 01/02/2006 : 09:53:42
--------------------------------------------------------------------------------
Olá galera...
Estou precisando de um protocolo que detecta e corrige erros.
Se souberem de algum, favor me indicar.
Estou precisando também, da rotina de CRC em C.

Obrigado pela atenção!

BFCardoso.


Cláudio
Professor



420 Posts Posted - 01/02/2006 : 11:55:40
--------------------------------------------------------------------------------
Olá, Bruno!
Detecção de erro é bem simples de fazer, se não precisar de muita sofisticação apenas um ou-exclusivo ou soma simples entre os bytes (daí vem o nome CheckSum) resolve seu problema.
Quanto a correção, não resolve seu problema o reenvio do frame em caso de detecção de erro (é bem mais simples)?

Abraço,

Cláudio


BFCardoso
Aprendiz



43 Posts Posted - 01/02/2006 : 15:08:40
--------------------------------------------------------------------------------
Olá...
A detecção de erro junto com o reenvio do frame eu sei fazer atraves do protocolo CRC.
Mas o negocio é que eu tava querendo achar um protocolo que nao fosse necessario o reenvio do frame. Um protocolo que realmente detectasse e corrigisse a mesnsagem.

Obrigado

BRCardoso


EDSONCAN
Professor


Brazil
361 Posts Posted - 01/02/2006 : 15:33:27
--------------------------------------------------------------------------------

Para memorias se usa muito codigo de Hamming
Para modem se usa V42 LAPM

Da uma olhada no site abaixo
www.inf.ufrgs.br/~taisy/disciplinas/TFs ... redund.pdf

Edson
www.moky.com.br


peters
Professor


Brazil
221 Posts Posted - 01/02/2006 : 15:35:11
--------------------------------------------------------------------------------
O problema vai ser o processamento e o consumo de banda necessário.
Em um MCU, não vejo vantagem em fazer isso, pois o tempo que vc perderá para para fazer a checagem, descobrir o erro, corrigir, vai ser muito maior do que reenviar o byte defeituoso. Sem contar que para que vc tenha 100% de certeza de que o byte foi "arrumado" correntamente, vc vai precisar de um checksum muuuito poderoso.

Eduardo Peters
Canoinhas - SC
Skype: dudupeters
MSN: peterseduardo (at) hotmail . com
GoogleTalk: dudupeters (at) gmail . com

BFCardoso
Aprendiz



43 Posts Posted - 02/02/2006 : 08:39:38
--------------------------------------------------------------------------------
Obrigado galera....
Estou muito satisfeito com o resultado deste forum.
Vou fazer o projeto com CRC mesmo. Será mais compensatório.
Obrigado pela ajuda de todos.

BFCardoso


peters
Professor


Brazil
221 Posts Posted - 02/02/2006 : 18:11:07
--------------------------------------------------------------------------------
Uma das coisas que podes usar para detectar e corrigir erros é "Códigos de Blocos Lineares", onde vc consegue realmente corrigir alguns erros de bits, mas não entendi ainda como isso funciona ao certo.
Será que alguém tem algum material sobre isso, ou já implementou algo?
Já entendi como funciona a coisa, mas não tenho nem idéia de como implementar isso.

Uma referência está aqui:
http://www.deetc.isel.ipl.pt/analisedes ... o_cap9.pdf

Eduardo Peters
Canoinhas - SC
Skype: dudupeters
MSN: peterseduardo (at) hotmail . com
GoogleTalk: dudupeters (at) gmail . com

andre_teprom
Mestre


Brazil
758 Posts Posted - 23/02/2006 : 17:23:46
--------------------------------------------------------------------------------
DETALHE :

Pessoal, quando se fala em deteção e correção de erro por CRC, tem-se que ter em mente o fato de que não é todo erro detectado que pode ser corrigido.

Por exemplo, eu já utilizei no meu projeto-final do curso da faculdade, o código HAMMING(7,4,1), que anexava 3 bit's à cada 4 bit's da mensagem - totalizando assim, 7 bit's enviados; no caso, apenas 1 erro no máximo, poderia ser corrigido pela rotina, embora o erro fosse detectável na ocorrencia em mais de 1 bit desta "palavra" de 4 bit's.

Ou seja, há um abismo entre a detecção e a correção. Razão pela qual o re-envio não pode ser descartado.

PS.: Em se tratando de dados de imagem/audio, podemos descartar o re-envio pois o cérebro humano é capaz de recompor mesmo que esses dados possuam pouca intelegibilidade.


------------------------
ANDRE CASTRO
Teprom Consult. Assess. Tec. Ltda.
www.teprom.eng.br
Fábio Pereira
embeddedsystems.io
Avatar do usuário
Fábio Pereira
Word
 
Mensagens: 674
Registrado em: 16 Out 2006 09:07
Localização: Kitchener, ON

Voltar para NXP (ex-FreeScale (ex-Motorola))

Quem está online

Usuários navegando neste fórum: Nenhum usuário registrado e 1 visitante

x