Skip to content
This repository has been archived by the owner on Sep 16, 2024. It is now read-only.

LTE: fix conditional in lte_check_attached #520

Open
wants to merge 1 commit into
base: Dev
Choose a base branch
from

Conversation

sven-hm
Copy link

@sven-hm sven-hm commented Jan 21, 2021

As CEREG was set to 1 in this commit the answer to an "AT+CEREG?" will only contain information up to the <stat>-value. So lte_check_attached with legacy=true and when "AT+CGATT?" returns 0 will always return false.

This tiny PR should fix the problem.

@peter-pycom
Copy link
Contributor

You're completely right. Yes, cereg 1 broke this line and I think it's safe to remove these checks

Thanks. We'll include it in the next release.

I see you set it to Draft, were you thinking of adding other changes? ...

Also, I would like to better understand the background - did you actually get a lte.isattached() False even though you were attached according to CEREG? If so, you must have gotten a CGATT 0. And I'd be very interested in the details, because I have never seen that. Are you using any additional AT commands? carrier param? Which country, provider, band, FW version, etc are you using?

@sven-hm
Copy link
Author

sven-hm commented Jan 25, 2021

Actually i first wanted to understand the difference between getting the attached-state information from the AT+CGATT? and AT+CEREG?. But if you say the fix doesn't break anything, i'll un-draft it :)
I had some debug-output in those lines and saw the case that AT+CGATT? returned 0 and AT+CEREG? returned +CEREG: 1,5, we have the lte.isattached() in a retry loop, so it took some retries and AT+CGATT? returned 1. I tried to reproduce this today in the morning but couldn't.
Before we try to connect we only use AT+CIMI to read the IMSI.

Some more details:

  • country: Germany
  • provider apn: iot.1nce.net
  • band: 8
  • board: GPy 1.0
  • FW version: v1.20.2.r4
  • modem firmware: UE5.0.0.0d, LR5.1.1.0-41065

@sven-hm sven-hm marked this pull request as ready for review January 25, 2021 15:42
@peter-pycom
Copy link
Contributor

peter-pycom commented Jan 25, 2021

Mhm. Could it be that it was a race condition? I mean if it only happened once, it could be that at the time of cgatt it was not attached, but a few milliseconds later at the time of cereg, it was attached, but it tested for a cereg=2 return value. That failed so it returned False. The subsequent call to isattached() should then return True, because now both cgatt and cereg both show that its attached.

Could it be like that?

@sven-hm
Copy link
Author

sven-hm commented Jan 28, 2021

That might be possible. I left one regularly attaching device running over the last days with some debug logging and didn't have the case again.

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

Successfully merging this pull request may close these issues.

2 participants