BarcodeMan: The UK source for Barcode Technology - The Mule™ Advanced User Documentation

This documentation is for the latest version Mule which includes a USB interface. If you have an earlier model (identified by having 2 round DIN connectors on the end) the documentation is here.

Overview

The Mule converts RS232 ASCII data into scancodes which the computer interprets as keystrokes. It can act as a 'virtual keyboard' by emulating a keyboard directly in hardware (KeyWedge Mode) or can utilise the USB port to achieve similar results utilising the Human Interface Driver (HID) provided with many modern operating systems.

The Mule can be used to simplify the interconnection of devices such as Barcode Scanners, Weighing Scales and other technical instrumentation to applications software even if the software authors had not anticipated the need for such interoperability.

The Mule can be used to allow one computer to control another. This has wide application in industrial, technical, scientific, manufacturing and testing environments.

Fitting the interface cable

The Mule is supplied with both KeyWedge and USB interfaces. Select either the PS2 KeyWedge, or the USB Keyboard cable assembly.

Push the connector into the square hole in The Mule. Press firmly until the latch engages (listen for a slight click) and the cable cannot be pulled out again.

Removing the interface cable

Connect to computer

KeyWedge configuration

USB keyboard configuration

The Mule USB interface works with virtually all computers which will work with a USB keyboard. Including PCs and Macs. The driver used by the Mule is identical to that used by the keyboard. It is sometimes called the HID (Human Interface Device) driver. All versions of Windows from Win98 second edition will work. For some versions of Windows the original install disks may be required the first time the Mule is used. Drivers can also be obtained for many UNIX like OSs. Please note the driver is provided by the Operating System Vendor it cannot be supplied by us.

Indicator Lamps

Green Lamp: Ready

The green lamp is lit when The Mule has powered up correctly and is waiting for RS232 data to arrive. The lamp is extinguished during the period it is unable to accept further data while it is transmitting to the KeyWedge or USB cables.

Red Lamp: Overload

The Mule continuously monitors the voltage of the power drawn from the PC. If The Mule is configured to power the RS232 device from the computer the Overload Lamp will light if the computer cannot provide sufficient power (a brief indication when the computer powers up is normal). If this happens you should reconfigure the links inside The Mule and the RS232 device to use an external power source.

Power Source

The Mule is usually powered from current drawn from the computer. Optionally The Mule and/or the connected RS232 device may be powered from an external Power Unit. The power supply should provide 9-12v DC at about 300mA. The central pin is positive. Further information can be found in the RS232 and Links sections.

RS232 Details

Connector & Pinouts

The RS232 connector on the Mule is a 9 pin male 'Dee' connector configured similarly to many PC computers. The pin numbering is shown below.

RS232 Pinout

Device Power Source

Pin 4 on the RS232 connector may optionally be used to supply power for the RS232 device. Pin 4 has been chosen for this purpose to provide compatibility with the normal DTR function usually connected here. Pin 9 can be used for the same purpose. Pins 4 and 9 are linked by default although either can be isolated by cutting the PCB track. Cut at point A to isolate pin 4 or Point B to isolate pin 9. (see pcb diagram) The actual power output depends on the way the links are fitted. Refer to the Link Configuration Table.

Handshake

The Mule requires a RTS/CTS handshake if no loss of data is to be guaranteed under all circumstances. However operation without a handshake is usually possible if your data is sent in bursts of 50 bytes or less with a pause between each burst long enough for the data to be transferred to the computer. Most barcode scanners and similar devices output packets of data in this way. If the Mule’s internal buffer overflows it inserts a 'keyboard overrun' scancode into the data being sent to the computer. Most computers respond to this by sounding a warning beep. If this occurs then characters have probably been lost. An occasional beep sound from the computer is evidence of a RS232 handshaking problem.

RS232 devices using two different RTS/CTS handshake schemes are in common use. One type will transmit whenever the Mule asserts RTS (the CTS line is disregarded). The other will not respond to RTS unless it is asserted only after it asserts CTS. Either scheme may be selected by the DIP Switch. Choose whichever works best. Some devices work equally well with either handshake type selected.

DIP Switches and Links

The DIP Switches and Links are located on the circuit board in the positions indicated in the figure. Use the following procedure to gain access to the circuit board.

Make sure The Mule is unpowered. Remove the 4 screws from the sides of the Mule and lift the cover. After making any changes ensure that no conductive or other foreign objects have fallen inside. Replace the cover before repowering the Mule.
PCB Layout

Dip Switch Configuration Table

The default state for the DIP switches is ALL OFF indicated by the green tinted rows.

After switches are changed it may be necessary to cycle the power before the new configuraton is recognized.

Switches 1 and 2 determine the RS232 Baud Rate
Switch 1: off	Switch 2: off	9600
Switch 1: on	Switch 2: off	1200
Switch 1: off	Switch 2: on	300
Switch 1: on	Switch 2: on	19200 [not guaranteed]
Switch 3 sets the RS232 data format
Switch 3: off		8 data bits, no parity
Switch 3: on		7 data bits, 1 parity bit (odd or even)
Switch 4 sets the RS232 handshake type
Switch 4: off		RTS asserted when ready. CTS ignored
Switch 4: on		RTS asserted only after CTS
Switch 5 sets the RS232 wait loop timeout [Note 1]
Switch 5: off		100mS
Switch 5: on		500mS
Switches 6 and 7 set the keyboard scancode types
Switch 6: off	Switch 7: off	Regular PS2 and PC/AT scancodes
Switch 6: on	Switch 7: off	Old style XT scancodes [Note 2]
Switch 6: off	Switch 7: on	XT values sent as AT codes [Note 3]
Switch 6: on	Switch 7: on	PS2 numeric pad [Note 4]
Switch 8 reverses the keyboard CAPS LOCK state
Switch 8: off		Normal operation
Switch 8: on		Swap case of alphabetic characters
Switches 9 and 10 set the key sending speed. [Note 5]
Switch 9: off	Switch 10: off	100 cps (fastest)
Switch 9: on	Switch 10: off	50 cps
Switch 9: off	Switch 10: on	25 cps
Switch 9: on	Switch 10: on	12.5 cps (slowest)

Note 1: If RS232 data is intermittent, altering the timeout may improve the overall throughput.
Note 2: These scancodes were used by computer keyboards produced during the period 1980-1990. Current computers are very unlikely to use them. Retained in the Mule for special purpose hardware. (Do not confuse XT scancodes with Windows XP)
Note 3: These scancodes were mainly used during the transition from XT to AT computers. They are occasionally used by some hardware or software applications.
Note 4: As regular PS2 except the numeric pad scancodes are transmitted for numbers. This may be needed for some special purpose applications. Not recommended for normal use as the keyboard Num Lock state affects operation.
Note 5: The Mule adjusts its speed to send at the fastest rate possible. Some early computers had a faulty feedback mechanism and the Mule sometimes had to be throttled back to a slower speed. Because this problem now only affects very old computers these switches may be removed or reassigned in the future.

Link Configuration Table

Defaults are indicated by the green tint.

Damage may occur if more than one link is fitted in each group or if links are altered when the Mule is powered on.

Group 1
Link at	Mule is powered from...
1A	... external PSU (via regulator in Mule)
1B	... direct from computer keyboard or USB circuit

Group 2
Link at	Pins 4 and 9 of RS232 Connector are connected to...
2A	... +5v DC. Sourced from external PSU via regulator in the Mule
2B	... +5v DC. Sourced from computer keyboard or USB circuit
2C	... unregulated DC supply direct from external PSU

Group 3
Link is	Permit or Disable scancode mode
Fitted	Scancode mode is possible
Open	Scancode mode is not possible

Advanced Information & Techniques

ASCII Mode

The default operating mode for the Mule is ASCII mode. Characters received at the RS232 port are assumed to be ASCII and the appropriate keystrokes are emulated. Virtually all the printable ASCII characters can be emulated as either a simple keystroke or a shifted keystroke. The number keys emulated are those along the top of the keyboard. The numeric pad numbers are not used as the Mule cannot know the state of the keyboard Num Lock.

The only ASCII control codes to be emulated by simple keystrokes are: CR, BS, TAB and ESC. All other ASCII codes up to and including code 255 are emulated by an ALT key sequence. For example the character represented by ASCII code 123 is emulated by the key sequence ALT down, Pad 0, Pad 1, Pad 2, Pad 3, ALT up. Provided link 3 is made, the special ASCII control code SI is used by the Mule to access Scancode mode. This is described later.

Note that the Mule emulates scancodes not characters. The scancodes are mapped to particular characters within the computer. Some countries (not the USA) require a keyboard driver. If you find some of the characters consistently converted incorrectly you may not have an appropriate keyboard driver loaded or you may be using a version of "The Mule" intended for a different country where some characters are mapped to different keyboard positions. This problem may be overcome by using scancode mode for those characters.

Scancode Mode - Explanation

Many keys like the function and cursor keys have no ASCII counterparts and cannot be directly emulated from ASCII mode. Many application programs require operation of these keys and the Mule includes a special means of emulating them. Using scancode mode every single key on the keyboard is accessible. Every possible simultaneous combination of keys and every possible sequence of simple or combinational keystrokes may be emulated. For example you may wish to emulate the combinational keystroke Shift-Alt-F1. This would be impossible in ASCII mode but with Scancode mode it is simple. Scancode mode with its unique flexibility is unique to the Altek Mule.

To understand and use Scancode mode you need to know how the keyboard encodes keystrokes. When any key is depressed a code number is sent to the computer. This code is called a 'scancode'. Each key has a unique scancode. The scancode bears no relation to the character appearing on the keycap. It is simply a reference to the physical position of the key on the keyboard. When the key is released a different scancode is sent to the computer. By processing these scancodes the computer can work out which key or combination of keys has been pressed. Scancodes may consist of one or more bytes.

Scancode Mode - How to Use

Scancode mode is entered by sending the ASCII control code SI to the Mule (providing link 3 is in place). The Mule remains in scancode mode until it receives the ASCII control character SO. Alternatively scancode mode will be 'Auto-exited' if a character alien to scancode mode is received. (e.g. any ASCII character other than: ABCDEFabcdef0123456789 and SO). In this case scancode mode is cancelled and the alien character will be sent as a normal keystroke.

If you wished to send the SI code as a proper keystroke rather than entering scancode mode this may be done by transmitting the SI character twice. Each scancode byte is sent as a pair of ASCII hexadecimal characters. Capital or lower case characters are treated as being identical. A single hexadecimal character followed by an exit or auto-exit from scancode mode is discarded. If you wish to prevent entry to scancode mode Link 3 should be opened. This may be the best approach if you wish to send a binary file and it is not convenient to duplicate all the SI codes.

Scancode Mode - Examples

To enter scancode mode it is necessary to send the Mule an ASCII control character known as the SHIFT IN character (sometimes simply called the SI character). The SI character is not a normal printable ASCII. It is a special character used to control hardware devices like the Mule.

To exit from scancode mode send either the ASCII control character SHIFT OUT (Sometimes simply called the SO character). You can also exit the scancode mode by sending any character alien to scancode mode. For example it is often simpler to send a ascii NEW LINE at the end of the scancode string.

All remaining scancode data is sent as printable ASCII characters. The characters used for scancode mode are the numbers 0-9 and the letters A-F, The letters can be sent as either upper or lower case- it makes no difference. Any character alien to scancode mode (in other words a character the Mule cannot interpret as a Scancode character) causes the Mule to exit scancode mode.

Computer languages use different syntax in order to send strings. I have provided three examples using BASIC, C and PERL. These are not intended to be complete examples or even the best way to do it. They are meant as an example to illustrate exactly what sort of characters need be sent in scancode mode. In all cases I have assumed a data stream is already opened to the Mule and I have used the codes needed for the Shift Alt F1 example above.

Example using VB (Microsoft Visual Basic)

The SHIFT IN character is represented by CHR(&H0F) because 0F is the hexadecimal value of the character. If you prefer to work in decimal numbers you could use CHR(15) which has exactly the same meaning. Similarly the SHIFT OUT can be represented by either CHR(&H0E) or CHR(14).

To send the codes for ALT SHIFT F1 the following could used...

PRINT CHR(&H0F);"121105F005F011F012";CHR(&H0E);

or...

PRINT CHR(15);"121105F005F011F012";CHR(14);

The above two lines have an identical result.

Note that the SHIFT OUT character may be omitted if the trailing character is alien to Scancode mode, for example a Carriage Return code. In these two simplified examples the trailing semicolon is omitted causing BASIC to auto append a Carriage Return.

PRINT CHR(&H0F);"121105F005F011F012"

or...

PRINT CHR(15);"121105F005F011F012"

Example using C syntax

To send the codes for ALT SHIFT F1 the following 3 lines could be used...

printf("\x0F");

printf("121105FF005f011f012");

printf("\x0E");

or more simply these 2 lines...

printf("\x0F);

printf("121105FF005f011f012\n");

This works because the Mule sees the \n character as alien to scancode mode.

Alternatively the whole can be sent is a single lien by using the substitution features of the printf() function. The first %c is replaced by the character having octal value 17(octal 17 = hex 0F = decimal 15), The second by the character having octal value 16 (octal 16 = hex 0E = decimal 14)

printf(%c121105FF005f011f012%c,\17,\16);

If you prefer hex to octal some versions of C may allow direct use of hex values like this.

printf(%c121105FF005f011f012%c,\xF,\xE);

Example using PERL syntax

To send the codes using PERL the following expressions could be used. (Note that in PERL the dot is used as the concatenation operator)

print chr(0x0F)."121105FF005f011f012".chr(0x0E);

or more simply by using the NEW LINE character to quit scancode mode...

print chr(0x0F)."121105FF005f011f012\n";

The Mule FAQ

A Both Modes function in a similar way. Both send data to the computer just as if it were typed at the keyboard. You may have to use USB on a Laptop which has no external keyboard socket. You may have to use KeyWedge on an old DOS machine with no USB port. You may have to use KeyWedge on a UNIX machine which has no USB driver. USB is sometimes quicker and easier because you do not have to disconnect the existing keyboard. There is no simple answer - use whichever is best for you.

A The Mule is designed to operate with a standard USA layout keyboard. Other countries sometimes have different ASCII values assigned to the keys (The same scancode is used but the computer interprets it differently) If you wish to use The Mule in a different country you may have to use scancode mode for the 'wrong' characters. Alternatively you could disable your own country keyboard driver. Your computer will then default to the USA key layout.

Q While using the Mule the computer sometimes beeps. The data often has characters missing and some characters are incorrect.

A If the RS232 buffer in the Mule overflows an 'overrun' scancode is inserted into the keyboard data stream. This will sound the computer beeper to warn of the error. This is almost always caused by an incorrect RS232 handshake. If your sending device cannot respond to a proper handshake then you will need to insert a delay into the RS232 data after about every 50 bytes allowing the Mule to clear its buffer before sending is restarted.

A In ASCII mode there is no straight forward solution. You could try ASCII code 156 or 163. If you need to send it in Scancode Mode this is the sequence 1226F026F012.

Q I am attempting to send a binary computer file to an application but after being transferred the data contains blocks of garbage.

Scancode mode example: To emulate Shift Alt F1
Keystrokes Required	Scancode
1: Enter scancode mode	&H0F
2: Shift key down	12
3: Alt key down	11
4: F1 key down	05
5: F1 key up	F005
6: Alt key up	F011
7: Shift key up	F012
8: Exit scancode mode	&H0E



Top Home	© Altek Instruments Ltd, 2008