Nova-R410 Cat-M1 timeout waiting for message status

Connectivity LTE Cat-M1 & NB-IoT
1

We have a R410 on an embedded ARM hardware. When plugged in, the serial device nodes do not come up. Running

    modprobe usbserial vendor=0x05c6 product=0x90b2

gets three nodes: /dev/ttyUSB0, /dev/ttyUSB1, and /dev/ttyUSB2 populated.

Now I can run example-serial-interface.py ok. But the example-send-message.py will fail without getting a URC response to the socket write.

The bottom part of the failed command response is:

....
DEBUG: [AT+CGMM]
DEBUG: {AT+CGMM}
DEBUG: {SARA-R410M-02B}
DEBUG: {}
DEBUG: {OK}
DEBUG: [AT+CEREG?]
DEBUG: {AT+CEREG?}
DEBUG: {+CEREG: 2,1,"2B0C","1AE320C",8}
DEBUG: {}
DEBUG: {OK}
INFO: Connecting to: cloudsocket.hologram.io
INFO: Port: 9999
DEBUG: [AT+USOCR=6]
DEBUG: {AT+USOCR=6}
DEBUG: {+USOCR: 0}
DEBUG: {}
DEBUG: {OK}
DEBUG: [AT+USOCO=0,"cloudsocket.hologram.io",9999]
DEBUG: {AT+USOCO=0,"cloudsocket.hologram.io",9999}
DEBUG: {OK}
INFO: Connect socket is successful
INFO: Sending message with body of length 88
DEBUG: Send: b'C8912230102107853834 251690 569752 M\x01novam-0.9.0\x00TTOPIC1\x00TTOPIC2\x00Bone two three!\x00\x00'
DEBUG: [AT+UDCONF=1,1]
DEBUG: {AT+UDCONF=1,1}
DEBUG: {OK}
DEBUG: [AT+USOWR=b'0,88,"43383931323233303130323130373835333833342032353136393020353639373532204d016e6f76616d5f74656c75732d302e392e300054544f504943310054544f5049433200426f6e652074776f207468726565210000"']
DEBUG: {AT+USOWR=0,88,"43383931323233303130323130373835333833342032353136393020353639373532204d016e6f76616d5f74656c75732d302e392e300054544f504943310054544f5049433200426f6e652074776f207468726565210000"}
DEBUG: {+USOWR: 0,88}
DEBUG: {}
DEBUG: {OK}
DEBUG: [AT+UDCONF=1,0]
DEBUG: {AT+UDCONF=1,0}
DEBUG: {OK}
Traceback (most recent call last):
  File "example-send-msg.py", line 44, in <module>
    timeout = 3)
  File "/root/hologram-python/Hologram/HologramCloud.py", line 112, in sendMessage
    result = super().sendMessage(output, timeout)
  File "/root/hologram-python/Hologram/CustomCloud.py", line 78, in sendMessage
    resultbuf = self.network.send_message(message)
  File "/root/hologram-python/Hologram/Network/Cellular.py", line 129, in send_message
    return self.modem.send_message(data)
  File "/root/hologram-python/Hologram/Network/Modem/Modem.py", line 251, in send_message
    raise SerialError('Timeout occurred waiting for message status')

On a laptop I can get it to continue with the following response. That’s why I think the missing URC is the problem or directed related to the problem:

DEBUG: {}
DEBUG: {+UUSORD: 0,2}
DEBUG: URC! +UUSORD: 0,2
DEBUG: handleURC state: 0
DEBUG: [AT+UDCONF=1,1]
DEBUG: {AT+UDCONF=1,1}
DEBUG: {OK}
DEBUG: [AT+USORD=0,2]
DEBUG: {AT+USORD=0,2}
DEBUG: {}
DEBUG: {+USORD: 0,2,"3030"}
DEBUG: {OK}
DEBUG: [AT+UDCONF=1,0]
DEBUG: {AT+UDCONF=1,0}
DEBUG: {OK}
INFO: Sent.
DEBUG: [AT+USOCL=0]
DEBUG: {AT+USOCL=0}
DEBUG: {OK}
INFO: Socket closed.
RESPONSE MESSAGE: Message sent successfully

Any idea how to get it fixed?

I’ve noticed on the laptop, only two usb serial interfaces are created, not three. That might be related to the problem.

I’m also running ppp on this embedded hardware without a success. It could be related.

2

That doesn’t appear to be a problem with the serial interface since it is able to talk to the modem to run the AT commands. Does the hologram send command work? Try running sudo hologram send test

1 Like
3

Thansk for the quick response. Will run the send test command and update.

4

BTW, I’m not sure if usbserial is the correct driver to load there. We use the option driver which I think is a specific type of that.
The SDK should load it for you but not sure if that works on Arduino. On the Pi, we do the equivalent of this to force the correct driver:

sudo modprobe option
sudo sh -c 'echo -n 05c6 90b2 > /sys/bus/usb-serial/drivers/option1/new_id'
5

Ok, I’ve only enabled the usb-serial driver. Will load the option driver too.

Very much appreciations.

6

Reuben, A question about the option driver dependency.

On laptop, usbserial, usb_wwan, options are loaded in a chain. Is the usb_wwan driver also required?

We have only the usb-serial-simple.ko and usbserial.ko built under the drivers/usb/serial directory. Maybe I’ll enable the usb_wwan too to give it a try.

7

I don’t think that one is required but yeah it does seem to load by default on most debian distributions

8

After compiling the option module and adding the R410 USB IDs, it looks to work well now.

A later commit from the main stream kernel needs to be applied like:

+++ drivers/usb/serial/option.c 2020-02-24 23:17:15.823935662 +0000
@@ -675,6 +675,10 @@
        .reserved = BIT(4) | BIT(5),
 };

+static const struct option_blacklist_info ublox_r410m_blacklist = {
+       .reserved = BIT(1) | BIT(3),
+};
+
 static const struct usb_device_id option_ids[] = {
        { USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
@@ -1175,6 +1179,12 @@
        { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */
+
+       /* These u-blox products use Qualcomm's vendor ID */
+       #define UBLOX_PRODUCT_R410M                    0x90b2
+       { USB_DEVICE(QUALCOMM_VENDOR_ID, UBLOX_PRODUCT_R410M),
+         .driver_info = (kernel_ulong_t)&ublox_r410m_blacklist },
+
        /* Quectel products using Qualcomm vendor ID */
        { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC15)},

When a R410 is inserted to a USB port, it enumerates to have 4 USB interfaces. The patch, makes the kernel skip interface 1 and 3, only link interface 0 and 2 to a node named /dev/ttyUSBx. That’s why only two device nodes are created when it works.

Without the patch, all 4 USB interfaces are probed against potential USB class drivers. That might have messed the u-blox modules up causing it to fail later subtly. Though I have not extensively tested to verify this. It should be safe the just apply the patch. Unless there are other things missing here.