I have a Pi3 with a PXFMini with a Ublox Neo-M8 plugged into it. I have apm-rover-3.2-erlebrain installed and I am on frambuesa.
Often Mission Planner will say there is no GPS even though it can calibrate the compass (2nd compass) which is on the GPS. If I remember correctly, the GPS is connected over UART on /dev/ttyS0 and the compass is over I2C at address 1e. To me this means the GPS is properly powered. When MissionPlanner says no GPS the GPS sometimes has a blue light indicating it has a lock. I have screened into /dev/ttyS0, but I cannot find a baud rate that gives me meaningful data. The data is always strange characters, but after I kill the screen I cannot reconnect to /dev/ttyS0 (not sure why and would like to learn). This information indicates to me that there is a software problem, but I am not sure how to debug it.
Sometimes the GPS is recognized and everything works fine, but more frequently no GPS is recognized. Power cycling multiple times does eventually solve the problem, but it feels more like a luck of the draw. It seems to me that /dev/ttyS0 is created regardless of the GPS being connected because the serial interface module is installed in the kernel because when I delete /dev/ttyS0, it will reappear after a reboot.
I have found a solution to the GPS not being recognized, but it requires restarting apm.sh. This is not a great solution for me as these robotic kayaks that the system is controlling are not usually connected to wifi and are not ssh-able when they are out on the water. I also have a lot of software around apm.sh that does various other things to pipe sensor data through the mavlink connection ardurover creates. These programs also need to be restarted in a specific order. To me, this sounds like some kind of race condition related to /dev/ttyS0 between apm.sh and the kernel at startup, but I would like to hear another opinion on this.
I have a few questions:
1. Why would it recognize it has a GPS sometimes, but not others when only a power cycle is done?
2. Why would screening into /dev/ttyS0 and then killing the session prevent further screens from connecting to the GPS?
3. Why am I able to screen into /dev/ttyS0 while ardurover is reading the NEMA data from the GPS? This will then prevent ardurover from reading the data and requires a reboot to resolve.
4. What can I change using systemctl to modify when the apm.sh daemon is started on boot up so that I can reliably get a GPS signal through ardurover? (I'm a novice systemctl user)
I have read the three topics from 2016 related to this problem. They do not pertain to mine as they were on escarlata, or were using the pxfmini apt package instead of the erlebrain package.