|The Mule-Engineering Details|
|Home Barcode Mill Barcode Fonts How to order Email us|
This information is provided to help engineers and systems integrators understand the Mule and its functionality in detail. From the engineering perspective the new Mule is 100% backward compatible with the original model. If you need information not provided here please email.
The Upgraded Mule with USB interface is now shipping.
This is a summary of the changes made for the new Mule...
9 Way Female Dee connector with screw jacks. Pinout designed to be similar to IBM PC. The design philosophy was RS232 devices designed for a PC should be plug compatible with the Mule. We added the ability to provide Power from the connector as a convienient way to power the RS232 device.
A MAX232 type device is used to handle the RS232 signal levels on pins 2, 3, 7, 8. The Data output line is connected and held at the RS232 quiescent level but no signals are transmitted from pin 3.
Pins 4 and 9 can be used to provide power for an external device. The use of pin 4 is compatible with the DTR signal usually associated with this pin. Pin 9 is used by a PC for the RI signal - this signal is rarely provided by the type of device connected to the Mule.
Pins 4 and 9 are interconnected by trace on the PCB with two 'weak points'. Either or both pins may be isolated by cutting the trace at these points. (It is very unlikely you will need do this)
Pins 4 and 9 are connected to a jumper header and can be linked to any of these voltage sources (Default is the first listed)...
The Mule has a small buffer but should usually be operated with a CTS/RTS handshake to guarantee no loss of data. The default handshake scheme suits most devices. The Mule asserts its RTS line when it can receive data and negates when it cannot. This is usually connected to the CTS line of the sending device.
An alternative handshake scheme can be selected by DIP switch inside the Mule. In this scheme the Mule will only assert its RTS line AFTER it receives a CTS assertion from the sending device. This scheme is rarely used. We added it after a request from a particular scanner manufaturer.
It is possible to use the Mule sucessfully without a handshake but only if the data arrives in short packets with specific interpacket and intercharacter timings. In general it is unwise to operate without a handshake unless you fully understand the characteristics of the sending device and your system can tolerate the occasional error.
This is the data flow timing needed to operate sucessfully without a handshake....
... it can be seen that this data flow is typical of data sent from a device like a barcode scanner. Indeed the Mule was originally designed with these devices in mind. Other devices like weighing scales may also provide similar data formatting. If your system can tolerate a small risk of data loss it may be operated without a handshake. However to guarantee no loss of data a hardware handshake must be used. Use without a handshake with unpredictable sending systems (For example: hand keyed data) will inevitably lead to data loss.
The default RS232 data format is 9600 baud 8 data bits, no parity bit, one or more stop bits. Other selectable baud rates are 300, 1200 and 19200. Operation at 19200 baud cannot be guaranteed with all sending devices if their baud timing is at the margin of the permitted RS232 specification. For most applications 9600 baud is plenty fast enough because the ultimate top speed is limited by the computer keyboard interface.
RS232 7 bit data with a parity bit can be selected by dip switch. The Mule accepts any parity bit (odd even mark space).
The KeyWedge cable is split into two at the computer end. Each is terminated by a PS2 style mini DIN connector- one Male and one Female. Connect the computer keyboard to the female connector. The Male connector fits the computer keyboard socket. No software drivers are needed the Mule emulates the keyboard in hardware. When the Mule is fitted normal keyboard operation is not affected. The Keyboard Wedge system can be used with ANY operating system.
The Mule is provided with an alternative USB interface. To the User the USB interface operates exactly as the KeyWedge interface. In other words data coming from the Mule is converted into keystrokes which appear on the computer screen just as if they had been keyed. The USB interface requires a 'Human Interface Device' (HID) driver. Drivers are available for many up to date operating stystems but may not be available for earlier systems like MSDOS. Device drivers are not supplied with the Mule they are the responsibility of the Operating System provider. Altek instruments believe suitable USB drivers are available for the following Systems...
Each has advantages and disadvantages. In overview the KeyWedge System is suitable for any operating system but some computers (laptops and portables) may not have a socket for an external keyboard. Furthermore some portable computers disable the internal keyboard when the external keyboard is in use. The USB is more convienient when frequent connection and disconnection is required. It is the only solution if an external keyboard connector is not provided or cannot be used. USB requires an OS with an appropriate driver and it occupies a valuable I/O port.
The advantages and disadvantages of each system are tabulated below.
|Use with any operating system||Yes||Only if device driver is|
|Occupies I/O resource||No||Yes|
|Frequent connection and disconnection||Not Good||Easy|
|Sends data as if it had been keyed||Yes||Yes|
|Use with Laptops and portables||Possible if suitable external Keyboard connector is available||If a suitable USB|
connector is available
|Use with Apple Mac||No||Yes if a USB keyboard port is available|
The PC keyboard uses a system of scancodes. Each time a key is pressed a scancode is transmitted. Most keys also send scancodes when released. If you type the single letter 'a' (Lower case A) at least 3 scancodes are transmitted (More if the key is held down). Things get even more complicated if you type A (Capital A) because the shift key is also involved. Here is an analysis of the scancodes transmitted for 'Capital A'...
... for this 'Capital A' character 6 scancode bytes are sent. All this is hidden from the user, the computer handles all the interpretation of scancodes and simply prints the 'A' on the screen as expected.
Most engineers are used to working with ASCII codes. But to inject ASCII characters into the keyboard circuit you first need to translate to scancodes. To write a computer program to do this is not a trivial task because the algorithm depends on what went before. For example if two capital letters follow each other it is not necessary to emulate 'shift key up' and 'shift key down' between the characters.
The Mule has ASCII-to-scancode conversion built in. You just send ASCII characters and the Mule automatically converts them to the appropriate stream of scancodes. Where it is possible ASCII controls are converted too. For example ASCII code 9 is converted to the 'Tab' key and ASCII code 27 to the 'Esc' key.
Some keys have no ASCII equivalent for example the Function Keys, Cursor Movement keys etc. These keys can be emulated by shifting the Mule into 'Scancode mode'. Once in Scancode Mode every single key can be emulated by sending its raw scancode value. It is even possible to emulate keys not present on a particular keyboard- for example the 'Flying Windows' key not present on older keyboards, or the 'Power', 'Sleep' and 'Wakeup' keys now appearing on some computers.
Many applications only need simple ASCII character emulation. To prevent the Mule from being used in scancode mode remove the jumper link inside the Mule. The default factory setting is scancode mode enabled (Link Fitted).
|Top Home||© Lee Allen, 2017|