Overview
The Modem Abstraction Layer (MAL) is part of the WNC SDK but I consider it separately because it is focused on controlling the LTE modem. The WNC18Qx device uses a Qualcom MDM9207 chipset which contains 4 ARM Cortex-A7 cores. In this chip, the LTE modem code runs on 3 of the 4 cores while the last core is running eLinux. As delivered from Qualcom the LTE modem interaction is through a Radio Interface Layer (RIL). To simplify this interface, WNC created a MAL which implements JSON strings that are used for control. The MAL runs as a daemon under eLinux, and interacts with the RIL via a Berkley socket connecting the eLinux core with the LTE modem. Since there can only be one owner of the socket, the MAL is implemented as a singleton class that opens the socket, then sends and receives JSON strings, and closes the socket.
The MAL class starts the MAL service when it is initialized the first time. After than, any time you issue a MAL command, a socket to the LTE modem is opened, the request is sent, and if a response is returned it is parsed and the the response returned to the caller. All the possible MAL commands are listed in the 'Avnet M18Qx LTE IoT API Guide.docx' that is packaged with the WNC SDK. The classes that utilize the MAL class in this application are:
GPS
The GPS class manages acquisition of GPS coordinates for the current LTE modem location by creating a separate thread that executes every second. As long as GPS is enabled, it will check for the current GPS location and if successful, the location and time of this fix is saved then a flag is set to indicate valid GPS data is available. A caller is then able to retrieve the data as necessary.
WWAN
The WWAN class implements the functionality for managing the WWAN LED which indicates the connection status of the LTE Modem. Because this is an on-going/continuous activity, a thread is created that runs every 2 seconds, queries the LTE Modem status, then updates the LED status.
DEVINFO
The Device Info class is the simplest of the classes as it only implements the functions to access the ICCID and IMEI and return the results as strings to the caller.
Summary
There are many other features that could be included in the application:
- Azure Twins - with this, you could update the state in the Twin and then have it automatically update the device--very nice if you are working with the proper back-end application in place.
- Provisioning - it allows you to provision a device without recompiling and reflashing code in a device (even one that may be out in the field)
- Azure Firmware Updates - Implements the process of downloading a new image to the device. Once it is on the device, it would require a seperate effort to update the flash, but in the case of this example application running on eLinux, it would be simply replacing the application which would be a lot easier to do.
I did not included them because I figured that the software was already sufficiently feature dense. I may add them in the future and if I do, all post another blog at that time. The current application utilizes an HTTP transport, but some features listed above require MQTT or AMPQ. I have tested the current software with the MQTT transport and it works fine, but getting the cloud side (back-end application) running will take some effort as it is a new area for me.
If you find this series of Blogs helpful or educational, please do let me know. I'm always looking for opportunities to help out the community implement/learn about currently available technology!