PDA

View Full Version : Checksum problem!



atomski
- 2nd November 2004, 08:22
Greetings and salutations ;)

This is a sequal of this thread:

http://www.picbasic.co.uk/forum/showthread.php?s=&threadid=828

I'll get to the problem asap, but first the code snippet:

DEFINE OSC 20
Rx_Data Var Byte[7]
Rx_Byte Var Byte
Rx_Bit Var Bit
Ack Var Bit
Pulse Var Word
Csum Var Byte
Csum_Data Var Byte
I Var Byte
w Var Byte

Goto Start

Checksum:
Ack = 0
FOR i = 0 TO 5
Csum_Data = Csum_Data + Rx_Byte[i] 'Sum all bytes for checksum
NEXT i
Csum = Rx_Data[6]
IF Csum = Csum_data THEN Ack = 1
i = 0
RETURN

Start:
Pulse = 0
PULSIN Rx_Pin, 0, Pulse
IF Pulse < 290 THEN Start

Get_Data:
FOR i = 0 to 6
FOR w = 0 TO 5
Pulse = 0
PULSIN Rx_Pin, 0, Pulse
If Pulse > 80 and Pulse < 120 THEN Rx_Bit = 0
IF Pulse > 180 AND Pulse < 220 Then Rx_Bit = 1
Rx_Byte.0 = Rx_bit
Rx_Byte = Rx_Byte << 1
NEXT w
Rx_Data[i] = Rx_Byte >> 1
NEXT i
i = 0
w = 0
GOSUB Checksum
GOSUB Send_Data
GOTO Start

END

Now, first thing's first. All my ASCII chars are represented
with their HEX value - $30 which makes it easier for me to
use since now all chars are only 6-bits. Less bits = shorter
over-the-air transmission time. Here's the table:

Character set
ASCII NEW NEW Character
Hex Hex Bin Value
--- --- ------ -----
30 00 000000 0
31 01 000001 1
32 02 000010 2
33 03 000011 3
34 04 000100 4
35 05 000101 5
36 06 000110 6
37 07 000111 7
30 08 001000 8
39 09 001001 9
3A 0A 001010 : (colon)
3B 0B 001011 ; (semi-colon)
3C 0C 001100 < (less than)
3D 0D 001101 = (equal sign)
3E 0E 001110 > (greater than)
3F 0F 001111 ? (question mark)
40 10 010000 @ (AT symbol)
41 11 010001 A
42 12 010010 B
43 13 010011 C
44 14 010100 D
45 15 010101 E
46 16 010110 F
47 17 010111 G
48 18 011000 H
49 19 011001 I
4A 1A 011010 J
4B 1B 011011 K
4C 1C 011100 L
4D 1D 011101 M
4E 1E 011110 N
4F 1F 011111 O
50 20 100000 P
51 21 100001 Q
52 22 100010 R
53 23 100011 S
54 24 100100 T
55 25 100101 U
56 26 100110 V
57 27 100111 W
58 28 101000 X
59 29 101001 Y
5A 2A 101010 Z
5B 2B 101011 Æ
5C 2C 101100 Å
5D 2D 101101 (reserved)
5E 2E 101110 (reserved)
5F 2F 101111 (reserved)
60 30 110000 (space)
61 31 110001 (reserved)
62 32 110010 (reserved)
63 33 110011 (reserved)
64 34 110100 (reserved)
65 35 110101 (reserved)
66 36 110110 (reserved)
67 37 110111 (reserved)
68 38 111000 (reserved)
69 39 111001 (reserved)
6A 3A 111010 (reserved)
6B 3B 111011 (reserved)
6C 3C 111100 (reserved)
6D 3D 111101 (reserved)
6E 3E 111110 (reserved)
6F 3F 111111 (reserved)

However, here's where my problem lies... When my
encoder calculates checksum by using the same method
as described above in the Checksum subroutine, it will
return a number spaning from %00000000 (if all my
shifted ASCII chars are $00) to %101111010 (if all my
shifted ASCII chars are $3F, and the result is a 9-bit
number). Since, I'm sending only 6-bits per byte, the
encoder will send only bits 5 to 0 of checksum.
When I try to reconstruct that in the above subroutine,
I run into mucho problemas. As long as the checksum falls
into 6 bits my subroutine works, but if it exceeds 6-bits,
Csum received won't match Csum_data I get by summing
6 bytes of data received by the decoder.

Any ideas on how to solve this, and still keep the 6-bit
scheme in place?

Thank you in advance!

Ingvar
- 2nd November 2004, 09:25
Hi Vladimir,

Try keeping everything within 6 bits all the time. Easily done by bitwise anding with $3F. I assume that the two highest bits of Rx_Data[x] is always zero. If not you should do some anding with them too.

/Ingvar

Checksum:
Ack = 0
FOR i = 0 TO 5
Csum_Data = Csum_Data & $3F
Csum_Data = Csum_Data + Rx_Byte[i] 'Sum all bytes for checksum
NEXT i
Csum_Data = Csum_Data & $3F
Csum = Rx_Data[6]
IF Csum = Csum_data THEN Ack = 1
i = 0
RETURN

atomski
- 2nd November 2004, 09:37
Ingvar,

Thanks for the reply. Rx_Data[x] bit7 and bit6 are always 0,
but Rx_Data[x] bit5 and bit4 aren't. As you can see from the
table, they can be e.g. %00 0000 = 0, %01 0000 = @, %10
0000 = P or %11 0000 = space. I'll try what you've sugested
as soon as I get back home from work. TNX!

atomski
- 3rd November 2004, 07:21
Ingvar,

The ANDing worked just fine. Now I can enter any
combination of characters and still get away with
my 6-bit scheme. Thanks!