There are still too many areas where the ADL APIs are incomplete (or still entirely missing) and one still has to resort to messing about with AT Commands; eg,
Set RTC: viewtopic.php?f=11&t=2031&p=7587&hilit=messing+about#p7587
Platform information: viewtopic.php?t=1171
viewtopic.php?f=3&t=904&p=4451&hilit=messing+about+with+AT+commands#p4451
Caller’s number (Call Service): viewtopic.php?f=3&t=3568&p=13617#p13617
Battery management:
viewtopic.php?f=3&t=3595
Again, see: viewtopic.php?f=5&t=3741&p=14470#p14468
And again - see: viewtopic.php?f=37&t=3804&p=14812&hilit=It%27s+ugly#p14812
And another one: viewtopic.php?f=78&t=3121&p=16870#p16870
And again: viewtopic.php?f=3&t=4394&p=17644#p17641
Hiya,
Another one: Q26xx USB port status (i.e. cable plugged in, bus enumerated etc).
ciao, Dave
Are there even any AT commands to tell you that??
Hiya,
Nope.
But something HAS to know that the cable bas been connected and the USB hardware is active, because the HOST device (i.e. PC) gets some sort of message and starts bus enumeration. The (PC) HOST knows that enumeration is complete because it goes ‘Bing’…
You can use the adl_portEvent() API to get an DTR event when a client opens or closes a connection to the USB flow - but this happens long after the enumeration is complete.
I’m trying to drive the USB LED in a sane way for the end-user - I only want the LED to illuminate when all the following conditions have been met:
USB module is enabled (i.e. AT+WMFM= has been issued to enable the device)
AND
A HOST device has been connected (i.e. VPAD_USB line has 3V3 on it)
AND
Bus enumeration has been completed (i.e. Host PC goes ‘bing’).
Can get the first two by using a second GPIO to sense the VPAD_USB signal and then read the state of the USB hardware using AT+WMFM? when the GPIO changes. Have to guess the last…
Maybe something like a DCD event using the adl_portEvent() API when the bus has enumerated?
ciao, Dave
Another - SMS Delivery Receipts: https://forum.sierrawireless.com/t/how-to-get-delivery-report/4769/2
New year, new example: https://forum.sierrawireless.com/t/configuring-the-cgclass/4255/3
If you enable the ATI level 1 traces, you will see that ADL does actually issue AT+CLCC internally, and this does give the caller’s number - so why can’t it make that information available via the API??!
Another broken link - see: Lots of missing topics!
Another example: https://forum.sierrawireless.com/t/q2686-gprs-problem/4829/6
Worse than that, WIP has deprecated the wip_netInitOpts API and now recommends that we use AT+WIPS instead 
Come on, Sierra Wireless - what are you thinking??!
Sometimes i think they are not thinking… 
Well I just moved over from development on Telit modules where there are no APIs to speak of… just AT-command this, AT-command that. If you want to retrieve any type of data you have to send the command and literally write code to break apart the response string to pull out what you want. So when your app fails 3 weeks later it’s probably because you received an ever-so-slightly different response that doesn’t fit your code… (maybe the +CMGS count goes into double digits! oh no)
Anyways as far as I’m concerned SW is leagues ahead in this department. I am still thrilled when I come across functions like wm_strGetParameterString