In the AT Commands Manual the following is mentioned under 1.5. Unsolicited Result Code: If an event which delivers a URC coincides with the execution of an AT command, the URC will be output after command execution has been completed
Our codebase is written with that in mind.
However, when a lot of requests are being executed (we do a lot of GNSS requests) and at the same time a BLE device connects, the following may happen:
AT+QGNSSRD="NMEA/RMC"
+QBTGATSCON: 0,"FFAA",0,9430B5DFB110,1
+QGNSSRD: $GNRMC,151312.000,A,5229.6438,N,01326.9183,E,0.33,13.88,041023,,,A*43
OK
In this case, a GNSS AT request is being interrupted by a BLE URC (in this case QBTGATSCON but we see the same for QBTGATRREQ).
Before we start refactoring our code to support this situation, I would like to find out more about why this is happening.
So my questions are:
Is this by design and if yes, is this behavior documented?
Is there a way to avoid/fix this on our side?
If this is indeed not by design, is this a known issue and can we expect a fix any time soon for this?
EDIT: maybe needless to say but we are using the all-in-one setup.
There are two types of URCs, the system URC and the URC returned by the AT command:
The system urc reports when certain conditions are met. For example, the command “+QBTGATSCON: 0,“FFAA”,0,9430B5DFB110,1” is reported when ble disconnects
URC returned by the AT command. After the AT command is entered, urc is returned by some query commands, for example, +QBTGATSCON: 0,“FFAA”,0,9430B5DFB110,1.
The at query command takes some time, so before your AT URC can return, it triggers other conditions and reports the ble urc.
How does this rhyme with the AT Commands Manual that reads the following?:
"If an event which delivers a URC coincides with the execution of an AT command, the URC will be output after command execution has been completed"
From this I understand that under no circumstances an AT command can ever be interrupted by a URC and should be outputted after the AT command is completed. However, the behavior that we are seeing tells us differently. Or am I misinterpreting this?
Hi
As for this, do you use mcu to connect to our module, so it takes time for the module to respond to the command? Maybe your at command has not been sent to the module, and the module has already sent urc to the mcu. I suggest you directly monitor the RX TX port of the module to see what the specific output of urc and at command is like
Hi
Your understanding is no problem, the general urc is like this, but we internally change the Bluetooth part of the urc output to non-URC class output, so it will be output during the execution of at, this scheme seems to solve some known problems
Are you saying that you reclassified the BLE URC as non-URC to circumvent some issues you had and those can interrupt AT commands? I’m probably misunderstanding what you are trying to say but if that is the case, I fail to see how the BLE commands are not URC’s (after all, they still are unsolicited). Especially since in the BLE documentation they are mentioned as such:
+QBTGATSCON: 1,“A001”,0,61625C58B558,1 //URC: establish a connection.
Our whole system is written with the knowledge that AT commands cannot be interrupted by URC’s, as per documentation.
Please help me understand. Are we doing something wrong or is this an error in the BLE part of the MC60?
Hi
BLE several commands, deliberately changed to non-URC interface output, although they are URC, but not the nature of the general URC, as to why so modified I am not clear, do this function of the colleague can not find.
These URCs do not affect normal AT command execution or module behavior
Are there any limitations to your development? You can make a special judgment, for these Ble class URC to do the next processing
I’m terribly sorry but I am having a lot of difficulties understanding what you are trying to say. I used ChatGPT to help me so forgive me if I seem to not have understood your reply.
“These URCs do not affect normal AT command execution or module behavior”
That is the problem. They do affect normal AT command execution (see example above and the other one below). The BLE URC’s are interrupting our AT commands. Our system is built with the notion that this should not be possible (as per Quectel documentation).
The only way for us to fix this is an expensive refactoring operation. I’m therefore asking you whether this is by design and whether there is a solution from your side to avoid BLE “URC’s” to interrupt AT commands.
For clarity, here is another example:
TX: AT+QGNSSRD="NMEA/GLL"
RX: +QBTGATRREQ: "FFAA",1,96,9430B5DFB110,521,0,0
+QGNSSRD: $GNGLL,5229.6414,N,01326.9187,E,151242.000,A,A*4C
OK