Is there such thing as a 4 bit CRC ?

Looks like there are some answers on the web. DuH !

Useful experience still welcomed !

boB

A simple 16 nibble array would work just fine. Of course.

Getting close so I am feeling a bit dumb even asking :)

Looks like x4 + x1 + 1 is used but that won't fit into 4 bottom bits. Maybe what I am really looking for is just a bastardization of the 4 bits I am tryng to hash ? Not sure how smart that table has to be.

Nevermind... I'm just stoopid.

Created an array of 15 randome numbers... That should work.

IF I am doing my math right 8 bits is good enough for 4 data bits, 3 syndrome bits, and a parity bit to give you 1 bit error correction, 2 bit error detection. That might be better than a 4 bit CRC.

You want the "distance" (i.e., number of bits that must change in order to convert one valid code into another valid -- but, now, INCORRECT -- code to be as long as possible. FOR EVERY POSSIBLE VALID CODE.

Once can *detect* N errors in codes if the distance between valid codes is N+1.

So, if you have to flip a minimum of 2 bits to be able to convert one code word into another valid (but incorrect) code word, then you can obviously detect any code that has *only* ONE flipped bit.

You can *correct* M errors in a code word if the minimum distance between code words is 2M+1.

Note that you need to understand the nature of your error sources in order to understand the protection any code will present. If each bit stands an equal chance of flipping -- but, the chance of multiple bits flipping is lessened due to the independence of those events -- then you want a different sort of code than if, for example, one flip *tends* to result in other flips.

E.g., if you are sending data down a communication channel and noise can blot out large chunks of the data stream, then your code needs to address the likeliness of multiple bits being affected in the same corruption event.

[Google "Hamming Distance"]

Use some Hamming code, which can correct one bit error and additionally detect odd number of bit errors. Used e.g. in Teletext page numbers, 4 bits of data (actually BCD) in an 8 bit octet (byte).

I will Google Hamming Distance. I think I understand that but possibly not.

This system does have the possibility of having quite a bit of noise actually. I probably should not have too small of error detection at least. I hadn't thought of using error correction but sending multiple times instead for this one. I think I have more time to resend rather than processor time for decoding.

Thank all of you for making me think more about this.

Thanks. I think I may just do 8 bit CRC for the short command.

I will be re-transmitting often enough I think for the messages to get through.

I had thought of Hamming (I think that's what I was thinking of ?)

Thanks.

Next, I do have to see exactly how much noise I will be dealing with here. It will be RS485 at not very high of data rate so I should have Shannon on my side. I hope.

boB

Your maths is good enough.

Given 4 data bits a, b, c, and d, you can calculate the parity bits

p = a ^ b ^ c q = a ^ b ^ d r = a ^ c ^ d s = b ^ c ^ d

and send these.

On reception, you then calculate:

P = p ^ a ^ b ^ c Q = q ^ a ^ b ^ d R = r ^ a ^ c ^ d S = s ^ b ^ c ^ d

Correct transmission will give zero for all of these. For one error, any three can be used to give the error bit - for two errors, those results will be inconsistent.

Theoretically RS-485 should be capable of 115200 bit/s up to 1 km, but requires good twisted pairs, proper termination and in practice also galvanic isolation.

I would be more worried about the short single byte messages especially on 2 wire RS-485, since during data direction changes (Rx/Tx switching) all drives are in tri-state and only the "fail safe" termination will keep the line in IDLE state.

If "fail-safe" termination is not used, turn on the Tx driver into IDLE ("1") state for a few character times. before sending the actual command byte. Keeping the Tx in IDLE state for a while, will get rid of any reflections on the bus, reducing the risk of bit errors.

Some kinds of noise or problems are related to data rates (and helped by low rates), but many are not. Don't blindly assume that lower rates are always better - sometimes it is better with higher rates and more expressive telegrams.

Thanks guys !

It is great to get some good dialog on this newsgroup :) Although I have seen some very good chat in the past.

This RS485 is on a back-plane and so is a short line at least.

Communications will mainly be from one master to maybe 4 slaves.

These are inverter modules so that is where the noise comes from.

I had one PWM line that was being interfereed with on the bus and what I did to fix it was to R-C low pass filter at the receiving logic end in the module. Worked wonderfully !

I am also designing in this R-C Low Pass Filter between the RS485 RX output and the microcontroller (ST) UART input.

Now, UARTS have up to a 16X sample and I have known this for many years (decades actually) but I have never looked into how that sampling actually works. Lower baud rate, I would imagine, should separate these samples by more time and help the data integrity. Any insight into this aspect ?

boB (in Phoenix AZ this week)

You seem to be expecting interference from the inverters. undriven differential lines like 485 might be susceptible to that. I believe there are biasing contraptions to set a defined output level in Hiz. use those. An rc filter on output might be a good idea, but by itself won't keep a Hiz line from toggling. Driving to a defined level before going Hiz is also a good idea to increase slew rates.

Ya know... We did that at another company several years ago on RS485... It got way out of hand. I'm not sure how biasing up the A and B lines might screw up any common mode rejection that is built into these receivers ?

I think that with good rejection of bad packets, using a CRC at the end of the packet, this should not be an issue. Also, the noise that gets into the lines is VERY fast and not long lasting at all (luckily)

The master transmit can certainly bring the transmitter active long before the actual data is transmitted. In fact, I'm not so sure I can't just keep the master holding the RS485 bus active all the time ?

For this application, I have not considered two-way communications yet as I don't think it will be necessary. Yet.

But we will see. Biasing may very well help.

Thank you for this input !

If this is a unidirectional system with just the master transmitting, keep the Tx always active. No need for "fail safe" DC biasing.

If the bus is just within a single PCB backplane, not much interference is expected at slow data rates. I would not expect much problems with low data rates (300-1200 bits/s) and single byte commands.

The classical way of biasing is at the ends of the bus line, with

100 - 150 ohm resistor between the A and B lines, and suitable resistors from one line to ground and the other resistor from the other line to power supply. With equal biasing resistors the common-mode is not spoiled.

There is considerable confusion which line is A and which is B. The bias polarity must be set so that the output of a receiver stays at the UART idle level (usually up) when no transmitter is active.

The 100 to 150 ohm resistance is a suitable termination for common twisted-pair line.

--

-TV

There is no confusion which line is A and which is B. Unfortunately, there is a great confusion which line is Tx+ and which is Tx- or D+ or D-, since some manufacturers have these mixed up.

Due to this mess, I have recommended using A/B nomenclature for RS-485 as well as for the RS422 for the Tx pair (and A'/B' for the receiving RS-422 pair).

100-120 ohms sounds about right, 150 ohms is a bit too much for ordinal twisted pairs.