enableRAT returns false

hi,

when i call

BG96_Modem.enableRAT("catm+gsm", function(res) { /* res is always false */ } );

the value in the callback is always false. the documentation ( BG96_Modem | Dev Center ) says that false indicates an error. but how do i get the error or more information about the problem?

thanks

Difficult to say in the current version of the library, which, as you say, only passes true or false to the callback, not an error code. One for the to-do list…

Try adding the line BG96_Modem._debug = true; first, so you’ll get some log info back.

Meantime, this is the section of the code where it triggers the callback. This may help you narrow it down:

_getmodemready(function(ready) {
            // Couldn't get modem to talk to us
            if (!ready) {
                _net = null;
                if (cb != null) cb(false);
                return;
            }

            // Set scan mode as needed
            if (!_checkandset("nwscanmode", mode >> 4, false)) {
                _net = null;
                if (cb != null) cb(false);
                return;
            }

            // ... and iotopmode
            if (!_checkandset("iotopmode", mode & 0xf, false)) {
                _net = null;
                if (cb != null) cb(false);
                return;
            }
            
            // ... and nwscanseq
            if (!_checkandset("nwscanseq", nwscanseq, false)) {
                _net = null;
                if (cb != null) cb(false);
                return;
            }
            
            // All ok
            _net = null;
            if (cb != null) cb(true);
        }.bindenv(this));

Basically, that’s a bunch of AT commands the library sends to the modem. The called functions will output info if _debug is set.

I’m observing repeated errors as I try to get the BG96 off “gprs+catm” and onto “catm” solely. When I call BG96_Modem.enableRat(), I will keep getting false back for hours/days until it eventually switches over to catm. From that point on, it’s fine.

If I turn BG_96._debug to true, I get the following:

2023-09-21T23:56:49.469 +00:00	[Device]	modem ready
2023-09-21T23:56:49.589 +00:00	[Device]	checkandset nwscanmode to 3
2023-09-21T23:56:49.688 +00:00	[Device]	current value: 0
2023-09-21T23:56:49.828 +00:00	[Device]	setting new value: AT+QCFG="nwscanmode",3,0
2023-09-21T23:56:49.948 +00:00	[Device]	set failed:
OK

What can I do to prevent this? A disconnect/reconnect doesn’t remedy this. The devices are remote but I may be able to cold start the modem, if you think that would make a difference

Actually a forced disconnect will fix the issue. What I observe is that the onunexpecteddisconnect() callback is invoked 1 minute after the modem error, passing a reason code of 0. The imp repeatedly does this everytime I call enableRat() until I powercycle the unit. When it starts up again it’s on a catm network.

hi,

not exactly the same:

[server.log] modem ready
[server.log] checkandset nwscanmode to 0
[server.log] current value: 0
[server.log] checkandset iotopmode to 0
[server.log] current value: 0
[server.log] checkandset nwscanseq to 0201
[server.log] current value: 020103
[server.log] setting new value: AT+QCFG="nwscanseq",0201,0
"""
  [server.log] set failed:
  OK
"""

in my code the onunexpecteddisconnect is not called. but i want catm+gsm and i am on catm although the function says false .

when i want to switch to “gsm” only i get:

[server.log] modem ready
[server.log] checkandset nwscanmode to 1
[server.log] current value: 0
[server.log] setting new value: AT+QCFG="nwscanmode",1,0
"""
  [server.log] set failed:
  OK
"""

I assume the problem lies in the “…,0” at the end of all of this commands,
as it means that the change takes effect only after the next reboot. So if the routine checks the success of the change of settings, it will likely get the old values first.
The other option would be …,1 to have an immediate reboot, but this should happen only at the end of this routine once, or use CFUN=1,1 to have a reboot after the 3 settings have been made.

This topic was automatically closed after 60 days. New replies are no longer allowed.