Categories
Uncategorized

Verizon UML290 and Sprint U600 USB Modems in Embedded Systems

Recently I tested support for the Verizon UML290 and Sprint U600 USB Cellular modems in an embedded Linux system.  Both modems support 3G and 4G networks, but only the 3G modes were tested due to lack of 4G coverage at the testing location.

Fortunately, both modems function very similar to previous modems, so with the drivers available in the Linux kernel, and standard pppd support in OpenEmbedded, they worked fine.

The Verizon UML290 modem provides a challenge in that it must be manually switched between 4G and 3G modes.  Typically this is done automatically by the vzaccess program Verizon supplies with the modem that runs on Windows.  The solution for this system was to manually set the modem to 3G mode as detailed on the following page:

http://www.evdoinfo.com/content/view/3492/64/

It appears that some embedded systems such as the Cradlepoint routers have implemented automatic 3G/4G switching support for the UML290, so this is no doubt possible with a little effort.

The Sprint U600 modem appears to default to 3G, or automatically switch inside the modem.

The same pppd scripts can be used with both modems:

# /etc/ppp/peers/verizon_um290
user a
password v
connect "/usr/sbin/chat -v -f /etc/ppp/peers/verizon_um290_chat"
defaultroute
usepeerdns
ttyACM0
921600
local
usepeerdns
debug
-detach
# /etc/ppp/peers/verizon_um290_chat
'' 'ATZ'
'OK' 'ATDT#777'
'CONNECT' ''

To initiate a connection:

pppd call verizon_um290

With Verizon cellular modems, it appears that port 22 is often blocked, so if you need to access a remote device via ssh, you may need to run ssh on a higher port number.  With 4G networks, it appears that the networking setup may be different in that a public IP address may not be assigned.  From the above evdoinfo.com page, we find the following text:

This fix will also work for users looking to use their device for remote based applications because it assigns a public facing IP address (3G ONLY). With eHRPD you’re assigned a private IP in either 3G or 4G mode, which has prevents UML290 users from accessing remote applications.

Perhaps the Rev A HDR Service mode will also work in 4G mode, but its seems as cellular networks become more complicated, there will be more issues to deal with in using USB Cellular modems for remote access in embedded systems.

Past articles on USB Cellular modems:

Categories
Uncategorized

Sprint 598U USB Broadband Modem in Embedded Systems

One thing that works really well in Linux is support for USB Broadband modems. While it usually takes a little fiddling with PPP scripts, it is generally not too difficult to get working. One of the reasons for this is most modems implement a USB serial interface, and then the modem is controlled with standard AT commands. A customer who currently supports a Verizon USB modem in their product wanted to add support for a Sprint modem. After a little research, we settled on the 598U from Sierra Wireless. Below is a picture of the 598U plugged into an industrial terminal.

sprint 598U modem

Why are USB Broadband modems useful in Embedded Systems?

As systems become more complex, and time to market is shrinking (thus less testing), it is becoming increasingly important to be able to remotely diagnose problems. With a broadband modem like the Sprint 598U, developers can remotely log into a device using SSH, and debug problems. This is a huge benefit. The cost of the modem and a 1 year data plan becomes fairly insignificant when you consider the cost to fly a developer on-site to debug issues. While there are other ways to remotely access an embedded system, such as reverse ssh, the simplicity of the broadband modem is attractive as it bypasses the firewall issues. Even with reverse ssh, I’ve run into paranoid sys admins who block the outgoing port 22 on their networks, which makes reverse ssh difficult. Once you have the IP address of the broadband connection, you can connect to it directly with ssh from anywhere in the world. I’ve accessed systems that were being field tested in New Zealand from the United States, and it worked great.

Increasingly, the value of complex embedded systems is shifting from control to data. While the control aspect is as important as it ever was, access to data is what is giving many products and businesses the competitive edge. Being able to collect data and visualize how the system is performing is becoming increasingly important to maximize performance. And sometimes this data must be collected in real-time. Scenarios where USB broadband modems might make sense:

  • remote sites that do not have internet connectivity
  • mobile applications such as vehicle terminals
  • temporary installations where the system is only located in one place for a limited time
  • situations where it is very difficult to get administrators of the local network to cooperate in adding the embedded system to their network

Finding PPP Config information

I usually develop as much as I can on x86 systems (vs. an embedded target) as it is a lot more convenient, so I plugged the modem into a Ubuntu 8.10 laptop. While Ubuntu 8.10 recognizes and configures a UM150 Verizon modem, it does not automatically configure the 598U. Typically, the next step is to google around for information on various support forums on how to set up the PPP config files, as most manufactures don’t provide support for Linux. As I could not find any existing information for the 598U, I decided to see if Sierra Wireless published any information. Was I ever suprised when I found this page. Sierra Wireless provides fairly comprehensive information on using the modem under Linux, and their PPP scripts actually worked — great job! But in the end, when I plugged the 598U into the embedded device that already supported the Verizon modem, it just worked with my existing PPP scripts. This is another indication of the value of using common code and interfaces in Linux.

The Linux Advantage

When you run Linux in an embedded system, using a USB broadband modem becomes fairly simple. It is actually a little bit deceiving as to what all has to happen. Different modems use different chipsets, and thus different drivers. While they all eventually expose a USB serial interface, there are enough differences to require separate drivers. As an example, the 598U uses the “sierra” USB-serial driver. This driver is 782 lines, plus it utilizes a common USB serial framework that is many times this size. On the application side, the pppd framework is used to manage the modem and the network connection. Starting the connection is as simple as running “pppd call cdma” from your application. The pppd application manages getting an IP address, setting up nameservers in resolve.conf, etc. Because all broadband modems are supported by a common application interface and very similiar drivers, supporting multiple modem vendors is actually quite easy. Contrast this to the Windows driver scenario where every vendor provides their “own” driver, and their “own” application user interface, and their “own” way to initiate an internet connection, and it is not obvious to me how you could easily control all this in a consistent, automated fashion in an embedded device. The way we set it up is you plug the modem in, and a few seconds later the system is automatically connected to the internet. There is nothing for the user to configure, initiate, etc. Printing from Linux in embedded applications is similiar.

This is another example of how it is possible to leverage the work of many to add advanced functionality and features to a device with very little development cost. Getting more done with less should be an attractive (and perhaps critical) way to operate for any company seeking to remain competitive.

Categories
Uncategorized

Using a Verizon USB720 modem in an Embedded Linux system

The Verizon USB720 Cellular modem is a quick and easy way to add wireless internet connectivity to your embedded system.  Why might you want to add cellular  connectivity to your embedded device?  Remote access and diagnostics is a big reason.  One customer I have is planning to supply all their distributors with a USB720 so they can easily upload log files from devices in the field.  The alternative is copying the log files to a flash drive, finding a PC connected to the internet, and then uploading the files — too much hassle, therefore it does not get done.  Also, think about the cost of sending a field support person on-site to troubleshoot problems versus shipping them a USB720 and accessing the device remotely.

The USB720 is a fairly small device that plugs into the ubiquitous USB port.  This articles covers some of the details on how to configure an embedded Linux system to work with this device.

Why is the USB720 a good fit for wireless connectivity in Embedded Systems?

Some reasons the USB720 (or other USB based cellular modems) is an attractive option:

  • fairly fast: provides typical download speeds of 600-1400kbps, and upload speeds of 500-800kbps
  • convenience: it plugs into a USB port.  No taking apart the box and installing an embedded module, etc.
  • affordable: with plans around $60/mo, its a lot cheaper than sending field support people on-site to debug every problem.
  • uses standard PPP protocols for connection.  That means it works with Linux.
  • supported by the mainstream Linux kernel

usb720_a

Kernel Configuration

The USB720 looks like a USB-serial device to the host system.  If you plug it into your Ubuntu desktop Linux system, all the needed kernel pieces are there and it will just work.  With your embedded system, you need to make sure a number of kernel options are enabled including:

CONFIG_PPP=m
CONFIG_PPP_ASYNC=m
CONFIG_PPP_DEFLATE=m
CONFIG_SLHC=m
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_OPTION=m

The CONFIG_USB_SERIAL_OPTION selection enables a driver that is specifically optimized to work with the USB chip found in many cellular modems.  Once you enable the above modules, and if you are running udev, simply plugging in the device will cause the appropriate modules to load and a /dev/ttyUSB0 device will now appear.

PPP Scripts

The most difficult part of this exercise is figuring out how to configure the PPP scripts.  Verizon of course does not tell you how to configure their device and only supplies software for Windows and MAC.  There are a number of howtos available on the internet, but most of them are tailored to using kppp or wvdial. Neither are very practical for embedded systems. Fortunately, the standard pppd daemon is fairly easy to use, is easy to build for embedded systems (it is already included in OpenEmbedded), and seems to work very well.  The following scripts are needed:

/etc/ppp/peers/verizon

noauth
connect "/usr/sbin/chat -v -f /etc/ppp/peers/verizon_chat"
defaultroute
usepeerdns
ttyUSB0
921600
local
usepeerdns
debug
-detach

/etc/ppp/peers/verizon_chat

'' 'ATZ'
'OK' 'ATDT#777'
'CONNECT' ''

/etc/ppp/chap-secrets
/etc/ppp/pap-secrets

"<phone number>@vzw3g.com"  *       "vzw"

At this point, you can run pppd call verizon and you should see something like:

 root@cm-x270:~$ pppd call verizon
Serial connection established.
using channel 9
Using interface ppp0
Connect: ppp0 <--> /dev/ttyUSB0
Warning - secret file /etc/ppp/pap-secrets has world and/or group access
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x539657b7> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x0 <mru 1500> <asyncmap 0x0> <magic 0xb9b652e5> <pcomp> <accomp>]
sent [LCP ConfAck id=0x0 <mru 1500> <asyncmap 0x0> <magic 0xb9b652e5> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x539657b7> <pcomp> <accomp>]
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15>]
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 192.168.1.119> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
rcvd [LCP DiscReq id=0x1 magic=0xb9b652e5]
rcvd [LCP ProtRej id=0x2 80 fd 01 01 00 0c 1a 04 78 00 18 04 78 00]
rcvd [IPCP ConfReq id=0x0 <addr 66.174.61.4>]
sent [IPCP ConfAck id=0x0 <addr 66.174.61.4>]
rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x2 <addr 192.168.1.119> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
rcvd [IPCP ConfNak id=0x2 <addr 70.210.82.191> <ms-dns1 66.174.95.44> <ms-dns3 66.174.92.14>]
sent [IPCP ConfReq id=0x3 <addr 70.210.82.191> <ms-dns1 66.174.95.44> <ms-dns3 66.174.92.14>]
rcvd [IPCP ConfAck id=0x3 <addr 70.210.82.191> <ms-dns1 66.174.95.44> <ms-dns3 66.174.92.14>]
not replacing default route to eth0 [192.168.1.1]
local  IP address 70.210.82.191
remote IP address 66.174.61.4
primary   DNS address 66.174.95.44
secondary DNS address 66.174.92.14
Script /etc/ppp/ip-up started (pid 2303)
Script /etc/ppp/ip-up finished (pid 2303), status = 0x0
root@cm-x270:~$ ifconfig
ppp0      Link encap:Point-to-Point Protocol
          inet addr:70.210.82.191  P-t-P:66.174.61.4  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:64 (64.0 B)  TX bytes:94 (94.0 B)

You are connected 🙂

Using the OE ppp package

Add ppp support to your image using OE is fairly straightfoward:

  • add the kernel modules to your image
  • add ppp to your image
  • add a custom package that includes the configuration scripts listed above

One thing that may trip you up is the ppp scripts are expecting resolv.conf to be in the following location: /var/run/resolv.conf.  The reason for this is we want resolv.conf in a RAM file system to prevent unneeded flash wear.  Therefore, /etc/resolv.conf should be configured in your rootfs as a soft link to /var/run/resolv.conf.

Summary

The Linux kernel support for USB720 and the pppd package offer a quick, robust way to add cellular network connectivity to about any embedded Linux system that has a USB host port.  As systems become more complex, it will be increasingly important to be able to remotely access systems in the field to troubleshoot problems, help users with configuration, etc.  The USB720 offers a quick way to provide this type of connection without going through the expense of designing cellular connectivity into your product.  One thing I usually encourage all my customers to do when designing new products is expose a USB host port, even though they may not see any immediate use for it.  This is one of those reasons.

Below is a picture of a USB720 connected to a Compulab cm-x270 development system.

usb720_b