drivers/gps support ublox basic spectrum analyzer (UBX-MON-SPAN)

[dagar]

• enable UBX-MON-SPAN with new parameter GPS_UBX_SPECTRUM
  • available on m9n and ZED f9p
• GPS drivers update ubx: add optional spectrum analyzer support (UBX-MON-SPAN) PX4-GPSDrivers#115

[ryanjAA]

👍👍

[mrpollo]

When is this coming in? looks really helpful

[ThomasRigi]

Hi @dagar , while looking into an obscure RTK failure mode that we've encountered, I've found this open PR. We think it would be interesting information (linked to PX4/PX4-GPSDrivers#115 (comment)) . We took your PR as a base, and managed to get some first data quickly.

If there's still interest we can provide support on the PR to get it merged.

One question in particular that we have on this PR is on how GPS_UBX_SPECTRUM is used to set the publication of the data. I would have expected it to also be used in the constructor in the same way as GPS_SAT_INFO, with the rest following analogously:

	/* create satellite info data object if requested */
	if (enable_sat_info) {
		_sat_info = new GPS_Sat_Info();
		_p_report_sat_info = &_sat_info->_data;
		memset(_p_report_sat_info, 0, sizeof(*_p_report_sat_info));
	}

Is there a reason for having two separate ways of activating additional debug topics ?

On a side note (for another PR), we'd also like to add a new message for logging more data from UBX_MSG_MON_RF , in which we'd have the same question on how to init the logging.

[ThomasRigi]

resolution_hz = spectrum_span_hz / 256, so we can remove this field.

[dakejahl]

I think this comes in once we have a way to report it, see mavlink/rfcs#30

[hamishwillee]

I think this comes in once we have a way to report it, see mavlink/rfcs#30

@dakejahl Did you confirm that RFC proposes what you want?

[ThomasRigi]

IMO it's already very valuable to have it in the log. For example with Flight Review you can do some fancy stuff:

It has already helped us identify a disturbance on a frequency that made the F9P on HPG 1.30 completely lose the fix with RTK activated, and on HPG 1.51 it only saw some minor degradation but kept the RTK fix throughout the disturbance.

We're finalising the code on our branch. I'll be able to provide a PR hopefully in a week. Most of our changes compared to this PR are related to multi-instance logging: we want both L1 and L2 for both our receivers.

Side note: we've also worked on logging all data from the MON-RF topic. It's a very similar change (same for multi-logging). I'll provide a PR too.

[dakejahl]

I think this comes in once we have a way to report it, see mavlink/rfcs#30

@dakejahl Did you confirm that RFC proposes what you want?

Mostly yes, still don't quite have time to spend on it.

@ThomasRigi can you re-open this as a fresh PR fully fleshed out? Along with the submodule change.