Home/ Questions/Q 321653
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T08:51:56+00:00

We are trying to emulate a POS keyboard in order to integrate an application

  • 0

We are trying to emulate a POS keyboard in order to integrate an application with an existing Point of Sale application.

We ran across this software: Virtual Serial Port Kit

It basically creates a virtual serial port pair so that data send to COM1 can come out of COM4 and vice versa. This allows our application to send data through COM4 to appear to the POS application that it is talking to a keyboard on COM1.

Pretty ingenious, but it seems there is some kind of signalling going on that we are not able to replicate with the .Net System.IO.Ports.SerialPort class…

From what we can tell from serial port monitoring programs, this is how the startup sequence works:

  1. 8 byte Command sent to keyboard
  2. Keyboard beeps
  3. Some kind of signal is sent from the keyboard
  4. Second 8 byte command is sent to keyboard, triggered by the signal
  5. Keyboard replies with device and version information

When using our virtual serial port, we cannot figure out how to replicate the signal sent from the keyboard. We can see all data coming through properly, so we believe the settings on our SerialPort object are correct. Here is a snippet of our SerialPort settings:

_port.BaudRate= 9600;
_port.Parity = Parity.None;
_port.DataBits = 8;
_port.StopBits = StopBits.One;
_port.DtrEnable = true;
_port.RtsEnable = true;

We also noticed from using portmon we see a GET_MODEM_STATUS request that is what the POS application is waiting on before sending the second command.

Any ideas on how to diagnose this? Since we are using .NET this whole situation is a little more low level than we’re used to.

UPDATE: I also want to note that we tried the SDK here: Franson Serial Tools but we could not even get data to go through when using this SDK.

UPDATE: We have thrown out using any kind of virtual serial port. We have gotten a cable to run from the POS PC to another and can see data coming across to emulate the keyboard. Now our problem is that we can’t figure out how to signal that the keyboard is ready to recieve data as the top answer mentions. It appears that the POS application sends the command to beep an waits up to 3 seconds waiting for a signal. So it times out when talking to our application, but not when talking to the real keyboard

How can we do this with the SerialPort class? We already set DtrEnable and RtsEnable to true, do we need to set something else? Or do we have to use a lower level serial port p/invoke to accomplish this?

SOLUTION:

_port.RtsEnabled = false;
Thread.Sleep(1000);
_port.RtsEnabled = true;

This makes the POS application think the keyboard is plugged in, which makes sense. I’ll mark the #1 answer as the answer since it greatly helped us find the solution.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    EDITED to give more perspective from the point of view of simulating the keyboard.

    As it happens I have written low-level drivers for the 92R keyboard in the distant past.

    You really need the documentation for the proprietary protocol to do this properly – for example commands sent to the keyboard contain a sequence number and a checksum. I’d recommend contacting Fujitsu and attempting to get hold of this documentation.

    From what you’ve described:

    • The first 8-byte command you sent was probably a reset command (as it caused the keyboard to beep). The keyboard sends a response to acknowledge the command, then resets itself.

    • After sending a reset command, the POS app needs to wait for the keyboard to reset (I think about 3000ms) before sending other commands.

    • It looks like the second send is a command to request the firmware version.

    • The POS app will also need to subsequently send a command to enable “autoinput” before the keyboard will actually send keystrokes.

    • There are also commands available to request the keylock position, sound the tone generator, enable/disable the MSR, and write to the optional embedded 2-line display. So your simulator will need to be capable of reproducing the responses to these commands.

    • Once the POS app has enabled “autoinput” the keyboard will send unsolicited messages with the keystrokes being pressed (or keylock position changes, or MSR input). IIRC these messages also have a sequence number and checksum that you will need to reproduce in your simulator.

    The only signalling I know of is that the keyboard raises CTS when it is ready to receive data. If you connect two ports on a PC, you need a special null modem cable (see below) so that when your simulator raises RTS on COM4 it will be seen as CTS on the other port.

    The COM ports on a TeamPOS motherboard provide power to the keyboard. You probably don’t want to connect these pins to your COM4 port, so I would suggest using a null modem cable that connects only the following pins:

    2 (Tx data) – 3 (Rx data)

    3 (Rx data) – 2 (Tx data)

    7 (RTS) – 8 (CTS)

    8 (CTS) – 7 (RTS)

    • 0