str2str no longer sends a fix after a com port disconnect/reconnect #bluetooth

[jancelin]

jancelin/MultiProbeCase#7 (comment)

context:

To explain this bug I am going to use an RTK rover containing an F9p ublox with a Bluetooth connection thanks to the HC-05 module connected to the uart1.
On the other side a pc or raspberry pi under linux with rtklib (RTKLIB-b34g) using str2str to redirect data from a CentipedeRTK network base to rfcomm (/dev/rfcomm0) to broadcast the correction to the F9p.

bug:

str2str no longer sends data if the Bluetooth module disconnects and reconnects, it is necessary to restart str2str to have a data transfer again, yet the logs still show a data transfer.

method for manufacturing the bug:

Configure GNSS F9p And BT

https://docs.centipede.fr/docs/make_rover/configuration

Configure PC/ raspberry pi

• Connect BT:

bluetoothctl

• scan on

get mac ex: [NEW] Device 00:19:09:01:0B:CF ROVER_CENTIPEDE

• pair 00:19:09:01:0B:CF

[bluetooth]# pair 00:19:09:01:0B:CF

• trust 00:19:09:01:0B:CF

Changing 00:19:09:01:0B:CF trust succeeded

• quit

• Start rfcomm to automatically connect the bluetooth module to the /dev/rfcomm0 port

sudo rfcomm bind 0 00:19:09:01:0B:CF

• check that the port is correctly mounted:

ls -l /dev

crw-rw----   1 root     dialout 216,     0 sept. 19 13:34 rfcomm0

if you want to stop the service run the command :sudo rfcomm release 0

• start an rtcm3 correction transimition between caster.centipede.fr and the BT module to reach the F9P:

str2str -in ntrip://:@caster.centipede.fr:80/LIENSS -out serial://rfcomm0:115200:8:N:1:off

you can change LIENSS to the base closest to you and in operation ( https://centipede.fr)

Now the data is sent to the F9P and the RTK LED should glow or flash (check that you are connected to an aerial and that you are in a place where the aerial can see the satellites).

Making the bug:

• restart your rover or just the bluetooth module.
  Tthe rtk led (fix/float) no longer glows.Yet you still have correct logs on str2str

2023/09/19 11:46:34 [CE---]     510683 B   11362 bps (0) caster.centipede.fr/LIENSS (1) /dev/rfcomm0 
2023/09/19 11:46:39 [CE---]     519530 B   12874 bps (0) caster.centipede.fr/LIENSS (1) /dev/rfcomm0 
2023/09/19 11:46:44 [CE---]     525165 B   10957 bps (0) caster.centipede.fr/LIENSS (1) /dev/rfcomm0 
2023/09/19 11:46:49 [CE---]     534195 B   14169 bps (0) caster.centipede.fr/LIENSS (1) /dev/rfcomm0 
2023/09/19 11:46:54 [CE---]     539785 B   10929 bps (0) caster.centipede.fr/LIENSS (1) /dev/rfcomm0 
2023/09/19 11:46:59 [CE---]     548177 B   13405 bps (0) caster.centipede.fr/LIENSS (1) /dev/rfcomm0 
2023/09/19 11:47:04 [CE---]     555948 B   14542 bps (0) caster.centipede.fr/LIENSS (1) /dev/rfcomm0 
2023/09/19 11:47:09 [CE---]     563424 B   12848 bps (0) caster.centipede.fr/LIENSS (1) /dev/rfcomm0 
2023/09/19 11:47:14 [CE---]     571801 B   10935 bps (0) caster.centipede.fr/LIENSS (1) /dev/rfcomm0 

• Stop str2str (ctrl c)
• and restart it (top arrow or the command: str2str -in ntrip://:@caster.centipede.fr:80/LIENSS -out serial://rfcomm0:115200:8:N:1:off)

The LED on the f9p is glowing again, so the RTCM3 corrections are reaching the f9p....

[GregoireW]

The issue is

RTKLIB/src/stream.c

Line 543 in 8fdf210

if (write(serial->dev,buff,n)<n) {

a serial write may fail because buffer full or something like that, but this code do not do nothing with the error. if the kernel remove a device then put it back, the first device serial may be locked and the serial will be bound to another device. in your example rfcomm0 should still exist as long as str2str is running, but yout rf device should be bound on rfcomm1 (I do not have hardware to reproduce this, I did some test with virtual device but ... )