-
Notifications
You must be signed in to change notification settings - Fork 79
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
Question for assistnow example and LENA-R8 #176
Comments
Hi Arnout: I'm otherwise occupied for a few hours, will get back to you later, but a quick response: From what you're asking, I guess this is with a "LENA-R8001M10"? You're right that, for whatever reason, the current FW version of LENA-R8 does not support access to the on-board GNSS device using CMUX, which, frankly speaking, is an utter pain; all of the However, you shouldn't have to do any of this AssistNow stuff "by hand", the intention is that the cellular module downloads all of the assistance data to the internal GNSS chip by itself. This is in the It is probably, of course, possible to do all of this by hand with the |
Re-reading your post, I see that you've already tried what I was suggesting. I will see if there's a sensible way to make the MGA download working use AT commands later. |
Ugh. Whatever we do here will be a complete hack I'm afraid. The thing is that the The hack (see branch including this below) is as follows:
I have made these changes on a branch which I have pushed here: https://github.com/u-blox/ubxlib/tree/hack_hack_hack_for_arnout_nothing_to_see_here_rmea ...and run it against a SARA-R510M8S (which should be sufficiently similar for our purposes) and it appears to work, see logged output from running a hacked version of the assist_now_main.c example below (with suitably modified AssistNow authentication token, don't worry). If this works for you, and means that LENA-R8001M10 becomes a usable beast, I can see if I can find some acceptable way to bring the hack into the
|
Cool! Thanks Rob! I quickly tried your code, and indeed, I manage to transfer the assistnow data to the lena-r8 now. Unfortunately, is does not make the fix perform better than manually doing the AGPS=1,5 command. (that of course also does local aiding). Even though it is interesting in trying to figure out how the assistnow works internally, and I can play with ucenter and manually try to upload assistnow data, I think I am just going to leave it up to the module, and for now have to live with the slower lock times on the lena-r8? Anyway, many thanks for the branch! At least if I ever want to go back to manual control of the assitnow data, I can now use it this way, also on the lena! |
I think there's something wrong with the LENA-R8001M10 behaviour: the M10 module it contains is our best yet, there is no way it should take 30 seconds or more (which is the usual cold-start time) when it has been given assistance information. I will raise this as a bug internally. If you have a copy of the branch now, is it OK if I delete it from here? Thinking about it overnight, it wouldn't be so bad if I modified the I will get back to you with any feedback I receive over what LENA-R8001M10 is up to ref. assistance data. |
Hi, Ok thanks! Regarding the LENA, I think there's something wrong in how it internally handles the AGPS:
So all these things combined, make the LENA-R8001M10 pretty inferior to the SARA-R4 for our application unfortunately.
(more than 10 seconds for the reply, while this is usually very fast on the sara) |
Sorry about this; internal bug raised, Jira number |
Hi,
I've been looking into getting the MGA-based offline/online assistnow data to the LENA-R8 through the ubxlib. So far no luck.
As far as I understand:
In
uGnssAdd
, we check ifpInstance->transportType != U_GNSS_TRANSPORT_AT
Only then, are the ringbuffers created u
RingBufferCreateWithReadHandle(&(pInstance->ringBuffer) ..
In case of the LENA-R8, the transport type is AT for GNSS, CMUX is not used, so no ringbuffers are created
During the actual
uGnssMsgPrivateReceiveStart
call (to put the assistnow data into the modem), it is attempted to take a ringbuffer(uRingBufferTakeReadHandle(&(pInstance->ringBuffer));)
This fails because of the reasons above
So quick question: Is there a way that we can push the assitnow data manually (using the MGA lib) into the module?
By the way, I was actually initially just using the AT+UGPS commands manually, to let it do the download and pushing of the data to the modem itself internally, but for some reason this works considerably worse/slower than on the SARA-R4. Hence, why I quickly looked into pushing the data myself (what in the end is also just done by ucenter)
Thanks for your feedback!
The text was updated successfully, but these errors were encountered: