You can use the Network Manager command line interface to create an open hotspot using this command:
nmcli con add con-name open_hotspot ifname wlan0 type wifi ssid yourSSID mode ap wifi.band bg wifi.channel 6 ipv4.method shared
60 Series 802.11ac Wi-Fi + Bluetooth 5.1 M.2 module (PCIE Wi-Fi, USB interface)
Name | Part | Type | Last Updated |
---|---|---|---|
Datasheet - ST60-2230C-P and ST60-2230C-PU | ST60-2230C-PU | Datasheet | 08/03/2022 |
Product Brief - 60 Series.pdf | ST60-2230C-PU | Product Brief | 05/02/2022 |
Distributor | Part | In Stock | Region | Buy |
---|---|---|---|---|
Avnet | ST60-2230C-PU | 3800 | North America | Buy Now |
DigiKey | ST60-2230C-PU | 793 | North America | Buy Now |
DigiKey | ST60-2230C-PU | 793 | North America | Buy Now |
Mouser | ST60-2230C-PU | 212 | North America | Buy Now |
Mouser | ST60-2230C-PU | 212 | North America | Buy Now |
Farnell | ST60-2230C-PU | 115 | EMEA | Buy Now |
Arrow Electronics | ST60-2230C-PU | 0 | North America | Buy Now |
Future Electronics | ST60-2230C-PU | 0 | North America | Buy Now |
Future Electronics | ST60-2230C-PU | 0 | North America | Buy Now |
You can use the Network Manager command line interface to create an open hotspot using this command:
nmcli con add con-name open_hotspot ifname wlan0 type wifi ssid yourSSID mode ap wifi.band bg wifi.channel 6 ipv4.method shared
The m.2 used on our Wi-Fi modules is an E-key. Review the PCI Express M.2 Specification from the PCI-SIG website for more information.
This can be found by reviewing the release notes for the specific product on GitHub.
Yes as new kernels are updated in Ubuntu automatically it will break backports and will need to be reinstalled.
Laird modules can be used on a Ubuntu system with a kernel version that is supported by Laird backports.
To check, find the kernel version of the Ubuntu system and then check the release notes of the products to see if the latest backports supports that kernel.
Inside the LE Menu, the PHY rate can be specified with the
-t [1,2]
option. Use 1 for 1MPHY and 2 for 2MPHY.
Yes, for Classic Bluetooth the BTLRU can put the module in Device Test Mode by sending the
tm
command.
No, it's not possible to do an unmodulated carrier with BTLRU.
Configuring the ST60 for hostapd to take advantage of it's max data rate requires a bit of setup. For hostapd to take advantage it has to know all the capabilities of the radio which can be pull from 'iw list'. One will need to convert the capabilities from 'iw list' to ht_capab and vht_capab. To help do this conversion reference the hostapd full config documentation.
Note: hostapd is not officially supported at this time, but wpa_supplicant setup as an AP is support via the sterling-supplicant which can be obtained here: Sterling-60.
Below is a sample working configuration for the ST60.
# hostapd configuration
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
interface=wlan0
driver=nl80211
# IEEE 802.11
ssid=hostAPD
hw_mode=a
channel=149
max_num_sta=12
auth_algs=1
# DFS
country_code=US
ieee80211d=1
ieee80211h=1
# IEEE 802.11n
ieee80211n=1
ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][RX-STBC1][DSSS_CCK-40][MAC-AMSDU-3839]
# IEEE 802.11ac
ieee80211ac=1
vht_oper_chwidth=1
vht_capab=[MAX-MPDU-3895][RXLDPC][SHORT-GI-80][RX-STBC-1][TX-ANTENNA-PATTERN][RX-ANTENNA-PATTERN]
vht_oper_centr_freq_seg0_idx=155
# IEEE 802.11i
wpa=2
wpa_key_mgmt=WPA-PSK
wpa_passphrase=password1
rsn_pairwise=CCMP
The unused antenna port must be terminated with a 50 ohm load. A 1/4 Watt resistor is recommended. For the u.fl version of the module, it might be more cost-effective to just use one of the certified antennas. It's not easy to find an affordable 50 ohm resistor that plugs into the u.fl connector.
The shelf life statements are essentially to prevent mishandling of the product and not storing it properly. If the modules are still sealed in the package, stored at the proper temperature and have not been exposed to moisture they should be fine. However, when working with modules beyond their shelf life you MUST bake the modules before populating the them to your board. Failure to bake the modules could result in the yield rate dropping down lower than expectation due to popcorn or de-lamination on the modules. It is recommended that you follow IPC/JEDEC J-STD-033 which is the general standard for the handling, packing, shipping and use of moisture/reflow sensitive surface mount devices.
Our main concern is around the castellation/pads which solder the module to the board. It is imperative those pads do not get tarnished, as this would cause soldering issues. Humidity can affect solderability as well, as if there is any excess moisture in the solder on the module, during reflow of the module to the board, steam balls can essentially explode the solder and sometimes result in an open circuit (or possibly a short circuit).
As long as all of the moisture handling and temperature guidelines are being followed you will likely have no issues. It is further recommended that when you do the build with modules that have exceeded their shelf life that you start with a handful to perform a test run and do a final test to make sure all is working as expected. As long as there are no issues with the initial test run we would expect that you will not experience any problems.
To activate BT, list controller information and scan for BT/BLE devices:
# bluetoothctl
Agent registered
[bluetooth]# power on
Changing power on succeeded
[bluetooth]# list
Controller C0:EE:40:50:00:00 summit [default]
[bluetooth]# scan on
To connect to a device acting as a peripheral:
[bluetooth]# scan on
Discovery started
[CHG] Controller C0:EE:40:50:00:00 Discovering: yes
[NEW] Device 4C:90:DE:92:00:00 Pixel XL
[CHG] Device 4C:90:DE:92:00:00 RSSI: -68
[CHG] Device 4C:90:DE:92:00:00 RSSI: -58
...
[NEW] Device 4C:90:DE:92:00:00 Pixel XL
[bluetooth]# scan off
Discovery stopped
[CHG] Controller C0:EE:40:50:00:00 Discovering: no
[CHG] Device 4C:90:DE:92:00:00 TxPower is nil
[CHG] Device 4C:90:DE:92:00:00 RSSI is nil
[bluetooth]# pair 4C:90:DE:92:00:00
Attempting to pair with 4C:90:DE:92:00:00
[CHG] Device 4C:90:DE:92:00:00 Connected: yes
[NEW] Primary Service
/org/bluez/hci0/dev_4C_90_DE_92_00_00/service0001
00001801-0000-1000-8000-00805f9b34fb
Generic Attribute Profile
[NEW] Characteristic
/org/bluez/hci0/dev_4C_90_DE_92_00_00/service0001/char0002
00002a05-0000-1000-8000-00805f9b34fb
...
[NEW] Characteristic
/org/bluez/hci0/dev_4C_90_DE_92_00_00/service003a/char003b
00002a8a-0000-1000-8000-00805f9b34fb
First Name
[NEW] Characteristic
/org/bluez/hci0/dev_4C_90_DE_92_00_00/service003a/char003d
00002a90-0000-1000-8000-00805f9b34fb
Last Name
[NEW] Characteristic
/org/bluez/hci0/dev_4C_90_DE_92_00_00/service003a/char003f
00002a8c-0000-1000-8000-00805f9b34fb
Gender
...
[CHG] Device 4C:90:DE:92:00:00 UUIDs: 0000181c-0000-1000-8000-00805f9b34fb
[CHG] Device 4C:90:DE:92:00:00 UUIDs: 0000aaa0-0000-1000-8000-aabbccddeeff
[CHG] Device 4C:90:DE:92:00:00 ServicesResolved: yes
Request confirmation
[agent] Confirm passkey 210165 (yes/no): yes
[Pixel XL]# trust 4C:90:DE:92:00:00
[CHG] Device 4C:90:DE:92:00:00 Trusted: yes
Changing 4C:90:DE:92:00:00 trust succeeded
The peripheral device is a Google Pixel XL running Android 10 using Nordic’s nRF app with an advertising profile setup with dummy information. If you pair with a device that does not have some kind of service running, it will disconnect, as BT/BLE has nothing to do.
For international use, we recommend leaving the 60 configured in the default static worldwide mode as this mode will not violate any of our modular certifications.
The 60 series in static WW mode:
Using the test scripts provided with BlueZ to setup a GATT server:
cd /lib/bluez/test/
./example-gatt-server &
Power on Bluetooth, start advertising and set to pairable:
# bluetoothctl
Agent registered
[bluetooth]# power on
Changing power on succeeded
[bluetooth]# advertise on
[bluetooth]# pairable on
Connect with Nordic's nRF smartphone app and read the fake battery level.
The Sterling supplicant is based on the open-source wpa_supplicant and is also provided as an open-source package.
We update the source and patch as needed to make sure we are up to date on the latest CVEs.
It also goes through our QA validation process with each production release of backports and firmware. For more information, see the release notes on GitHub:
The iw tool can be used to read the status of the device:
# iw dev
phy#0 Unnamed/non-netdev interface wdev 0x2 addr 7e:4a:78:cc:85:77 type P2P-device txpower 31.00 dBm Interface wlan0 ifindex 7 wdev 0x1 addr aa:bb:cc:07:0c:b1 ssid testAP type AP channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz txpower 31.00 dBm Managed/client mode link information:# iw wlan0 link
Connected to aa:bb:cc:12:34:56 (on wlan0) SSID: testAP freq: 2462 RX: 364 bytes (2 packets) TX: 3782 bytes (22 packets) signal: -31 dBm tx bitrate: 2.0 MBit/s bss flags: short-slot-time dtim period: 2 beacon int: 200 AP mode to read connected client information:# iw wlan0 station dump
Station aa:bb:cc:8b:6c:fe (on wlan0) inactive time: 3000 ms rx bytes: 6479 rx packets: 37 tx bytes: 9706 tx packets: 66 tx failed: 0 signal: -44 [-44] dBm tx bitrate: 1.0 MBit/s rx bitrate: 65.0 MBit/s authorized: yes authenticated: yes associated: yes WMM/WME: yes TDLS peer: no DTIM period: 2 beacon interval:100 short slot time:yes connected time: 20 seconds
We provide a sysfs entry for this purpose:
cat /sys/class/net/wlan0/device/lrd/info
Driver name : lrdmwl
Chip type : 88W8997-PCIE
HW version : 7
FW version : 5.4.29.5
DRV version : 8.1.0.11
OTP version : 1
OTP num mac : 2
Radio Type : ST
MAC address : c0:ee:40:50:00:00
Region code : 0xff (0xff)
Country code: '00' ('00')
TX antenna : 2
RX antenna : 2
You must load Summit firmware for multi-BSSID support. After loading the driver and firmware, perform the following: Stop all software that may be managing the Wi-Fi interface including the supplicant, NetworkManager, connman, hostapd, etc.
List out the current virtual interfaces on the physical interface (phy):
# iw dev
phy#0
Interface wlan0
ifindex 7
wdev 0x1
addr c0:ee:40:50:00:00
type managed
txpower 20.00 dBm
Delete the virtual interface:
# iw wlan0 del
Add up to 3 virtual interfaces onto the phy using unique names per dev (note there are two underscores in __ap):
# iw phy0 interface add ap0 type __ap
# iw phy0 interface add ap1 type __ap
# iw phy0 interface add ap2 type __ap
Confirm the virtual interfaces exist:
# iw dev
phy#0
Interface ap2
ifindex 10
wdev 0x4
addr c0:ee:40:50:00:02
type AP
txpower 20.00 dBm
Interface ap1
ifindex 9
wdev 0x3
addr c0:ee:40:50:00:01
type AP
txpower 20.00 dBm
Interface ap0
ifindex 8
wdev 0x2
addr c0:ee:40:50:00:00
type AP
txpower 20.00 dBm
The MAC on the first interface will not change and each subsequent interface added will add 1 to the first MAC.
For Sterling supplicant it is limited to only 1, for the Summit supplicant it is a total of 3.
More information comparing the Summit vs Sterling stack can be found in the Summit stack product brief:
Open/unsecured Network:
network={
ssid="myAP"
key_mgmt=NONE
scan_ssid=1
}
WPA2-PSK:
network={
ssid="myAP"
key_mgmt=WPA-PSK
psk="password"
pairwise=CCMP
group=CCMP
proto=RSN
scan_ssid=1
}
WPA2-AES with EAP-TLS
network={
scan_ssid=1
ssid="myAP"
pairwise=CCMP
group=CCMP
key_mgmt=WPA-EAP
proto=RSN
eap=TLS
identity="user1"
private_key="/etc/certs/user1.pem"
private_key_passwd="user1"
client_cert="/etc/certs/user1.pem"
}
WPA-TKIP with PEAP MSCHAPv2:
network={
scan_ssid=1
ssid="myAP"
key_mgmt=WPA-EAP
eap=PEAP
identity="user1"
phase1="peaplabel=auto peapver=0 "
phase2="auth=MSCHAPV2"
password="user1"
}
For the full documentation provided by the wpa_supplicant maintainers, please visit: https://w1.fi/cgit/hostap/plain/wpa_supplicant/wpa_supplicant.conf
In order to leverage our modular certifications, you must follow the RF design of the module associated with the chip/SIPT. Design files will be provided upon request so you can reproduce our design on your custom board. We highly suggest you to take advantage of our free design review to prevent any issues when going for certification testing.
Please submit a ticket using our support portal when you are ready to begin the process.
The country code is stored in one time programmable memory (OTP) on the 60 Series module. The default is worldwide mode. You can permanently change this in manufacturing using the LMU (Laird Manufacturing Utility). For access to this tool, please submit a ticket using our support portal and we can send you a link to the pre-compiled binaries. More information about using the tool, please download the laird-sterling-60-docs-<ver>.tar.bz2 archive and read the vendor tools application note available here.
The LRU (Laird Regulatory Utility) and manufacturing firmware are used to exercise the 60 Series radios during certification testing. We do not publicly provide the LRU, however you can submit a ticket using our support portal and we will provide the pre-compiled binaries via a secure link. For more information regarding the use of the tool, please download the laird-sterling-60-docs-<ver>.tar.bz2 archive and read the vendor tools application note.
We provide custom "thinmac" firmware that not only includes optimizations and power tables but is designed to run on the 60 Series modules. Using firmware that is not provided by us will violate the modular certifications and may not work with our module.
We provide driver support via our fork of the backports package. Backports replaces the kernel-side Bluetooth stack and Wi-Fi stack including cfg80211, mac80211 and custom "lrdmwl" driver. We regularly perform a kernel rebase to keep up with LTS releases which provides the benefit of running a modern stack on a range of kernels. We perform build verification regression testing including popular silicon vendor kernels such as Xilinx, nVidia, ST Micro, TI and NXP. All releases are QA validated in our automated testing system.
We support our customers integrating backports in different Linux build environments including Yocto, Buildroot and PetaLinux. Please contact support if integration assistance is needed.
CVEs that have been addressed are referenced in our release notes. If there is a new CVE or one that is not listed in our release notes, please submit a ticket using our support portal and we will provide the status.
Radio-specific release notes can be found in the corresponding GitHub repo: https://github.com/LairdCP/Release-Packages
Yes, the unused antenna port needs to be terminated with 50 Ohms.
Please also refer to the application note "app_note_60_siso" that can be found in the documentation archive on
Github where you downloaded the Laird software for the module.
On Github where all software releases for the 60-series modules can be found 60 Releases amongst every release there is an archive called for example: "laird-sterling-60-docs-8.3.0.16.tar.bz2 In the archive there are technical documents like:
Most of them are very relevant for your development with the 60-series Wifi module.
If the binary returns "not found" or does not work after confirming the executable bit is set with chmod +x <filename>
, then you will need to create a symlink pointing to the system's interpreter. The file
tool will show the expected interpreter and architecture of a binary, readelf
is a lot more verbose and is used to discover the expected "sonames" of shared libraries. These utilities do not have to be used on the target system and is convenient to use on a common x86 Linux machine. These utilities can be installed on Ubuntu with sudo apt install binutils
.
Example output from the file command:
sterling_supplicant-arm-7.0.0.139/usr/sbin$ file wpa_supplicant
wpa_supplicant: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 3.0.0, stripped
Example output from the readelf command:
sterling_supplicant-arm-7.0.0.139/usr/sbin$ readelf -ld wpa_supplicant Elf file type is EXEC (Executable file)
Entry point 0xba28
There are 10 program headers, starting at offset 52 Program Headers:
...
<edited>
...
[Requesting program interpreter: /lib/ld-linux.so.3]
...
<edited>
...
Dynamic section at offset 0x176ee8 contains 30 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [librt.so.1]
0x00000001 (NEEDED) Shared library: [libnl-3.so.200]
0x00000001 (NEEDED) Shared library: [libnl-genl-3.so.200]
0x00000001 (NEEDED) Shared library: [libdl.so.2]
0x00000001 (NEEDED) Shared library: [libdbus-1.so.3]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libc.so.6]
...
<edited>
...
To use this binary, we will have to confirm this symlink exists or create a new symlink pointing to the interpreter on the target filesystem:
cd /lib/
ls -l ld-*
-rwxr-xr-x 1 root root 158772 Dec 2 2019 /lib/ld-2.26.so
ln -sf ld-2.26.so ld-linux.so.3
ls -l ld-*
-rwxr-xr-x 1 root root 158772 Dec 2 2019 /lib/ld-2.26.so
lrwxrwxrwx 1 root root 10 Dec 21 18:55 /lib/ld-linux.so.3 -> ld-2.26.so
If the binary now reports that a library is not found when executed, repeat the steps shown above for creating a library symlink/soname pointing to it's real name. This may require you to use the find command to discover the location of the library. Example for libnl-genl-3:
find / -name 'libnl-genl-3*' -exec ls -l {} 2>/dev/null \;
-rwxr-xr-x 1 root root 18524 Feb 14 23:42 /usr/lib/libnl-genl-3.so.200.26.0
cd /usr/lib/
ln -sf libnl-genl-3.so.200.26.0 libnl-genl-3.so.200
ls -l libnl-genl-3*
-rwxr-xr-x 1 root root 18524 Feb 14 23:42 /usr/lib/libnl-genl-3.so.200.26.0
lrwxrwxrwx 1 root root 24 Feb 14 23:37 /usr/lib/libnl-genl-3.so.200 -> libnl-genl-3.so.200.26.0
If the library does not exist, you will have to include that package in your build. For instance if the above example libnl was missing, include the libnl package when building your filesystem.
To use an antenna that is not listed on your wireless modules datasheet, it must be of the same topology (e.g. dipole, PIFA, etc.), equal or lesser gain, and have the same in-band and out of band characteristics.
Note: Japan (MIC) lists applicable antennas on its certificates. If your antenna is not on the approved list, regardless of whether it is comparative, it must be added to the certificate before it can be used in Japan.
It is best practice to include the source in your build system. If using Yocto, our external layer will do this for you.
Here is an example manually compiling using our SOM60 as a target in a Buildroot environment:
#CFLAGS += -I/usr/local/openssl/include
CFLAGS += -I/wb/buildroot/output/som60sd/build/host-libopenssl-1.1.1d/include
set:
CC="" for your cross-compile binary
PKG_CONFIG="" for your pkg-config binary
PKG_CONFIG_PATH="" for your pkgconfig directory
OBJCOPY="" for your objcopy binary
Note the following example is a single line command:
make CC="/wb/buildroot/output/som60sd/host/bin/arm-buildroot-linux-gnueabihf-gcc" PKG_CONFIG="/wb/buildroot/output/som60sd/host/bin/pkg-config" OBJCOPY="/wb/buildroot/output/som60sd/host/arm-buildroot-linux-gnueabihf/bin/objcopy" PKG_CONFIG_PATH="/wb/buildroot/output/som60sd/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/pkgconfig"
There are certain patch ranges within kernels 4.4 and 4.9 that need a modification so backports can build, the reason why we cannot fix it in backports is that we cannot track and differentiate between patch versions of the same 'major.minor' version of kernel. To fix this issue, move the function kobject_has_children
from linux/kobject.h to drivers/base/core.c in your kernel source, rebuild the kernel and then rebuild backports.
No, the ST60 SIPT module on the 2230C carrier board is strapped for 1.8 VIO operation only. Design for an embedded SDIO operation and does not allow 3.3 VIO even during card enumeration.
Simply log into GitHub, go to the corresponding release packages page and click the "Watch" button (eye icon) in the top right of the page. Some radios (such as the LWB Series) requires you to download firmware separately from the product page; this firmware is updated on the product page in conjunction with GitHub releases.
Additional documentation can be located in the Sterling 60 GitHub repository
In order to be able to leverage the Modular Approval of a wireless module the following requirements have to be met: