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.
Related
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 ?
I have 3 xbee receiver devices connected to Ubuntu on port ttyUSB0, ttyUSB1, ttyUSB2. Out of these 3, device on ttyUSB2 stops working after every 2-3days. When I open xctu, it shows below error:
Could not find device on port /dev/ttyUSB2. Error initializing xbee device parameters. Connection timeout. Could not read device information.
When I type ls /dev or lsusb, I can see all 3 devices connected and all the 3 serial ports but the device on /dev/ttyUSB2 doesnt respond. When I unplug it and plug it back, it starts operating normally. But again after 2-3 days, it stops responding.
Can anyone please suggest what could be the issue.
I had the same problem. Turned out another program (Cura / Creality Slicer, in my case) was intermittendly checking the serial ports for connected devices, which (I assume) interrupted serial communication for XCTU.
Closing the other program solved the issue.
I'm new to serial communication. For a project I have to develop software for a vending machine. The vending machine basically consists of a host computer (a windows xp machine) and various peripherals. One of those peripherals is a coin acceptor. According to the documentation of the vending machine, the host computer communicates with the coin acceptor using the serial port. The only documentation I have is this document called "Multi-Drop Bus / Internal Communication Protocol" (the version I have can be found here: http://www.coin-acceptor.com.cn/Upload/EditorFiles/technicalfile/Mdb_version_4-2.pdf).
According to the docs it seems I have to create a serial port connection using a baud rate of 9600, 1 start bit, 1 stop bit, 1 mode bit and 8 data bits (page 29 in the linked document). The vending machine docs state that the coin acceptor is on COM port 6. I tried to create a connection like this using HyperTerminal and Putty. My first question is:
How do I properly create a connection to a device that supports this MDB 'protocol'? Putty and HyperTerminal don't allow me to set a "mode bit". I didn't find anything about the flow control and parity bit in the document. Can this be done using Putty or HyperTerminal? Or do I need some other tool to communicate over MDB?
My second question is about how to send a command to the device. I looked through the commands and saw a RESET command. According to the document, upon receiving the RESET command the device should reset itself and respond with an ACK. According to pages 33 and 63 of the document, if I want to send the RESET command to the coin acceptor, I can send the HEX value 08H over the serial line. Page 33 states that the coin changer listens to commands sent to addresses 08H until 10H (if I'm interpreting the document correctly, that is). Page 63 states that the RESET command is 08H with no data bytes. So can I just type "08H" into Putty and hit "enter" to send this command to the device? Or how can I send this command to the device over the serial line? Is this even the right approach or am I looking in the completely wrong place? The vending machine docs only contain this document for the coin acceptor. Thank you for the help!
Kind regards
Chris
I'm using Python 2.7, pySerial under windows 7.
I have 8 devices, they are connected to my PC via Virtual COM port (Silicon Labs CP210x USB to UART Bridge), I'm testing them With multiprocessing all 8 COM ports are open and each time i'm sending command to one unit only, there is no MultiThreading.
The problem is that after X time (it could be 10 minutes or 5 hours), the output Queue of the serial ports fails to send me responses. it's not a specific port each time it's a different port (it can be several ports)
It's importent to say, the device gets my command and do it. the fail is to get the response, The device i'm testing is OK for sure.
I am sniffing the port with Serial monitor, all the commands send OK and the device makes them, only it doesn't respond.
Any idea's ?
There could be n number of reasons:
Buffers might be full
Com Port is not working or might be
And finally the device is malfunctioning..
Check out these things might be it will help you.
I've been trying to do TCP communication using my Wavecom Fastrack modem. What I want to achieve is make the modem connect to a specified TCP server port to enable me to transfer data to and from the server. I found some information on than in the user's guide.
Basing on the information you can find on page 66 I created an application that opens the serial port to which the modem is connected and writes the following AT commands:
AT+WIPCFG=1 //start IP stack
AT+WIPBR=1,6 //open GPRS bearer
AT+WIPBR=2,6,11,"APN" //set APN of GPRS bearer
AT+WIPBR=2,6,0 //username
AT+WIPBR=2,6,1 //password
AT+WIPBR=4,6,0 //start GPRS bearer
AT+WIPCREATE=2,1,"server_ip_address",server_port //create a TCP client on port "server_port"
AT+WIPDATA=2,1,1 //switch do data exchange mode
This is exactly what the user's guide says. After the last command is sent to the modem, the device switches to data exchange mode and from then on everything what is written to the serial port opened by my application should be received by the server and everything the server sends should appear in the input buffer of that port.
The thing is that I did not manage to maintain stable bidirectional communication between the server and my modem. When I write some data to the serial port (only a few bytes), it takes a lot of time before the data appears on the server's side and in many cases the data does not reach the server at all.
I performed a few tests writing about 100 bytes to the serial port at once. Logging the data received by my server application I noticed that the first piece of data (8-35 bytes) is received after a second or two. The rest of the data appears in 2-5 seconds (either as a whole or in pieces of the said size) or does not appear at all.
I do not know where to look for the reason of that behaviour. Did I use wrong AT commands to switch the modem to TCP client mode? I can't believe the communication may be so slow and unstable.
Any advice will be appreciated. Thank you in advance.
what OS are you running? Windows does a pretty good job of hiding the messy details of communicating with the GPRS modem, all you have to do is create a new dial-up connection. To establish the connection you can make a call to the Win32 RasDial function. Once connected, you can use standard sockets to transfer data on a TCP port.
i have been using wavecomm modem for 2 years now.As far as i know from my experience is that if you are able to send some of the data then you can send all of the data.
the problem might be in the listening application which receives the data on the server side.
It could be that it is unable to deal with the amount of data that you are trying to send.
try sending the same data in smaller busts
with some delay in between them,then you might receive all data intact.