Application Pitfalls: Serial DF1 over WAN

Digi's wireless group was asking me why AB/DF1 didn't always work over radio when per the specification, DF1 has a nice end-of-message pattern. One would think moving serial DF1 through radio or cellular-IP would be natural and painless.

However, the problem I see watching Windows applications use the serial API (via the PortMon utility) is that they ASSUME a small delay or gap between the (DLE)(ACK) bytes and the response from the slave.

So the application uses the incorrect algorithm:

1. Read 2 Bytes
2. Ask Windows to notify application when more data comes
3. Loop, reading buffered data and waiting until full response seen
   

The problem with this algorithm is it assumes the response will NOT have been received by the time the application sees the 2 byte (DLE)(ACK). Because we're dealing with radio or IP system that make effort to packetize data there is a high probability that the (DLE)(ACK) and the slave response arrived at the same time within the same packet without any noticable gap. Therefore, Windows NEVER notifies the application of that more data has arrived ... because no more ever comes! The full response has already been received and buffered. The application makes the false assumption that measurable time will occur between step #1 and the start of loop #3.

The correct algorithm would be:

1. Read 2 Bytes
2. Loop, reading buffered data and waiting until full response seen

This works because it handles both the situation of no response, a response already received and fully buffered, and a response trickling in over time.

See Also:

• Download the Rockwell Allen-Bradley DF1 specification: this used to be open to download as a PDF ... it is still free but now you need to log into http://www.ab.com/ and find "DF1 Protocol and Command Set Reference Manual - Publication 1770-6.5.16"
  
• Download PortMon http://www.microsoft.com/technet/sysinternals/utilities/PortMon.mspx