Telit LE910 and ME910

[Alex-EEE]

Description

Are there any plans to add support for Telit's LE910 ( 4G ) and ME910 ( Cat-M1 narrowband IoT ) modules?

Issue request type

[ ] Question
[ x ] Enhancement
[ ] Bug

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-143

[AriParkkila]

@Alex-EEE assuming that you are using PPP mode (that's Mbed OS internal LWIP stack), you can use e.g. TELIT_HE910 driver.

I tested with LE910-EUG and at least GSM network connection was fine, here is my setup:

• Connect K64F to LE910
• mbed compile -m K64F -DCELLULAR_DEVICE=TELIT_HE910 -DMDMRXD=D0 -DMDMTXD=D1 -DMDMRTS=NC -DMDMCTS=NC
• Copy binary to K64F

If you want to enable 4G/Cat-M1, change TELIT_HE910_CellularNetwork::has_registration to return true also on C_EREG.

I guess @paspik can comment about support.

[Alex-EEE]

Fantastic, thanks for the look and code tweaks!

[0Grit]

@Alex-EEE Did you ever end up getting @AriParkkila's recommended action to work?

[Alex-EEE]

I have yet to try it. We'll probably be looking at cell drivers next quarter, so whenever we do, I'll post on here any additional steps needed

[0Grit]

Can you re-open the issue?

[Alex-EEE]

Sure. Re opening b/c I haven't tried this fix yet.

[0Grit]

Thanks @Alex-EEE I'd like to see it remain open until both parts are officially supported in the OS.

[0Grit]

@dlfryar We can probably sort it out internally but wanted to note this doesn't seem to 'just work'.
Also can this issue be unresolved in jira until official support for these parts are added to the OS?

If we find a solution or implement ourselves we'll be happy to do an MR.

Edit: For others note, target MCU is NRF52840.

[dlfryar-zz]

@dlfryar We can probably sort it out internally but wanted to note this doesn't seem to 'just work'.
Also can this issue be unresolved in jira until official support for these parts are added to the OS?

If we find a solution or implement ourselves we'll be happy to do an MR.

Edit: For others note, target MCU is NRF52840.

What's the issue you are seeing? Can you post a build or run log?

Are you able to build using @AriParkkila instructions above?

[trowbridgec]

@dlfryar We were able to get around this and get the example to work, but it required a few tweaks for the ME910:

• Add AT_CellularBase::AT_CGDATA to the list of unsupported features as apparently the ME910 doesn't support that command (see the AT command reference doc for more info).
• Remove AT_CellularBase::AT_CGAUTH from the list of unsupported features since the ME910 does support this command (again, see the ME910 AT command reference doc).
• Add @AriParkkila's fix from above.
• For the nRF52840 (which we're using in our design), disable CRYPTOCELL.

[dlfryar-zz]

It looks like CGDATA and CGAUTH are both optional per 3GPP TS 27.007.

@AriParkkila any guidance on how similar modules should be supported through the driver when they don't support optional command implementations?

[0Grit]

Tests Pass. Should we just wait till the cellular refactor releases to make MR?

[dlfryar-zz]

Adding @jarvte to get additional feedback.

I believe cellular changes slated for 5.12 are API refinements. I don't believe they would impact the driver with regard to supported commands. Is there some other refactor you are referring to?

[0Grit]

#9568
I assumed breaking change might mean we'd need to make some accomodations.

[dlfryar-zz]

Looks like it's already merged so a new pull request would line up with that work. You can add @jarvte and @AriParkkila to the PR for visibility.

[0Grit]

We are operating off 5.11.3. Expect an MR post release of 5.12.

[0xc0170]

cc @ARMmbed/mbed-os-wan

[0Grit]

Any further insight as to why we needed to disable cryptocell?

[0Grit]

@maclobdell @ARMmbed/mbes-os-wan

We have a working-ish implementation for ME910 but are struggling at each step.

Currently having trouble with maintaining connection to Pelion using PSM mode.
My thinking is that UDP would be the preferable transport in this scenario?
LWM2M Registration lifetime, psm, and coap settings I would assume are pretty important to get right.

@trowbridgec can provide more accurate details if needed.

[hasnainvirk]

It looks like CGDATA and CGAUTH are both optional per 3GPP TS 27.007.

@AriParkkila any guidance on how similar modules should be supported through the driver when they don't support optional command implementations?

The current layout of the cellular support suggests that at the time of construction of the driver for the modem, a construct of certain properties is built and fed to the AT_CellularBase object. Please check the code out here https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/TELIT/HE910/TELIT_HE910.cpp#L24
This tells the controller layer what the modem is capable of. I assume LE910 and ME910 differ in specs from HE910 a bit (haven't read the data sheet though) . If that's the case, LE910 and ME910 could potentially come as separate targets in the tree. Please note that the HE910 may work if you just happen to use a subset of those properties which happen to be present on LE910 or ME910.

One way of achieving harmony could be to come up with a single target, say, X910 and then based upon compile time flag or a run time flag we could pick up what modem is intended to be used and then that would serve as the measure stick to set correct properties.

I think another thing that we are missing in most of our drivers is proper overrides for power up sequences and pin polarity settings. We did try to add such overrides in EC2X series modem drivers https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/QUECTEL/EC2X/QUECTEL_EC2X.h#L34

[hasnainvirk]

@maclobdell @ARMmbed/mbes-os-wan

We have a working-ish implementation for ME910 but are struggling at each step.

Currently having trouble with maintaining connection to Pelion using PSM mode.
My thinking is that UDP would be the preferable transport in this scenario?
LWM2M Registration lifetime, psm, and coap settings I would assume are pretty important to get right.

@trowbridgec can provide more accurate details if needed.

TCP is certainly going to be problematic with PSM theoretically. The sleep time is characterized by the difference of two network or device initiated timers 'T3324 Active Timer' and 'T3412 Extended periodic TAU (tracking area update) Timer'. I am not sure what would be the value of this diff in your case and if it would have any impact on your setup. But theoretically, its quite possible if the time diff is too short. This may not be a problem in case of handshake (as it would be rather quick X RTTs) but maintaining connection state may become difficult in case of long sleeping periods.
@yogpan01 Can shed more light on the LWM2M registration life span and CoAP settings. If your application sends a keep alive sort of message then it covers the case of registration life span. Other way around is to set registration life span larger than the period of your app. For PSM settings you may need to dig through. The timers mentioned above will drive the way you perform PSM.

[40Grit]

@hasnainvirk thanks!

Any insight regarding PPP versus AT mode and PSM?

[hasnainvirk]

@40Grit For PSM, it shouldn't matter what mode you pick given that you don't turn-off modem, i.e., the modem goes into a deeper sleep level (lowest possible power state but not shutdown state). Some data sheets suggest that while into low power mode, modems can still respond to AT commands. So I would argue that the PPP connection between modem and LWIP should retain its state even in low power mode. Now in PSM mode the attach state is preserved so when activity is needed, i.e., the modem sends a message or a tracking update, it just does it, no re-attach or a new dial-up (in case of PPP) needed.
The only benefit of AT mode over PPP is the RAM and ROM footprint (using LWIP brings in its costs).

[40Grit]

@hasnainvirk Any way to use PPP mode and still send AT commands without losing connection?

Probably varies per module but in this case we see the ME910 losing connection when switching between the two.

[hasnainvirk]

@40Grit It's not possible to send AT commands when you are in PPP mode. Many modems will chuck your connection to the ground if you try to send any AT command. Some may just send a BUSY signal. You can check that if the modem shuts down your PPP connection by monitoring the DCD pin if available. When the modem hangs up on you, DCD pin will wriggle (high or low depending upon the modem).

[hasnainvirk]

@40Grit I assume you want to switch between the modes to retrieve SMS, is that so ?

[0Grit]

@hasnainvirk yes that is one of the use cases. We were also thinking it would be useful to check on certain parameters settings of the ME910 module form time to time.

I suppose it isn't a huge deal to close connection to Pelion and then just re-register after getting what is needed.

Our thinking was that any TCP socket would most certainly be lost, but maybe there would be a way to still maintain COAP UDP connection through an interruption of PPP connectivity.

[hasnainvirk]

If you add RI pin to your driver construction, you may be able to add a URC to handle SMS. Then RI can tell you when to switch to command mode and handle your SMS. I hope there are options while setting up URC to block the calls and allow only SMSs. Yeah in case of UDP it should be alright. Please note that you may get a different IP address. That means renegotiation with Pelion. Again, @yogpan01 can tell you more but I think now a days Pelion Client can work without DTLS handshake (which is the time and power consuming part). I think this is a feature in DTLS v1.3

[trowbridgec]

The current layout of the cellular support suggests that at the time of construction of the driver for the modem, a construct of certain properties is built and fed to the AT_CellularBase object. Please check the code out here https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/TELIT/HE910/TELIT_HE910.cpp#L24
This tells the controller layer what the modem is capable of. I assume LE910 and ME910 differ in specs from HE910 a bit (haven't read the data sheet though) . If that's the case, LE910 and ME910 could potentially come as separate targets in the tree. Please note that the HE910 may work if you just happen to use a subset of those properties which happen to be present on LE910 or ME910.

@hasnainvirk Thank you for your clarifications. We did end up having to change a couple of the properties to match what's available in the ME910 vs. the HE910, but it was relatively straightforward after reading through the datasheet. We also wrote our own power up sequences, but I'd think that would be expected.

Our motivation for sending AT commands while the PPP connection is active was actually to be able to send (not retrieve) SMS messages. I'm not sure if that makes any difference though. I saw mentions of people creating a separate context (cid) to use for sending SMS messages, but that seemed to require multiple UART connections to the modem which we don't have. Our workaround was to trigger a disconnect, send the SMS message, and then trigger a reconnect, and it has seemed to work out alright so far. If you have any better suggestions, we'd be happy to hear them.

As far as PSM, we seem to see the underlying LWIP stack signaling that the PPP connection was lost, and after that, it is unusable to the Pelion client. Maybe it's a matter of adjusting the T timer to appropriate values so that the connection stays open (and move to UDP as well)?

Here's an example of the traces we see when the PPP connection drops out (presumably because the PSM timer kicked in):

[INFO][LPPP]: status_cb: Connection lost
[DBG ][CELL]: ppp_status_cb: event 0, ptr 2

[hasnainvirk]

The current layout of the cellular support suggests that at the time of construction of the driver for the modem, a construct of certain properties is built and fed to the AT_CellularBase object. Please check the code out here https://github.com/ARMmbed/mbed-os/blob/master/features/cellular/framework/targets/TELIT/HE910/TELIT_HE910.cpp#L24
This tells the controller layer what the modem is capable of. I assume LE910 and ME910 differ in specs from HE910 a bit (haven't read the data sheet though) . If that's the case, LE910 and ME910 could potentially come as separate targets in the tree. Please note that the HE910 may work if you just happen to use a subset of those properties which happen to be present on LE910 or ME910.

@hasnainvirk Thank you for your clarifications. We did end up having to change a couple of the properties to match what's available in the ME910 vs. the HE910, but it was relatively straightforward after reading through the datasheet. We also wrote our own power up sequences, but I'd think that would be expected.

Our motivation for sending AT commands while the PPP connection is active was actually to be able to send (not retrieve) SMS messages. I'm not sure if that makes any difference though. I saw mentions of people creating a separate context (cid) to use for sending SMS messages, but that seemed to require multiple UART connections to the modem which we don't have. Our workaround was to trigger a disconnect, send the SMS message, and then trigger a reconnect, and it has seemed to work out alright so far. If you have any better suggestions, we'd be happy to hear them.

As far as PSM, we seem to see the underlying LWIP stack signaling that the PPP connection was lost, and after that, it is unusable to the Pelion client. Maybe it's a matter of adjusting the T timer to appropriate values so that the connection stays open (and move to UDP as well)?

Here's an example of the traces we see when the PPP connection drops out (presumably because the PSM timer kicked in):

[INFO][LPPP]: status_cb: Connection lost
[DBG ][CELL]: ppp_status_cb: event 0, ptr 2

@trowbridgec If your modem supports software MUX, it may be possible to multiplex two separate contexts (say one in command mode and another in data mode) on the same UART, i.e., multiple file handles. Other case of having multiple UARTs is already looked upon by you. @AriParkkila can assist you more with AT MUX. I haven't played around much with the new code base. I had been involved with this project in ancient times. :) I will try to study this from code perspective and try to dig more information from the data sheets.

[hasnainvirk]

@trowbridgec By the way, do you have a link for your fork where you are working ? Are you going to contribute or is your work in stealth mode ?

[trowbridgec]

@hasnainvirk The software MUX idea sounds great! @AriParkkila if you have any insight into that, we'd be very interested in something like that.

As far as our ME910 driver implementation, it's currently in house, but I can do some cleaning up and create a PR with it. We'd love to get your feedback on what we have so far.

[trowbridgec]

@hasnainvirk @AriParkkila @maclobdell @ARMmbed/team-embeddedplanet

I created PR #10484 for bringing our ME910 driver implementation.

[AriParkkila]

@Alex-EEE It looks like PR #10484 by @trowbridgec might solve this request, so this issue could be closed?

[40Grit]

@AriParkkila I'd prefer this stay open till that merges

[AriParkkila]

@Alex-EEE PR #10484 was merged, this issue can be closed?

[40Grit]

This was reopened at my request. It has been resolved. @AriParkkila

[0Grit]

@0xc0170 This can be closed.