Parity checking

Thread Starter

atferrari

Joined Jan 6, 2004
4,764
From a textbook:

"The parity bit is chosen so that the total number of 1's in a coded frame is even. We say that the coded frame has even parity."

From a basic explanation in a Web site:

"Computing parity involves counting the number of ones in a unit of data, and adding either a zero or a one (called a parity bit) to make the count even (for even parity) or odd (for odd parity).

For example, 1001 is a 4-bit data unit containing two one bits; since that is an even number, a zero would be added to maintain even parity,...."

To my surprise, from AN 160 from Linx Technologies:

"A parity check is accomplished by adding all of the '1's in a string of bits. For even parity, if the number is even, then the parity bit is set, otherwise it is not."

(Bold formatting, is mine)

Comments anyone?
 

Dave

Joined Nov 17, 2003
6,969
The first two explainations of parity are correct. My understanding is:

Assuming you are using single-bit parity, for even parity if the number of 1s in a data block is even, set the parity bit to zero so that the data word has an even number of 1s. Conversely, for odd parity if the number of 1s in a data block is even, set the parity bit to one so that the data word has an odd number of 1s.

Therefore: Even parity has even number of ones, odd parity has odd number of ones.

Could you post a link to the source of the parity information for the AN 160 from Linx Technologies?
 

Thread Starter

atferrari

Joined Jan 6, 2004
4,764
Hola Dave,

Could you post a link to the source of the parity information for the AN 160 from Linx Technologies?

Here you have, Sir! My pleasure.

Linx AN 00160

Thanks for READING my post and replying!
 

hgmjr

Joined Jan 28, 2005
9,027
Interesting discussion.

Is it possible that the difference between the two explanations depends on whether the parity bit is included or excluded from the parity calculation?

In the Linx Technology website description, it indicates that "the last (or parity) bit is not used in the parity calculation". It is just used as a flag to indicate that the original data had an even number of bits in it.

In the other scenerio, the parity bit enters into the parity calculation and is used to insure that the bit count is even or odd depending on the parity mode that was chosen. This is the scheme I normally have in mind when I think of parity.

At least that would be one way to explain the contradiction.

If as the designer of the communication link you have control over both ends of the link then you get to chose which way you handle the parity bit. If you are in control of only one end of the link then you would need to make sure that it was clear which way the other end of the link was handling the parity bit if chaos is to be averted.

hgmjr
 

Thread Starter

atferrari

Joined Jan 6, 2004
4,764
Hola hgmjr!

Is it possible that the difference between the two explanations depends on whether the parity bit is included or excluded from the parity calculation?

Exactly. First approach makes it part of the counting. Second approach makes a flag of it. "the last (or parity) bit is not used in the parity calculation".

My experience: in (my) Z80 times, when I first heard of parity checking / parity bit, intuitively assumed that flagging whatever, (and also here) was the way to go.

Later, texbooks and the usual applications made me aware of a bit used to FORCE even (or odd) parity as decided beforehand, so I forgot the "flag" idea.

Days ago, in my quest about Hamming's syndrome calcualtions, I run across that AN and became disoriented for a while.

At least that would be one way to explain the contradiction.

"Contradiction" is, in my opinion, not exact. But yes, a different approach to the same problem.

There is an inherent risk of taking for granted the wrong one. Better to check.

Yesterday, a poster in another forum, told me about having exactly that problem.

Thanks for READING my post and replying.
 

pebe

Joined Oct 11, 2004
626
Hi atferrari
I read your postings with interest , and wonder if you have decided firmly that parity checks is the route you want to go. The application from Linx indicates that CRC is more robust.

When Teletext was being infroduced in the UK, I was involved with data capture from it. It used Hamming code for the headers and parity checks for each line of information, but both these were prone to serious errors in poor TV reception areas.

Could you give some idea of the application you have? How many bytes, etc?
 

Thread Starter

atferrari

Joined Jan 6, 2004
4,764
Hola Pebe,

Thanks for asking.

A small robot with 3 omni directional wheeled legs controlled by the brains through an IR link with 4-bits commands: start / stop / reverse.

To allow a majority vote at the receiving end, each order repeated thrice.

Right now I am implementing the generation of the orders through a look up table.

At the other end, error correction, not yet implemented.

When reading about Hamming technique I puzzled myself to solve it for 8-bits data. It worked, but now, I resumed my original task.

Since legs are not linked to each other, I want to avoid some catastrophic situation like one of them not starting or not stopping.

Checksums, CRC and the like are not justified, I think.

This field is definitely new to me!

I have the feeling that such a simple thing will dissapoint you. Perhaps you were expecting a high rate link. Were you? ;-)
 

Gorgon

Joined Aug 14, 2005
113
Originally posted by atferrari@Oct 22 2005, 05:46 AM

A small robot with 3 omni directional wheeled legs controlled by the brains through an IR link with 4-bits commands: start / stop / reverse.

To allow a majority vote at the receiving end, each order repeated thrice.

Hi atferrari,
For your small application I would think that going from majority vote to a proper three equality would sequre your transmission link.
You may even try to transmit four or five times, inverting every second telegram, reinvert at reception and compare for total equality if you have systematic noise.

Padding with additional databits just to increase the telegram transmission time may also help.

TOK ;)
 

pebe

Joined Oct 11, 2004
626
Hi atferrari

I was just curious – wondered if it was part of an RF link.

Now you’ve said it’s IR, then perhaps details of a similar project of mine may be of interest to you.

I found that if there is an excess of IR radiation then there is very little chance of data being corrupted. The IR will be reflected off walls and ceiling as well as by the direct beam.

I used the TV remote control system as a basis for encoding the data. Present IR systems use a burst of 40KHz carrier as a ‘1’ and nothing for a ‘0’ and I believe they use Manchester coding.

But I used the older system of sending very short pulses as markers, leaving a period between them to indicate ‘1’ or ‘0’. A ‘0’ was 1ms and a ‘1’ was 2ms. A 5ms period was used as the first pulse, followed by a train of 4 bits (to give 16 commands), then the 5 pulses were repeated at least once, but for as long as the button was held down. The output of the receiver went to a microcontroller which compared two sets of the 4 data bits. As soon as two identical commands had been received, the command was actioned. I used a custom chip for the receiver and reduced the AGC time constant to prevent possible interference from fluorescent lights.

The marker pulses were about 5microsecs long so the duty cycle was very small. It was then possible to pulse the IR emitters at up to 1A without exceeding their ratings. I found the method gave solid communication with no glitches.

I have used this same method of very short pulses on another project (a starting-line beam for racing) and found it had a range of over 100ft.

I hope that may have given you some ideas. Good luck
 

Thread Starter

atferrari

Joined Jan 6, 2004
4,764
Hi Gorgon and Pebe,

Thanks for replying. Tomorrow I will do my frist check on the hardware. In the simulator, it seems to work.

Later I will try to speed up things. I am using the idea of the SIRC protocol (Sony).

Already changed the qtty of bits to simplify things.

I will revert with the outcome.

Gracias.
 
.include "2313def.inc"
.def DATA = r16
.def DATA1 = r17
.def TEMP = r18
.def BITCOUNT = r19
.def PARITY = r20

;*****************This is a kewl delay that gets the parity!!!*********************
ldi BITCOUNT,8 ;WE HAVE TO KILL 372 CLOCK CYCLES
a: sbrs DATA1,0 ;ANYWAYS SO LETS MAKE IT USEFUL!!!
rjmp ODD
rjmp EVEN

b: sbrc DATA1,0
rjmp ODD
rjmp EVEN

EVEN: ser parity
lsr DATA1
dec BITCOUNT
breq CHECKBIT
rjmp b

ODD: clr parity
lsr DATA1
dec BITCOUNT
breq CHECKBIT ;SO THE PARITY IS SET OR CLEARED
rjmp a ;NEAT HUHH

;*****************This is a kewl delay that gets the parity!!!*********************
I hope this helped someone, i killed myslef writing it,,, i would have been better to use the mov command when working with data, instead of using data1 and data 2,,, here the rest of it

CHECKBIT: ldi BITCOUNT,0x08
ldi TEMP,0x61; ;ALL BITS ARE AROUND
SB_DELAY: dec TEMP ;372 CLOCK CYCLES
brne SB_DELAY ;SO THIS IS A LOOP
nop
nop


GETBIT: sbrc DATA,0
rjmp LOWBIT ;CLEARS THE BIT
rjmp HIGHBIT ;SETS THE BIT

BIT_DELAY: ldi TEMP,0x78; ;ALL BITS ARE AROUND
BITDELAY: dec TEMP ;372 CLOCK CYCLES
brne BITDELAY
lsr DATA ;LSB CHECKED FIRST
dec BITCOUNT
breq SENDPARITY
rjmp GETBIT

HIGHBIT: cbi PORTB,2 ;SETS THE BIT
rjmp BIT_DELAY

LOWBIT: nop
sbi PORTB,2 ;CLEARS THE BIT
rjmp BIT_DELAY
;*************************************************************************
SENDPARITY: sbrc PARITY,3
rjmp SET
rjmp CLEAR

SET: nop
nop
sbi PORTB,2

CLEAR: nop
cbi PORTB,2
 
OMG, i cant believe i wrote that! due to the forum update i was notafied and completly forgot about this forum. now that i am back i really looked the code over to make sure i wrote it, lol, i dont even understand it now. Glad to be back on the forums...
 
Top