Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GNSS callbacks don't fire (gnss sample) #72961

Closed
ASerbinski opened this issue May 17, 2024 · 5 comments
Closed

GNSS callbacks don't fire (gnss sample) #72961

ASerbinski opened this issue May 17, 2024 · 5 comments
Assignees
Labels
area: GNSS bug The issue is a bug, or the PR is fixing a bug

Comments

@ASerbinski
Copy link
Contributor

Describe the bug
I'm working with an Adafruit Feather M0 Lora (https://docs.zephyrproject.org/latest/boards/adafruit/feather_m0_lora/doc/index.html) with a GPS "featherwing" (https://www.adafruit.com/product/3133)

Currently attempting to get the GNSS sample working correctly (https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/drivers/gnss)

Now because the GPS uses the same UART as is normally used for the Zephyr console, I had to make some changes to put the console on the USB in addition to defining the GNSS.

I added these lines to prj.conf;

CONFIG_USB_DEVICE_STACK=y
CONFIG_USB_DEVICE_PRODUCT="Feather M0 Lora w/GPS"
CONFIG_USB_DEVICE_PID=0x0004
CONFIG_USB_DEVICE_INITIALIZE_AT_BOOT=y

And I created boards/adafruit_feather_m0_lora.overlay:

/ {
	chosen {
		zephyr,console = &cdc_acm_uart0;
		zephyr,shell-uart = &cdc_acm_uart0;
	};

	aliases {
		gnss = &sercom0;
	};
};

&sercom0 {
	current-speed = <9600>;
	gnss: gnss-nmea-generic {
		compatible = "gnss-nmea-generic";
	};
};

&usb0 {
	cdc_acm_uart0: cdc_acm_uart0 {
		compatible = "zephyr,cdc-acm-uart";
	};
};

It builds fine, it flashes fine, and I can receive from the console using minicom, which gives me lots of output that looks like this (I've truncated some lines due to sensitive location data);

[00:00:00.000,000] <dbg> modem_chat: modem_chat_script_start: running script: gnss_nmea_generic_init_chat_script
[00:00:00.000,000] <dbg> modem_chat: modem_chat_script_stop: gnss_nmea_generic_init_chat_script: complete
*** Booting Zephyr OS build v3.6.0-4165-g5f1e1c7b34ae ***
[00:00:00.063,000] <dbg> modem_chat: modem_chat_on_unknown_command_received: )�R��j
                                                                                   $GLGSA,.....
[00:00:00.146,000] <dbg> modem_chat: modem_chat_log_received_command: $GNRMC,.....
[00:00:00.188,000] <dbg> modem_chat: modem_chat_on_unknown_command_received: $GNVTG,.....
[00:00:00.960,000] <dbg> modem_chat: modem_chat_log_received_command: $GNGGA,.....
[00:00:01.022,000] <dbg> modem_chat: modem_chat_on_unknown_command_received: $GPGSA,.....
[00:00:01.064,000] <[00:00:01.148,000] <dbg> modem_chat: modem_chat_log_received_command: $GNRMC,.....
gnss-nmea-generic: gnss_info: {satellites_cnt: 7, hdop: 1.400, fix_status: GNSS_FIX, fix_quality: GNSS_SPS}
gnss-nmea-generic: navigation_data: {latitude: xxxxx, longitude : xxxxx, bearing xxxxx, speed xxxxx, altitude: xxxxx}
gnss-nmea-generic: gnss_time: {hour: 16, minute: 56, millisecond 55000, month_day 17, month: 5, century_year: 24}
[00:00:01.189,000] <dbg> modem_chat: modem_chat_on_unknown_command_received: $GNVTG,.....

That looks pretty nice, its obviously receiving and processing the data received from the GPS. However, missing is the output from the two callbacks "gnss_data_cb" and "gnss_satellites_cb". These callbacks are apparently not firing, which means that I don't have any way to access the data, which is the actual objective.

Is there a bug here? Or am I missing something?

@ASerbinski ASerbinski added the bug The issue is a bug, or the PR is fixing a bug label May 17, 2024
Copy link

Hi @ASerbinski! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

@bjarki-trackunit
Copy link
Collaborator

Hi, the gnss alias needs to point to the gnss node, rather than the uart node :) The sample contained some overlays which incorrectly pointed to the uart node, which where fixed with this PR #72249

@bjarki-trackunit
Copy link
Collaborator

bjarki-trackunit commented May 19, 2024

The reason the node needs to be updated is this:

/**
* @brief Register a callback structure for GNSS data published
*
* @param _dev Device pointer
* @param _callback The callback function
*/
#if CONFIG_GNSS
#define GNSS_DATA_CALLBACK_DEFINE(_dev, _callback) \
static const STRUCT_SECTION_ITERABLE(gnss_data_callback, \
_gnss_data_callback__##_callback) = { \
.dev = _dev, \
.callback = _callback, \
}
#else
#define GNSS_DATA_CALLBACK_DEFINE(_dev, _callback)
#endif

When defining the callback, a pointer to a specific GNSS can be used to filter out which device calls that specific callback, which can be useful if there are two GNSS devices. Setting the _dev argument to NULL would allow the callback to call, but if you tried to use the GNSS API with the UART node (currently pointed to by the alias), you would get undefined behavior :)

@bjarki-trackunit
Copy link
Collaborator

bjarki-trackunit commented May 19, 2024

Proof that the GNSS callback works is here

GNSS_DATA_CALLBACK_DEFINE(NULL, gnss_dump_data_to_log);

this is the callback which produces the log output you are seeing :) that was the thing which helped me isolate the issue in the first place (the _dev is NULL)

@ASerbinski
Copy link
Contributor Author

@bjarki-trackunit ; Thank you so much, I have it working now!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: GNSS bug The issue is a bug, or the PR is fixing a bug
Projects
None yet
Development

No branches or pull requests

3 participants