Need Information regarding the PS events in QuecOpen sdk for BC660K_GL?

Technical Subjects Open Solution
1

Hi,
I’m using open SDK (v1.0) for the development of BC660K_GL.
This has a PS stack for informing the app regarding underlying radio events.
But I could not find detailed info about which events are reported and on which URC those events are generated.

I see the examples and could find some but they are not clear.

typedef enum {
    URC_ID_START = 0,      //< URC event ID for command +CREG
    URC_GROUP_MM = (U_CAC_MM << 12),
    URC_ID_MM_SIGQ,
    URC_ID_MM_TAU_EXPIRED,
    URC_ID_MM_BLOCK_STATE_CHANGED,
    URC_ID_MM_CERES_CHANGED,
    URC_ID_MM_NITZ_REPORT,
    URC_GROUP_PS = (U_CAC_PS << 12),
    URC_ID_PS_BEARER_ACTED,
    URC_ID_PS_BEARER_DEACTED,
    URC_ID_PS_CEREG_CHANGED,
    URC_ID_PS_NETINFO,
    URC_GROUP_SIM = (U_CAC_SIM << 12),
    URC_ID_SIM_READY,      //< SIM card is ready
    URC_ID_SIM_REMOVED,    //< SIM card is removed
    URC_GROUP_DEV = (U_CAC_DEV << 12),
  

    URC_ID_END,            //< End of the URC event ID enumeration
} ENUMurcID;

  1. But if the module is run in its native firmware, on connection, CEREG, CSCON, IP are reported automatically. But in the case of quecopen SDK, these won’t be shown, instead which events will be reported in the ps callback?

  2. An unknown event 16389 comes.

  3. Would MQTT/lwm2m event urc would also be reported in this, if yes, then on which events, if not then how would the app know regarding the late URCs?

2
  1. When the bottom layer detects changes in the network or sim card, it reports messages to the application layer. If the network status changes, the module will report these URCs. pls Look closely at example_ps.c

2.16389 Did not see the definition, the underlying definition can ignore this message

3.660k only has the example of mqtt. In combination with ril_urc.c, lwm2m is not added

3

In bc660K_gl SDK, are URCs not reported automatically to the main app, as you have mentioned example_mqtt in combination with ril_urc, does that mean aside from PS events, all the other events like MQTT must be reported to the main app by the app itself (like in ril_urc).
For example MQTT, there are no handlers from ril_urc attached to any MQTT command in ril_mqtt.c but would that still work or do you have to attach these handlers yourself even there?

If I remember right, BC66 reported URC to the main app themselves, or was that also using ril_urc somehow?

4

Hi BetaEngineer1992,

I am pretty new to the Quectel development environment but I am in the process of porting code from an existing BC66 code base to the BC660K. I was of the opinion that these were backward compatible but this is not the case and not only that I am also finding it difficult to get information on what sequence of events are expected to be sent on start-up by the RIL.

From what I can observe debugging the code I noted that on the BC66 there is a MSG_ID_RIL_READY that gets sent automatically on start-up and we use this to kick of our application.
Another message that I can see get sent by the RIL_URC is the MSG_ID_URC_INDICATION which contains the actual type of message in msg.param1 and the returned parameter in msg.param2.

At the moment on the BC660K I am not getting the MSG_ID_RIL_READY message and hence kind of a show stopper for me.
I did also note that until the URC_ID_PS_BEARER_ACTED event is received, the radio is not actually connected to an MT. I might be wrong on my assumption but this is based on my issuing the following
command

AT+CGATT?
[ATResponse_Handler] receData= [
+CGATT: 1

OK

If I issued the command before receiving the URC_ID_PS_BEARER_ACTED event, then the AT+CGATT command returns +CGATT: 0.

If I remember right, BC66 reported URC to the main app themselves, or was that also using ril_urc somehow?

So I believe that you are correct in your observation about BC66 sending message to the main app at least the two event mention above.

Regards
Ola

5

Hi Ola,
we have the same case. I also used BC66 before, so I was of the opinion that most of the code would be compatible with BC660K, but that’s not the case.
I’m not sure about your requirement, but I have observed the following shortcomings yet,

  • No lwm2m support yet
  • ql_time only deals with the current time, no no conversion from epoch to ST_TIMe & vice versa available.
  • Lack of basic APIs in ril APIs (system, power, network, etc. as compared to BC66)

You are right about the RIL_Initialize(), BC660K_GL does not notify the app about this event.
So it’s better to manually initialize it at the start of your main task, then pass the message to your while loop. I have done something like this,

void proc_main_task(void) {
	ST_MSG msg;
	Ql_SleepDisable();
	Ql_RIL_Initialize();

	Ql_UART_Open(m_myUartPort, 115200, CallBack_UART_Hdlr);
	maintask_queue = osMessageQueueNew(MAINTASK_QUEUE_LEN, sizeof(msg), NULL);
	ret = Ql_PSCallback_Register(GROUP_ALL_MASK, pscallback);

	msg.message = MSG_ID_APP_START;	
	msg.param1 = 0;
	msg.param2 = 0;
	osMessageQueuePut(maintask_queue, &msg, 0,0);

        while (1) {	
	        if(osOK == osMessageQueueGet(maintask_queue,(void*)&msg, NULL, osWaitForever)) {
		        switch(msg.message) {
			        case MSG_ID_RIL_READY: {
				        APP_DEBUG("<-- RIL is ready -->\r\n");
				        Ql_RIL_Initialize();
			        }
			        case MSG_ID_APP_START: {	
				        APP_DEBUG("<-- APP is ready -->\r\n");
				        // Your Starting Code here
				        break;
			        }
		        }
	        } 
        }
}

You can also check the examples if not already handled this.

Regarding PS events, yes that is also the case. Normally in case of Native firmware (where bc660k act as just the nb IoT module), on connection/disconnection CEREG, IP, and CSCON are received. But in an open solution, there is no way to get them only the Bearer acted or deacted events, So you have to read them yourself manually.

I’m testing the events URC for MQTT, if not reported automatically to the app, then it’s an extra work to notify the app manually.
Regards,

6

Hi BetaEngineer1992,

Thanks for your response. Unlike yourself who have previously worked on the BC66. I have never used the BC66 before project. In fact I only heard of Quectel about 2 months ago so very new territory for me.

The BC66 project was written by someone else who have left the company and handed down to another colleague who then handed it down to me as they became busy with another project so I am completely new to the whole area including NBIoT.

I am however not new to firmware development on other platforms so picking this up has not been much trouble I only wished that there were more documentation available, explaining what is actually going on.

And probably documentation that discusses the difference between the BC66 and BC660. According to our hardware designer, the BC660 was sold to him as a drop-in replacement which clearly is not the case and needs more time on the porting.

Out of curiosity the following code snippet in the while(1) proc_main_task() function

        case MSG_ID_RIL_READY: {
	        APP_DEBUG("<-- RIL is ready -->\r\n");
        }

is this a typo error? the reason that I ask is that I don’t get the MSG_ID_RIL_READY event on my board or is there something I need to do to in order to receive it.

I am currently using the example_ps.c as my template example and seem to have most things working. One problem though that I am looking for a work around is the delay in the getting the URC_ID_PS_BEARER_ACTED event as this can take up to about 15 minutes to come through.

Our project uses a small battery and only runs for about a minute and goes to sleep for hours before waking up again. So to have to wait 15 minutes for the bearer acted event to come through is not an option.

there is no way to get them only the Bearer acted or deacted events, So you have to read them yourself manually.

I’m testing the events URC for MQTT, if not reported automatically to the app, then it’s an extra work to notify the app manually

I am not very clear with what you mean here. Is this a work around for getting the URC_ID_PS_BEARER_ACTED event faster using MQTT? if so can you please elaborate more as I am blocked on this.

Ola

7

Hi,
yes, the reason for posting these questions here was to get some clarity on things that are not mentioned in SDK or any document. And yes, from the HW perspective, bc66 and bc660k can be replacements (I’m not very good in hw), but from a software/SDK point of view, they are different.

Back to your concerns,
Yes, ril_initalize inside while is typo, I used this before, but since it is useless, I forgot to remove this. :grinning:
And regarding, PS event useful (for me) is the bearer events. This event comes (from my observation) from a change in cereg state. But since I was using cscon and IP handlers as well before, so for me these ps events were not enough because they don’t report cscon changes, so I had to handle it myself. If you only need to know whether the module has been attached or detached from the network, then these PS events will be enough.

Regarding 15 minutes time, yes the issue is there. There is another topic in the forum here to discuss this, but this time is always there.
In my observation, when new firmware is flashed, all-flash including module NV is erased, so on bootup module has to search for the network which takes time. The topic in the forum discusses how to handle this but it’s not an official response nor have i tried so I can’t say for sure it will work.

What I’d suggest (that is what I am doing), is when the module is connected to the network, get the operator via
AT+COPS?, and hard code this operator via AT+COPS=1,2,“op id”,“act” in the start of firmware, so that module only tried to search for the specific operator, this has made the time for search considerably smaller.
And during sleep mode, module NV memory is retained, so on the next wake-up, it should not take 15 minutes or so, and should connect immediately.

Hope this helps.
Regards.

8

Hi BetaEngineer1992,

Cool thanks. That is very useful information that you have shared. Highly appreciated. and thanks once again.

Regards
Ola

9

Hi BetaEngineer1992,

Just to mentioned that your suggested for getting the URC_ID_PS_BEARER_ACTED event quickly by setting the AT+COPS=1,2,“op id”,“act” at start-up work as a charm,

One thing that bothers me though is that on the BC66 code that I am porting. I can not see where the COPS command is being set and this seems to connect quickly to a network.

So my question is this. I appreciate that you don’t work for Quectel but as far as you aware, is this issue only applicable to the BC660 and not BC66.

if anyone reading this post knows the answer to this please respond. I just feel slightly uncomfortable that I can not find where the +COPS command is been set on the BC66 and yet it does not take long in connecting.

Regards
Ola

10

Hi Ola,
As far as I know, this issue only happens in bc660K, but then I don’t have experience with others modules from quectel, so probably anyone from quectel support can confirm this.

Also, I’m not sure what your requirement is for the migration of firmware, you can always add new things specific to BC660K, since bc66 SDK was mature, and bc660K had only 1 revision, so it might not be possible that all the functionality of bc66 is in bc660K.
However the connection time issue is inherited to the module, is not related to SDK/API (IMO), so you might have to add a new program to handle this in bc660K

Best Regards.

11

Hi BetaEngineer1992,

Sorry for late acknowledgment of your post. I believe your response was good enough for me to get on. I think I am just about finished with the porting work.

I only wished there was more information on the Quectel SDK as the post title mentions. It would have been very good if Quectel supplied some form of documentation which basically describes the data structure that is associated with each PS event and its length.

What does the PS acronym even mean? I have tried to search and can not find anywhere. Small things like this can make the programming less painful.

Hi herbert.pan-Q
Can you please feed this back to your team, and if any of things I mentioned already exits please share them with me. Many thanks in advance.

Regards

12

I am not good at open SDK. If there are still problems in debugging, please solve them by tickets
https://ticket.quectel.com/secure/Dashboard.jspa