ubxlib
ubxlib copied to clipboard
u-blox
[GNSS Module] Streaming Position Processing
The GNSS module provides a mechanism to poll the GNSS for its current location and to get a call back when the that location has been received. However it does not seem to support a mechanism to process and store points if they are being sent by the GNSS not as a response to a poll. This would be a helpful feature!
Hi there and yes, agreed this is a missing feature. Did we discuss it already? I have a feeling I did with someone but there's been Christmas and the new year since then....
What would the API look like? Would it be along the lines of starting an asynchronous position request but leaving it running, so your callback would be called with new position fixes as they occur until you tell the API to stop, possibly by having the callback function return a Boolean result which would be true for continue and false to stop (or, if you're not in the callback, just setting the callback function to NULL)?
Apologies, getting my feet back under the desk in 2022 and now realize that this, or at least the resolution to this, is kind of similar to https://github.com/u-blox/ubxlib/issues/34. We'll try to get this done ASAP, though power saving may have to come first since there are quite a few people waiting on that now.
I agree power saving is more important! Yes there are some parallels w/ #34 but i think this is perhaps a sub ticket of some sort. That other ticket talks about constantly streaming the assistance data into the GNSS as well as streaming the GNSS navigation/position out to the MCU. I am referring specifically to support in the GNSS module ( u_gnss_pos.c ) not in the location module. We may be saying the same thing just making sure.
What would the API look like?
In terms of a mechanism to get the GNSS data to the "client", I think your suggestion of repeatedly calling the callback as new location data arrives would certainly work!
An alternative could be to add add the locations to a queue ( as supported by u_port_os.h ).
Understood, yes, I think it is probably a subset. Will get to it after power saving, realistically March I think.
This might be obvious but the GNSS can be configured to send position at a regular interval rather than sending a poll request and waiting for a response. Configuring a regular update and asynchronous processing the result is what i have in mind here.
Understood, though I don't think you need most of ubxlib for that: just open the serial port and absorb NMEA into a thing of your own.
The reason I was going down the route described in #34 is because that would work just as well for a GNSS chip attached via a cellular module (rather than attached directly to the MCU) without having to implement support for a 3GPP CMUX to support another asynchronous stream.
The default epoch is one second and so streaming it or reading it once a second (which could be from file storage in the cellular module) would lead to a worst-case latency of 2 seconds; not sure if that's a problem of course.
Anyway, there's time to thing about this, power saving first...
In our particular case, we are using the GNSS connected directly to the MCU and benefit from the use of ubxlib as we need to configure the GNSS based on our needs (we don't use all of the default settings). Perhaps #34 represents a more likely use case.
FYI, the GNSS API now includes a uGnssMsg API which allows you to register an interest for a given message type, in any supported protocol (UBX, NMEA or RTCM) and have one of your callbacks called when such a message arrives, which would allow you to receive such a stream, this for the case where your GNSS chip is connected directly to your MCU.
You can find an example of how to do this [here](https://github.com/u-blox/ubxlib/blob/master/example/gnss/msg_main.c).
This doesn't yet work for the case where the GNSS chip is connected via the cellular module, that will come when we've added CMUX support.
Any updates of when the CMUX support will come? We are now wishing we had connected Sara (combined cellular and GNSS) in such a way that we separate comms channels for GNSS and the modem. We are seeing the serialisation of modem commands is the limiting factor of the rate at which we can get GNSS updates. We may move away from MQTT as a transport to avoid these issues.
Hi @owain-incus, funny you should ask that but it's what I've been writing/debugging for the last little while. Had to take a break to re-architect the test system in the middle (for other reasons), which is why it has taken so long. Plan is for it all to be released by mid March.
CMUX support, and on top of that streaming position, is now available in the master branch, final relevant commit c5400594b2d4dfb80d10397906534ebfb971d2c9; see uLocationGetContinuousStart() for the high level API or uGnssPosGetStreamedStart() if you are using the GNSS API directly.
It works with GNSS chips connected via UART, I2C or SPI interfaces and also works to GNSS chips embedded inside or connected via a cellular module. Examples can be found here (uLocationGetContinuous() to a directly-connected GNSS chip), here (uLocationGetContinuous() to a GNSS chip embedded inside or connected via a cellular module) and here (uGnssPosGetStreamedStart()).
I will close this issue now: please feel free to re-open it, or open another, if you have issues.
Hello! Could anybody please help me set up SARA-R510M8S so that I could interact with the GNSS module via multiplexed main UART (RX/TX only)?
What's the channel of interaction of the cell module with the internal GNSS module? Should I consider it? Is it AT-command-based as well?
Example from main_loc_gnss_cell_continuous.c doesn't work because uDeviceOpen(&gDeviceCfg, &devHandle); returns -5 error, which means that some parameters are wrong. But which parameters can be wrong if devHandle is NULL and gDeviceCfg is just static const uDeviceCfg_t gDeviceCfg = {.deviceType = U_DEVICE_TYPE_NONE}; ?
I have also tried to set up CMUX, so multiplexer is enabled successfully but the position is not coming. So I first set up the cell network, tested it after connection, and tried to add the GNSS part with CMUX. CMUX is enabled. uCellMuxAddChannel is ok. uGnssAdd is ok. Then something strange is happening. I don't understand why before uGnssPosGet everything is sending AT-commands and when the uGnssPosGet is executing, it is sending some data somewhere.
like
U_GNSS: sent command b5 62 01 07 00 00 08 19
Why is it sending some data and where? I'm trying to get the location. It should use AT commands, no?
Before that, I could see a lot of AT commands setting up the cellular module and testing it and then some strange hex data instead of AT commands. As a result - no position data.
@elektron314: can you open this as a new issue? I will reply to you there.