Results 1 to 9 of 9
  1. #1
    Join Date
    Aug 2006
    Location
    New England
    Posts
    520

    CRC Errors - TP/FT-10

    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?

  2. #2
    Join Date
    May 2002
    Posts
    9,564
    Right. Are you serious?

  3. #3
    Join Date
    Aug 2006
    Location
    New England
    Posts
    520
    I'm seriously asking for some advice on how to diagnose my problem.

  4. #4
    Join Date
    Mar 2003
    Location
    NY
    Posts
    2,164
    Is that bandwidth the average or the max? That's awfully high in any case. I believe the recommended rate is around 20% average.

  5. #5
    Join Date
    Aug 2006
    Location
    New England
    Posts
    520
    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?

  6. #6
    Join Date
    Nov 2006
    Location
    Mirabel, QC, Canada
    Posts
    88
    Quote Originally Posted by ctrlguy View Post
    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.
    -------------------------
    CO2 Racks Rock !

  7. #7
    Join Date
    Jun 2007
    Location
    Darwin, Australia
    Posts
    28

    daisy chain double terminated

    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

  8. #8
    Join Date
    Aug 2006
    Location
    New England
    Posts
    520
    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;.

  9. #9
    Join Date
    May 2002
    Posts
    9,564
    Quote Originally Posted by crankshaft View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Comfortech Show Promo Image

Related Forums

Plumbing Talks | Contractor Magazine
Forums | Electrical Construction & Maintenance (EC&M) Magazine
Comfortech365 Virtual Event