EmbeddedRelated.com
Forums
Memfault Beyond the Launch

Need Help with CRC16

Started by Miguel Angel Palos M July 27, 2020
On 7/30/2020 1:15 AM, Tauno Voipio wrote:
> The example text file cannot be reliably used to check, as its whitespace can > be transformed during transfers through the NNTP protocol.
You also don't know if the CRC is calculated over the actual text file *or* if the text file is a pretty-printed version of the data (stored in some not defined encoding) that the checksum protects. Are line terminations CRs? LFs? CRFLs? Sure seems like the *source* of the file would be best equipped to indicate what the "rules" are!
El jueves, 30 de julio de 2020 a las 3:15:40 UTC-5, Tauno Voipio escribió:
> On 30.7.20 2.46, Miguel Angel Palos M wrote: > > El martes, 28 de julio de 2020 a las 3:01:09 UTC-5, Don Y escribió: > >> On 7/27/2020 12:54 PM, Miguel Angel Palos M wrote: > >>> Hi good day; I want to see the possibility that if someone can help me > >>> generate a crc calculator from txt files, I have a text file, and the result > >>> of the crc by which it must be submitted I already have, but I don't know > >>> how to get to He actually has several files to do the test, but I couldn't > >>> get to those results; Can someone help me? > >> Why don't you ask "him" for clarification? > > > > > > To this day I already know the polynomial of the crc16, any other idea of ​​how to obtain the other data that I lack to calculate the data of the crc? > At least, you need the initial value of the generator and which way the > bits are processed, most significant end first or least significant end > first. > > If you have many examples, the initial value can be deduced, but it > would be better to know it. Often all ones (0xffff) are used, to prevent > initial null bytes of the message being ignored. Sometimes the final > value is inverted. > > The example text file cannot be reliably used to check, as its > whitespace can be transformed during transfers through the NNTP protocol. > > -- > > -TV
Mr Tauno Voipio I have many examples of +10 files with the crc in the header which is what it should give and all in TXT format, the detail is that I have not even found what you are commenting on and it makes itself look so easy. ----physics.txt------- E48D 8 1 1 1 400 8888 TH86 9 8 7 6 3 2 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 100 0 0 0 1 0 1 0 0 0 0 0 0 0 2 0 1 1 2 2 2 4 4 4 3 120 6 1 20 1 55 200 1 999 1 999 0 0 0 0 0 300 1 999 1 999 0 0 0 0 0 3000 1 9000 1 9999 0 0 0 0 0 0 0 0 0 0 200 20 999 1 999 200 20 999 1 999 300 1 999 1 999 0 0 0 0 0 200 1 999 1 999 200 1 999 1 999 654 FALSE -1 0 -1 0 -1 0 -1 0 -1 0 -1 0 -1 0 -1 0 -1 0 -1 0 TRUE 5 FIXED XRAYS 1 500 400 0 0 NA 0 500 33 33 33 33 654 250 250 FIXED XRAYS 1 100 80 0 0 NA 0 100 33 33 33 33 654 250 250 FIXED XRAYS 1 100 80 0 0 NA 0 100 33 33 33 33 654 250 250 ARC XRAYS 1 180 96 1800 2700 NA 0 180 33 33 33 33 654 100 100 ARC XRAYS 1 90 53 2700 1800 NA 0 90 33 33 33 33 654 100 100 ----physics.txt----ends -----service.txt----- EB78 7 0 0 100 5 200 11 200 0 200 7 200 5 300 14 462 5 442 3 -100 -3 -100 -3 -100 -3 -100 -3 -100 -4 -100 -3 0 0 300 -2 -1500 -3 2100 1 0 0 -6 0 76 0 125 0 -300 -14 500 40 200 5 200 8 510 77 100 0 0 0 0 0 -1500 600 100 0 100 0 100 0 100 0 100 -1 100 0 100 0 100 0 100 0 100 0 100 0 200 0 200 0 205 0 200 0 210 0 195 0 300 0 100 0 100 0 100 0 100 0 100 0 300 0 100 0 100 0 100 0 100 0 0 0 0 0 0 0 0 0 100 0 3650 -50 180 409 40 2048 -52 21 1024 1024 16 7197 -32293 0 7194 -32290 0 2750 850 200 409 512 12288 -52 32 1024 1024 16 7214 18905 0 0 0 0 201 -105 40 615 885 4096 52 0 1024 1024 6 6 -4117 857 4 4095 1481 201 -105 40 615 885 4096 52 0 1024 1024 6 -5 -4098 482 -15 4125 586 201 -20 40 615 864 8192 52 0 1024 1024 6 366 1827 -406 0 0 0 201 -20 40 615 864 8192 52 0 1024 1024 6 348 1805 -285 0 0 0 1675 595 64 307 200 0 -52 32 2047 102 8 4646 9594 0 0 0 0 1250 750 160 307 180 16384 52 40 683 300 8 4009 4211 0 0 0 0 1540 0 160 307 200 8192 52 40 683 400 8 3185 12886 0 0 0 0 2750 850 96 624 128 12288 -52 32 500 500 8 7190 -20251 0 0 0 0 402 5 40 615 0 0 52 0 1024 1024 1 0 0 0 0 0 0 402 5 60 615 384 0 52 0 1024 1024 8 737 3683 439 0 0 0 32 20 20 30 100 842 6 -8 0 8196 800 256 0 0 0 3640 800 0 0 4096 3640 800 0 0 4096 2400 630 0 0 1280 2400 800 0 0 1280 2500 400 0 0 0 1200 120 0 0 12288 1000 110 0 0 10496 1700 50 0 0 18176 28 120 20 100 6 20 6 20 6 20 6 20 6 100 6 100 6 100 20 120 5 0 900 1800 2700 3600 0 5 900 1350 1800 2250 2700 0 6 -90 -40 20 80 140 190 6 -90 -40 20 80 140 190 5 -20 20 80 140 190 0 5 -20 20 80 140 190 0 6 650 800 1000 1200 1400 1600 5 770 875 1000 1125 1230 0 6 0 300 600 900 1200 1500 5 900 1350 1800 2250 2700 0 0 0 0 0 0 0 0 5 20 100 200 300 380 0 255 0 1 1 1 2 3 4 5 6 6 7 8 9 10 11 12 12 13 13 14 14 15 15 16 16 17 18 19 20 21 22 23 23 25 28 32 36 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 ---------service.txt---ends-------
El jueves, 30 de julio de 2020 a las 4:41:39 UTC-5, Don Y escribió:
> On 7/30/2020 1:15 AM, Tauno Voipio wrote: > > The example text file cannot be reliably used to check, as its whitespace can > > be transformed during transfers through the NNTP protocol. > You also don't know if the CRC is calculated over the actual text file > *or* if the text file is a pretty-printed version of the data (stored > in some not defined encoding) that the checksum protects. > > Are line terminations CRs? LFs? CRFLs? > > Sure seems like the *source* of the file would be best equipped to > indicate what the "rules" are!
In fact, when modifying even a blank space the program that validates the crc, marks an error; if you take into account the blank spaces. The Line terminations are a new line /n the source files are published, and the rest is an executable (exe) that only verifies it and then executes.
El jueves, 30 de julio de 2020 a las 8:40:53 UTC-5, Miguel Angel Palos M escribió:
> El jueves, 30 de julio de 2020 a las 3:15:40 UTC-5, Tauno Voipio escribió: > > On 30.7.20 2.46, Miguel Angel Palos M wrote: > > > El martes, 28 de julio de 2020 a las 3:01:09 UTC-5, Don Y escribió: > > >> On 7/27/2020 12:54 PM, Miguel Angel Palos M wrote: > > >>> Hi good day; I want to see the possibility that if someone can help me > > >>> generate a crc calculator from txt files, I have a text file, and the result > > >>> of the crc by which it must be submitted I already have, but I don't know > > >>> how to get to He actually has several files to do the test, but I couldn't > > >>> get to those results; Can someone help me? > > >> Why don't you ask "him" for clarification? > > > > > > > > > To this day I already know the polynomial of the crc16, any other idea of ​​how to obtain the other data that I lack to calculate the data of the crc? > > At least, you need the initial value of the generator and which way the > > bits are processed, most significant end first or least significant end > > first. > > > > If you have many examples, the initial value can be deduced, but it > > would be better to know it. Often all ones (0xffff) are used, to prevent > > initial null bytes of the message being ignored. Sometimes the final > > value is inverted. > > > > The example text file cannot be reliably used to check, as its > > whitespace can be transformed during transfers through the NNTP protocol. > > > > -- > > > > -TV > Mr Tauno Voipio > > > I have many examples of +10 files with the crc in the header which is what it should give and all in TXT format, the detail is that I have not even found what you are commenting on and it makes itself look so easy. > > ----physics.txt------- > E48D > 8 > 1 > 1 > 1 > 400 > 8888 > TH86 > 9 > 8 > 7 > 6 > 3 > 2 > 1 > 0 > 0 > 0 > 0 0 0 0 0 0 0 0 0 0 > 0 0 1 1 1 1 0 0 0 0 > 100 > 0 > 0 > 0 > 1 > 0 > 1 > 0 0 0 0 0 0 > 0 > 2 > 0 > 1 > 1 > 2 > 2 > 2 4 > 4 4 > 3 > 120 > 6 1 20 > 1 55 > 200 1 999 > 1 999 > 0 0 0 > 0 0 > 300 1 999 > 1 999 > 0 0 0 > 0 0 > 3000 1 9000 > 1 9999 > 0 0 0 > 0 0 > 0 0 0 > 0 0 > 200 20 999 > 1 999 > 200 20 999 > 1 999 > 300 1 999 > 1 999 > 0 0 0 > 0 0 > 200 1 999 > 1 999 > 200 1 999 > 1 999 > 654 > FALSE > -1 0 > -1 0 > -1 0 > -1 0 > -1 0 > -1 0 > -1 0 > -1 0 > -1 0 > -1 0 > TRUE > 5 > FIXED XRAYS 1 500 400 0 0 NA 0 500 > 33 33 33 33 654 250 250 > FIXED XRAYS 1 100 80 0 0 NA 0 100 > 33 33 33 33 654 250 250 > FIXED XRAYS 1 100 80 0 0 NA 0 100 > 33 33 33 33 654 250 250 > ARC XRAYS 1 180 96 1800 2700 NA 0 180 > 33 33 33 33 654 100 100 > ARC XRAYS 1 90 53 2700 1800 NA 0 90 > 33 33 33 33 654 100 100 > ----physics.txt----ends > > > > -----service.txt----- > EB78 > 7 > 0 > 0 > 100 5 > 200 11 > 200 0 > 200 7 > 200 5 > 300 14 > 462 5 > 442 3 > -100 -3 > -100 -3 > -100 -3 > -100 -3 > -100 -4 > -100 -3 > 0 0 > 300 -2 > -1500 -3 > 2100 1 > 0 0 > -6 0 > 76 0 > 125 0 > -300 -14 > 500 40 > 200 5 > 200 8 > 510 77 > 100 0 > 0 0 > 0 0 > -1500 600 > 100 0 > 100 0 > 100 0 > 100 0 > 100 -1 > 100 0 > 100 0 > 100 0 > 100 0 > 100 0 > 100 0 > 200 0 > 200 0 > 205 0 > 200 0 > 210 0 > 195 0 > 300 0 > 100 0 > 100 0 > 100 0 > 100 0 > 100 0 > 300 0 > 100 0 > 100 0 > 100 0 > 100 0 > 0 0 > 0 0 > 0 0 > 0 0 > 100 0 > 3650 -50 180 409 40 2048 -52 21 1024 1024 16 > 7197 -32293 0 7194 -32290 0 > 2750 850 200 409 512 12288 -52 32 1024 1024 16 > 7214 18905 0 0 0 0 > 201 -105 40 615 885 4096 52 0 1024 1024 6 > 6 -4117 857 4 4095 1481 > 201 -105 40 615 885 4096 52 0 1024 1024 6 > -5 -4098 482 -15 4125 586 > 201 -20 40 615 864 8192 52 0 1024 1024 6 > 366 1827 -406 0 0 0 > 201 -20 40 615 864 8192 52 0 1024 1024 6 > 348 1805 -285 0 0 0 > 1675 595 64 307 200 0 -52 32 2047 102 8 > 4646 9594 0 0 0 0 > 1250 750 160 307 180 16384 52 40 683 300 8 > 4009 4211 0 0 0 0 > 1540 0 160 307 200 8192 52 40 683 400 8 > 3185 12886 0 0 0 0 > 2750 850 96 624 128 12288 -52 32 500 500 8 > 7190 -20251 0 0 0 0 > 402 5 40 615 0 0 52 0 1024 1024 1 > 0 0 0 0 0 0 > 402 5 60 615 384 0 52 0 1024 1024 8 > 737 3683 439 0 0 0 > 32 > 20 20 > 30 100 > 842 6 -8 0 8196 > 800 256 0 0 0 > 3640 800 0 0 4096 > 3640 800 0 0 4096 > 2400 630 0 0 1280 > 2400 800 0 0 1280 > 2500 400 0 0 0 > 1200 120 0 0 12288 > 1000 110 0 0 10496 > 1700 50 0 0 18176 > 28 120 > 20 100 > 6 20 > 6 20 > 6 20 > 6 20 > 6 100 > 6 100 > 6 100 > 20 120 > 5 0 900 1800 2700 3600 0 > 5 900 1350 1800 2250 2700 0 > 6 -90 -40 20 80 140 190 > 6 -90 -40 20 80 140 190 > 5 -20 20 80 140 190 0 > 5 -20 20 80 140 190 0 > 6 650 800 1000 1200 1400 1600 > 5 770 875 1000 1125 1230 0 > 6 0 300 600 900 1200 1500 > 5 900 1350 1800 2250 2700 0 > 0 0 0 0 0 0 0 > 5 20 100 200 300 380 0 > 255 > 0 1 1 1 2 3 4 5 6 6 7 8 9 10 11 12 > 12 13 13 14 14 15 15 16 16 17 18 19 20 21 22 23 > 23 25 28 32 36 40 40 40 40 40 40 40 40 40 40 40 > 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 > > ---------service.txt---ends-------
The First Line in each file are the crc that should be.
On 7/30/2020 6:46 AM, Miguel Angel Palos M wrote:
> El jueves, 30 de julio de 2020 a las 4:41:39 UTC-5, Don Y escribió: >> On 7/30/2020 1:15 AM, Tauno Voipio wrote: >>> The example text file cannot be reliably used to check, as its >>> whitespace can be transformed during transfers through the NNTP >>> protocol. >> You also don't know if the CRC is calculated over the actual text file >> *or* if the text file is a pretty-printed version of the data (stored in >> some not defined encoding) that the checksum protects. >> >> Are line terminations CRs? LFs? CRFLs? >> >> Sure seems like the *source* of the file would be best equipped to >> indicate what the "rules" are! > > > In fact, when modifying even a blank space the program that validates the > crc, marks an error; if you take into account the blank spaces. > > The Line terminations are a new line /n > > the source files are published, and the rest is an executable (exe) that > only verifies it and then executes.
"source files"? As in "source code" (for the program)? If so, then you already have what you need. Otherwise, try removing the first line from the file and feeding the balance to <https://crccalc.com/> to see what *it* computes as the checksum. If it agrees with the value in the line that you removed, then you (appear to) have a tool that will do the work that you want.
A bit of web searching will find sample code to do CRC16 for various processors.

-- 
mdfs.net/Info/Comp/Comms/CRC16.htm

Memfault Beyond the Launch