Using pppd with LARA-R6 via USB

[cirdeirf]

Hi,

I'd like to use the new PPP-level integration on Linux with a LARA-R6 cellular module connected via USB but ran into two issues so far:

1. I had to comment out lines 979 and 980 in u_cell_pwr.c

            success = moduleConfigureOne(atHandle, "AT&K0",
                                         U_CELL_PWR_CONFIGURATION_COMMAND_TRIES);

as this does not seem to work if connected via USB:

2024/03/26 15:27:17.792: AT&K0
2024/03/26 15:27:17.832:
2024/03/26 15:27:17.832: +CME ERROR: operation not supported

2. More importantly: CMUX seems to be required for this to work which cannot be used on the USB interface. I probably will have to use one of the additional AT interfaces. Any ideas how to do that?
   Until now we used ubxlib to setup the cellular module (we use LARA-R211 und LARA-R6) and fork pppd from within our application.

Thanks for your help and this really useful library!

[RobMeades]

Hi, and thanks for posting. As you may have guessed from having to comment-out that line, we don't routinely test using modules via the USB interface: not that it shouldn't work, it is just that UART is the more common use-case. I will see if there's a good way to take the offending line "out of circuit" for the USB use-case.

On the CMUX thing with PPP, that's correct; we do that so that normal AT traffic can continue, GNSS information from a GNSS chip inside a cellular module can be streamed out in parallel, etc. all without the user having to worry about it. As to using one of the UART interfaces on the LARA-R6, I think it should just work - have you tried connecting to it (with the USB disconnected as the module likely switches to USB when it sees 5V there and so would then ignore you over UART)?

[cirdeirf]

Thanks, but I think I meant to say "use one of the additional AT instances", i.e., USB1/USB2/USB3. Unfortunately, our module is connected exclusively via USB.

[RobMeades]

Ah, I see: what you need is PPP-level integration running to a serial port rather than to CMUX; I'd been waiting for someone to ask for that. Our virtual serial device interface is not quite the same as our uPortUart (hindsight is a wonderful thing); probably the simplest way to make it happen would be to follow the pattern we use in our test code for the virtual serial device and slap a virtual serial device interface on top of a uPortUart interface (EDIT: or whatever serial interface you fancy; it doesn't have to follow the pattern of our porting layer for your own use-case).

You would need to perform a little surgery in u_cell_ppp.c about here to not bring up the CMUX and instead attach that virtual interface but you would likely be on your way.

I'm a bit buried in other things at the moment or I'd have a go at this myself. If you either (a) don't fancy diving in or (b) aren't in a hurry, I might be able to give it a go in a few weeks.

[cirdeirf]

I appreciate your pointers but the required changes seem to exceed my expertise/understanding of the lib a bit. I'll wait and hope that you'll find time for this.

[RobMeades]

Understood, I will think on it and propose something back here for you to try.

[RobMeades]

FYI, I have the code for this now but won't be able to test it until next week. Will post something here then.

[cirdeirf]

Great, I'm looking forward to it.

[RobMeades]

@cirdeirf: how brave are you feeling (or alternatively how good is your knowledge of Docker containers)? I have a version of this which should work but I can't test it yet because of some subtlety to do with the way Docker containers work on different platforms (our test system runs instances of itself inside a Docker container); this is nothing to do with you of course but it means I can't give you tested code until I find a way around it.

If you are feeling brave enough to just give stuff a try, I have pushed a preview branch here:

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

...where the Linux PPP sockets example is updated to point PPP at another USB end-point if you define U_CFG_APP_CELL_UART_PPP (e.g. you might have U_CFG_APP_CELL_UART=0, U_CFG_APP_CELL_UART_PPP=1 and U_CFG_APP_UART_PREFIX=/dev/ttyUSB; of course you don't need all these #defines for your application code, it is just our way of defining things for our test system).

You will see from that example that the idea is the uNetworkCfgCell_t structure you pass to uNetworkInterfaceUp() has gained a new field, pUartPpp, which you point at a uDeviceCfgUart_t structure that defines your PPP "UART" (actually USB end-point in your case), e.g. something like:

uDeviceCfgUart_t gNetworkCfgCellUartPpp = {
    .uart = -1, // Use -1 to leave the number off the end of pPrefix, pPrefix becomes the _entire_ UART name
    .baudRate = 115200,
    .pinTxd = -1,
    .pinRxd = -1,
    .pinCts = -1,
    .pinRts = -1,
    .pPrefix = "/dev/ttyUSB1"
};

...to use /dev/ttyUSB1 for PPP (you might have put /dev/ttyUSB0 in the uDeviceCfgUart_t part of the uDeviceCfgCell_t structure you gave to uDeviceOpen(), which will be used for AT commands).

I will entirely understand if you'd rather let me sort my own rubbish out before inflicting this on yourself, just posting it in case you were in a hurry really.

[RobMeades]

I have fixed my test problem; you can find a tested preview branch here:

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

I will delete early_preview_feature_cell_ppp_usb_rmea now.

No code changes aside from the removal of some debug that I left in by mistake. This is the version that I will put in for review, it will hopefully appear in master here next week. Let me know if you see any problems should you have time to try it.

[cirdeirf]

Thanks.
A first quick test was unsuccessful, unfortunately: Seems like when I end up in uPortUartOpen during uNetworkInterfaceUp, pFindUartById returns -1 and I get U_ERROR_COMMON_BUSY.
I'll keep investigating.

Here is my configuration if you should happen to spot any mistake there on a glance:

uDeviceCfg_t device_cfg_ = {
  .version = 0,
  .deviceType = U_DEVICE_TYPE_CELL,
  .deviceCfg = {
      .cfgCell = {
          .version = 0,
          .moduleType = U_CELL_MODULE_TYPE_LARA_R6,
          .pSimPinCode = nullptr,  // not supported
          .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_USB,
  .transportCfg = {
      .cfgUart = {
          .version = 0,
          .uart = U_CFG_APP_CELL_UART,
          .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,
          .pPrefix = "/dev/ttyUSB1",
      },
  },
  .pCfgName = nullptr,
};

uNetworkCfgCell_t network_cfg_ = {
  .version = 0,
  .type = U_NETWORK_TYPE_CELL,
  .pApn = "internet.m2mportal.de",
  .timeoutSeconds = 240,
  .pKeepGoingCallback = nullptr,
  .pUsername = nullptr,
  .pPassword = nullptr,
  .authenticationMode = U_CELL_NET_AUTHENTICATION_MODE_NOT_SET,
  .pMccMnc = nullptr,
  .pUartPpp = &gNetworkCfgCellUartPpp,
};

uDeviceCfgUart_t gNetworkCfgCellUartPpp = {
  .version = 0,
  .uart = U_CFG_APP_CELL_UART,
  .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,
  .pPrefix = "/dev/ttyUSB2"
};

[RobMeades]

For my clarification, uDeviceOpen() works but uNetworkInterfaceUp() returns an error? I guess you have U_CFG_APP_CELL_UART set to -1 (or uDeviceOpen() wouldn't have worked)?

[RobMeades]

Hmmm, I wonder: the difference with your case is that you are setting both U_CFG_APP_CELL_UART to -1, in my testing I happen to set that to 1 for the first case and 2 for the second, I wonder if the logic in our Linux uPortUart code doesn't work quite right if U_CFG_APP_CELL_UART is -1 in both cases. Let me test that...

[cirdeirf]

For my clarification, uDeviceOpen() works but uNetworkInterfaceUp() returns an error? I guess you have U_CFG_APP_CELL_UART set to -1 (or uDeviceOpen() wouldn't have worked)?

Correct. I just used this value as it is defined in u_cfg_app_platform_specific.h.

[RobMeades]

You can try setting .pPrefix to "/dev/ttyUSB" in both cases and setting the .uart field to 1 and 2 respectively. If what I think is the problem, is the problem, that should work for you.

[cirdeirf]

Thank you. Was about to answer that that works ^^.

[RobMeades]

Woohoo! Please continue hammering it. In particular, do you have any issues getting name resolution to work on Linux? Have a weird problem that I am seeing with our test system, only when the Docker container it is running inside is running on Centos8, where name resolution doesn't appear to work, seems to time out. It works fine when the Docker container is running on Raspbian, so I have put it down to "some odd Linux thing", but would be interested to know if you see the problem on whatever Linux you are running.

Meanwhile I will go fix the logic in the uPortUart bit of the Linux port layer.

[RobMeades]

If you would like to use you original formulation, I believe the fix required is to change this line:

ubxlib/port/platform/linux/src/u_port_uart.c

Line 419 in d251066

if (pFindUartById(uart) != NULL) {

...to be:

    if ((uart >= 0) && (pFindUartById(uart) != NULL)) {

[cirdeirf]

Woohoo! Please continue hammering it. In particular, do you have any issues getting name resolution to work on Linux? Have a weird problem that I am seeing with our test system, only when the Docker container it is running inside is running on Centos8, where name resolution doesn't appear to work, seems to time out. It works fine when the Docker container is running on Raspbian, so I have put it down to "some odd Linux thing", but would be interested to know if you see the problem on whatever Linux you are running.

Meanwhile I will go fix the logic in the uPortUart bit of the Linux port layer.

But name resolution on the underlying system (Centos8) works? My knowledge of Docker containers is quit limited I'm afraid. Name resolution works on our system (custom linux built using yocto project) without problems so far.

[RobMeades]

But name resolution on the underlying system (Centos8) works?

I don't have that scenario to hand as the test system always runs inside the Docker container and the only Centos8 machines I have are part of the test system, I don't have one I that I can freely use.

When I print out the PPP traffic passing between the module and the application (those debug prints I have now removed) I can see what I guess is the DNS request being sent to the cellular module (a burst of PPP activity after the DNS query function is called at Linux level), but it seems to take slightly too long for the PPP activity in the reverse direction (which I guess is the answer coming back) to occur, the Linux bit has timed-out before that. I don't see how this can be anything to do with ubxlib but, then again, I can't see what it would be to do with.

If your Linux flavour gets an answer to a DNS query in time that is useful information; I will put it down to "it's a mystery, probably not my fault" for now.

[cirdeirf]

Thank you. Was about to answer that that works ^^.

Although the connection may not be stable. Our application regularly pings some server to check if internet is available and every 20-40s this ping currently fails once and succeeds again for ~30s. I'm going to clean up (some pppd-forking-related stuff I no longer need), recheck old pppd options and check again.

[RobMeades]

Interesting: do you have any way of "sniffing" the USB interface? Normally when problems of this nature occur I would recommend switching on CMUX debug, which prints out detailed activity, and of course one can see AT commands in any case, but once PPP is on a separate USB port and connected to the Linux kernel via pppd there is currently no way in the ubxlib code to see what the traffic is. I don't know whether pppd can be persuaded to log that kind of thing: any debug log would likely be full of connection retries because of the persist and max_retries 0 thing we need to have it try to connect to the socket that ubxlib will offer.

Otherwise, I could put those debug prints I took out back in, under a conditional compilation flag, for these occasions. Would that be useful?

[cirdeirf]

Sry, you are too fast for me ^^"
I'm busy with other stuff but was eager to see it working. Will report again later today or tomorrow (or when I think I need those debug prints).

[cirdeirf]

Would you mind giving me the debug prints (or putting them back in)?

Analysing pppd debug output/options did not help me much. I can look at the serial device (used for pppd connection) via, e.g., picocom, but the output is not readable (or at least there was nothing obvious during the "outage" times).

[cirdeirf]

The ubxlib log output during application shutdown does not look quite right by the way. Although it probably is not the cause for my problems as they occur during a fresh "boot" as well.

U_CELL: initialising with enable power pin not connected, PWR_ON pin not connected and VInt pin not connected.
2024/04/12 07:33:34.206: AT
2024/04/12 07:33:34.247:
2024/04/12 07:33:34.247: OK
2024/04/12 07:33:34.267: AT
2024/04/12 07:33:34.307:
2024/04/12 07:33:34.307: OK
U_CELL_PWR: powering on, module is already on.
2024/04/12 07:33:34.328: ATE0
2024/04/12 07:33:34.368:
2024/04/12 07:33:34.368: OK
2024/04/12 07:33:34.388: AT+CMEE=2
2024/04/12 07:33:34.429:
2024/04/12 07:33:34.429: OK
2024/04/12 07:33:34.449: AT+UDCONF=1,0
2024/04/12 07:33:34.489:
2024/04/12 07:33:34.489: OK
2024/04/12 07:33:34.510: ATI9
2024/04/12 07:33:34.550:
2024/04/12 07:33:34.550: 00.13,A00.01
2024/04/12 07:33:34.550:
2024/04/12 07:33:34.550: OK
2024/04/12 07:33:34.570: AT&C1
2024/04/12 07:33:34.611:
2024/04/12 07:33:34.611: OK
2024/04/12 07:33:34.631: AT&D0
2024/04/12 07:33:34.671:
2024/04/12 07:33:34.671: OK
2024/04/12 07:33:34.692: AT+UCGED=2
2024/04/12 07:33:34.732:
2024/04/12 07:33:34.732: OK
2024/04/12 07:33:34.752: AT&K0
2024/04/12 07:33:34.793:
2024/04/12 07:33:34.793: +CME ERROR: operation not supported
2024/04/12 07:33:34.813: AT+UPSV=0
2024/04/12 07:33:34.854:
2024/04/12 07:33:34.854: OK
2024/04/12 07:33:34.874: AT+UMNOPROF?
2024/04/12 07:33:34.914:
2024/04/12 07:33:34.914: +UMNOPROF: 90
2024/04/12 07:33:34.914:
2024/04/12 07:33:34.914: OK
2024/04/12 07:33:34.935: AT+UGPRF?
2024/04/12 07:33:34.975:
2024/04/12 07:33:34.975: +UGPRF: 2,0,""
2024/04/12 07:33:34.975:
2024/04/12 07:33:34.975: OK
2024/04/12 07:33:34.995: AT+CFUN=4
2024/04/12 07:33:35.036:
2024/04/12 07:33:35.036: OK
U_PORT_PPP: listening for pppd on socket 127.0.0.1:5000.
2024/04/12 07:33:35.057: ATE0
2024/04/12 07:33:35.097:
2024/04/12 07:33:35.097: OK
2024/04/12 07:33:35.117: AT+CMEE=2
2024/04/12 07:33:35.158:
2024/04/12 07:33:35.158: OK
2024/04/12 07:33:35.178: ATE0
2024/04/12 07:33:35.219:
2024/04/12 07:33:35.219: OK
2024/04/12 07:33:35.239: AT+CGMM
2024/04/12 07:33:35.279:
2024/04/12 07:33:35.279: LARA-R6001D
2024/04/12 07:33:35.279:
2024/04/12 07:33:35.279: OK
2024/04/12 07:33:35.300: AT+USIO?
2024/04/12 07:33:35.340:
2024/04/12 07:33:35.340: +USIO: 4, *4
2024/04/12 07:33:35.341:
2024/04/12 07:33:35.341: OK
2024/04/12 07:33:35.361: AT+ULWM2M?
2024/04/12 07:33:35.401:
2024/04/12 07:33:35.401: +ULWM2M: 1
2024/04/12 07:33:35.401:
2024/04/12 07:33:35.402: OK
2024/04/12 07:33:35.512: AT+CFUN?
U_PORT_PPP: pppd has connected to socket.
2024/04/12 07:33:35.553:
2024/04/12 07:33:35.553: +CFUN: 4
2024/04/12 07:33:35.553:
2024/04/12 07:33:35.553: OK
2024/04/12 07:33:35.573: AT+CFUN=1
2024/04/12 07:33:35.614:
2024/04/12 07:33:35.614: OK
2024/04/12 07:33:35.634: AT+CPIN?
2024/04/12 07:33:35.675:
2024/04/12 07:33:35.675: +CPIN: READY
2024/04/12 07:33:35.675:
2024/04/12 07:33:35.675: OK
2024/04/12 07:33:35.695: AT+CCID
2024/04/12 07:33:35.735:
2024/04/12 07:33:35.736: +CCID: 898822800000********
2024/04/12 07:33:35.736:
2024/04/12 07:33:35.736: OK
U_CELL_INFO: ICCID is 898822800000********.
2024/04/12 07:33:35.756: AT+URAT?
2024/04/12 07:33:35.797:
2024/04/12 07:33:35.797: +URAT: 3,0
2024/04/12 07:33:35.797:
2024/04/12 07:33:35.797: OK
2024/04/12 07:33:35.817: AT+UBANDMASK?
2024/04/12 07:33:35.858:
2024/04/12 07:33:35.858: +UBANDMASK: 3,134742213,0,2,384
2024/04/12 07:33:35.858:
2024/04/12 07:33:35.858: OK
2024/04/12 07:33:35.969: AT+COPS?
2024/04/12 07:33:36.009:
2024/04/12 07:33:36.009: +COPS: 0
2024/04/12 07:33:36.009:
2024/04/12 07:33:36.009: OK
2024/04/12 07:33:36.030: AT+URPM?
2024/04/12 07:33:36.040:
2024/04/12 07:33:36.040: +CREG: 2
2024/04/12 07:33:36.040:
2024/04/12 07:33:36.040: +CGREG: 2
2024/04/12 07:33:36.040:
2024/04/12 07:33:36.040: +CEREG: 2
2024/04/12 07:33:36.060:
2024/04/12 07:33:36.060: +URPM: 1
2024/04/12 07:33:36.060:
2024/04/12 07:33:36.060: OK
2024/04/12 07:33:36.081: AT+UCGED?
2024/04/12 07:33:36.212:
2024/04/12 07:33:36.212: +UCGED: 2
2024/04/12 07:33:36.212: 4,0,000,00
2024/04/12 07:33:36.212: 3749,8,50,50,2f11,0000000,202,00000000,ffff,ff,-91,-11,124.00,255,255,255,255,255,255,0,255,255,0,0
2024/04/12 07:33:36.212:
2024/04/12 07:33:36.212: OK
U_CELL_NET: preparing to register/connect...
2024/04/12 07:33:36.233: AT+CREG=2
2024/04/12 07:33:36.273:
2024/04/12 07:33:36.273: OK
2024/04/12 07:33:36.294: AT+CGREG=2
2024/04/12 07:33:36.334:
2024/04/12 07:33:36.334: OK
2024/04/12 07:33:36.334:
2024/04/12 07:33:36.335: +CREG: 1,"2F11","01B18207",7
2024/04/12 07:33:36.335:
2024/04/12 07:33:36.335: +CGREG: 4
2024/04/12 07:33:36.335:
2024/04/12 07:33:36.335: +CEREG: 1,"2F11","01B18207",7
2024/04/12 07:33:36.355: AT+CEREG=4
7: RegH
-1: OoC
7: RegH
2024/04/12 07:33:36.396:
2024/04/12 07:33:36.396: OK
2024/04/12 07:33:36.416: AT+CIMI
2024/04/12 07:33:36.456:
2024/04/12 07:33:36.456: 901405005247170
2024/04/12 07:33:36.457:
2024/04/12 07:33:36.457: OK
U_CELL_NET: user-specified APN is "internet.m2mportal.de".
2024/04/12 07:33:36.477: AT+CGDCONT=1,"IP","internet.m2mportal.de"
2024/04/12 07:33:36.540:
2024/04/12 07:33:36.540: OK
U_CELL_NET: authentication mode will be PAP.
2024/04/12 07:33:36.560: AT+UAUTHREQ=1,1,"sim","m2m"
2024/04/12 07:33:36.607:
2024/04/12 07:33:36.607: OK
U_CELL_NET: setting automatic network selection mode...
2024/04/12 07:33:36.627: AT+COPS?
2024/04/12 07:33:36.668:
2024/04/12 07:33:36.668: +COPS: 0,0,"Telekom.de",7
2024/04/12 07:33:36.668:
2024/04/12 07:33:36.668: OK
2024/04/12 07:33:36.688: AT+CFUN=1
2024/04/12 07:33:36.729:
2024/04/12 07:33:36.729: OK
2024/04/12 07:33:36.749: AT+CREG?
2024/04/12 07:33:36.789:
2024/04/12 07:33:36.789: +CREG: 2,1,"2F11","01B18207",7
2024/04/12 07:33:36.790:
2024/04/12 07:33:36.790: OK
7: RegH
2024/04/12 07:33:37.090: AT+CGREG?
2024/04/12 07:33:37.130:
2024/04/12 07:33:37.130: +CGREG: 2,4
2024/04/12 07:33:37.130:
2024/04/12 07:33:37.130: OK
-1: OoC
2024/04/12 07:33:37.431: AT+CEREG?
2024/04/12 07:33:37.471:
2024/04/12 07:33:37.471: +CEREG: 4,1,"2F11","10","1B18207",7,,,"00000000","01100000"
2024/04/12 07:33:37.472:
2024/04/12 07:33:37.472: OK
7: RegH
2024/04/12 07:33:37.772: AT+COPS=3,0
2024/04/12 07:33:37.812:
2024/04/12 07:33:37.812: OK
2024/04/12 07:33:37.833: AT+COPS?
2024/04/12 07:33:37.873:
2024/04/12 07:33:37.873: +COPS: 0,0,"Telekom.de",7
2024/04/12 07:33:37.873:
2024/04/12 07:33:37.873: OK
2024/04/12 07:33:37.893: AT+CGATT?
2024/04/12 07:33:37.934:
2024/04/12 07:33:37.934: +CGATT: 1
2024/04/12 07:33:37.934:
2024/04/12 07:33:37.934: OK
2024/04/12 07:33:37.954: AT+CGACT?
2024/04/12 07:33:37.995:
2024/04/12 07:33:37.995: +CGACT: 1,1
2024/04/12 07:33:37.995: +CGACT: 11,0
2024/04/12 07:33:37.995:
2024/04/12 07:33:37.995: OK
2024/04/12 07:33:38.015: AT+CEER
2024/04/12 07:33:38.055:
2024/04/12 07:33:38.056: +CEER: EMM detached
2024/04/12 07:33:38.056:
2024/04/12 07:33:38.056: OK
U_CELL_NET: connected after 4 second(s).
2024/04/12 07:33:41.026: AT+CGACT?
2024/04/12 07:33:41.066:
2024/04/12 07:33:41.066: +CGACT: 1,1
2024/04/12 07:33:41.066: +CGACT: 11,0
2024/04/12 07:33:41.066:
2024/04/12 07:33:41.066: OK
2024/04/12 07:33:41.086: AT+CGPADDR=1
2024/04/12 07:33:41.127:
2024/04/12 07:33:41.127: +CGPADDR: 1,"10.39.187.185"
2024/04/12 07:33:41.127:
2024/04/12 07:33:41.127: OK
U_CELL_NET: IP address "10.39.187.185".
2024/04/12 07:33:41.147: AT+CGCONTRDP=1
2024/04/12 07:33:41.188:
2024/04/12 07:33:41.188: +CGCONTRDP: 1,5,"internet.m2mportal.de","10.39.187.185","","10.74.210.210","10.74.210.211","","",,,1428
2024/04/12 07:33:41.188:
2024/04/12 07:33:41.188: OK
U_CELL_NET: primary DNS address:   "10.74.210.210".
U_CELL_NET: secondary DNS address: "10.74.210.211".
U_CELL_PPP: sent ATD*99***1#[0d]
U_CELL_PPP: received [0d][0a]CONNECT[0d][0a]
U_PORT_PPP: socket connected to module.
.
.
.
U_PORT_PPP: socket disconnected from module (but pppd still connected to socket).
2024/04/12 07:36:37.191: AT+COPS?
2024/04/12 07:36:37.232:
2024/04/12 07:36:37.232: +COPS: 0,0,"Telekom.de",7
2024/04/12 07:36:37.232:
2024/04/12 07:36:37.232: OK
2024/04/12 07:36:37.252: AT+CFUN=4
2024/04/12 07:36:37.474:
2024/04/12 07:36:37.474: OK
2024/04/12 07:36:37.474:
2024/04/12 07:36:37.474: +CREG: 0
2024/04/12 07:36:37.474:
2024/04/12 07:36:37.474: +CGREG: 0
2024/04/12 07:36:37.474:
2024/04/12 07:36:37.474: +CEREG: 0
2024/04/12 07:36:37.494: AT+CREG?
2024/04/12 07:36:37.535:
2024/04/12 07:36:37.535: +CREG: 2,0
2024/04/12 07:36:37.535:
2024/04/12 07:36:37.535: OK
2024/04/12 07:36:37.835: AT+CGREG?
2024/04/12 07:36:37.875:
2024/04/12 07:36:37.875: +CGREG: 2,4
2024/04/12 07:36:37.875:
2024/04/12 07:36:37.875: OK
-1: OoC
2024/04/12 07:36:38.176: AT+CEREG?
2024/04/12 07:36:38.216:
2024/04/12 07:36:38.216: +CEREG: 4,0
2024/04/12 07:36:38.216:
2024/04/12 07:36:38.216: OK
-1: NReg
2024/04/12 07:36:38.516: AT+CGATT?
2024/04/12 07:36:38.557:
2024/04/12 07:36:38.557: +CGATT: 0
2024/04/12 07:36:38.557:
2024/04/12 07:36:38.557: OK
-1: NReg
U_CELL_NET: disconnected.
2024/04/12 07:36:38.577: AT+CEER
2024/04/12 07:36:38.617:
2024/04/12 07:36:38.617: +CEER: EMM detached
2024/04/12 07:36:38.618:
2024/04/12 07:36:38.618: OK
U_CELL_PPP: *** WARNING *** PPP did not terminate, it may not connect next time, you may wish to reboot the module.
U_PORT_PPP: pppd has been disconnected from socket.
U_PORT_PPP: no longer listening for pppd on socket.

[RobMeades]

Done in latest commit to preview branch; define U_PORT_PPP_PRINT_ENABLE to get them. I'm in a bit of a hurry this morning so have not even had chance to compile this, please fix as necessary, you should be able to see what is intended.

[RobMeades]

On the U_CELL_PPP: *** WARNING *** PPP did not terminate, it may not connect next time, you may wish to reboot the module in the log, I put that warning there because, with some module types (SARA-R5 is a case in point), if the link is not closed at PPP level before the CMUX channel that PPP is running over is taken down, under some circumstances, SARA-R5 won't bring the PPP link back up again next time, it kind of gets stuck.

I will have a look at why the warning is appearing in this case (I see it also) but it might not be "real". It is sometimes difficult for the ubxlib code to tell if the PPP link has been shut-down since it is not closing the PPP link itself, it is waiting for the PPP entity at the bottom of the host IP stack to do so and, in the Linux case, it can only infer that pppd has done so by monitoring the PPP traffic, there is no way to get an "I've closed now" event back into the ubxlib code.

[cirdeirf]

Done in latest commit to preview branch; define U_PORT_PPP_PRINT_ENABLE to get them. I'm in a bit of a hurry this morning so have not even had chance to compile this, please fix as necessary, you should be able to see what is intended.

pHex was probably meant to be pStr but otherwise it works. Though I hadn't had the time to look at the output (or understand it). I wanted to try first if the same problems persist when using a LARA-R211. Unfortunately it seems as if I will have to make further changes to make ubxlib work for that module (until now I used ubxlib very sparsely/mainly for AT client handling). U_CELL_NET_CEREG_TYPE = 4 for example does not work on the LARA-R211.

[RobMeades]

Oh, LARA-R2? Not a module that we've ever seen here in ubxlib. Surprised that CEREG type 4 doesn't work though: I would have thought that's basic LTE. You will see from the comments in the code that the choice of CEREG type needs to be done with great care as, because of the way 3GPP have specified the AT commands, it is impossible to tell the difference between the information response to an AT+CEREG request and a +CEREG URC and the encoding of the two responses are different.

[philwareublox]

Hi,
LARA-R211 does not support +CEREG mode 4. Only 0, 1, 2 modes are supported. If you want to change UBXLIB to support mode '3' for this module, you will have to also review the +CEREG response parsing.
BTW, LARA-R211 is now an obsolete module, which has been replaced with LARA-R6, which is supported by UBXLIB.
Phil.

[cirdeirf]

Thanks. Yes, I will look into the functions mentioned in the U_CELL_NET_CEREG_TYPE comment.

Hi, LARA-R211 does not support +CEREG mode 4. Only 1, 2 and 3 modes are supported. If you want to change UBXLIB to support mode '3' for this module, you will have to also review the +CEREG response parsing.

Doesn't 18.36.3 of the AT commands manual say that only modes 0, 1, and 2 are allowed for LARA-R2?
"TOBY-L4 / LARA-R2 / TOBY-R2 - 0 (default value), 1, 2"

BTW, LARA-R211 is now an obsolete module, which has been replaced with LARA-R6, which is supported by UBXLIB. Phil.

Unfortunately, we still have same devices with LARA-R211 modules. So whatever I change has to work for both LARA-R211 and LARA-R6.

[philwareublox]

Hi,
Yes, you are correct. In the notes section it says '3' mode is not supported. I missed this :)
Phil.