Assistance Requested for Configuring ubxlib for LEAN_R8 on Linux

[IssamSayyaf]

Hello,

I hope this message finds you well.

I am reaching out to seek your guidance on configuring the ubxlib library for use with the LEAN_R8 device on a Linux operating system. I have successfully cloned the repository and identified the specific components I need within the UBXLIB_FEATURES section of the linux.cmake file.

Following this, I executed the cmake command to configure the build environment and subsequently ran the test program, which performed as expected. However, my primary objective is to ensure that the compiled library is fully compatible with the LEAN_R8 device, which connects via USB and communicates using the Point-to-Point Protocol (PPP).

Could you please advise on the steps necessary to instruct the cmake build system to target the LEAN_R8 device specifically? My aim is to ensure seamless communication over USB with PPP protocol support. and if there are any examples of this.

I appreciate your time and look forward to your expert advice.

[RobMeades]

Hi there, and thanks for posting. The problem you'll have is that we don't currently have a PPP-level integration into Linux with LENA-R8, only with ESP-IDF [plus Zephyr with some provisos] and with SARA-R5 or SARA-R422.

That said, I can take a look at how difficult it would be to do a PPP-level integration with Linux; I know that on Windows it would involve signed drivers, which would be difficult, but with Linux we should be able to use pppd. I will also need to check on the status of PPP with LENA-R8. Will get back to you.

[IssamSayyaf]

Okay, thank you very much, I am looking forward to hearing from you soon. Thank you in advance for your help and support.

[IssamSayyaf]

I have a question, could you tell me how can I run it using UART without PPP now, and when the new update is ready I can move to it? how can I adjust the Flags to tell it the number of /dev/ttyUSBX and specify the LENA_R8.

Thank you in advance

[RobMeades]

Certainly: in the uDeviceCfg_t structure you pass to uDeviceOpen() you would set the moduleType field of uDeviceCfgCell_t to U_CELL_MODULE_TYPE_LENA_R8; you could also set it to U_CELL_MODULE_TYPE_ANY and ubxlib will read the module type and set it for you but it is slightly quicker to set the proper module type yourself.

To tell Linux the correct serial port to use with the module, if, say, you were using /dev/ttyUSB5 then in the uDeviceCfg_t structure you pass to uDeviceOpen() you would set the uart field of uDeviceCfgUart_t to 5 and the pPrefix field to /dev/ttyUSB.

You can see how we configure this structure in the examples, e.g. this one which runs PPP from ESP-IDF; a Linux version might look similar.

[RobMeades]

Hi again. I have pushed a preview branch that contains support for PPP on LENA-R8 and also support for PPP with Linux here:

https://github.com/u-blox/ubxlib/tree/preview_ppp_linux_lena_r8_rmea

Details about how to make it happen can be found in the Linux platform README.md and you will find example code here. A few things to note:

• There seems to be a limitation with LENA-R8 that, once a PPP connection is running, any other AT-command-based activity that needs to send data to the network using the clients on-board the LENA-R8 (i.e. things like using the ubxlib function to look up a DNS address, using ubxlib MQTT or HTTP, using a ubxlib socket) will fail. This is currently preventing me checking the code in as such simultaneous operations are something we specifically test for ubxlib. I am trying to find out if there is any way around this; I imagine you won't mind, as I guess you will do all of those things from Linux natively once PPP is up; if there is no way around it I will need to modify our tests to match for LENA-R8.
• Running/configuring pppd can be quite complex. especially as most things connected with it seem to be considered a security risk. In our test system we have the pppd executable setuid (so that non-root users can run it and it will assume root privileges when it needs to) and we configure it with noauth (since no cellular module is going to ever be able to authenticate itself to pppd). You will need to decide on your approach to such matters.

Please give it a try and let me know if it works for you. If you confirm that it works I will merge the support for PPP with Linux and, once I've sorted out what it is doing, the support for PPP with LENA-R8, into master here and will delete the preview branch some time after that.

[IssamSayyaf]

Okay, Thank you very much. I will test it and come back to you thank you very much.

[RobMeades]

FYI, branch updated to handle the case where pppd disappears without ubxlib knowing about it; probably wouldn't be an issue for your testing.

[RobMeades]

We've now had time to test this pretty thoroughly ourselves and so it is pushed here, see commits ac08677d4570aa46632317c28a4b114ad645f47d and f62f008347dee8ee5fb3863dd1a7b850c39d7086; if you just take head revision you should be fine.

If that works for you please close this issue, otherwise let us know how we can help.

[IssamSayyaf]

to be honest not yey, I moved to another task, and I have to check and test everything related to LTE the next week. Of course, I will check everything. I would like to thank you for your great support and help. Thank you very much.

[RobMeades]

NP: I shall delete the preview branch, please just work from a refresh of master and let us know if you have problems with it.

[IssamSayyaf]

Great news, okay of course thank you very much

[IssamSayyaf]

Hello,

I would like to thank you, I build it and I understand how I should choose the LEAN and the connection port and I have all the library as .o

I need some support, how can in the end build the final application and connect all of this library, moreover, I want to make the library work on an ARM processor. how can I generate the elf file? this is my question now I have compiled everything I have all the library.o, and for example, I want to test my board using this main_ppp_linux.c however how can I generate the elf file and apply the cross-compiling?

Thank you in advance.

this is my modification static const uDeviceCfg_t gDeviceCfg = { .deviceType = U_DEVICE_TYPE_CELL, .deviceCfg = { .cfgCell = { .moduleType = U_CELL_MODULE_TYPE_LENA_R8, .pSimPinCode = NULL, / SIM pin / .pinEnablePower = U_CFG_APP_PIN_CELL_ENABLE_POWER, .pinPwrOn = U_CFG_APP_PIN_CELL_PWR_ON, .pinVInt = U_CFG_APP_PIN_CELL_VINT, .pinDtrPowerSaving = U_CFG_APP_PIN_CELL_DTR }, }, .transportType = U_DEVICE_TRANSPORT_TYPE_UART, .transportCfg = { .cfgUart = { .uart = 5, // UART port number .pPrefix = "/dev/ttyUSB" // Prefix for the device file .baudRate = U_CELL_UART_BAUD_RATE, .pinTxd = U_CFG_APP_PIN_CELL_TXD, .pinRxd = U_CFG_APP_PIN_CELL_RXD, .pinCts = U_CFG_APP_PIN_CELL_CTS, .pinRts = U_CFG_APP_PIN_CELL_RTS,

ifdef U_CFG_APP_UART_PREFIX

        .pPrefix = U_PORT_STRINGIFY_QUOTED(U_CFG_APP_UART_PREFIX) // Relevant for Linux only

else

        .pPrefix = NULL

endif

    },
},

};

[RobMeades]

I build it...

That's good news, well done!

how can in the end build the final application and connect all of this library

That kind of depends what you want your application to do. The example shows how to bring up a network connection and the section in the README.md of the Linux platform folder shows how to set up pppd so that the connection is visible to the Linux kernel. After that you should just be able to use connectivity from within Linux in the usual way, or make ubxlib API calls from the application that you have linked the ubxlib library into.

moreover, I want to make the library work on an ARM processor.

When you say "ARM processor", since you are talking of an .elf file, I guess you mean an MCU (like nRF52/nRF53, STM32, ESP32, that kind of thing). The answer will depend entirely on what the MCU is and what the SDK is. The MCU manufacturer will usually provide/support one or more SDKs and ubxlib supports some of those SDKs: for nRF52/nRF53 we support nRFConnect/Zephyr, for STM32F4 we support STM32Cube, for other STM32 flavours we support native Zephyr and for ESP32 we support ESP-IDF. You would choose one of these SDKs and then follow the instructions in the relevant ubxlib /port/platform/xxx folder to perform the build.

[IssamSayyaf]

Great, I want to run the application on ARM cortex A7 with Linux os. So the platform is Linux

target_link_libraries(YOUR_APPLICATION_NAME ubxlib ${UBXLIB_REQUIRED_LINK_LIBS}) target_include_directories(YOUR_APPLICATION_NAME PUBLIC ${UBXLIB_INC} ${UBXLIB_PUBLIC_INC_PORT})

So I need to add these two lines for the cmakelist.txt to compile my application and link it with ubloxlib

Is it right?

[RobMeades]

Taking a step back for a moment, just to align on terminology in case of misunderstandings.

Above you mention ".elf file and apply the cross-compiling"; cross-compiling means using a toolchain on machine (a) to build an executable file that will NOT run on machine (a) but will instead run on machine (b). The executable file created would usually be an .elf file, or possibly a .hex file or even a .bin file, machine (a) would usually be a Windows or Linux or Mac desktop machine and you would usually use some form of download/flash tool to move the .elf file to machine (b), where it would run. The reason for doing this is usually because machine (b) is an embedded MCU or some such, it is not a development environment, not a place where you would write code, and is not powerful enough to run a compiler, so you need a "special" toolchain (e.g. GCC ARM) running on a desktop machine to produce code for an entirely different processor to that where the compiler is running. This toolchain is different to the GCC you might already have on your Linux desktop, which only makes code that will run on that Linux desktop (compiling, as opposed to cross-compiling).

Above you also say "I want to run the application on ARM cortex A7 with Linux OS": given that you mentioned cross-compiling and a .elf file, I guess that this target machine is some form of embedded Linux and it has to be machine (b) because it is not sufficiently powerful to run a compiler itself, you need machine (a) to run the compiler.

So you will need something like GCC ARM, or whatever the suppliers of the "ARM cortex A7 with Linux OS" machine suggest, installed on your desktop machine, machine (a), and, after that, you would create a build environment that calls GCC-ARM (rather than the native GCC compiler for machine (a)) on the .c files of your application, plus the ubxlib files. If you are using CMake then yes, it would be pretty much as indicated, just make sure that the correct toolchain for the target machine is being called by the CMake files.

[IssamSayyaf]

Thank you very much, I have built the example and a cmake I will share with you, but I still have a problem, with a cross-compiling problem Could you help me? I will be thankful just I want to build This is the project containing "CMakeLists", issam_LTE.c issam_LTE.h project.zip

[RobMeades]

OK: what is the problem?

[IssamSayyaf]

I think I discovered the problem there are problems with OpenSSL and libgpiod I am trying to add it to gcc-arm to generate the file based on gcc-arm.

I will come back to you to tell you.

A huge thanks for your helping

[IssamSayyaf]

I am embarrassed too much could you give me an example of how can I build the issam_LTE.c using gcc-arm I tried too much, but I still have a lot of problems.

You mentioned this was tested by Raspberry how can I generate a file and test it on raspberry, should I build the system on raspberry pi.

Moreover if just can you just help me on this point would be great, how can I build the issam-lte,c using gcc-arm, as you mentioned I am working with embedded Linux, especially stm32mp1

[RobMeades]

Cross-compiling is a complex thing to do: for an embedded MCU, where everything is usually compiled from .c files in one go, i.e. there are no pre-compiled libraries, one can just get a flavour of GCC for the target MCU (e.g. GCC-ARM) and away you go, but if the target is a Linux machine and you need to include in your application third party libraries like OpenSSL and libgpiod then you will, of course, need to obtain and point your build at versions of those third party libraries that have been compiled for the target architecture, the thing you are cross-compiling to; this makes the process even more complex.

If the target is a kind of Raspberry Pi that runs Linux then, 10 years ago, I might have suggested that compiling for the Pi on a Windows or Linux desktop was necessary, since the Pi's back then were not so powerful, but these days a Raspberry Pi 3, 4 or 5 should be perfectly fine for compiling the relatively small application you have in mind, so I would go for compiling everything natively on the Raspberry Pi, no cross-compiling required.

Then you can just fetch the OpenSSL and GPIO libraries on that Raspberry Pi (I think the Pi already has these installed but if not libssl-dev and libgpiod-dev are probably what you want) and everything should work.

[IssamSayyaf]

Dear, thank you for all your support and great results, the software is working very well. I built the example and ran it and I was able to connect, everything was fantastic. however, I think this will be the last question. during the run of the example I stacked at this point, you can guide me, or give me any hints. I will be thankful.

After creating a ppp connection and connecting with APN, the software started to enter into a loop and repeat the last 5 commands more and more. Do you know what is it the problem?

---

root@stm32mp1-hexabitzv2-mx:~/LTE_1/ubxlib/port/platform/linux/mcu/posix/runner/issam/build# ./issam_LTE U_CELL: initialising with enable power pin not connected, PWR_ON pin not connected and VInt pin not connected. AT

OK AT

OK U_CELL_PWR: powering on, module is already on. ATE0

OK AT+CMEE=2

OK AT+UDCONF=1,0

OK ATI9

02.00,A01.22

OK AT&C1

OK AT&D0

OK AT&K0

OK AT+UPSV=0

OK AT+UGPRF?

+UGPRF:2,0,""

OK AT+CFUN=4

OK

+CREG: 0,"0000","0000",0 U_PORT_PPP: listening for pppd on socket 127.0.0.1:5000. Opened device with return code 0. Br[ 812.650387] TCP: request_sock_TCP: Possible SYN flooding on port 5000. Sending cookies. Check SNMP counters. inging up the network... U_CELL_NET: preparing to register/connect... AT+CREG=2

OK AT+CGREG=2

OK U_PORT_PPP: pppd has connected to socket. AT+CEREG=4

OK AT+CIMI

234502106062261

OK AT+CIMI

234502106062261

OK U_CELL_NET: APN from database is "jtm2m". AT+CGDCONT=1,"IP","jtm2m"

OK AT+UAUTHREQ=1,0,"",""

OK AT+CGDCONT=2,"IP","jtm2m"

OK U_CELL_NET: setting automatic network selection mode... AT+COPS?

+COPS: 0

OK AT+CFUN=1

OK AT+CREG?

+CREG: 0,"0000","0000",0

OK -1: NReg AT+CGREG?

+CGREG: 2,0,"0000","0000"

OK -1: NReg AT+CEREG?

+CEREG: 4,0,"0000","00000000", 0,0,0,"00000000","00000000"

OK -1: NReg AT+CREG?

+CREG: 0,"0000","0000",0

OK -1: NReg AT+CGREG?

+CGREG: 2,0,"0000","0000"

[RobMeades]

This is normal: the cellular module is trying to connect to the cellular network, which may take some time (at least seconds and, on the first attempt in a location where the cellular module has not connected before, potentially minutes).

[IssamSayyaf]

Great! After 242 seconds, I have this message Would you like me to do something special?

Thank you very much,

OK -1: Deny AT+CREG?

+CREG: 0,"1903","5f66",0

OK -1: NReg U_CELL_NET: unable to register with the network, is APN "jtm2m" correct and is an antenna connected? AT+CEER

+CEER:No Error Call

OK AT+CFUN=4

OK

+CREG: 0,"0000","0000",0 U_CELL_NET: connection attempt stopped after 242 second(s). Unable to bring up the network! Closing device... -1: NReg Segmentation fault (core dumped)

[RobMeades]

Can you post a bit more of the log, maybe include the whole log as an attachment? "Deny" means that some form of service has been denied by the cellular network but the exact form of that service is not clear as the Deny will be an interpretation of a URC (i.e. an unsolicited output from the module that conventionally begins with a +) which happened before the bit you have pasted in above. It could be that circuit-switched service has been denied but packet switched service is possible (in which case either there's a bug in our code or the timeout is real) or it could be that both circuit and packet switched service has been denied, in which case your SIM card has not been accepted on any visible cellular network.

EDIT: what SIM card are you using and have you been given an APN you must provide when using that SIM card (if so are you using that APN)?

Segmentation fault (core dumped) is, of course, unexpected, irrespective of whether you have achieved a connection or not; do you get any back-trace at that point?

[IssamSayyaf]

Okay, I will attach the log file. if can you take a look and tell me, what do you think the problem? I will be thankful for your help. You can find the file as an attachment. Thank you in advance

+CREG: 0,"0000","0000",0 U_PORT_PPP: listening for pppd on socket 127.0.0.1:5000. Opened device with return code 0. Bringing up the network... U_CELL_NET: preparing to register/connect... U_PORT_PPP: pppd has connected to socket. AT+CREG=2

OK AT+CGREG=2

OK AT+CEREG=4

OK AT+CIMI

234502106062261

OK AT+CIMI

234502106062261

OK U_CELL_NET: APN from database is "jtm2m". AT+CGDCONT=1,"IP","jtm2m"

OK AT+UAUTHREQ=1,0,"",""

OK AT+CGDCONT=2,"IP","jtm2m"

OK U_CELL_NET: setting automatic network selection mode... AT+COPS?

log_LTE.txt

[RobMeades]

Thanks: relatively quickly (about 1/3rd of the way into your log) the network is returning "denied" for both circuit-switched and packet-switched service:

+CREG: 3,"1903","5f66",0 [begins occurring at line 1324 out of 4186]
+CEREG: 4,3,"1903","5f660000", 0,0,20,"00000000","00000000" [begins occurring at line 1352 out of 4186]

So either (a) your SIM card is not valid or (b) you are not using the correct APN for your SIM card.

What SIM card are you using and were you given an APN to use with that SIM card?

[IssamSayyaf]

I used a mobile thing company I have to change the APN.

https://www.thingsmobile.com/private/thingsmobile

[RobMeades]

Ah, yes, set the APN to "TM" and try again.

[IssamSayyaf]

Yeah I recognize the problem I will search how to modify the APN in the code Thank you very much, sorry I am not too much expert on these things.

Thank you I will modify it

[RobMeades]

https://github.com/u-blox/ubxlib/blob/2dd46e25078b7c1b519674acc46330982cd0b8da/example/sockets/main_ppp_linux.c#L129

[IssamSayyaf]

still have the same problem, I need to configure some thing before use the SIM like the PIN, or something like this. OK -1: Deny U_CELL_NET: unable to register with the network, is APN "TM" correct and is an antenna connected? AT+CEER

+CEER:No Error Call

OK AT+CFUN=4

OK

+CREG: 0,"0000","0000",0 U_CELL_NET: connection attempt stopped after 243 second(s). Unable to bring up the network! Closing device... -1: NReg Segmentation fault (core dumped)

[IssamSayyaf]

Does the chip need an external antenna?

[RobMeades]

No, no PIN is required (we do not support PIN entry as there is no human to enter it and programming a PIN will send it over UART wires that anyone can monitor in any case).

Does the chip need an external antenna?

Yes: what physical board are you using?

[IssamSayyaf]

It is a customized board designed by our company. I will share with you the picture.

[RobMeades]

Looks like you need to plug 2.4 GHz cellular antennas into BOTH of these sockets:

[IssamSayyaf]

okay, there are any specific requirements for the antenna like gain, 2.4GHz I will order two if there are any specific kind you recommend it to me I will be happy to hear from you

[RobMeades]

Getting a good antenna is important, it can make a huge difference to the performance of your product, but I'm no RF engineer I'm afraid, so I am in no position to recommend one. For now, just to get things working, buy any LTE antennas that you are sure will match the sex of those U.FL connectors: what you have on the board appear to be male U.FL connectors so your antennas will need to have female U.FL connectors on the end of them.

[IssamSayyaf]

Okay great don't worry I will buy a good one. I will check then I will come back with news.

A huge thank you

[RobMeades]

Correction: that's a LENA-R8 device with an M10 GNSS module inside it, so one of those U.FL connectors will probably be for GNSS, which will need a high quality GNSS active antenna, the other will be for LTE. You will need to find out which is which!

[IssamSayyaf]

Yeah, So we have to choose a good antenna. I checked the FCC ID. I have seen some expirments for the LTE I am in France and I choose Band 7. Antenna Gain = 9 dBi. Is it a good choice? https://fcc.report/FCC-ID/XPYUBX22EL01/

[philwareublox]

France has these bands for 4G LTE: (MHz) B1 (2100), B3 (1800), B7 (2600), B20 (800), B28a (700), B28b (700)

Depending on what actual network you will roam on to, as you are using a roaming SIM, that network will be on Band 7, Band 20, Band 3, Band 1 etc...

You'd have to look at the network operators and what bands they are on. In my experience for europe, bands 3 and 20 are common. You'll have to see what networks are on band 7 2600MHz.

Of course the LENA-R8M10 module supports these bands 1,2,3,4,5,7,8,12,20,28,66 But it depends on the actual network operator bands in the location you are deploying into.

[IssamSayyaf]

I have checked many operators in my area which use band 3 and 7. So I think band 3 will be good. I have to buy a good antenna that works on this band. Is it right?

[philwareublox]

I would imagine you can find an antenna which covers LTE on all Bands. Here is one from Taoglas: https://www.taoglas.com/product/fxub63-ultra-wide-band-flex-antenna/

[IssamSayyaf]

Great, I am checking it, it looks suitable. Thank you very much.

[IssamSayyaf]

Hello,

I'm back with an update on the antenna. I've used the antenna, and now it seems like I can communicate with the network. However, I'm still facing some problems. It tells me the APN is not correct, even though I used the one provided by the SIM provider, which is called "TM." I attached the logfile contain the output on the termianl. Please could you help me.

Thank you in advance.

log_LTE.txt

[IssamSayyaf]

This is the C file, is the same example that you provide us in repo

issam_LTE.c.txt

[RobMeades]

That is good progress.

It tells me the APN is not correct,

Not quite: that is a debug print from the ubxlib code saying that you have not been able to activate a PDP context with the network and suggesting things you might check, like the APN. Looking at the log, there appears to be a limitation, I guess in your subscription, look toward the bottom of this segment, where it says +CME ERROR: operation not allowed:

AT+CFUN=1
OK
AT+CREG?
+CREG: 0,"0000","0000",0
OK
AT+CGREG?
+CGREG: 2,0,"0000","0000"
OK
AT+CEREG?
+CEREG: 4,0,"0000","00000000", 0,0,0,"00000000","00000000"
OK
+CREG: 5,"35c5","00dcf406",7
+CEREG: 5,"35c5","00dcf406",7
+CREG: 5,"35C5","00DC"
+CGREG: 4,"35C5","00DC"
AT+COPS=3,0
OK
AT+COPS?
+COPS: 0,0,"Orange F",7
OK
AT+CGATT?
+CGATT:1
OK
AT+CGACT?
+CGACT: 0,0
OK
AT+CGACT=1,1
OK
AT+CGACT?
+CGACT: 1,1
OK
AT+CGACT?
+CGACT: 1,1
OK
AT+CGACT=1,2
+CME ERROR: operation not allowed
U_CELL_NET: unable to activate a PDP context, is APN "TM" correct?

LENA-R8 has a limitation that it will not let you use the same PDP context for the internal module clients (MQTT, HTTP, sockets) and for PPP, hence we activate a second PDP context for PPP. That is what the line AT+CGACT=1,2 is doing and it is being rejected by the network. It seems that your "TM" SIM card, or possibly the "Orange F" network, only allows a single PDP context (you can see that AT+CGACT=1,1 succeeded), activation of a second PDP context is not allowed. The same procedure works fine here on Vodafone UK, see below:

 23:39:35,009 AT+COPS?
 23:39:35,143 +COPS: 0,0,"vodafone UK",7
 23:39:35,173 OK
 23:39:35,185 AT+CGATT?
 23:39:35,222 +CGATT:1
 23:39:35,253 OK
 23:39:35,264 AT+CGACT?
 23:39:35,294 +CGACT: 0,1
 23:39:35,325 OK
 23:39:35,336 AT+CGACT=1,1
 23:39:35,382 OK
 23:39:35,393 AT+CGACT?
 23:39:35,452 +CGACT: 1,1
 23:39:35,483 OK
 23:39:35,494 AT+CGACT?
 23:39:35,524 +CGACT: 1,1
 23:39:35,555 OK
 23:39:35,566 AT+CGACT=1,2
 23:39:35,782 OK
 23:39:35,794 AT+CGACT?
 23:39:35,853 +CGACT: 1,1
 23:39:35,864 +CGACT: 2,1
 23:39:35,894 OK
 23:39:38,870 U_CELL_NET: connected after 6 second(s).
 23:39:38,884 AT+CGACT?
 23:39:38,952 +CGACT: 1,1
 23:39:38,964 +CGACT: 2,1
 23:39:38,993 OK
 23:39:39,004 AT+CGPADDR=1
 23:39:39,035 +CGPADDR: 1,"10.115.181.187"
 23:39:39,065 OK

Not sure what to suggest; if you are definitely never going to use the on-board module clients, you will just use PPP, there may be a way to hack the code to force PPP to use the first context, but it will be a bit of a hack I'm afraid.

[IssamSayyaf]

So, the problem could be with the SIM itself. Could I try using my mobile SIM to test it, or should it be an IoT SIM? My network is "free Mobile" in France.

[RobMeades]

Difficult to say really: doesn't need to be anything particularly special, SIM-wise, aside from supporting activation of two PDP contexts. Probably worth a try with your mobile phone SIM I guess.

[RobMeades]

If that doesn't work, you can try defining the conditional compilation flag U_CELL_PRIVATE_PPP_CONTEXT_ID_LENA_R8=-1 when compiling the ubxlib code. As I say the on-board module clients for MQTT, HTTP and sockets won't work with that set but it should allow you to use PPP with a single PDP context.