Request to remove or alter auto config for Septentrio GNSS receiver

[SeptentrioGNSS]

Feature request

In the current and latest stable version of the ArduPilot code for the implementation of Septentrio receivers (SBF), there is an auto config for a logged stream to the internal disk of the receiver. The mention of this stream is in the file: AP_GPS_SBF.h. Is there a possibility to make it more configurable for any user to specify if they want this stream logged and what content needs to be logged.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Currently a setSBFOutput command is sent to the receiver. It overwrites configurations made on the receiver side or it might not be needed by the user to have this log and there is no way of removing this from the auto config. As there is no parameters to change the contents of the command this is very limiting as the overwrite happens on every boot of the autopilot. After boot the connected receiver needs to be reprogrammed in order to have the right configurations for a flight.

Describe the solution you'd like
A clear and concise description of what you want to happen.
More customisation could be accomplished by adding 4 variables in MissionPlanner:

• Logging interval (OFF, sec1, msec100, msec50, OnChange)
• Logged messages (Postprocess, PP+Support, PP+Support+BBSamples, PP+Event+Comment+ReceiverStatus)
• Logging overwrite (On, OFF)
• Advanced option (having an open field where commands in Septentrio format can be sent to the receiver)

With these variables the content of the message sent to the Septentrio receiver can be customised from MissionPlanner itself. The OFF variable assignment would mean no message regarding logging is sent. The variables define the fields needed in the Septentrio command line interface (CLI) command where the interval, the kind of messages logged and an overwrite can be set by the user. The advanced option would allow for an open text field that anny Septentrio command can be sent to the receiver.

Regarding the other fields in the command (e.g. Stream# or Dsk1) it is fine to keep them fixed as I would suggest only making a note which states the usage of the fixed fields in the command so the user is aware of this on the README of the GPSdriver or the .h or .cpp of the SBF code.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Removing the command so that the receiver logging configuration is not touched by MissionPlanner and all the necessary configurations can be made from Septentrio software tools but this adds a level of extra work as not everything can be done from MissionPlanner itself. The preferred solution is the one above as this incorporates a mostly all-in-one solution for integrations of ArduPilot and Septentrio GNSS receivers.

Platform
[ X ] All
[ ] AntennaTracker
[ X ] Copter
[ ] Plane
[ ] Rover
[ ] Submarine

Additional context
Add any other context or screenshots about the feature request here.

code in question is at line 87

[peterbarker]

Ping @WickedShell , who is responsible for the current logging settings and might have a vested interest in the current settings

[WickedShell]

There are a couple of things we can do here, listed in ease of things that already exist:

• You can add custom configuration lines to the hwdef and do a custom build, which would allow specifying a different logging stream to be specified. This will technically send the hard coded line first, then follow it up with the custom one, which isn't great, but would work. The other downside is that this requires you to have a custom build which is less commonly available.
• You can send gps data injections from the GCS, there's exsisting MAVLink handling for this, but I don't think there is a convenient interface in MP for it. I've used this in a custom GCS to inject 1 way configuration messages to the GPS driver. This is annoying to do every boot though, and obviously is pretty custom again.
• Now we are at the spot of new changes. The easiest change is to make it so that if GPS_RAW_DATA was set to 0 to not emit the logging message at all from the configuration. Adding more meanings to this is a bit harder, as we've already made 2 have a special case for Septentrio GPS units (unmount the SD card when disarmed).
• Do something more complicated, as proposed above, but which is a bit harder to generalize for all units, although we could lean against the per driver specific parameters.

Regarding the comments made, I'd really prefer the ArduPilot implementation of logging continue to request Comment+ReceiverStatus as from a support perspective I've found both of these to be extremely useful, and pretty light weight. And if you are logging PostProcess having Event seems much more useful, and again if it's not connected it should be pretty low impact. Are you seeing problems with this?

My builds have been adding the Support block as I've found it to be valuable and nice. (I can be convinced it should be in the default logging set). If we add that in, that would only leave us needing to add a flag for BBSamples and rates I guess.

[flyingthingsintothings]

I would like to work on this issue. I discussed the implementation with @SeptentrioGNSS and we had the following idea for a more flexible logging implementation.

There could be three new parameters added in the GPS module. The first would allow the user to choose a logging frequency from a set of discrete values (Off (0Hz), 0.1Hz, 0.5Hz, 1Hz... 20Hz). This frequency would then be used on a best-effort basis by every driver that wants to support custom logging frequency. Users could choose Off (0Hz) to disable logging completely which would prevent any logging setup from being performed on the receiver. The second parameter would represent a logging level that is then translated by each driver into actual data that makes sense for that level (e.g. Lite logs only contain Comment+ReceiverStatus on Septentrio GNSS receivers, Basic contains Lite + PostProcess+Support...). The levels could be called Lite, Basic, Default and Full. The specific data at each level for Septentrio GNSS receivers isn't decided yet, but would be properly documented so users know which level logs what. The third parameter would be used to indicate whether logging should be added to any existing logging that is already on the receiver, or would overwrite it.

Suggested names for the parameters would be GPS_LOG_HZ for the logging frequency, GPS_LOG_LEVEL for the logging level and GPS_LOG_FORCE for log overwriting.

The advantage of this approach is that the parameters are detailed enough for users to configure logging how they want, while being generic enough to support different drivers/receivers without adding driver-specific parameters. Any driver-specific things could be documented so users are aware whether their receiver will support the chosen parameter values.

I would love any input on this approach.
@WickedShell

[peterbarker]

@flyingthingsintothings created a PR reflecting his ideas here: #26442