LAVA’s wireless serial device servers (WiFi ESLs) can operate in Ad Hoc or Infrastructure modes. These two modes are fundamentally different, each with their own advantages and disadvantages.

Ad Hoc Networks

The Latin expression “ad hoc” translates into English as “for this,” a translation that loosely suggests what ad hoc networks are:  networks set up for a single simple purpose. In their simplest form, Ad Hoc networks are peer-to-peer connections between two wireless devices capable of operating in Ad Hoc mode. The two devices have a direct wireless connection to each other, with no intervening wireless devices (or “infrastructure”) such as wireless access points or routers.

Additionally, multiple Ad Hoc devices sharing the same SSID (“Service Set Identifier”) can be on the same Ad Hoc network, extending the concept from a one-to-one network to a multi-node system of connections.

Ad Hoc networks can be set up simply and easily with no need for a pre-existing wireless network, or for additional network hardware beyond the nodes in the network itself. Ad Hoc networks offer low cost networking as well. Disadvantages of Ad Hoc networks include generally shorter working ranges than those of more highly-powered Infrastructure networks, decreasing performance as the number of devices in an Ad Hoc network increases, and no bridge to wired networks. Another disadvantage of conventional Ad Hoc networks is that they do not implement the strongest levels of security now available.

Infrastructure Networks

Infrastructure networks are collections of wireless devices attached to an intermediate piece of network infrastructure, typically an access point, router, or PC running access point software. A WiFi ESL in Infrastructure mode becomes a wireless part of a larger Local Area Network (LAN).

Advantages of Infrastructure networks include greater power and distance than most Ad Hoc networks, greater scalability and stability, and better security. These advantages come at the cost of greater expense to set up, and of reduced flexibility.

Ad Hoc and Infrastructure networks

What does this mean for wireless serial device servers? For one thing, it means that a WiFi ESL in Ad Hoc mode is an extremely simple and effective means of adding a serial port to a laptop, with no need for USB-to-serial, hard wired Ethernet-to-serial connection, or a wireless router. For another, in Infrastructure mode, WiFi ESLs offer all the advantages of wired networked serial ports: simplicity, reliability, and configurability.

WiFi ESL 1-232-DB9, WiFi ESL 1-232-RJ45

WiFi ESL 2-232-DB9, WiFi ESL 2-232-RJ45

These new wireless serial device servers support 802.11a or 802.11b+g modes, with choices of WEP 64, WEP 128, WPA (TKIP), or WPA2 (AES) encryption. They retain all the functionality of the standard LAVA Ether-Serial Links, with DHCP/manual IP address configuration, intuitive installation and configuration, full-throughput non-blocking serial ports at 115.2 kbps, and upgradeable firmware.

The serial ports are configurable in a variety of modes: Windows-implemented ports (driver mode), raw TCP client connections, raw TCP server connections, raw data connections (client + server), Ethernet modems (accepting Hayes-compatible command strings), or RFC 2217 controlled ports (serial control over Telnet).

The wireless Ether-Serial Links include full Windows support from Windows XP through Windows 7, as well as Linux support. In raw modes they are operating system independent.

They include a power supply, the LAVA Ether-Link Manager application (Windows), and of course, the LAVA Lifetime Warranty.

Shergroup has developed a solution that provides the best of both worlds for this user: on that person’s system they have installed another DOS emulator that talks to a LAVA single serial port card (the LAVA SSerial-PCI). That card is in turn connected to a LAVA Ether-Serial Link serial device server, which in turn is connected to the UNIX server.

Connecting DOS emulators

In effect, a serial tunnel runs between the two emulators, making it possible for the user on the Windows system to connect to the DOS emulator on the UNIX system.

What makes us confident enough to offer this warranty? It’s simple: we engineer and manufacture LAVA boards ourselves, so we know our products inside out. But more than that, we test every LAVA board individually to ensure that it is working, before it ships.

That final statement means a lot, and is worth a close look. It is not actually enough to know a  design works. The fact is that “stuff” happens, and not every component is identical. The overwhelming majority of finished cards coming out of the solder machine will work, but there will be some that won’t and at the end of it all the only way to know that a given card works is to test it.

It’s almost too obvious to say such a thing, but the reality is that many manufacturers test only a sample of products in a production lot, on the assumption that a given failure rate is acceptable, or maybe thinking that failures won’t happen. That belief might be good enough for them, but is it good enough for you? What will it cost you to visit a customer site to troubleshoot a hardware failure?

Life isn’t perfect, but LAVA tries to come close. And remember, we also have unlimited live free technical support and a no-hassle return policy.

SSerial-PCI to card swipe

As a result, Adamas Technikos’ reputation for bulletproof computer solutions has meant that word of mouth is enough to fill their customer pipeline.

Parallel-PCI to dot matrix printer

Current POS applications of LAVA cards by Adamas Technikos include the LAVA Parallel-PCI for dot matrix forms printers, and the LAVA SSerial-PCI for card swipes at a bank that prefers the security of serial over USB connectivity for payment processing. On the Dell and IBM motherboards that Adamas Technikos deploys, on-board serial and parallel ports are lacking.

Kevin Turner of Adamas Technikos emphasizes that getting it right the first time is key to their customers’ satisfaction, whether the industry is POS, healthcare, transportation, or manufacturing, all areas they serve.

Predictive dialers are a highly useful telemarketing tool, as they can greatly increase the amount of time that telemarketing agents spend on the phone in actual contact with those who have been called, improving the utilization of agents in actual calls from 40 minutes per hour to up to 57 minutes per hour. Agents do not lose time in dialing and redialing, managing phone lists, and waiting for someone to pick up a call.

MarkeTel Systems predictive dialers

At the telephony level, predictive dialers need at some point to connect to either a Voice over IP (VoIP), digital, or Plain Old Telephone System (POTS) telephony system. In the case of POTS dialers, a modem has typically been the dialer, and modem interfaces are RS-232 serial. In modem pools with numerous phone lines, banks of modems are integrated with computers using multi-port serial interfaces.

One of LAVA’s customers, MarkeTel Systems (http://www.marketelsystems.com) is a leader in CTI predictive dialers, and uses LAVA serial cards to complement their systems.

Numerous other predictive dialers also interface on RS-232:

http://www.way2call.com/scripts/openExtra.asp?extra=41: dialer with host interface RS-232

http://www.freedownloadscenter.com/Business/Misc__Phone_Tools/Phone_Dial_by_PC.html: software that uses serial RS-232 for modems

http://www.kolkersystems.com/: Gemini-2000 hardware predictive dialer

http://www.vikingelectronics.com/products/view_product.php?pid=193: PB-100 predictive dialer hardware and software

http://filedir.com/communications/telephony/phone-dial-by-pc-935381.html: Phone Dial by PC software

Power over Ethernet (PoE) white paper

The PoE device receiving power does not in fact need to be an Ethernet device at all, making it possible to use PoE as a generalized, efficient, and managed low to medium power distribution system.

LAVA has introduced four PoE serial device servers as well, so now is a good time to become familiar with this powerful new technology.

A recent call to our support lines exemplifies the problem. A customer called up with a question: why would the LAVA Ether-Serial Link 4-232-RJ45 that he wanted to connect to a Valcom 2924 intercom system connect with a null modem cable, but not with a straight-through cable? On the face of it, the question seems nonsensical: evidently, if one cable works, then the other should not. Where was the problem? The LAVA Ether-Serial Link is configured as a Data Terminal Equipment (DTE) device, and since a null modem cable worked, the Valcom 2924 was also a DTE, so the connection was DTE-to-DTE. (If a straight-through cable had worked, then the intercom system would be a piece of Data Circuit-terminating Equipment (DCE), and the connection would be DTE-to-DCE).

Setting aside the fact that the term “null modem cable” can mean a number of things (see our blog post on null modem or crossover cables), you would think that ANY null modem cable, should it work, would not be replaceable with a straight-through cable. Common sense, right? The only problem was that the customer said the setup HAD worked with BOTH types of cables, when he was using a now-discontinued serial device server that was not a product of LAVA’s.

A bit of digging into this revealed that the intercom system in question had a DB-9 RS-232 printer port that could also be a source of Station Message Detail Recording (SMDR) information. Simple enough, but if the the intercom had a DB-9 serial port, why was the customer using a LAVA Ether-Serial Link with RJ-45 serial connectors? Why not just DB-9 to DB-9 and be done with it?

Valcom 2924

The answer lay with the discontinued serial device server the customer was wanting to replace — it was an Equinox ESP8. This serial device server has eight RS-232 interface ports, with RJ-45 connectors.

Equinox ESP8

Now here is where it gets a bit funky. A look at the documentation for this device server revealed that Equinox was calling it a “Multi-Interface Serial Hub”, and available with it were a bunch of modular adapters and modular cables:

Modular DTE and DCE connectors

As you can see, the modular adapters make it possible to operate the ESP8 as either a DTE or DCE interface. There is a ten-wire “reversing cable” here — a serial cable to pair with the serial device server to be either a DCE or DTE device, as needed. This makes the device more versatile, in the sense that the cable is able to be either a straight-through or a null modem, WHEN USED WITH THIS DEVICE AND ITS ADAPTERS FROM EQUINOX. But it does nothing special for the LAVA Ether-Serial Link, which uses the tenth wire in an RS-232 RJ-45 connection for a totally different purpose: that is, as a way to supply power to serial peripherals over the serial connection.

Reversing Cable

See what I mean about the complications of RS-232 on an RJ-45 connector? And this is just the tip of the iceberg. Take a look at the multiplicity of arrangements of serial port lines on RJ-45 connectors documented on the following pages:

http://www.conserver.com/consoles/Signals/signals.html

http://www.opengear.com/alternate.html

So the bottom line really is: when setting up serial interfaces with RJ-45 connections, make no assumptions about what wire is running where or what cable will work, because odds are you will be wrong! Fully documented pinouts are essential for quick, error-free setups.

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:

POS to NVR integration – General design

“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.

POS to NVR integration – Initial grounding setup

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.

POS to NVR integration – Testing for correct TX/RX line

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.

POS to NVR integration – Stripped wires in POS cable

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:

POS to NVR integration – Proposed breakout box

Let us know what you think.