How looks like command for Gryphon GPS440 Barcode to start scaning - serial-port

I am trying to pragmatically control scanning operation of Gryphon I GPS4400 barcode scanner.
Scanner is attached to host over usb cable and scanner is programmed to act as virtual serial port.
I have control over serial port on host and I am receiving data from scanner regularly, also I am able to send some data to scanner over serial port. Scanner from my random text sent sometime response to serial port some time just beep.
I am trying to activate scanning mode:
Serial On Line: Scanning is initiated by command sent through the
host interface (manual triggering can be enabled in this read mode
through option setting).
(I know how to activate this mode on scanner, by reading configuration barcodes, but after that I do not know how to send command to trigger scanning)
My problem is that i can't find what sequence I need to send to scanner to start scanning?
Is it possible at all to control scanning by commands over virtual com port attached by USB or I need to have dedicated serial cable with special wiring ?

Related

Bluetooth cant connect a master RN42-I/RN to another

I have a PCB DRONE that is using RN42-I/RN for Bluetooth communication.
The drone is controlled with smartphone APP.
I am making a hardware controller for that drone, so I got the same RN42-I/RN BT Module and connected it to my pc using a UART TO USB converter.
I configured the RN42-I/RN as master
here are the settinges pulled out using command "D" and "E".
***Settings***
BTA=0006668CB21E
BTName=HHController
Baudrt=115K
Mode =Mstr
Authen=1
PinCod=1234
Bonded=0
Rem=0006668CB270
***ADVANCED Settings***
SrvName= SPP
SrvClass=0000
DevClass=1F00
InqWindw=0800
PagWindw=0800
CfgTimer=255
StatuStr=NULL
HidFlags=200
DTRtimer=8
KeySwapr=0
when I send "I,10" to scan for the drone I get
Inquiry,T=10,COD=0
Found 2
0006668CB270,XMC-Bluetooth,1F00
Inquiry Done
XMC-Bluetooth is the drone but when send "C,0006668CB270" the connection fails
what am I doing wrong??
Note that I can connect the drone to my phone with no problem.
I think that the problem might have to do with the pairing code, which is a code that appears on the phone when i connect and i only have to press connect and it connects. this code is only used to insure you are connecting the right device it is not a passkey
I have tried with HC05 to but had the same result.

Simulate com port on pc to be recognised by other pc

Currently I have a server, that communicates with a projector through a RS232. The server opens a com port when the projector is connected. The same happens to any PC when a certain type of device is connected through the USB (lets say an Arduino for example). What I want to do it basically replace the projector with a PC/Arduino/Raspberry without the server noticing anything. That would mean the server will recognise the connected PC and open a COM port for it. What do I need to do on the PC so that it automatically opens a com port on the server? I guess there is something very basic that any printer, Arduino, projector etc does, that computers recognise it as a "com port device".
P.S. Doesn't matter the OS on the PC, I just need to make it work and then implement w/e I need to do with the established communication over the port.
P.S.2 I've searched a lot about it, but probabl I am doing it wrong, because I didn't find my type of question anywhere.
COM ports are basically hardware that is detected by the system. Let's say, if an Arduino is connected to a PC, it has its onboard USB to TTL converter which can be found in the device manager(if using windows). Similar USB to TTL converters are there in the market like CP2102, PL2303 which acts like a COM port even if no device is connected further to it. it may be possible that the program you are using(as you referred server) may be sending some data over the serial port and verifying the hardware.
What you need to do to replace it is, first of all, find the baud rate at which the communication is going on, then, listen over the serial lines which machine is sending which message in the sequence(there must be a handshake as I mentioned earlier), if a complicated algorithm is not used by the device, you can simply mimic the device by sending same messages over serial.

How to connect embedded gps device to gpsd

My questions are about my problem interfacing to the 'device' side of gpsd.
I have a GPS device that produces NMEA 0183 output via an RS232 / UART connection, sitting on an embedded board. My problem is that I want to get the data from this device into 'gpsd' running in linux on an SoC on another 'System' board. The only connection I have to get the data from the embedded board with the device is an I2c connection, and I can create an app on the System board that will pull the NMEA message data from the embedded board, across the I2c interface.
My question is how best to get these NMEA messages from my app on the System board into gpsd running on my System board, so that I can use gpsd to 'consolidate' and 'distribute' the gps data to other client applications?
It looks like possibilities are using a tcp or udp device connection into gpsd, or to use a pseudo-terminal (pty) connection as is apparently used for regression testing.
I tried opening a 'raw' pseudo-terminal pair in my app, and adding the pty slave device to gpsd via gpsd's control socket connection. But although gpsd appears to recognize the device as a pseudo-terminal (with major node number 136) and add the pty slave device (/dev/pts/2 in this case), open the pty slave device, and 'activate' the device, it never appears to read any of the NMEA messages coming across the pty slave.
I see the following debug output from gpsd:
root#abcd-efgh:~# gpsd -n -N -D12 -F /var/run/gpsd.sock
gpsd:SPIN: control socket /var/run/gpsd.sock is fd 3
gpsd:PROG: control socket opened at /var/run/gpsd.sock
gpsd:INFO: launching (Version 3.11~dev)
gpsd:IO: opening IPv4 socket
gpsd:SPIN: passivesock_af() -> 4
gpsd:IO: opening IPv6 socket
gpsd:SPIN: passivesock_af() -> 5
gpsd:INFO: listening on port 2947
gpsd:PROG: shmat() succeeded, segment 0
gpsd:PROG: shared-segment creation succeeded,
gpsd:INFO: running with effective group ID 0
gpsd:INFO: running with effective user ID 0
gpsd:INFO: startup at 2016-08-31T16:48:39.000Z (1472662119)
gpsd:UNK: select waits
gpsd:SPIN: select() {3 4 5} -> { 3 } at 1472662124.273340 (errno 0)
gpsd:INFO: control socket connect on fd 6
gpsd:CLIENT: <= control(6): +/dev/pts/2\x0a
gpsd:INFO: <= control(6): adding /dev/pts/2
gpsd:INFO: stashing device /dev/pts/2 at slot 0
gpsd:INFO: opening GPS data source type 6 at '/dev/pts/2'
gpsd:INFO: speed 115200, 8N1
gpsd:SPIN: open(/dev/pts/2) -> 7 in gpsd_serial_open()
gpsd:INFO: gpsd_activate(2): activated GPS (fd 7)
gpsd:INFO: device /dev/pts/2 activated
At that point gpsd just appears to "hang" waiting on messages...
But although GPS messages are then being written from the pty master (by the app running on the System board that pulls the messages from the device), gpsd never appears to read them... If I connect with 'gpsmon' or 'gpspipe' to see what messages are coming across, I see no JSON or raw message output like I would if I had a serial device (ttySx) directly connected to gpsd. I'm not sure if gpsd has added my pty slave file descriptor to the list of descriptors it 'select()'s on.
I've also tried writing another 'dummy' app to open the pty slave device in place of gpsd and read what's coming across the pseduo-terminal connection from the 'main' app that is writing the NMEA messages, and the dummy app appears to get all of the messages correctly. So I'm not sure why gpsd isn't seeing them.
Is the pty connection a valid way to approach this?
Do I have to start up gpsd from my application, passing it the slave pty device path in gpsd's runstring options, instead of connecting the pty device via the control socket 'add device' message?
Or would the 'tcp' device connection be a more standard way to interface the messages from the device, via my main application? Can I then open a local socket connection from my app, and feed the 'tcp://localhost:port' in an 'add device' message across the control socket connection? Or does the tcp socket connection have to already exist when gpsd is launched?
UPDATE: It does appear my pty interface works, as long as I run gpsd with the pts slave device in the runstring, instead of trying to add it with an "add device" message through the control socket. I'm now seeing the NMEA messages I'm sending through from my application being used by gpsd, and can run gpsmon and see location information updating.

COM port lockup with Mbed Virtual Serial Port

I am working with someone using Mbed and a LPCXpresso11U68 board.
I'm not intimately familiar with this particular board, but it has two USB connectors on it, one for the OpenSDA-ish debugger, and a second one is a direct connect to the CPU. I can connect both of these ports to my PC and attach a terminal emulator to each of them, and both ports show output (with a small installed program running on the board).
The device manager shows me that one port (COM51) is using "mbed Serial Port" driver and the other port (COM52) is using "Mbed Virtual Serial Port.
So far so good...
There is a reset button on the board. If I press that button, the port that is attached to the PC using the Mbed Virtual Serial Port driver (in my case COM52) stops operating. The other port (COM51) just restarts cleanly.
The problem I'm having is that after I exit the terminal program (note this happens with both TeraTerm and uCon), if I attempt to reconnect to that port, its not in the list of available comports. Strangely thought, it is still present in the Device Manager.
The only way I've found that I can clear this problem is to unplug/plug that usb cable (COM52) or issue a BREAK condition to COM51 (which AFAIK, resets the board).
I am the writer of uCon and I'd like to be able to detect this (which I can), and also be able to restart the comport connection without any other manual intervention.
One final note: apparently this is not specific to the LPCXpresso11U68 board; my guess it is some issue with the Mbed Virtual Serial Port driver.
Anyone have a clue what may be going on here?

Serial port shown in device manager but unable to access/found?

I've installed the Arduino virtual USB serial port driver, it's appeared as COM4 on my device manager. I double checked by listing all available serial ports in powershell
> [System.IO.Ports.SerialPort]::getportnames()
COM1
COM4
However, when I try to do an echo to the serial port, it says it does not exist
> echo helloworld > COM4
The system cannot find the file specified.
I am trying to upload some firmware in to my arduino, but I kept getting denied by the port. Trying a different USB gives me the same result. I wrote a small program to test the serial port and I get the error:
The serial port "COM4" does not exist.
The device name of a serial port on Windows is \\.\COMn where n is the port number. A device driver can emulate the DOS device name, like "COM4" if it chooses to do so, very simple to do in the device driver code. But that's an increasingly rare thing to do, especially for port numbers larger than 2 and extra especially for port numbers larger than 4. So seeing your echo command fail is not unusual.
A serial port cannot be shared, it can only be opened once by a process and everybody else that tries to open it will get the fail-whale ERROR_ACCESS_DENIED error code. Necessarily so, serial ports sit at the very bottom layer of the OSI model, there is no protocol that arbitrates access to the port. Or to put it another way, the operating system has no guidance on who should get the data that the port receives. There can be only one candidate, the process that opened the port first. So the error message you got is not unusual, you have to make sure that nobody else is using the port. Including the Arduino serial port monitor.

Resources