Im trying to communicate with a device via serial but am having a hard time understanding the protocol. I am not too familiar with serial communications.
Introduction This document will describe the Extended Communications Protocol as implemented with InfoSight Marking System software. Extended Protocol is intended to provide secure communications with an intelligent host device. This document assumes familiarity with the ASCII character code as well as fundamental computer programming skills. Disclaimer This document is correct to the best knowledge of InfoSight Corporation which reserves the right to change the document's contents or the systems referred to at any time without prior notification. Protocol Parameters Communications is established via an RS232 serial connection with the following parameters: Communications Parameters Baud Rate Selectable 1200 - 19200 Data Bits 8 Parity None Start Bits 1 Stop Bits 1 Three Wire RX, TX and GND Software handshaking (XON/XOFF) is implemented in some types of marking systems to control the flow of information. Hardware handshaking (DTR/DSR) is not implemented.
Communications with the marking system controller is accomplished via a Master / Slave arrangement with the Host being the Master and the marker being the slave. The slave will only transmit in response to a message from the master.
Note: All transmissions are in standard ASCII utilizing the following control characters: Control Character Definitions Character Definition Hex Decimal SOH Start of Header 0x01 1 STX Start of Text 0x02 2 ETX End of Text 0x03 3 CR Carriage Return 0x0D 13 ACK Acknowlege 0x06 6 NAK Negative ACK 0x15 21 XOFF Transmit Off 0x13 19 XON Transmit On 0x11 17 Master Data Format SOH TYPE STX DATA TEXT ETX BCC CR Where, TYPE - A single printable ASCII character that defines the meaning and the contents of the message DATA TEXT field. Message types may be custom defined for certain applications as required. Standard message types are defined later. DATA TEXT - An optional field which contains the actual data of the transmission. Some message types require no data since the 'message' is conveyed by the TYPE character. BCC - This is an optional field used to improve link reliability by providing fault detection.
The BCC is computed by taking an eight bit addition of the TYPE and DATA TEXT characters and transmitting them as a three digit ASCII decimal number in the range 000 to 255. Refer to the example BCC computation later in this document. Slave Data Format (response) The slave will respond to the master's transmission in one of two ways depending on whether errors were detected or not.
SOH TYPE ACK STX DATA TEXT ETX BCC CR or SOH TYPE NAK STX DATA TEXT ETX BCC CR If no errors were detected in the reception of the packet, then the first response will be sent back to the master. If any errors were detected (e.g. Parity, Framing, Overrun, BCC, Format, etc.) then the second (NAK) message will be sent. Note that the ACK message does not necessarily imply that the DATA TEXT field itself is correctly presented, just that no communications errors occurred.
The TYPE character will always be the same as the received TYPE. The DATA TEXT field is optional and depends on the message TYPE. The BCC field will always be present in the response. Retries If the host does not receive a response from the I-Dent within three seconds, or it receives a NAK response, it should retransmit the entire packet.
If, after three retries (four tries total), the host has not received a response, the host should declare the link to be 'down'. Standard Message Types Certain message types which are common to most marking systems are briefly discussed below. For a complete description of the Extended Protocol message types for a particular marker, refer to the data sheet for that marker. 1 - The DATA TEXT is a message to be printed. The message text is stored in the buffer for the currently assigned buffer. The response message contains no data in the DATA TEXT field.
A - The DATA TEXT is a number from 1 to 10 specifying the buffer number to Assign for printing. The response message DATA TEXT field will contain an ASCII '1' if the assignment number is valid, or '0' if it is invalid. S - This type is used to query the marker for its current status. There is no DATA TEXT field for this type. The ACK response message from the marker will contain a DATA TEXT field.
This field will contain one or more numbers separated by commas where each number is made up of four ASCII digits representing a decimal value. The binary equivalent value of this number has a bit pattern representing the status of the marker and is dependant upon the specific marker and application. Example BCC Computation The following example is a typical transmission including the BCC.
To download the character string 'ABC123' to the currently assigned message buffer, send the following message. SOH 1 STX ABC123 ETX 141 CR where '1' is the message TYPE and 141 is the BCC. The BCC is computed as follows (note all math shown in hexadecimal): 1) BCC = Message TYPE character + DATA TEXT characters.
031H 1 - Message Type 041H A 042H B 043H C message Text 031H 1 032H 2 + 033H 3 / 18DH 2) We are only interested in the lower eight bits of the sum, so we discard the first digit and keep the lower two. This results in a BCC of 8DH. Note that when performing the summation in an eight bit variable (e.g. Unsigned char in 'C') that the most significant bits are automatically truncated. If the master's programming language is incapable of doing eight bit addition, then the same result can be obtained by taking the MODULO 256 operation on a sixteen bit sum.
The MODULO operation is division where the Remainder is kept and the Quotient is discarded. 3) Once the BCC value is obtained, it must be placed into the message packet after the ETX character.
The BCC must be transmitted in its decimal ASCII form. The decimal equivalent of the hexadecimal value 8DH is 141 decimal.
Converting the value 141 into three ASCII characters yields 031H, 034H and 031H. These three characters become the transmitted BCC. The actual data transmitted (in hex) by the host for this message is: 001H 031H 002H 041H 042H 043H 031H 032H 033H 003H 031H 034H 031H 00DH 4) If the marker receives the message correctly, it will respond with the following message: 001H 031H 006H 002H 003H 030H 034H 039H 00DH which equates to the following ASCII message: SOH 1 ACK STX ETX 049 CR Note that if the marker detected an error in receiving the message from the host it would respond with a NAK (015H) character in place of the ACK. The BCC would be unaffected by this since the ACK/NAK is not included in the BCC computation. Conclusion This concludes the description of the Extended Protocol for communications with InfoSight Corporation Marking System Software. Please refer all questions to the factory. For Windows is available for download.
Download the datasheet. Specifications are subject to change without notice.
#include ' Overview This library provides functions needed to transmit and receive STX/ETX packets over any interface which can send and receive bytes. STX/ETX is a simple packet protocol for serial data streams and offers packetization, type tagging, and checksum protection for user data. Common uses of STX/ETX might include radio communications were it can improve data reliability over lossy channels. STX/ETX may also be used effectively anywhere multiple access to the communication medium is required.
The packets can be made to contain destination addresses or routing information as well as data. STX/ETX Details STX/ETX is a simple packet protocol that can be wrapped around user data for one or more of the following reasons: 1. Packetization is needed. Using packets can be helpful if your data naturally forms little 'bunches' or if different types of data must be sent over the same channel (a serial cable, for example). If your data forms 'bunches', you can send user data inside STX/ETX packets with a predetermined structure, like an array of A/D conversion results. If you need a way to tell the receiver what kind of data you're sending, you can use the TYPE field in the STX/ETX packet. Error checking is needed.
STX/ETX packets will add a checksum to your data. This allows the receiver to verify that data was received correctly and is error-free. Packets which are corrupted in transmission and fail the the checksum test are automatically discarded. Error checking is especially useful when the data transmission channel is unreliable or noisy (examples: radio, infrared, long cables, etc) STX/ETX packets have the following structure: STXstatustypelengthuser data.checksumETX All fields are 1 byte except for user data which may be 0-255 bytes. Uppercase fields are constant (STX=0x02, ETX=0x03), lowercase fields vary. The length field is the number of bytes in the user data area. The checksum is the 8-bit sum of all bytes between but not including STX/ETX.
Generated on Tue Sep 20 03: for Procyon AVRlib by 1.4.2.
Binary Synchronous Communication ( BSC or Bisync) is an character-oriented, half-duplex, announced in 1967 after the introduction of. It replaced the (STR) protocol used with second generation computers. The intent was that common link management rules could be used with three different character encodings for messages. Six-bit looked backwards to older systems; with 128 characters and with 256 characters looked forward. Transcode disappeared very quickly but the EBCDIC and USASCII dialects of Bisync continued in use. At one time Bisync was the most widely used communications protocol and is still in limited use in 2013. Contents.
Framing Bisync differs from protocols that succeeded it in the complexity of message framing. Later protocols use a single for all messages sent by the protocol., (DDCMP), (PPP), etc. Each have different framing schemes but only one frame format exists within a specific protocol. Bisync has five different framing formats.
Scuilli, Joseph A. (Oct 26, 1981). Retrieved Aug 27, 2012. Retrieved Oct 23, 2013. Retrieved Oct 23, 2013.
IBM Corporation. Further reading. (new link). Connectivity Knowledge Platform. Retrieved 2006-07-06. A detailed description of the protocol.
Telecom Corner Technical Reference Site. TBI/WebNet, Inc. October 2004. Retrieved 2006-07-06.
Serengeti Systems. Retrieved 2006-07-06. Surag serial full episode.
Serial Protocol Stx Etx
IBM Corporation. Retrieved 2012-06-07. IBM Corporation. IBM Corporation.
This article is based on material taken from the prior to 1 November 2008 and incorporated under the 'relicensing' terms of the, version 1.3 or later.