Streaming GNSS, offloading processing to Sara

[owain-incus]

Hi Rob/Andreas,

I am using Sara with GNSS; I see your GNSS library code does not use the in built features of the SARA with regards to off-loading work from our CPU to the Sara; I think the Sara supports commands where you just say give me a GNSS location every x seconds; this is done with just a single AT command; after which Sara just starts streaming results as and when.

Looking at the 0.9.1 libraries it looks like various mutex's are created and a task spawned to go and get the GNSS. Are you looking at a feature to use the Sara to do the work for us rather that push the work onto our host processor?

All the best,
Owain

[RobMeades]

Hi Owain: yes, this has been raised a few times now, see #37 and #34. It's kinda the next majorly-requested feature in the queue after cellular power saving, which has occupied all of this year so far.

Question is, what form should the interface take? If you have a GNSS module connected directly to an MCU then I guess that ubxlib is probably only used to configure the GNSS module in the to-the-GNSS-module direction and in the other direction the MCU would just swallow the NMEA stream itself from uPortUart. With a GNSS module that is either connected-via or inside a cellular module then I think there are two possible approaches:

1. Have the GNSS module write a fix to the cellular file system which can be fed back to the MCU through a callback every second based on a URC, i.e. epoch-based.
2. Implement CMUX to the cellular module, allowing a true stream to the MCU in parallel with the AT stream.

(1) would be fairly straightforward, (2) might be a more pure approach but would require quite a log of architectural ripping-up-and-putting-back-together-again in the ubxlib code I would expect.

Views?

[owain-incus]

Somewhere we have to have "logical" connections; either simulated by shared AT interface; or via the CMUX.

I have not delved into how you implement stuff at the moment; but how does library cope with the various situations where asynchronous events / status are sent from Sara; changes in LTE connection state; reception of GNSS data etc. Does implementation reply on not seeing such messages? Or have you already split off somehow into logical connections?

I suppose thats what the CMUX is for?

Either implementation is purely synchronous (MPU asks for something; waits for response) or somehow we get the asynchronisity that the Sara internally supports. Anything other than the CMUX seems a bit of a kludge?

[RobMeades]

Today everything that goes through the cellular module logically goes via the AT interface; if it is GNSS stuff to a GNSS chip attached via a cellular module then it is tunneled through the AT interface (using AT+UGUBX). As you know, AT interfaces uses "unsolicited result codes", URCs, basically things beginning with a "+" spat back at you without warning on a line-buffered basis by the cellular module. The AT Client can be given callbacks which do a string match on the beginning of the URC and runs an asynchronous task so that it can catch them arriving without warning.

So yes, you're quite right that anything other than CMUX is kind of a kludge. With CMUX we can have an AT channel and a quite separate pure GNSS channel to the GNSS chip, all over the same UART: at least, that's my understanding, I've not actually used it myself yet.

Best thing, then, is for me to look in more detail at CMUX. There still might be a reason for doing the "(1)" if people need something more quickly than the CMUX-type refactoring will take. I'll take a look at CMUX as soon as I can get this goldarned power saving thing sorted, it's doing my head in...

[owain-incus]

:-)

Are these logical AT interfaces; or is that a single AT interface with a single handler for the unsolicited messages from the module (both GNSS, and cellular).

Good luck on the power saving; guess what I'll be asking for that soon....Ouuups.

[RobMeades]

You instantiate an AT client with a UART, so there is one AT interface per UART; I believe that in theory you could have more than one AT client per UART, though I admit I've never tried that [and can't see the use-case]. And the AT interface has no knowledge of whether it is doing cellular or GNSS stuff, it is just does AT stuff.

[RobMeades]

Streaming position is now available in the master branch, final relevant commit c540059; 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.