Reading binary commands using PC comm port and Windows OS on XStream radio modems

The XStream interface board gives a PC comm port access to the RTS/CMD (module pin 5) and the CTS (module pin 1) signals as well as the Din and Dout signals necessary to interact with the binary command mode. 

The RTS signal from the PC is used to indicate whether incoming serial characters should be interpreted as commands or data. The CTS signal from the radio is used to frame a binary response, it also pulses to indicate when the binary command has executed. The signal timings are important as the program must ensure that the RTS signal is de-asserted during the last bit of the binary command byte transmitting to the radio modem. Note that just because the character has been copied to the serial out buffer doesn't ensure that it has entirely shifted out the serial port. Here is an algorithm for performing a binary read:

Try observing the timing of the assertion and de-assertion of the RTS signal compared to the TXD signal using an oscilloscope. To observe the calls that X-CTU (XCTU) software makes to the serial port during the reading and writing of binary commands consider using a free application called PortMon. 

Here are some guidelines to keep in mind when developing applications to use the binary command interface:

1. During a binary read, the CTS signal is used to frame the binary response. We recommend monitoring the CTS line to differentiate the response from the binary command from data coming out the serial port that may have been received over-the-air.
2. When doing a read, be sure to clear the CTS event twice before asserting the binary command mode. This can be cleared by reading it using the WaitCommEvent (see MSDN).
3. Set RTS using EscapeCommFunction (see MSDN).
4. CTS will frame the response so wait for a CTS event before de-asserting the command mode.
5. If using a USB serial driver, note that it is not as responsive as a mother board serial driver. This is because the USB protocol adds additional latency because it is time slot driven (TDMA). As a result, the driver cannot get immediate responses to queries but must wait for the USB to return the result.
6. With that in mind, don't poll the driver rapidly (every millisecond). Try to avoid doing single character events but design comm port functions to operate on larger blocks of data when possible.(I.E. Try to read blocks of data from the comm port, not just one character. This is more efficient for the driver and the USB bus.)
7. Use the WaitCommEvent with timeouts to trigger on events instead of using a port polling mechanism. This programming technique allows the driver the time it needs to respond and keeps the application from overloading it with requests.

Following these guidelines will facilitate the implementation of binary commands on a PC platform using the windows operating system.