Eye in the Sky (www.eyeintheskycams.com) wanted to develop a simple and effective method of collecting receipt/journal printer information from a Ruby POS system, print it, and simultaneously send it to an NVR (Network Video Recorder) for text overlay.
The solution required taking the serial port printer outputs from a Ruby POS system to a dumb line splitter, which passed all the serial lines directly to the printer, and also passed the ground (GND) and transmit (Tx) lines to the LAVA Ether-Serial Link.
The printer was able to print just as before, and the receipt/journal data was also passed to the Ether-Serial Link, which passed it onto the NVR (in this case, a Milestone Systems NVR) over a network connection.
The LAVA Ether-Serial Link is set to operate in Windows Driver mode, and is a fully-implemented remote serial port, accessible from a Windows PC (in this case, a Windows 7 system). In this mode, data arriving on the serial port of the Ether-Serial Link is passed on to the Milestone system for overlay.
The primary challenge in creating this setup was simply making the correct pin connections from the RJ-45 serial connectors of the Ruby POS to the serial port on the LAVA Ether-Serial Link, as the pin designations for the port outputs from the Ruby POS were not readily available.
Once this was done — a matter of selecting the correct splitter lines — the system was ready for prime time.
Computer Automated Measurement and Control (CAMAC) is a long-established standard for data acquisition hardware, often used in the nuclear and particle physics fields. The good news about CAMAC systems (when enclosed in a chassis, they are called CAMAC “crates”) is that they seemingly last forever. The bad news is that they are very expensive, often customized, hard to replace, and interfaced to increasingly obsolete computers.
In the case of the DSPT 6001 / 6002 CAMAC Controllers, interfacing used a controller that seated on the ISA bus slot of a PC. When upgrading the computer made it impossible to continue to use that controller because motherboards with ISA buses were getting hard to find, it became necessary to develop a substitute for the PC004 interface card used in that system. In response to this need Computer Methods developed its PP004 High Speed Interface Controller for the DSPT 6001/6002 CAMAC Controller (http://www.computer-methods.com/products/pp004.html).
This interface in turn needs to interface to a PC on a parallel port connection, specifically an EPP mode parallel port. It so happens that LAVA makes a range of such cards: our Parallel-PCI, Parallel-PCI/LP. Parallel-PCIe, and Parallel-PCIe/LP among them. CAMAC controller interface connected, CAMAC crate up and running, problem solved, money saved!
The interest in an RS-232 serial port for the Raspberry Pi has LAVA considering making a simple GPIO-to-RS-232 DB-9 serial port board. This little item would plug onto the Raspberry Pi’s GPIO pin header, take the Raspi’s UART signals up to RS-232 levels, and present them on a conventional DB-9 (aka DE-9) connector. It would save a lot of people the trouble of individually sourcing components and parts, futzing around with pinouts, line drivers, and soldering, and ending up with a messy bread-boarded product at the end of it all.
So the question for all you out there thinking about using the Raspberry Pi to connect to an RS-232 peripheral is this: if you could have a tidy single-board serial port that would plug onto the GPIO of the Raspberry Pi, would you want it to plug directly onto the GPIO pins or would you want it led off the Raspberry Pi’s board with a ribbon cable? Reply to this post to let me know!
The range of serial cabling includes crossover cables, sometimes called null modem cables. This post fills out the information on crossover cables, as at times confusion about them can cause systems not to work.
When two pieces of Data Terminal Equipment (terminals, or DTEs) need to be connected to each other, or two pieces of Data Circuit-terminating Equipment (modems, or DCEs) need to be connected to each other, a serial crossover or null modem cable is used. These cables align incoming signals with the corresponding outgoing signals on the other side of the connection. At a minimum, the Transmit Data (TD) line of a serial link needs to be paired with the corresponding Receive Data (RD) line on the other device.
Why would one need such a cable?
- It can be a way of connecting two PCs without networking interfaces such as Ethernet, making direct file transfers between systems possible.
- It can be a method for technically-minded users to debug systems with minimal software overhead (that is, as little code and as few drivers as possible).
- It can provide access to a serial console when problems make the local monitor and keyboard of a computer unavailable, or when a computer is being remotely operated or operated “headless” (that is, without a monitor, keyboard and mouse).
Not all null modem cables are the same however, and some cables will not work in specific applications. The three standard types of null modem cables are described here, for DB-9 to DB-9 and DB-25 to DB-25 connections, making six variations. I haven’t shown the three DB-9 to DB-25 versions, which in any case are just the DB-9 side at one end and the DB-25 side at the other (see below, “9-Pin to 25-Pin Connection”). The bottom line is: there are nine variants of RS-232 crossover cables.
The first, “No Handshaking,” swaps the complementary data transmit and receive lines. This is the minimum needed for a crossover connection. This cable will work as a crossover cable when control lines are not needed for the link. It cannot be used when hardware handshaking is required. It can be used when hardware flow control has been turned off on the serial ports involved, but doing so will simply bypass the control lines regardless of their state.
The second, “Full Handshaking,” swaps the data lines as well as the control lines needed for handshaking/flow control. The pairs of lines needed for handshaking are DTR/DSR and RTS/CTS This cable crosses these pairs between the two ends of the cable. This cable will work as a crossover cable when control lines are not needed for the link, or when hardware handshaking is required. It can be used when hardware flow control has been turned off on the serial ports involved, but doing so will simply bypass the control lines regardless of their state.
The third, “Loopback Handshaking,” swaps the data transmit and receive lines, but the DTR/DSR and RTS/CTS pairs are not swapped with their complements. Instead, the DTR line on one side of the link is looped back to the DSR line on the same side of the link, and the RTS line on one side of the link is looped back to the CTS on the same side of the link. This cable will work as a crossover cable when control lines are not needed for the link. It can be used regardless of the on/off state of hardware flow control on the serial ports involved, but will “fool” the link into accepting that hardware handshaking has been completed. It cannot be used when true hardware handshaking is required.
If one side of a serial crossover cable uses a 9-pin connector and the other side uses a 25-pin connector, the lines map between these two connectors as follows:
Aside: Payment Processing Terminals and Serial Crossover (Null Modem) Cables
LAVA’s experience connecting modem-based payment terminals with serial device servers is relevant to this discussion of crossover cables. This scenario uses a null modem cable between the serial device server and the payment terminal. While some payment terminals require only RX and TX lines, LAVA recommends using a “Full Handshaking” cable with the line signaling unless you are certain that control signals are not used. LAVA does NOT recommend a cable that uses “Loopback Handshaking”. Care should be taken when purchasing null modem cables as not all packages indicate clearly what type of null modem cable is being sold.