20060710:

Update:
		Miscellaneous updates and corrected spelling.


git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@2110 7ae35d74-ebe9-4afe-98af-79ac388436b8

README

@@ -1,5 +1,5 @@
 hamlib - (C) Frank Singleton 2000 (vk3fcs@ix.netcom.com)
-and (C) Stephane Fillod 2000-2003
+and (C) Stephane Fillod 2000-2006
 
 The purpose of this project is to provide stable, flexible,
 shared libraries that enable quicker development of Amateur
@@ -8,8 +8,8 @@ Radio Equipment Control Applications.
 Many Amateur Radio Transceivers come with serial interfaces
 that allows software to control the radio. This project will
 endeavour to provide shared libraries that greatly simplify
-the application programmers interaction with radio equipment.
- 
+the application programmer's interaction with radio equipment
+and other controllable devices such as rotators, switches, etc.
 
 The shared libs will provide functions for both radio control,
 and data retrieval from the radio.
@@ -41,10 +41,9 @@ Backend Examples are:
 2. hamlib-xxxx.so will provide connectivity to the Wiz-bang
    moon-melter 101A (yikes..)
 
-Hamlib will also enable developers to develop
-professional looking GUI's towards a standard control library
-API, and they would not have to worry about the underlying
-connection towards physical hardware.
+Hamlib will also enable developers to develop professional looking GUI's 
+towards a standard control library API, and they would not have to worry 
+about the underlying connection towards physical hardware.
  
 Initially serial (RS232) connectivity will be handled, but
 I expect that IP (and other) connectivity will follow afterwards. 
@@ -61,8 +60,13 @@ you'll need at least the following tools:
 	* doxygen
 	* cvs and ssh to connect to http://sourceforge.net/
 
-There's also a README.betatester and README.developer files in this directory
-if you feel like hacking hamlib.
+There are also the README.betatester and README.developer files in this 
+directory if you feel like hacking hamlib.  Otherwise, contributions of rig 
+specifications and protocol documentation are highly encouraged.  Do keep
+in mind that in some cases the manufacturer may not provide complete control
+information or it is only available under a Non-Disclosure Agreement (NDA).
+Any documentation *must* be publically available so we can legally write and
+distribute Free Software supporting a given device.
 
 However, if you just want to recompile the library, please refer
 to the INSTALL file. IMPORTANT: If autoconf or automake are installed on
@@ -70,12 +74,13 @@ your system, make sure they are matching *at least* the version shown above.
 The Hamlib team is very interrested to hear from you, how Hamlib
 builds and works on your system, especially on non-Linux system or 
 non-PC systems. We try to make Hamlib as portable as possible.
+
 Please report in case of problems at hamlib-developer@lists.sourceforge.net
 Patches are welcome too!
-And for those who were brave enough to read until then, but not lucky enough
-to rebuild the lib, there're good news. The RPM and deb packages are
-available at the sourceforge.net site. Enjoy!
 
+And for those who were brave enough to read until here, but not lucky enough
+to rebuild the lib, there is good news. The RPM and deb packages are
+available at the sourceforge.net site. Enjoy!
 
 Take a look at tests/README for more info on simple examples.
 

README.betatester

@@ -1,15 +1,19 @@
 
 * Why does Hamlib need beta-testers?
+
 Hamlib is developed by a team of enthusiasts around the world, for fun,
 much in the spirit of hamradio. (Note that it is not restricted for ham
-usage only). There's a great deal of protocols and rigs around the
+usage only). There are a great deal of protocols and rigs around the world
 developers may not own. However, protocols may be available, so backends
-can be implemented, but cannot always be tested by developers.
-That's where beta-testers are so precious. On top of that, I've been
-told that there's no such sure thing like bug free code. 
+can be implemented, but cannot always be tested by developers. That's where 
+beta-testers are so precious. On top of that, I've been told that there's 
+no such sure thing like bug free code. 
+
 Feedback and improvement requests are also valuable.
 
+
 * Okay, you volunteer as beta-tester, how to proceed?
+
 First of all, you can start testing official releases. They are easier to
 test because they come in precompiled and packaged (.rpm, .deb).
 Reports from these versions are still very appreciated, on
@@ -23,12 +27,13 @@ waiting for the next official version.
 
 So to proceed, you will have first to obtain either a snapshot or 
 a check out of the latest sources from cvs, then rebuild the Hamlib 
-package and finally test it with your rig.
-Don't worry, it's much simpler than what it looks, despite the size of the
-package.
+package and finally test it with your rig. Don't worry, it's much simpler 
+than what it looks, despite the size of the package.
+
 Pre-requisite:
  - some kind of internet access
  - POSIXish compiler toolchain
+
  
 So here we go:
 
@@ -37,6 +42,7 @@ So here we go:
 Download the latest snapshot from http://www.hamlib.org/bleeding-edge/
 You'll find tar balls with names like hamlib-1.1.4-cvs-021021.tar.gz,
 i.e. a check out made 21-10-02, ready for building.
+
 If you cannot afford the cvs checkout, and want a more recent snapshot,
 just ask for it on the hamlib-developer mailing list.
 
@@ -47,7 +53,8 @@ to obtain a cvs checkout, what are the required tools versions
 (very important or make won't even work!), and how to deal with autogen.sh.
 
 * build
-Reading the INSTALL file in top directory will explain you more verbosely
+
+Reading the INSTALL file in top directory will explain in more detail how
 to do the following commands. 
 
 	./configure --disable-static --prefix=/some/where
@@ -59,8 +66,9 @@ compilation if you don't plan to use static libraries.
 
 
 * Structure
-For the braves who want to peruse the contents, here's what all the
-subdirectories are for:
+
+For the brave who want to peruse the contents, here are what all the
+subdirectories are for (these are just a sample):
 
 alinco,aor,icom,
 jrc,kachina,kenwood,
@@ -80,6 +88,7 @@ include:		non-distributed header files go there
 src:			Hamlib frontend source directory
 tests:			rigctl/rotctl and various C programs for testing
 
+
 * testing Hamlib
 
 Don't attempt to test Hamlib from source directory unless you're a
@@ -90,9 +99,11 @@ and .libs).
 So here we go. First of all, identify your rig model id.
 Make sure /some/where/bin is in your PATH, rigctl has to be reachable.
 Run "rigctl -l"  to get a list of rigs supported by Hamlib.
+
 If you cannot find yours in the list, please report to the 
 hamlib-developer mailing list. Protocol manual and rig specification may
 help a lot.
+
 You found your id? good! You're almost ready to use rigctl.
 Have a quick look at its manual page:
 	man -M /some/where/man rigctl
@@ -105,6 +116,7 @@ Let's say you own an Icom IC-756:
 The -vvvvv is very important since this will increase verbosity, and give
 precious traces to developpers if something goes wrong. At this level, 
 the protocol data exchanged will also be dumped.
+
 Unless some problem shows up, you should be presented with a menu
 like "Rig command: ". Enter "?" followed by return to have the list 
 of available commands. 'Q' or 'q' quits rigctl immediately.
@@ -125,7 +137,7 @@ m,M     get_mode/set_mode       FM, USB, LSB, CW, WFM, etc.
 G       vfo_op                  UP, DOWN
 _       get_info                should give remote Id and firmware vers
 
-NB: some functions may not be implemented in the backend of
+NB: some functions may not be implemented in the backend or
 simply not available on this rig.
 
 When reporting to hamlib-developer mailing list, please include traces and
@@ -161,7 +173,8 @@ And then send my_rig_traces.txt to hamlib-developer mailing list.
 Okay fellows, test as much as you can, in the weirdest situations if
 possible. There is a special prize for those who find 'Segmentation fault'
 and other nasty bugs.
-Needless to say, patchs are also very welcome :-)
+
+Needless to say, patches are also very welcome :-)
 
 
 Oct 29, 2002

README.developer

@@ -1,5 +1,5 @@
 Hamlib - (C) Frank Singleton 2000 (vk3fcs@ix.netcom.com)
-	and Stephane Fillod 2000-2005
+	and Stephane Fillod 2000-2006
 
 Take a look at http://sourceforge.net/projects/hamlib/
 Here you will find a mail list, and the latest CVS releases.
@@ -96,8 +96,7 @@ General Guidelines.
 1. Building
 
 If you just want to recompile the library, please refer
-to the INSTALL file. 
-This document introduces hacking the code of Hamlib.
+to the INSTALL file.  This document introduces hacking the code of Hamlib.
 
 1.1 Obtaining sources: anonymous (pserver) cvs checkout
 
@@ -106,6 +105,7 @@ This document introduces hacking the code of Hamlib.
 
 When prompted for a password for anonymous, simply press the Enter key.
 The check out has only to be done the first time. 
+
 After the initial retrieval, whenever you want to update your local
 version, issue the following command in the root directory of hamlib.
 
@@ -118,7 +118,7 @@ for more information about how to use the CVS repository of Hamlib.
 
 1.2. Requirements
 
-Hamlib is entirely developped using GNU tools, under various Linux systems. 
+Hamlib is entirely developed using GNU tools, under various Linux systems. 
 Note that it is not restricted to Linux systems. We welcome anyone who
 has access to a POSIXish system to port Hamlib to. Contact us for help.
 
@@ -199,16 +199,16 @@ or pass "SHELL=bash" as a parameter to make.
 
 1.4. Feedback
 
-The Hamlib team is very interrested to hear from you, how Hamlib
+The Hamlib team is very interested to hear from you, how Hamlib
 builds and works on your system, especially on non-Linux system or 
 non-PC systems. We try to make Hamlib as portable as possible.
 Please report in case of problems at hamlib-developer@lists.sourceforge.net
 Patches are welcome too!
 
-So far, Hamlib has been tested successfuly under the following systems:
+So far, Hamlib has been tested successfully under the following systems:
 (if your system is not present, please report to the mailing list)
 
-	* Debian potato/sarge/sid i386
+	* Debian i386
 	* Debian sid mipsel
 	* RedHat i386
 	* Linux ppc
@@ -300,7 +300,9 @@ like this. The error checking is removed for simplicity.
    to see some GTK apps that use the hamlib API's
    so they can be used by end users as a nice part of the
    Ham shack.
-   Starting point: kontakt, grig
+
+   Starting points (not exhaustive): 
+   	gmfsk, gpredict, grig, klog, kontakt, ktrack, xlog, xtlf
 
 8. Contributing code
 
@@ -309,6 +311,7 @@ like this. The error checking is removed for simplicity.
    Contributed code to the Hamlib frontend must be released under the LGPL.
    Contributed code to Hamlib backends must follow backend current license.
    Needless to say, the LGPL is the license of choice.
+
    End user applications like rigctl, rotctl and RPC daemons should be released
    under the GPL, so any contributed code must follow the rule.