This is now explained using navigation software, which shall receive GPS data on a Wireless LAN connection. But the example provides information to judge, if a different purpose App may also use the NetCom 123 WLAN.

Many GPS receivers on board of boats or yachts use a serial port to output the position data. This port may use a RS232, or a RS422/485 interface. The NetCom 123 WLAN will serially connect to that interface, there is no problem in matching the configuration to receive the data. In many situations the data will arrive with 4800 bps, 8 data bits, one stop bit and no parity. But other options are available as well.
The NetCom 123 WLAN can forward the received data either to Ethernet or to WLAN as of IEEE 802.11b/g. The latter is typically required.

The data shall be received on the smartphone, there is no concept of serial ports in such devices. Further there is no driver to install a virtual serial port on the operating systems. So the data is received directly via socket functions. It depends on the certain application how this must be configured.
Many Apps use TCP/IP to get the data. They have to establish a TCP connection to the NetCom, and read the GPS data via that connection. This is possible with NetCom. The serial port of the NetCom is configured for "TCP Raw Server" Mode. This way it can accept one or more connections at the same time, providing the GPS data to TCP/IP. Since no Ethernet connection exists, received serial data is forwarded on the WLAN. Even if the App does not allow to configure the TCP port to operate on, the NetCom may use any TCP port to accept the connection.

Some Apps may use UDP data transmission instead of TCP connections. This is not a problem either. The maximum data packet size on a WLAN is roughly 1400 bytes, while typical GPS data sets only use one line of text.
Using UDP there is no connection for a stream of data. Instead received serial data shall be bundled to a package, and sent in one UDP data frame. The NetCom 123 WLAN allows several methods to define when a package is ready. With GPS data in NMEA format the serial data is typically terminated with a CR/LF sequence. NetCom can use this as a trigger to send the received data.

The UDP data frame may be sent to one predefined target, or sent via broadcast to all interested devices on the WLAN. So also in this configuration multiple stations may use the GPS positional data.

The ground connection is is not written explicitly in the specifications. Instead a so called Common Voltage Range (CVR) is defined. The specification -7V to +12V for the CVR allows to design and manufacture less complex and hence low-cost circuits. Without somehow connecting the logic Ground an installation can not ensure this requirement is met on all stations. A device without such an option is possibly not conforming to RS485 specifications.

Transmission happens in a balanced fashion. Two wires are used to carry one logic signal. A positive differential voltage represents a logic 1, a negative differential voltage represents a logic 0.
The transmitting device produces voltages within the CVR, typical +5V for high and 0V for low level. These voltages of course are generated with respect to the logic ground of the transmitter. Any measurement must check the voltage between the signal line and logic Ground. When the signals connect to a device, it must evaluate the voltages with respect to the logic Ground of the receiver. If both Ground levels differ by more than +7V, on the receiver side one or both voltages may be not within the CVR. If the levels are not within the defined CVR, the logic value may not be understood, causing errors on receiving.

Basically this is also discussed on Wikipedia, and for example in application notes from manufacturers like Maxim and Analog Devices. The connection of ground may happen implicit, because the logic ground of all devices is connected to some global protective ground level. If this is nearly the same on all devices, an extra wire is not required.
If the ground levels are different, without an explicit connection all equalising currents run on the data lines, hence pass the logic circuits for transmit and receive. This can damage the devices, and often does over time.

When the serial interface is galvanically isolated, sometimes there is no contact for the isolated logic ground. In such networks it may be possible to make a simulated connection. On the receiver side one resistor connects the positive signal line with ground, and another resistor connects the negative signal line with ground. As a net effect now the logic ground of the receiver is in the middle of the positive an negative voltages. So both data lines are in the CVR with respect to the receiver. It is difficult to give reasonable values for these resistors. If there are only two devices connected, resistors in the range of 2k Ohm should do the job. But in any installations this requires explicit calculations.

For the first way just follow the instructions in User Manual (see Section "Buildroot")

For the second way checkout OnRISC_Software as described in User Manual (see Section "Programming Examples Repository"), install toolchain and execute following steps:

1.  cd scripts
2.  ./vskernel.sh 3.0.4
3. export ARCH=arm
4. cd linux-3.0.4/
5. make
   

However the latest driver version for Windows 7 (also operates on XP and Vista) provides a chance to configure a suitable workaround. Please download the latest manual to see how this can be used.

Very frequently Windows programs refuse to operate with COM10 or higher. What is the reason?

1. The program is an old 16-bit application. In this case COM9 is the highest available interface.
   It is very likely this is not the cause today, but you never know.
2. The program offers a list of ports, only containing COM1 through COM9.
   Please contact the programmer. This is a limit imposed by his application.
3. The program does not open the port in the correct way, please contact the programmer.
   Probably a name like "COM11:" is used to select the port. This is not allowed. The correct name is "\\.\COM11", i.e. with <Backslash><Backslash><Dot><Backslash> as prefix; further the colon at the end is not allowed. This method also operates with COM1 through COM9.

Programmers shall check the MSDN article about this problem.