[wol] Wake on Lan

wakeonlan client

On the computer you will use to send the WOL packet, you need to have a client to generate this kind of data. You may use net-misc/wakeonlan Perl script as client, which is in Portage tree:

 emerge -n net-misc/wakeonlan

Prepare and wake up your PC

You need to know the MAC address of the PC you want to wake up; you may get this information from the client PC using ping towards the PC you want to wake up (in this example 192.168.20.52) and then you can see the arp table:

 ping 192.168.20.52 arp

You will have an output similar to this, from which you'll get the MAC address:

Code:

Address                  HWtype  HWaddress           Flags Mask            Iface jupiter.home.net         ether   00:0C:6E:96:58:DE   C                     eth0

Now, you may switch off the computer on which you want to try WOL. From the client PC, you have to send the WOL packet:

 wakeonlan -i 192.168.20.255 00:0C:6E:96:58:DE

In this example, we send the WOL packet in broadcast to the subnet 192.168.20.x, using the MAC address we got before. Now, if everything is ok, you see your computer wake up magically!

WOL always enabled on shutdown

You may experience that, on next reboot of system, your PC won't wake up, even if you send WOL packet correctly from another box; this is due to the fact that the ethernet driver will lose it's previous configuration during boot.

A quick and clean way to get rid of this, and let the wake on LAN be enabled on every shut-down, is to add this line to /etc/conf.d/local.stop

Code: /etc/conf.d/local.stop

ethtool -s eth1 wol g

This is the same command used to enable WOL previously used from shell; when your Gentoo box turns off, the commands presents in this configuration file are executed, so you'll have WOL enabled at every shut-down.

[info] ASCII Table

[info] detect internet IP

http://ipid.shat.net/iponly/

this site can used in other program to detect external IP addr

Serial/TCP Terminal

realTerm

\url http://sourceforge.net/projects/realterm/

[wow] WOW client and patches download

http://www.wow-patch.in

[wireless]Wireless System overview

Wireless System

Wireless System Overview

Since ancient times, humans have learned to cooperate in order to overcome nature's limitations. There is a growing need to exchange information and services quickly and effortlessly across local, national and now global communities. People want the ability to communicate any time, anywhere in our mobile society.

Wireless technologies make our mobile society possible. Apple's iPod library syncs up with a laptop computer, drivers navigate their cars over uncharted roads, bargain hunters browse online stores, business travelers collaborate 24/7 with associates around the globe. Regardless of the circumstance, people today have an unprecedented level of mobility thanks to any combination of the four common wireless services:

1. WPAN: < 10 m, such as hands-free cell phones

2. WLAN: < 100 m, such as laptop to broadband access
3. WMAN: < xx Kms, such as building-to-building
4. WWAN: cell phones

In general, WLAN provides the most versatile service. WPAN range is too short and still binds the user to the nearest node. WMAN is too bulky and expensive to lug around. And WWMAN suffers speed and service charge constraints.

According to industry consensus, WLAN applications consist of three categories that cover many of our day to day mobility requirements:

1. PC Networking: Desktop Computers, Laptops, Routers, Printers, etc.

2. Consumer Electronics: Video Game consoles, Projectors, DVD players, TVs, Set-top boxes, Digital Cameras, Security Cameras, etc.

3. Handheld Devices: Mobile Phones, PDAs, iPods, Video iPods, etc.

In order to ensure high throughput, good range and universal interoperability, IEEE 802.11x standards govern WLAN operations. WLAN and IEEE 802.11x have become synonymous over the years:

IEEE 802.11 - The original 1 Mbit/s and 2Mbit/s, 2.4GHz RF and IR standard (1999)
IEEE 802.11a - 54Mbit/s, 5 GHz standard (1999, shipping products in 2001)
IEEE 802.11b - Enhancements to 802.11 to support 5.5 and 11 Mbit/s (1999)
IEEE 802.11c - Bridge operation procedures; included in the IEEE 802.1D standard (2001)
IEEE 802.11d - International (country-to-country) roaming extensions (2001)
IEEE 802.11e - Enhancement: QoS, including packet bursting (2005)
IEEE 802.11f - Inter-Access Point Protocol (2003) Withdrawn February 2006
IEEE 802.11g - 54 Mbit/s, 2.4 GHz standard (backwards compatible with b) (2003)
IEEE 802.11h - Spectrum Managed 802.11a (5 GHz) for European compatibility (2004)
IEEE 802.11i - Enhanced security (2004)
IEEE 802.11j - Extensions for Japan (2004)
IEEE 802.11k - Radio resource measurement enhancements
IEEE 802.11l - (reserved and will not be used)
IEEE 802.11m - Maintenance of the standard: odds and ends
IEEE 802.11n - Higher throughput improvements
IEEE 802.11o - (reserved and will not be used)
IEEE 802.11p - WAVE - Wireless Access for the Vehicular Environment (such as ambulances and passengers cars)
IEEE 802.11q - (reserved and will not be used, can be confused with 802.1Q VLAN trunking)
IEEE 802.11r - Fast roaming
IEEE 802.11s - ESS Mesh Networking
IEEE 802.11t - Wireless Performance Prediction (WPP) - test methods and metrics
IEEE 802.11u - Compatibility with non-802 networks (e.g., cellular)
IEEE 802.11v - Wireless network management
IEEE 802.11w - Protected Management Frames
IEEE 802.11x - (reserved and will not be used)
IEEE 802.11y - 3650-3700 Operations in USA

Among the physical layers, .11, .11b, .11a, .11g and Draft n offer progressive speeds over the course of development, which are as follows

Standard	Year	Modulation	Peak Rate	Peak Throughput
.11	1999	DSSS	2 Mbps	1 Mbps
.11b	1999	CCK	11 Mbps	6 Mbps
.11a	1999	OFDM	54 Mbps	25 Mbps
.11g	2003	OFDM	54 Mbps	22 Mbps
Draft n	2006	MIMO OFDM	300 Mbps	180 Mbps

Also available are security features vital to wireless protection; QoS support that improves the service quality when service compromise becomes inevitable; radar detection that avoids interference with airport or weather Radar operations.

Users should evaluate application needs carefully and tailor the product appropriately. A sample of video application requirements are listed as follows:

Application	Throughput
SDTV	5 Mbps
Cable Modem	6 Mbps
DVD	9.8 Mbps
HDTV	12.9 Mbps
ADSL2+	20 Mbps
FTTH	30 Mbps
HD DVD	36 Mbps
Blue-ray DVD	48 Mbps
VDSL	50 Mbps

Video streaming is very demanding in frame errors, e.g., FER < 10-4 or tighter, so the peak throughput of a specific WLAN device is recommended to scale down to one-third of its original value for budgetary purposes. For example, a peak throughput of 15 Mbps is necessary for satisfactory SDTV streaming at 5 Mbps in general.

[vim] Use Vim to edit file in hex format directly

:%!xxd

[edit the file]

:%!xxd -r

[cygwin]Howto make a portable cygwin environment

I, have thoroughly emigrated to Linux, need a Linux-Like environment
to make things better in my PC-Architecture course, so I decide to
make a portable cygwin environment.

Because I have no portable devices, such as Flash Disk. I have to
upload the whole environment to internet for further downloading.

Here is WHAT I do to make such a portable cygwin environment.

1. cp the cygwin which is already installed when I used windows to a
work directory named $cygwin.
2. write a script to make a cygwin environment, such as where is the
/, /usr and /bin in windows
use $cygwin/bin/mount to make mount points on which the
$cygwin/bin/bash depends to make a work environment.

/etc/profile will be read when evoke bash with a --login parameter,
namely evoke a login bash shell

[fpga] Storing Quartus II projects under version control

reference at nios2wiki

Storing Quartus II projects under version control

There is no need to backup all files in a Quartus project to be able reproduce it. You have to store source files (so that you can modify the project) and final binary files (so that you can reproduce the system exactly).

NOTE: This is not the final list yet, but it works for most simple projects (the software part is still missing). You should still test a reconstruction of the project from this files.

Quartus II source files:

project files:
- project_name.qpf Quartus II project file
- project_name.qsf Quartus constraint file (lists the hardware constraints defined for a project, from the used chip and pinout to timing constraints)
- project_name.qws Quartus Window Settings ? (the configuration of the Quartus gui for the project, may be omitted)
top level source files:
- project_name.bdf Block diagram / Schematic file (top level schematic file, there may be many nested files)
- project_name.vhd VHDL file (top level VHDL file)
- project_name.v Verilog file (top level Verilog file)
component source files:
- component_name.bsf Block Symbol file (component symbol file)
- component_name.vhd VHDL file (top level VHDL file)
- component_name.v Verilog file (top level Verilog file)
SOPC builder project source files (SOPC builder creates many VHDL or Verilog files, that you do not need to store)
- sopc_project_name.ptf the list and configuration of components selected in the SOPC gui
- sopc_project_name.bsf Block Symbol file (SOPC component symbol file, especially if you modified it)
Board Description (if you created your own board, the list is incomplete!)
- board_name/class.ptf
software source files:
- tbd

Quartus II binary files

hardware binary files
- project_name.sof SRAM Object File
software binary files
- tbd

Reconstructing a project from a subversion repository

Since the subversion repository contains only the necessary files, a procedure should be followed for reconstructing the full project from the repository.

Import the selected project from the subversion repository to the local drive.
Open the project in Quartus II.
Open the SOPC builder project and build it.
Build the Quartus II project and program the hardware into the FPGA.
Import the software part of the project into a NIOS IDE workplace.

References

Archiving SOPC Builder Projects http://www.altera.com/literature/hb/qts/qts_qii54017.pdf

[solved] Locking assertion failure. Matlab R2008a.

reference at https://answers.edge.launchpad.net/ubuntu/+question/26562

export LIBXCB_ALLOW_SLOPPY_LOCK=1

[udev]Check cable status of LAN

To check carrier status

cat /sys/class/net/eth0/carrier

[gentoo]x11-libs/libxcb-1.3 has no libxcb-xlib.so.0.0.0

why?

[info]rsync

Delta-transfer algorithm, which only transfers difference

[web]Download film directly using Wget

Ah oh, my univ. has a VOD server, but we cannot download the movies that storage on it directly.

After sniffer some package, I know how to download it

here it is

add a header to http request,

GUID: 00000000-0000-0000-0000-000000000000

and set user agent to

RMA/1.0

use wget to download it

wget -U "RMA/1.0" \
--header="ClientID: WinNT_5.1_6.0.12.1056_RealPlayer_R30CND_zh-CN_686"
URL

[linux] live CD/DVD Howto

Ref. at ubuntuforum.org

Background on live CD/DVD

Note: This section is a clarification of how live CD works. You don't have to read it. You can skip it if you want.

A live CD/DVD is basically a normal linux installation just like an ordinary harddrive installation. However, simply copying the harddirve installation over to a CD/DVD is not enough to produce a working system. Why? because there are still minor differences between a live CD/DVD and on ordinary harddrive installation. So in addition to copying our harddirve installation to the CD/DVD we must address those differences as well.

So what are these differences?

The CD or DVD is read only media. Linux needs to have write access to certain parts of the system to be able to operate properly (like "/dev" "/proc" "/var" "/tmp"). There are a lot of approaches to address this problem. All of which utilize the system RAM. Some of these approaches enable write access only to essential directories and files, and hence, they do not allow the user to modify the system or install new packages while in the live CD. Other approaches, like unionfs which is what is used in this guide, allows the user to write to any part of the system. This is done by merging part of the RAM with the read-only filesystem of the live CD/DVD and making the look like one filesystem that have read-write access. Unionfs has to be mounted at boot in a certain manner.
With the harddrive installation the location of the root filesystem is fixed. So it is passed to the kernel at boot time using the root=/dev/... parameter. With a live CD/DVD, the location of the root device is not fixed as the user might have multiple cdrom drives, these drives can be ide, scsi ... etc. So for the root filesystem to be mounted, there must be a way to identify the root device, and then we have to load the suitable kernel modules (to be able to access the cdrom controller as well as the CD filesystem). All this has to be done even before we have a root filesystem mounted.
To fit on a CD, the filesystem is usually compressed using squashfs. So we need to autodetect the filesystem type. We also need to have the proper modules for mounting it.

These considerations require special preparation at boot time, some of which must be performed even before mounting the actual filesystem. How can we do this?

Linux introduced a mechanism that allow for such preparations at boot time before the actual root filesystem is mounted. It is called the initial root filesystem or initramfs. This mechanism is used also in mounting normal harddirve installations, as it adds flexibilty to the boot process.

initramfs is virtual filesystem. It is a compressed cpio (cpio is an archive format similar to tar) archive that contains a minimal shell, kernel modules necessary for mounting the root filesystem and number of scripts that perform some tasks at boot time. The most important of these scripts is a script called init located at the root of the initramfs.

How does initramfs work?

The boot loader loads both the kernel and the initramfs into memory and starts the kernel. The kernel then unpacks the initramfs and mount it as initial root filesystem, and then looks for the init program within the initial filesystem, and once it finds it, it executes it and hand the boot process over to it. This init scirpt is responsible for finding the real root filesystem and mounting it. It is also responsible for any special preparations required at boot time.

So any special operations required for booting the system from live media can be coded into the initramfs boot scripts.

How is initramfs is created?

We do not have to create initramfs manually (although it can be done). There are tools for creating and updating initramfs like the command update-initramfs. Moreover, these tools can include custom scripts into the initramfs if they are placed in a certain preset locations (/usr/share/initramfs/scripts). So all we have to do is dump our custom scripts (which will do all the required preparation for booting the live CD/DVD) into these preset locations, and then create a custom initramfs by running update-initramfs.

We don't even have to write these scripts. Why? becuase there are packages that have scripts tailored for booting form live CDs. One of these packages is called casper (this is the package used in this howto). By installing casper into the system, it places the scripts in there proper locations (where they can be spotted by update-initrfamfs). The only thing we need to do after installing casper is running update-initramfs to create an initramfs suitable for live CD/DVD.

The live CD/DVD structure:

The directory tree of the live CD/DVD we are going to create is going to look like this:

Code:

(CD ROOT)
|-------+casper
|	|-------filesystem.${FORMAT}	
|	|-------filesystem.manifest
|	|-------filesystem.manifest-desktop
|	
|-------+boot
|	|--------+grub
|	|	 |--------menu.lst
|	|	 |--------stage2_eltorito
|	|
|	|-------vmlinuz
|	|-------initrd.gz
|	|-------memtest86+
|
|--------md5sum.txt

/casper/filesystem.${FORMAT}: This is the container of the linux filesystem we are going to copy from our harddisk. It is usually a compressed filesystem like squahsfs.

/casper/filesystem.manifest: This file is optional. You only need it if you decide to include the Ubuntu installer in the CD. The purpose of this file will be explained later.

/casper/filesystem.manifest-desktop: This file is optional. You only need it if you decide to include the Ubuntu installer in the CD. The purpose of this file will be explained later.

/boot/grub/menu.lst: File containing boot options for the live CD/DVD.

/boot/grub/stage2_eltorito: The boot loader of the CD. (stage2 of grub).

/boot/vmlinuz: The linux kernel. This is copied form the linux filesystem.

/boot/initrd.gz: the initramfs that contain the customizations necessary for the live CD/DVD.

/boot/memtest86+: Optional file used to test the RAM of the machine form the live CD/DVD.

/md5sum.txt: Optional file containing checksums for all the files in the CD.

[info] use google to search locale related info.

http://www.google.com/intl/$locale/

where $locale is the abbrevation of locale. and the last slash is neccesary.

e.g.

search japanese

http://www.google.com/intl/ja/

engliah

http://www.google.com/intl/en/

chinese

http://www.google.com/intl/zh_cn/

[info] skip the authentication of Computer Lib ,Ynu

when the system boot , there are two processes to check the validity of logon user.

remotecfg.exe and remoteAutoLoad.exe

this two procresses are interlocked, say that while we close one, the other will detect this behavior

and start it again.

Method to close both:

1 use debuger ntsd to stop one

2 close the other

3 close the debuged one

[info]Manipulating config file when programming

libconfig
libconfuse
lua

[info] Disable write buffer of usb flash key

mount with sync, dirsync

[info] convert text Encoding on linux

iconv

Great Utility!

[info] Vim-like pdf viewer

apvlv

http://apvlv.googlecode.com

[math]A good place for seaching algorithm

Numerical Recipes

http://www.nr.com/

[info]Online Proxy

well, i love it 'cos speedness.

http://zend2.com

t

[xml]XML Information Set

XML Information Set (Second Edition)

W3C Recommendation 4 February 2004

This version:: http://www.w3.org/TR/2004/REC-xml-infoset-20040204
Latest version:: http://www.w3.org/TR/xml-infoset
Previous version:: http://www.w3.org/TR/2003/PER-xml-infoset-20031210
Editors:: John Cowan, jcowan@reutershealth.com; Richard Tobin, richard@cogsci.ed.ac.uk

Please refer to the errata for this document, which may include some normative corrections.

Abstract

This specification provides a set of definitions for use in other specifications that need to refer to the information in an XML document.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is a Recommendation of the W3C. It has been reviewed by W3C Members and other interested parties, and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

This document updates the Infoset to cover XML 1.1 and Namespaces 1.1, clarifies the consequences of certain kinds of invalidity, and corrects some typographical errors. It is a product of the W3C XML Activity. The English version of this specification is the only normative version. However, for translations of this document, see http://www.w3.org/2003/03/Translations/byTechnology?technology=xml-infoset.

Documentation of intellectual property possibly relevant to this recommendation may be found at the Working Group's public IPR disclosure page.

Please report errors in this document to www-xml-infoset-comments@w3.org (public archives are available). The errata list for this Recommendation is available at http://www.w3.org/2001/10/02/xml-infoset-errata.html.

1. Introduction

This specification defines an abstract data set called the XML Information Set (Infoset). Its purpose is to provide a consistent set of definitions for use in other specifications that need to refer to the information in a well-formed XML document [XML].

It does not attempt to be exhaustive; the primary criterion for inclusion of an information item or property has been that of expected usefulness in future specifications. Nor does it constitute a minimum set of information that must be returned by an XML processor.

An XML document has an information set if it is well-formed and satisfies the namespace constraints described below. There is no requirement for an XML document to be valid in order to have an information set.

Information sets may be created by methods (not described in this specification) other than parsing an XML document. See Synthetic Infosets below.

An XML document's information set consists of a number of information items; the information set for any well-formed XML document will contain at least a document information item and several others. An information item is an abstract description of some part of an XML document: each information item has a set of associated named properties. In this specification, the property names are shown in square brackets, [thus]. The types of information item are listed in section 2.

The XML Information Set does not require or favor a specific interface or class of interfaces. This specification presents the information set as a modified tree for the sake of clarity and simplicity, but there is no requirement that the XML Information Set be made available through a tree structure; other types of interfaces, including (but not limited to) event-based and query-based interfaces, are also capable of providing information conforming to the XML Information Set.

The terms "information set" and "information item" are similar in meaning to the generic terms "tree" and "node", as they are used in computing. However, the former terms are used in this specification to reduce possible confusion with other specific data models. Information items do not map one-to-one with the nodes of the DOM or the "tree" and "nodes" of the XPath data model.

In this specification, the words "must", "should", and "may" assume the meanings specified in [RFC2119], except that the words do not appear in uppercase.

XML Versions

Different versions of the XML specification may specify different parsing rules. The information set of an XML document is defined to be the one obtained by parsing it according to the rules of the specification whose version corresponds to that of the document. A document which does not specify a version number is considered to have version 1.0. If an XML processor accepts a document with a version number that it does not understand, it will not necessarily be able to produce the correct information set.

Namespaces

XML documents that do not conform to [Namespaces], though technically well-formed, are not considered to have meaningful information sets. That is, this specification does not define an information set for documents that have element or attribute names containing colons that are used in other ways than as prescribed by [Namespaces].

Furthermore, this specification does not define an information set for documents which use relative URI references in namespace declarations. This is in accordance with the decision of the W3C XML Plenary Interest Group described in [Relative Namespace URI References].

The value of a [namespace name] property is the normalized value of the corresponding namespace attribute; no additional URI escaping is applied to it by the processor.

Entities

An information set describes its XML document with entity references already expanded, that is, represented by the information items corresponding to their replacement text. However, there are various circumstances in which a processor may not perform this expansion. An entity may not be declared, or may not be retrievable. A non-validating processor may choose not to read all declarations, and even if it does, may not expand all external entities. In these cases an unexpanded entity reference information item is used to represent the entity reference.

End-of-Line Handling

The values of all properties in the Infoset take account of the end-of-line normalization described in [XML], 2.11 "End-of-Line Handling".

Base URIs

Several information items have a [base URI] or [declaration base URI] property. These are computed according to [XML Base]. Note that retrieval of a resource may involve redirection at the parser level (for example, in an entity resolver) or below; in this case the base URI is the final URI used to retrieve the resource after all redirection.

The value of these properties does not reflect any URI escaping that may be required for retrieval of the resource, but it may include escaped characters if these were specified in the document, or returned by a server in the case of redirection.

In some cases (such as a document read from a string or a pipe) the rules in [XML Base] may result in a base URI being application dependent. In these cases this specification does not define the value of the [base URI] or [declaration base URI] property.

When resolving relative URIs the [base URI] property should be used in preference to the values of xml:base attributes; they may be inconsistent in the case of Synthetic Infosets.

``Unknown'' and ``No Value''

Some properties may sometimes have the value unknown or no value, and it is said that a property value is unknown or that a property has no value respectively. These values are distinct from each other and from all other values. In particular they are distinct from the empty string, the empty set, and the empty list, each of which simply has no members. This specification does not use the term null since in some communities it has particular connotations which may not match those intended here.

Inconsistencies Resulting from Invalidity

As noted above, an XML document need not be valid to have an information set. However, certain kinds of invalidity affect the values assigned to some properties. Entities, notations, elements and attributes may be undeclared. Notations and elements may be multiply declared (multiple declarations are valid for entities and attributes). An ID may be undefined or multiply defined. Such cases are noted where relevant in the Information Item definitions below.

Synthetic Infosets

This specification describes the information set resulting from parsing an XML document. Information sets may be constructed by other means, for example by use of an API such as the DOM or by transforming an existing information set.

An information set corresponding to a real document will necessarily be consistent in various ways; for example the [in-scope namespaces] property of an element will be consistent with the [namespace attributes] properties of the element and its ancestors. This may not be true of an information set constructed by other means; in such a case there will be no XML document corresponding to the information set, and to serialize it will require resolution of the inconsistencies (for example, by outputting namespace declarations that correspond to the namespaces in scope).

2. Information Items

An information set can contain up to eleven different types of information item, as explained in the following sections. Every information item has properties. For ease of reference, each property is given a name, indicated [thus]. Links to a definition and/or syntax in the XML 1.0 Recommendation [XML] are given for each information item.

2.1. The Document Information Item

XML Definition: document (Section 2, Documents)

XML Syntax: [1] Document (Section 2.1, Well-Formed XML Documents)

There is exactly one document information item in the information set, and all other information items are accessible from the properties of the document information item, either directly or indirectly through the properties of other information items.

The document information item has the following properties:

[children] An ordered list of child information items, in document order. The list contains exactly one element information item. The list also contains one processing instruction information item for each processing instruction outside the document element, and one comment information item for each comment outside the document element. Processing instructions and comments within the DTD are excluded. If there is a document type declaration, the list also contains a document type declaration information item.
[document element] The element information item corresponding to the document element.
[notations] An unordered set of notation information items, one for each notation declared in the DTD. If any notation is multiply declared, this property has no value.
[unparsed entities] An unordered set of unparsed entity information items, one for each unparsed entity declared in the DTD.
[base URI] The base URI of the document entity.
[character encoding scheme] The name of the character encoding scheme in which the document entity is expressed.
[standalone] An indication of the standalone status of the document, either yes or no. This property is derived from the optional standalone document declaration in the XML declaration at the beginning of the document entity, and has no value if there is no standalone document declaration.
[version] A string representing the XML version of the document. This property is derived from the XML declaration optionally present at the beginning of the document entity, and has no value if there is no XML declaration.
[all declarations processed] This property is not strictly speaking part of the infoset of the document. Rather it is an indication of whether the processor has read the complete DTD. Its value is a boolean. If it is false, then certain properties (indicated in their descriptions below) may be unknown. If it is true, those properties are never unknown.

2.2. Element Information Items

XML Definition: element (Section 3, Logical Structures)

XML Syntax: [39] Element (Section 3, Logical Structures)

There is an element information item for each element appearing in the XML document. One of the element information items is the value of the [document element] property of the document information item, corresponding to the root of the element tree, and all other element information items are accessible by recursively following its [children] property.

An element information item has the following properties:

[namespace name] The namespace name, if any, of the element type. If the element does not belong to a namespace, this property has no value.
[local name] The local part of the element-type name. This does not include any namespace prefix or following colon.
[prefix] The namespace prefix part of the element-type name. If the name is unprefixed, this property has no value. Note that namespace-aware applications should use the namespace name rather than the prefix to identify elements.
[children] An ordered list of child information items, in document order. This list contains element, processing instruction, unexpanded entity reference, character, and comment information items, one for each element, processing instruction, reference to an unprocessed external entity, data character, and comment appearing immediately within the current element. If the element is empty, this list has no members.
[attributes] An unordered set of attribute information items, one for each of the attributes (specified or defaulted from the DTD) of this element. Namespace declarations do not appear in this set. If the element has no attributes, this set has no members.
[namespace attributes] An unordered set of attribute information items, one for each of the namespace declarations (specified or defaulted from the DTD) of this element. Declarations of the form xmlns="" and xmlns:name="", which undeclare the default namespace and prefixes respectively, count as namespace declarations. Prefix undeclaration was added in Namespaces in XML 1.1. By definition, all namespace attributes (including those named xmlns, whose [prefix] property has no value) have a namespace URI of http://www.w3.org/2000/xmlns/. If the element has no namespace declarations, this set has no members.
[in-scope namespaces] An unordered set of namespace information items, one for each of the namespaces in effect for this element. This set always contains an item with the prefix xml which is implicitly bound to the namespace name http://www.w3.org/XML/1998/namespace. It does not contain an item with the prefix xmlns (used for declaring namespaces), since an application can never encounter an element or attribute with that prefix. The set will include namespace items corresponding to all of the members of [namespace attributes], except for any representing declarations of the form xmlns="" or xmlns:name="", which do not declare a namespace but rather undeclare the default namespace and prefixes. When resolving the prefixes of qualified names this property should be used in preference to the [namespace attributes] property; they may be inconsistent in the case of Synthetic Infosets.
[base URI] The base URI of the element.
[parent] The document or element information item which contains this information item in its [children] property.

2.3. Attribute Information Items

XML Definition: attribute (Section 3.1, Start-Tags, End-Tags, and Empty-Element Tags)

XML Syntax: [41] Attribute (Section 3.1, Start-Tags, End-Tags, and Empty-Element Tags)

There is an attribute information item for each attribute (specified or defaulted) of each element in the document, including those which are namespace declarations. The latter however appear as members of an element's [namespace attributes] property rather than its [attributes] property.

Attributes declared in the DTD with no default value and not specified in the element's start tag are not represented by attribute information items.

An attribute information item has the following properties:

[namespace name] The namespace name, if any, of the attribute. Otherwise, this property has no value.
[local name] The local part of the attribute name. This does not include any namespace prefix or following colon.
[prefix] The namespace prefix part of the attribute name. If the name is unprefixed, this property has no value. Note that namespace-aware applications should use the namespace name rather than the prefix to identify attributes.
[normalized value] The normalized attribute value (see 3.3.3 Attribute-Value Normalization [XML]).
[specified] A flag indicating whether this attribute was actually specified in the start-tag of its element, or was defaulted from the DTD.
[attribute type] An indication of the type declared for this attribute in the DTD. Legitimate values are ID, IDREF, IDREFS, ENTITY, ENTITIES, NMTOKEN, NMTOKENS, NOTATION, CDATA, and ENUMERATION. If there is no declaration for the attribute, this property has no value. If no declaration has been read, but the [all declarations processed] property of the document information item is false (so there may be an unread declaration), then the value of this property is unknown. Applications should treat no value and unknown as equivalent to a value of CDATA. The value of this property is not affected by the validity of the attribute value.
[references] If the attribute type is ID, NMTOKEN, NMTOKENS, CDATA, or ENUMERATION, this property has no value. If the attribute type is unknown, the value of this property is unknown. Otherwise (that is, if the attribute type is IDREF, IDREFS, ENTITY, ENTITIES, or NOTATION), the value of this property is an ordered list of the element, unparsed entity, or notation information items referred to in the attribute value, in the order that they appear there. In this case, if the attribute value is syntactically invalid, this property has no value. If the type is IDREF or IDREFS and any of the IDs does not appear as the value of an ID attribute in the document, or if the type is ENTITY, ENTITIES or NOTATION and no declaration has been read for any of the entities or the notation, then this property has no value or is unknown, depending on whether the [all declarations processed] property of the document information item is true or false. If the type is IDREF or IDREFS and any of the IDs appears as the value of more than one ID attribute in the document, or if the type is NOTATION and there are multiple declarations for the notation, then this property has no value.
[owner element] The element information item which contains this information item in its [attributes] property.

2.4. Processing Instruction Information Items

XML Definition: processing instruction (Section 2.6, Processing Instructions)

XML Syntax: [16] PI (Section 2.6, Processing Instructions)

There is a processing instruction information item for each processing instruction in the document. The XML declaration and text declarations for external parsed entities are not considered processing instructions.

A processing instruction information item has the following properties:

[target] A string representing the target part of the processing instruction (an XML name).
[content] A string representing the content of the processing instruction, excluding the target and any white space immediately following it. If there is no such content, the value of this property will be an empty string.
[base URI] The base URI of the PI. Note that if an infoset is serialized as an XML document, it will not be possible to preserve the base URI of any PI that originally appeared at the top level of an external entity, since there is no syntax for PIs corresponding to the xml:base attribute on elements.
[notation] The notation information item named by the target. If there is no declaration for a notation with that name, or there are multiple declarations, this property has no value. If no declaration has been read, but the [all declarations processed] property of the document information item is false (so there may be an unread declaration), then the value of this property is unknown.
[parent] The document, element, or document type declaration information item which contains this information item in its [children] property.

2.5. Unexpanded Entity Reference Information Items

XML Definition: Section 4.4.3, Included If Validating

A unexpanded entity reference information item serves as a placeholder by which an XML processor can indicate that it has not expanded an external parsed entity. There is such an information item for each unexpanded reference to an external general entity within the content of an element. A validating XML processor, or a non-validating processor that reads all external general entities, will never generate unexpanded entity reference information items for a valid document.

An unexpanded entity reference information item has the following properties:

[name] The name of the entity referenced.
[system identifier] The system identifier of the entity, as it appears in the declaration of the entity, without any additional URI escaping applied by the processor. If there is no declaration for the entity, this property has no value. If no declaration has been read, but the [all declarations processed] property of the document information item is false (so there may be an unread declaration), then the value of this property is unknown.
[public identifier] The public identifier of the entity, normalized as described in 4.2.2 External Entities [XML]. If there is no declaration for the entity, or the declaration does not include a public identifier, this property has no value. If no declaration has been read, but the [all declarations processed] property of the document information item is false (so there may be an unread declaration), then the value of this property is unknown.
[declaration base URI] The base URI relative to which the system identifier should be resolved (i.e. the base URI of the resource within which the entity declaration occurs). This is unknown or has no value in the same circumstances as the [system identifier] property.
[parent] The element information item which contains this information item in its [children] property.

2.6. Character Information Items

XML Syntax: [2] Char (Section 2.2, Characters)

There is a character information item for each data character that appears in the document, whether literally, as a character reference, or within a CDATA section.

Each character is a logically separate information item, but XML applications are free to chunk characters into larger groups as necessary or desirable.

A character information item has the following properties:

[character code] The ISO 10646 character code (in the range 0 to #x10FFFF, though not every value in this range is a legal XML character code) of the character.
[element content whitespace] A boolean indicating whether the character is white space appearing within element content (see [XML], 2.10 "White Space Handling"). Note that validating XML processors are required to provide this information. If there is no declaration for the containing element, or there are multiple declarations, this property has no value for white space characters. If no declaration has been read, but the [all declarations processed] property of the document information item is false (so there may be an unread declaration), then the value of this property is unknown for white space characters. It is always false for characters that are not white space.
[parent] The element information item which contains this information item in its [children] property.

2.7. Comment Information Items

XML Definition: comment (Section 2.5, Comments)

XML Syntax: [15] Comment (Section 2.5, Comments)

There is a comment information item for each XML comment in the original document, except for those appearing in the DTD (which are not represented).

A comment information item has the following properties:

[content] A string representing the content of the comment.
[parent] The document or element information item which contains this information item in its [children] property.

2.8. The Document Type Declaration Information Item

XML Definition: document type declaration (section 2.8, Prolog and Document Type Declaration)

XML Syntax: [28] doctypedecl (section 2.8, Prolog and Document Type Declaration)

If the XML document has a document type declaration, then the information set contains a single document type declaration information item. Note that entities and notations are provided as properties of the document information item, not the document type declaration information item.

A document type declaration information item has the following properties:

[system identifier] The system identifier of the external subset, as it appears in the DOCTYPE declaration, without any additional URI escaping applied by the processor. If there is no external subset this property has no value.
[public identifier] The public identifier of the external subset, normalized as described in 4.2.2 External Entities [XML]. If there is no external subset or if it has no public identifier, this property has no value.
[children] An ordered list of processing instruction information items representing processing instructions appearing in the DTD, in the original document order. Items from the internal DTD subset appear before those in the external subset.
[parent] The document information item.

2.9. Unparsed Entity Information Items

XML Definition: entity (section 4, Physical Structures)

XML Syntax: [71] GEDecl (section 4.2, Entities)

There is an unparsed entity information item for each unparsed general entity declared in the DTD.

An unparsed entity information item has the following properties:

[name] The name of the entity.
[system identifier] The system identifier of the entity, as it appears in the declaration of the entity, without any additional URI escaping applied by the processor.
[public identifier] The public identifier of the entity, normalized as described in 4.2.2 External Entities [XML]. If the entity has no public identifier, this property has no value.
[declaration base URI] The base URI relative to which the system identifier should be resolved (i.e. the base URI of the resource within which the entity declaration occurs).
[notation name] The notation name associated with the entity.
[notation] The notation information item named by the notation name. If there is no declaration for a notation with that name, or there are multiple declarations, this property has no value. If no declaration has been read, but the [all declarations processed] property of the document information item is false (so there may be an unread declaration), then the value of this property is unknown.

2.10. Notation Information Items

XML Definition: notation (section 4.7, Notations)

XML Syntax: [82] NotationDecl (section 4.7, Notations)

There is a notation information item for each notation declared in the DTD.

A notation information item has the following properties:

[name] The name of the notation.
[system identifier] The system identifier of the notation, as it appears in the declaration of the notation, without any additional URI escaping applied by the processor. If no system identifier was specified, this property has no value.
[public identifier] The public identifier of the notation, normalized as described in 4.2.2 External Entities [XML]. If the notation has no public identifier, this property has no value.
[declaration base URI] The base URI relative to which the system identifier should be resolved (i.e. the base URI of the resource within which the notation declaration occurs).

2.11. Namespace Information Items

Each element in the document has a namespace information item for each namespace that is in scope for that element.

A namespace information item has the following properties:

[prefix] The prefix whose binding this item describes. Syntactically, this is the part of the attribute name following the xmlns: prefix. If the attribute name is simply xmlns, so that the declaration is of the default namespace, this property has no value.
[namespace name] The namespace name to which the prefix is bound.

3. Conformance

Since the purpose of the Information Set is to provide a set of definitions, conformance is a property of specifications that use those definitions, rather than of implementations.

Specifications referring to the Infoset must:

Indicate the information items and properties that are needed to implement the specification. (This indirectly imposes conformance requirements on processors used to implement the specification.)
Specify how other information items and properties are treated (for example, they might be passed through unchanged).
Note any information required from an XML document that is not defined by the Infoset.
Note any difference in the use of terms defined by the Infoset (this should be avoided).

If a specification allows the construction of an infoset that has inconsistencies as described above under Synthetic Infosets it may describe how those inconsistencies are to be resolved, and should do so if it provides for serialization of the infoset.

Appendix A. References

Normative References

ISO/IEC 10646: ISO (International Organization for Standardization). ISO/IEC 10646-1:2000. Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane and ISO/IEC 10646-2:2001.Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 2: Supplementary Planes, as, from time to time, amended, replaced by a new edition or expanded by the addition of new parts. [Geneva]: International Organization for Standardization. (See http://www.iso.ch for the latest version.)
Namespaces: Namespaces in XML, W3C, eds. Tim Bray, Dave Hollander, Andrew Layman. 14 January 1999. Available at http://www.w3.org/TR/REC-xml-names.
Namespaces 1.1: Namespaces in XML 1.1, W3C, eds. Tim Bray, Dave Hollander, Andrew Layman, Richard Tobin. 4 February 2004. Available at http://www.w3.org/TR/xml-names11.
RFC2119: Key words for use in RFCs to Indicate Requirement Levels, ed. S. Bradner. March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt.
XML: Extensible Markup Language (XML) 1.0 (Third Edition), W3C, eds. Tim Bray, Jean Paoli, C.M. Sperberg-McQueen, Eve Maler, François Yergeau. 4 February 2004. Available at http://www.w3.org/TR/REC-xml.
XML 1.1: Extensible Markup Language (XML) 1.1, W3C, eds. Tim Bray, Jean Paoli, C.M. Sperberg-McQueen, Eve Maler, John Cowan, François Yergeau. 4 February 2004. Available at http://www.w3.org/TR/xml11.
XML Base: XML Base, W3C, ed. Jonathan Marsh. February 2000. Available at http://www.w3.org/TR/xmlbase.

Informative References

DOM: Document Object Model (DOM) Level 1 Specification, W3C, eds. Vidur Apparao, Steve Byrne, Mike Champion, et al. 1 October 1998. Available at http://www.w3.org/TR/REC-DOM-Level-1.
XPointer-Liaison: XPointer-Information Set Liaison Statement, W3C, ed. Steven J. DeRose. 24 February 1999. Available at http://www.w3.org/TR/NOTE-xptr-infoset-liaison.
Relative Namespace URI References: Results of W3C XML Plenary Ballot on relative URI References in namespace declarations, 3-17 July 2000, W3C, eds. Dave Hollander, C. M. Sperberg-McQueen. 6 September 2000. Available at http://www.w3.org/2000/09/xppa.
RDF Schema for the XML Information Set: RDF Schema for the XML Information Set, W3C, ed. Richard Tobin. 6 April 2001. Available at http://www.w3.org/TR/xml-infoset-rdfs.

Appendix B: XML Reporting Requirements (informative)

Although the XML Recommendation [XML] is primarily concerned with XML syntax, it also includes some specific reporting requirements for XML processors.

The reporting requirements include errors, which are outside the scope of this specification, and document information. All of the XML requirements for document information reporting have been integrated into the XML Information Set; numbers in parentheses refer to sections of the XML Recommendation:

An XML processor must always provide all characters in a document that are not part of markup to the application (2.10).
A validating XML processor must inform the application which of the character data in a document is white space appearing within element content (2.10).
An XML processor must normalize line-ends to LF before passing them to the application (2.11).
An XML processor must normalize the value of attributes according to the rules in clause 3.3.3 before passing them to the application.
An XML processor must pass the names and external identifiers (system identifiers, public identifiers or both) of declared notations to the application (4.7).
When the name of an unparsed entity appears as the explicit or default value of an ENTITY or ENTITIES attribute, an XML processor must provide the names, system identifiers, and (if present) public identifiers of both the entity and its notation to the application (4.6, 4.7).
An XML processor must pass processing instructions to the application (2.6).
An XML processor (necessarily a non-validating one) that does not include the replacement text of an external parsed entity in place of an entity reference must notify the application that it recognized but did not read the entity (4.4.3).
A validating XML processor must include the replacement text of an entity in place of an entity reference (5.2).
An XML processor must supply the default value of attributes declared in the DTD for a given element type but not appearing in the element's start tag (3.3.2).

Appendix C: Example (informative)

Consider the following example XML document:

<?xml version="1.0"?>    <msg:message doc:date="19990421"               	xmlns:doc="http://doc.example.org/namespaces/doc"               	xmlns:msg="http://message.example.org/"  >Phone home!</msg:message>

The information set for this XML document contains the following information items:

A document information item.
An element information item with namespace name "http://message.example.org/", local part "message", and prefix "msg".
An attribute information item with the namespace name "http://doc.example.org/namespaces/doc", local part "date", prefix "doc", and normalized value "19990421".
Three namespace information items for the http://www.w3.org/XML/1998/namespace, http://doc.example.org/namespaces/doc, and http://message.example.org/ namespaces.
Two attribute information items for the namespace attributes.
Eleven character information items for the character data.

Appendix D: What is not in the Information Set

The following information is not represented in the current version of the XML Information Set (this list is not intended to be exhaustive):

The content models of elements, from ELEMENT declarations in the DTD.
The grouping and ordering of attribute declarations in ATTLIST declarations.
The document type name.
White space outside the document element.
White space immediately following the target name of a PI.
Whether characters are represented by character references.
The difference between the two forms of an empty element: <foo/> and <foo></foo>.
White space within start-tags (other than significant white space in attribute values) and end-tags.
The difference between CR, CR-LF, and LF line termination.
The order of attributes within a start-tag.
The order of declarations within the DTD.
The boundaries of conditional sections in the DTD.
The boundaries of parameter entities in the DTD.
Comments in the DTD.
The location of declarations (whether in internal or external subset or parameter entities).
Any ignored declarations, including those within an IGNORE conditional section, as well as entity and attribute declarations ignored because previous declarations override them.
The kind of quotation marks (single or double) used to quote attribute values.
The boundaries of general parsed entities.
The boundaries of CDATA marked sections.
The default value of attributes declared in the DTD.

Appendix E: RDF Schema (informative)

See RDF Schema for the XML Information Set for a formal characterization of the Infoset.

[tex] How Latex Fonts works

here is how to add a font work with latex when LATEX detect a command that indicates using a new font, such as \usefont{s_enc}{s_family}{s_series}{s_shape}\selectfont, the LATEX do following things in order.

search for fd file named s_encs_family, e.g. t1myfont.fd, or failed if there is no such file.
get the tfm name for such a font which has the attributes {s_enc}{s_family}{s_series}{s_shape} from the fd file.
search for the tfm font file or failed if the font is not exist.

LATEX will generate a dvi file if all above steps are passed. Now the rest things will be related to dvi driver. I use yap to watch the file generated by LATEX will got a wrong message "font not loadable". and details Making PK font: e:\pkg\cTeX\texmf\miktex\bin\makepk.exe --verbose sfont 600 600 magstep(0.0) ljfour Trying to make PK font "sfont" (at 600 DPI)... "makemf" --verbose "sfont" "ttf2pk" -q -t "sfont" makepk: "sfont.pk" could not be created. Loading 'cmr10' instead. Do the following command to get the new font working with PDFLATEX and yap

ttf2tfm sfont.ttf >>ttf2pk.cfg

[motor]

reference at http://www.acroname.com/robotics/info/articles/back-emf/back-emf.html

Contents

Introduction
The Process
The Moto 1.0 and Back-EMF
Back-EMF Measurement Circuits
Limitations
Credit and Attribution

Introduction

Back-EMF refers to using the voltage generated by a spinning motor (EMF) to conclude the speed of the motor's rotation. This can be used in motion control algorithms to modulate the velocity or to compute the angular distance the motor has traveled over time. This article attempts to describe this form of motion control feedback in more detail.

Typically a motor takes power in the form of voltage and current and converts the energy into mechanical energy in the form of rotation. With a generator, this process is simply reversed. A generator takes mechanical energy and converts it into both electrical energy with a voltage and current. Most motors can be generators by just spinning the motor and looking for a voltage/current on the motor windings.

Note

A very simple demonstration of this is to wire two LEGO motors together. If you spin one, the other spins based on the current you create when turning the windings of the first motor. If you have them around, give this a try, it is fascinating.

When doing Back-EMF measurements for motion control, this fact that a motor can also be a generator is exploited. The motor is run almost continually as a motor with current being supplied to turn the windings. Occasionally, and for a very short period of time, the process is reversed. The windings are allowed to float and the inertia in the motor keeps it spinning while a measurement of the voltage from the spinning motor/generator is taken.

The voltage observed when the motor is spinning is directly proportional to the speed the motor is running. This fact can be used to "peek" at the motor's speed with no optical encoders or other forms of active feedback.

Contents

The Process

Reading the velocity from a motor using Back-EMF requires two alternating steps. First, the motor is run for some period of time by providing current to the windings. This current can be supplied as a constant voltage or a PWM motor input to vary the speed. The second step is to remove the current from the windings and "float" them. This means that there is no active circuit between the windings and any other source/sink. This allows the inertia in the motor and mechanical system to spin the motor long enough to measure the voltage produced by the motor. Typically these two steps are alternated roughly 50Hz (times per second).

The time required for the motor to flip from a motor to a generator depends on the inherent capacitance or stored charge in the induction of the motor windings. This time is typically in the order of a millisecond or two, depending on the conditions. Watching the process on a scope can give you some idea of the timing.

Below we walk through some simulated scope pictures to show these various steps and introduce some terminology used in the BrainStem Moto 1.0 Application to control a motor using Back-EMF.

Simulated scope running at 25% duty cycle.

Above we see how a scope might look when running a motor at 1/4 speed. Notice how the Back-EMF rises up to roughly 1/4 of the PWM maximum voltage and stabilizes. If the Back-EMF measurement gap is too long, the motor will begin to slow down and the feedback will drop accordingly.

Simulated scope running at 3/4% duty cycle.

Next, we see what the scope might look like when running the motor at 3/4 speed. Notice how most everything remains the same but now the stable Back-EMF signal is roughly 3/4 of the maximum motor winding voltage.

Simulated scope with induced load running at 75% duty cycle.

Finally, we see what the 3/4 speed case might look like when the motor is under load. Since the motor has a great deal of current developing a large induction in the windings when it is under load, the inductive spike is bigger and the stable Back-EMF region takes longer to achieve as this larger induction must be dumped from the windings first before the Back-EMF region stabilizes. Proper tuning of the latency before taking the measurement is important to minimize the measurement gap while allowing enough time for stable Back-EMF measurement.

Contents

The Moto 1.0 and Back-EMF

The BrainStem Moto 1.0 module is a very flexible motion control board. It has the built in parameters to handle timing required for Back-EMF feedback control using a PID loop to manage the motor outputs based on the velocity feedback provided by the Back-EMF measurement.

Below is a diagram of the flow of information in the closed-loop control when using the Moto 1.0 module in A/D velocity mode (Back-EMF mode). This loop repeats at an adjustable frequency with typical values ranging from 10-200 Hz. to effect speed control without encoders.

Brainstem Moto internal Back-EMF control loop.

The settings (the orange inputs on the left) are all adjustable through a simple User Interface that runs on a variety of platforms. Here is the interface used to adjust these settings.

Brainstem Moto user interface for Back-EMF control.

Contents

Back-EMF Measurement Circuits

The Back-EMF measurement circuit can be a bit challenging. The circuit needs to handle the (possibly large) voltages of the motor and convert them into a range that the A/D inputs of a microcontroller can handle. In addition, the windings of the motor invert when the motor direction changes so the circuit needs to both adjust the voltage range and create an input offset so that the neutral (not spinning) voltage output of the measurement circuit centers around a known value.

If you are only running the motor in one direction, this circuit can be as simple as a resistor ladder to scale the voltage to the A/D range. If the motor is running bi-directionally, a more sophisticated circuit is required. The Acroname 3A Back-EMF H-Bridge uses a two-stage operational amplifier to manage this voltage scaling and offset. This circuit also must have the brake turned ON for floating the windings during the Back-EMF measurement gap due to the characteristics of the LMD 18200 H-Bridge employed for the motor outputs on the 3A Back-EMF H-Bridge. This activation of the brake circuit is referred to as "auto braking" in the Moto 1.0 module.

There are probably as many ways to measure the voltage in a Back-EMF circuit as there are potential motor, direction, and voltage combinations. The key is to ensure that the measurement is passive so it doesn't affect the motor and that it is fast so that the motor can spend most of the time running.

Contents

Limitations

Back-EMF velocity measurement is novel and great if you don't have an encoder on your motor. Good quadrature encoders like those used in the Garcia robot will typically out perform the Back-EMF measurement method described here. In addition, encoders can give absolute position information whereas Back-EMF can only report velocity. Position must be computed through integrating the velocity over time which has significant limitations.

One other limitation of Back-EMF velocity control is that it effectively reduces the maximal duty cycle that can be obtained from the motor as it requires the motor to be turned off at times during the operation to facilitate the measurements.

Contents

Credit and Attribution

Back-EMF motion control has been around for decades finding use in model trains, audio tape transport mechanisms, and other special purpose uses. Acroname first learned of this approach to speed control while talking with Randy Sargent about work he and Bill Bailey were doing with velocity measurement for robotics. Thanks to Randy and Bill for sharing this information with the robotics community.