Closed richahert closed 1 year ago
Hi @richahert
While I can understand the utility of having multiple TCP clients receiving the output from a given GNSS device (which is already supported functionality), I'm unclear in what circumstances it would ever be useful to have multiple TCP clients all sending different configuration commands to the same physical device?
As you're probably aware, U-blox receivers only support configuration commands through their serial ports, so there would need to be an instance of PyGPSClient physically connected to the receiver via USB or UART in the normal manner.
PyGPSClient can already read incoming UBX messages via a TCP socket. This facility was originally intended for receiver output messages ("GET" types), but it could in theory be adapted to accept input commands ("SET" & "POLL" types) from some as-yet-undefined TCP 'configuration client' and forward these onto a connected receiver. This in itself is a relatively trivial enhancement.
However, there are significant additional complexities associated with your particular use case:
I'm not convinced this use case is common enough to justify the amount of (volunteer) work it would entail, but I'm happy to be persuaded otherwise.
Hi @richahert
I've looked into this, and what I could do relatively easily is extend the existing TCP streaming facility to allow remote configuration from a SINGLE TCP client, and pass any responses/acknowledgements back to that one client. It would probably be necessary to specify that the client was in 'command' (SET) mode, rather than standard receiver (GET) mode via a new checkbutton.
Would that satisfy your immediate requirements?
Supporting multiple TCP 'command' clients simultaneously would be far more challenging, and I'm really not convinced there's a widespread need for this.
Thank you for looking into the issue. I think that would help me a lot.
I'm putting this on the backlog for now. I'm afraid it may be months before I can get to it.
As a workaround, I used socat
on the client side as well to wrap the TCP socket (back) into tty. Connected to the virtual serial port with pygpsclient
and configuration read/write is functional.
Is your feature request related to a problem? Please describe.
I would like to be able to configure Ublox GNSS Devices over a TCP connection.
I need to use the TCP connection because I want multiple clients to be connected to the same reciever. They should able to configure the receiver and read the settings.
Describe the solution you'd like
There should be a way to send the configuration messages over the tcp connection, such that I can configure ublox parameters just as with a serial connection. There might be troubles with the response messages when multiple clients try to configure parameters at the same time, however it would already be a major improvement if it works when it works for one client configuring at a time.
Describe alternatives you've considered
I used
socat
to create a virtual serial port clone. However you'd need a new instance for every client and the buffering hard to configure properly.Would you be willing to contribute a test device?
I think any ublox F9* device should be sufficient.
It would be awesome if you could implement that feature :)