You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using the ntrip_client (branch ros2 for ROS2 Humble) to connect to http://rtk2go.com:2101.
The connection is successful in about 90% of the cases, but sometimes the following error occurs:
[ntrip_ros.py-1] [ERROR] [1690972588.743143226] [ntrip_client.ntrip_client_node]: Unable to read response from server at http://rtk2go.com:2101
[ntrip_ros.py-1] [ERROR] [1690972588.743503821] [ntrip_client.ntrip_client_node]: Exception: 'utf-8' codec can't decode byte 0xd3 in position 12: invalid continuation byte
[ntrip_ros.py-1] [ERROR] [1690972588.743955650] [ntrip_client.ntrip_client_node]: Unable to connect to NTRIP server
After some debugging I found out that this is because of this strange server response: b'ICY 200 OK\r\n\xd3\x00\x13>\xd0\x00\x03\x89\x97\th\xf7\x82q\x11\xf9\x97\x0b\tS\xa4O\xd3\x8b2'
When the connection is successful, the server response looks like this: b'ICY 200 OK\r\n'
This means that sometimes there is a trailing byte sequence (which is not always the same).
I'm using the ntrip_client (branch ros2 for ROS2 Humble) to connect to http://rtk2go.com:2101.
The connection is successful in about 90% of the cases, but sometimes the following error occurs:
After some debugging I found out that this is because of this strange server response:
b'ICY 200 OK\r\n\xd3\x00\x13>\xd0\x00\x03\x89\x97\th\xf7\x82q\x11\xf9\x97\x0b\tS\xa4O\xd3\x8b2'
When the connection is successful, the server response looks like this:
b'ICY 200 OK\r\n'
This means that sometimes there is a trailing byte sequence (which is not always the same).
The issue can be fixed by using
ISO-8859-1
instead ofutf-8
decoding in line 132 of thentrip_client.py
:response = self._server_socket.recv(_CHUNK_SIZE).decode('ISO-8859-1')
(see https://github.com/LORD-MicroStrain/ntrip_client/blob/ros2/src/ntrip_client/ntrip_client.py#L132)
This fix would make the connection request more robust (although it is just a workaround for the strange server response).
What do you think? Have you any ideas why this server response occurs or how to further improve the fix?
The text was updated successfully, but these errors were encountered: