Protecting 3x16 bits with 16 bits ?
|
Prev: Call for Papers: The 2010 International Conference on Computer Design (CDES'10), USA, July 2010 (updated)
Next: Protecting 3x16 bits with 16 bits ? (Raptor codes)
From: Skybuck Flying on 14 Feb 2010 02:08 Not really, Today I programmed a first try of the hamming code, and it's working, overall bit still needs to be added, maybe tomorrow hamming code will be done. I also found many many many crc8 routines. I am not sure what code/polynomial to use, but I think this can be tested to see which ones work best. So ultimately thanks to other people, my time is way shortened. Also crc's are more of a black art and so is probably ldpc's there is no really good answer, so that will drive many people nuts ;) :) I thank people spending use ammounts of time analyzing polynomials so I don't have too ! ;) :) Ultimately I might have to roll my own crc too so I understand it enough to implement it in floating points... though I think I already found some code with floating points so I might be done real fast if it's any good ;) :) And for LDPC's I still don't understand those... too wacky for me... do you understand those ? ;) Bye, Skybuck =D
From: Ian Bell on 14 Feb 2010 05:24 Skybuck Flying wrote: > Not really, Today I programmed a first try of the hamming code, and it's > working, overall bit still needs to be added, maybe tomorrow hamming code > will be done. > > I also found many many many crc8 routines. > > I am not sure what code/polynomial to use, but I think this can be tested to > see which ones work best. > > So ultimately thanks to other people, my time is way shortened. > > Also crc's are more of a black art and so is probably ldpc's there is no > really good answer, so that will drive many people nuts ;) :) > > I thank people spending use ammounts of time analyzing polynomials so I > don't have too ! ;) :) > > Ultimately I might have to roll my own crc too so I understand it enough to > implement it in floating points... though I think I already found some code > with floating points so I might be done real fast if it's any good ;) :) > > And for LDPC's I still don't understand those... too wacky for me... do you > understand those ? ;) > > Bye, > Skybuck =D > > I certainly hope this implementation is not going into any commercial product. Cheers Ian
From: Morten Reistad on 14 Feb 2010 09:56 In article <hl8j1a$ajk$1(a)localhost.localdomain>, Ian Bell <ruffrecords(a)yahoo.com> wrote: >Skybuck Flying wrote: >> Not really, Today I programmed a first try of the hamming code, and it's >> working, overall bit still needs to be added, maybe tomorrow hamming code >> will be done. >> >> I also found many many many crc8 routines. >> >> I am not sure what code/polynomial to use, but I think this can be tested to >> see which ones work best. >> >> So ultimately thanks to other people, my time is way shortened. >> >> Also crc's are more of a black art and so is probably ldpc's there is no >> really good answer, so that will drive many people nuts ;) :) >> >> I thank people spending use ammounts of time analyzing polynomials so I >> don't have too ! ;) :) >> >> Ultimately I might have to roll my own crc too so I understand it enough to >> implement it in floating points... though I think I already found some code >> with floating points so I might be done real fast if it's any good ;) :) >> >> And for LDPC's I still don't understand those... too wacky for me... do you >> understand those ? ;) >> >> Bye, >> Skybuck =D >> >> > >I certainly hope this implementation is not going into any commercial >product. ... echoes from beyond the killfile .. If you want a good, robust, all round crc, use the ccitt 16 or 32 bit ones. Just google, you'll find implementations in c[++], java, haskell and other languages easily. If forward error correction is an issue there are lots of libraries for this as well. However, 6 octets may need more than 2 octets to give a forward error correction and a protection as well. But I don't have much hope you will understand this. The idea of using floating point at all tells me you are way off the mark in your thinking. When you don't understand stuff, steal from someone else. Preferrably open source code, that is what this is for. -- mrr
From: Skybuck Flying on 14 Feb 2010 11:27 Nono, The crc needs to go into the gpu, and mostly only floating point available there ! ;) Is there a CCITT 8 bit version ? Bye, Skybuck ;) :)
From: Skybuck Flying on 14 Feb 2010 12:10
"Skybuck Flying" <IntoTheFuture(a)hotmail.com> wrote in message news:97bf$4b782482$d53371df$31740(a)cache5.tilbu1.nb.home.nl... > Nono, > > The crc needs to go into the gpu, and mostly only floating point available > there ! ;) > > Is there a CCITT 8 bit version ? To answer my own question, yesterday I already found one, but I am not sure if it's correct ;) So you think a CCITT is all around eh ? ;) Hmmm ;) :) BYTE crc8_calc(BYTE *byt, WORD size ) { /* Calculate CRC-8 value; uses The CCITT-8 polynomial, expressed as X^8 + X^5 + X^4 + 1 */ BYTE crc = (BYTE) 0xff; WORD index; BYTE b; for( index=0; index<size; index++) { crc ^= byt[index]; for( b=0; b<8; ++b ) { if( crc & 0x80 ) crc = (crc << 1) ^ 0x31; else crc = (crc << 1); } } return crc; } Bye, Skybuck. |