[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-users] gpspipe -R raw reverse direction

From: Paul Bongaerts
Subject: Re: [gpsd-users] gpspipe -R raw reverse direction
Date: Sat, 18 May 2019 12:29:59 +0200

Yo Gary,

First to sum up, trying to run a base station with raspberry pi and ublox m8t. 
To be able to connect a client running on a windows machine rtknavi / u-center etc serial is forwarded to tcp with netcat.
This has the disadvantage that only one client can be connected at once, only that client can also send back commands to config the gps.
For connecting a second client, there needs to be a virtual copy because /dev/ttyAMAO is already taken by the first one. This second copy is read only.
Now i also want to connect gpsd for local display etc so yet another virtual copy in -b broken/bluetooth device mode? 
Or rather try the other way around use gpds as master and connect clients to it. Firing up a gpspipe -(format) for every client seems the way to go after that.
Pesky thing is most clients use tcp only so no gps2udp or direct gpsd connection, and we need raw serial data from the device to these applications.

> Yo Paul!

> On Thu, 16 May 2019 21:07:52 +0200
> Paul Bongaerts <address@hidden> wrote:

> > To forward raw serial data to a network client i use gpspipe.
> > for read only clients this works fine, even with the initial headers
> > gpspipe/gpsd adds to the beginning of the real data

> The headers come up now and again.  No one motivated to add a -q option.
> And the JSON data can be useful.
Did notice them at the start not at the now and then. Found a motivating reason:
When running rtknavi client on nc -l -k 2102 </dev/ttyAMA0 >/dev/ttyAMA0 all is fine
When running rtknavi client on gpspipe -R /dev/ttyAMA0 | nc -l -k $TCP_CLIENT_PORT
After a while it goes nuts and some 20.000+ km out of range, might be these headers?

> > Now how to send real raw serial data back ? in direct mode (without
> > gpsd) something simple like:
> >   nc -l -k 2102 </dev/ttyAMA0 >/dev/ttyAMA0
> > does what i need.

> No generic way at this point.  For limited things you can use "gpsctl -x"
> or for ublox there is ubxtool.  But neither just passes data.

Tried both already, and indeed none of them does the trick. i use ubxtool for autobaud and setting options at low level device mode before starting gpsd.
The gpsctl-x option comes closest, only that also adds headers and checksum. And i never got it to work.

BTW while you are reading, could you give a ubxtool -c and gpsctl -x example for lets say changing the rate from 1 to 4 hz?
When using the hex commands found from u-center binary console it doesn't do the trick. (with or without the header/checksum)

> No one asked before.  Why would you want such a thing?  GPS do not
> generally do much with incoming data
> > Now how can this be send back to gpsd and forwarded to the device?

> Lost me...  Can you provide a higher level description?  What data
> needs to be sent to the GPS?

For all 3 above, to send data back from an external client application to the device for configuring the gps.
Guess the combined GPS/GSM modules need even more talkback for the modem part.

BR Paul

reply via email to

[Prev in Thread] Current Thread [Next in Thread]