MiniPCIe based cellular modules supporting both USB2 and USB3 are not detected in the host system? Such as Sierra Wireless MC74** series, and Telit LM940/LM960 series modules.
From start the PCI-SIG miniPCIe form factor standard only included support for PCIe + USB2 data interface and had designated signal lines for these between host system and the miniPCIe module. Since revision 2.1 of the PCI-SIG miniPCIe standard it is defined that the PCIe data lanes can be shared/used for USB3 also.
Cellular modules mainly rely on USB2 interface but as the cellular throughput speeds have increased, the USB2 can become a bottleneck on LTE Cat 6 modules and higher. To address this, USB3 data interface was introduced on the higher data throughput mobile broadband cellular modules and made available in parallel to USB2 interface. However due to limited amount of pin lanes available in the miniPCIe socket they share location with the PCIe data interface pin lanes.
When the host system and module are powered on, the cellular module will try to probe if USB3 interface is present on the pin lanes and if communication can be established, otherwise the module will revert to using the USB2 data interface instead.
However, in some host systems where PCIe data interface also is implemented on the shared pin lanes, the signals will interfere with the cellular modules probing for USB3 interface making it not fall back to USB2 data interface. This usually result in the cellular module not being detected at all in the host operating system.
The USB3 auto-sensing functionality is enabled by default but can be disabled by using AT commands to write the memory changes to the internal NV memory which is stored between restarts. After the module is restarted it will use only the USB2 pin lanes for data interface. Please also check and validate if the host system BIOS support disabling of the PCIe interface in the miniPCIe socket.
Related AT commands for configuring USB3/USB2 modes:
Telit LM940/LM960 modules:
AT#USBSWITCH=1
AT#REBOOT
For Sierra Wireless MC74 series: (firmware version dependent)
AT!ENTERCND="A710"
AT!USBSPEED=0
AT!RESET
For troubleshooting this issue in hardware, you can try isolating the USB3 data interface pins #23, 25, 31, 33 on the top side of the miniPCIe data cards card socket so no signalling to and from the hosts can occur. This could be done in the board design or with adapter.
The module target region states Global, what does that mean?
When a cellular module is described as "global," it means that the module is designed to operate on multiple cellular networks worldwide. Cellular networks use different technologies and frequency bands in different regions and countries. A global cellular module is capable of supporting multiple frequency bands and typically multiple cellular technologies, allowing it to connect to networks across various regions and countries.
This does not mean that it supports all bands, on all networks, globally, as different operators and networks might have different requirements and approval steps. Reach out to one of our experts if you want to know if the product supports your target deployment region.
What is Remote SIM Provisioning (RSP) and what does SGP standards have to do with it?
The GSM Association (GSMA) is an industry organization that represents the interest of Mobile Network Operators (MNO’s) worldwide. They facilitate consensus and harmonization across the industry by developing common industry standards to make everything work in the mobile area.
SGP is one of these standards that include the specifications for implementation of eUICC and Remote SIM Provisioning (RSP) architecture. Remote SIM Provisioning is what gives your SIM the ability to switch operators over the air.
What are the SGP standards then?
The SGP standards define the different types of Remote SIM Provisioning available on the market. There are slightly different architectures for IoT (M2M) and Consumer provisioning schemes.
SGP.0x – The M2M "Push" RSP
Typically used for M2M/IoT devices where the end-user interaction is limited. The RSP is often initialized via a server who pushes the data to the SIM, hence why it’s sometimes called the push method. This method, however, comes with limitations in that you need to choose a connectivity provider (MNO/MVNO) up-front and sign a contract. You will also have limited ability to completely switch to another provider down the road, as the server managing your SIMs are located with your first choice of provider.
SGP.2x – The Consumer "Pull" RSP
This is what you will find in your smartphone. Because you have a User Interface (UI) and a camera you can scan a QR code provided by your Connectivity Provider (MNO/MVNO) which then downloads (Pulls) an operational profile from an SM-DP+ server. This method comes with limitations in that you need physical access and end-user interaction with your device. You also need a Local Profile Assistant (LPA) and a secondary connection to the internet (example Wi-Fi) to download, and then provision your profile to the SIM card.
SGP.3x – The upcoming standard “Consumer IoT”
SGP.32 is the new eSIM IoT specification created to simplify the eSIM architecture for IoT use cases.
It takes a lot of inspiration from the vastly popular Consumer standard (SGP.22) but will need additional elements; eSIM IoT Remote Manager (eIM) and IoT Profile Assistant (IPA).
In essence, you will be able to either Pull or Push data from your device, or from a server, meaning less technical hurdles to jump through.
This, easily put, means that you will have a less complex way of integrating an eUICC in your application and will have more choices when it comes to control over connectivity providers, even years into your deployments.
What is an eSIM and what is the difference from a traditional SIM card?
eSIM stands for "Embedded Subscriber Identity Module". It is a small chip that contains essential information about the device's identity, such as the mobile network operator and the device's credentials, the same as a traditional plastic SIM-card.
What is the difference between an eSIM and a traditional SIM card?
The main difference is that eSIMs are embedded and therefore cannot be removed or replaced, whereas traditional SIM cards can be swapped out between devices. eSIMs offer more flexibility in terms of network optimization and management, as changing networks can be done remotely.
Which are the benefits of using an eSIM in IoT modules and M2M instead of a regular SIM?
eSIMs provide several benefits:
Cost savings: With eSIMs, manufacturers can reduce their supply chain costs and simplify the deployment of devices in remote or hard-to-reach locations. It reduces the requirement of sending SIM cards and manually installing them. Both cost and time efficient.
Durability: an eSIM is more durable and can withstand vibration and shock.
Improved security: eSIMs have stronger security measures in place than traditional SIM cards, helping to protect sensitive data transmitted over IoT networks. By embedding a SIM, you also prevent unauthorized physical access to the SIM.
Better scalability: eSIMs offer greater scalability and flexibility as M2M devices can be deployed both more quickly and easily without the need for excess ability of the physical SIM cards.
Greater flexibility: Because eSIMs can be managed remotely, M2M devices can change networks more easily, and manufacturers can avoid the logistics of physical SIM card distribution.
Is eSIM and eUICC the same thing?
No. An eSIM is an embedded SIM card.
An eUICC is an Embedded Universal Integrated Circuit Card which is a type of SIM card. More specifically, the eUICC is what makes Remote SIM Provisioning (RSP) work. A SIM card with eUICC functionality can come in all different SIM form factors, from traditional plastic, to eSIM ICs. Read more about Remote SIM Provisioning here
Are there any downsides to using an eSIM in IoT modules and M2M?
Some of potential drawbacks of using eSIMs in IoT modules include:
Limited network coverage: Not all MNOs support eSIMs, and network coverage may be more limited than with traditional SIM cards.
Complexity: While eSIMs offer greater flexibility and scalability, they also require more complex management systems and security measures.
Cost: While eSIMs can provide cost savings in the long run, there may be higher upfront costs associated with initial deployment and management.
How can I control my Bluetooth devices on linux?
The easiest way of controlling Bluetooth devices on a Linux host is by using the Bluez package which can be found at the below link: https://github.com/bluez/bluez
It is natively supported from kernel 4.4 and by installing the bluez-utils package you can use the command line tool, bluetoothctl for configuring and pairing your Bluetooth.
Make sure that the bluetooth.service is running on your host device which can be checked with the command,
$ sudo systemctl status bluetooth.service
and started with,
$ sudo systemctl start bluetooth.service
In addition, make sure that the drivers are properly installed and loaded. Sometimes, WiFi drivers only include drivers for WLAN over PCI and an additional set of drivers are needed for Bluetooth to function in parallell over USB.
The package can support earlier kernel verision by backporting the package which supports the below basic features:
3.13 basic bluetooth classic and LE functionality
3.10 basic bluetooth classic
For basic troubleshooting, the Arch Linux wiki has a thorough guide at the following link:
What diagnostics information is needed when troubleshooting WiFi?
In order to ease the troubleshooting of technical problems and understand your end-product or application and its usage scenario we ask you to please provide the following information when creating a technical support ticket at: techship.com/technical_support/
Please give a detailed problem description and in what precise circumstances it is present.
Describe the host system:
-Hardware (system board, processor architecture, other peripheral devices...)
-Operating system with detailed versions (E.g. Windows version and build, Linux distribution, kernel version)
-Drivers used and versions (Linux: out-of-tree vendor drivers or in-kernel drivers?)
-Connection script and connection settings, including e.g. hostapd configuration
Details from the Wi-Fi module label:
-Model
-SKU/BOM or P/N code
-MAC
For Linux systems, capture terminal logs from commands with sudo prefix:
uname –a
ifconfig -a
dmesg
Iw list
lshw -c network
ip route
For PCIe devices:
lspci
lspci –vv
For USB devices:
lsusb
lsusb -t
ls -l /dev/serial/by-id
ls -l /sys/bus/usb-serial/devices
How can I quickly get up and running with my Wi-Fi device using the Network Manager tool in Linux?
Using Network Manager to setup a wifi connection is quick and automatic once the configuration is in place. Install the Wi-Fi card and make sure the device shows up in your Linux system with:
lspci *******************
00:1e.0 SD Host controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series SDIO Controller (rev 0d)
00:1f.0 ISA bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Low Pin Count Interface (rev 0d)
00:1f.1 SMBus: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series SMBus Controller (rev 0d)
01:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
*******************
The Qualcomm device we have plugged in here shows up as expected. If that is not the case, make sure that the card is properly seated, pin-compatible and that the host system has correct drivers installed!
What drivers are being utilized can be found using the index in the previous code snippet:
sudo find /sys | grep drivers.*01:00.0/sys/bus/pci/drivers/ath10k_pci/0000:01:00.0
Here we see that the device is using the kernel built-in wifi driver ath10k which is compatible with the device used here.
Next step is to check that NM finds the device:
sudo nmcliwlp1s0: unavailable
"Qualcomm Atheros QCA986x/988x"
wifi (ath10k_pci), 04:F3:21:4F:0A:A2, sw disabled, hw, mtu 1500
Here it is found by NM but in disabled state, activate it using:
sudo nmcli radio wifi on //activate wifiwlp1s0: disconnected
"Qualcomm Atheros QCA986x/988x"
0 connections available
wifi (ath10k_pci), 04:F3:21:4F:0A:A2, hw, mtu 1500
sudo nmcli dev wifi //lists available wifi access points
sudo nmcli dev wifi connect 'SSID' password 'password' //connect to a network/access pointTo setup an automatic connection instead of manual direct-connect follow the below steps:
nmcli con add con-name 'wifi' ifname 'wlp1s0' type wifi ssid 'SSID'
nmcli con modify 'wifi' wifi-sec.key-mgmt 'wpa-psk' //Add security layer matching the access point
nmcli con modify 'wifi' wifi-sec.psk 'password' //Add the access point password to the connection
nmcli con up 'wifi'//Activate the connection
nmcli dev set 'wlp1s0' autoconnect yes //Set connection to autoconnectThere are also a number of different settings that can be changed to your liking. Below you can see an example of how to set which band an existing connection should use:
nmcli connection edit wifi
goto wifi //Access general wifi settings
goto band //Access band settings
set a //Sets the band to 5GHz
save //Persistent save
quit //Quit the interactive terminal
sudo systemctl restart network-manager //Restart to apply settingsMore information available at: https://wiki.archlinux.org/title/NetworkManager#nmcli_examples
Note: Tested on Ubuntu 22.04 kernel 5.19
Example on how to control a Techship PC201 adapter via GPIO signals when it is assembled as a hat on a Raspberry PI4.
Example on how to control a Techship PC201 adapter via GPIO signals when it is assembled as a hat on a Raspberry PI4.
Hardware:
Assemble the PC201 adapter as a hat for the Raspberry PI4 unit and Assemble a 40-pin riser header between the PCBs.
To use signals from the GPIO socket to control the PC201 adapter, place jumper links on the PC201's pin headers mentioned below, depending on the function you want be able to control by GPIO.
Host system OS / software:
In this example we are running Raspberry Pi OS and using the raspi-gpio tool to configure and control the Raspberry PIs GPIO signals.
In recent versions of Raspberry Pi OS the raspi-gpio tool have been renamed to pinctrl but support same commands and attributes.
Configure the Raspberry Pi's GPIO 26,27 for output functionality with pull down and GPIO 16 for output functionality with no pull down.
sudo raspi-gpio set 26,27 op pd
sudo raspi-gpio set 16 op pn
sudo pinctrl set 26,27 op pd
sudo pinctrl set 16 op pn
GPIO 27 - Controlling the PC201 adapters power IC enable signal
(Ensure J7 have a jumper link between pin 2-3 on PC201 PCB)
Enable signal on:
sudo raspi-gpio set 27 dh
sudo pinctrl set 27 dh
Enable signal Off:
sudo raspi-gpio set 27 dl
sudo pinctrl set 27 dl
Some modems will not boot up after power supply is enabled if not the wireless disable signal is also set to high/normal mode state.
GPIO 16 - Controlling the miniPCIe sockets Wireless Disable signal
(Ensure J4 have a jumper link on PC201 PCB)
Wireless disable Off: (normal operational mode)
sudo raspi-gpio set 16 dh
sudo pinctrl set 16 dh
Wireless disable on: (wireless disabled mode)
sudo raspi-gpio set 16 dl
sudo pinctrl set 16 dl
GPIO 26 Controlling the miniPCIe sockets Hardware Reset signal
(Ensure J8 have a jumper link on PC201 PCB)
Activate reset signal:
sudo raspi-gpio set 26 dh
sudo pinctrl set 26 dh
Release reset signal:
sudo raspi-gpio set 26 dl
sudo pinctrl set 26 dl
For detailed information of the GPIO control signals routing please refer to the Techship PC201 adapter hardware guide.
For details about cellular modem behaviour to control signals, timings, etc. please refer to the modem manufacturers hardware guide.
How do you configure a wifi network using IW and IP utilities with wpa_supplicant in Linux?
IW is a configuration utility for wireless devices and supports most if not all drivers implemented officially in the Linux kernel. It can be used to setup and connect to wifi networks as well as configure access points/hotspots on supported modems. It replaces the older iwconfig utility which is not recommended for use.
The IP utility is a routing tool that is used to configure network interfaces on your linux host and to configure bridges between devices.
To list all wireless devices the command iw dev or /sbin/iw dev can be used and the response could look something like this:
phy#0
Interface wlp1s0
ifindex 4
wdev 0x1
addr 04:f0:21:3f:0a:a3
type managed
txpower 23.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 0 0 0 0 0 0 0
To make sure that the device is up and running issue:
ip link show wlp1s0
In this case, the wireless device is wlp1s0 and for which command return the following:
4: wlp1s0: UP> mtu 1500 qdisc noqueue state DOWN mode DORMANT group default qlen 1000
link/ether 04:f2:24:3d:2b:d9 brd ff:ff:ff:ff:ff:ff
If the device is not active and 'UP' it can be set active using:
sudo ip link set wlp1s0 up
To see if the device is connected to a network or not, issue:
iw wlp1s0 link
Connected to b3:fa:d4:32:64:12 (on wlp1s0)
SSID: Techship
freq: 5200
RX: 4602636 bytes (28600 packets)
TX: 17664 bytes (150 packets)
signal: -53 dBm
rx bitrate: 360.0 MBit/s VHT-MCS 8 40MHz short GI VHT-NSS 2
tx bitrate: 6.0 MBit/s
bss flags: short-slot-time
dtim period: 3
beacon int: 100
If not, it simply returns 'Not connected'
To see available wifi networks in range use the scan function of the modem:
iw wlp1s0 scan
********************SNIPPET*******************
BSS d0:21:f9:32:64:bb(on wlp1s0)
last seen: 7092.798s [boottime]
TSF: 1755910453320 usec (20d, 07:45:10)
freq: 5220
beacon interval: 100 TUs
capability: ESS Privacy SpectrumMgmt ShortSlotTime RadioMeasure (0x1511)
signal: -71.00 dBm
last seen: 1704 ms ago
Information elements from Probe Response frame:
SSID: Techship
Supported rates: 6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0
DS Parameter set: channel 44
Country: SE Environment: Indoor/Outdoor
Channels [36 - 36] @ 23 dBm
Channels [40 - 40] @ 23 dBm
Channels [44 - 44] @ 23 dBm
Channels [48 - 48] @ 23 dBm
Channels [52 - 52] @ 23 dBm
Channels [56 - 56] @ 23 dBm
Channels [60 - 60] @ 23 dBm
Channels [64 - 64] @ 23 dBm
Channels [100 - 100] @ 30 dBm
Channels [104 - 104] @ 30 dBm
Channels [108 - 108] @ 30 dBm
Channels [112 - 112] @ 30 dBm
Channels [116 - 116] @ 30 dBm
Channels [120 - 120] @ 30 dBm
Channels [124 - 124] @ 30 dBm
Channels [128 - 128] @ 30 dBm
Channels [132 - 132] @ 30 dBm
Channels [136 - 136] @ 30 dBm
Channels [140 - 140] @ 30 dBm
RSN: * Version: 1
* Group cipher: CCMP
* Pairwise ciphers: CCMP
* Authentication suites: PSK
* Capabilities: 1-PTKSA-RC 1-GTKSA-RC (0x0000)
BSS Load:
* station count: 4
* channel utilisation: 19/255
available admission capacity: 31250 [32us]
********************SNIPPET*******************
Make sure that the country parameter is correct, if not you can set the country code with the following:
sudo iw reg set SE
This ensures that the modem follows country-specific frequency regulations!
To connect to a password protected network (e.g. WPA version 1,2 or 3) a configuration file called wpa_supplicant.conf that handles the security protocol is needed:
wpa_passphrase SSID >> /etc/wpa_supplicant.conf
enter wifi password and hit enter
The generated output would look something like this:
network={
ssid="Techship"
#psk="password"
psk=5abc7d89f8e9d8c7aa6b8c7d223e520d26a13e932bf0acb1d4580461d6d2ba8d
}
If sudo privileges aren't enough; login as root with: sudo -s and issue the above again.
When the file has been created it can be run in the background using:
sudo wpa_supplicant -B -D wext -i wlan0 -c /etc/wpa_supplicant.conf
Then check once more if the connection was successful with:
iw wlp1s0 link
The last step is to request an IP adress from the host server via DHCP client:
dhclient wlp1s0
Issue ip addr show wlp1s0 to check assigned ip address and
if you have recieved one you are ready to surf!
For further information and features see:
en:users:documentation:iw [Linux Wireless] (kernel.org)
wpa_supplicant - ArchWiki (archlinux.org)
networking:iproute2 [Wiki] (linuxfoundation.org)
P.S.
For basic applications the use of Network Manager is simpler, mostly automatic and included in most common distributions of Linux, see the below FAQ for more info!
https://techship.com/faq/wifi-linux-network-manager-quick-start-guide/
Note: Tested on Ubuntu 22.04 kernel 5.19
Example on how to control a Techship MC201 adapter via GPIO signals when it is assembled as a hat on a Raspberry PI4.
Example on how to control a Techship MC201 adapter via GPIO signals when it is assembled as a hat on a Raspberry PI4.
Hardware:
Assemble the MC201 adapter as a hat for the Raspberry PI4 unit and Assemble a 40-pin riser header between the PCBs.
To use signals from the GPIO socket to control the MC201 adapter, place jumper links on the MC201's pin headers mentioned below, depending on the function you want be able to control by GPIO.
Host system OS / software:
In this example we are running Raspberry Pi OS and using the raspi-gpio tool to configure and control the Raspberry PIs GPIO signals.
In recent versions of Raspberry Pi OS the raspi-gpio tool have been renamed to pinctrl but support same commands and attributes.
Configure the Raspberry Pi's GPIO pins 16,22,26,27 for output functionality with no pull down.
sudo raspi-gpio set 16,22,26,27 op pn
sudo pinctrl set 16,22,26,27 op pn
GPIO 27 - Controlling the MC201 adapters power IC enable signal
(Ensure J7 have a jumper link between pin 2-3 on MC201 PCB)
Enable signal on:
sudo raspi-gpio set 27 dh
sudo pinctrl set 27 dh
Enable signal Off:
sudo raspi-gpio set 27 dl
sudo pinctrl set 27 dl
GPIO 22 - Controlling the M.2 sockets Full Card Power Off signal
(Ensure J2 have a jumper link between pin 1-2 on MC201 PCB)
Power on card:
sudo raspi-gpio set 22 dh
sudo pinctrl set 22 dh
Power off card:
sudo raspi-gpio set 22 dl
sudo pinctrl set 22 dl
GPIO 16 - Controlling the M.2 sockets Wireless Disable signal
(Ensure J4 have a jumper link between pin 1-2 on MC201 PCB)
Wireless disable Off:
sudo raspi-gpio set 16 dh
sudo pinctrl set 16 dh
Wireless disable on:
sudo raspi-gpio set 16 dl
sudo pinctrl set 16 dl
GPIO 26 Controlling the M.2 sockets Hardware Reset signal
(Ensure J8 have a jumper link on MC201 PCB)
Activate reset signal:
sudo raspi-gpio set 26 dh
sudo pinctrl set 26 dh
Release reset signal:
sudo raspi-gpio set 26 dl
sudo pinctrl set 26 dl
For detailed information of the GPIO control signals routing please refer to the Techship MC201 adapter hardware guide.
For details about cellular modem behaviour to control signals, timings, etc. please refer to the modem manufacturers hardware guide.
How is the active antenna feature enabled on the Sierra Wireless EM7590 module?
The active GNSS antenna feature on the Sierra Wireless EM7590 module sets 3.3V on the GNSS antenna port.
First, make sure that the GNSS feature is enabled. This can be checked by using the following command:
AT!CUSTOM?If GNSS is enabled, the return of this command will contain:
"GPSENABLE" 0x01If GNSS isn't enabled, it can be enabled with the following commands:
AT!ENTERCND="A710"
AT!CUSTOM="GPSENABLE",1The EM7590 also supports configuring the GNSS receiver path to the AUX antenna port. However, the active antenna feature is only available on the dedicated GNSS antenna port so make sure the receiver path is set to the dedicated GNSS port if you wish to utilize the active GNSS antenna feature. This setting also be checked with the same command as before:
AT!CUSTOM?If the return doesn't contain:
"GPSSEL" 0x01Then the GNSS receiver path is set to the dedicated GNSS antenna port.
If the above criteria is met, the active GNSS antenna feature can be enabled by sending the following command:
AT+WANT=1Please refer to the EM7590 AT Command Guide for more details about the commands mentioned in this FAQ,