If the GPS driver was used on another port (e.g. TELEM2), it would get
stuck in a `write` call and not return anymore. Disabling flow control
fixes that.
CPU usage is unchanged.
This warning message would often be printed during normal configuration and does not represent a good indicator for true GPS lost states. Instead the system flags should be used, which are available through the normal logging system.
Note: it changes the interface slightly: instead uf -dualgps, use -e now.
This also fixes 2 bugs:
- nullptr access when doing 'gps status' with fake gps running
- close(fd) was called on an uninitialized fd when gps fake was running
The gps driver did not give feedback if a non-existing verb was used
such as `gps foo`. Also, the goto out was ugly and the usage always
marked as an error when it's really an info. This cleans it up a bit.
It makes more sense to set the optimization flags on a platform basis
instead of individually for each module. This allows for different
optimization options for SITL, NuttX, Snapdragon, etc.
It uses a queue length of 6. There are 3 RTCM msgs/s, but due to
fragmentation and WiFi lags, there can be more than that. During several
tests, a length of 6 showed no queue overflows.
Drawbacks of the previous method: when writing to the SD card, there are
high delays in the write() call of several 100ms, every now and then. The
frequency and length of these events depend on:
- SD card
- used logger bandwidth
- bandwidth of gps data (RTCM)
Since the whole gps thread was blocked during this period, it lead to
gps timeouts and lost module.
What we do now is: publish an orb topic with queuing. This makes it async
and the logger takes care of buffering. This means it's best to:
- use high logger rate
- use large logger buffer
- reduce logger bandwith by disabling unused topics
Beat Küng