Ublox Config Dialog with TCP Socket

[richahert]

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 :)

[semuadmin]

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:

1. You would need to deploy some kind of 'configuration client' to send the UBX commands over TCP in the first place. This could, for example, be another remote instance of PyGPSClient set up to transmit UBX commands via a socket rather than serial connection.
2. If you have multiple clients all sending different configuration commands to a single device, would there not be potential for conflicting command sequences and possibly even corruption of the device's non-volatile storage?
3. You would presumably want to send any acknowledgements and responses back through the socket connection to the 'configuration client', which means the connection would have to be duplex (unless you were happy to submit the configuration commands 'in the blind'). There may be latency considerations if you're sending multiple commands in rapid succession. An MQ pub/sub model may be a better pattern.
4. In the absence of some kind of TCP socket authentication, this would leave the u-blox device open to 'malicious' input from any remote TCP client (subject to whatever LAN/WAN access constraints you implemented on your network). The manifest risk may be relatively low, but best practice would normally advise that the connection be authenticated.

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.

[semuadmin]

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.

[richahert]

Thank you for looking into the issue. I think that would help me a lot.

[semuadmin]

I'm putting this on the backlog for now. I'm afraid it may be months before I can get to it.

[Grtschnk]

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.