Tag Archives: ARC156

Noise Immunity of ARC156

Posted on by

From firmware 6.00,  BACRouter had built in a software noise filter for RS485. Here we will investigate its performance on ARC156.

Performance Of Reference Devices

The reference devices are ZN551 and AAR modules which utilize microchip COM20019i to handle ARCnet communication.

From testing, the reference devices only care about the falling edge of signals which corresponds to differential voltage of RS485 bus.  Signal width does not participate to decode, unless the width is less than 0.52us which will be ignored. The mechanism is described in following paragraph.

These reference devices have a hardware noise filter built on SN74HC164 and SN74AHC1G32. On 10M clock base, only input signal levels from RS485 transceiver are low both on 1th and 5th clock, COM20019i will receive a low signal, so low level pulses shorter than 0.5us will be filtered.

Idle RS485 bus is more vulnerable to noise, because the biasing current is only a few Milli-amperes, it will take much longer to recover from noise signal than a driven bus which one node is in sending state.

On an idle bus, noise signals wider than 0.52us will be mistakenly decoded by COM20019i as a starting pulse of a new frame.

On a driven bus, when a bit 1 is being sent, there should be a falling edge of differential voltage,  if falling edge of noise is in the range of +/- 3.2us of valid signal’s falling edge, COM20019i will detect multiple falling edges, duplicated edges will be ignored.

When a bit 0 is being sent, there is no falling edge, but if there is noise of which falling edge is in the range of +/- 3.2us, COM20019i will incorrectly decode to bit 1.

Performance Of BACRouter

On and idle bus, BACRouter can tolerate noise signals shorter than 2.1us.

On a driven bus, if there is continuous bit 1s being sent,  the pulse width is 3.2us, BACRouter can only tolerate noise signal shorter than 1.05us. If there is bit 0 being sent, the pulse width will be greater than 6.4us, then BACRouter can tolerate noise signal shorter than 2.1us.

Conclusion

Immunity(Width of Noise signal)BACRouterReference Device
Idle Bus2.1us0.52us
Bit 1s being sent1.05usDon’t care
Bit 0 being sent2.1us0.52us

ARC156 and Multiple Frame Ratio

Posted on by

One of ARCNET’s greatest feature is determinacy. It has several design decisions to help it being deterministic.

  • Only 1 packet can be sent for each token pass.
  • The max payload of a packet is limited to 507 bytes.
  • Every delay is strictly limited.

So for ARC156, the time of the token passing a node is about 40.1 milliseconds in worst case that the node has a non-broadcast packet with 507 bytes payload to send and the propagation delay is extreme.

If a node has no packets to send, neglecting propagation delay, it only take 448 microseconds for the token passing. It’s very fast comparing to ms/tp.

In BACnet network, most packets have less than 50 bytes. For example, a ReadProperty request relayed from BACnet IP to ARC156 has only 25 bytes payload, a typical respond has only 32 bytes payload.

If there is a ARC156 bus with 30 nodes, one of nodes is router which relays packets from/to BACnet IP network. For each token passing round, the router sends one ReadProperty request asking for Present_Value property of Analog object in one of other nodes which replies a Complex ACK.  The time for the a passing round is about  21.4 milliseconds, so the throughout is 1/21.4 = 0.0467 transaction per milliseconds.

If we allow the router to send multiple request when it holds a token but passes token out before it has used token for 40.1 milliseconds,  the throughout will be improved while the determinacy is not degraded.

For example, if the router send 10 requests to different nodes before it passes the token out, it only takes 36.7 milliseconds. Nodes with request received will send reply when token is passing them. The total time for a token passing round is about 90.8 milliseconds.  The throughout is 10/90.8 = 0.11 transaction per milliseconds, it is about 2.36 times as standard implementation.

“Multiple Frame Ratio” parameter for BACRouter’s ARC156 port defines how long time BACRouter can hold the token to send multiple packets. For example, If “Multiple Frame Ratio” is 0.5,  then BACRouter can hold the token for 0.5 * 40.1 milliseconds = 20 milliseconds. 40.1 milliseconds here is the longest time a node can hold token we discussed at the begin.

BACRouter Changlog v6.00+

Posted on by

BACRouter switched to ARM soc from v6.00.  Now the firmware file format is xxxx_xxxx_6.00_arm_xxxx.tar.gz

For firmware version prior to v6.00, please visit: old firmware

6.12  2025.04.29  Download

ARC156:  If next station had been verified, when passing token failed, retry it once.

ARC156: If a frame lasts less than 5 bits,  regards it as noise.

6.11  2025.04.02  Download

ARCnet standard and Datasheet of COM20019i state that the accuracy of clock should be 0.01% or better, so our previous implementation utilize a conservative clock error correction logic to tolerate clock error to 0.05%. After testing ZN551 and AAR module, we found they actually tolerate clock error up to 4.5% when decoding packets(The reconfiguration process still require clock error less than 0.2%), they are supposed to synchronize receiver clock to pulse preceding every byte. In this version, we implement a aggressive logic to achieve similar or better performance.

6.10  2025.03.28

ARC156:  The “Nodes on the bus” runtime info may detect non-existed node when two segments of bus with active nodes join together.  The workaround is double detecting to avoid false signal.

ARC156:  If BACRouter is the sole node on the bus, it will keep sending ITT(Invite To Transmit) to look for other nodes, none data packet can be sent. any NPDU sent to this port will be timed-out on the queue, then it will be annoying in the log. In this version, if BACRouter find itself is sole node on the bus, it will delete packet on the queue at a reasonable rate, and record it on the packet capture buffer to pretend sending the packet out. So when investigating packet captured, BACRouter are sending packets but get no response, this behavior is consistent to other data-link type.

Modbus RTU:  Some devices do not respect T15 between bytes, we remove the verify to improve compatibility.

Application Settings:  “Client Mode” is removed to comply to BTL requirement.

Modbus/FreeClient: When debugging the mapping or script, Writing from BACnet side usually need to be perform, user has to launch a BACnet client for example Yabe. There is often a BACnet server already running on the computer, so user has to start a VM to run Yabe. It wastes a lot time, so we integrate write function on the runtime info page.

6.09  2025.02.26  Download

MSTP bug to manipulate hardware will cause certain NPDU body discarded.

6.08  2025.01.23  Download

WebUI bug on Modbus Master Module:

When “Write Test” analog object mapping to single register, the byte order should respect to “Byte order for single register”, not “Byte order for big integer”.

When “Write Test” multi-state object mapping to 2 registers, the byte order should respect to “Byte order for big integer”, not “Byte order for single register”

The real value of binary object of free client device in “Runtime Info” page should respect to polarity setting.

6.07  2025.01.10  Download

Because BACRouter highly rely on high resolution timer, If there is electromagnetic disturbance, the crystal on the board may be disturbed, so timer will drift, lead to program malfunction.  We add correct function in this version.

6.06  2025.01.07  Download

Bugfix for free client module’s binary output object. It was introduced by v6.01 Polarity feature.

Modbus master module: when writing to read only data address, some devices respond timeout instead of report a exception, which will cause BACRouter keeps trying and fails with offline. For this version, BACRouter will only try 3 times then gives up.

6.05  2025.01.04

Refactor low level arc156 and ms/tp drivers to simplify code.

ARC156 driver add logic to drop packet send to node responding excess NAK to Free Buffer Enquiry

WebUI: Remind user when IP or netmask has been changed but DHCP server keeps enabled,

6.04  2024.12.26  Download

Fix bug on ms/tp:  Sending packet to ms/tp port with NPDU length near 1497 bytes may trigger the bug.

6.03  2024.12.25

ARC156 is usable now.

6.01  2024.12.06

Fixed bug on bus name collision detection for Modbus/Free Client module.

Free Client:  Bianry objects add “Polority” attribute. Multistate objects add state quantity limitation of 256.