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

Synchronization between LTE and GPS #22

Open
kaffetorsk opened this issue May 6, 2024 · 6 comments
Open

Synchronization between LTE and GPS #22

kaffetorsk opened this issue May 6, 2024 · 6 comments

Comments

@kaffetorsk
Copy link
Contributor

According to nordic the LTE and GPS shares a physical radio resource.

While using your library it seems that if GPS is currently awaiting fix, and I send something on a socket, the send future returns Ok() even though nothing is actually sent.

Am I doing something wrong? Is this a limitation? Shouldn't the "send" future be returned after the radio resource is free, and the data actually sent, or alternatively return an Err()

Workaround so far is to use a mutex for sync.

@diondokter
Copy link
Owner

Hi, I've not run into that so far. Can you tell me what the modem api actually returns?

My guess is that we just have to add something in the various matches like here:

nrf-modem/src/socket.rs

Lines 329 to 338 in f9d4a24

match connect_result {
// 0 when we have succesfully connected
0 => Poll::Ready(Ok(())),
// The socket was already connected
NRF_EISCONN => Poll::Ready(Ok(())),
// The socket is not yet connected
NRF_EINPROGRESS | NRF_EALREADY => Poll::Pending,
// Something else, this is likely an error
error => Poll::Ready(Err(Error::NrfError(error))),
}

@kaffetorsk
Copy link
Contributor Author

Testing takes a looong time when doing it on HW. Coming back with results and examples.

Meanwhile:
The match you mention is part of connect().

My architecture involves a connected socket (dtls) kept in scope by an async task. Another async task periodically pulls GPS data using start_continuous_fix() and free() (with a timeout). I have to use continuous_fix since the 9160 sporadically gives coordinates that are way of, and need to sanity check 2 sets of coordinates.

This works until the continuous_fix runs while i send to the socket

@dragonnn
Copy link
Contributor

dragonnn commented Nov 19, 2024

I think I am getting similar issue for time to time. Sometimes stuff is not send over an UdpSocket and sometimes when the socket is active I am never getting a fix. 2/3 times it works fine, but the other don't and it always happens when I am not connected to it so I could get any logs yet :/.
Just right now it was running with a socket open for ~3h and didn't get a single fix (it is retiring to re run start_continuous_fix when it timeouts after 5 minutes) and it got a fix right after closing a socket because it send me an sms when it finds a fix after it lost it.

@diondokter
Copy link
Owner

Ok, good to know. I don't really have the bandwidth to look into it though.

Nordic probably has docs surrounding this issue and I think I've seen some APIs before. So there likely is a solution in some form.

@dragonnn
Copy link
Contributor

Maybe this https://docs.nordicsemi.com/bundle/ncs-2.0.0/page/nrfxlib/nrf_modem/doc/api.html#c.nrf_modem_gnss_prio_mode_enable ?
But I am not aware if my SIM does support eDRX, I kind suspect not, but I will try it anyway if it helps.
But that could make the problem of LTE not sending stuff sometimes when GNSS is running even worse.

@diondokter
Copy link
Owner

I don't know, it might help!

You can try by just calling that function and seeing if that helps

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants