OPN2002

Revision as of 24 August 2010 19:16 by Administrator (Comments | Contribs) | (→FAQ) m

Concepts and Vernacular

  • Fixed PIN: a PIN code that is preset in the OPN2002. Typically the last 4 characters of the OPN2002's Bluetooth name.
  • Dynamic PIN: a PIN code that is determined at pair time by the Bluetooth host.
  • HID: Human Interface Device. In the case of the OPN2002, it's recognized as a Bluetooth HID keyboard, meaning that each character of a scanned barcode is transmitted to the host as a keyboard press. HID devices cannot be used as a master at pair time, but after pairing with a Bluetooth host, can switch roles and become master devices for reconnection purposes.
  • SPP (VCP): Serial Port Profile (Virtual COM Port). In the case of the OPN2002, it sends data serially to a serial port on the Bluetooth host. Software running on the host can read from that serial port to capture the data.

Solutions

The OPN2002 is usable on most platforms and with most Bluetooth stacks.

Supported systems include:

  • Mac OS X
  • iOS 4+ (including iPads running iOS 3.2) (currently HID only)
  • Windows (all flavors)
  • Windows Mobile
  • Linux
  • Android (SPP only)
  • BlackBerry (SPP only)

Note that OpticonRL is available for those platforms that only permit Bluetooth SPP.

FAQ

I'm trying to connect the OPN2002 to my Mac in VCP mode, but I can't seem to get the pairing to complete.

So Unix machines - which is what a Mac essentially is - have their serial ports implemented in a different way, from what you might be used to with a Windows PC. When a serial device is connected to the Mac, and the kernel is able to map a valid kernel driver to it, a POSIX device file is created under /dev/ for that serial port. After that, programs can read and write to this file, which becomes the same thing as reading and writing from a serial port. Windows uses a similar concept with COM (serial) ports, just implemented slightly differently.
Now, when you connect the OPN2002 to the Mac using Bluetooth VCP (SPP), one of these POSIX device files is created in /dev/. To finish the initial connection, that file must be opened with some program - namely yours. To test this yourself, you can use the Terminal program, and run the 'cat' command against the new file that was created under /dev/ while the pairing process was taking place. After that, the initial pairing should complete successfully.

I have the OPN2001 Simulation Application installed on my OPN2002. The OPN2002 seems to behave as an OPN2001 in USB mode, but I can't poll or download scans over Bluetooth. What gives?

Have you tried the getDSR() function? It simulates the RTS signal over Bluetooth VCP; the RTS signal is normally how the OPN2001 signals that it has data to be downloaded.

Why doesn't my pairing seem to finish when I try to connect my OPN2002 in SPP mode?

The (outgoing) COM port needs to be opened on the Bluetooth host after pairing is complete if the OPN2002 is connecting as a slave; if the OPN2002 is connecting as a master, the (incoming) COM port on the Bluetooth host must be open prior to the connection attempt for the connection to succeed.