Conversation
|
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? |
|
Actually i first wanted to understand the difference between getting the attached-state information from the Some more details:
|
|
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? |
|
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. |
As
CEREGwas set to1in this commit the answer to an"AT+CEREG?"will only contain information up to the<stat>-value. Solte_check_attachedwithlegacy=trueand when"AT+CGATT?"returns0will always return false.This tiny PR should fix the problem.