TECHSHIP IS A GLOBAL SUPPLIER OF WIRELESS COMPONENTS
The SIMCom SIM7600G-H R2 LTE CAT-4 M.2is Multi-Band LTE-TDD/LTE-FDD module solution in a M.2 form factor. Dev.kit can be found here 11653 - SIMCom SIM7900-M2-EVB KIT
SIM7600G-H R2 is a LTE CAT4 module with support of up to 150Mbps downlink data transfer.
With abundant application capability like TCP/UDP/FTP/FTPS/HTTP/HTTPS/DNS, the module provides much flexibility and ease of integration for customer's application
SIM7600G-H R2 is a global variant with supports for more than 20 LTE bands as well as fallback to 3G and 2G.
Regional versions of the SIM7600X-H series are also available.
The SIMCom SIM7600G-H R2 LTE CAT-4 M.2is Multi-Band LTE-TDD/LTE-FDD module solution in a M.2 form factor.
Dev.kit can be found here 11653 - SIMCom SIM7900-M2-EVB KIT
Simcom SIM7500 series and SIM7600 series AT commands manual
Simcom SIM7500 series and Simcom SIM7600 series AT commands manual
This archive contains the SIMCom:
SIM7100_SIM7500_SIM7600 Series_GPIO_Application Note_V3.00
SIM7100_SIM7500_SIM7600 Series_LBS_Application Note_V3.00
SIM7100_SIM7500_SIM7600 Series_Sleep Mode_Application Note_V3.00
SIM7100_SIM7500_SIM7600 Series_UART_Application Note_V3.00
SIM7100_SIM7500_SIM7600 Series_UIM HOT SWAP_Application Note_V3.00
SIM7100_SIM7500_SIM7600_SIM7800 Series_USB AUDIO_Application Note_V3.00
SIM7100_SIM7600 Series_TTS_Application Note_V3.0
SIM7500_SIM7600 Series_FOTA_Application Note_V3.00
SIM7500_SIM7600 Series_FTP(S)_Application Note_V3.00
SIM7500_SIM7600 Series_GNSS_Application Note_V3.00
SIM7500_SIM7600 Series_Jamming Detection_Application Note_V3.00
SIM7500_SIM7600 Series_SAT_Application Note_V3.00
SIM7500_SIM7600_SIM7800 Series_ECALL_Application Note_V3.00
SIM7500_SIM7600_SIM7800 Series_MQTT(S)_Application Note_V3.00
SIM7500_SIM7600_SIM7800 Series_SMS_Application Note_V3.00
SIM7500_SIM7600_SIM7800 Series_SSL_Application Note_V2.00
SIM7500_SIM7600_SIM7800 Series_TCPIP_Application Note_V3.00
SIM7600 Series_HSIC_LAN_Application Note_V2.00
SIM7600 Series_Open Linux Sleep&Wake-Up_Application Note_V2.00
SIM7600 Series_Open Linux UART&SPI_Application Note_V2.00
SIM7600 Series_Open Linux_Development Guide_V2.00
SIM7600 Series_SFOTA_Application Note_V2.00
SIM7600_SIM7800 Series_SGMII_LAN_Application Note_V3.00
SIM7600M22_MIFI_SIM7800 Series_BT_Application Note_V3.00
FCC certificate for SIMCom SIM7600G-H R2
IC certificate for SIMCom SIM7600G-H R2
KC certificate and test report for SIMCom SIM7600G-H R2
RoHS & REACH certificate for SIMCom SIM7600G-H R2
Jate & Telec certificate for SIMCom SIM7600G-H R2
RCM certificate for SIMCom SIM7600G-H R2
CCC & SRRC certification for SIMCom SIM7600G-H R2
This archive contains the SIMCom SIM7600G-H firmware LE20B04SIM7600G-H-M2 update files and release notes
Simcom firmware update tools and procedure
This archive contains the SIMCom SIM7600G-H firmware LE20B03SIM7600G-H-M2 update files and release notes
Simcom firmware update tools and procedure
Which antenna ports should I connect antennas to on the LTE or 5G module?
It is important to understand the functionality of the different antenna ports on the cellular module when deciding which ports to use. There is a risk of underutilizing the module by not connecting antennas to the right ports. This guide aims to explain some general terms and abbreviations used to label and describe antenna ports and their different functionalities.
Some antenna port labels that are commonly used on cellular modules are listed below:
MAIN – Primary transmit and receive antenna port. Required for basic functionality.
DIV – Diversity receive port. This port is used to receive the same signal as the primary port, but at a different spatial point. By receiving the same signal at two different spatial points, the module can mitigate destructive effects that might be present on one of the different spatial points. The diversity receive functionality is especially useful in urban environments where the interference environments may be radically different between two spatial points. It is always recommended to use the diversity receive port as this functionality improves the quality and reliability of the overall link.
GNSS – GNSS receive port. GNSS stands for Global Navigation Satellite System, examples of such systems are GPS, Galileo, GLONASS and BeiDou. The available systems may differ between different modules. To see what systems are available for a specific module, please consult the modules hardware documentation. As this antenna port is used for positioning applications, a suitable GNSS antenna needs to be connected to this port in order to utilize this functionality.
MIMO – MIMO port. MIMO stands for Multiple Input Multiple Output and refers to the amount of antennas used at each side of the link. For example, 4x4 DL MIMO means that the base station and the module each use 4 antennas for the modules downlink. Usually, the MIMO label is used to denote antenna ports that are used for spatial multiplexing which is a technique used for increasing the bitrate. This is achieved by splitting the signal into different streams that are transmitted and received on spatially separated antennas on each side of the link. For the majority of cellular modules, spatial multiplexing is only available for the module's downlink.
AUX – Auxiliary antenna port. The available functions on this port may differ between modules. Examples of functionalities that can be present on this port are diversity receive, DL-MIMO and GNSS. Please consult the module's hardware documentation to see which functionalities are present on this port.
Some cellular modules have numeric, non-descriptive labels on their antenna ports. These modules can have different functionalities for different frequency intervals/bands, on one single antenna port. For these modules, consult the hardware documentation to find what functionalities are present for which frequency intervals/bands one the different antenna ports. Please note that antenna ports with transmit functionality for certain frequency bands need to have a antenna connected in order to utilize these frequency bands.
If you have further inquiries regarding antenna ports on cellular modules, please create a Support Ticket by visiting the following link: https://techship.com/support/new/
How to collect initial diagnostics data and logs for Simcom cellular modules, needed when requesting Techship technical support?
In order to troubleshoot and solve a technical problem, we ask you to please provide information about your host system and logs from the related Simcom module when creating a technical support ticket.
Detailed problem description and in what situations it present or can be reproduced.
Describe the host system:
-Hardware (system board, peripherals...)
-Operating system and detailed versions (E.g. Windows, Linux release, kernel...)
-Drivers and driver versions
Identify the precise details of cellular module found on label:
-SKU/BOM or P/N code
(For RMA returns the IMEI number is mandatory)
If you are running on a Linux based system, please capture the terminal logs bellow:
ls -l /dev/serial/by-id
ls -l /sys/bus/usb-serial/devices
The logs from the cellular module firmware can be acquired by accessing the USB enumerated serial (COM) interfaces accepting AT commands. They can be named modem, AT, PC UI etc. (In Windows device manager, found under modem or serial interfaces). Send the following AT commands bellow to module and capture the output and include them when creating the the technical support ticket.
Test that you get a reply with command:
Command echo enabled:
Basic module info:
Detailed module version info:
Verbose error reporting:
Last error report:
USB endpoint configuration:
List current configuration:
Request UE system info:
Preferred network mode:
Preferred band selection:
Preferred acquisition order:
List network operator info:
Network registration status:
Network EPS registration status:
Packet domain attach status
List APN details/PDP profiles:
PDP profiles attach status:
Show PDP IP address:
RM network interface status:
The support ticket can be created after login at: https://techship.com/technical_support/
How to use NetworkManager and ModemManager in Linux to automatically establish a cellular data connection and configure IP details?
Using NetworkManager and ModemManager in Linux to automatically establish a connection and configure IP details
In this FAQ we will show how to set up NetworkManager to automatically configure, establish the cellular data connection in your system.
NetworkManager and ModemManager are open source tool for Linux to manage several types of networks and interfaces such as ethernet, wifi, etc. It can also manage cellular WWAN interfaces through the ModemManager tool.
It is hosted by the Freedesktop.org community and driven by Aleksander Morgado and other contributors. please visit https://wiki.gnome.org/Projects/NetworkManager and https://www.freedesktop.org/wiki/Software/ModemManager/ for latest information, source code, API reference manuals, debugging tips, contribution, mailing list etc.
ModemManager is capable of communicating over several types of device control channels such as QMI/RMNET, MBIM, MODEM / AT command etc. But support for vendor proprietary or out-of-kernel drivers are none or very limited. Such drivers are gobinet, simcom_wwan and other drivers provided by the vendors directly.
Many Linux distributions have NetworkManager and ModemManager pre-installed or they can typically easily be installed through the systems package manager.
In Ubuntu for example apt can install it for you by command if not already installed:
apt install network-manager
Check with commands below that you have both tools installed in system and their versions.
ModemManager (and NetworkManager) are continuously developed for better compatibility with the cellular devices, therefore it is recommend to use a recent version of the tools and in case of problem situations, evaluate the latest versions from source and check the mailing list archives for possible discussions on the problem experienced.
Keep in mind that NetworkManager and ModemManager projects are not directly developed or driven by the cellular device vendors and the compatibility with the device you aim to use can be limited. Some vendors contribute with code to make their devices fully compatible, while others don't. Many cellular devices can be set to expose standardized types of USB network interface and control channel such as MBIM interface by USB-IF or the Qualcomm proprietary interface QMI that ModemManager will try to identify, and often manage to work successfully with but there are exceptions also.
Both NetworkManager and ModemManager have command line interfaces (nmcli and mmcli respectively) where you can interact with the management tools.
Relate to the following FAQ if you want more details for using ModemManager only to configure and control the cellular device but manually establish, maintain the connection and network interface IP address details.
How-to guide: control and set up a data connection in Linux using ModemManager as connection manager?
Have ModemManager list all the cellular device it has detected. Here we use the Alcatel IK41 series with MBIM interface in this example:
/org/freedesktop/ModemManager1/Modem/0 [Alcatel] Mobilebroadband
General details and status of them modem can be listed with "--modem" option.
General | dbus path: /org/freedesktop/ModemManager1/Modem/0
| device id: 998e478c5b14c75e16bffe6abaacabef22fb2f5b
Hardware | manufacturer: Alcatel
| model: Mobilebroadband
| firmware revision: MPSS.JO.2.0.2.c1.7-00004-9607_
| carrier config: default
| h/w revision: 0
| supported: gsm-umts, lte
| current: gsm-umts, lte
| equipment id:
System | device: /sys/devices/pci0000:00/0000:00:14.0/usb3/3-1
| drivers: option1, cdc_mbim
| plugin: Generic
| primary port: cdc-wdm0
| ports: cdc-wdm0 (mbim), ttyUSB0 (at), ttyUSB2 (at), wwan0 (net),
| ttyUSB1 (qcdm)
Status | lock: sim-pin
| unlock retries: sim-pin (3)
| state: locked
| power state: on
| signal quality: 0% (cached)
Modes | supported: allowed: 2g; preferred: none
| allowed: 3g; preferred: none
| allowed: 4g; preferred: none
| allowed: 2g, 3g; preferred: 3g
| allowed: 2g, 3g; preferred: 2g
| allowed: 2g, 4g; preferred: 4g
| allowed: 2g, 4g; preferred: 2g
| allowed: 3g, 4g; preferred: 3g
| allowed: 3g, 4g; preferred: 4g
| allowed: 2g, 3g, 4g; preferred: 4g
| allowed: 2g, 3g, 4g; preferred: 3g
| allowed: 2g, 3g, 4g; preferred: 2g
| current: allowed: 2g, 3g, 4g; preferred: 2g
Bands | supported: egsm, dcs, pcs, g850, utran-1, utran-8, eutran-1, eutran-3,
| eutran-7, eutran-8, eutran-20, eutran-28
| current: egsm, dcs, pcs, g850, utran-1, utran-8, eutran-1, eutran-3,
| eutran-7, eutran-8, eutran-20, eutran-28
IP | supported: ipv4, ipv6, ipv4v6
SIM | dbus path: /org/freedesktop/ModemManager1/SIM/0
Check that the cellular device is managed by NetworkManager by not having state "unmanaged" listed for it.
nmcli device status
DEVICE TYPE STATE CONNECTION
cdc-wdm0 gsm disconnected --
enp3s0 ethernet unmanaged --
lo loopback unmanaged --
Now you should create a connection profile in NetworkManager for your specific network carrier and SIM card with the "nmcli connection add" command:
nmcli connection add type gsm ifname '*' con-name '3-sweden' apn 'data.tre.se' connection.autoconnect yes gsm.pin 0000
- type is gsm for all typical cellular connections unless it is of cdma type.
- ifname is the control interface name, in this case cdc-wdm0, wildcard can be used also to have it autoselect.
- con-name is the profile name you want to give it.
- apn is provided by your network carrier and tells the modem what attach point it should use for the data connection.
- connection.autoconnect set to yes will make NetworkManager always try to auto connect and maintain this profile connection.
- gsm.pin lets you provide a pin code for the SIM card, that NetworkManager will try to use if PIN check is enabled for SIM card.
There are several additional commands and attributes available such as username and password settings for the APNs etc. Refer to the NetworkManager help and manual pages for full details on the commands.
If successful you should receive a reply similar to this one:
Connection '3-sweden' (cad6fcbf-2cb1-4796-b7e6-67b9f9635aef) successfully added.
You can check the status now by command:
nmcli device status
DEVICE TYPE STATE CONNECTION
cdc-wdm0 gsm connected 3-sweden
enp3s0 ethernet unmanaged --
lo loopback unmanaged --
Where connected should be listed as state if the connection establishment was successful.
If the connection is not successful or you want more details about the device and connection you can check commands:
You can list the current status with command:
WIFI-HW WIFI WWAN-HW WWAN
enabled enabled enabled enabled
nmcli device show cdc-wdm
GENERAL.STATE: 100 (connected)
IP4.ROUTE: dst = 126.96.36.199/30, nh = 0.0.0.0, mt = 700
IP4.ROUTE: dst = 0.0.0.0/0, nh = 188.8.131.52, mt = 700
IP6.ROUTE: dst = ff00::/8, nh = ::, mt = 256, table=255
IP6.ROUTE: dst = 2a02:aa1:1017:6d11::/64, nh = ::, mt = 700
IP6.ROUTE: dst = ::/0, nh = fe80::21e6:9049:6cfb:8ac3, mt = 1024
IP6.ROUTE: dst = 2a02:aa1:1017:6d11::/64, nh = ::, mt = 256
IP6.ROUTE: dst = ::/0, nh = 2a02:aa1:1017:6d11:21e6:9049:6cfb:8ac3, mt = 700
nmcli connection show
NAME UUID TYPE DEVICE
3-sweden e946017f-2e9c-477b-89ad-4c31e7331d65 gsm cdc-wdm0
Ifconfig should now show the related IP address details already set to the network interface by NetworkManager:
wwan0: flags=4291 mtu 1500
inet 184.108.40.206 netmask 255.255.255.252 broadcast 220.127.116.11
inet6 2a02:aa1:1017:6d11:6474:7254:7b72:eb09 prefixlen 64 scopeid 0x0
inet6 2a02:aa1:1017:6d11:1060:3dff:feac:e92f prefixlen 64 scopeid 0x0
ether 12:60:3d:ac:e9:2f txqueuelen 1000 (Ethernet)
RX packets 186 bytes 10886 (10.8 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5 bytes 480 (480.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
You can now for example test the connection over the network interface by sending ping requests.
Testing IPV4 connection:
ping -4 -I wwan0 18.104.22.168
PING 22.214.171.124 (126.96.36.199) from 188.8.131.52 wwan0: 56(84) bytes of data.
64 bytes from 184.108.40.206: icmp_seq=1 ttl=118 time=55.8 ms
64 bytes from 220.127.116.11: icmp_seq=2 ttl=118 time=45.4 ms
64 bytes from 18.104.22.168: icmp_seq=3 ttl=118 time=42.9 ms
--- 22.214.171.124 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 42.918/48.053/55.845/5.601 ms
Testing IPV6 connection: (if your cellular device, network subscription and APN supports it)
ping -6 -I wwan0 2600::
PING 2600::(2600::) from 2a02:aa1:1017:6d11:1060:3dff:feac:e92f wwan0: 56 data bytes
64 bytes from 2600::: icmp_seq=1 ttl=46 time=172 ms
64 bytes from 2600::: icmp_seq=2 ttl=46 time=171 ms
64 bytes from 2600::: icmp_seq=3 ttl=46 time=169 ms
64 bytes from 2600::: icmp_seq=4 ttl=46 time=168 ms
--- 2600:: ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 167.921/170.037/172.272/1.651 ms
The connection is successful and automatic reconnect is working when testing to unplug and plug in the device again.
For additional configurations, commands and available attributes, please relate to the manual pages for NetworkManager and ModemManager.
NetworkManager and ModemManager write log messages to the Linux syslog file /var/log/syslog.
In case of problems with establishing a cellular data connection, please copy the logfile after the problem have appeared and include it in a Techship technical support ticket.
In some situations more detailed debug logs are needed, these can be acquired by changing the log levels for NetworkManager and ModemManager and run them manually.
To capture debug logs, please first disable and stop the normal services:
systemctl stop NetworkManager ModemManager
systemctl disable NetworkManager ModemManager
Run them manually in background with debug level set:
/usr/sbin/ModemManager --log-level=DEBUG &> /dev/null &
/usr/sbin/NetworkManager --log-level=DEBUG &
Reproduce the cellular data connection problem.
Once completed, kill the processes:
killall -TERM NetworkManager ModemManager
Copy the relate messages in syslog to a mm-nm-sys-debug.log logfile:
grep -E 'ModemManager|NetworkManager|systemd|dbus-daemon|dhclient' /var/log/syslog > mm-nm-sys-debug.log
Activate and start the services again:
systemctl enable NetworkManager ModemManager
systemctl start NetworkManager ModemManager
Include the mm-nm-sys-debug.log in a technical support ticket at Techship.com where you describe the issue in details and include other relevant information also such as kernel version, ModemManager and NetworkManager versions, dmesg log etc.
How-to use the SIM7600 series modules in RNDIS USB mode with automatic connection management
Both Windows and Linux systems can support RNDIS interface drivers for the SIM7600 series modules, this example demonstrates how it can be done in a Linux environment.
There is a open source Linux in-kernel driver supporting RNDIS USB network interfaces called rndis_host.
Make sure to have the kernel config for rndis host driver support enabled.
Read more about the kernel configs in this FAQ:
Common Linux kernel modules and configs necessary for communicating with cellular modules over USB interface
By default the Simcom modules are delivered with QMI/RMNET network interface enabled, so you will need to change the USB mode by AT commands on the Modem/AT serial ports exposed over the USB interface.
Bus 001 Device 006: ID 1e0e:9001 Qualcomm / Option
Switch the module from USB PID 9001 to USB PID 9011 mode for RNDIS interface:
The module will now restart automatically and re-enumerate with a new USB ID.
Check dmesg or with lsusb that you have the Simcom SIM7600 module detected with, VID: 1e0e PID: 9011
Bus 001 Device 006: ID 1e0e:9011 Qualcomm / Option
Verify with lsusb -t that the Linux in-kernel driver rndis_host driver is loaded correctly for interface 0 and 1.
It can look e.g. like this:
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 480M
|__ Port 4: Dev 6, If 3, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 4: Dev 6, If 1, Class=CDC Data, Driver=rndis_host, 480M
|__ Port 4: Dev 6, If 6, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 4: Dev 6, If 4, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 4: Dev 6, If 2, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 4: Dev 6, If 0, Class=Communications, Driver=rndis_host, 480M
|__ Port 4: Dev 6, If 5, Class=Vendor Specific Class, Driver=option, 480M
If your system don't load the option serial interfaces correctly, then they can be forcefully loaded as bellow:
echo 1e0e 9011 > /sys/bus/usb-serial/drivers/option1/new_id
Relate to the following Linux kernel commit for details on how to modify the usb serial option driver source code in order to auto load the drivers:
USB: serial: option: add support for Simcom SIM7500/SIM7600 RNDIS mode
You should now have the Linux system drivers ready for usage, and a rndis network interface visible (typically named usb0). The host system have a DHCP client active on the network interface. Module will delegate a Network Address Translated (NAT) IP to the Linux host system.
dhclient -v usb0
Listening on LPF/usb0/4a:de:a7:7e:46:07
Sending on LPF/usb0/4a:de:a7:7e:46:07
Sending on Socket/fallback
DHCPREQUEST of 192.168.225.46 on usb0 to 255.255.255.255 port 67 (xid=0xaabce35)
DHCPACK of 192.168.225.46 from 192.168.225.1
RTNETLINK answers: File exists
bound to 192.168.225.46 -- renewal in 21475 seconds.
In order to enable the automatic network connection establishment, the SIM card should have PIN code check disabled. If it isn't disabled, the Linux host system need to provide the PIN code to module after each modem restart.
Refer to AT command: AT+CPIN=xxxx for further details.
The Access Point Name (APN) related to your cellular subscription needs to be configured once to the module so the automatic connection establishment can be established on the correct data bearer.
Defining an empty string as value on the AT+CGDCONT profile, will make the module try to subscribe for a APN, however this may not always work e.g. in roaming conditions, so best procedure is to always configure the correct ones for the network and your subscription.
Check the currently configured APN profiles:
You should have at least profile 1 and 6 defined to empty strings to enable subscribe of the APN details: AT+CGDCONT=1,"IPV4V6",""
+CGDCONT Profile 1 is used for the cellular network registration process and APN at profile 6 will be tied to the RNDIS network interface for data connection.
Define both APN profiles according to the details you have obtained for your cellular subscription. Most often the APN details are same for both network registration and the actual data connection, then you define same details to both profile 1 and 6:
Some APN names require additional authentication also, please refer to the AT command: AT+CGAUTH in the AT commands guide for details on how to define auth details correctly.
Current auth configurations can be checked with AT command:
Most often no auth details are needed for the profiles and they should be empty, profiles can be cleared by defining the profile number in question and zero in the second parameter:
If you have modified the APN information, username and passwords it is necessary to disconnect and reconnect to cellular network and packet data service to activate the new settings.
It can easily be done with AT+CFUN=0 command followed by AT+CFUN=1 to switch module operation mode (SIM card will also be re-initialized, so PIN code have to be given again if the PIN code check is activated).
The module will now try to establish and maintain the data connection automatically with the new settings.
If everything was configured correctly and the connection established successfully on the APN, the host system will have network access on the RNDIS network interface:
It can be tested e.g. by pinging a remote host over the RNDIS network interface:
ping -I usb0 126.96.36.199
PING 188.8.131.52 (184.108.40.206) from 192.168.225.46 usb0: 56(84) bytes of data.
64 bytes from 220.127.116.11: icmp_seq=1 ttl=52 time=167 ms
64 bytes from 18.104.22.168: icmp_seq=2 ttl=52 time=37.6 ms
64 bytes from 22.214.171.124: icmp_seq=3 ttl=52 time=44.4 ms
64 bytes from 126.96.36.199: icmp_seq=4 ttl=52 time=33.6 ms
--- 188.8.131.52 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 8ms
rtt min/avg/max/mdev = 33.600/70.635/166.972/55.753 ms
SIM7600E-H/SIM7600SA-H with firmware release LE11B12SIM7600M22.
SIM7600G-H with firmware release LE20B01SIM7600M22.
Antenna Location: External | Polarization: Vertical | Impedance: 50 Ohm | Height: 157 mm | Width: 21 mm | Length: 157 mm | Connector Type: SMA-M | Mounting method: Connector | Technology / Antenna Frequency: GSM 850/900/1800/1900 MHz, UMTS 2100, LTE 790-960/1710-2690 MHz
1 PCS PRICE $8.10
Cable Specification: 1.13 mm coax | Cable length: 15 cm | Connector Type: IPEX MHF/U.FL, SMA-F
1 PCS PRICE $4.50
Cable Specification: 1.13 mm coax | Cable length: 20 cm | Connector Type: IPEX MHF/U.FL, SMA-F
1 PCS PRICE $4.60
Antenna Location: External | Max power: 50 W | Radiation pattern: Omnidirectional | Polarization: Vertical | Impedance: 50 Ohm | Diameter: 12.8 mm | Length: 195 mm | Connector Type: SMA-M | VSWR: 2.5 :1 | Mounting method: Connector | Technology / Antenna Frequency: GSM 850/900/1800/1900 MHz, UMTS 2100, LTE 790-960/1710-2690 MHz
1 PCS PRICE $7.80
Antenna Location: Outdoor, External | Operating Temperature Range: -40 °C – 85 °C | IP Class: IP67 | Polarization: RHCP (GPS) | Cable Specification: RG174 | Cable length: 250 cm | Impedance: 50 Ohm | Height: 13.7 mm | Width: 34 mm | Length: 41 mm | Connector Type: SMA-M | VSWR: 1.5 :1 | Gain: 3.5 dBi | Mounting method: Other | Technology / Antenna Frequency: GPS 1575.42 | Active/Passive GPS: Passive
1 PCS PRICE $13.20
Antenna Location: External | Operating Temperature Range: -40 °C – 85 °C | Max power: 50 W | Polarization: Linear | Cable Specification: RG174 | Cable length: 300 cm | Impedance: 50 Ohm | Height: 37.6 mm | Width: 49.6 mm | Length: 107.6 mm | Connector Type: SMA-M | VSWR: 2.5 :1 | Gain: 2 dBi | Mounting method: Adhesive, Screw | Technology / Antenna Frequency: GSM 850/900/1800/1900 MHz, UMTS 2100, Wifi/Bluetooth 2400, LTE 791-862/1710-2690 MHz
1 PCS PRICE $13.80