qmix/qbus mwd communication protocol ˜ a brief …

ERDOSMILLER

QMIX/QBUS MWD COMMUNICATION PROTOCOL - A BRIEF INTRODUCTION

Copyright © 2017 Erdos Miller 2

Introduction Since inception, one of our passions at Erdos Miller has

been designing and developing measurement while

drilling (MWD) tools. These tools, while only relevant

to a handful of people, are an engineer’s dream given

their complexity and the intense challenge of designing

one that works reliably time and again.

Many years ago, the Tensor corporation brought to

market the first affordable mass market MWD system.

The company took the capabilities that only a few of

the majors, like Schlumberger, Halliburton, and Baker

Hughes possessed and made an affordable system

for the mass market. Thousands were sold, and this

system quickly became the working standard for

smaller service companies, with many compatible third-

party replacement components being developed.

Like most complex systems, there was a need for

machine-to-machine communications. The engineers

at Tensor chose to implement a custom serial protocol

of their own and called it qMIX, also known as qBUS,

q/BUS, q/MIX, or sometimes just q. Given that the

Tensor systems became the working standard, qMIX

also became the standard communication protocol.

Even though these tools were developed many years

ago, they are still prevalent today, and to successfully

develop MWD equipment compatible with a wide array

of today’s tools, one must master qMIX. However,

mastering qMIX and developing compatible software

is a challenge. Little to no documentation exists so

you’re left on your own. You need to break out an

oscilloscope, decode the communication by hand,

and reverse engineer the operation of this complex

communications protocol byte by byte.

Erdos Miller has built dozens of devices that use the

qMIX/qBUS protocol and we can help our clients

achieve the same. This guide is meant to be an

introduction to one of the more obscure protocols we

have ever encountered.

Bus Architecture

The qMIX protocol defines the procedures for

communications over a multipoint link where two

or more processors are connected. The bus is

controlled by a communications bus master (CBM)

which arbitrates all bus traffic. Nodes on the bus have

a unique ID number in the range of 00-99. The bus

master cycles through the address space polling each

node and the addressed node may transmit data at

this time if it is available. Data transfers between nodes

are relayed through the bus master rather than directly

from node to node. The protocol allows for one node

to relinquish bus master status to another node, but in

practice few nodes have the capability of being bus

master; examples include MPUs and some surface

receivers. Data is transferred using predominantly

ASCII characters, although binary data transfers are

also possible.

Typical node addresses in an MWD string are shown in

the table below. Often, MWD tools only contain node

20, the MPU (MPTx20). A table of the qMIX address

space is shown below.

The relationship between the user PC, receiver, and the MPU (other nodes can be connected in parallel with the MPU).

PC Receiver MPURS-232, USB, or Ethernet

qMIX


Node Address Description

00-04 User PC(s)

05 Surface Receiver (MPRx05)

06 Field Service Primary PC

07 Field Service Secondary PC

08Reserved for Driller’s Remote Terminal (DRT 08)

09 Driller’s Remote Terminal (DRT 09)

20 Downhole Tool (MPTx20)

21-29Reserved for downhole sub-system nodes

30-99 Undefined

The physical layer of the bus consists of a single

communications signal, line 5 on common GE/Tensor

compatible MWD systems. In general, the bus uses

half-duplex asynchronous serial communication at a

5V TTL level. Data characters are transferred at 9,600

baud, 1 start bit, 8 data bits, 1 stop bit, and no parity. In

contrast to common implementations of a 5V UART, the

qMIX bus is inverted and idles at 0V.

Bus Data FlowTwo predominant uses of the qMIX bus are inter-node

communication and configuration of the MWD. The

majority of MWD tools in the field run with a single

node on the bus, the MPU (MPTx20). In these cases,

the qMIX bus simply idles, cycling through polling

sequences of slave IDs (all of which time out).

There are several devices on the market that can

augment a GE/Tensor compatible MWD string by

taking advantage of the qMIX bus, which allows

communication between these devices and the MPU.

Examples of information available through the qMIX

interface include surveys, battery voltage, and flow

state. These devices may also store values to the

MPU, which are transmitted to the surface in survey or

telemetry sequences. Variables available for such use

are called generic variables (GVs).

The settings of an MWD tool can be modified when

the MPU (device address MPTx20) is connected to a

surface receiver (device address MPRx05). The receiver

may negotiate for bus master status, depending on

manufacturer and model.

ASCII control characters shown in bold in the following

examples are non-printable.

Bus Communication Protocol

At power-up, the communications bus master initializes

the qMIX bus and starts polling the slave address

range, inquiring whether the node has any information

to send. The bus master has three primary types of

messages that it sends to the slave devices, including

polling sequences, calling sequences, and message

broadcasts.

Polling Sequence

A polling sequence is sent from the bus master to a

slave device inquiring whether the slave has any data

to send. The slave device will then either send data, if it

has any, or it will indicate that it has no data to transfer.

A typical polling sequence consists of an enquire

prefix (ASCII characters LF CR), a two-digit address

(ASCII encoded), a left arrow (‘<’), and the ASCII enquire

character (ENQ).

An example polling sequence to node address 21 is

shown below. The top line is the human-readable ASCII

form and the lower line shows the corresponding hex

values.

ASCII: LF CR 2 1 < ENQHEX : 0A 0D 32 31 3C 05

The slave device can respond in several ways:

1. With Data — If the slave device has data ready

to transmit to any other node, it starts a transfer

sequence (described in the following sections).

2. No Data — If the slave device has no data to

transfer, it sends an ASCII end-of-transmission (EOT)

character, terminating the calling sequence.

3. Bus Master Request — If the slave device wants

to become the bus master, it can try to negotiate

bus master status with the active bus master. The

bus master can either approve or deny the request.

Most slave devices do not have the capability to

become bus master.

4. Timeout — If there is no slave device to respond to

the calling sequence within a four-character time-

period, the bus master will place an EOT character

on the bus and consider the addressed device

‘offline’.

Calling Sequence

A calling sequence is initiated by the bus master when

it has data ready to be sent to a slave device. The

slave device will acknowledge the calling sequence

if it is ready to receive the data from the bus master. If

the slave device is not ready to receive the data, it will

not acknowledge the calling sequence and the bus

master will repeat the calling sequence later. A typical

calling sequence consists of an enquire prefix (ASCII

characters LF CR), a two-digit address (ASCII encoded),

a right arrow (‘>’), and the ASCII enquire character

(ENQ). An example calling sequence to node address

21 is shown below.

ASCII: LF CR 2 1 > ENQHEX : 0A 0D 32 31 3E 05

The slave device can respond in several ways:

1. Ready to Receive Data — If the slave device is

ready to receive data, it responds to the calling

sequence with an acknowledge (ACK) character.

The bus master will then begin a transmission

sequence to the slave device (described in the

following sections).

2. Currently Not Ready to Receive Data — If the

slave is currently not ready to receive data, it can

place an ASCII NAK character on the bus. This

indicates that the bus master should retry the

calling sequence. The bus master will attempt the

calling sequence periodically until the slave device

responds with an ASCII EOT or ACK character.

3. Cannot Receive Data — If the slave device cannot

receive data it will place an EOT character on the

bus, ending the logical link with the bus master.

In contrast to the ‘Currently Not Ready to Receive

Data’ state, the bus master will not try to resend

the data. This can be used in conditions where the

node is incapable of receiving (or storing) data.

4. Timeout — If the slave device does not respond

within four-character time-periods, the bus

master will retry up to three times. If no response

is received, the bus master will consider the

addressed device ‘offline’.

Message BroadcastMessage broadcasts provide a method of data

transmission to multiple nodes at once. These

messages are generally reserved for non-critical data

as the protocol provides no method to verify that

the messages were received correctly. The structure

of a message broadcast is like a calling sequence,



consisting of an enquire prefix (ASCII characters LF

CR), a two-digit address (allowing for wildcards), a right

arrow (‘>’), and the ASCII enquire character (ENQ). It is

then immediately followed by a transmission sequence.

The broadcast sequence is like a regular message

transfer sequence with the exception that the message

transfer sequence (described in the following section)

is terminated by an ASCII EOT character instead of an

ENQ character.

An example broadcast to node addresses 20-29 is

shown below.

ASCII: LF CR 2 # > ENQ HEX : 0A 0D 32 23 3E 05

In this message, the ‘#’ character is a wildcard and

represents all characters 0-9. To broadcast to all nodes

on the bus, the address of ‘##’ would be used.

Recognizing the broadcast, slave devices will receive

the data contained in the message transfer sequence

if the slave’s own address falls into the broadcast

address range. Unlike polling or calling sequences,

slave devices never respond to a message broadcast.

Message Transfer SequenceThe above sections describe three methods that may

result in a data transfer between nodes, including:

1. A polling sequence resulting in a data transfer

from a node to the bus master.

2. A calling sequence resulting in a data transfer

from the bus master to a node.

3. A message broadcast resulting in a data transfer

from the bus master to multiple nodes.

The structure of a message transfer is composed

of three fields that are separated by ASCII control

characters. Italic fields below represent actual data.

ASCII: SOH [header] STX [data] ETX [crc] ENQ HEX : 01 [header] 02 [data] 03 [crc] 05

Header Field

The header field is made up of 14 to 24 characters

and is framed by the start-of-header (SOH) and start-

of-text (STX) ASCII characters. The first 14 characters

define the destination name (D), destination node ID (N),

source name (S), and source node ID (M), using ASCII

characters. This is followed by two characters defining

the message type (T).

ASCII: SOH DDDD NN SSSS MM TT … STX

The first character in the message type field is always

a forward-slash. Possible message types include the

following:

1. /? Designating an inquiry

2. /< Designating a reply (back)

3. /> Designating a download

An additional 10 bytes are reserved for application

dependent information but this is generally not used in

MWD applications.

Data Field

The data field is alpha-numeric ASCII coded data,

either requesting or setting the value of a variable or

field. The data field is framed by the start-of-text (STX)

and end-of-text (ETX) ASCII characters.

CRC Field

The last field of a message transfer sequence is a

4-character hexadecimal block-check field and is

framed by the end-of-text (ETX) and the enquire (ENQ)


ASCII characters. However, in the case of a broadcast

message, it is instead terminated by the end-of-

transmission (EOT) ASCII character. Valid characters for

the CRC field are the ASCII digits 0-9 and A-F.

Examples

Here is an example of a PC (node address of ‘Mon 02’)

requesting the value of ‘GV0’ from all devices on the

qMIX bus. Note that the ASCII control characters are

shown here in bold and are non-printable. They are

only shown for illustration purposes, separated from

the message fields by spaces.

This qMIX transmission is a broadcast message, and by

using all wildcard characters in the destination name

and ID fields it is addressed to all nodes. The contents

of the message request the value of variable ‘GV0’

from all slave nodes on the bus. A possible response

to this transmission sequence may be the following.

Note that for the above examples, extra space

characters were omitted from the data field to keep the

example concise. In practice the CRCs shown above

would be invalid.

Flow Control

Message transfers other than broadcasts require the

receiver of the message (master or slave) reply with

either a positive or negative acknowledgement within

four character cycles. This uses the ASCII ACK or NAK

characters, respectively. The transmitter will then

terminate the logical link with the receiving node using

an end-of-transmission (EOT) character within four

character cycles.

SummaryIn this document, a basic overview of the operation of

the qMIX bus used in GE/Tensor-compatible MWDs was

presented. First, we provided a general overview of the

bus architecture and data flow. Next, major aspects

of the qMIX protocol were presented on a holistic

level, and the three types of messages that exist in

the protocol were briefly discussed. Finally, examples

were provided to illustrate standard qMIX data transfer

directives.

The purpose of this document was to give a general

overview on the qMIX protocol and, for sake of brevity,

a comprehensive discourse on the details of the

protocol have been omitted. For more information,

please contact Erdos Miller and speak with

professionals who have extensive experience with the

qMIX communications protocol.

ASCII: SOH Mon 02MPTx20/</x STX GV0= 2.5 ETX 84F6 ENQ

ASCII: SOH ____##Mon 02/?/x STX gv0? ETX 82F5 EOT


About Erdos MillerTurnkey solutions made to last in the harshest environments

With our extensive experience in designing rugged and reliable downhole electronics, software, and surface

equipment, Erdos Miller can solve your oilfield engineering challenges. We have experience designing custom

MWD electronics, firmware, and software for our customer’s downhole and surface equipment needs.

Let us know how we can partner on your next project.

Address

15120 Northwest Fwy.

Ste. 100

Houston, TX 77040

Contact

1-888-337-0869

[email protected]

erdosmiller.com

qmix/qbus mwd communication protocol ˜ a brief …

Documents