Thanks CCIKelly - This was what I was looking for. I think I found the Bulletin you were talking about see attached I also didn't know the FX40 did not come with a EOL resistor?
I can't find any spec in any JCI lit giving details the questions electronic vendors always ask. Tolerance & watt of the 220 Ohm resistor - if any one knows please pass it on
Thanks, Chet
ddcfreek -Previous post -
I have poor FX40 N2 performance, including slow updating, intermittent comm loss, random alarms, and points randomly commanded to zero.Cause

oor N2 performance has been traced to multiple causes; all standard N2 troubleshooting items.
http://www.hvac-talk.com/vbb/cid:_1_...5B733E862573A1
Solution

erform the standard N2 troubleshooting (e.g. check the maximum bus length, be sure there are EOLs where applicable, ensure the correct polarity, etc.).
http://www.hvac-talk.com/vbb/cid:_1_...5B733E862573A1NOTE: The FX Controllers are not self-terminating. Therefore, be sure to install 220 ohm end-of-line resistors (EOLs) as specified in ASC and N2 Bus Networking and Troubleshooting Guide Technical Bulletin, LIT-6363003, N2 EOL Termination section.
http://www.hvac-talk.com/vbb/cid:_1_...5B733E862573A1
Details:Additionally, check the following items unique to FX40 N2 networks:
1) Observe the recommended maximum 1000 point limit per FX40 (this is the sum of all N2, LON, BACnet and Niagara points, see SDB 040522066005465: "How do I count the current number of points defined in an FX40?"
2) Ensure that the FX40 is running the latest jciN2.jar file. This can be determined by opening the Software Manager in FX Workbench Pro - all software modules in an FX40 v1.2 should be at 3.0.106 (for FX40 v1.0 or 1.1, jciN2.jar should be 3.0.99.11).
This version of the jciN2.jar file incorporates features that demonstrably improve communications to TEC, DX9100 and VMA controllers.
Internal Notes FSC Only: In response to some complaints of poor N2 performance, Steve Michals has produced an updated jciN2.jar 3.0.106.23 which incorporates the following new features:
- modified handling of negative acknowledge (NAK) errors which are common with TECs; the updated behavior is more consistent with N2 driver behavior in NAE and N30.
- immediate read-back of values following an adjust command (instead of waiting for the entire poll cycle to read a point's value); this is in response to user complaints that setpoint adjustments are not promptly reflected in the graphic or text screens of the FX40
3) On projects with N2 TECs, communication was improved by the addition of a 0.047 microF capacitor at each end of the N2. In instances where the typical 220 EOL resistor is already in place on the N2, these capacitors would be wired in parallel with the EOL.
See the Product Update PU 07-07: Compatibility Issues Related to TEC21xx Series N2 Networked Thermostats Communicating with a Supervisory Controller.
http://publish.cg.na.jci.com:9085/pu...p_z/pu0707.pdf
Why does this work? Somewhere around mid-2006, there was a production change to the TEC N2 circuit. TECs from this production batch sometimes generate an N2 noise spike that can negatively affect N2 communication. The capacitors act to dampen out this noise to yield cleaner N2 communication.
4) On projects with VMA controllers...
a) Ensure that the VMAs are upgraded to the latest firmware C04.
b) Edit the temperature change-of-value (COV) increments to at least 1 DegF.
c) Because VMA controllers impose a greater polling load on the N2 bus than traditional N2Open devices (such as the UNT, VAV and AHU controllers), count each VMA as being equivalent to 2 ASCs when engineering an FX40 N2 network. E.g., an FX40 N2 network comprised of 30 UNTs and 35 VMAs would represent 30 + (2 x 35) = 100 controllers - the recommended maximum.
5) On projects with traditional ASCs (i.e. UNT, VAV, AHU, DX9100), reload controllers using the latest version of HVAC Pro 8.08. With DX9100 reload controllers using the GX-9100 Programming Tool version 7.04 or newer.
6) Free up FX40 memory by reducing the number of internal database backups to zero. We have feedback that some random behaviors (such as false alarms, points going to zero) are drastically reduced by this strategy.