Skip to content

Conversation

@stronnag
Copy link
Collaborator

As yet untested (other than seeing that the Cli option is present)

@stronnag
Copy link
Collaborator Author

stronnag commented Dec 13, 2017

Currently, this allocates GNSS channels as:

Id GNSS Min channels Max channels Enabled
0 GPS 8 16 Y
1 SBAS 1 3 Y
2 Galileo 4 8 Y
3 BeiDou 8 16
4 IMES 0 8
5 QZSS 0 3
6 GLONASS 8 14 Y

Usually gives me between 24 and 27 satellites.

@giacomo892
Copy link
Collaborator

Why do you need to use UBLOX7? I'm using GALILEO as configured via u-center and it is working perfectly at 5Hz.

@stronnag
Copy link
Collaborator Author

Expedience mainly. No reason other than I've not yet got further in defining the exact criterion (e.g. GPS firmware version). One of the several reasons why it is currently marked "Do not merge".

@giacomo892
Copy link
Collaborator

I've a BN880, among the others, that like 50% of the times fails to be auto-configured with UBLOX7 at boot time and it falls back to standard UBLOX at 5Hz. Do you ever experienced this? So that module is likely to miss GALILEO most of the times. I think I should configure it via u-center and don't use auto-configure on it.. but :P

@stronnag
Copy link
Collaborator Author

Ucenter doesn't help users with units without non-volatile storage. It is not auto-configuration; it is user preference via the CLI, with a sanity check. If your unit is broken, don't use it. It uses exactly the same setup stanza as ucenter, so is as likely to be successful.

@giacomo892
Copy link
Collaborator

Maybe I don't have explained the issue clearly. Configuration changes that I do via u-center are sticky. My sole issue with that module if that if I choose UBLOX7 protocol in the configuration tab, I'm getting 5Hz updates via POSLLH most of the times instead of getting NAV-PVT at 10Hz. It like an auto-configuration issue. If I enable NAV-PVT from u-center and disable auto-configuration in INAV of all works just fine at 10Hz all the times.

Changed the CLI variable to `gps_ublox_use galileo` for consistency with
other GPS variables

Changed the eligibility test to M8N hardware and v3 firmware (or later)
@stronnag
Copy link
Collaborator Author

Tested with M8N, Galileo capable but not enabled in EEPROM.

  • With gps_ublox_use_galileo = OFF, Galileo not enabled
  • With gps_ublox_use_galileo = ON, Galileo is enabled

@stronnag
Copy link
Collaborator Author

Fortuitously, the hacky version selection will work on other user's devices ....

image

enum: gpsDynModel_e
- name: gps_ublox_use_galileo
values: ["OFF", "ON"]
enum: gpsUbloxUseGalileo_e
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you remove this table? It seems it does nothing now.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the error is that gps_ublox.c no longer references the related configure variable, which was not intended when I changed the criteria.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm understanding it correctly, a boolean without any table seems like the best option. Do you plan to add more states to the variable in the future?

@stronnag
Copy link
Collaborator Author

No just following similar examples. Please educate me / update the PR if there is a better way

@fiam
Copy link
Member

fiam commented Dec 16, 2017

@stronnag

TLDR: Your setting definition is correct. There's just a small issue with the field definition in the .h file.

I really need to document the settings file format better, sorry about that. For now, let me briefly explain the concepts relevant to this PR:

  • Each setting must have a type. It can be explicit (defined in settings.yaml via type: field) or implicit (determined by parsing the .h files by the generator).
  • Settings with numeric values define a minimum and maximum values. The settings machinery uses these values internally to validate values set by the user (e.g. CLI command set foo = 7). If any of those values is 0, it can be omitted (that's why you see some settings with just max and no min).
  • Settings based on enums require a table which indicates the name of each value. Its minimum and maximum values are defined as 0 and number_of_values_in_enum - 1 respectively for these ones. Tables are defined at the top of the settings file, in the tables: section and then referenced by name via the table: field in the setting definition. This means several settings can share the same table.
  • In INAV, boolean settings are represented as enum settings with a table mapping 0 to OFF and 1 to ON.
  • Which brings us to the last point for today. There are so many boolean settings that manually referencing the ON/OFF table became tedious, so I introduced a shorthand for them by setting the type to bool (i.e. type: bool in the setting definition). This sets the type as an uint8_t and the table to ON/OFF.

gpsAutoConfig_e autoConfig;
gpsAutoBaud_e autoBaud;
gpsDynModel_e dynModel;
gpsUbloxUseGalileo_e ubloxUseGalileo;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd just use a boolean here. Having an enum for just 0 and 1 complicates the code and it seems unlikely that we'll want to add more states to this field in the future.

@fiam
Copy link
Member

fiam commented Dec 16, 2017

@stronnag It seems you forgot to initialise the field when resetting the PG. You need to set its default value around line 134 in gps.c:

PG_RESET_TEMPLATE(gpsConfig_t, gpsConfig,

@stronnag
Copy link
Collaborator Author

I think I will write an 'adding a new CLI option' wiki page after this.

@stronnag stronnag merged commit 76a09c9 into development Jan 19, 2018
@stronnag
Copy link
Collaborator Author

As this has been independently tested on a new 'no eeprom' GPS, I'm merging.

@stronnag stronnag deleted the ublox-enable-galileo branch January 19, 2018 15:19
@digitalentity digitalentity added this to the 1.9 milestone Jan 21, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants