search

berthubert / galmon

galileo open source monitoring
GNU General Public License v3.0
200 stars 53 forks source link

Setting new baud rate for ublox UART fails if it happens to be set to the new rate already #146

Open bitkat opened 3 years ago

bitkat commented 3 years ago

F9P with UART1 connected to the serial port of a Raspberry Pi 3B running Raspberry Pi OS. Port shows up as /dev/ttyAMA0 Running ubxtool as a service following the example described here: https://github.com/berthubert/galmon#linux-systemd

The default baud rate for the F9P is a lowly 38400, which I need to increase. As ubxtool supports speeds up to 115200, I do /usr/local/ubxtool/ubxtool -u 1 -p /dev/ttyAMA0 -b 38400 -n 115200

This works fine the first time after powerup, but fails subsequent times (e.g. when restarting the service) because then the F9P UART is set to the higher baud rate already. It seems that now we need /usr/local/ubxtool/ubxtool -u 1 -p /dev/ttyAMA0 -b 115200

The problem is that I haven't found a universal incantation to stick in ubxtool.sh that will always work. Perhaps it is possible to have ubxtool "just try" the new baudrate and be happy if it works.

kpfleming commented 3 years ago

This is 'expected behavior', for what it is worth. The first time you run ubxtool you configure the device to meet your requirements/preferences, and then after that you don't need the -n option any longer.

bitkat commented 3 years ago

More precisely: the first time you run ubxtool after powerup of the ublox module. There is no way of knowing whether that's the case as power to the module often stays on over reboots. In fact we only know at what speed to talk to the module after having had a successful conversation with it. So even "initial" configuration is a matter of trial and error.

Changing ubxtool behaviour in the way described makes sense to me, but of course that was only a suggestion. Any solution will do.

kpfleming commented 3 years ago

Indeed you are correct; it's been a while since I setup my modules and I had forgotten about this quirk. I think I used the ubxtool program (confusingly named the same name) from the gpsd package to store the desired baudrate into flash memory in the module, so that it would always boot with the proper baudrate.