The Berkeley motes are a family of embedded sensor nodes sharing roughly the same architecture.
Let us take the MICA mote as an example. The MICA motes have a two-CPU design. The main microcontroller (MCU), an Atmel ATmega103L, takes care of regular processing. A separate and much less capable coprocessor is only active when the MCU is being reprogrammed. The ATmega103L MCU has integrated 512 KB flash memory and 4 KB of data memory. Given these small memory sizes, writing software for motes is challenging. Ideally, programmers should be relieved from optimizing code at assembly level to keep code footprint small. However, high-level support and software services are not free. Being able to mix and match only necessary software components to support a particular application is essential to achieving a small footprint. A detailed discussion of the software architecture for motes.
In addition to the memory inside the MCU, a MICA mote also has a separate 512 KB flash memory unit that can hold data. Since the connection between the MCU and this external memory is via a low-speed serial peripheral interface (SPI) protocol, the external memory is more suited for storing data for later batch processing than for storing programs. The RF communication on MICA motes uses the TR1000 chip set (from RF Monolithics, Inc.) operating at 916 MHz band. With hardware accelerators, it can achieve a maximum of 50 kbps raw data rate. MICA motes implement a 40 kbps transmission rate. The transmission power can be digitally adjusted by software through a potentiometer (Maxim DS1804). The maximum transmission range is about 300 feet in open space.
Like other types of motes in the family, MICA motes support a 51 pin I/O extension connector. Sensors, actuators, serial I/O boards, or parallel I/O boards can be connected via the connector. A sensor/actuator board can host a temperature sensor, a light sensor, an accelerometer, a magnetometer, a microphone, and a beeper. The serial I/O (UART) connection allows the mote to communicate with a PC in real time. The parallel connection is primarily for downloading programs to the mote.
It is interesting to look at the energy consumption of various components on a MICA mote. A radio transmission bears the maximum power consumption. However, each radio packet (e.g., 30 bytes) only takes 4 ms to send, while listening to incoming packets turns the radio receiver ON all the time. The energy that can send one packet only supports the radio receiver for about 27 ms. Another observation is that there are huge differences among the power consumption levels in the active mode, the idle mode, and the suspend mode of the MCU. It is thus worthwhile from an energy-saving point of view to suspend the MCU and the RF receiver as long as possible.
Source of Information : Elsevier Wireless Networking Complete 2010
Sunday, August 19, 2012 | 0 Comments
Sensor node hardware can be grouped into three categories, each of which entails a different
set of trade-offs in the design choices.
● Augmented general-purpose computers: Examples include low-power PCs, embedded PCs (e.g., PC104), custom-designed PCs (e.g., Sensoria WINS NG nodes), 1 and various personal digital assistants (PDAs). These nodes typically run off-the-shelf (OTS) operating systems such as Win CE, Linux, or real-time operating systems and use standard wireless communication protocols such as Bluetooth or IEEE 802.11. Because of their relatively higher processing capability, they can accommodate a wide variety of sensors, ranging from simple microphones to more sophisticated video cameras. Compared with dedicated sensor nodes, PC-like platforms are more power hungry. However, when power is not an issue, these platforms have the advantage that they can leverage the availability of fully supported networking protocols, popular programming languages, middleware, and other OTS software.
● Dedicated embedded sensor nodes: Examples include the Berkeley mote family, the UCLA Medusa family, Ember nodes, 2 and MIT μ AMP. These platforms typically use commercial OTS (COTS) chip sets with emphasis on small form factor, low power processing and communication, and simple sensor interfaces. Because of their COTS CPU, these platforms typically support at least one programming language, such as C. However, in order to keep the program footprint small to accommodate their small memory size, programmers of these platforms are given full access to hardware but barely any operating system support. A classical example is the TinyOS platform and its companion programming language, nesC.
● System-on-chip (SoC) nodes: Examples of SoC hardware include smart dust, the BWRC picoradio node, and the PASTA node. 3 Designers of these platforms try to push the hardware limits by fundamentally rethinking the hardware architecture trade-offs for a sensor node at the chip design level. The goal is to find new ways of integrating CMOS, MEMS, and RF technologies to build extremely low power and small footprint sensor nodes that still provide certain sensing, computation, and communication capabilities. Since most of these platforms are currently in the research pipeline with no predefined instruction set, there is no software platform support available.
Source of Information : Elsevier Wireless Networking Complete 2010
Wednesday, August 15, 2012 | 0 Comments
We discussed various aspects of sensor networks, including sensing and estimation, networking, infrastructure services, sensor tasking, and data storage and query. A real-world sensor network application most likely has to incorporate all these elements, subject to energy, bandwidth, computation, storage, and real-time constraints. This makes sensor network application development quite different from traditional distributed system development or database programming. With ad hoc deployment and frequently changing network topology, a sensor network application can hardly assume an always-on infrastructure that provides reliable services such as optimal routing, global directories, or service discovery.
There are two types of programming for sensor networks, those carried out by end users and those performed by application developers. An end user may view a sensor network as a pool of data and interact with the network via queries. Just as with query languages for database systems like SQL, a good sensor network programming language should be expressive enough to encode application logic at a high level of abstraction, and at the same time be structured enough to allow efficient execution on the distributed platform. Ideally, the end users should be shielded away from details of how sensors are organized and how nodes communicate.
On the other hand, an application developer must provide end users of a sensor network with the capabilities of data acquisition, processing, and storage. Unlike general distributed or database systems, collaborative signal and information processing (CSIP) software comprises reactive, concurrent, distributed programs running on ad hoc, resource-constrained, unreliable computation and communication platforms. Developers at this level have to deal with all kinds of uncertainty in the real world. For example, signals are noisy, events can happen at the same time, communication and computation take time, communications may be unreliable, battery life is limited, and so on. Moreover, because of the amount of domain knowledge required, application developers are typically signal and information processing specialists, rather than operating systems and networking experts. How to provide appropriate programming abstractions to these application writers is a key challenge for sensor network software development. In this chapter, we focus on software design issues to support this type of programming.
To make our discussion of these software issues concrete, we first give an overview of a few representative sensor node hardware platforms. We present the challenges of sensor network programming due to the massively concurrent interaction with the physical world. TinyOS for Berkeley motes and two types of nodecentric programming interfaces: an imperative language, nesC, and a dataflow-style language, TinyGALS. Node-centric designs are typically supported by node-level simulators such as ns-2 and TOSSIM. State-centric programming is a step toward programming beyond individual nodes. It gives programmers platform support for thinking in high-level abstractions, such as the state of the phenomena of interest over space and time.
Source of Information : Elsevier Wireless Networking Complete 2010
Saturday, August 11, 2012 | 0 Comments
Advances in microelectronics technology have made it possible to build inexpensive, low-power, miniature sensing devices. Equipped with a microprocessor, memory, radio, and battery, such devices can now combine the functions of sensing, computing, and wireless communication into miniature smart sensor nodes , also called motes . Since smart sensors need not be tethered to any infrastructure because of on-board radio and battery, their main utility lies in being ad hoc, in the sense that they can be rapidly deployed by randomly strewing them over a region of interest. Several applications of such wireless sensor networks have been proposed, and there have also been several experimental deployments. Example applications are:
● Ecological Monitoring: wild-life in conservation areas, remote lakes, forest fi res.
● Monitoring of Large Structures: bridges, buildings, ships, and large machinery, such as turbines.
● Industrial Measurement and Control: measurement of various environment and process parameters in very large factories, such as continuous process chemical plants.
● Navigation Assistance: guidance through the geographical area where the sensor network is deployed.
● Defense Applications: monitoring of intrusion into remote border areas; detection, identification, and tracking of intruding personnel or vehicles.
The ad hoc nature of these wireless sensor networks means that the devices and the wireless links will not be laid out to achieve a planned topology. During the operation, sensors would be difficult or even impossible to access and hence their network needs to operate autonomously. Moreover, with time it is possible that sensors fail (one reason being battery drain) and cannot be replaced. It is, therefore, essential that sensors learn about each other and organize into a network on their own. Another crucial requirement is that since sensors may often be deployed randomly (e.g., simply strewn from an aircraft), in order to be useful, the devices need to determine their locations. In the absence of a centralized control, this whole process of self-organization needs to be carried out in a distributed fashion. In a sensor network, there is usually a single, global objective to be achieved. For example, in a surveillance application, a sensor network may be deployed to detect intruders. The global objective here is intrusion detection. This can be contrasted with multihop wireless mesh networks , where we have a collection of source – destination pairs, and each pair is interested in optimizing its individual performance metric. Another characteristic feature of sensor networks appears in the packet scheduling algorithms used. Sensor nodes are battery-powered and the batteries cannot be replaced. Hence, energy-aware packet scheduling is of crucial importance.
A smart sensor may have only modest computing power, but the ability to communicate allows a group of sensors to collaborate to execute tasks more complex than just sensing and forwarding the information, as in traditional sensor arrays. Hence, they may be involved in online processing of sensed data in a distributed fashion so as to yield partial or even complete results to an observer, thereby facilitating control applications, interactive computing, and querying. A distributed computing approach will also be energy-efficient as compared to mere data dissemination since it will avoid energy consumption in long haul transport of the measurements to the observer; this is of particular importance since sensors could be used in large numbers due to their low cost, yielding very high resolutions and large volumes of sensed data. Further, by arranging computations among only the neighboring sensors the number of transmissions is reduced, thereby saving transmission energy. A simple class of distributed computing algorithms would require each sensor to periodically exchange the results of local computation with the neighboring sensors. Thus the design of distributed signal processing and computation algorithms, and the mapping of these algorithms onto a network, is an important aspect of sensor network design.
Design and analysis of sensor networks must take into account the native capabilities of the nodes, as well as architectural features of the network. We assume that the sensor nodes are not mobile . Further, nodes are not equipped with position-sensing technology , like the Global Positioning System (GPS). However, each node can set its transmit power at an appropriate level — each node can exercise power control . Further, each node has an associated sensing radius ; events occurring within a circle of this radius centered at the sensor can be detected.
In general, a sensor network can have multiple sinks, where the traffic generated by the sensor sources leaves the network. We consider networks in which only a single sink is present. Further, we will be concerned with situations in which sensors are randomly deployed . In many scenarios of practical interest, preplanned placing of sensors is infeasible, leaving random deployment as the only practical alternative; e.g., consider a large terrain that is to be populated with sensors for surveillance purposes. In addition, random deployment is a convenient assumption for analytical tractability in models. Our study will also assume a simple path loss model , with no shadowing and no fading in the environment.
Source of Information : Elsevier Wireless Networking Complete 2010
Tuesday, August 07, 2012 | 0 Comments
What makes a good mobile website? This is an impossible question to answer, because design and taste are always highly subjective matters. But certain considerations are worth bearing in mind from the start, and these considerations will undoubtedly help you create positive user experiences for your mobile users.
Recognizing Mobile Users
It should go without saying that the most important aspect to developing a mobile website is to ensure that it is available and easy to reach! This sounds straightforward, of course, but it can
actually become relatively involved: It ’ s a fair assumption that existing site owners are very careful to promote and use their current website URL consistently. If you want to create a separate site for your mobile users, should it be a different URL? Should it appear on the same URL? If so, how does the server or CMS know whether to present one type of site or another? How can you cater to user choice and potentially let them switch back and forth between your desktop and mobile sites? How can you publicize the (attractive) fact that the mobile site exists at all? And ensure that it is correctly listed in search engines and directories?
There are glib answers to all these questions, but each has a level of subtly to it, and no matter which technique you use for hosting, selecting, and publicizing your mobile presence, it is inevitable that you will have to distinguish between mobile users and desktop users. In reality, this means detecting between mobile and desktop browsers and then providing different sites or templates accordingly. Users find content in the strangest ways, and it remains the site owner ’ s responsibility to ensure that the right type of experience is given to each type of user. You look at a number of techniques for doing this, both in the general sense, but also for specific content management systems.
A web standards body, the W3C, uses the term thematic consistency . This is not, as you may think, related to themes or the cosmetics of a site, but to the fact that according to the body ’ s “ One Web ” philosophy, the whole Web should be accessible from any device — so given a specific URL, any browser should receive the same content.
This is not to say that the same content should look the same (because the theming of a mobile
web page can be often very different to that of its equivalent desktop page), nor even that users on different devices want to see the same content (because they are quite possibly in a different context, looking for possibly very different things).
But the One Web philosophy is valuable and important, and indeed URLs should always be used in a way that honors the Uniform adjective of the acronym. It would be counterproductive for the
whole mobile web movement if it were to become a disconnected ghetto of content targeted at one type of device alone and did not share links, resources, and content with the vast existing Web.
When you are building your mobile website, think carefully about how its information architecture is sympathetic to this: The same posts, pages, articles, products, and so forth should be easily and consistently accessible from all types of browsers, even if their appearance and surrounding user - interface may be radically different.
It is also important to ensure that your own website ’ s brand is preserved between its mobile and desktop versions. There should be consistency between the theming, color schemes, and the look and feel of different types of sites. If your desktop site is light and airy and your mobile site is dark and cluttered, you will confuse your users, many of whom may remember what your desktop site looks like and may find it hard to correlate that with the mobile site, damaging their trust in your brand or site.
The same goes for your logo, color scheme, feature images, graphical elements and so on; within reason you should endeavor to reuse as much as possible between the two sites. Users need to feel that they are interacting with the same brand while being given an entirely optimized, mobile - centric experience.
Similarly, if your desktop site is renowned for a simple, cheerful, and highly efficient user interface and experience, your mobile users will expect the same of the mobile site. Indeed, due to its constraints, a mobile website obviously needs to have even more attention paid to its usability!
A Dedication to Usability
With limited real estate (both physically and in terms of pixels) and often very different input
techniques — not to mention the fact that users may be in a more time - sensitive context, and with a slower network connection — a mobile device needs to be presented with a site interface that is as efficient to use as possible. At the very least, consider carefully any use of excessive forms, multi - paged wizards to complete common or simple tasks, or complex menus to get to critical functionality. These are not likely to be appreciated by mobile users.
Instead, think hard about what mobile users want to do, and ensure that those critical tasks are as heavily optimized as possible on the mobile version of the interface. Arguably this was one of the big successes of the “ native app ” phenomenon: Although many apps were little more than
views of a company ’ s existing web content, the app paradigm allowed interface designers to think entirely afresh about how it could be accessed. The popular pattern of a toolbar at the bottom of an app ’ s screen with four or five important tasks that can be reached with a thumb seems a long way from the lengthy and complex menu bar across the top of a website, but it shows that the same information architecture and fundamental functionality can always be accessed using different user interface techniques. Think hard about which techniques work best for the new medium and types of devices you are targeting.
Finally, remember the point about the mobile device being so much more than merely a browser on a small screen. Yes, it ’ s phone, an address book, a game console, and so on, but it ’ s also a device that is in the user ’ s hand nearly every hour of the day, a device that brings unique capabilities and possibilities for you to design to.
Never forget that your mobile is an adjective, not a noun. The important point about the mobile
web is not that the user is holding a mobile phone, but that she is mobile. Make the most of the fact that the visitors to your website don ’ t just have a small screen, rather they are out and about in the real world, living their lives, staying connected — and they want to access everything you have to offer, whenever they want it, in a wonderful mobile way.
Source of Information : Wiley - Professional Mobile Web Development with WordPress Joomla and Drupal
Friday, August 03, 2012 | 0 Comments