We’ve had a number of POS system installers wanting to take output from a POS system to a serial printer, and also send it to a DVR (Digital Video Recorder) or NVR (Network Video Recorder) over an IP connection. Integrating POS and video surveillance is a growing business, and some people are finding it a key to success with their customers. Business Solutions Magazine (June 2012) had a cover story on just this topic, pointing out how Datatek was making this type of installation a part of their business. Business Solutions covers this topic in some depth here.
In a previous blog post, we diagrammed this sort of setup and spoke in general terms about how simple this was to do — merely a matter of taking the serial TX line and the GND line from the cable running between printer and POS, tapping into them, and sending that input to the LAVA Ether-Serial Link (ESL). The ESL would send that along to the video recorder. Since the voltages involved for the ESL’s serial port (+10/-10 VDC) are enough, and the data rates for the POS printers are low (usually operating at 19200bps or 9600bps), there are no major electrical issues given normal cable lengths. The layout is like this:
“Merely a matter of taking the serial TX line and the GND line from the cable running between printer and POS, tapping into them, and sending that input to the LAVA Ether-Serial Link (ESL)” sounds damn easy. But it’s not. There are two big obstacles in the way: first, the serial lines are not clearly identified on most POS systems, and are not standard from system to system in any case; and second, getting the ground connection wrong could introduce a ground loop that could fry the Ether-Serial Link, the POS station, the printer, or any combination of these, depending on how lucky you are.
POS vendors are not particularly helpful on this, as you’ll find when you try to pry from them the pinouts of the devices they sell. Rather than coming back with the information, they will try to sell you a pricey cable, but that cable will still not split the signals in the way you need. It also doesn’t help that when the serial connectors are RJ45, the serial line designations are even more sketchy.
So here’s what you need to do:
1) Set up grounding between the ESL and the POS/printer. This is an essential first step to prevent damaging your hardware and must be left in place through this process. Since the chassis of both the printer and the POS system will be grounded, this is a good place to start. It also helps that the pinouts on the ESL are marked, right on the enclosure. You can start by taking the ground from the ESL’s serial port to the chassis of either or both of the POS system and the printer. If the POS system has a DB9 connector, the shell of that will be grounded too.
2) Set up a terminal application on the ESL to be able to monitor the serial port activity that you will be generating in Step 5.
3) Attach a wire to the RX connector in the ESL’s serial port. Again, this line is identified on the enclosure of the ESL.
4) Now you need to EXPOSE (not cut) the wires in the POS cable running from the POS to the printer. You will be tapping onto these wires one at a time to look for signal activity between the POS and the printer.
5) One by one test the connection between a wire in the POS cable and the RX signal line on the ESL by watching the terminal application you have running as you send data to the printer. The TX line coming from the POS will send data to the ESL, and that data will appear on the terminal application. This is the data line that you want.
6) At this point you want to find the GND line among those running between the POS station and the printer. Having eliminated one of the lines as the POS TX line, attach a voltmeter to the remaining lines one at a time, looking for the line with zero resistance. This is the second line that you will tap onto. Power off the devices in the system and complete the attachments, that is tap from the POS TX (printer RX) line to the ESL RX line, and from the POS/Printer GND line to the ESL GND line. You’re done.
NOTE: LAVA is considering creating a simple interface board to make this process a lot less painful. It will be essentially a breakout board that will let you easiliy plug between the POS station, printer, and ESL, and configure the correct GND and TX-RX connections without cutting wires and patching connections. It will look something like this:
Let us know what you think.
New Microsoft-certified drivers are now available for online download for the range of LAVA PCIe cards:
These drivers are certified for Windows 7 32-bit and 64-bit.
GPSes are becoming commonplace, not just as the standalone devices we have in our cars, but perhaps even more often as a capability built into our smartphones. In the majority of cases, the data that those GPSes generate is used by and stored in the device itself, but occasionally people want to access that data in other ways. A typical instance is when someone wants to download waypoints, routes, or tracks for use in computer-based mapping software or to transfer data to another device. In such cases the appropriate GPS interface sometimes is RS-232 serial. For example, a number of Garmin GPSes have serial output:
Garmin GPS 35 TracPak Series (GPS 35 LVC, GPS 35 LVS, GPS 35 HVS, GPS 35 PC)
Additionally, at times a more specialized GPS is being used, and these GPSes often have RS-232 serial as their interfaces. Such GPSes may have greater sensitivity or a higher polling rate than usual. One example listed below is for rocketry, where taking telemetry readings every five seconds does not get the job done. Another, the syncboxRED, uses GPS signals for highly accurate timing.
Hackers have fun with data output from GPSes as well, and some of the links below reference such applications. LAVA PCI serial cards or USB-Serial Links are complementary to many of these GPS applications.
Modify any USB GPS to XDA Serial RS232, afternoon project:
Hacking Garmin etrex GPS: making your own cable to run from the proprietary connector to standard RS-232:
Another DIY cable for Garmin:
A connector source for those who want to make their own Garmin compatible cable:
CatTrack™ GPS to RS232 Adapter – Product information
Using the Holux GM-210 GPS for either RS-232 or TTL:
Another integration of the Holux GM-210 GPS:
High sensitivity GPS:
Rocketry application — high sample rate GPS:
Vehicles manufactured after 1996 have a capability that few drivers realize exists: your vehicle has an interface to its computer that can provide a panoply of information about your vehicle’s operation and status, second by second. This interface, the On-Board Diagnostics (OBD) port, gives information on speed, acceleration, fuel use, temperatures (of oil, coolant, air intake, etc,), engine load, rpms, electrical voltages, fault conditions, and much more. If you’ve ever had your “Check Engine” light go on, and not known why, this interface will tell you precisely why, as well as making it possible to reset the indicator. Those skilled in tuning their cars’ engines use OBDII as a matter of course.
The current incarnation of the standard, OBDII, works with almost all cars on the market in one form or another. The OBDII output coming from the car’s electronics feeds into a computer running software to interpret and display this data, or to a piece of dedicated automotive troubleshooting hardware.
When connecting OBDII outupts to a computer, a number of OBDII connectors will do the job: OBDII-to-RS-232 serial, OBDII-to USB, OBDII-to-WiFI, and OBDII-to_Bluetooth, among others. For ODBII devices addressing outputs to RS-232 serial , LAVA has a number of RS-232 serial interface ports that will do the job. For desktop PCs, any one of a number of our PCI and PCIe serial port cards are great. If you have a laptop, our USB-to-Serial Link will work very well.
A good general introduction to OBDII:
The OBDII specification is not publicly available, but a lot of information is at:
A variety of OBDII interface methodologies:
Some typical OBDII-to-RS232 interfaces:
For the hobbyist interested in building their own OBDII-to-RS-232 interface:
A good site for determining OBDII compatibility for “transitional” 1995/1996 vehicles:
For those interested in interfacing the ELM327 to RS232 in Linux:
Much of the OBDII interfacing uses the ELM327 interpreter chip. This chip provides an RS-232 (serial) interface to ODBII data. The gamut of ELM327 chips and their specifications are here:
For those interested in looking deeper in to OBDII, or interested in making their own interface hardware: