Cellular technology overview and porting updated #489

AriParkkila · 2018-04-09T12:40:33Z

No description provided.

AnttiKauppila · 2018-04-10T06:34:28Z

docs/reference/contributing/connectivity/CellularInterface.md

@@ -87,7 +58,7 @@ typedef enum {

 You must define all pins. Implement `onboard_modem_api.h`. The target board must provide an implementation of the [onboard_modem_API](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/onboard__modem__api_8h_source.html).

-#### Modifying cellular targets
+## Modifying cellular targets

 Setup for some predefined targets is available in [CellularTargets.h](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_cellular_targets_8h_source.html). For a new target, you need to modify `CellularTargets.h`. In `CellularTargets.h`, you need to specify a cellular device in addition to UART pins connecting the Mbed OS CPU to the modem. For example, if the new device MY_NEW_TARGET defined above in the "Adding modem target support" chapter is connected with QUECTEL BG96, you would need the following changes marked in between `// !!!!` in `CellularTargets.h`:


I would combine those two sentences talking about CellularTargets.h.
Something like ... to modify CellularTargets.h by specifying a cellular device ...

AnotherButler

@AriParkkila Thanks for the PR 👍 I've left some comments and queries for you to address. I've also copy edited the file. Please review my changes to make sure I didn't accidentally change the meaning of anything.

AnotherButler · 2018-04-11T16:14:10Z

docs/reference/contributing/connectivity/CellularInterface.md


-Setup for some predefined targets is available in [CellularTargets.h](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_cellular_targets_8h_source.html). For a new target, you need to modify `CellularTargets.h`. In `CellularTargets.h`, you need to specify a cellular device in addition to UART pins connecting the Mbed OS CPU to the modem. For example, if the new device MY_NEW_TARGET defined above in the "Adding modem target support" chapter is connected with QUECTEL BG96, you would need the following changes marked in between `// !!!!` in `CellularTargets.h`:
+Setup for some predefined targets is available in [CellularTargets.h](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_cellular_targets_8h_source.html). For a new target, you need to modify `CellularTargets.h` by specifying a cellular device in addition to UART pins connecting the Mbed OS CPU to the modem. For example, if the new device `MY_NEW_TARGET` defined in the "Adding modem target support" section is connected with QUECTEL BG96, you would need the following changes marked in between `// !!!!` in `CellularTargets.h`:


I know some of this is existing content, but we try not to include board-specific information and examples in our documentation. Is there any way to remove some of the board-specific content and replace it with more generic instructions?

True, this porting page could be rewritten in more neutral tone of voice. I will look into this in the next phase after Handbook has been restructured.

AnotherButler · 2018-04-11T16:16:12Z

docs/reference/contributing/connectivity/CellularInterface.md

@@ -118,38 +89,50 @@ Setup for some predefined targets is available in [CellularTargets.h](https://os

 If none of the existing modems is compatible with the new modem, then create new modem implementation under [features/cellular/framework/targets](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets). A device class inheriting [AT_CellularDevice](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_a_t___cellular_device_8h_source.html) is a minimum. [QUECTEL_BG96](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/QUECTEL/BG96/QUECTEL_BG96.h) is an example of the device class. You can create additional overlapping functionality for everything that is available in [features/cellular/framework/targets](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets).


We also don't link to GitHub if at all possible. Could you please replace GitHub links with Doxygen links? Let me know if I need to generate Doxygen for another feature branch here.

Fixed CellularDevice and LISA PPP link https://github.com/AriParkkila/Handbook/commit/bb3b257e26fcdfc7edc4d9dff6fc94c07b5421fc

Example links are still to Github, and there is no reason to make Doxygen to those individual targets.

I will try to remove links in the next phase, as commented above.

AnotherButler · 2018-04-11T16:18:10Z

docs/reference/technology/connectivity/cellular.md

+
+3GPP TS 27.007 and 27.005 are standards to provide consistent cellular network data connectivity and SMS over an AT command interface for cellular devices, regardless of the underlying cellular network.
+
+OMA Lightweight M2M is a protocol from the Open Mobile Alliance for IoT device management. The Mbed OS cellular API provides core functionality to implement the LWM2M Client. For more information, please see [OMA LWM2M](https://en.wikipedia.org/wiki/OMA_LWM2M) and [OMA LwM2M ConnMgmt](http://www.openmobilealliance.org/release/LWM2M_CONNMGMT/V1_0-20170314-A/OMA-TS-LWM2M_ConnMgmt-V1_0-20170314-A.pdf).


Query: Is there a non-wikipedia link we could use for OMA LWM2M instead?

A very good point. Updated link to OMA in https://github.com/AriParkkila/Handbook/commit/699138568757c0484e0640878a89520117386a92

AnotherButler · 2018-04-11T16:20:13Z

docs/reference/technology/connectivity/cellular.md

+
+#### PPP mode with the LWIP stack on Mbed OS
+
+In PPP mode, the LWIP stack is linked as a part of the Mbed OS application. Sockets are implemented on the LWIP stack, and the modem is used over a Point-to-Point Protocol (PPP) link as a plain data pipe.


Query: Who or what implements sockets on the LWIP stack? You, the user? Or something else? Also, who or what uses the modem over a PPP link?

Updated description about IP stack selection in https://github.com/AriParkkila/Handbook/commit/df8b05aa9ec9438fde316659a9aa243b5bb3c66e

Fixed also "AT commands are modem specific, and you need to implement them" due to this page is intended to application developers... who are not the ones to make porting.

AnotherButler · 2018-04-11T16:21:07Z

docs/reference/technology/connectivity/cellular.md

+
+#### AT mode with the IP stack on the modem
+
+In AT mode, the modem's internal IP stack is used over an AT link. Sockets are part of the IP stack, so AT commands are used to control sockets. Socket AT commands are modem specific, and you need to implement them on the Mbed OS side within a `CellularStack` class. You can browse `CellularStack` under the cellular/targets folder to learn how your cellular module supports AT sockets.


Query: Who or what uses the modem's internal IP stack over an AT link? You, the user? Or something else? Also, who or what uses AT commands to control sockets?

Above is a sentence "If you want to use UDP or TCP sockets, you need an IP stack."

This page is written to application developers so "you" always means an application developer, that is an API user.

I originally wrote this under APIs, but this was moved under Technology which may now cause some confusion... API (this page) and contributor (porting page) has identifiable readers... How about Technology??

AnotherButler · 2018-04-11T16:21:52Z

docs/reference/technology/connectivity/cellular.md

+
+### Non-IP optimizations
+
+The Mbed OS cellular API has also been planned to **support non-IP communication in the near future**. You need to make two changes when using non-IP in your application:


Query: Do we want to include this before we actually support non-IP communication?

Removed Non-IP socket chapter:
https://github.com/AriParkkila/Handbook/commit/28da2d75b081653974d46c4245abe1a4b025771f

AnotherButler · 2018-04-11T16:23:41Z

docs/reference/technology/connectivity/cellular.md

+
+This feature serves devices that need smaller latencies. A connection is kept open all the time, but the modem achieves a sleep state between the reception times. The data connection, if using IPv4, may need periodic keep alive messages to keep the network address translation mapping valid.
+
+eDRX configuration is given to the modem. It is negotiated with the network, and the time accepted by the network may differ from the requested time. Availability of this optimization depends on the cellular network.


Query: Who or what gives eDRX configuration to the modem? Also, who or what negotiates it with the network?

Clarified that An application gives eDRX configuration to the modem in https://github.com/AriParkkila/Handbook/commit/d9e98f640a283cdbdc9c44c2daba43c6cbcf01d6

AnotherButler · 2018-04-11T16:24:24Z

docs/reference/technology/connectivity/cellular.md

+
+Which networking protocol to use depends on multiple factors. Server communication model, power consumption, reliability need and operator support are the biggest factors. 
+
+TCP is a reliable transmission protocol. For long-lived sessions, periodic keep alive messaging is necessary, which places demands on the main power source. For a long-lived TCP connection, the server application can contact the device. Connections can still have long latencies because the device's use of eDRX power optimization affects when it listens for incoming packets. Mbed TLS supports TLS transport security over TCP. Operators may, however, prevent using TCP over NB-IoT due to device deployment and network planning considerations.


Query: Do we need a TLS representative to review this content?

I think this is good as it is, the chapter was originally written by @lauri-piikivi

Would be nice to point at TLS docs. Maybe this as entry point?
https://tls.mbed.org/core-features

Added link to TLS, because this is for app devs code example link serves here the best
3d1cb4b

AnotherButler · 2018-04-11T16:24:56Z

docs/reference/technology/connectivity/cellular.md

+
+Non-IP is a new option for communication over NB-IoT. The device sends messages to an operator messaging service. The server application communicates with the messaging service using a web API. The messaging service allows the device and server application to communicate regardless of their activity windows. The cellular network security services provide security inside the cellular network, from the messaging center to the web application with HTTPS. Because network support for non-IP may vary, the application depends on use case. For wider operation, it needs to support both non-IP and IP for a transition period.
+
+For DTLS and TLS transport security, even if the device maintains its own IP address during power save periods, the address may be changed in the network due to Network Address Translation (NAT). NAT is a mechanism to share the few IPv4 addresses among more users. The NAT address change necessitates renegotiation of the (D)TLS security session. The TLS and DTLS protocols support session ID and session ticket mechanisms to optimize the renegotiation. Both device and (D)TLS server must support the used mechanism.


Query: Who or what may change the address in the network due to NAT?

This chapter was also written by @lauri-piikivi.

DTSL/TLS, cellular IP addressing and NAT is very complex issue. This chapter is intentionally open-ended due to explaining this in details would take a book or two. Even though it's not complete, it's still good to give some note that there are some points to consider.

Can we link to relevant documentation / references?
May also need to point at corresponding standards where this is described/defined.

I guess that IP, NAT, etc. are in general knowledge to the typical readers.

AriParkkila · 2018-04-12T12:02:48Z

@AnotherButler thanks for your review. I guess your comments are now addressed or deliberately moved to the future releases :)

SeppoTakalo · 2018-04-12T13:50:46Z

Please add the technology/connectivity/cellular.md into the docs.json

Perhaps after the IP networking section, just before Mesh

                "title": "Technology",
                "intro": {
                    "type": "markdown",
                    "url": "https://github.com/ARMmbed/Handbook/blob/new_engine/docs/reference/technology/technology.md"
                },
                "sources": [{
                        "type": "markdown",
                        "url": "https://github.com/ARMmbed/Handbook/blob/new_engine/docs/reference/technology/connectivity/connectivity.md"
                    },
                    {
                        "type": "markdown",
                        "url": "https://github.com/ARMmbed/Handbook/blob/new_engine/docs/reference/technology/connectivity/networking.md"
                    },
                    {
here

NOTE: You need to rebase your work on top of new_engine branch in order to see those pages in docs.json

AnotherButler · 2018-04-12T21:04:59Z

Can I make these changes to the live site, too?

SeppoTakalo · 2018-04-13T06:35:06Z

This is relevant for 5.9, so please don't merge to the live site yet.
According to Ari, one of the documented feature is still in feature branch. (Asynchronous cellular API)

AriParkkila · 2018-04-13T07:01:14Z

Link this PR into docs.json under Technology https://github.com/AriParkkila/Handbook/commit/a119acd5db9d995dd3053ec0286c879c6901d58f

There seems to be a warning... probably not due to my change:
WARNING - The page "reference\technology\connectivity\networking.md" contained a hyperlink to "reference\technology\connectivity\quick_start_intro.md" which is not listed in the "pages" configuration.

SeppoTakalo · 2018-04-13T07:50:19Z

What?
Where did you get this warning?

AriParkkila · 2018-04-13T07:52:40Z

That could be because I used mkdocs...

AnotherButler · 2018-04-16T15:11:38Z

It's fine to include documentation about feature-branch code in our contributing section, but we should not include information in the technology section or user APIs until the code is on master.

@AriParkkila On the contributing page, could you please add a section with defined behavior and undefined behavior? Also, are there any potential trouble areas that those porting may need to watch out for?

MarceloSalazar · 2018-04-17T09:56:30Z

docs/reference/technology/connectivity/cellular.md

+### Quick start
+
+There are two phases to Mbed OS connectivity:
+


This seems generic to all IP networking in Mbed OS.
Can we point at the networking section and remove quick-start as it seems irrelevant?

I think it's still good to tell that cellular is quite difficult compared to other IP networking... Quick start emphasises that appdevs should use CellularConnectionFSM. This chapter also has links to our two example applications.

MarceloSalazar · 2018-04-17T09:58:26Z

docs/reference/technology/connectivity/cellular.md

+
+If you want to see code, you can go to our [cellular example](https://github.com/ARMmbed/mbed-os-example-cellular) or 
+our [advanced cellular example](https://github.com/ARMmbed/mbed-os-example-cellular-advanced).
+


Would be nice to say a few words about the examples and guide users to the right one.
Related to this: https://github.com/ARMmbed/mbed-os-example-cellular-advanced/issues/1

Instead of pointing to GH, we should point to teams examples.

MarceloSalazar · 2018-04-17T10:05:44Z

docs/reference/technology/connectivity/cellular.md

+
+Which networking protocol to use depends on multiple factors. Server communication model, power consumption, reliability need and operator support are the biggest factors. 
+
+TCP is a reliable transmission protocol. For long-lived sessions, periodic keep alive messaging is necessary, which places demands on the main power source. For a long-lived TCP connection, the server application can contact the device. Connections can still have long latencies because the device's use of eDRX power optimization affects when it listens for incoming packets. Mbed TLS supports TLS transport security over TCP. Operators may, however, prevent using TCP over NB-IoT due to device deployment and network planning considerations.


Would be nice to point at TLS docs. Maybe this as entry point?
https://tls.mbed.org/core-features

MarceloSalazar · 2018-04-17T10:08:28Z

docs/reference/technology/connectivity/cellular.md

+
+Non-IP is a new option for communication over NB-IoT. The device sends messages to an operator messaging service. The server application communicates with the messaging service using a web API. The messaging service allows the device and server application to communicate regardless of their activity windows. The cellular network security services provide security inside the cellular network, from the messaging center to the web application with HTTPS. Because network support for non-IP may vary, the application depends on use case. For wider operation, it needs to support both non-IP and IP for a transition period.
+
+For DTLS and TLS transport security, even if the device maintains its own IP address during power save periods, the address may be changed in the network due to Network Address Translation (NAT). NAT is a mechanism to share the few IPv4 addresses among more users. The NAT address change necessitates renegotiation of the (D)TLS security session. The TLS and DTLS protocols support session ID and session ticket mechanisms to optimize the renegotiation. Both device and (D)TLS server must support the used mechanism.


Can we link to relevant documentation / references?
May also need to point at corresponding standards where this is described/defined.

MarceloSalazar · 2018-04-17T10:39:45Z

Can we explain CELLULAR_DEVICE and CELLULAR_TARGET macros in detail and behavior when defining them?
There seems to be too much magic going on with this compile-time configuration.

Also, can we explain how to enable a Cellular driver that is not part of Mbed OS?
Not everyone can/want to get their driver in Mbed OS
https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/

SeppoTakalo · 2018-04-19T13:23:09Z

@AriParkkila Ari, are you working towards taking those feedbacks into the documentation?

SeppoTakalo · 2018-04-26T08:04:22Z

docs/reference/contributing/connectivity/CellularInterface.md


-This document provides guidelines and details for setting up a cellular device driver with Mbed OS. Please see the [working principles when working with a cellular C++ API](https://os.mbed.com/docs/latest/reference/network-socket.html) for more information.
+This document provides guidelines and details for setting up a cellular device driver with Mbed OS. Please see the [working principles when working with a cellular C++ API](/docs/development/reference/network-socket.html) for more information.


What does a "working principle" mean?

Are you trying to link to Socket API or Cellular interface page?

If you intented to link to this https://os-doc-builder.test.mbed.com/docs/development/reference/cellular-api.html

then use just cellular-api.html

SeppoTakalo · 2018-04-26T08:29:42Z

docs/reference/contributing/connectivity/CellularInterface.md

@@ -62,7 +33,7 @@ For example,
    },
 ```

-Use standard pin names. A standard naming convention for pin names is required for standard modem pins in your target's **_'targets/TARGET_FAMILY/YOUR_TARGET/PinNames.h'_**. The example below shows the full UART capable modem. If any of these pins is not connected physically, mark it **_'NC'_**. Also indicate pin polarity.
+Use standard pin names. A standard naming convention for pin names is required for standard modem pins in your target's **_'targets/TARGET_FAMILY/YOUR_TARGET/PinNames.h'_**. The example below shows the full UART-capable modem. If any of these pins is not connected physically, mark it **_'NC'_**. Also indicate pin polarity.


What standard?
There is no pin name standard.

Are you trying to say that for modem, you need to map these pin aliases to your target pins?

Can you also change the pin documentation from below.

It has pin MDMRTS = P0_22, // Request to Send which, by TIA/EIA-232-E has updated to be actually RTR - Ready-To-Receive - DTE is ready to receive data from DCE.

See:
https://en.wikipedia.org/wiki/RS-232#Data_and_control_signals

Nowadays people still use the old pin name, but actually mean the new standard. So change the comment after the pin name to reflect its actual use.

SeppoTakalo · 2018-04-26T08:49:51Z

docs/reference/contributing/connectivity/CellularInterface.md

-If the new modem supports PPP mode, then you can use the existing Mbed OS LWIP stack to control the modem when connecting to a network. To use the LWIP stack, set `lwip.ppp-enabled` to true in an application `mbed_app.json`. [UBLOX LISA](https://github.com/ARMmbed/mbed-os/tree/master/features/cellular/framework/targets/UBLOX/LISA_U) is an example of a modem implementation using PPP mode to connect to a network. For example, [mbed-os-example-cellular](https://os.mbed.com/teams/mbed-os-examples/code/mbed-os-example-cellular/) instantiates [EasyCellularConnection class](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_easy_cellular_connection_8h_source.html), which in turn instantiates [CellularConnectionFSM class](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_cellular_connection_f_s_m_8h_source.html). CellularConnectionFSM instantiates classes implementing [the AT command layer](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_a_t___cellular_device_8h_source.html) between the modem and the Mbed OS CPU. For LISA classes [UBLOX_LISA_U](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/UBLOX/LISA_U/UBLOX_LISA_U.h), [UBLOX_LISA_U_CellularNetwork](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/UBLOX/LISA_U/UBLOX_LISA_U_CellularNetwork.h) and [UBLOX_LISA_U_CellularPower](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/UBLOX/LISA_U/UBLOX_LISA_U_CellularPower.h) have been implemented for a modem specific functionality. In the AT command layer, [AT_CellularNetwork](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_a_t___cellular_network_8h_source.html) includes functionality calling [nsapi_ppp_connect()](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/netsocket_2nsapi__ppp_8h_source.html) to start the data call through the PPP pipe.
+##### Providing an implementation using the network stack on the cellular module (AT only mode)
+
+The [QUECTEL_BG96_CellularStack](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/QUECTEL/BG96/QUECTEL_BG96_CellularStack.h) is an example of a modem-specific AT command cellular stack implementation. For example, [mbed-os-example-cellular](https://os.mbed.com/teams/mbed-os-examples/code/mbed-os-example-cellular/) instantiates the [EasyCellularConnection class](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_easy_cellular_connection_8h_source.html), which in turn instantiates the [CellularConnectionFSM class](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_cellular_connection_f_s_m_8h_source.html). CellularConnectionFSM instantiates classes implementing [the AT command layer](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_a_t___cellular_device_8h_source.html) between the modem and the Mbed OS CPU. For the [QUECTEL BG96](https://github.com/ARMmbed/mbed-os/tree/master/features/cellular/framework/targets/QUECTEL/BG96) classes, [QUECTEL_BG96](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/QUECTEL/BG96/QUECTEL_BG96.h), [QUECTEL_BG96_CellularStack](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/QUECTEL/BG96/QUECTEL_BG96_CellularStack.h) and [QUECTEL_BG96_CellularNetwork](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/QUECTEL/BG96/QUECTEL_BG96_CellularNetwork.h) have been implemented for a modem specific functionality. QUECTEL_BG96_CellularStack implements a QUECTEL BG96 specific AT command stack for socket data handling.


Sounds a lot like Quectel BG96 adverticement.
Can this be made generic?

You do not need to refer to any specific hardware in oder to tell that EasyCellularConnection will instantiate the target specific class and it will initialise the AT command parser and serial port.

Then "For example implementation of these two driver classes, look for features/cellular/framework/targets directory tree in Mbed OS"

+1 on Seppo's comment

In addition, the information here is very packed and hard to read.
Can we split and restructure this?

SeppoTakalo · 2018-04-26T08:54:11Z

docs/reference/contributing/connectivity/CellularInterface.md

+
+##### Providing an implementation using the Mbed OS provided network stacks (PPP mode)
+
+If the new modem supports PPP mode, then you can use the existing Mbed OS LWIP stack to control the modem when connecting to a network. To use the LWIP stack, set `lwip.ppp-enabled` to true in an application's `mbed_app.json`. [UBLOX PPP](https://github.com/ARMmbed/mbed-os/tree/master/features/cellular/framework/targets/UBLOX/PPP) is an example of a modem implementation using PPP mode to connect to a network. For example, [mbed-os-example-cellular](https://os.mbed.com/teams/mbed-os-examples/code/mbed-os-example-cellular/) instantiates [EasyCellularConnection class](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_easy_cellular_connection_8h_source.html), which in turn instantiates [CellularConnectionFSM class](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_cellular_connection_f_s_m_8h_source.html). CellularConnectionFSM instantiates classes implementing [the AT command layer](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_a_t___cellular_device_8h_source.html) between the modem and the Mbed OS CPU. For PPP classes [UBLOX_PPP](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/UBLOX/PPP/UBLOX_PPP.h), [UBLOX_PPP_CellularNetwork](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/UBLOX/PPP/UBLOX_PPP_CellularNetwork.h) and [UBLOX_PPP_CellularPower](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/UBLOX/PPP/UBLOX_PPP_CellularPower.h) have been implemented for a modem specific functionality. In the AT command layer, [AT_CellularNetwork](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_a_t___cellular_network_8h_source.html) includes functionality calling [nsapi_ppp_connect()](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/netsocket_2nsapi__ppp_8h_source.html) to start the data call through the PPP pipe.


Mbed OS LWIP stack to control the modem when"

No, the LwIP does not control the modem. How about "You can use LwIP stack to handle sockets and IP connectivity for your modem after connected to network"

And again: Target specific, but not that much. I would still like to see this call path, and initialisation sequences written in generic, not target specific ways. Then, after explaining, you can tell which drivers in the tree implement the call path you described.

SeppoTakalo · 2018-04-26T08:56:16Z

docs/reference/contributing/connectivity/CellularInterface.md

- 	mbed test -n "mbed-os-features-cellular-tests-cellular-cellular_all" -m YOURMACHINE -t YOURCOMPILER --app-config YOURCONFIG.json
- 	```
+    ```
+    mbed test -n "mbed-os-features-cellular-tests-*" -m YOURMACHINE -t YOURCOMPILER --app-config YOURCONFIG.json


how about TARGET and TOOLCHAIN?

It is not "your machine" that runs the tests.

We have always used word "target" to specify the build target/board.
Also we have always used word "toolchain" to specify one of ARM, GCC_ARM or IAR toolchains.

YOURMACHINE and YOURCOMPILER should be replaced. See Mbed CLI terminology.

SeppoTakalo · 2018-04-26T09:54:38Z

docs/reference/technology/connectivity/cellular.md

+Mbed OS cellular is the preferred choice of building applications for [Mbed Cloud](https://cloud.mbed.com/docs/) and cellular IoT solutions. Key features of Mbed OS cellular include:
+
+- Compatibility with 3GPP TS 27.007 and 27.005.
+- OMA Lightweight M2M Client enabler.


OMA Lightweight M2M Client enabler.

Why this is relevant?
Any connectivity is Client enabler. Especially if its IP based.

SeppoTakalo · 2018-04-26T09:58:33Z

docs/reference/technology/connectivity/cellular.md

+
+Mbed OS already supports several Mbed Enabled boards with on-board cellular modules out of the box. Because Mbed OS is an open source platform, developers can enable support for new cellular boards with our adaptation framework. Please see our [cellular porting guide](/docs/development/reference/contributing-connectivity.html#cellularinterface) for more information.
+
+### Quick start


This dead-simple example is what I like. But it actually belongs to CellularInterface.md

Yes, this could probably be in the both. But, I think PORTING readers are familiar with API/Technology pages but not vice versa so I guess it's good to keep this here.

MarceloSalazar

Overall looking good, but there are a few items that should be reviewed and addressed.

MarceloSalazar · 2018-05-03T12:25:40Z

docs/reference/contributing/connectivity/CellularInterface.md

+If none of the existing modems is compatible with the new modem, then create new modem implementation under ``features/cellular/framework/targets``. A device class inheriting [AT_CellularDevice](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_a_t___cellular_device_8h_source.html) is a minimum. [QUECTEL_BG96](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/QUECTEL/BG96/QUECTEL_BG96.h) is an example of the device class.
+
+### Modifying cellular APIs
+


AFAIK APIs are not intented to be modified.
Do you mean, extending the API by inheriting from Cellular class?

MarceloSalazar · 2018-05-03T12:27:39Z

docs/reference/contributing/connectivity/CellularInterface.md

-If the new modem supports PPP mode, then you can use the existing Mbed OS LWIP stack to control the modem when connecting to a network. To use the LWIP stack, set `lwip.ppp-enabled` to true in an application `mbed_app.json`. [UBLOX LISA](https://github.com/ARMmbed/mbed-os/tree/master/features/cellular/framework/targets/UBLOX/LISA_U) is an example of a modem implementation using PPP mode to connect to a network. For example, [mbed-os-example-cellular](https://os.mbed.com/teams/mbed-os-examples/code/mbed-os-example-cellular/) instantiates [EasyCellularConnection class](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_easy_cellular_connection_8h_source.html), which in turn instantiates [CellularConnectionFSM class](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_cellular_connection_f_s_m_8h_source.html). CellularConnectionFSM instantiates classes implementing [the AT command layer](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_a_t___cellular_device_8h_source.html) between the modem and the Mbed OS CPU. For LISA classes [UBLOX_LISA_U](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/UBLOX/LISA_U/UBLOX_LISA_U.h), [UBLOX_LISA_U_CellularNetwork](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/UBLOX/LISA_U/UBLOX_LISA_U_CellularNetwork.h) and [UBLOX_LISA_U_CellularPower](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/UBLOX/LISA_U/UBLOX_LISA_U_CellularPower.h) have been implemented for a modem specific functionality. In the AT command layer, [AT_CellularNetwork](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_a_t___cellular_network_8h_source.html) includes functionality calling [nsapi_ppp_connect()](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/netsocket_2nsapi__ppp_8h_source.html) to start the data call through the PPP pipe.
+##### Providing an implementation using the network stack on the cellular module (AT only mode)
+
+The [QUECTEL_BG96_CellularStack](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/QUECTEL/BG96/QUECTEL_BG96_CellularStack.h) is an example of a modem-specific AT command cellular stack implementation. For example, [mbed-os-example-cellular](https://os.mbed.com/teams/mbed-os-examples/code/mbed-os-example-cellular/) instantiates the [EasyCellularConnection class](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_easy_cellular_connection_8h_source.html), which in turn instantiates the [CellularConnectionFSM class](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_cellular_connection_f_s_m_8h_source.html). CellularConnectionFSM instantiates classes implementing [the AT command layer](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_a_t___cellular_device_8h_source.html) between the modem and the Mbed OS CPU. For the [QUECTEL BG96](https://github.com/ARMmbed/mbed-os/tree/master/features/cellular/framework/targets/QUECTEL/BG96) classes, [QUECTEL_BG96](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/QUECTEL/BG96/QUECTEL_BG96.h), [QUECTEL_BG96_CellularStack](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/QUECTEL/BG96/QUECTEL_BG96_CellularStack.h) and [QUECTEL_BG96_CellularNetwork](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/QUECTEL/BG96/QUECTEL_BG96_CellularNetwork.h) have been implemented for a modem specific functionality. QUECTEL_BG96_CellularStack implements a QUECTEL BG96 specific AT command stack for socket data handling.


+1 on Seppo's comment

In addition, the information here is very packed and hard to read.
Can we split and restructure this?

MarceloSalazar · 2018-05-03T12:28:03Z

docs/reference/contributing/connectivity/CellularInterface.md

+
+##### Providing an implementation using the Mbed OS provided network stacks (PPP mode)
+
+If the new modem supports PPP mode, then you can use the existing Mbed OS LWIP stack to control the modem when connecting to a network. To use the LWIP stack, set `lwip.ppp-enabled` to true in an application's `mbed_app.json`. [UBLOX PPP](https://github.com/ARMmbed/mbed-os/tree/master/features/cellular/framework/targets/UBLOX/PPP) is an example of a modem implementation using PPP mode to connect to a network. For example, [mbed-os-example-cellular](https://os.mbed.com/teams/mbed-os-examples/code/mbed-os-example-cellular/) instantiates [EasyCellularConnection class](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_easy_cellular_connection_8h_source.html), which in turn instantiates [CellularConnectionFSM class](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_cellular_connection_f_s_m_8h_source.html). CellularConnectionFSM instantiates classes implementing [the AT command layer](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_a_t___cellular_device_8h_source.html) between the modem and the Mbed OS CPU. For PPP classes [UBLOX_PPP](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/UBLOX/PPP/UBLOX_PPP.h), [UBLOX_PPP_CellularNetwork](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/UBLOX/PPP/UBLOX_PPP_CellularNetwork.h) and [UBLOX_PPP_CellularPower](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/UBLOX/PPP/UBLOX_PPP_CellularPower.h) have been implemented for a modem specific functionality. In the AT command layer, [AT_CellularNetwork](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_a_t___cellular_network_8h_source.html) includes functionality calling [nsapi_ppp_connect()](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/netsocket_2nsapi__ppp_8h_source.html) to start the data call through the PPP pipe.


Similar comment to above.
The information here is very packed and hard to read.
Can we split and restructure this?

MarceloSalazar · 2018-05-03T12:30:49Z

docs/reference/technology/connectivity/cellular.md

+You can browse `CellularTargets.h` file to find out if your <manufacturer-module> is already supported, or if you can adapt some existing driver for your needs. You need to change the pin-names above to actual pins, such as D0 and D1, according to your Mbed target. You may also need to define MDMRTS and MDMCTS pins if you have RTS/CTS connected on UART.
+
+### Cellular APIs
+


I'm wondering if this API section should be moved to here:
docs/reference/api/connectivity/networksocket/CellularInterface.md

MarceloSalazar · 2018-05-09T17:28:20Z

docs/reference/technology/connectivity/cellular.md

+<span class="images">![](https://s3-us-west-2.amazonaws.com/mbed-os-docs-images/api-cellular-quick-start.png)<span>Figure 2. Connect to cellular network and open a socket</span></span>
+
+If you want to see code, you can go to our [cellular example](https://github.com/ARMmbed/mbed-os-example-cellular).
+


We should probably use this one:
https://os.mbed.com/teams/mbed-os-examples/code/mbed-os-example-cellular/

MarceloSalazar · 2018-05-09T17:38:11Z

docs/reference/technology/connectivity/cellular.md

+
+### Class reference
+
+[![View code](https://www.mbed.com/embed/?type=library)](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/classmbed_1_1_cellular_device.html)


Shouldn't we move the API / Class reference to the API section?
https://os.mbed.com/docs/v5.8/reference/cellular-api.html

I think that's mostly about socket layer, while cellular device is more about connectivity...

MarceloSalazar · 2018-05-09T17:45:29Z

docs/reference/technology/connectivity/cellular.md

+If you use an Mbed OS target and a separate cellular module via a serial line (UART), you need to configure in your `mbed_app.json` configuration file which cellular module to use and which UART pins are connected between the Mbed OS target board and the cellular module:
+
+    `"CELLULAR_DEVICE=<manufacturer-module>", "MDMRXD=<rx-pin-name>", "MDMTXD=<tx-pin-name>"`
+


This is very useful info. Can we be a bit more explicit on exactly where you expect people to add this info?
For example something like (not sure it's correct):

{ "macros": [ "CELLULAR_DEVICE=<manufacturer-module>", "MDMRXD=<rx-pin-name>", "MDMTXD=<tx-pin-name>" ] }

AriParkkila · 2018-05-21T10:24:45Z

@AnotherButler could you tell more about what you mean by "On the contributing page, could you please add a section with defined behavior and undefined behavior? Also, are there any potential trouble areas that those porting may need to watch out for?"

Complete initial copy edit for formatting, linking best practices and grammar changes.

Complete initial copy edit for active voice, American spelling, formatting and grammar.

…he modem

AriParkkila · 2018-05-22T11:07:59Z

Updated review comments in #6852088

SeppoTakalo

From my point of view the content now looks OK for 5.9

AnotherButler · 2018-05-23T15:21:43Z

@AriParkkila If you look at the Wi-Fi contributing page (https://os-doc-builder.test.mbed.com/docs/development/reference/wifi-port.html), you can see there's an Assumptions section with defined and undefined behavior. I was just asking if there's any such behavior for this API.

AnotherButler · 2018-05-23T15:21:58Z

@MarceloSalazar Have your concerns been addressed?

MarceloSalazar · 2018-05-30T15:55:55Z

Sorry for late reply - the documents are good to go for OOB.
@AnotherButler let's get this merged asap.

AriParkkila mentioned this pull request Apr 10, 2018

Technology/Connectivity refactoring #470

Merged

AnttiKauppila reviewed Apr 10, 2018

View reviewed changes

AnotherButler reviewed Apr 11, 2018

View reviewed changes

MarceloSalazar reviewed Apr 17, 2018

View reviewed changes

SeppoTakalo suggested changes Apr 26, 2018

View reviewed changes

AnotherButler requested a review from ashok-rao April 26, 2018 14:22

MarceloSalazar suggested changes May 3, 2018

View reviewed changes

MarceloSalazar reviewed May 9, 2018

View reviewed changes

MarceloSalazar suggested changes May 9, 2018

View reviewed changes

Ari Parkkila and others added 10 commits May 22, 2018 10:40

Cellular technology overview and porting updated

d8f2780

Review update in cellular porting

ef8d403

Copy edit CellularInterface.md

16448f1

Complete initial copy edit for formatting, linking best practices and grammar changes.

Copy edit cellular.md

b7bd6a0

Complete initial copy edit for active voice, American spelling, formatting and grammar.

Cellular porting changed link to docs and updated LISA_PPP

9d5b47e

Cellular: Updated link to OMA

6528bb9

Cellular: Updated description about IP stack selection

fd147d5

Cellular: Removed Non-IP socket chapter

c5822d4

Cellular: clarified that An application gives eDRX configuration to t…

bb61a6e

…he modem

Cellular: Added link to cellular at docs.json / technology

bd0feae

Ari Parkkila added 2 commits May 22, 2018 10:40

Cellular: Added description about how modem is configured

0b09992

Cellular: Updated review comments

6852088

SeppoTakalo approved these changes May 23, 2018

View reviewed changes

MarceloSalazar self-requested a review May 30, 2018 15:56

MarceloSalazar approved these changes May 30, 2018

View reviewed changes

AnotherButler merged commit 0123f25 into ARMmbed:new_engine May 30, 2018


		Setup for some predefined targets is available in [CellularTargets.h](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_cellular_targets_8h_source.html). For a new target, you need to modify `CellularTargets.h`. In `CellularTargets.h`, you need to specify a cellular device in addition to UART pins connecting the Mbed OS CPU to the modem. For example, if the new device MY_NEW_TARGET defined above in the "Adding modem target support" chapter is connected with QUECTEL BG96, you would need the following changes marked in between `// !!!!` in `CellularTargets.h`:
		Setup for some predefined targets is available in [CellularTargets.h](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_cellular_targets_8h_source.html). For a new target, you need to modify `CellularTargets.h` by specifying a cellular device in addition to UART pins connecting the Mbed OS CPU to the modem. For example, if the new device `MY_NEW_TARGET` defined in the "Adding modem target support" section is connected with QUECTEL BG96, you would need the following changes marked in between `// !!!!` in `CellularTargets.h`:

		@@ -118,38 +89,50 @@ Setup for some predefined targets is available in [CellularTargets.h](https://os

		If none of the existing modems is compatible with the new modem, then create new modem implementation under [features/cellular/framework/targets](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets). A device class inheriting [AT_CellularDevice](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_a_t___cellular_device_8h_source.html) is a minimum. [QUECTEL_BG96](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/QUECTEL/BG96/QUECTEL_BG96.h) is an example of the device class. You can create additional overlapping functionality for everything that is available in [features/cellular/framework/targets](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets).


		3GPP TS 27.007 and 27.005 are standards to provide consistent cellular network data connectivity and SMS over an AT command interface for cellular devices, regardless of the underlying cellular network.

		OMA Lightweight M2M is a protocol from the Open Mobile Alliance for IoT device management. The Mbed OS cellular API provides core functionality to implement the LWM2M Client. For more information, please see [OMA LWM2M](https://en.wikipedia.org/wiki/OMA_LWM2M) and [OMA LwM2M ConnMgmt](http://www.openmobilealliance.org/release/LWM2M_CONNMGMT/V1_0-20170314-A/OMA-TS-LWM2M_ConnMgmt-V1_0-20170314-A.pdf).


		#### PPP mode with the LWIP stack on Mbed OS

		In PPP mode, the LWIP stack is linked as a part of the Mbed OS application. Sockets are implemented on the LWIP stack, and the modem is used over a Point-to-Point Protocol (PPP) link as a plain data pipe.


		#### AT mode with the IP stack on the modem

		In AT mode, the modem's internal IP stack is used over an AT link. Sockets are part of the IP stack, so AT commands are used to control sockets. Socket AT commands are modem specific, and you need to implement them on the Mbed OS side within a `CellularStack` class. You can browse `CellularStack` under the cellular/targets folder to learn how your cellular module supports AT sockets.


		### Non-IP optimizations

		The Mbed OS cellular API has also been planned to support non-IP communication in the near future. You need to make two changes when using non-IP in your application:


		This feature serves devices that need smaller latencies. A connection is kept open all the time, but the modem achieves a sleep state between the reception times. The data connection, if using IPv4, may need periodic keep alive messages to keep the network address translation mapping valid.

		eDRX configuration is given to the modem. It is negotiated with the network, and the time accepted by the network may differ from the requested time. Availability of this optimization depends on the cellular network.


		Which networking protocol to use depends on multiple factors. Server communication model, power consumption, reliability need and operator support are the biggest factors.

		TCP is a reliable transmission protocol. For long-lived sessions, periodic keep alive messaging is necessary, which places demands on the main power source. For a long-lived TCP connection, the server application can contact the device. Connections can still have long latencies because the device's use of eDRX power optimization affects when it listens for incoming packets. Mbed TLS supports TLS transport security over TCP. Operators may, however, prevent using TCP over NB-IoT due to device deployment and network planning considerations.


		Non-IP is a new option for communication over NB-IoT. The device sends messages to an operator messaging service. The server application communicates with the messaging service using a web API. The messaging service allows the device and server application to communicate regardless of their activity windows. The cellular network security services provide security inside the cellular network, from the messaging center to the web application with HTTPS. Because network support for non-IP may vary, the application depends on use case. For wider operation, it needs to support both non-IP and IP for a transition period.

		For DTLS and TLS transport security, even if the device maintains its own IP address during power save periods, the address may be changed in the network due to Network Address Translation (NAT). NAT is a mechanism to share the few IPv4 addresses among more users. The NAT address change necessitates renegotiation of the (D)TLS security session. The TLS and DTLS protocols support session ID and session ticket mechanisms to optimize the renegotiation. Both device and (D)TLS server must support the used mechanism.

		### Quick start

		There are two phases to Mbed OS connectivity:


		If you want to see code, you can go to our [cellular example](https://github.com/ARMmbed/mbed-os-example-cellular) or
		our [advanced cellular example](https://github.com/ARMmbed/mbed-os-example-cellular-advanced).


		This document provides guidelines and details for setting up a cellular device driver with Mbed OS. Please see the [working principles when working with a cellular C++ API](https://os.mbed.com/docs/latest/reference/network-socket.html) for more information.
		This document provides guidelines and details for setting up a cellular device driver with Mbed OS. Please see the [working principles when working with a cellular C++ API](/docs/development/reference/network-socket.html) for more information.


		##### Providing an implementation using the Mbed OS provided network stacks (PPP mode)

		If the new modem supports PPP mode, then you can use the existing Mbed OS LWIP stack to control the modem when connecting to a network. To use the LWIP stack, set `lwip.ppp-enabled` to true in an application's `mbed_app.json`. [UBLOX PPP](https://github.com/ARMmbed/mbed-os/tree/master/features/cellular/framework/targets/UBLOX/PPP) is an example of a modem implementation using PPP mode to connect to a network. For example, [mbed-os-example-cellular](https://os.mbed.com/teams/mbed-os-examples/code/mbed-os-example-cellular/) instantiates [EasyCellularConnection class](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_easy_cellular_connection_8h_source.html), which in turn instantiates [CellularConnectionFSM class](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_cellular_connection_f_s_m_8h_source.html). CellularConnectionFSM instantiates classes implementing [the AT command layer](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_a_t___cellular_device_8h_source.html) between the modem and the Mbed OS CPU. For PPP classes [UBLOX_PPP](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/UBLOX/PPP/UBLOX_PPP.h), [UBLOX_PPP_CellularNetwork](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/UBLOX/PPP/UBLOX_PPP_CellularNetwork.h) and [UBLOX_PPP_CellularPower](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/UBLOX/PPP/UBLOX_PPP_CellularPower.h) have been implemented for a modem specific functionality. In the AT command layer, [AT_CellularNetwork](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_a_t___cellular_network_8h_source.html) includes functionality calling [nsapi_ppp_connect()](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/netsocket_2nsapi__ppp_8h_source.html) to start the data call through the PPP pipe.


		Mbed OS already supports several Mbed Enabled boards with on-board cellular modules out of the box. Because Mbed OS is an open source platform, developers can enable support for new cellular boards with our adaptation framework. Please see our [cellular porting guide](/docs/development/reference/contributing-connectivity.html#cellularinterface) for more information.

		### Quick start

		If none of the existing modems is compatible with the new modem, then create new modem implementation under ``features/cellular/framework/targets``. A device class inheriting [AT_CellularDevice](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/_a_t___cellular_device_8h_source.html) is a minimum. [QUECTEL_BG96](https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/QUECTEL/BG96/QUECTEL_BG96.h) is an example of the device class.

		### Modifying cellular APIs

		You can browse `CellularTargets.h` file to find out if your <manufacturer-module> is already supported, or if you can adapt some existing driver for your needs. You need to change the pin-names above to actual pins, such as D0 and D1, according to your Mbed target. You may also need to define MDMRTS and MDMCTS pins if you have RTS/CTS connected on UART.

		### Cellular APIs

		<span class="images">![](https://s3-us-west-2.amazonaws.com/mbed-os-docs-images/api-cellular-quick-start.png)<span>Figure 2. Connect to cellular network and open a socket</span></span>

		If you want to see code, you can go to our [cellular example](https://github.com/ARMmbed/mbed-os-example-cellular).


		### Class reference

		[![View code](https://www.mbed.com/embed/?type=library)](https://os-doc-builder.test.mbed.com/docs/development/mbed-os-api-doxy/classmbed_1_1_cellular_device.html)

		If you use an Mbed OS target and a separate cellular module via a serial line (UART), you need to configure in your `mbed_app.json` configuration file which cellular module to use and which UART pins are connected between the Mbed OS target board and the cellular module:

		`"CELLULAR_DEVICE=<manufacturer-module>", "MDMRXD=<rx-pin-name>", "MDMTXD=<tx-pin-name>"`

Cellular technology overview and porting updated #489

Cellular technology overview and porting updated #489

Uh oh!

Conversation

AriParkkila commented Apr 9, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AnotherButler left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AriParkkila commented Apr 12, 2018

Uh oh!

SeppoTakalo commented Apr 12, 2018

Uh oh!

AnotherButler commented Apr 12, 2018

Uh oh!

SeppoTakalo commented Apr 13, 2018

Uh oh!

AriParkkila commented Apr 13, 2018

Uh oh!

SeppoTakalo commented Apr 13, 2018

Uh oh!

AriParkkila commented Apr 13, 2018

Uh oh!

AnotherButler commented Apr 16, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment