Cannot connect using UART, only USB (cannot even find device over UART)

basvanwesting

Hi,

I using the vintage_net_mobile library to establish a CAT-M1 cellular connection with the Sixfab Raspberry Pi Cellular IoT HAT.

If I understand correctly UART is enabled by default on the device v1.1.0. For the v1.3.0 HAT, UART is disabled by default and 2 jumpers need to be soldered. But I have the v1.1.0 version (and these jumpers don’t even exist).

Also UART doesn’t seem to have any non-default requirements for Nerves on rpi4.

Does anybody have experience with this kind of issue, to help me out a bit?

Using the USB connection this works beautifully:

iex> VintageNet.get_by_prefix(["interface", "ppp0"])
[
  {["interface", "ppp0", "addresses"],
   [
     %{
       address: {100, 85, 118, 2},
       family: :inet,
       netmask: {255, 255, 255, 255},
       prefix_length: 32,
       scope: :universe
     }
   ]},
  {["interface", "ppp0", "config"],
   %{
     type: VintageNetMobile,
     vintage_net_mobile: %{
       modem: VintageNetMobile.Modem.QuectelBG96,
       scan: [:lte_cat_m1],
       service_providers: [%{apn: "wm"}]
     }
   }},
  {["interface", "ppp0", "connection"], :internet},
  {["interface", "ppp0", "hw_path"], "/devices/virtual"},
  {["interface", "ppp0", "lower_up"], true},
  {["interface", "ppp0", "mobile", "access_technology"], "CAT-M1"},
  {["interface", "ppp0", "mobile", "band"], "LTE BAND 8"},
  {["interface", "ppp0", "mobile", "channel"], 3700},
  {["interface", "ppp0", "mobile", "cid"], 2639383},
  {["interface", "ppp0", "mobile", "iccid"], "..."},
  {["interface", "ppp0", "mobile", "imsi"], "..."},
  {["interface", "ppp0", "mobile", "lac"], 260},
  {["interface", "ppp0", "mobile", "mcc"], 204},
  {["interface", "ppp0", "mobile", "mnc"], 16},
  {["interface", "ppp0", "mobile", "network"], "T-Mobile NL"},
  {["interface", "ppp0", "mobile", "signal_4bars"], 4},
  {["interface", "ppp0", "mobile", "signal_asu"], 30},
  {["interface", "ppp0", "mobile", "signal_dbm"], -53},
  {["interface", "ppp0", "present"], true},
  {["interface", "ppp0", "state"], :configured},
  {["interface", "ppp0", "type"], VintageNetMobile}
]

It does claim 4 USB slots, but I’m not sure whether that is not normal.

iex()> Circuits.UART.enumerate
%{
  "ttyAMA0" => %{},
  "ttyS0" => %{},
  "ttyUSB0" => %{
    description: "Qualcomm CDMA Technologies MSM",
    manufacturer: "Qualcomm, Incorporated",
    product_id: 662,
    serial_number: "...",
    vendor_id: 11388
  },
  "ttyUSB1" => %{
    description: "Qualcomm CDMA Technologies MSM",
    manufacturer: "Qualcomm, Incorporated",
    product_id: 662,
    serial_number: "...",
    vendor_id: 11388
  },
  "ttyUSB2" => %{
    description: "Qualcomm CDMA Technologies MSM",
    manufacturer: "Qualcomm, Incorporated",
    product_id: 662,
    serial_number: "...",
    vendor_id: 11388
  },
  "ttyUSB3" => %{
    description: "Qualcomm CDMA Technologies MSM",
    manufacturer: "Qualcomm, Incorporated",
    product_id: 662,
    serial_number: "...",
    vendor_id: 11388
  }
}

But then I disconnect the USB, the modem cannot be found over UART alone.

iex(16)> Circuits.UART.enumerate
%{"ttyAMA0" => %{},  "ttyS0" => %{}}

It states as not present:

iex(5)> VintageNet.Info.info
VintageNet 0.9.2

All interfaces:       ["eth0", "lo", "wlan0", "wwan0"]
Available interfaces: ["wlan0"]

Interface ppp0
  Type: VintageNetMobile
  Present: false
  Configuration:
    %{
      type: VintageNetMobile,
      vintage_net_mobile: %{
        modem: VintageNetMobile.Modem.QuectelBG96,
        scan: [:lte_cat_m1],
        service_providers: [%{apn: "wm"}]
      }
    }

I did build a custom system-rpi4 with PPP and additional USB flags enabled as stated in the vintage_net_mobile docs. See GitHub - basvanwesting/custom_rpi4: nerves_system_rpi4 for mobile · GitHub for that custom system-rpi4 setup.

I did find a small deviation from the docs there as the CONFIG_USB_NET_CDC_NCM flag cannot be enabled explicitly through make linux-menuconfig, but seems implicitly enabled though CONFIG_USB_NET_HUAWEI_CDC_NCM, which also enabled CONFIG_USB_USBNET). So I just edited the linux-4.19.defconfig manually. But that doesn’t seem related. I just mentioned it for completeness.

Regards, Bas

5 comments

/nerves #vintage_net #vintage_net_mobile

0 1898 5

2020-11-17 13:31:54 UTC

Showing Posts 1 to 5

Show Best Posts
Show All (oldest first)
Show All (newest first)

fhunleth

Co-author of Nerves

I have not used the Sixfab board. I have used the Quectel BG96, but only the USB connection. To use the UART connection instead, I’d create a new vintage_net_mobile modem implementation. Since there’s only one serial port, that one has to belong to the PPP connection. That means that the status pollers need to be turned off. I.e., no signal strength reports when connected. This issue turned out to be a non-starter for my company so I never implemented it.

My first try for the new modem implementation would be to remove required "wwan0" interface to enumerate (see VintageNet.Interface.RawConfig — vintage_net v0.13.12). Continue to use ppp0 for the ifname, but without the required interface, vintage_net will think that the modem is always ready to configure and use even if ppp0 doesn’t exist. Then keep the code to bring up the PPP connection, but point it to ttyAMA0 or ttyS0 (assuming that’s where the UART is connected). Retries are handled automatically be vintage_net, but you can tweak the timeouts in the raw config if you don’t like them. My hope is that this would get something for you that enables data to flow. You may want to look into vintage_net’s power management feature if you need to toggle a GPIO to turn the modem off and on. I’ve used it to get the modem unstuck if there are too many retries or to power it off completely when unused. From there, I’d look into adding AT commands to pull of modem status before the PPP connection is made, but that would require more thought - maybe the PPP chat script could do it and some code could be added to parse the results.

Frank

Post #1

basvanwesting

Hi @fhunleth,

Thanks for your help! It is interesting to know that USB is a viable approach. I though it was mainly for debugging purposes. I’m perfectly happy not using the UART, I just assumed you should use UART for any HAT style boards (since the are HAT’s, not dongles). Can I conclude that USB is simply better/easier for cellular interfaces?

Do you use something like a BG96 USB Dongle yourself? These are about half the price in comparison to the BG96 HAT boards, so if USB is in any way preferable to UART, that seems like a win/win.

If so, could you give a quick OK/NOK about the 4 identical USB listings on ttyUSB0-3 returned by Circuits.UART.enumerate? That does seem a bit wierd to me.

Post #2

fhunleth

Co-author of Nerves

We (my company, that is) buy BG96 MiniPCIe modules in bulk from Quectel. The MiniPCIe connector has the USB signals on it. This is also on a custom board. USB to MiniPCIe adapter boards exist. I’ve only used them for prototyping, though.

As for USB vs. UART, I think it depends on the modem which is easier. Some cellular modems have particularly annoying USB interfaces that require setup via usb_modeswitch to use. On the other hand, with USB, you have more options than just AT commands and PPP for connections.

What you’re seeing with 4 USB tty ports showing up is correct. This is the default Linux/Quectel driver setup. Two are hardcoded to support AT commands and PPP connections. I haven’t used the other two ttys.

One thing to note: There’s a recent Linux kernel update that changes the ttys that show up. The Nerves core team tries to keep the Linux kernel pretty up to date on kernel LTS branches, but hasn’t gotten to that one, and we’re considering patching out that change to avoid breaking the current Quectel LTE modem support. However, this isn’t a long term solution and there’s proof-of-concept code floating around to support the QMI interface to the Quectel modems and to other USB-connected modems. IMHO, QMI is just a better way of interfacing with these devices than using AT/PPP over the tty ports and once I find someone to help push it over the edge or I have time myself, I’d like to switch.

Post #3

basvanwesting

Hi @fhunleth,
Thanks for the all the information again. I’m definitely interested in the QMI interface. But I wouldn’t be of much help, since that is way above my paygrade . So I’ll stick with the USB approach for now.

Post #4

basvanwesting

I think I should have said “above my level of expertise” instead “above my paygrade”. The latter indicates a lack of commitment, which was not the case. Still learning as non-native speaker…

Post #5

— All posts loaded —