Hi all,
I would like to know if there is a way to check, through ADL API, if module is on AT or DATA mode?
I’m getting trouble receiving and handling AT_MODE/DATA_MODE event, so it will help debugging if I could check directly which mode is on.
Thanks in advance,
Camilo.
Hi Camiloalmendra,
You can use a variable for status of fcm (data or at mode) 
ttt
Did you read my question?
Hi camiloalmendra,
No ADL API support this feature. So you can use a variable for state of fcm is data or at mode.
ttt
AT or Data mode is a property of a Flow - not of the module.
No, there isn’t an API to check directly - you have to keep track of the events.
What “trouble” are you having, exactly?
We have just figure it out: flow is closed after a few AT ↔ DATA mode transitions. An ADL_FCM_EVENT_FLOW_CLOSED event is received through fcm control handler, but there is no call to ‘adl_fcmUnsubscribe’ in the code.
What we have not yet figure it out is WHY fcm is arbitrarily closed. Anyone has been through this kind of problem?
Regards,
Camilo.
Clearing a call can automatically close Flows…
In fact, we are not using gsm/gprs features, just fcm one. We are switching modes in order to change baud rate.
It worths note that in some test scenarios, with baud rate changing not so oftenly, the flow is not closed and module keeps running steadly (changing baud rate from 600 to 9600, and then back to 600) for hours. But if we change the pattern of messages sent by/to the FCM, we end up in this situation (fcm closed).
We are running tests with a modified version, that re-opens FCM in case a FLOW_CLOSED event is received.
However, it will be insightful to know what is the cause of such behaviour.
Thanks,
Camilo.
Camilo,
I’ve faced the same behaviour while porting my app from eDLib to WIP. (I don’t think it is something with WIP, as I have also had to move to firmware 6.57f, so probably it can be a bug in 6.57f).
I will probably end up reopening the serial flow as you do, but isn’t there a proper way to fight the problem?