CRC Errors - TP/FT-10

[ctrlguy]

I've spent less time than I probably should looking at my (mostly small) Lonworks networks through a protocol analyzer. Right now, I have a network with about 55 devices, daisy chained and doubly terminated. LonScanner is reporting about 1% CRC errors and around 60% bandwidth utilization. I've tried filtering the packets by subsystem and get no errors from anywhere when filtered that way. There are no apparent problems with the operation of the system, but the errors worry me. Do I need to worry? Buy a router? Adjust throttles?

[sysint]

Right. Are you serious?

[ctrlguy]

I'm seriously asking for some advice on how to diagnose my problem.

[dapper]

Is that bandwidth the average or the max? That's awfully high in any case. I believe the recommended rate is around 20% average.

[ctrlguy]

To be honest, I forget what the label was on that bandwidth usage. I'll look again tomorrow. The instantaneous usage was very low; a few percent.

Anyway, assuming my bandwidth number is the maximum or something, what about the CRC errors?

[yroy]

Anyway, assuming my bandwidth number is the maximum or something, what about the CRC errors?

If the average traffic (or bandwidth usage if you prefer) is above 40%, then is is natural to have continously increasing number of TE (transmission errors). These come up when two devices try to talk at the same time on the channel. These are nothing to worry about.

Cyclic Redundancy Check Errors on the other hand, are not supposed to <naturally show up> under heavy traffic conditions. Because it means the message was corrupted somewhere between the sender node and the receiving node. Corrupted as in <wrong bits at the wrong place>.

I do not understand why filtering would remove the CRC errors. My guess would be that the source of noise that is causing the corruption is intermittent, and that if you are persistent enough, you will see CRC errors even if you are filtering packets.

You said bus and doubly-terminated. I trust you are not using two 55 (I never remember the exact number) ohm termination resistors. With the two terminators in place (around 110 ohms each), you should still be measuring 55 ohms overall.

Okay, if it's in the 51-56 range, no worries.

If that's ok, then you are either violating some wire distance rule (based on the cable you are using, cause these rule changes based on wire type), or some node to node distance rule. Sorry I do not normally use bus, so do not know what these numbers are.

Either than that, it is possible that at some particular time of day, when some particular piece of equipment is turned on or off, that you get CRC errors induced in the data cable by some higher power and higher frequency signal running in a cable that <follows your data cable> in parallel for more than a few feet. Always avoid wiring in parallel with these types of cables.

Finally, if that is not the case either, avoid routing your data cable near equipment such as lighting ballasts. In this case, it is not that you are routing in parallel with anything but simply that you are too close to a very noisy piece of equipment.

Finally, a 1% CRC error is a fairly low error rate. Nothing to be alarmed about. You probably will never notice something wrong because of it.

Anyway, that's my 10 cents for tonight. Best of luck in all your projects.

[crankshaft]

Hi ctrlguy,
If the network was daisy chained, wouldn't you have the master at one end and the terminating resistor at the other? If you have two ends with terminators on them, the packets might be colliding or something. I don't think LON has collision detection / or packet ACK / NACK like TCP/IP.
Cheers
Crankshaft

[ctrlguy]

It was apparently a partial short in a wire left dangling from a controller for temporary FT-10 network access. Well, at least it went away when we removed the wire. I still don't understand the bandwidth thing. The value I read was the average bandwidth. I wouldn't have thought a wire problem would show more usage. Anyway, all fixed. It's using about 10&#37;.

[sysint]

Hi ctrlguy,
If the network was daisy chained, wouldn't you have the master at one end and the terminating resistor at the other? If you have two ends with terminators on them, the packets might be colliding or something. I don't think LON has collision detection / or packet ACK / NACK like TCP/IP.
Cheers
Crankshaft

I don't think so either. I think it's better than TCP/IP.