Open source technology has spread into many different areas of system development, but wireless has been one of the more difficult areas to address. With many more wireless devices using 32-bit microcontroller cores, such as ARM, that are capable of running Linux, there is increasing interest in using Linux in embedded designs. At the same time, there is also the desktop approach, with mainstream Linux distributions such as Debian, Ubuntu, and Mint, that is gaining in popularity and can also be used for development environments.
The Linux Wireless group has a range of the drivers for the majority of commercial wireless chips and cards, but warns that most do not implement all possible features and many have issues. This presents problems for developers of wireless Linux gateways. Hardware from companies not providing complete specifications, free firmware, and drivers can be more problematic to support, and the switching of chipsets by manufacturers without changing model numbers also makes the list less useful.
As a result, the open source community is working to develop drivers that support a range of cards and devices as Linux evolves. The compat -wireless project (now called compat-drivers) is the framework that pulls code from Linux kernel releases and strives to backport them automatically for usage on older Linux kernel releases. Compat-drivers allow developers to make releases of code from newer Linux kernel releases and get the latest drivers to users without having to recompile their entire kernel.
It consists of code from three projects: the linux-2.6-allstable.git kernel; compat-wireless.git; and compat.git.
The compat-wireless stable releases incorporate code from each of these git trees for the respective upstream Linux kernel stable release. A branch called linux-3.x.y exists for each stable release.
At the same time, there is also pressure to combine the advantages of Linux with the low cost and low power of 8-bit wireless devices, and this has led to some very interesting custom approaches such as the Synapse SNAP network.
SNAP networks
For developers wanting to use Linux but not wanting to develop their own drivers and gateway applications, Synapse has developed an ecosystem of hardware modules and software running on Linux to build wireless networks quickly and easily.
These are aimed at systems that monitor the environment around them and issue commands to control other machines and systems. One such machine may be monitoring the ambient light and checking for motion, poised to activate a lighting system. Another might be observing the operating characteristics of a motor and controlling its speed. Yet another may be watching and adjusting the temperature and humidity.
SNAP is a network operating system that can run on any computing platform, from tiny embedded controllers, to notebook and desktop computers running Linux, all the way to massive Internet and Cloud servers.
One of the key features of SNAP is that it performs full mesh routing using any and all available communications interfaces. Employing standard protocols, SNAP fully exploits the communications capabilities made available by the device upon which it is running. These protocols may include IEEE 802.15.4 (ZigBee) and Wi-Fi, as well as wired protocols such as TCP/IP, Ethernet, USB, RS232 and RS485.
When an instance of SNAP is first invoked, it looks for the communications interfaces that are available. The SNAP instance immediately starts "pinging" and monitoring these interfaces to see if any other SNAP instances are in the vicinity. As soon as two or more SNAP instances establish communication, they form a mesh network. As more and more SNAP instances are activated, they automatically integrate themselves into the network. These self-forming, self-healing SNAP-based networks do not require a central controller, providing higher reliability as a controller can form a single point-of-failure in conventional network solutions. All SNAP-enabled devices perform full peer-to-peer mesh routing. If one device fails for any reason, the other devices will automatically route messages around the failed unit.
However, a gateway device running Linux can provide a secure link back to the Internet, protecting the network from intrusion and converting the data so that it can be accessed remotely.
In addition to performing mesh-routing, the SNAP network operating system can also run user-created applications. These applications are captured in the high-level Python scripting language by means of an intuitive, easy-to-use development environment called Portal.
These SNAPpy applications are a combination of SNAP and the Python language. A SNAPpy application is captured in the form of script that calls a suite of small, parameterized functions. These functions can also call each other and functions in one SNAP node may call functions in other nodes.
Figure 1: SNAPpy applications are executed by a virtual machine.
SNAPpy applications are automatically translated into byte code, which may be downloaded into one or more SNAP nodes. As illustrated in Figure 1, each SNAP node includes a SNAPpy (Python) Virtual Machine, which executes the byte code forming the SNAPpy applications. This provides extreme portability, because the SNAPpy Virtual Machine provides a layer of abstraction that separates the applications from the physical hardware. This means that a SNAPpy application executable will immediately run on any processor without requiring any modification or re-compilation.
In SNAPpy, concurrency is achieved through event-driven programming. This means that most SNAPpy functions run quickly to completion, and never “block”or “loop” waiting for something. External events will trigger SNAPpy functions.
SNAP-based wireless networks
SNAP has been ported to a wide variety of low-cost, low-power microcontrollers that can be used in wireless modules. A Hardware Abstraction Layer (HAL) is used to interface SNAP to the outside world in the form of its microcontrollers' input and output pins, which are used to monitor sensors and control actuators. The HAL allows SNAP to be quickly and easily ported to different microcontrollers as required.
Figure 2: The SNAP Hardware Abstraction Layer (HAL) for Linux developers.
In order to keep network traffic to a minimum (thereby conserving bandwidth and power), SNAP provides complete support for remote procedure calls (RPCs). This is a messaging architecture where the name of a function and its associated parameters can be bundled up and broadcast over the network, providing a more efficient network than the large, complex packets employed by conventional networks. Functions in SNAPpy applications can be invoked on any node by any node or by any other device accessing the network. These RPCs can also be used by the Linux gateway and passed through the Internet, allowing remote monitoring and control of the wireless network.
Debugging applications is greatly facilitated by the fact that developers can quickly edit their SNAPpy application scripts, download them "over-the-air" into the wireless nodes, use RPCs to invoke individual functions in those nodes, and monitor any RPCs being made by any network node.
To get SNAP-based wireless networks to communicate with each other via the Internet requires the use of a Connect E10 unit. This is a small, industrial-class, embedded Linux computer running an instantiation of SNAP and with wireless, Ethernet, and USB communications interfaces. When it connects to the Internet, the first thing it does is to log on to the SNAP Cloud server and provides the username and password that is associated with a particular "community" that the user has set up. Any SNAP network whose SNAP Connect E10 has the same username and password can communicate with other networks in the same community. Similarly, any user can access any node on any SNAP-enabled wired or wireless network using the username and password associated with that community. This allows a system administrator to monitor and control networks located around the globe. The SNAP-cloud handles the firewall issues with allowing data through to the different networks, based on the permission from the E10 connect units.
Portal
Developing the applications requires the use of Synapse’s Portal. This is an interactive, wireless application development environment that runs on Linux using a syntax-highlighted Python editor to create scripts to wirelessly download into SNAP nodes. Portal supports a fast, real-time view of the SNAP network, configuration and monitoring of the devices, a channel analyzer, data and event logging, and more.
All devices are peers, so any device can be a bridge for Portal, do mesh routing, and sleep, among other things, and there are no “coordinators” in SNAP. As SNAP implements a full mesh topology, any node can talk directly to any other node within radio range, and can talk indirectly to any node within the SNAP network. Communication among devices can be unicast (reliable) or multicast (unacknowledged) and the Portal appears as a peer device on the SNAP network.
Figure 3: The Synapse Portal runs on Linux.
All SNAP devices implement a core set of built-in functions (procedures) to handle basic network configuration, system services, and device hardware control. These functions may be invoked remotely from Portal or from any other device on the SNAP network. Additional user-defined functions may be uploaded to devices as well. This upload process can be over directly connected serial interfaces, or over the air. Once uploaded, these functions are also callable locally or remotely, and may themselves invoke local and remote functions.
Like the SNAP nodes, Portal can also be extended through scripting. By loading a script, users can add new functions to Portal, which you (and the other SNAP nodes) can call. These Portal scripts are written in full Python, so there are not the limitations of the embedded SNAPpy subset.
These capabilities can be explored in the EK2500 development kit. This provides the RF Engine hardware, SNAP network firmware, and Portal desktop software for running on a Linux desktop or gateway.
Figure 4: The Synapse EK2500 development kit.
However, many developers are looking to build a Linux gateway from individual components and Sagrad has developed open source drivers for its hardware and an API to support high volume developments.
This gives system implementers unprecedented control over their project both technically and from a risk and support perspective. This software is matched with one of the highest volume and most robust 802.11 chipsets sold in the cellular markets. This versatile combination has been optimized for both performance and battery consumption.
The API is provided just above the hardware extraction level so that the engineer does not need to deal with the details of the hardware control. The API provides enough functionally to complete everything beyond packet send and receive. The rest of the protocol is open for customer modification.
The open source project should lead to a completely open-source MAC, and is supported by a number of large commercial companies. It enables customers to implement custom protocols and applications, using the low cost silicon normally used for 802.11, and allows projects to be completed with very-low-cost microprocessor solutions. The sample code provides a simple pack transmission and reception scheme, which is interoperable with other 802.11 chip sets, but does not yet implement connection tracking schemes needed for standard 802.11.
As an example of the hardware, Sagrad’s SG901-1059B Wi-Fi module is a high-speed module supporting all data rates of the latest standards including Wi-Fi 802.11B/G/N using a USB 2.0 interface. The module’s high level of interoperability and its low cost is desirable for high volume applications and is suited for many embedded systems able to support Linux including high bandwidth applications such as gateways.
Figure 5: Sagrad’s SG901-1059B Wi-Fi module.
The SG901-1059B WLAN module is designed to operate in the 2.4 GHz ISM frequency band. It uses a highly integrated MAC/BBP and RF single chip RT3070 design with 150 Mbps PHY rate support. The module fully complies with IEEE802.11n draft 3.0 and IEEE802.11b/g feature sets.
It is still possible to use cards such as the SG901-1059B in a Linux gateway without an API like Sagrad’s. Drivers for the card support Linux2.4 and 2.6, and it is relatively simple to install the card for Ubuntu Linux as a root [su] user.
Using the command [sudo apt-get install ndisgtk] installs the packages that are needed: the ndiswrapper packages and the ndisgtk package. Developers can use a GUI tool to connect to the wireless network using the drivers that sit (or can be saved to) the directory of/etc/ndiswrapper/cardname. These include the .inf and .sys files for the different cards. Sometimes the drivers will be a .exe file, which can be packed into .inf and .sys file using an application such as Wine in Ubuntu.
With more wireless devices using a 32-bit processor core such as the ARM7 or ARM9, Linux can be run alongside the wireless protocol stacks in a gateway.
The deRFgateway development board from dresden elektronik is optimally tuned to the company’s existing radio modules. These are equipped with temperature, light and acceleration sensors for measurement tasks in home and industrial environments.
At the same time, there is also pressure to combine the advantages of Linux with the low cost and low power of 8-bit wireless devices, and this has led to some very interesting custom approaches such as the Synapse SNAP network.
Figure 6: The deRFgateway.
With on-board Ethernet in the deRFgateway, USB, sensors, LEDs and user buttons, the boards are suited for evaluation and development of IEEE 802.15.4 based wireless sensor networks using Zigbee or 6LoWPAN protocols, but also for the immediate implementation in an end-user application running Linux.
The version with a female connector for all pluggable deRF modules gives the user a high flexibility in terms of processor type and performance as well as the frequency range. Since all deRF modules are pin compatible, the user can select the best match or even change easily during the development process. The transition from 2.4 GHz to sub GHz, the change from an AVR to ARM processor, or the exchange of the chip ceramic antenna with an external antenna is simple. For higher volumes, a solderable module is also available.
The power to the deRFgateway is supplied either by USB, an AC adapter, or three AA batteries. The standard JTAG connections for ARM and AVR are present for the programming and debug interface together with other standard interfaces like SPI, UART and I²C. Additional sensors for special measurement tasks can be connected using the 34-pin expansion header.
The Ethernet connection opens up a wide field of applications, such as a Zigbee gateway, IPv4/IPv6 access to 6LoWPAN networks, as well as back-end connections in widely spread sensor networks. Due to the relatively high current consumption of the Ethernet transceiver, a power saving deRFnode has been developed. The strict low power design of the deRFnode and all its components makes it especially useful for end devices. On battery operation, it can easily reach a lifetime of several years.
Conclusion
With more devices using 32-bit cores, Linux is an increasingly popular option for developers. With open source activities such as open APIs and the compat-driver group, the ability to integrate wireless networks and Linux gateways is improving. At the same time, more custom networks also harness the flexibility of mesh-networks and Linux to provide cost effective, scalable networks that can be easily accessed over the Internet via Linux gateways.
